At Apple Computer, products are designed with a number of basic principles of
human-computer interaction in mind. This chapter discusses the human interface
design principles that describe key considerations for the design decisions
you make for your product.
Having technical knowledge of the Macintosh user interface is a key factor in
product design, but understanding the theories behind the user interface can
help you create an excellent product. This chapter provides a theoretical base
for the wealth of practical information on implementing the Macintosh
interface elements presented in Part Two.
This section presents a set of principles useful for designing products for
Macintosh computers. The reason for defining a set of design principles is to
help you build a product that meets the standards of the Macintosh computer.
Also, these principles can help clarify what you can do in order to design a
product based on what is known about people and how they operate in the world.
You'll undoubtedly find out that you can't design in accordance with all of
the principles all of the time. In that type of situation, you'll have to make
a decision based on which principle or set of principles is most important in
the context of the task you're solving.
You can take advantage of people's knowledge of the world around them by using
metaphors to convey concepts and features of your application. Use metaphors
involving concrete, familiar ideas and make the metaphors plain, so that users
have a set of expectations to apply to computer environments. For example,
people often use file folders to store paper documents in their offices.
Therefore, it makes sense to people to store computer documents in computer-
generated folders that look like file folders. People can organize their hard
disks in a way that's analogous to the way they organize their file cabinets.
The desktop is the primary metaphor for the Macintosh interface. It appears to
be a surface on which people can keep tools and documents. Several other
metaphors are integrated into the desktop metaphor. It makes sense in the
context of a desktop environment to include folders and a trash can (even
though most trash cans don't sit on the desktop). Menus are an extension of
the desktop metaphor. People can connect the idea of making choices from a
computer menu with making choices from a restaurant menu. Although people
don't keep restaurant menus on the edge of their desks, using the term menu in
the computer environment reinforces the idea that people can use computer
menus to make choices.
Metaphors in the computer interface suggest a use for something, but that use
doesn't define or limit the implementation of the metaphor. For example, a
paper file folder has a limited storage capacity, but a folder on the
Macintosh doesn't have to be constrained by the same limitations. Computer
folders can hold a limitless number of files (up to the storage capacity of
the hardware), and this is an advantage that the computer can offer. Try to
strike a balance between the metaphor's suggested use and the ability of the
computer to support and extend the metaphor.
Direct manipulation allows people to feel that they are directly controlling
the objects represented by the computer. According to the principle of direct
manipulation, an object on the screen remains visible while a user performs
physical actions on the object. When the user performs operations on the
object, the impact of those operations on the object is immediately visible.
For example, a user can move a file by dragging an icon that represents it
from one location to another or can position a cursor in a text field by
directly clicking the location where the cursor should be placed.
In addition to expecting physical results from their actions, users want their
tools to provide feedback. For example, when a drawing tool is moved, a line
appears in the document on which the user is working. Users want to see what
actions are available at any given moment. If grave consequences might follow
from any of those actions, they want to know about those consequences&emdash;before
any damage is done and while they can still change their minds. They want
clues that tell them that a particular command is being carried out, or, if it
cannot be carried out, they want to know why not and what they can do instead.
Users also want topics of interest to be highlighted.
Animation, when used sparingly, is one of the best ways to show a user that a
requested action is being carried out. For example, animated pointers reassure
the user, during a lengthy process such as saving a large document to disk,
that the computer is completing the task without any problems.
On the desktop, users perform actions by choosing from alternatives presented
on the screen. Users interact directly with the screen, selecting objects and
performing activities by using a pointing device, typically a mouse, to point
at elements on the desktop.
The Macintosh desktop works according to two fundamental paradigms. Both
paradigms share two basic assumptions: that users can see on the screen what
they're doing and that users can point at what they see. The paradigms are
based on a general form of user action: noun-then-verb.
In one paradigm, the user selects an object of interest (the noun) and then
chooses the actions to be performed on the object (the verb). All actions
available for the selected object are listed in the menus, so users who are
unsure of what to do next can refresh their memory by scanning through the
menus. At any time, users can choose any available action without having to
remember any particular command or name. For example, a user clicks a document
icon (the noun) and then prints (the verb) the document by choosing Print from
the File menu.
In the second paradigm, the user drags an object (the noun) onto some other
object that has an action (the verb) associated with it. On the desktop, for
example, the user can drag icons to the Trash, to folders, or to disks. The
user doesn't choose an action from the menus, but it's clear what happens to
one object when it's placed on another object. For example, dragging a
document icon to the Trash means that the user wants to discard that document.
For this metaphor to work, the user must recognize what an object such as the
Trash is for, so it is especially important that objects look like what they
do in the real world. If the document icon didn't look like a piece of paper
with text and the Trash didn't look like the place to discard something, the
interface would be more difficult to use.
Consistency in the interface allows people to transfer their knowledge and
skills from one application to any other. Use the standard elements of the
Macintosh interface to ensure consistency within your application and to
benefit from consistency across applications.
Effective applications are consistent in a number of different ways.
Consistency in the visual interface helps people learn and then easily
recognize the graphic language of the interface&emdash;for example, once users know
what a checkbox looks like, they don't have to learn another symbol for making
choices. Consistency in the behavior of the interface means that people have
to learn how to do things such as clicking and pointing only once; then they
can explore new applications or new types of features using skills that they
already have. In general, consistency benefits the typical user, who usually
divides working time among several applications, and it benefits software
developers because their users can build on prior experiences with elements in
other applications when learning how to use a new application.
The following are some questions you can ask yourself when thinking about
consistency in your product.
Is your product consistent
¥ within itself?
¥ with earlier versions of your product?
¥ with Macintosh interface standards?
¥ in its use of metaphors?
¥ with people's expectations?
Note that the most difficult kind of consistency to achieve is matching
people's expectations. Because you often face a wide audience and a range of
expertise, it's difficult to meet the expectations of everyone. You can
address this problem by carefully weighing the consistency issues in the
context of your target audience and their needs.
Don't hide features in your application by using abstract commands. People
should be able to see what they need when they need it. For example, menus
present lists of commands so that people can see their choices instead of
having to remember and type command names.
People should be able to find all the available features in your application.
If you find a need to initially "hide" features, do it in a way that gives
people information about where they can find more choices. A stepped
interface, by revealing relevant information to users in steps, shows the
choice most users want most of the time while providing a way for the user to
get more choices. For information on stepped interfaces, see the guidelines in
the section "Using Progressive Disclosure" on page 35 in Chapter 3, "Human
Interface Design and the Development Process.
Make sure that there is no significant difference between what the user sees
on the screen and what the user receives after printing. Let the user be in
charge of both the content and the format (spatial layout as well as font
choices) of the document. When the user makes changes to the document, quickly
and directly display the results; the user shouldn't have to wait for a
printout or make mental calculations of how the document shown on the screen
will look when it appears on the printed page.
Allow the user, not the computer, to initiate and control actions. People
learn best when they're actively engaged. Too often, however, the computer
acts and the user merely reacts within a limited set of options. In other
instances, the computer "takes care" of the user, offering only those
alternatives that are judged "good" for the user or that "protect" the user
from having to make detailed decisions. This approach mistakenly puts the
computer, not the user, in control.
The key is to create a balance between providing users with the capabilities
they need to get their work done and preventing them from destroying data. For
situations in which a user may destroy data accidentally, you can help the
user by providing warnings, usually in the form of an alert box, to notify
users of a potentially undesirable situation and still allow them to proceed,
if they confirm that this is what they want. This approach "protects" users
but allows them to remain in control.
Keep users informed about what's happening with your product. Provide feedback
as they do tasks and make that feedback as immediate as possible. When a user
initiates an action, provide some indicator, visual or auditory (or both),
that your application has received the user's input and is operating on it.
Provide as much information as possible about how long operations take. When
your application can't respond to user input because it's processing a
different task, inform the user of what to expect and describe any delays, why
they occur, and how long they'll take. Also, tell the user how to get out of
the current situation whenever possible.
Provide direct, simple feedback that people can understand. Most people would
not know what to do if they saw this message "The computer unexpectedly
crashed. ID = 13." It would be very helpful if the message spelled out exactly
which situation caused the error&emdash;for example, not enough memory was available
for the computer to complete the task&emdash;so that the user could understand how to
avoid the situation in the future.
You can encourage people to explore your application by building in
forgiveness. Forgiveness means that actions on the computer are generally
reversible. People need to feel that they can try things without damaging the
system; create safety nets for people so that they feel comfortable learning
and using your product.
Always warn people before they initiate a task that will cause irretrievable
data loss. Alert boxes are a good way to warn users of this kind of situation.
Note, however, that when options are presented clearly and feedback is
appropriate and timely, learning how to use a program should be relatively
error-free. This means that frequent alert boxes are a good indication that
something is wrong with the program design.
Computers often introduce a new level of complexity for people. If people are
to cope with this complexity, they need some stable reference points. The
Macintosh interface is designed to provide a computer environment that is
understandable, familiar, and predictable.
To give users a visual sense of stability, the Macintosh interface provides
the desktop, a two-dimensional space on which objects are placed. It also
defines a number of consistent graphics elements (menu bar, window border, and
so on) to maintain the illusion of stability. Note that it is the perception
of stability that you want to preserve, not stability in any strict physical
sense.
To give users a conceptual sense of stability, the interface provides a clear,
finite set of objects and a clear, finite set of actions to perform on those
objects. Even when particular actions are unavailable, they are not eliminated
from a display but are merely dimmed.
Aesthetic integrity means that information is well organized and consistent
with principles of visual design. This means that things look good on the
screen and the display technology is of high quality. Since people spend a lot
of their time working while looking at the computer screen, design your
products to be pleasant to look at on the screen for a long time. You may want
to consider investing some of your resources in a graphic designer; the skills
a graphic designer can bring to your product design are well worth the
expense.
Keep the graphics of the display simple. The number of elements and their
behaviors should be limited to enhance the usability of the interface.
Graphics&emdash;icons, windows, dialog boxes, and so on&emdash;are the basis of effective
human-computer interaction and must be designed with that in mind. Don't
clutter the screen with too many windows, overload the user with complex
icons, or put dozens of buttons in dialog boxes.
Make sure to follow the graphic language of the interface and don't change the
meaning of standard items. For example, if you sometimes use checkboxes for
multiple choices and other times for exclusive choices, you dilute the meaning
of the element.
Don't use arbitrary graphic images to represent concepts. When you add
nonstandard symbols to menus, dialog boxes, or other elements, the meaning may
be clear to you, but to other people the symbols may appear as something
different and distracting. If you need symbols other than standard ones, use
graphic images that convey meaning through representation, analogy, or
metaphor. For more information on designing additional appropriate symbols,
see the section "Extending the Interface" in Chapter 3, "Human Interface
Design and the Development Process," beginning on page 38.
In general, match the graphic element with users' expectations of its
behavior. Push buttons appear as though they push in rather than slide
sideways. Indicators in sliders slide along to change values. These behaviors
map to people's expectations of how these elements behave.
Give users some control over the look of their computer environments. This
allows them to display their own style and individuality. It also reduces the
burden on the designer of trying to create an interface that appeals to every
user. When a user sets up his or her computer environment in a certain layout,
it should stay that way until the user changes it.
For the most part, try to create modeless features that allow people to do
whatever they want when they want to in your application. Avoid using modes in
your application because a mode typically restricts the operations that the
user can perform while it is in effect. It locks the user into one operation
and doesn't allow the user to work on anything else until that operation is
completed. In contrast, modelessness allows the user to perform more than one
operation at a time and thus gives the user more control over what he or she
can do on the computer and in an application. As much as possible, you want to
preserve the user's ability to be in control of the task and the order of
operations.
This is not to say that you should never use modes in applications. Sometimes
using a mode is the best way out of a particular problem. Most acceptable
modes fall into one of the following categories:
¥ Long-term modes, such as doing word processing as opposed to graphics
editing. In this sense, each application is a mode.
¥ Short-term "spring-loaded" modes, in which the user must constantly do
something to maintain the mode. Examples are holding down the mouse button
to scroll text or holding down the Shift key to extend a text selection.
¥ Alert modes, in which the user must rectify an unusual situation before
proceeding. Keep these modes to a minimum.
Other modes are acceptable if they do one of the following:
¥ They emulate a familiar real-life situation that is itself modal. For
example, choosing different tools in a graphics application resembles the
real-life choice of physical drawing tools.
¥ They change only the attributes of something, not its behavior. The
boldface and underline modes of text entry are examples.
¥ They block most other normal operation of the system to emphasize the
modality, as in error conditions incurable through the software (for
example, a dialog box that disables all menu items except Close).
If an application uses modes, there must be a clear visual indicator of the
current mode, and the indicator should be near the object most affected by the
mode. A good example is the changing pointer in many Macintosh graphics
applications; depending on the function ("mode") the user has selected, the
pointer looks like a pencil, a paintbrush, a spray can, or an eraser. It
should also be very easy for users to get into or out of the mode (such as by
clicking a different palette symbol).
This section discusses several other issues that are helpful to think about
when you design your product.
Identifying and understanding your target audience are among the most
important first steps when you start designing your product. To create a
product that people can and will use, study the people who make up your target
audience.
It's useful to create scenarios that describe a typical day in the life of a
person you think uses the type of product you're designing. Think about the
different work spaces, tools, and constraints and limitations that people deal
with. You can also visit actual work places and study how people do their
jobs.
Analyze the steps necessary to complete each task you anticipate people
wanting to accomplish. Then design your product to facilitate those tasks,
using a step-by-step approach by thinking of how a person might get from one
place to the next in a logical fashion.
Involve users throughout the design process and observe them working in their
environment. Use people who fit your audience description to test your
prototypes and development products. Listen to their feedback and try to
address their needs in your product. Develop your product with people and
their capabilities, not computers and their capabilities, in mind. For more
information, see the section "Involving Users in the Design Process" in
Chapter 3, "Human Interface Design and the Development Process," beginning on
page 41.
The computer should be accessible to everyone who chooses to use it. There are
likely to be members of your target audience who are different from the
"average" user that you envision. Users will undoubtedly vary in their ages,
styles, and abilities. They may also have physical or cognitive limitations,
linguistic differences, or other differences you need to consider. Identify
how the individuals in your target audience differ and what special needs they
may have.
Make it easy for users to interact with your product using different input
devices and output devices. If you develop specialized hardware and software
for people with physical limitations, work with application developers so that
your products are supported by their software.
Make your application accessible to people around the world by including
support for worldwide capabilities in your designs from the beginning of your
development process. Take stock of the cultural and linguistic needs and
expectations of your target audiences. For more information, see the section
"Worldwide Compatibility" beginning on page 16 in Chapter 2, "General Design
Considerations.
More information about universal access appears throughout the book where
appropriate. For specific information, see the section "Universal Access
beginning on page 24 in Chapter 2, "General Design Considerations.
©Apple Computer, Inc. 1985-1991