Contents:

|| 1. Events: UPA, Classic, and Ariel Support forUSE 2002.
|| 2. Modeling: Mapping Use Cases.
|| 3. Design: In-Context Communication with Users.
|| 4. Training: Master Class for Experienced Designers.

= = = = =
* Featured design house in the March/April issue of ACM interactions!
* Winners of the 2001 Performance-Centered Design Platinum Award of Excellence.
* Winners of the 1999 Jolt Award for Product Excellence for the book, Software for Use
* Over 2000 leading professionals have subscribed to forUse.
Forward this issue to your colleagues.
To join: http://foruse.com/subscribe.htm.
Browse archives: http://foruse.com/newsletter.htm.
= = = = =

1. Events: forUSE 2002 Sponsors Join; Deadline Looms.

One sign that we must be doing something right is the company we have been keeping. We are absolutely delighted to be joined by the Usability Professionals’ Association, Classic Systems Solutions, Inc., and Ariel Performance Centered Systems, Inc., who are collaborating with us to bring you forUSE 2002, 25-28 August in Portsmouth, New Hampshire.

The UPA is the leading international organization for professionals working in the areas of Web and software usability and user interface and interaction design. It is a practical-oriented organization dedicated to enhancing the skills and professional success of usability professionals. We were impressed by their newly launched print publication, User Experience, which is a welcome addition to the available resources for practicing professionals. More information about the UPA at http://www.upassoc.org/.

