Basic Principles

Four basic principles were considered when the overall look and feel of the OpenStep user interface was established. You should consider the same principles when creating interfaces for your own applications:

• The interface should feel natural to the user.
• The user is in control of the workspace and its windows.
• The mouse (not the keyboard) is the primary instrument for user input.
• The interface is consistent across all applications.

Each of these principles is discussed in more detail below.

The Interface Is Natural

The great advantage of a graphical user interface is that it can feel natural to your users. In a carefully designed interface, the workspace becomes a visual metaphor for some aspect of the real world, and the objects displayed on the screen can be manipulated in ways that are analogous to the ways physical objects are manipulated. This is what makes a user interface intuitive--it behaves as your users, with experience of real objects in the real world, expect it to.

The similarity of graphical objects to real objects should be at a fundamental, rather than superficial level. Interface objects need not resemble physical objects in every detail, but they do need to behave in ways that your users' experience with real objects would lead them to expect.

For example, objects in the real world stay where your users put them; they do not disappear and reappear. Your users should find the same qualities in graphical objects. Similarly, although graphical dials or switches do not duplicate all the features of physical dials and switches, they should be recognized immediately by your users, and they should suggest the same actions that real dials and switches suggest.

The User Is in Control

The workspace and the tools for working in it (the keyboard and mouse) belong to the user, not to any one application. Users should be free to choose which application and window they will work in and to rearrange windows in the workspace to suit their own tastes and needs.

Users working with an application should be given the widest possible freedom of action. It is inappropriate for an application to arbitrarily restrict what its users can do. If an action makes sense, it should be allowed.

Avoiding Modes

Applications should avoid setting up arbitrary modes that restrict their users. Modes often make programming easier, but they also prevent your users from determining what happens next.

In OpenStep interfaces, modes are used in only three situations:

• In attention panels, which are covered in Chapter 5, "Panels."
• In the modal tool paradigm, which is covered in "Three Action Paradigms" in Chapter 2.
• In spring-loaded modes, which last only while the user holds a key or mouse button down. See "Window Order" in Chapter 4 for more information.

When you use a mode in one of these situations, the mode should be freely chosen by the user, it should be visually apparent that the situation is modal, and you should provide an easy way out of the mode.

When You Should Act for the User

Even though the user is generally in control, it is sometimes appropriate for the application to act on the user's behalf without waiting for instructions. Consider the panel that appears when users choose the Print command. For some items on this panel, like "page size," a state must always be selected. Selecting a default page size of "letter" is an action that your application can reasonably take for its users.

The purpose of acting for the user is to simplify a task and possibly make a user action unnecessary. Therefore, when the application acts it must respond as though the user had acted. If the page size control, for example, changes in appearance when a user changes its state, it must change in the same way when the application sets its state.

Actions made on the user's behalf should be simple and convenient. Otherwise, they can be annoying or confusing, and reduce the user's sense of control over the workspace. If there is any doubt whether an application should act on the user's behalf, then it probably should not. It is better for the application to do too little than too much.

The Mouse Is the Primary Input Device

Every aspect of an application, every possible operation by a user, is represented by a graphical object displayed on the screen. Graphical objects are operated mainly by the mouse, and the keyboard is principally used for entering text. The mouse is the more appropriate instrument for acting on graphical objects.

One of the goals of user interface design is to make mouse actions as natural for users as touch typing is for experienced typists. This is only possible if mouse actions follow established paradigms that users can rely on. To help achieve this, three paradigms have been developed for user actions on OpenStep interface objects. They are covered in "Three Action Paradigms" on the next page.

Although the mouse is the primary input device, the OpenStep interface also allows keyboard alternatives to mouse actions. They can be efficient shortcuts for experienced users. Keyboard alternatives are always optional; however, a keyboard operation without a corresponding mouse-oriented action on screen is not acceptable. ("Implementing Keyboard Alternatives" in Chapter 3 covers the details of implementing keyboard alternatives.)

The Interface Is Consistent

When every application has the same basic user interface, all applications benefit. Consistency makes each application easier to learn and increases the likelihood it will be used and accepted.

Just as drivers become accustomed to a set of conventions on public highways, users tend to learn and rely on a set of conventions for their interaction with a computer. Although different applications are designed to accomplish different tasks, they all require some common actions--selecting, editing, scrolling, setting options, making choices from a menu, managing windows, and so on. You application's behavior is predictable only when you follow the conventions for these actions.

Interface conventions permit computer users, like drivers, to develop a set of habits and to act instinctively in familiar situations. Instead of being faced with special rules for each application, which would be like each town defining its own rules of the road, users can carry their knowledge about interface objects from one application to another.

Three Action Paradigms

Graphical user interfaces work best when they have well-defined paradigms for user actions with the mouse. These paradigms must be general enough to support the widest possible variety of applications, and also precise enough that users are always aware of what actions are possible and appropriate.

The OpenStep user interface supports three paradigms of mouse action:

• Direct manipulation
• Targeted action
• Modal tool

Direct Manipulation

Most interface objects respond directly to manipulations with the mouse--a button is highlighted when pressed, a window comes forward when clicked, the knob of a slider moves when dragged. Direct manipulation is the most intuitive of the action paradigms and the one best suited for moving and resizing graphical objects. For this reason, windows can only be reordered, resized, and moved by direct manipulation.

