To Constantine & Lockwood, Ltd., Home Page To Constantine & Lockwood, Ltd., Home Page
To Constantine & Lockwood, Ltd., Home Page Back to Previous Page          
forUse: The Electronic Newsletter of Usage-Centered Design
#2 | February 2000
  Subscribe. Prior IssueIndex by issue.Next Issue

|| Contents:
|| 1. Modeling: Cluster Cases for Simpler Use Case Models
|| 2. Design: Self-Taught Users Through Instructive Interfaces
|| 3. Training: June Seminars in Usage-Centered Design

= = = = =

Do your colleagues a favor; forward this issue to them. They can
join over 2000 leading professionals who subscribe. To join, click
here: <>.
Browse archives: <>.
= = = = =

1. Speed and Simplify Use Case Modeling with Cluster Cases

In large projects or when developing use cases under time pressure, it can be tempting to hand-wave over a whole collection of use cases that seem to be related. Often we see models that bury a multitude of potential problems in use cases with vague, non-specific, or conglomerated names like "updating patient record" or "loading/reloading/unloading control program block." Is this a good idea? It depends. Many times it can be useful to be "suitably vague," especially when you are first developing the use case model. You don't want to lose momentum or become bogged down in fine details that are better deferred until later. But how do you know whether your hand-waving is reasonable information hiding or just sweeping real problems under the modeling rug?

In our own work, we have found a useful tool in the concept of cluster cases. Cluster cases are collections of functionally related use cases covered by a single, compound name. Either multiple verbs deal with a common object (for example, "creating/modifying subscriber address") or one verb applies to several related objects (for example, "printing course précis/description"). If the actions and/or objects are sufficiently close in relationship, deferring the narrative details and the decision about whether there is to be one use case or many is acceptable. To be avoided are conglomerations of unrelated cases with vaguely similar terms or divergent operations described by the same word, such as "editing patient identification/medical-history." It may all be editing, but the covered use cases are unlikely to have much in common.

We diagram cluster cases as a series of staggered, overlapping ellipses, which is visually pretty self-explanatory. We thus keep the early model simple and flag for ourselves the need for more analysis later.

Cluster cases are one of the topics covered in an important new paper summarizing much of the work on use cases since the book was published: "Structure and Style in Use Cases for User Interface Design" <>.

2. Instructive Interfaces

On several recent projects, we have been elaborating on the concept of instructive interfaces-user interfaces that subtly and implicitly guide and teach the user how to use an application. One component of successful instructive interfaces is intrinsic help. Intrinsic help is guidance built into the interface itself rather than contained in a separate help file or facility. It is subtle help the user gets without having to ask for it and even without having to know that help is needed.

One simple form of intrinsic help that we have found useful in several situations is the embedded prompt. Embedded prompts are instructions contained in text boxes or data entry fields. To keep them from being confused with data, they usually appear grayed and in parentheses. For example, in a field labeled "Name" might be an embedded prompt: "(Enter unique identifier for the program block before saving.)" Better forewarned than chastised with an error message or alert box later. Embedded prompts vanish when the control is clicked and the text cursor appears; they reappear whenever the control is left empty.

Tool tips, control tips, and data tips are another versatile techniques for providing intrinsic help. A problem with tool tips and their kin is that the help they provide is often overly terse, offering little more than a name or a brief hint. The cascading, two-level tool tips proposed in our book, Software for Use, were recently implemented within Windows by one of our clients. Although they succeed as a scheme for providing a fuller explanation after a second delay, to make them practical as intrinsic help the second delay for the cascading tip has to be fairly long-much too long for some impatient but curious users to wait. The solution is to reveal the cascaded tip either after a delay or on user action. We signal the presence of a cascaded tip with a small chevron in the lower right of the primary tip. Unlike conventional tool tips, the primary tip does not disappear from a cascading tool tip if the mouse pointer is moved over it. Instead, it shows push affordance as a rollover effect. A click anywhere within the primary tip immediately pops down the secondary tip, as does a wait of 2400-3600 ms after the primary tip. It works!

Instructive interfaces is one of the topics we cover in our new week-long training seminars. (See below.)

3. Usage-Centered Design and Usability Inspections

The first public course we sponsored in February went so well that we've already had requests to do it again. Our next week-long training in usage-centered design will be 26-30 June in Portsmouth, NH. (People loved not only the course, but also the hotel, the food, and the city!) Get the details, including early registration discounts, at <>.

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

To unsubscribe, send email with the word "unsubscribe" (no quotes) in the subject and message to: <>

  Subscribe. Prior IssueIndex by issue.Next Issue