|| Contents:
|| 1. Design: Sweating the details. [TECHNIQUE]
|| 2. Practice: February seminar deadline approaches. [TRAINING]
|| 3. Tools: Soft support. [PROCESS]

= = = = =

Forward this issue to your colleagues so they can join over 1200
leading professionals who subscribe. Click here to join:
<http://foruse.com/forms/subscribe.htm>.
Browse archives: <http://foruse.com/newsletter/>.
= = = = =

ForUse.com, a leading resource for usability and design
professionals, ranked among the top 20% of sites worldwide by
WebsMostLinked.com.

= = = = =

1. Persistence of Vision.

Edison said it first and best. Invention is more perspiration than inspiration. Really good user interface design may begin with ideas but ultimately is a matter of persistence, of pushing through on problems and of sweating the details.

This lesson was driven home afresh in a recent class taught for a client. Rather than using mere exercises or "toy" problems, we employ realistic design problems in our public and in-house training programs, and this class was working on a truly challenging case study. They had to design a data entry scheme for rapid on-the-fly recording of usability defects as these are uncovered during live inspections. The class was forewarned that anything short of a breakthrough would probably not make the cut. Ordinary components and conventional designs would be unlikely to supply the performance edge needed for a successful system. The entire design, down to the lowest level of detail, needed to be closely tailored to the specific tasks of defect recording.

Despite the advanced warning, one group ultimately delivered a rather ordinary solution that fell far short of the mark. In discussing their approach and the process by which they had arrived at their solution, it became clear that they had actually started out on a fast track but had gotten derailed along the way. The team had considered--and quickly rejected--several promising design ideas that could have led to a sound and creative design.

What had happened in this team was that as soon as an approach to some part of the problem was proposed, it would be criticized on various grounds, then quickly rejected. Instead of trying to find a way to overcome or work around objections, they ended up with a lowest-common-denominator design for which the problems, though substantial, were not so immediately apparent to them.

For example, the task of noting defects in a user interface design is, in part, an inherently visual, graphic-oriented problem. An effective recording scheme must provide a way for quickly and precisely indicating where in a screen shot or design sketch each offending element is located. A naive solution might supply a text box for entering "defect location," which could often require the harried session scribe to think up and type something like "button second from left on floating tool palette docked at top right" or "just slightly left of center below the midline."

Our erstwhile design team had briefly considered allowing the scribe to mark up a graphic image of the interface but had rejected the technique on several counts. As they explained their logic, a thumbnail image would be too small to mark directly, and an extra step would be required to enlarge it for marking. Marking the image would require selecting a marking tool--yet another extra step--followed by another relatively slow operation as the recorder drew a line around the part of the image to be noted.

In a sense, the team was trapped by a severe case of the "yes-buts." "Yes, but that requires an extra step." "Yes, but that is a slow operation." In our experience, better designs result from starting with an initial design concept that closely fits the task, then pushing through the yes-buts by treating each as another problem to be solved.

This team began by thinking inside the box and assuming that a screen image or drawing would be represented by a thumbnail image, an assumption that may or may not make sense. If a thumbnail image is too small, then the designers should consider how screen real estate might be allocated to allow for a larger image. If it has to be a thumbnail but speed is of the essence, then the challenge is how to make the image expandable without requiring an extra mouse click. Perhaps the image could expand automatically on mouse-over or on receiving focus.

Rather than dropping good ideas by yes-butting them to death, consider trying a process more like the one that we and our clients have found to work so well.

1. Start with a promising direction or scheme that seems to fit well with the tasks being supported.

2. Identify and question built-in assumptions regarding the proposed approach.

3. Identify problems or limitations with the proposed approach, then try to find ways to overcome or circumvent these problems.

Eventually, if too many unsolved problems accumulate or if truly fundamental flaws emerge, it may be necessary to go back to square one and consider alternative approaches. But, don't be too quick to abandon your vision. Persistence pays.

2. Learning How