Classic Systems (http://www.classicsys.com/) are the usability engineering experts who led the way with software-based GUI guidelines. Ariel (http://www.arielpcs.com/) is the recognized leader in designing knowledge management systems that capture and integrate corporate knowledge.

The conference is a truly world-class opportunity to build your skills and knowledge by learning first-hand from the leading thinkers and doers of usage-centered design. Details of the rich program are at http://foruse.com/2002/program.htm.

LAST CHANCE: To take advantage of early-bird discounts of $200 on conference registration and $100 on tutorials, you must register on the Web by 30 June: http://foruse.com/2002/register.htm.

2. Modeling: Picture This - Task Maps and Use Case Diagrams

In June I was in Canada presenting a 2-day seminar on advanced topics in usage-centered design for TorCHI, the Toronto-based special interest group on computer-human interaction. In an aside, I commented that we now seldom create task case maps (or “use case diagrams” to the RUP/UML crowd). Say what?? First the world learns that accounting firms are not keeping accounts, and now you are told that the grandfather of software diagramming, the inventor of structure charts, is disavowing drawings. What is happening to the world?

After the seminar, Roger Chang of Cognos sent me email to follow up on my remark. He wrote:

“One huge advantage of task case maps is that [they offer] a way to see a ‘birds eye view’ and all the relationships, so that we don't design in pieces myopically. I'm wondering how to [salvage] this idea I have that the big picture is very useful and that task maps are the answer.... How are designer's using your approach to modeling able to get this big picture view without the task maps? Are there some specific techniques that address this?”

Roger is absolutely right about the importance of getting the big picture, especially when it comes to mapping out the overall user interface architecture to fit the structure of the tasks being supported. In principle, a task case map, which shows all the task cases and their interrelationships, is just the ticket. In practice, task case maps and their “unified” cousins, use case diagrams, do not deliver on their promises precisely when and where you need them most.

To understand both the problems and potential solutions, let’s take a look at UML use case diagrams, which picture use cases as little ellipses inside a box that represents the system boundary, actors as little stick figures around the outside of the box, and sundry connecting lines for all their interrelationships. It seems like such a reasonable idea--a kind of top level context diagram for the system with all actors and all their supporting use cases.

When most people think of such use case diagrams, they picture something like the ones they’ve seen in text books and training classes, such as the borrowed one I included in my presentation at TOOLS Pacific in 2000. It models a simplified ticketing kiosk with 4 use cases supporting 4 actors through a total of 7 relationships. If you’ve never seen this widely reproduced and often imitated little diagram, it’s slide 20 in the TOOLS presentation, which you can grab from our Web site at http://foruse.com/presentations/tools.pdf. (Be forewarned that it’s a 1.4MB download.) or turn to page 27 of the Rumbaugh, Jacobson, and Booch UML Reference Manual (Addison-Wesley, 1999). (Be forewarned that it’s a 1.2 kilo load and will cost you nearly $47/kg.)

For toy problems and classroom examples, use case diagrams are just dandy and do, indeed, give a clear, easily interpreted overview. But what about real-world problems, like the ones you and I work on, in which there can be dozens of user roles supported by hundreds of task cases. Even at the lower end of this range, use case diagrams become virtually unreadable and all but impossible to interpret.

Consider a moderate sized application having 100 task cases supporting 13 user roles with typically 6-18 task cases per role and some 65 task cases that are unique to a single role. A use case diagram for this problem, such as the one shown in slide 21 of the TOOLS presentation, resembles an Olympic-version of pick-up-sticks, a visual woodpile that can only be understood through laborious line-tracing. Any notion of a useful birds-eye view has vanished. The trees have become lost in the forest, which covers the landscape in a jumble of lines and shapes. The bigger the problem, the more important it is to have a meaningful map of the landscape, but the bigger the problem the less sense such diagrams make.

As with all modeling and model building, the way out of the forest is through selective views that hide information. For visual and interaction design, two kinds of information most need to be gleaned at a glance from any good overview: role support and task co-operation.

First, there is the question of which task cases support which user roles. This view is important for prioritizing task cases and checking the task model for completeness and consistency. For each role, you need to ensure that the associated task cases are sufficient to cover all responsibilities of that role. You also want to look for critical task cases that support many high-priority roles and to identify isolated task cases that support only a single, low-priority role. This information provides guidelines useful for refining project scope and for planning feature rollout.

For both these purposes, a matrix or tabular form is easier to use and scales up more readily than a diagram. We use a Role Support Matrix that puts user roles in columns and task cases in rows. The cells in the matrix express the relationship. In the simplest form, an X indicates a task case supports a role; in a more sophisticated variant, the intersection can indicate how important the task case is to a role, from irrelevant through absolutely critical.

The second sort of information to get from a task overview is what goes with what, that is, what task cases need to be supported in the same place or region of the user interface. For this, a complicated use case diagram or task case map can be confusing or even misleading. For planning a first cut at the user interface architecture, all you really are interested in is how task cases cluster together.

These days, our preferred way of modeling is to brainstorm task cases directly onto index cards, then refine the model in card-based form (see http://foruse.com/newsletter/forUse19.htm#3 and http://foruse.com/articles/webapplications.htm). Once the task model is complete, we can use the task cards to construct a co-operation clustering. Co-operating task cases are task cases that are likely to be enacted together as part of a common scenario or in sequence or within the same time frame. We construct a tentative co-operation clustering by arranging cards on a surface with the distance between cards representing a subjective judgment of how likely the task cases are to be enacted together. Strictly speaking, this is a form of affinity clustering in which the distance is inversely proportional to the probability of co-operation: cards piled on top of each other are certain to be enacted together; widely separated cards are highly unlikely to be enacted together.

Each cluster of co-operating task cases represents a candidate for a separate interaction context (page, screen, dialog, form, etc.). Although a snapshot of the co-operation clusters or their re-drawing in diagrammatic form affords a useful birds-eye perspective, here, too, a matrix format scales up better. A Co-operation Matrix, with clusters as columns and task cases as rows, also has other advantages. It easily accommodates to the common situation where one task case really belongs in multiple clusters, which implies that the supporting facilities need to be accessible from or duplicated on multiple pages or dialogs.

I am, I confess, a visual thinker, with a strong personal preference for getting information in graphical form, so I do not surrender my diagrams casually. However, on large projects that demand methodical modeling and meticulous tracking of details, the tabular or matrix formats are much handier for most purposes, although I still like to sketch out a draft navigation map based on the co-operation clustering.

What is missing from the Role Support Matrix and the Co-operation Matrix are the details of the relationships among task cases. These become particularly important when it comes down to the design of each interaction context or set of interrelated contexts. Separate task case maps of the smaller number of tasks associated with one or a few clusters can be easily drawn. Because they span fewer cases, these localized task case maps clarify how a collection of task cases are interrelated without becoming a confusing jumble of lines.

3. Design: Error? What error? Where? Communication in Context.

In registering on the Web for some service or other last week, I committed some minor sin or sins and got one of “those pages” topped with a message in red. It admonished me that one or more of my fields had been entered improperly. Try though I did, I could not decipher what was in error. After three tries and the third use of the back button, I was duly punished with a fresh form within which all of the fields had been wiped clean. “Oh, fiddlesticks!” I muttered. Or other words to that effect.

I kept trying. I persisted only because I am in the profession and wanted to know precisely what perverse programming or vile validation had wiped me out. Real users would most likely have skedaddled after the second attempt.

Of course, the problem lay in that ominous phrase about “one or more” of my fields. There were multiple “mistakes,” some of which were hard-to-spot typos on my part and the other of which was that the name of our company had too many characters for their dumb-eared database. I discovered the latter only because, on retyping all my entries, I did not make the same typographical errors.

The problem with this Web form is not just that the original error message did not specify enough information; the information was in the wrong place. Even if it had spelled out all three or four “errors” in my entries, the fact that it was at the top of a long page with many fields would have made finding and correcting all the fields a challenge that not all impatient potential customers would accept.

It’s all about communication in context. We covered this topic in some depth in our book, but designers and developers on the Web seem not to have gotten the word. The rule is simple: Give feedback in context, not out of context. Tell users what they need to know where they need to know it.

What is the right way to report form validation errors to users? There is no one right way, but there are some broad principles that are not too hard to follow. First, if the error truly must be corrected, you need to make sure that the user has the opportunity to correct it by using what Alan Cooper calls a “blocking bulletin.” A message box is best, as it does not completely break the visual context, but a separate page with a message also works. If you give the user the original page back with a message inserted at the top, you need to style the message to be sure the user understands its significance immediately. Boldface alone, even with red text, is not always enough or appropriate.

Second, each and every field that is in error should be flagged with a clear visual indication that it needs to be corrected along with information about what the problem is and how to correct it. Effective techniques to flag errors include changing the background color of the problem fields (e.g., to light orange, #FFCC99), putting a thickened color border around the fields (e.g., red-orange, #CC3300), and putting a message adjacent to the field (e.g., in dark red, #990000). The thick color border is a little harder to spot at a glance but has advantages for color-impaired viewers. A message should be present in all cases, and a screen tip with more detail is desirable.

Best practices in this aspect of forms design for the Web would begin with a modal message, such as:

“We have a problem with your loan application. Please correct the fields that are highlighted with a thick red border, then click the Apply button again.”

The focus should automatically go to the first field to be corrected. Adjacent to the highlighted field should appear a short phrase, such as, “Too long.” A mouse-over screen tip might read: “Type no more than 24 characters including spaces.”

Be sure to tell users everything they need to know up-front. Yahoo, for instance, presents a wide entry field for company name with more than enough room to type “Constantine & Lockwood, Ltd.” Only after you type it in and submit the form do you learn that company names are limited to 25 characters. Cut it down to “Constantine&Lockwood Ltd” and you are slapped on the wrist by another message informing you that it contains “improper” characters. Infuriating. Eventually you learn that ampersands are disallowed, so you type “Constantine Lockwood Ltd” despite the fact that the ampersand is our trademark and part of the legal corporate name. Fiddlestick them.

In my original example, the problem vanishes if the field length is not so sharply and inappropriately limited. If the database must use an artificially short field, simple truncation spares the user unnecessary inconvenience. The truncation will become evident on the confirmation page, where the sufficiently motivated user will have a chance to choose an alternative editing. The general point is not to validate what you don’t have to; it just imposes unnecessary restrictions on users and may even lose customers.

To learn more about supporting user intentions on the Web, be sure to hear “Devilish Details: Best Practices in Design for e-Commerce” at forUSE 2002. Register now before the discounts disappear (http://foruse.com/2002/).

4. Training: Master Class in Usage-Centered Design

For those of you ready to take your work to the next level, Lucy Lockwood and Larry Constantine will be conducting a Master Class for experienced designers called “Pushing the Envelope.” This special post-conference class is open to interaction designers, information architects, user interface designers, and other usability professionals who want coaching from two leaders in the field. Register now for the conference and master class while early-bird discounts are still in effect. You can save $200 on conference registration and $100 on each tutorial through 30 June. Details at http://foruse.com/2002/.

= = = =
forUse is published 9 times a year by Constantine & Lockwood, Ltd., trainers, consultants, and innovators in usage-centered design. On the Web at <http://foruse.com/>. © Copyright 2002, Constantine & Lockwood, Ltd.

To unsubscribe, just  click here to send email.