 |
 |
forUse Newsletter Archives | |||||
 |
 |
||||||
 |
|||||||
|
|
|
forUse Newsletter Archives | |||||
|
|
|
||||||
|
|
|||||||
 |
forUse: The Electronic Newsletter of Usage-Centered Design #28 | January 2003 |
|
 |
||
| Subscribe! |
   |
|
|
Contents: || 1. Learning: Upcoming Presentations || 3. Modeling: Task Granularity
= = = = = 1. Learning: Upcoming Presentations and Training 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. 7 April 2003 | CHI 2003 | Ft. Lauderdale, FL Constantine, Lockwood 5 May 2003 | ICSE 2003 | Portland, OR Constantine, Lockwood 4-6 June 2003 | 10th DSV-IS Workshop | Madeira, Portugal Constantine 22-27 June 2003 | HCI International 2003 | Crete, Greece Windl, Constantine 19-22 October 2003 | forUSE 2003 | Portsmouth, NH Constantine, Lockwood NOTE: Deadline 28 February 2003! Proposals are due 28 February for the forUSE 2003 Second International Conference on Usage-Centered Design. See www.foruse.com/2003/ for more information. 2. Design: Short Answers for Instructive Interaction. Designers are always looking for answers to their problems--particularly quick, easy answers. In our own teaching and consulting, we usually downplay the answers to put the emphasis on the problem-solving process. If you learn a solution, you have one answer to one problem, which may or not fit the next situation. If you learn the skills of model-driven design, you have the conceptual tools for attacking any problem and finding a good solution whenever needed. Unfortunately, people tend to remember solutions and to forget how these were derived. For this reason, we have always been a bit reluctant to publish design solutions. When we do share solutions, as in the series of design studies we published (www.foruse.com/articles/designstudy1.pdf, designstudy2.pdf, and designstudy3.pdf), we go into some detail regarding the thought processes that led to those particular designs. Instructive interaction is an exciting new approach for user interfaces using a body of techniques for making innovative designs self-teaching. Through instructive interaction, users learn how to use a novel interface correctly without an extended trial-and-error process. The techniques are grounded in solid theory and exploit a new learning paradigm called anticipatory learning (or the “I-knew-that effect”). Our article on the theory and practice of instructive interaction just appeared in the Winter 2002 issue of User Experience (published by the Usability Professionals Association, www.upassoc.org); an extended draft version with additional examples can be found at www.foruse.com/articles/instructive.pdf. The article catalogs a variety of specific techniques for making user interfaces self-teaching, and therein lies a problem. Instructive interaction is beginning to generate a certain amount of buzz, and we have already received feedback from designers who claim to be using instructive interaction, having incorporated this bit or that bit from the catalog of techniques. Imitation is not only flattering, it’s a great design technique--perhaps the easiest technique of all. Like all good designers, we are always willing to borrow good ideas, and instructive interaction draws on a diverse body of both established and novel design concepts from many sources. Some of these ideas do have sufficiently broad utility to stand more or less on their own. Such is the case with progressive screen tips (example at www.foruse.com/about/portfolio/), first described in our book (www.foruse.com/resources/) and slowly becoming more common in software. However, instructive interaction is more than just a collection of isolated visual and interaction design tricks. What makes a novel user interface self-teaching hinges not only on the techniques of presentation but on certain global properties of the user interface taken as a whole. For instance, as long as the user experiences the interface as inviting and supporting free exploration, the rapid learning process can continue. Any part of the user interface that inhibits exploration or that penalizes the user for making a wrong guess spoils the whole experience, bringing the learning-through-discovery to a grinding halt. So, while it may look like a lot of short answers or isolated design ideas, instructive interaction requires a comprehensive design process with careful attention to detail throughout the user interface. You don’t get instructive interaction just by changing user interface widgets here and there or by plugging in various design ideas where convenient. Which brings us full circle to an old theme: good user interface design is a matter of detail yet is more than just details. Attention to detail must permeate the design process and the design. You only have to get a few small things wrong to ruin an otherwise good concept, as many companies doing e-business on the Web have discovered. You’ll find precisely this subject addressed in my just-released paper from the forUSE 2002 conference, “Devilish Details: Best Practices in Usage-Centered Web Design.” You can find a copy at www.foruse.com/articles/details.pdf (1.2M .PDF file). Better yet, purchase a copy of the Proceedings and get all 36 papers from the conference; details and ordering information are at www.foruse.com/resources/. 3. Modeling: Fine Points of Task Granularity At the OOPSLA 2002 conference, which I mentioned in the December newsletter, I sat in on Jim Heumann’s tutorial about user experience modeling in the Rational Unified Process. Although not always acknowledging the debt, the RUP approach draws heavily on usage-centered design going all the way back to our work with Ivar Jabobson and colleagues in the Objectory days. There are important differences, of course. RUP is handicapped by its complexity, its proliferation of artifacts, and its linkage to UML, which lacks constructs for modeling user interfaces. Nevertheless, it is possible to conduct credible usage-centered design within the RUP framework. (See, for example, the Armstrong and Underbakke paper in the forUSE 2002 Proceedings; details at www.foruse.com/resources/.) One important difference is in the granularity of task modeling. Usage-centered design typically produces fairly fine-grained task models with the total work broken down into numerous small, interconnected task cases. The Rational folk, along with others coming from a conventional use case tradition, caution against having too many use cases and favor fewer but larger cases, each of which is more like an extended scenario. They often argue that this coarse-grained model is simpler and easier to understand; we argue the opposite, that factoring the work into a fine-grained collection of small tasks actually simplifies the model. In the final analysis, of course, the intrinsic complexity of the work to be modeled cannot be wished away; it can only be moved around or disguised. To a given level of precision and completeness, modeling with fewer pieces means that each piece is bigger and more complicated in itself. Smaller, simpler pieces make each piece easier to understand in isolation but shift the complexity of the whole into the relationships among the scattered parts. If there seems to be an echo of long familiar issues in factoring code, it is no accident; the name of the game here--as in programming--is managing complexity, and it is all a matter of tradeoffs. The usage-centered approach has the edge when it comes to managing complexity, because it distills the work down to its most abstract essence. In principle, task cases reduced to essential form (abstract, simplified, generalized, and independent of technology and implementation) represent the smallest possible formulation of the complete structure of a given collection of tasks. In practice, breaking user tasks down into smaller units has a number of advantages. It improves the odds of discovering all the discrete elements of work, especially the many small, obscure, or exceptional bits that make life interesting for users and programmers alike. Whenever it is reasonable, we put these odd bits into separate task cases that extend the base cases, thus keeping the base cases simple and focused on the typical tasks. The resulting model is easier to audit for completeness, because all the needed task elements and their interrelationships are visible. By highlighting and making explicit the relationships among task cases, this approach also makes it easier to explore new ways to compose larger chunks of work out of the numerous discrete tasks. This ability to rearrange small task elements without invalidating or rewriting the basic model itself offers additional benefits. It favors reuse, since elements common to multiple task are recognized as distinct task cases rather than buried as internal steps within other task cases. This granularity exposes common task elements and promotes finding a single common design solution supporting each task, however many times or places it might be used in the model as a whole. Ultimately, reuse in the programming itself is supported and promoted. Reuse extends even to users. A design based on smaller, more manageable units of work, offers users opportunities for mixing and matching operations in novel ways, including for ends and means not anticipated by the designers. The goal is more flexible user interfaces through support of the individual component parts of work. As if this were not enough justification, fine-grained models that expose the inherent structure of work highlight opportunities for business process redesign and work simplification. Realistic scenarios and the more concrete, more complicated use cases favored by RUP and other methods, do not distill or extract the underlying structure and basic elements of user tasks, so they tend instead to focus attention on current practices and existing ways of carrying out work. Elaborated scenarios have their place, however, particularly when it comes to laying out the navigation architecture and making the translation from a task model to a user interface design. Realistic and representative scenarios also serve well for driving inspections and testing. A fine-grained task model is a good starting point for constructing scenarios that incorporate particular parts of the work and traverse well-defined portions of the user interface. To construct useful scenarios from the task model, you first break the total work down into the smallest units that make sense to users, that represent discrete and meaningful intentions of users in roles. You also need to understand the interrelationships among these task elements, either as specific relationships, such as extension or inclusion, or as the more generic likelihood of their being used together. Tasks should also be prioritized by ranking them in terms of expected frequency, significance to the user, and importance to the business success of the system. Good scenarios are built around basic tasks that are common, typical or representative. A relatively simple and straightforward scenario can then be elaborated by including closely related tasks that extend or are otherwise likely to be used along with the main tasks. Finally, other tasks of importance to users or the business can be folded into the mix. The result is not just an understandable and usable scenario but a scenario that truly reflects the structure of the tasks users need to accomplish. Similarly, if you want or need RUP-style use cases for whatever reasons, these are easily constructed from a fully-factored task model just by combining related task cases into larger and more complicated units. In short, we find that better, more versatile task models ultimately lead to better user interfaces designs, so we follow this pattern: (1) break the total work down into small, meaningful task cases (2) identify the connections or interrelationships among these tasks (3) prioritize tasks by frequency, user significance, and business importance (4) construct more extended scenarios or conventional use cases by combining related task cases Over several recent seminars, we have noted that teams who pushed the task modeling down to the most basic or atomic level and then backed up to more aggregated scenarios fared better, particularly when it came to the overall organization of the user interface. 4. Design: Naked Again In the December Newsletter (#27) I wrote about naked objects and expressive interfaces. The analysis of the naked objects concept (“The Emperor Has No Clothes” www.foruse.com/articles/nakedobjects.pdf) has quickly become a popular download. In purest form, the naked objects approach simply presents users with unadorned domain objects in a standard form. All interaction is reduced to drag-and-drop and selection from context menus revealed by right-clicking an object. To their credit, the naked object people seem to have taken up the challenge, at least to the extent of beginning to pay some nascent attention to usability in the presentation of objects on the user interface. Among other things, the proposed “new GUI” (http://www.nakedobjects.org/new-gui.html) will reduce window management by incorporating multiple views into a single window and will provide a more natural display of multi-line fields. Of course, at the same time they still reject almost every suggestion from their own user-developer community to relax the rigid rules limiting the interaction style. Not surprisingly, they also misunderstand our critique, as evident from this posting on their Web site: “Larry Constantine strongly opposes attempts to push the noun-verb style of interaction that we favour - one of the several things that have motivated his recent criticism of Naked Objects. He argues that some user actions just cry out for the verb-noun form. One of his examples is in a drawing program where the user selects the paint command and then chooses which object to fill with that colour. But, interestingly, in that example the user is really picking up a paint pot (i.e. a noun) and then dragging it onto other objects for an implied one-parameter method. (In other words this would work perfectly well in Naked Objects.)” --Richard Pawson Readers of this newsletter know that this is a clever distortion of my position, which certainly does not oppose “noun-verb style” (object-action grammars) but merely argues for flexible accommodation to user preferences, allowing the user free choice depending on the task and personal preferences. The redefinition of my original example is little more than a semantic game that ignores user experience. Users experience choosing an action, then clicking on the object of that action as different from dragging one object to another and will spontaneously prefer one or the other idiom as fits their thinking about the task at hand. (Of course, more people have difficulty with drag-and-drop than with simple clicking, but that is another matter.) Indeed, everything the user might want to do can forced through the narrow funnel of a highly restricted set of interaction idioms, but that does mean this is a good idea. Another posting on the same forum noted that you have to “read the manual” as it were to use a naked object form of “expressive interface.” On this, we are at opposite poles. Instructive interaction (www.foruse.com/instructive.pdf) can support flexible user problem solving with free accommodation to personal style while also eliminating the need to “read the manual.” The bottom line is that we think the user interface should accommodate to users rather than that users should accommodate to user interfaces. What do you think? =
= = = To unsubscribe, just click here to send email. |
||
| Subscribe! |
|
|
|
|
||