By directly manipulating the icons that represent documents, applications, mail messages, or other objects stored in the computer's memory, users can manipulate the objects the icons represent. For example, dragging an icon to a new location will change the position of a file in the file system's hierarchy.

The other paradigms--targeted action and modal tool--include some direct manipulation. When users select objects as targets for actions, the objects highlight themselves in some way, providing feedback to the users. And when users select modal tools from palettes, the appropriate tool icons are highlighted, reminding your users which tool is in use.

Targeted Action

Your applications provide controls, such as buttons and scrollers, which let users choose what the application will do next. Clicking on a close button, for example, doesn't just highlight the button; it also removes the window from the screen. Controls are devices, like light switches and steering wheels, that let your users carry out actions.

All controls act on targets. For some controls, such as the Quit menu command, the entire application is the target. For others, such as the close button in a window title bar, the target is a window. And for still others, such as the Cut menu command, the target is a subset of one window's contents, such as a range of text the user has selected.

In some of these cases (the Quit command and the close button) the target of the action is implied, but in others (the Cut command) the user must explicitly select the target. User-selected targets are frequently text strings or editable graphics. They can also be other types of objects, such as windows (the target of the Close Window menu command) or file icons (the target of the Workspace Manager Destroy command).

When the target of an action must be selected by the user, the user first selects the target and then chooses the control that initiates the action. With the Cut command, for example, users select a range of text in a document and then choose the command from the Edit menu.

This kind of targeted action, with an explicit selection, is the normal paradigm for controlling or operating on objects. It has the advantage that users can choose a target and then initiate a sequence of different actions. Users who select text, for example, can change the font, the point size, and then copy the selection to the pasteboard, without changing the target. Another advantage is that a single control can act on a series of different user-selected targets, making it extremely efficient and powerful. The Cut command, for example, can delete text, graphics, icons, and other objects.

For those situations in which direct manipulation is the most natural way to perform an operation, it is preferable to targeted action. However, since direct manipulation is not sufficient for many operations, targeted action is actually the most frequently used paradigm. Direct manipulation is an easy, natural way to resize a window by dragging its borders. It is neither easy nor natural to set the size of text by dragging the letters to a new height.

Modal Tool

With the modal tool paradigm, users determine what their mouse actions will do by selecting a tool. Depending on the tool that is chosen, mouse actions (clicking and dragging) produce different visual results. For example, a graphics editor might provide one tool for drawing circles and ovals, another for rectangles, and a third for simple lines.

Each tool sets up a mode--a period of time when the user's actions are interpreted in a specific way. The mode limits the user's freedom of action to a subset of all possible actions, which is normally undesirable. But with the modal tool paradigm, the limits imposed by the mode are justified in several ways:

• The mode is not hidden. The altered shape of the pointer and highlighted state of the tool make it apparent which mouse behaviors are in effect.
• The mode is not unexpected. It is the result of a user choice, not the by-product of some other action.
• The way out of the mode (usually clicking on another tool) is apparent and easy. It is also available to the user at any time.
• The mode mimics the way things are done in the real world. Artists and workers choose the appropriate tool (whether it is a brush, hammer, pen, or telephone) for the task at hand, finish the task, and choose a different tool for the next task.

These modal tools are often displayed in palettes with related tools, each tool enabling a specific set of mouse behaviors. The pointer assumes a different shape for each tool, so that it is always apparent which one has been selected, and the tool remains highlighted in the palette.

The modal tool paradigm is appropriate when a particular type of operation is likely to be continued for some length of time (for example, drawing lines). It is not appropriate if the user is put in the position of constantly choosing a new tool before each action.

Figure 2-1 shows a typical palette of modal tools; the freehand line tool is highlighted to indicate that it has been selected, and the pencil-image pointer shows that a mode is in effect.

Paradigm Extensions

Users come to expect familiar operations throughout the user interface. It is your responsibility to make sure the action paradigms your application uses are apparent to its users--controls should look like controls (like objects that fit into the targeted action paradigm), palettes of tools should look like palettes of tools, and so on.

You should also make sure that the paradigms used in your applications fit the actions users will actually be taking. It would not be appropriate if your users were required to select a modal "moving tool" just to move objects. Graphical objects should move, as real objects do, through direct manipulation.

Applied properly, the three paradigms described in this chapter can accommodate a wide variety of applications and user actions. Yet, over time, as programmers develop innovative software, new and unanticipated operations might require extending these paradigms.

A paradigm extension should be your last resort. All possible solutions within the standard user interface design covered in this chapter should be exhausted first. You must weigh the functionality added by extending the paradigms against the ill effects of eroding interapplication consistency for your users. Make sure that any extensions you develop are obviously different to your users from the existing paradigms.

If a paradigm extension is required, it should be designed so that it grows naturally out of the standard user interface, and adheres to the general principles discussed above.

Testing User Interfaces

The success of an application's interface depends on real users. There is no substitute for having users try out the interface, even before there is any functionality behind it, to see whether it makes sense to them and lets them accomplish what they want.