Alan Cooper, Robert Reinmann, David Cronin - About Face 3- The Essentials of Interaction Design (pdf)
Page 26
A transient application should launch to its previous position and DESIGN
principle
configuration.
No doubt you have already realized that almost all dialog boxes are really transient applications. You can see that all the preceding guidelines for transient applications apply equally well to the design of dialog boxes (for more on dialog boxes, see Chapters 24 and 25).
Daemonic posture
Programs that do not normally interact with the user are daemonic posture applications. These applications serve quietly and invisibly in the background, performing possibly vital tasks without the need for human intervention. A printer driver or network connection are excellent examples.
As you might expect, any discussion of the user interface of daemonic applications is necessarily short. Where a transient application controls the execution of a function, daemonic applications usually manage processes. Your heartbeat isn’t a function that must be consciously controlled; rather, it is a process that proceeds autonomously in the background. Like the processes that regulate your heartbeat, daemonic applications generally remain completely invisible, competently performing their process as long as your computer is turned on. Unlike your heart, however, daemonic applications must occasionally be installed and removed and, also occasionally, they must be adjusted to deal with changing circumstances. It is at these times that a daemon talks to a user (or vice versa). Without exception, the interaction between a user and a daemonic application is transient in nature, and all the imperatives of transient application design hold true here also.
14_084113 ch09.qxp 4/3/07 6:04 PM Page 173
Chapter 9: Platform and Posture
173
The principles of transient design that are concerned with keeping users informed of the purpose of an application and of the scope and meaning of the available choices become even more critical with daemonic applications. In many cases, users will not even be aware of the existence of the daemonic application. If you recognize that, it becomes obvious that reports about status from that application can be quite dislocating if not presented in an appropriate context. Because many of these applications perform esoteric functions — such as printer drivers or communications concentrators — the messages from them must take particular care not to confuse users or lead to misunderstandings.
A question that is often taken for granted with applications of other postures becomes very significant with daemonic applications: If the application is normally invisible, how should the user interface be summoned on those rare occasions when it is needed? One of the most frequently used methods in Windows is to represent the daemon with an onscreen application icon in the system tray. Putting the icon so boldly in a user’s face when it is almost never needed is a real affront, like pasting an advertisement on the windshield of somebody’s car. Daemonic icons should only be employed persistently if they provide continuous, useful status information. Microsoft solved this problem in Windows XP by hiding daemonic icons that are not actively being used to report status or access functionality (see Figure 9-5).
Figure 9-5 The status area of the taskbar in Windows XP. The mouse cursor is pointed at an icon representing a daemonic process that monitors the network.
The icon provides modeless visual status information, as the icon changes if there is no network access. Hovering over the icon provides more information, and right-clicking on it provides access to various functions related to the network connection.
Both Mac OS and Windows employ control panels as an effective approach to configure daemonic applications. These launchable transient applications give users a consistent place to go to configure daemons. It is also important to provide direct, in-line access to daemonic applications any time there is an issue with them that prevents a person from accomplishing what he aims to. (Of course, standard dis-claimers apply: Don’t interrupt users unnecessarily.) For example, if a taskbar icon indicates a problem with a printer, clicking on that icon should provide a mechanism to troubleshoot and rectify the problem.
14_084113 ch09.qxp 4/3/07 6:04 PM Page 174
174
Part II: Designing Behavior and Form
Designing for the Web
The advent of the World Wide Web was both a boon and a curse for interaction designers. For perhaps the first time since the invention of graphical user interfaces, corporate decision makers began to understand and adopt the language of user-centered design. On the other hand, the limitations and challenges of Web interactivity, which are a natural result of its historical evolution, set interaction design back several years. Designers of Web applications are only now beginning to take advantage of the many desktop interaction idioms (such as drag-and-drop) that were old news years before the first Web sites went online.
In the early days of the Web boom, the industry was flooded with fresh design school graduates, traditional graphic designers, and young enthusiasts who saw the Web as an exciting and lucrative opportunity to create compelling communication through new forms of interactive visual expression. The biggest challenges involved working around the tight constraints of the medium (originally created to share scientific papers and attached diagrams) to produce a user experience with even a rudimentary level of interactivity and visual organization.
Even then, the people designing and building Web sites recognized that a new design issue resulted from the support of hyperlinks in documents: the design, organization, and structuring of content. Findability, a term coined by Peter Morville, is an apt way to describe the design issue in a nutshell. A new breed of designers, the information architects, built a discipline and practice to address the nonvisual design problems of logical structure and flow of content.
Some of today’s browser-based applications (often collectively referred to as Web 2.0, a term credited to Tom O’Reilly) blur many of the distinctions between desktop and Web applications, and even offer the opportunity to define new interaction idioms that better support the people we are designing for. With the rise of so-called “rich Internet applications” supported by technologies such as AJAX, Macromedia Flash, Java, and ActiveX, the design of Internet-enabled software demands much greater attention to sophisticated product behavior than is required of simpler page-based Web sites. While findability remains a significant issue, it can be eclipsed by the classic interaction problems of PC-based applications.
This newly available ability to deliver complex behavior in a browser demands application-quality interaction design. The visual designer’s focus on look-and-feel and the information architect’s focus on content structure are not sufficient to create effective and engaging user experiences with this new generation of the Web.
Before we get into different postures that emerge on the Web, we’ll first discuss the different kinds of services and products that are typically offered through a Web
14_084113 ch09.qxp 4/3/07 6:04 PM Page 175
Chapter 9: Platform and Posture
175
browser: informational Web sites, transactional Web sites, and Web applications. As with many of the categorizations we offer in this book, the lines between these can be fuzzy. Consider them to represent a spectrum upon which any Web site or application can be located.
Informational Web sites
Web browsers were originally conceived of as a means of viewing shared and linked documents without the need for cumbersome protocols like File Transfer Protocol (FTP), Gopher, and Archie. As a result, the Web was originally made up solely of collections of these documents (or pages) referred to as Web sites. We continue to use the term to refer to informational services on the Web whose level of interaction primarily involves searching and clicking on links. Web sites, as described, can easily be conceived of as sets of pages or documents organized sequentially or hierarchically, with a navigation model to take users from one page to another, as well as a search facility to a provide more goal-directed location of specific pages. Plenty of Web sites still exist out
there, in the form of personal sites, corporate marketing and support sites, and information-centric intranets. In such informational Web sites, the dominant design concerns are the visual look-and-feel, the layout, navigational elements, and the site structure (information architecture). Web sites do not typically exhibit complex behavior (where the result of a user interaction is dependent on application state), and therefore don’t often require the services of interaction designers.
As this book is focused on interaction design, we won’t attempt to address the many aspects of designing Web sites that have been covered in great detail in many other volumes. Steve Krug’s Don’t Make Me Think! , Louis Rosenfeld and Peter Morville’s Information Architecture, and Jeffrey Veen’s The Art and Science of Web Design, in particular, cover the essential elements of Web design in a clear and straightforward manner. Jakob Nielsen’s useit.com Web site is also an excellent resource.
Postures for informational Web sites
Sites that are purely informational, which require no complex transactions to take place beyond navigating from page to page and limited searching, must balance two forces: the need to display a reasonable density of useful information and the need to allow first-time and infrequent users to learn and navigate the site easily. This implies a tension between sovereign and transient attributes in informational sites.
Which stance is more dominant depends largely on whom the target personas are and what their behavior patterns are when using the site: Are they infrequent or one-time users, or are they repeat users who will return weekly or daily to view content?
14_084113 ch09.qxp 4/3/07 6:04 PM Page 176
176
Part II: Designing Behavior and Form
The frequency with which content is updated on a site does, in some respects, influence this behavior: Informational sites with real-time information will naturally attract repeat users more than a site updated once a month. Infrequently updated sites may be used more for occasional reference (assuming that the information is not too topical) rather than for heavy repeat use and should thus be given more of a transient stance than a sovereign one. What’s more, the site can configure itself into a more sovereign posture by paying attention to how often a particular user visits.
Sovereign attributes
Detailed information display is best accomplished by assuming a sovereign stance.
By assuming full-screen use, designers can take advantage of all the space available to clearly present the information as well as navigational tools and wayfinding cues to keep users oriented.
The only fly in the ointment of sovereign stance for the Web is choosing which full-screen resolution is appropriate. (To a lesser degree, this is an issue for desktop applications, though it is easier for creators of desktop software to dictate the appropriate display.) Web designers need to make a decision early regarding what resolution to optimize the screen designs for. While it is possible to use a “liquid layout” to flexibly display content in a variety of browser window sizes, your designs should be optimized for common display sizes and should accommodate the lowest common denominator appropriate for the primary persona. Quantitative research is helpful in determining this: Among people similar to your personas, how many really have 800x600 screens these days?
Transient attributes
The less frequently your primary personas access the site, the more transient a stance the site needs to take. In an informational site, this manifests itself in terms of ease and clarity of navigation and orientation.
Sites used for infrequent reference might be bookmarked by users: You should make it possible for them to bookmark any page of information so that they can reliably return to it at any later time.
Users will likely visit sites that are updated weekly to monthly only intermittently, so navigation must be particularly clear. If the site can retain information about past user actions via cookies or server-side methods and present information that is organized based on what interested them previously, this could dramatically help less frequent users find what they need with minimal navigation (assuming that a user is likely to return to similar content on each visit to the site).
14_084113 ch09.qxp 4/3/07 6:04 PM Page 177
Chapter 9: Platform and Posture
177
Transactional Web sites
Some Web sites go beyond simple clicking and searching to offer transactional functionality that allows users to accomplish something beyond acquiring information. Classic examples of transactional Web sites are online stores and financial services sites. These are typically structured in a hierarchical page-based manner, similar to an informational Web site, but in addition to informational content, the pages also contain functional elements with complex behaviors. In the case of the online store, these functional elements include the shopping cart, check-out features and the ability to save a user profile. Some shopping sites also have more sophisticated and interactive tools as well, such as “configurators,” which allow users to customize or choose options related to their purchases.
Designing transactional Web sites requires attention to both information architecture to organize the pages and to interaction design to devise appropriate behaviors for the more functional elements. Of course, visual design must serve both of these ends, as well as the effective communication of key brand attributes, which is often particularly important considering the commercial nature of most transactional sites.
Postures for transactional Web sites
Online shopping, banking, investment, portal, and other transactional sites must, like informational sites, strike a balance between sovereign and transient stances. In fact, many transactional sites have a significant informational aspect — for example, online shoppers like to research and compare products or investments. During these activities, users are likely to devote significant attention to a single site, but in some cases (such as comparison shopping), they are also likely to bounce around among several sites. For these types of sites, navigational clarity is very important, as are access to supporting information and efficient transactions.
Search engines and portals like Google and Yahoo! are a special kind of transactional site designed to provide navigation to other Web sites, as well as access to aggregated news and information from a variety of sources. Clearly, performing a search and navigating to resulting sites is a transient activity, but the information aggregation aspects of a portal like Yahoo! sometimes require a more sovereign stance.
The transient aspects of users’ experiences with transactional sites make it especially important that they not be forced to navigate more than necessary. While it may be tempting to break up information and functions into several pages to reduce load time and visual complexity (both good objectives), also consider the potential for confusion and click fatigue on the part of your audience. In a landmark usability study conducted in 2001 by User Interface Engineering about user perception of page load time for e-commerce sites like Amazon.com and REI.com,
14_084113 ch09.qxp 4/3/07 6:04 PM Page 178
178
Part II: Designing Behavior and Form
it turned out that user perception of load time is more closely correlated to whether a user is able to achieve her goal than to actual load time.1
Web applications
Web applications are heavily interactive and exhibit complex behaviors in much the same way that a robust desktop application does. While some Web applications maintain a page-based navigation model, these pages are more analogous to views than they are to Web documents. While many of these applications are still bound by the archaic server query/response model (which requires users to manually
“submit” each state change), technology now supports robust asynchronous communication with the server and local data caching, which allows an application delivered through a browser to behave in much the same way as a networked desktop application.
Examples of Web applications include:
Enterprise s
oftware, ranging from old school SAP interfaces duplicated in a browser to contemporary collaborative tools such as Salesforce.com and 37Signals’ Basecamp
Personal publishing tools, including blogging software such as SixApart’s MoveableType, photo-sharing software such as Flickr, and of course the ubiquitous Wiki
Productivity tools such as Writely, a browser-based word processor, and Google Spreadsheets
These Web applications can be presented to users very much like desktop applications that happen to run inside a browser window, with little penalty as long as the interactions are carefully designed to reflect technology constraints. While it certainly can be challenging to design and deliver rich and responsive interactions that work in a number of different browsers, the Web platform is very conducive to delivering tools that enable and facilitate collaboration. The Web browser is also a good method for delivering infrequently used functionality for which a user may not want to install a dedicated executable. And of course, a Web application enables users to access their information and functionality from anywhere they have Internet access. This is not always appropriate or necessary, but given the mobility of today’s workforce and the popularization of telecommuting, it can certainly be of significant value to allow people to access the same tools and functionality from several different computers.
14_084113 ch09.qxp 4/3/07 6:04 PM Page 179
Chapter 9: Platform and Posture
179
There are a number of popular misconceptions about Web applications worth mentioning. For one, they are not easier or faster to build. In our experience, building an application to be delivered through a browser takes just as much (if not more) planning, engineering, and programming as building it to be delivered through standard desktop technologies. Second, Web applications are not inherently more usable or comprehendible. It is a common assumption that because many users are familiar with some Web interactions based upon their experience with online stores and informational Web sites that they will be able to leverage this familiarity to more easily understand applications delivered through a browser.