Title: Author

:

Thoughts about UI design Oren Cohen Shwartz

Introduction
The importance of designing a good UI is well known in our days. We have made some progress since the boring console applications. Now days we are not talking about just an intuitive UI design but about Smart client applications with extended capabilities. Designing a good UI application looks like an easy task but in reality it is not. Meeting with customer needs; surly with hundred of them is a hard task. This article describes several UI Design rules; complying with them, so I believe, will be a good start for better UI application.

Who should read this article?
The article might be useful for UI designer, Product and Project Managers and of course developers.

Disclaimer
The article contains thoughts of my own of how to approach UI design. I assume that some of the readers will disagree with some of the rules and that is just fine, after all the extent of the UI quality is in the eye of the beholder. Nevertheless, this article sees the light because I think it suit most of Windows UI applications I have used.

Consistency
If the UI is lack of consistency then it sucks. The consistency should be both in look and usage. If you use Microsoft Outlook you are probably know what I am talking about. How many times did you use the Ctrl+F shortcut in Outlook and learn to see that in this program it forwards the email. This lack of consistency get the bad side of me, and it does so time after time again. This is A Bug. It is not only that the fox in Redmond irritate the users

they have also put Microsoft in bad reputation situation. Since the emerging of Windows OS, Microsoft tried to encourage developers to write Windows applications. The use of WIN API was, and still is, free of charge (as opposed to MAC); they have developed frameworks like MFC, VB, ATL and tools. Moreover Microsoft wanted the developers to keep the consistency in term of windows use but failed to so in Outlook.

Example 1:

In the above example Nero UI Designer have decided to innovate by designing non traditional window. While it looks sharp it is still confusing because the close button is not in the upper right side of the window but in the bottom. The close icon is, for some reason, similar to XP shutdown icon. In order to accomplish the UI Consistency rule we must followed the common Windows application behaviors. My application of choice is most of the Office package applications. I always turn to the Office package application and for the following reasons: First, the UI Design of this package is well debugged. Second, users of my application use them intensively. Third Microsoft put money, thoughts and effort in this design. One of my colleagues hates the fact that he need to develop Office like applications. He used to complain about his own creativity which is going down the drain.

I have used to told him that it is not important how much he hates what Microsoft represents, there are still good reasons to use it, and not only for the end users sake. Copycat Office Toolbars and Menus simplify the development work because we ride on Microsoft experience in UI designing. Be rest and sure that company of this caliber spends a lot of time and money on this issue why spending it again?

Example 2:

In the above example we can see that the menu is missing the ALT shortcut like File. The icons in each layout look like it was designed by different graphic designer. The export icon is not meaningful. The layout is too loaded. In places where Windows is not consistent or where your design is simply differ then you need to write a set of rules that will be applied for your entire application(s). For example if you use Toolbar keep using it in each Form. Don’t decide out of a sudden to drop it in one of your Forms. Another example is the use of Context Menu. If you have certain common items in a context menu like: Copy, Cut and Past then you should keep them for each, relevant control, and in the same order.

The usage might be differing and the context menus might have extra specific items for each control but the common need to stay, for consistency purpose. It is also important to use the same font family and size and to keep similar Window layout.

Always think about the end user
This rule could have, humouredly, putted like this: “Hmmm… someone will actually going to use it some day”. Only there is nothing to laugh about. This rule is dead serious. If you don’t think about the user in each step of the UI design and in the development stages then no customer, certainly not a happy one, will use your application. Developers and UI Designers (who use to be developers) tend to forget about the end user skills. They think about them self as the end users. In reality most of the end user skills is much lower than those of the developer. This rule is not easy to comply to because day after day on the designing and developing table we get familiar with the defects and bad UI Design begins to make sense. It is crucial to detect the type of users that is going to work with the application. Mostly, the best practice is to aim to the lowest common ground and apply advance and advance of advance capabilities in conceal. It would also be great to allow each user to customize the UI according to his knowledge, capabilities and expertise. This customization data must be stored in a persistent media for each user for future application runs and need to stay intact after application updates? The quality of the user experience is determined, in my humble opinion, by the following main questions: • Do the features and functionalities that I have yearned to have exists and work well? • Is it simple, intuitive and easy to use? • Is it done fast in term of performance? • Is it stable? If the user answers those question with Yes answers then we are facing a happy user that will use the application happily again an again. Meet the user needs and he will praise your software else he will blame you for all the miseries exists in the world.

