 |
 |
forUse Newsletter Archives | |||||
 |
 |
||||||
 |
|||||||
|
|
|
forUse Newsletter Archives | |||||
|
|
|
||||||
|
|
|||||||
 |
forUse: The Electronic Newsletter of Usage-Centered Design #5-6 | August 2000 |
|
 |
||
| Subscribe. |
   |
|
|
|| Contents: = = = = = Do your colleagues a favor: forward this issue to them. They can We have been busy with some exciting work that has delayed the newsletter. We hope you find the results in this double issue worth the wait. 1. Usage-Centered Design in a Unified World Many of our clients doing usage-centered design have software tools and development practices based on the Unified Modeling Language (UML), the industry-standard notation for object-oriented analysis and design. UML, alas, has many weaknesses and shortcomings, especially when it comes to supporting user interface design and model-driven approaches for enhancing software usability. For example, there are no models or notation to support abstract prototyping. In a parallel vein, an increasing number of companies are using some form or another of the so-called Unified Process (UP) as the basis for their software development processes. With or without the "Rational" prefix or imprimatur, the UP has become a major theme in modern software development practice. Even its competitors, such as the less well-known OPEN (Object-oriented Process, Environment, and Notation) model, often define themselves largely in relation to the UP. Where does usage-centered design fit into this picture? Can you do successful model-driven user interface design using UML? How can the Unified Process and usage-centered design accommodate to each other? What can we learn from recent large-scale industrial applications and accelerated Web-based projects that have used usage-centered design? What is most needed in the way of software tools to support usage-centered design? With these questions in mind, in July we brought together some of the world's leading experts for a five-day intensive working session on the state-of-the-art and future directions for usage-centered design. We were joined by colleagues Meilir Page-Jones, methodologist from Wayland Systems and author of Fundamentals of Object-Oriented Design in UML, Helmut Windl, head of the Usability Competence Center for Siemens AG in Germany, and James Noble, educator and OO patterns guru from Victoria University of Wellington, New Zealand. It was an amazing week during which we were able to pull together an enormous wealth of experience and insight to achieve some real breakthroughs. As we organize and write up our work, we'll be sharing results via this newsletter and in white papers at forUse.com and elsewhere. The good news is that the group delivered the goods in several areas, including incorporation of usage-centered design notation into UML, better techniques for integration of usage-centered design with software design and architecture, and a much improved approach to abstract prototyping (see 3. below). Stay tuned. 2. Usage-Centered Design with UML and UP? If you are doing usage-centered design or using essential use cases along with UML/UP/RUP, we want to hear from you! Send us a note describing (1) what tools you are using, (2) what problems you have had, and (3) what you've learned. We'll collate and report what we hear in a future newsletter. 3. From Abstraction to Realization--in Double-Time One of the most exciting pieces of work to emerge from the Convergence Conference is a refinement to the content model. In usage-centered design, the content model describes, in the abstract, the contents of the various views or interaction contexts in the user interface being designed. It is a form of "abstract prototype" that describes the overall organization of the user interface without specifying details of appearance and behavior, serving as a bridge between a task model and a final visual and interaction design. Many designers have found the process of "abstract prototyping" to be both helpful and a major headache. When we collected and reviewed our experiences on numerous projects, we concluded that abstract prototyping was indeed worthwhile but the current technique needed refinement. We took a closer look at some major projects to see just where the problems were and to try to overcome them. We identified three significant hitches: (1) Often it was hard to come up with the right abstract tool or material to put into the content model. (2) The consistent language of the users and application domain had a tendency to get lost in abstract prototyping, isolating the content model from other models, particularly the object domain model. (3) Translating an abstract prototype in the form of a highly abstract content model into a final design was often extremely difficult and messy--one of those steps in a process where one is tempted to erect a sign: "Here magic happens!" It became clear from our analysis that conventional content models were too abstract and unstructured to bridge the enormous gap from task model to design. To better support the design process, designers need a more informative abstract prototype that conveys specific information without going too far into design, one that lies closer to a final solution without overly constraining the design or specifying too much detail. At the heart of the approach we devised is a standard, all-purpose set of abstract user interface components--canonical components--from which the modeler constructs the abstract prototype. These canonical components are specific as to purpose--such as, contain, collect, select, create, move, and the like--without specifying the actual user interface widget for implementation. In all, just 15 abstract components are enough to model virtually any user interface in the abstract. The abstract materials in this "canonical set" include: container, collection, element, and notification; the abstract tools include: operation/action (generic abstract tool), start, quit, select, create, delete, modify, move, duplicate, accept, and link. An abstract prototype based on canonical components is just about half way between a task model based on essential use cases and a realistic paper prototype. For this reason, it smoothes and simplifies task-driven user interface design. Not only is it easier for the designer to pick appropriate abstract components based on task requirements, but each canonical component typically translates more or less straightforwardly into a small set of standard solutions. Less experienced designers are helped to quickly find good conventional solutions; sophisticated designers will find that common patterns and opportunities for innovation are easier to recognize in models constructed from standard abstract components. For more details, get the full working paper at <http://foruse.com/articles/canonical.htm>. 4. Scoping it Out Defining the scope is basic to every product development process. In the absence of careful definition and control over scope, products remain ill-defined, and projects are subject to "scope creep" that can steadily turn a challenging project into an impossible one. Drawing the boundary around the system--specifying what is included and what is outside the scope of the project--is an art form. Most problematic are situations in which features are added that do not quite add up to a complete and useful set of capabilities. The results of this kind of creeping featuritis are complex systems in which many of the features go unused by users. Scoping is one area in which marketing issues often resemble the functional and technical issues. You lose if you include functions or features in a product in attempt to appeal to an additional audience or market segment but fail to include all the capability needed by those potential customers. On the flip side, including more capability than is actually needed by customers wastes development and marketing resources. How do you draw the system boundary appropriately? User roles provide one particularly appropriate basis for deciding on what will be included and what will be excluded from a given product or release. Often initial fantasies for a new product or service begin with unrealistically ambitious fantasies. Initial user role models may include many more roles than it is practical to support. We develop user role models by brainstorming a set of candidate roles. The initial model is often too ambitious, even after we pare it down by eliminating overlap and redundancy. As we begin to describe and characterize roles, we start to develop a sense of just what is needed to support particular roles. This analysis helps us in the next step: prioritization. We rank user roles in order of their expected frequency or commonness among potential users, then we rank in order of importance for a successful product. From these two rankings we select a set of core user roles that must be supported in the next release of the product. In many cases, there are also some clear outliers--relatively unimportant roles of low expected frequency--that are deliberately set aside, either permanently or until reconsidered for a future release or new product. Good task modeling assures us that everything needed to support the included roles will be provided by the system, and by excluding entire user roles, we avoid incorporating partial sets of features that are not needed by the target users. Even when project scope has been defined in advance or dictated from above, prioritizing and scoping based on user roles often points to more realistic or cost-effective ways to draw the boundary. Because the user role model is the first step in usage-centered design, guidance on revising the scope comes early enough to be really useful. 5. Seminar Success Demand for training in usage-centered design keeps increasing. The May and June seminars sold out, and now the September series in Portsmouth, NH is following suit, with only a few places left. Get the details today at <http://foruse.com/seminars/>. =
= = = To unsubscribe, send email with the word "unsubscribe" (no quotes) in the subject and message to: <mailto:unsubscribe@foruse.com> |
||
| Subscribe. |
|
|
|
|
||