While we are on the subject of training, don't miss the chance to let your colleagues know about the upcoming full-week intensive training in usage-centered design, 5-9 February 2001. This newly revised version of our well-received seminars includes the latest material plus expanded opportunities to put techniques into practice. Register by 29 December and you can save up to $500! Details are available at: <http://www.foruse.com/seminars.htm>

3. Of Tools and TOOLS

Last month your earnest editor keynoted the TOOLS Pacific conference in Sydney, Australia. Inspired by the response to my recent Software Development Management Forum column called "Unified Hegemony," the talk was titled "Can UML and the Unified Process Meet the Challenge of Usability?" The answer would have to be described as a qualified "no," at least not in their present form. Judging from discussions in the hallways and in the meet-the-author poolside chat later in the day, the PowerPoint polemic on unified problems stirred up quite a hornets nest.

In its present form, the so-called Unified Modeling language fails to support usability and user interface design on a number of counts.

First and foremost, UML provides neither a diagram type nor a notation for representing user interfaces in either abstract or realistic form. Neither is there any model or notation for modeling user interface architecture, that is, the various views or interaction contexts to be provided and the interconnections among them. Users of UML and the tools that support them are reduced to such clumsy workarounds as representing interface context navigation maps as class diagrams.

In addition, the UML concept of "actors" is neither as rich nor as useful for model-driven user interface design as the concept of user roles employed in usage-centered design. Indeed, when speaking of human actors, the UML term is misleading, because it is the role not the actor that is most important for user interface design.

Worst of all, and most surprising in light of the roots of UML in use-case driven design, there is no standard way for defining use cases and describing their contents except as notes or annotations. For designers trying to use software tools strictly based on UML, this means that the tools do not recognize and understand the contents that define use cases. For designers using structured use cases based on well-organized templates, such as those developed by us and by use case guru Alistair Cockburn, the tools are even less useful and usable.

The Unified Process and the Rational Unified Process, its commercialized cousin, are harder to criticize because the sundry books and documentation present competing and conflicting pictures. The somewhat slippery stories presented leave UP supporters free to claim that UP and RUP are pretty much whatever they want them to be. Of course, you can spend a whopping per-seat licensing fee and get a copy of the RUP, but even that doesn't settle the matter, since the process is argued to be extensible and customizable. This really means that, if you do the work of understanding thousands of pages worth of detail plus the work of paring, pruning, and enhancing the process, you can turn it into something else that it probably should have been in the first place.

The problems in the Unified Process as it has been defined in public sources, begin right up front. First of all, user interface design is seen as a requirements activity rather than a design process. Moreover, the important concept of user roles is not developed sufficiently to support usage-centered design based on essential use cases. On the plus side, UP does employ user interface design models. The so-called "logical prototype" is, in fact, a somewhat simplistic derivative of the Content Model as we developed it for usage-centered design. However, the principle technique for user interface design in UP is by iterative prototyping rather than by any systematic derivation based on models.

We have long taken a collegial and conciliatory stance on these issues and have repeatedly offered our help to Rational and to other software tool vendors. Nevertheless, despite a growing cadre of frustrated designers, much of the process-support and CASE tools industry seems yet to discover systematic, model-driven user interface design or the need to support it in the tools.

All is not lost. If the right people lobby the OMG with sufficient fervor, the UML notation can be fixed. (1) System actors (other systems and machines) must be distinguished from user roles. (2) The notation should support structured contents of both user roles and use cases. (3) The UML "use case diagram" needs to be improved by using distinct line types for various relationships. (4) Most importantly, models and notations for abstract prototypes and interface navigation maps must be added.

The fixes for the Unified Process are less straightforward because of critical differences in philosophy. In our view, one size does not fit all, especially if the one size available is the extra jumbo deluxe heavyweight all-in-one unified edition. We believe that a simple process that can be scaled up is far better than a complex process that can be cut down. Our philosophy has always been that every diagram, document, activity, or artifact must fully justify its existence by demonstrably saving time, improving quality, or facilitating problem solving.

Incidentally, if you have had frustrating experiences with tools and tool vendors, please tell us about them. And if you have successful workarounds for the inadequacies of current tools, please share them with your fellow readers. <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 2000, 2002, Constantine & Lockwood, Ltd.

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