The problem is when there are various types of users with different expectations. In one of the projects that I have participate in, I have notice something very interesting about the use of UI. The application UI exposes the same functionality in three different places: Menu, Toolbar and Context Menu. At first it looked like a redundancy issue but soon I saw that three different people in my company used one of option accordingly. Using this approach makes different type of users happy. Another practice that helps to think about the end users during the designing and developing process is to meet them on regular basis and to gather feedbacks in pre marketing stages. You should also run surveys between the customers after the buying or examination processes. Asking for the users for their involvements will teach them that you are committed to quality and cause them to be much more patient and cooperative in regards to bugs.

Keep it clean and don’t over estimate users capabilities
Design good UI application is not about thinking how to make a Toolbar but, what should be the type of it: Should it be Dockable or not? What to put in it? Does it required? User might ask the following question when working with your application: How to do it? Where to do it? When to do it? Make sure that the questions can be answered by the user within short period of time. As shortest the learning curve is the happier the users are. • Avoid overwhelmed messages and dialogs controls which requires the user to make a decisions. At least you should make it as clear as it can be. Users just hate to read those messages like: “…yada yada ….happened…..” and then after few frightening lines of this story it requires to answer a question like: “…Do you want to X?” The user does not give a damn about this kind of messages so don't load him with information. It is hard task to decide for your users what they should decide about and what not. There is a thin line between annoying and upset them for not letting them know about stuff.

Example 3:

In the above example you can see extensive use of words in Winzip. When you see this message you are saying to your self “Oh boy do I have 15 minutes to read all this stuff. • Do not depend on your manual and help files. You have probably heard about the initials: RTFM (Read The Fucking Manual). It is a crying shame but it is true, users don’t read it or at least they will do almost everything to avoid it. The more money the application cost the more chances that the users will use the manual. For example, if the application is free and the user does not get along with it, he might just uninstall it. The above fact does not mean you can avoid of writing a manual; the customer still demands it. What you can do, is to make the UI clean, clear and simple to work with. • Do not make an assumption that the end user is intelligent enough to not customizing the UI background to black because this is the color of the font or because it will look ugly. I am using Murphy’s main law to say that if the application UI allows the user to shoot is leg then he will probably manage to do so. Make sure to protect the application against stupid users else you will be dealing with stupid company blames. • Do not burden the user with error messages that he can not digest. Keep UI information messages short an explanatory. Create rich log to send to the customer support instead. Be sure you clear the horror messages like “…Fatal problem…” or “…we should not arrive to this code…” before you ship the application.

Make sure the application stand tall in any circumstances. Catch all the error and display friendly messages only. • Do not ask what the user can do in order to work better with your application and get the most of it. Do ask what the application can do for the users. End users are lazy. If you can ease their work they will appreciate it. Give the users tools to create semi or fully automatic processes so they won’t have to repeat doing the same stuff over and over again and have some free time to read the latest news on the web. Of course, I am talking about you. You are and exception :-) I am talking about Dilbert and Homer Simpson. If you don’t have the resources to make each part of your application simple at least make sure that the mainstream, frequent, actions are as simple as can be.

Customizability
There is no such thing as exaggeration in customization capabilities. I have never heard anyone complains about an application that there are too many configuration options. They might be angry only if those options are not ordered well. This rule is important for the following reasons: The amount of configuration options is stand in direct line with the ease of tailoring the application for specific customer; a job which is usually contains pain to the Customer/Project team members. The extent of customization options, allows users from different level of expertise to adapt the application to their needs. The user customizations data should be, of course, saved for future application runs. Good customizable application enables the use of it for user with disabilities. For example some of the end users might be color blind. In this case the option of changing the application colors is mandatory.

Take the user machine into consideration
When you decide on 32 bit color quality for the Toolbar icons you don’t take the users with max 16 bit color screen into consideration. Another example is the screen size. This kind of consideration, if left unhandled, can cause your application to look poor.

Take the user machine into consideration
Good UI which complies with all the above rules help firms to sale products. Sometime a competitive company steals business opertunities from your company, simply because their UI is better looking. It shines, sparks and makes good impression. It dose not matter if your application have much richer functionalities. If it looks ‘low tech’ then there is ‘no take’. The article describes only a drop in the oeacens of UI tips and rules. There are many other. I encourge you to read and learn about this topic it is the only way to write better UI applicaitons.

Bibliography
• • • • • User Interface Design For Programmers By Joel Spolsky October 24, 2001 The Essential Guide to User Interface Design by Wilbert O. Galitz, 2002 User-Centered Design Principles, MSDN Understanding Users, MSDN Design Specifications and Guidelines, MSDN