 |
 |
forUse Newsletter Archives | |||||
 |
 |
||||||
 |
|||||||
|
|
|
forUse Newsletter Archives | |||||
|
|
|
||||||
|
|
|||||||
 |
forUse: The Electronic Newsletter of Usage-Centered Design #29 | February 2003 |
|
 |
||
| Subscribe! |
   |
|
|
Contents: || 1. Technique: Defaults and Usability. || 2. Design: Patterns for Usability || 3. Process: Multi-Stream Design Teams || 4. Learning: Conference Presentations
= = = = = 1. Technique: Defaults and Usability Defaults matter. We have been saying a lot about attention to detail in design, and default settings are among the details that matter. The default values for fields or parameters and the default assumptions for settings of all kinds are a humble, often overlooked, but important part of usability. The point was reinforced in a review of a new shopping search service site called FetchBook.info that purports to search over 60 online book sources for the best price on any book. The business model has some potential if visitors can quickly and easily compare prices and then buy by clicking through to the seller. Ka-ching, another commission for FetchBook. The site also has an elegantly spare Google-like home page. Unfortunately, it just doesn’t work very well for a number of reasons, with poor choice of defaults as a major contributor. The primary search prompts the user to “Please enter book title, ISBN or author” but the appended drop-down offers 4 choices: Keyword, Title, Author, ISBN. The default is “Keyword.” Keeping in mind that the stated purpose of the service is to find the best price on a given book, this is the least likely choice of a user coming into the site with a book in mind. If the user fails to change the default, oodles of irrelevant hits are delivered. In practice, many users do not even notice the default setting. They merely type in the title, which is the most likely action for the typical user seeking a particular book. Title in, garbage out. In this scenario, typing “Software for Use” (to pick an example at random) returns 30 hits in 3 pages, but none of these is the book Software for Use. Oops. Try the same thing with the “Title” option selected, and you get another 30 hits, for which the first screen-full is “Software Test Automation,” “Advanced Use Case Modeling,” “Multitool Linux,” “Object-Oriented Software Engineering,” “Design & Use of Software Architectures,” and “Fundamentals of Physics.” Below the fold is the 7th hit, “Software for Use.” What is going wrong? The problem here is in default assumptions built into the search algorithm. The search engine is treating all the words equally and independent of word order, so “Multitool Linux” shows up because the subtitle is “Practical Uses for Open Source Software.” Thinking in terms of usage patterns and user intent makes it clear that if a user is typing what they think is a title, the default assumption is that word order matters. Moreover, the results should be sorted on the basis of closeness of fit, which would bring the correct selection to the top in most cases. The result page bears an uncanny resemblance to Google results, except that the user is not told how many hits there are, only that “More than 10 titles matched your search.” Again, the design does not take into account the needs and interests of users, who find the total number of hits of value in refining their search strategy and are guided in deciding how deep to drill before giving up. Given the performance thus far, we must take the meaning of the word “match” loosely. The Google-like presentation invites trying Google-like refinements, but those that the user might reasonably expect to work do not. Adding quotes around “Software for Use” yields exactly the same results as on the previous try. Oops again. Wrong default assumption about punctuation and user sophistication. Similar problems plague searches on author. Searching on “Larry Constantine” returns 15 results, including several books that I neither wrote nor edited. Two of these were books for which I did write the foreword, but the collection of murder mysteries by Otto Penzler, John Lescroart, K. C. Constantine, Laura Lippman, and Lawrence Block reveals more defects in the search assumptions. The bottom-of-page navigation also reveals a lack of thought about assumptions. In multi-page results, the most likely navigation is to the next page (or back to the prior page), and Google supplies large visual targets for these. FetchBook supplies none, forcing the user to click on the next tiny little number to get each succeeding batch of 10 “matches.” The comparison with Google is revealing, because attention to details and default assumptions is what makes Google work so well. I am struck by how often the first search returns the sought after information within the first page of results. Only in a small minority of cases do I need to construct an “advanced search” to get what I need. The irony is that FetchBook has such a much more restricted domain of interest and still doesn’t get the defaults right. In all fairness, Google is not perfect either, of course, although it does get a lot of things right. One small detail Google misses is supplying results navigation only at the bottom of the results page. It is reasonable to assume that the typical user will scan to the bottom before going on to peruse the next page, but I am struck by how often, in scanning for general trends, I find myself wishing for a redundant set of page navigation links at the top. (In case you missed it, redundant navigation is one of the best practices identified in “Devilish Details: Best Practices in Design for the Web” at http://foruse.com/articles/details.pdf). 2. Design: Patterns for Usability Patterns have become popular tools for understanding design and creating better designs. A pattern, as the name suggests, is a recurrent design problem that has been well analyzed and understood and for which a uniform solution or preferred approach has been worked out. Although content and style vary, most patterns have in common a statement of the problem or problems, an enumeration and analysis of the tradeoffs or issues in resolving the problem, and a demonstrably superior solution or solutions for which the consequences are clear. (For examples of some of the styles and templates used to write interaction design patterns, see http://www.cs.ukc.ac.uk/people/staff/saf/patterns/gallery.html.) Patterns capture and communicate experience, making the collective wisdom of an entire profession available for use. They can serve as permanent repositories of good practice, as guides for practitioners, and as media for education of new professionals. To some extent, patterns function like rules or guidelines but with some important distinctions. Patterns always apply to a limited domain--to certain problems but not all problems--and the clarification of this restricted domain is an integral part of the pattern itself. Because patterns--at least when well formulated-- combine a clear statement of the problem with a full discussion of the issues and solutions that are connected back to the problem and design issues, properly structured patterns are relatively easy to evaluate and refine. In fact, an important feature of the patterns community is the notion that patterns are subject to public review and criticism in the interest of building a robust body of commonly accepted and proven practice. The place of patterns in user interface and interaction design is not nearly as well established as in software engineering, where the patterns movement has matured into a major force, but interest has been growing steadily. Several substantial collections having been compiled, and hundreds of UI and HCI patterns can be found on the Web. Unfortunately, Sturgeon’s Law still reigns supreme, and 90% of the stuff is crud. We confess to deep reservations regarding patterns and the pattern movement. While formal structure can be helpful for comparison, compilation, and categorization, the patterns community sometimes manifests a rigid preoccupation with form and style, even at the expense of substance. Too many interface and interaction design patterns are exercises in the inflation of trivia and the elaboration of the obvious. Vacuous ideas or simple tricks of limited use are puffed up into full-blown patterns with all the pedantic trappings of the formal structure. Of patterns such as “Shopping Cart,” what can one say? (Problem: Users want to buy a product. Solution: Introduce a shopping cart where users can put their products in before they actually purchase them.) Duh! For students, catalogs of the well-known can be useful, and some of these compilations are not bad as summaries of basic techniques. (See, for example, Common Ground at http://www.mit.edu/~jtidwell/interaction_patterns.html.) Unfortunately, for practicing designers facing real-world problems, rendering the obvious obtuse through pedantic discourse is of limited value. In other cases, unproven or even unwise tricks or extremely specialized techniques of very limited general value have been elevated to the level of a pattern. Patterns are a bit like angels dancing on a pin. One can multiply them without apparent limit, but one ought not to do so with patterns if they are to retain their significance. To avoid unnecessary proliferation, patterns should reflect abstractions from and generalizations of a substantial body of experience in solving the more interesting if not the truly vexatious problems in design. The utility of patterns in practice largely depends on the extent to which they save think-work by providing well-conceived, thoroughly studied, non-obvious solutions to frequently encountered problems. A good pattern is more than just a design idea, a trick, or a specific solution to a specific problem; it is an encapsulation of hard-won wisdom. The best patterns emerge from making the same mistake or working through the same analysis repeatedly, recognizing the process as repetitive, reducing the problem to its essence, enumerating all the tradeoffs and design issues, then deriving a definitive solution or set of solutions for which the arguments are clear, defensible, or even provable. One reason so many user interface and interaction design patterns are so bad is that they are either obvious or are based on too little experience. It is not simply a matter of accumulating work experience in designing varied user interfaces. What is required is thoughtful practice by reflective designers who continuously re-examine their work and the processes through which it evolves. To discover and elucidate patterns requires a mindfulness that seems to elude many designers. You must not only learn how to do good design but learn how it is you do what you do. You must study your own solutions to understand their structure and to thoroughly explore and explicate all the alternatives. In large part, the profession as a whole has not tackled enough problems with enough insight to really recognize many genuinely useful and important design patterns. Truly useful patterns of provable and broad utility may remain rare, but there is no shortage of published patterns in user interface and interaction design. The struggling designer hoping to work from patterns must become familiar with a large number of them even after the truly trivial and wondrously worthless ones have been eliminated. A compact and powerful theory, a few good general principles, or an effective process would seem to be a far more efficient way to capture and communicate design wisdom. Indeed, in the grander scheme of things, patterns often stand in for good theory. They are an interim substitute for a fuller theoretical understanding of a phenomenon. Part of the appeal of patterns is no doubt that almost any idiot can write one--and all too many do--while only a relatively few idiots can invent a full-blow process and even fewer can construct a comprehensive theory. I am also skeptical about the real consequences of patterns applied in practice. Although revered in the software world, Christopher Alexander, the father of modern patterns, is not highly regarded in his own profession of architecture, in part because his own work and that of his followers is not particularly impressive. Putting skepticism and sarcasm aside, I do think there is a place for patterns in user interface and interaction design. Awhile back, a group of assembled colleagues worked out the concept of canonical-form abstract prototypes in part as a way to support the identification of high-level patterns within visual and interaction design. Abstract prototypes--particularly when formulated using canonical or standardized abstract components--expose and highlight repeated problems and common issues across multiple design efforts. Although we were initially quite excited about the potential, other demands intervened and nothing much was done in pursuit of abstract design patterns. Ever since the creation of canonical abstract prototypes, I have wanted to return to this idea of using them to capture and convey high-level design patterns. Recently, in reviewing a Web site for a colleague, I realized I was flagging problems and suggesting solutions that I had seen before in a variety of quite different contexts. The pattern, tentatively titled Detail View Direct Navigation, combines both interaction and presentation design issues of modest subtlety and lends itself to structural description in canonical form. The problem addressed by Detail View Direct Navigation is how to support versatile and efficient user navigation through information presented as both a list view and a series of detail or expanded views. The pattern is of broad application and the solution is non-obvious, at least judging by usage on the Web. To skip to the answer, (which is what so many designers want anyway) the pattern proposes solutions that allow the user to move directly from one detail view to another without having to return to the list view. The more interesting part is in the explication of the pattern and exploration of issues and alternatives, for which canonical abstract prototypes have been used. A draft of the complete pattern is available at http://foruse.com/patterns/detailnavigation.pdf. (Note: This document cannot currently be reached through the Web site, so use the preceding link.) Please do give us feedback on this pattern, and let us know what you think of the possible role of patterns in usage-centered design. Eventually, we would like to build a collection of high-level design patterns expressed as abstract prototypes using canonical abstract components. If you would like to try your hand at casting some of your own hard-won wisdom in this form, just use our pattern as a template and send your draft to me by email for consideration. If you want to learn more about work on usability, user interface, and interaction design patterns, here are some starting points: http://www.thinkware.se/cgi-bin/thinki.cgi/UserInterfacePatterns; http://www.mit.edu/~jtidwell/interaction_patterns.html; http://www.welie.com/patterns/; http://www.pliant.org/personal/Tom_Erickson/InteractionPatterns.html; http://c2.com/ppr/ui.html. Judge for yourselves, and let us know your reactions as well as you thoughts about and experiences with design patterns. 3. Process: Multi-Stream Design Teams Can the user interface design process be split up into multiple parallel streams? What do you do when you have a bodaciously complicated project and really tight deadline? Although logically a process of progressive modeling, in practice usage-centered design is a concurrent engineering process. User roles, tasks, and interface contents are modeled concurrently, with the models themselves serving as holding bins to organize and manage the process. The focus of attention begins with user roles, but attention always wanders and moves from model to model. In addition, the software engineering for system use cases supporting system actors (non-human actors) can proceed in parallel with user, task and content modeling and with the presentation and interaction design that derives from these models. With careful planning and close coordination, a substantial head start on implementation is possible without waiting for completion of the user interface design. Even more concurrency is possible in XP-style projects where modeling and design of the user interface and functionality for the next iteration overlaps programming for the current iteration. In our own work, even on the largest projects, we have always consolidated the modeling and design process in the hands of a single team. At time the modeling and design team may split into sub-teams, such as to complete the narratives defining essential use cases, but the design as a whole remains the charge of a single team as a whole. One of our clients is trying another strategy. They are working against the clock in the redesign of an extremely complex product that enfolds a number of distinct but interconnected and tightly integrated applications. They opted to organize the modeling and redesign into multiple streams, each one focused on a particular subsystem or application. Working in parallel, each of these teams undertook a complete usage-centered process modeling roles, tasks, and contents before focusing on design. These teams were supported by on-going access to “user surrogates”--domain experts with some first-hand experience as users or familiarity with actual use in practice. Such user surrogates can also function informally as liaisons or linking-pin members that help coordinate and maintain consistency across multiple streams. The project, still underway, is being closely watched and reviewed as it proceeds. Already some clear lessons have emerged. A number of problems have arisen around user role modeling. Perhaps most vexing was the fact that as each team went through the process of brainstorming and refining user roles for its own portion of the redesign, they tended to duplicate the work of other teams, even to some of the same arguments. We are now convinced that a better approach would be to complete a single comprehensive user role model before splitting up into multiple streams. A good user role model can even help guide the best way to split into multiple design streams or at least to highlight areas of interdependence or potential overlap across streams. If a role turns out to be of interest to more than one subgroup, at least they can be working from the same copy. In fact, bringing all the separate teams together to complete a common user role model promotes ownership of the model and helps ensure that all potentially relevant perspectives have been taken into account. The bottom line, then is this: If you are going to split the modeling and design process into parallel streams, we would strongly recommend that you make the split downstream of the user role modeling. 4. Learning: Conference Presentations We will be “hitting the road” this spring, presenting tutorials and participating in workshops at a number of conferences. Use links below to find out more information, recommend the tutorials to your friends, and definitely drop by and say hello if you are attending any of these events. 6 March 2003 | UPA Boston Mini-Conference | Boston Constantine “GUI to Web apps: What should we keep, what should we leave behind?” Panel with Sarah Bloomer, Jared Spool, Dan Workman (mailto:ddemarco@mathworks.com) 7 April 2003 | CHI 2003 | Ft. Lauderdale, FL Constantine, Lockwood “Card-Based User and Task Modeling for Agile Usage-Centered Design” Full-day Tutorial (http://www.chi2003.org/tutorial-details.html#22) 3-4 May 2003 | ICSE 2003 | Portland, OR Constantine “Usage-Centered Design and Software Engineering: Models for Integration” Workshop Paper (http://www.se-hci.org/bridging.html) 5 May 2003 | ICSE 2003 | Portland, OR Constantine, Lockwood “Usage-Centered Software Engineering: An Agile Approach to Integrating Users, User Interfaces, and Usability into Software Engineering Practice” Full-day Tutorial (http://cs.oregonstate.edu/icse2003/) 4-6 June 2003 | 10th DSV-IS Workshop | Madeira, Portugal Constantine Invited Presentation (http://math.uma.pt/dsvis2003/) 22-27 June 2003 | HCI International 2003 | Crete, Greece Windl, Constantine “Usage-Centered Design: Scalability and Integration with Software Engineering” Workshop Paper(http://hcii2003.ics.forth.gr/) 19-22 October 2003 | forUSE 2003 | Portsmouth, NH
=
= = = To unsubscribe, just click here to send email. |
||
| Subscribe! |
|
|
|
|
||