|| Contents:
|| 1. Conference: forUSE 2002.
|| 2. Practice: Implementing Good Designs.
|| 3. Innovation: Beyond the Clipboard.
|| 4. Colleagues: Networking Payoffs.

= = = = =
* Performance-Centered Design Platinum Award of Excellence 2001 - STEP 7 Lite
* Jolt Award for Product Excellence 1999 - Software for Use
* Over 100,000 downloads of  "Structure and Style in Use Cases!"
<http://foruse.com/articles/structurestyle2.htm>
* Nearly 2000 leading professionals have subscribed to forUse.
Forward this issue to your colleagues. To join: <http://foruse.com/forms/subscribe.htm>.
Browse archives: <http://foruse.com/newsletter/>.
= = = = =

1. "Design that Works."
25-28 August 2002. Mark your calendars. Those are the dates for forUSE 2002, the First International Conference on Usage-Centered, Task-Driven, and Performance-Centered Design to be held in picturesque Portsmouth, New Hampshire.

forUSE 2002 will be THE premier event of its kind and promises to be an exciting and enriching experience. Gloria Gery, pioneer of electronic performance support, is the keynote speaker. The week will be packed with a full schedule of tutorials, featured speakers, and special events. Come share experiences, ideas, and insights with colleagues and learn the latest techniques. And bring your family for an end-of-summer New England vacation. Watch our Web site in December for more details (http://foruse.com/).

Got something to say, an idea that works, experiences to share? We are looking for proposals for short presentations and experience reports (90 minutes), as well as full-day tutorials. Presenters will receive free registration for the conference and publication in the proceedings plus a stipend. Get details in the Call for Participation available by email (mailto:program@foruse.com) or on the Web (http://foruse.com/2002/).

2. Implementing Usage-Centered Designs
You can have the greatest design in the world, but if it is not programmed right you might as well have saved the trouble. One of the truly exciting things about the Siemens STEP 7 Lite project (http://foruse.com/pcd/) was seeing the design up and running, almost exactly as the design team conceived it. The fidelity of the implementation was no accident. Great pains were taken to assure good communication and coordination between the modeling and design team and the software engineers.

Without that careful planning and attention, good design can quickly go south. Here are some lessons we've learned about translating usage-centered design into code.

It's impossible to specify everything.
Up-front design can never cover all the bases and anticipate every last detail of the user interface. On one project, usability testing uncovered major problems in the beta release because users were confused by when and how various forms of data were being saved by the system. The user interface design team had done a thorough job in most areas but had naively assumed that the software engineers would use a single, consistent model for object persistence. Alas, since it wasn't in the design specs, each programming team had worked out its own solution. We won't make that same mistake again, but there is sure to be something else we "just assumed" or "didn't think about." So, no matter how good your designers and programmers might be, you need to have follow-up and usability testing to catch the inevitable glitches.

Teach your programmers well.
Messages of one kind and another are an aspect of the user interface that cannot possibly be fully specified in advance. In many cases it only becomes clear that the user needs to be notified of some condition or queried about some action once a programmer is deep into the code. Most of the resulting interaction between the software and the user ends up being determined "on the fly" by the programmer who happens to be working on that particular piece of code, which is good reason for everyone on the development team--not just the user interface designers--to learn the basic principles of usability and user interface design. Some aspects of the visual and interaction design will always end up being specified by the programmers in the course of programming, so you want to improve their chances of doing a good job.

Because messages are among the bits most likely to be "designed" on the fly, programmers should have especially good guidance in how to create effective messages. One of our clients created a complete manual for programmers on how to write good error, confirmation, and notification messages--including when NOT to annoy the user with a message or alert.

Stay in touch.
Inevitably, some problems or missing pieces in the user interface design will be discovered in the course of programming. Whatever project and programming model you follow, it is crucially important that the designers continue to be involved and available to the programmers throughout the project. This doesn't mean that programming progress has to grind to a halt every time a programmer has a question about some small detail. It does mean that programmers should have a feel for what aspects of the user interface layout and behavior are likely to be significant from a usability standpoint and which ones are not. Once again, it helps to have developers who are trained in the essentials of usage-centered design and who know when to stop and consult the designers and when just to plunge ahead with a reasonable assumption.

Have a friend in court.
On several projects, we have included at least one hard-core programmer in the user interface design process. This tactic pays off in several ways. For one thing, it insures that at least one member of the implementation group is thoroughly familiar with the design and how it ended up the way it did. Second, over time it helps to spread knowledge of usability and user interface design, especially the kind of deeper appreciation that only comes from having struggled through a complete design process and been there to hammer out the tough details.

Finally, a programmer who has been involved on both sides of the process becomes a "linking pin" who can help facilitate communication and coordination during the implementation process. Many questions arising during coding can be handled directly by a linking pin team member; those that can't can be readily identified and passed on to the rest of the design team. Programmers who participate in user interface design also tend to absorb some of the perspectives and values of usage-centered design, which they can then carry over into their work with other developers.

3. Working Space
In the context of various specific projects over the years, we have managed to come up with a number of user interface and interaction design innovations of broad utility. We described some of these in our book, including an animation solution for improving multi-row tabbed dialogs (p 204), viewfinder-style graphical navigation (p 206), and tool trays for as-you-go customization (pp 285-287). One of our inventions, progressive or cascading tool-tips (p 242), is seeing increased use in a variety of software products, including the recently released Siemens STEP 7 Lite software that took first place in the 2001 Performance-Centered Design competition (http://foruse.com/pcd/).

Our work on a browser-deployed performance-support system for classroom teachers generated a whole series of new ideas, some of which were targeted for patenting when our dot-com client tanked. Previously we have described two of these--a multi-function table-of-contents control and a specialized selection list--in design studies posted on our Web site. We have now completed the third study in the series, describing a novel approach for compiling and organizing diverse notes and resources into complex documents. The "dynamic workspace" we devised may remind some of you of the "dock" in Apple's OS X, but in this case we actually anticipated Apple.

The dynamic workspace functions as an unobtrusive but always available intelligent clipboard for pulling together and keeping track of information from many sources. Whereas classic copy-and-paste techniques rely on hidden behavior (the arcane keyboard functions of ctrl-C and ctrl-V), our dynamic workspace and its contents are always visible without usurping too much space. The workspace is also tailored for simple and efficient operation. It is smart enough to understand the nature of the information being gathered and operates by reasonable rules that save steps for users. For example, if a teacher goes to add to the workspace without first selecting anything in the visible document, the workspace does the reasonable thing. Instead of slapping the user on the wrist with a ping or a modal error message, it just takes the whole document. Consistent with our design philosophy of instructive interaction, the first-time user is clued into this action by the visible results of the whole-document icon being added to the workspace. For more about how and why we did it, check out the new design study (http://foruse.com/articles/designstudy3.htm).

3. Pay it Forward
Do your colleagues and the profession a favor. Pass on a copy of this newsletter to your colleagues along with your personal recommendation. Or send us their names, titles, and email addresses (mailto:newsletter@foruse.com).

= = = =
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 2001, 2002,  Constantine & Lockwood, Ltd.

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