The user interface
Some comments and application development tips about the design of the user interface
Copyright © 2000 Ernesto De Spirito
NOTE: No user was ill-treated to write this
article. ;)
 |
Contents
- Introduction
- Users levels
- Applications for different users groups
- Exterior beauty
- Visual elements of the user interface
- Explorer and Browser interfaces
- Color
- Resolution and color depth
- Fonts
- Further reading
 |
When thinking of the user interface most software developers think of windows, menus, dialogs, graphics, colors, etc., and forget the main component of the user interface: the user! For some reason we tend to think of (our concept of) the beauty or the presentation of our application rather than the real purpose of the interface: facilitating the interaction between the user and the application, or making it easy for the user to "talk" with the application, to say it in plain English.
Who is this nightmare character that blames us for every silly mistake
he makes with our application? ;) We'll try to typify the users in three
groups according to their level of knowledge and experience.
This is an elegant way of referring to those users who most likely will
be beginners all their lives. :-)
They don't know how to cut, copy and paste and most likely they are unable to copy a file, no matter how many times you explain that to them, so if your app requires these skills, it is not for beginners! It is not that they arrived late when God was delivering brains, but they just don't want to learn.
They don't like computers and probably never will. They use them because they have to or because a good salesman told them they are easy to use!
They are scared of the computer. Not because they think the computer will eat them, but because it'll eat their files (and they know it'll be their fault). They are too afraid of making mistakes, so it is very important your application gives them the confidence that they won't make mistakes inadvertently. It is counterproductive to ask the user every now and then "Are you sure?" because on one side it feeds the feeling of uncertainty in the user (like everything he/she does can be a potential disaster) and on the other side it generates automated responses (always pressing "Yes" or "Ok" without reading the questions), but well, this is a subject we'll talk about later.
They will have trouble setting up your application (from the start they don't understand what a setup is and why they have to do it), and they will certainly choose the "typical" option when setting up your application because it's the one selected by default. They accept all the default options and quite likely they will never change them, so make sure to set them for the "typical" user.
These users are the majority, so this is an important reason to program for them!
These are the ones that choose "Complete" (or "Full") when setting up an
application. They are more knowledgeable than beginners, so you can have
a civilized conversation with them ;)
They know how to cut, copy and paste and they know how to copy files for example. Don't expect much more, except that usually they are a bit more eager to learn.
They are not the majority, but they are very important because you'll probably get the best feedback from this group. They had been beginners no long ago and they know how hard it is to learn, and because they actually learned something they can communicate better their needs and the needs of beginners. Another reason why this group is important is that they can recommend your application and pass it on to others (including beginners that otherwise perhaps wouldn't know your app exists), thus helping spread the use of your application.
As you can imagine, these are the ones that choose the "Advanced" option when installing an application, and you can bet many will at least change the destination folder.
They know how to perform all the basic operating tasks (like search files, create direct accesses, configure the printer, etc.) and quite likely they will be much demanding of your application.
They want to feel they are in power and that they are in control of the application, not otherwise, except when they are new to the application, not to say when they are new to the task the app performs. You can safely bet in these cases they expect more guidance than beginners. They want to learn, but the easiest possible way.
Even though they are the minority, this group is important because they are usually in close contact with beginner and intermediate computer users and they normally influence their choices.
Applications for different users groups
Have you defined which kind of users is your app destined to? Usually, apps are destined to either beginners, advanced users or the general public (read "all"). If your app is targeted at a specific group, be sure to state this fact not to disappoint anyone.
Notice I haven't mentioned apps targeted at beginners+intermediate or intermediate+advanced, or intermediate users alone. Why? Because beginners+intermediate are almost all users, so why exclude advanced users? Intermediate users alone would also be unnecessarily excluding advanced users. The combination intermediate+advanced is not considered because it is very rare an application that can be used by intermediate users and not for beginners, so most probably the case is the designers "forgot" the beginners (didn't put enough effort to make the app easy to use) or they overestimated the users' skills. On the other hand, if the app is actually "too advanced" for beginners, chances are it is also too advanced for most intermediate users, so it would be more accurate to state that it is targeted at advanced users.
Ok, now let's talk about the main characteristics applications should have for the different users groups we have defined.
The priority of this kind of applications is ease of use above anything
else, meaning this that for example you can (and perhaps should) forget
about the standard: rectangular windows, title and menu bars, standard
colors, etc. Think of a Notepad replacement for example (an application
that replaces the Notepad that comes with Windows). Beginners don't know
what a caption bar or menu bar is :-) so we can get rid of them, and
perhaps instead of an ugly window with a white text box, we could think
of the image of an actual notepad (like the pages of our web site) with
some big buttons in the left margin for the basic operations (the few
a beginner would use). Association with real objects familiar to the
user (like a real notebook) is a good way of making the user feel
comfortable with an application.
Applications for advanced users
Typically, these are system utilities, CAD tools, etc. and usually they
provide a lot of functionality, so much that can even scare an advanced
user! :) You have to take into account that even though you are dealing
with advanced computer users, they might be beginners with your app, so
it would be wise to provide some sort of guidance or something to make
it easy for them to sort out the complexity of your application.
When designing for the advanced users it is quite important to follow the standard because they know it very well and they are used to it, and therefore they would find it unacceptable to have to learn something new or to use a "limiting" app. Advanced users want to have the power, they want features and performance.
Applications for the general public
Most applications are meant for the general public, being office suites by far the most popular.
Making applications suitable for all kinds of users is difficult, it is hard work, but it enables your app to reach the whole market. Achieving a good combination of ease of use, power and flexibility is easier said than done, but it is not impossible.
Think of a word processor for example. Beginners can use it. All they have to know is basic keyboard operation ("printable" keys, delete and the arrow keys) and how to load, save and print. Intermediate users will find most things they use very handy in the tool bars, and advanced users can access all the power the word processor can give them by exploring the main menu and context menus, using shortcut keys, etc.
The user interface is to an application more or less what the cover is to a book. You might have heard many times the phrase "Don't judge a book by its cover". Why not? Because the exterior appearance doesn't mean anything about interior quality, but truth is most people actually do give exterior appearance a great importance, so the interface of your app should be nice.
What is "nice"? I always mention MS Word for Windows as an example (Linux fans please don't kill me!). Does it use color? No, it's all the boring standard. Does it use graphics? Except for the tool bars and some menu aids, there are no graphics, not even as decorations or form backgrounds. Does it have anything special? No. So, what does it make it nice? Perhaps the key words here are "order" and "tidiness". Take a look at all the dialogs. Do you see any element out of place? Do you see any element (label, text box, etc.) that would be better if moved a single pixel in any direction? Got what I mean?
As you can see, order and tidiness have inherent beauty, so order and tidiness should be your primary concern. Make your application beautiful by itself. It's the easiest, cheapest and best way to make an application nice. Once, and only once, you got this, a bit of "makeup" can enhance this beauty, as sure as it can spoil it if you don't have good taste, so you should be very careful with this. It's more the job of a graphics designer than the job of a programmer...
Visual elements of the user interface
The splash screen is used to improve the perceivable speed of your application. Actually, an application will take a little bit more time to load with a splash screen than without one, but a splash screen that appears fast gives the user the (false) sensation that the application started working fast.
The splash screen is also frequently used as a nag in many shareware programs.
TIP: Provide a visual indication that your app is loading, especially if your app would take long to load. Just a simple blinking label saying "Loading..." would do it, but of course you can use something more elaborated.
TIP: Integrate the "Tip of the day" in the splash screen, giving the users something to read while they wait for your application to load.
TIP: The splash screen exists for a purpose. Don't use it if you don't need it. It's "grease".
Every day more applications include the "Tip of the day", also known as the "Did you know?" window. It's an interesting way of teaching some features of your application. Beginners and many intermediate users will never disable this window, so you'd better have a lot of tips to show. Most intermediate and advanced users would rather explore all the tips in the first session and then disable this window since they'll find it annoying.
TIP: Allow the user to explore all the tips (with Next - Previous buttons).
TIP: Include the option to disable the tips of the day in the same dialog.
TIP: Include meaningful information in the tips, not too obvious stuff like "You can open a file going to the File menu and selecting Open". Try to answer real or hypothetical FAQs.
TIP: Put first the tips regarding the basic operation of your program. Fancy or extra things go last.
TIP: If you don't have enough tips to offer, don't show the tip-of-the- day window. It's pathetic.
Wizards are good for beginners and even for advanced users who might not be experts in the field of your application. Normally, wizards are used to substitute a complex dialog box and they are mainly used for setups, (first-time) configurations and certain kinds of processes that require some input from the user.
The main advantage of the wizard over the dialog box is that it forces the user to focus on one thing at a time. Another important advantage is that wizards can "branch" showing different sets of options according to the ones the user have chosen before. This way, users don't see what they don't need to see and therefore things look much simpler.
TIP: When there is space (usually), provide some hint or help. For example, instead of just saying "Enter your name:" you can write "Please enter your name below. For example 'Homer J. Simpson' (without the quotes)". It's different since it gives the users more precisions about what is expected from them.
TIP: Wizards make things easy, but going step by step every time eventually becomes too cumbersome for intermediate and advanced users once they learned the process. When you can, include an "Advanced..." button and/or some way to disable the wizard and presenting a normal dialog box instead.
TIP: Don't use gradient colors or any custom drawings in the caption bar of your forms. Why? Because the font and colors you choose may not match the ones the user configured, and your application would look "unprofessional". Also, beware many title-bar-painting routines that are available out there fail to do the job right. Some produce ugly results in low color depth video modes while others apparently don't take into account the size of the (minimize, maximize and close) buttons, leaving a portion of the title bar painted with the system colors. Not nice. The standard is simple, the standard is nice, and most importantly, the standard is standard!
I shouldn't write a single line about the menu bar, but after seeing
some applications, I feel compelled to say one word: FTFS (Follow
The F^@%*&# Standard! ;)
TIP: The first menu should be File, System, Message, Job, Task or whatever is the most important thing of your application. The last option of this menu should be Exit (and the "x" should be its local shortcut, i.e. the shortcut for the item once the menu was opened).
TIP: You should have a Help menu with at least two items: help index (or at least a readme file or something!) and an about box.
TIP: Include a shortcut for all the main-menu items and the ones that are likely to be the most frequently used. Please don't use standard Windows keys (like Ctrl+X, Ctrl+C, Ctrl+V, F1, Alt+F4, etc.) for other purposes than their original ones (like Cut, Copy, Paste, Help, Close, etc.). Don't use Ctrl+S if it's not for saving. Include local shortcuts for all menu items.
TIP: Don't place a hundred elements in a menu. There is a great
invention called submenu. ;) But please don't abuse of submenus. Try to
reach an equilibrium. Usually (especially for faster access) it is
better to split a menu in two than using submenus.
TIP: As a rule of thumb, the maximum number of menu items is one or two less than the number that fits in a 640x480 screen with the standard Windows configuration.
TIP: If your tool bar doesn't have many elements, consider the use of
large icons and the possibility of including labels in the buttons since
beginners don't understand icons (or anything at all! ;)) or find it
difficult to associate the image with the action. They don't want to see
fancy graphics; they want to see something they can understand.
TIP: Provide tool tips for all elements in the tool bar. For elements that have a shortcut key, include it in the tool tip. Advanced users find it faster to use the shortcut key if they remember it rather than clicking the button with the mouse.
TIP: Make your graphics simple and easy to understand.
TIP: As a rule of thumb, the maximum number of items in the tool bar is the number that fits in a 640x480 screen with the standard Windows configuration.
TIP: Don't use your own custom pointers except to mean something specific to your application. Otherwise, the ones you present might be different than the ones the user is used to see.
TIP: Don't change the pointer shape often, unless to mean a special operation (like drag, paint, etc.). An exception to this rule is to denote parts where the user can click which are not too obvious at a single glance (actually they should be made obvious by other means rather than changing the mouse pointer, but sometimes it's difficult).
TIP: A text caption is always better than a graphic since it's easier to read that to interpret the meaning of an image. Also, a text caption makes obvious which is the shortcut key of the button.
TIP: Text and graphics are a good match.
TIP: If you make a graphic-only button (not recommended), at least have
the decency of providing a tool tip. Thanks. ;)
It's quite easy to make this kind of dialogs since Windows provides an API for this (MessageBox), but although it allows for fast development, you should consider not using it and instead design your own custom dialogs in situations where a wrong answer can signify data or time loss.
For example, when the user closes a form, many applications ask
and normally the answer is Yes, so users get used to clicking Yes (or pressing Enter) every time they see these dialogs, without actually reading the messages. However, there are some applications that reverse the question, for example
Needless is to say it has disastrous consequences for those who got used to click the Yes button to save their changes. Always asking questions where the most likely answer is Yes represents no solution (actually, it contributes more to the problem).
Telling users to read the messages is pointless. They won't. Period. But at least they read the button captions, so the solution is labeling the buttons with something meaningful. For example:
Explorer and Browser interfaces
Some MDI and SDI applications are difficult to use for most beginners and many intermediate users. They seem to easily get lost in all the menus and windows. Believe it or not, many beginners find it hard to determine which one is the topmost window. They think an application got stuck when they hear the beeps whenever they click on any part of it... except the modal dialog that appeared, but they can't "see" it because incredibly they don't distinguish the tridimensionality of the screen objects.
This problem can be partially solved using an interface like the famous Windows Explorer or one like most web browsers. They have in common that they present the user only one window (and dialogs occasionally).
In the Explorer interface, the user can see two panels: a tree at the left and a list or grid at the right. This kind of interface is quite useful for database applications. The tree is generally used as a menu, for example:
If the user clicks for example on "Customers", he would see all the customers listed in the right panel. If he clicks on "East coast", the list would be limited to those customers in the East coast of the US.
In the Browser interface, everything looks like a web page. For example, the main menu is like the main page of sites like Yahoo!, Altavista, etc. This is the best interface for novices, but it is difficult to implement in a single application, so it is quite common to see HTML pages combined with small CGI scripts or programs (or other forms of server processing, like PHP, ASP, JSP, etc.). A lot of effort goes into the interface, to make the application easy to use, so normally these applications are not very powerful and they are difficult to maintain.
Color is a very important (I would say CRITICAL) element of the user interface. Windows, Linux and other operating systems allow color configuration not only for aesthetic reasons, but also because many people have some sort of visual impairment. Many people need high contrasts to be able to read normally (usually dark text over light backgrounds, although some prefer light text over a dark background). Also you have to take into account that about 7% of the population (10% of males) suffer from some form of color blindness (inability to distinguish certain colors), making certain color combinations unreadable (they depend on the specific type of color blindness).
Either for reasons of personal taste or because of sight problems, many people run into the bother of changing the color options to satisfy their needs, so you should consider that overriding the system colors in your application is almost a capital sin, but there is an exception to this rule: if you use a background image and display text over it, you have to override the default text color to make sure the color of the text highly contrasts with the image (but usually you should restrict your color choices to black or white to insure you won't be dealing with an unreadable color combination).
TIP:If you decide to override the system colors, provide a way for the user to configure colors, or at least use colors that reduce vision problems. For example, a light blue font over a white background might be good to highlight hyperlinks, but many people consider it unreadable for longer texts. A black font over the standard light gray doesn't contrast good enough for 10% of the population, so you should choose a lighter gray for the background, or if you decide to use color, use a very unsaturated light color (see "Adding color to your applications").
TIP: Another recommendation is that you don't rely on color alone to mean something. For example, if you use green to signify "go" and red to signify "stop", it would be wise to also use a label. If your program display color bars, to cite another example, it would be good to use different patterns or some luminosity differentiation (technically, if for example you use RGB(255,0,0) as red, you could use RGB(0,229,0) as green, not RGB(0,255,0), so someone who can't distinguish between these two colors can perceive the difference in luminosity).
Most developers work at resolutions of 800 x 600 or higher and are used to true-color, while perhaps most users work in 640 x 480 and many people still have 256-color VGA cards. You have to make sure your application can be seen correctly at all resolutions and color depths.
For resolution, you need to make sure your application fits in a 640 x 480 screen, but insuring that your application can be seen in 256 colors requires a bit of effort. You can for example try restricting yourself to MSIE's safety palette and for your graphics you can provide alternate representations for each color depth and load at runtime the version that matches the device capabilities.
If your application uses fonts that don't come with the OS, it is quite likely that users won't have them, so you should either limit to the basic fonts or ship the fonts with your application and install them with your setup program (don't expect the user to do it "by hand").
In Windows, the use of fonts carries another problem because it allows the user to change the normal font sizes, and this causes some trouble to applications that use pixels instead of twips for their measurements. You would have to make sure your application can be seen correctly at least with "large fonts" (125% of the normal size), since the use of other custom proportions is discouraged.
AskTog
Human Interface Evangelism & Practical Design
http://www.asktog.com/Design. First principles
http://www.asktog.com/basics/firstPrinciples.html
IBM Design Concepts
http://www-3.ibm.com/ibm/easy/eou_ext.nsf/Publish/561
