|
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
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.
Users levels
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.
1) Beginners
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!
Intermediate
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.
Advanced
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.
Applications for beginners
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.
Exterior beauty
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
Splash screen
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".
Tip of the day
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
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.
Title bar
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!
Menu bar
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.
Tool bars
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.
Mouse pointers
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).
Buttons
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. ;)
Yes/No questions
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
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).
Resolution and color depth
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.
Fonts
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.
Further reading
This article was first published in our Developers Newsletter, now discontinued.
|
