14_084113 ch09.qxp 4/3/07 6:04 PM Page 164
164
Part II: Designing Behavior and Form
describes a different type of user interaction. More importantly, these categories give the designer a point of departure for designing an interface. A sovereign posture program, for example, won’t feel right unless it behaves in a “sovereign” way.
Sovereign posture
Programs that monopolize users’ attention for long periods of time are sovereign posture applications. Sovereign applications offer a large set of related functions and features, and users tend to keep them up and running continuously, occupying the full screen. Good examples of this type of application are word processors, spreadsheets, and e-mail applications. Many vertical applications are also sovereign applications because they are often deployed on the screen for long periods of time, and interaction with them can be very complex and involved. Users working with sovereign programs often find themselves in a state of flow. Sovereign programs are usually used maximized (we’ll talk more about window states in Chapter 20). For example, it is hard to imagine using Microsoft Outlook in a 3-x-4-inch window —
at that size it’s not really appropriate for its main job: creating and viewing e-mail and appointments (see Figure 9-1).
Figure 9-1 Microsoft Outlook is a classic example of a sovereign posture application. It stays onscreen interacting with a user for long, uninterrupted periods, and with its multiple adjacent panes for navigation and supporting information, it begs to take up the full screen.
14_084113 ch09.qxp 4/3/07 6:04 PM Page 165
Chapter 9: Platform and Posture
165
Sovereign products are characteristically used for long, continuous stretches of time. A sovereign product dominates a user’s workflow as his primary tool. PowerPoint, for example, is open full-screen while you create a presentation from start to finish. Even if other applications are used for support tasks, PowerPoint maintains its sovereign stance.
Users of sovereign applications are typically intermediates
Because people typically devote time and attention to using sovereign applications, they often have a vested interest in getting up the learning curve to become intermediate users, as discussed in Chapter 3. Each user spends time as a novice, but only a short period of time relative to the amount of time he will eventually spend using the product. Certainly a new user has to get over the initial learning curve, but seen from the perspective of the entire relationship between a user and the product, the time he spends getting acquainted with the program is small.
From the designer’s point of view, this often means that the program should be optimized for use by perpetual intermediates and not be aimed primarily at beginners (or experts). Sacrificing speed and power in favor of a clumsier but easier-to-learn idiom is out of place here, as is providing only sophisticated power tools. Of course, if you can offer easier or more powerful idioms without compromising the interaction for intermediate users, that is often best. In any case, the sort of user you’re optimizing for is determined by your choice of primary persona and your understanding of their attitudes, aptitudes, and use contexts.
Between first-time users and intermediate users there are many people who use sovereign applications only on occasion. These infrequent users cannot be ignored.
However, the success of a sovereign application is still dependent on its intermediate, frequent users until someone else satisfies both them and inexperienced users.
WordStar, an early word processing program, is a good example. It dominated the word processing marketplace in the late ‘70s and early ‘80s because it served its intermediate users exceedingly well, even though it was extremely difficult for infrequent and first-time users. WordStar Corporation thrived until its competition offered the same power for intermediate users, while simultaneously making it much less painful for infrequent users. WordStar, unable to keep up with the competition, rapidly dwindled to insignificance.
Be generous with screen real estate
Because a user’s interaction with a sovereign application dominates his session at the computer, the application shouldn’t be afraid to take as much screen real estate as possible. No other application will be competing with yours, so don’t waste space, but don’t be shy about taking what you need to do the job. If you need four toolbars to cover the bases, use four toolbars. In an application of a different
14_084113 ch09.qxp 4/3/07 6:04 PM Page 166
166
Part II: Designing Behavior and Form
posture, four toolbars may be overly complex, but the sovereign posture has a defensible claim on the pixels.
In most instances, sovereign applications run maximized. In the absence of explicit instructions from the user, your sovereign application should default to maximized or full-screen presentation. The application needs to be fully resizable and must work well in other screen configurations, but the interface should be optimized for full-screen use, instead of the less common cases.
DESIGN
Optimize sovereign applications for full-screen use.
principle
Use a minimal visual style
Because users will stare at a sovereign application for long periods, you should take care to mute the colors and texture of the visual presentation. Keep the color palette narrow and conservative. Big colorful controls may look really cool to newcomers, but they seem garish after a couple of weeks of daily use. Tiny dots or accents of color will have more effect in the long run than big splashes, and they enable you to pack controls together more tightly than you otherwise could.
DESIGN
Sovereign interfaces should feature a conservative visual style.
principle
The user will stare at the same palettes, menus, and toolbars for many hours, gain-ing an innate sense of where things are from sheer familiarity. This gives you, the designer, freedom to do more with fewer pixels. Toolbars and their controls can be smaller than normal. Auxiliary controls such as screen-splitters, rulers, and scrollbars can be smaller and more closely spaced.
Rich visual feedback
Sovereign applications are great platforms for creating an environment rich in visual feedback for users. You can productively add extra little bits of information into the interface. The status bar at the bottom of the screen, the ends of the space normally occupied by scrollbars, the title bar, and other dusty corners of the product’s visible components can be filled with visual indications of the application’s status, the status of the data, the state of the system, and hints for more productive user actions. However, be careful: While enriching the visual feedback, you must be careful not to create an interface that is hopelessly cluttered.
14_084113 ch09.qxp 4/3/07 6:04 PM Page 167
Chapter 9: Platform and Posture
167
The first-time user won’t even notice such artifacts, let alone understand them, because of the subtle way they are shown on the screen. After a period of steady use, however, he will begin to see them, wonder about their meaning, and experimentally explore them. At this point, a user will be willing to expend a little effort to learn more. If you provide an easy means for him to find out what the artifacts are, he will become not only a better user but also a more satisfied user, as his power over the application grows with his understanding. Adding such richness to the interface is like adding a variety of ingredients to a soup stock — it enhances the entire meal. We discuss this idea of rich visual modeless feedback in Chapter 25.
Rich input
Sovereign applications similarly benefit from rich input. Every frequently used aspect of the application should be controllable in several ways. Direct manipulation, dialog boxes, keyboard mnemonics, and keyboard accelerators are all appropriate. You can make more aggressive demands on a user’s fine motor skills with direct-manipulation idioms. Sensitive areas on the screen can be just a couple of pixels across because you can assume that the user is e
stablished comfortably in his chair, arm positioned in a stable way on his desk, rolling his mouse firmly across a resilient mouse pad.
DESIGN
Sovereign applications should exploit rich input.
principle
Go ahead and use the corners and edges of the application’s window for controls.
In a jet cockpit, the most frequently used controls are situated directly in front of the pilot; those needed only occasionally or in an emergency are found on the arm-rests, overhead, and on the side panels. In Word, Microsoft has put the most frequently used functions on the two main toolbars (see Figure 9-2). They put the frequently used but visually dislocating functions on small controls to the left of the horizontal scrollbar near the bottom of the screen. These controls change the appearance of the entire visual display — Normal view, Page Layout view, and Outline view. Neophytes do not often use them and, if accidentally triggered, they can be confusing. By placing them near the bottom of the screen, they become almost invisible to new users. Their segregated positioning subtly and silently indicates that caution should be taken in their use. More experienced users, with more confidence in their understanding and control of the application, will begin to notice these controls and wonder about their purpose. They can experimentally select them when they feel fully prepared for their consequences. This is a very accurate and useful mapping of control placement to usage.
14_084113 ch09.qxp 4/3/07 6:04 PM Page 168
168
Part II: Designing Behavior and Form
Figure 9-2 Microsoft Word has placed controls at both the top and the bottom of the application. The controls at the bottom are used to change views and are appropriately segregated because they can cause significant visual dislocation.
Document-centric applications
The dictum that sovereign applications should fill the screen is also true of document windows within the application itself. Child windows containing documents should always be maximized inside the application unless the user explicitly instructs otherwise, or the user needs to simultaneously work in several documents to accomplish a specific task.
DESIGN
Maximize document views within sovereign applications.
principle
Many sovereign applications are also document-centric (i.e., their primary functions involve the creation and viewing of documents containing rich data), making it easy to believe that the two are always correlated, but this is not the case. If an application manipulates a document but only performs a simple, single function, such as scanning an image, it isn’t a sovereign application and shouldn’t exhibit sovereign behavior. Such single-function applications have a posture of their own, the transient posture.
14_084113 ch09.qxp 4/3/07 6:04 PM Page 169
Chapter 9: Platform and Posture
169
Transient posture
A product with a transient posture comes and goes, presenting a single function with a constrained set of accompanying controls. The application is invoked when needed, appears, performs its job, and then quickly leaves, letting the user continue her normal activity, usually with a sovereign application.
The defining characteristic of a transient application is its temporary nature.
Because it doesn’t stay on the screen for extended periods of time, users don’t get the chance to become very familiar with it. Consequently, the product’s user interface should be obvious, presenting its controls clearly and boldly with no possibility of confusion or mistakes. The interface must spell out what it does: This is not the place for artistic-but-ambiguous images or icons — it is the place for big buttons with precise legends spelled out in a large, easy-to-read typeface.
DESIGN
Transient applications must be simple, clear, and to the point.
principle
Although a transient application can certainly operate alone on your desktop, it usually acts in a supporting role to a sovereign application. For example, calling up Windows Explorer to locate and open a file while editing another with Word is a typical transient scenario. So is setting your speaker volume. Because the transient application borrows space at the expense of the sovereign, it must respect the sovereign by not taking more space onscreen than is absolutely necessary. Where the sovereign can dig a hole and pour a concrete foundation for itself, the transient application is just on a weekend campout. It cannot deploy itself onscreen either graphically or temporally. It is the taxicab of the software world.
In cases when the entire computer system is fulfilling a transient role in the real world of atoms, it is not necessarily appropriate to minimize the use of pixels and visual attention. Examples of this include process monitors in a fabrication environment, or digital imaging systems in an operating theatre. Here, the entire computer screen is referred to in a transient manner, while the user is engaged in a sovereign mechanical activity. In these cases, it is critical for information to be obvious and easily understood from across the room, which clearly requires a bolder use of color and a more generous allotment of real estate (see Figure 9-3).
14_084113 ch09.qxp 4/3/07 6:04 PM Page 170
170
Part II: Designing Behavior and Form
Figure 9-3 Yahoo! Widgets and iTunes are good examples of transient applications. They are referred to or interacted with briefly before a user’s attention turns to an activity in a sovereign application. The use of rich dimensional rendering gives them an appropriate amount of visual gravity.
Bright and clear
Whereas a transient application must conserve the total amount of screen real estate it consumes, the controls on its surface can be proportionally larger than those on a sovereign application. Where more forceful visual design on a sovereign application would pall within a few weeks, the transient application isn’t onscreen long enough for it to bother the user. On the contrary, bolder graphics help the user to orient himself more quickly when the application pops up.
Transient applications should have instructions built into their surface. The user may only see the application once a month and will likely forget the meanings and implications of the choices presented. Instead of a button captioned Setup, it’s better to make the button large enough to caption it “Set up user preferences.” The verb/object construction results in a more easily comprehensible interface, and the results of clicking the button are more predictable. Likewise, nothing should be abbreviated on a transient application, and feedback should be direct and explicit to avoid confusion. For example, a user should be easily able to understand that the printer is busy, or that a piece of recently recorded audio is five seconds long.
Keep it simple
After the user summons a transient application, all the information and facilities he needs should be right there on the surface of the application’s single window. Keep the user’s focus of attention on that window and never force him into supporting subwindows or dialog boxes to take care of the main function of the application. If you find yourself adding a dialog box or second view to a transient application, that’s a key sign that your design needs a review.
Transient applications should be limited to a single window and
DESIGN
principle
view.
14_084113 ch09.qxp 4/3/07 6:04 PM Page 171
Chapter 9: Platform and Posture
171
Transient applications are not the place for tiny scrollbars and fussy mouse interactions. Keep demands on the user’s fine motor skills down to a minimum. Simple pushbuttons for simple functions are good. Direct manipulation can also be effective, but anything directly manipulable must be discoverable and big enough to interact with easily. You should also provide keyboard shortcuts, but they must be simple, and all important functions should also be visible on the interface.
Of course, there are some rare exceptions to the monothematic nature of transient applications. If a transient application performs more than just a single funct
ion, the interface should communicate this visually and unambiguously and provide immediate access to all functions without the addition of windows or dialogs. One such application is the Art Directors Toolkit by Code Line Communications, which performs a number of different calculator-like functions useful to users of graphic design applications (see Figure 9-4).
Keep in mind that a transient application will likely be called upon to assist in the management of some aspect of a sovereign application (as in the Art Directors Toolkit in Figure 9-4). This means that the transient application, as it is positioned on top of the sovereign, may obscure the very information that it is chartered to work on. This implies that the transient application must be movable, which means it must have a title bar or other obvious affordance for dragging.
Figure 9-4 Art Directors Toolkit by Code Line Communications is another example of a transient application. It provides a number of discrete functions such as calculating dimensions of a layout grid. These functions are designed to support the use of a sovereign layout application such as Adobe InDesign. While this application provides a number of different functions, they are organized into tabs and are all directly accessible at all times.
14_084113 ch09.qxp 4/3/07 6:04 PM Page 172
172
Part II: Designing Behavior and Form
It is vital to keep the amount of management overhead as low as possible with transient applications. All the user wants to do is perform a specific function and then move on. It is completely unreasonable to force the user to add nonproductive window-management tasks to this interaction.
Remember user choices
The most appropriate way to help users with both transient and sovereign apps is to give the applications a memory. If a transient application remembers where it was the last time it was used, the chances are excellent that the same size and placement will be appropriate next time, too. It will almost always be more apt than any default setting might chance to be. Whatever shape and position a user morphed the application into is the shape and position the application should reappear in when it is next summoned. Of course, this holds true for its logical settings, too.
Alan Cooper, Robert Reinmann, David Cronin - About Face 3- The Essentials of Interaction Design (pdf) Page 25
