 |
 |
forUse Newsletter Archives | |||||
 |
 |
||||||
 |
|||||||
|
|
|
forUse Newsletter Archives | |||||
|
|
|
||||||
|
|
|||||||
 |
forUse: The Electronic Newsletter of Usage-Centered Design #18 | December 2001 |
|
 |
||
| Subscribe! |
   |
|
|
|| Contents: =
= = = = 1.
Design Conference Dates and Deadlines Response to the announcement has been tremendous, setting records on visitors to forUse.com. The deadline for submissions, 15 February, is approaching faster than you think, so get your proposals prepared for consideration right away. Remember, presenters receive a stipend, free registration for the conference, and publication in the proceedings. Proposals (by email only, mailto:submission@foruse.com) should include: (a)
proposed title More details in the Call for Participation are available by email (mailto:program@foruse.com) or on the Web (http://foruse.com/2002/). Spread the word. FORUSE 2002 will be THE premier event of its kind, a week of learning, of new ideas, and of networking and making new friends among the great people working on the leading edge of usage-centered design. 2.
Practical Q&A Some of these questions are easy and need only a quick answer. Some are tougher, and take some thought. Recently, we've had a particularly good series of questions from a group at Sierra Systems who are busy applying usage-centered design on a new project. We thought some of the issues raised by David Blacoe and Christine Cunliffe might be of broader interest, so we have the compiled and edited the whole series of questions and answers. Q. DATA ATTRIBUTES. Could you provide one or two tips on where and how to specify data attributes. Some of us have decided to record them directly onto the content models. Others have decided to create a template of empty boxes that matched the size and width of the interaction spaces and populate the boxes with attribute names this way. Do you have any other suggestions? A. We don't think there is one right answer here, but in our own work we strive to keep the content model or abstract prototype as clean and simple as possible, carrying just the minimum amount of information needed to make them understandable for review, validation, and experimentation. In general, we prefer to use just data element or domain class names in content models, keeping the definitions of these separate in a glossary, data definition, or domain model. Where the attributes or substructure are important for making the content model understandable, we might also carry these parenthetically in the contents themselves. (As a rule, we like to carry information, such as attributes, in only one place in a collection of models. Otherwise, especially on large projects, you risk accidentally changing what is recorded in one place without updating it in the other. This is why we link back to a common business rules model and a common data model within task cases and elsewhere rather than copy these "in place" wherever they are used or referenced.) In practice, content models (or canonical abstract prototypes, which is what we now prefer to use) are used for two purposes. The original and main intent was to serve as a bridge for the user interface designer to get to a better visual and interaction design. For this purpose, the main issue is how much "intellectual leverage" the content model gives you in finding a good design. You want to keep the content model lean and flexible to permit easy reorganization, even radical restructuring of the user interface architecture. If you carry a lot of extra detail or complexity, shuffling things around gets more difficult. Moreover, greater abstraction and less concrete detail encourages more creative thinking. Some groups have also started using content models as part of specifications for programming. For this purpose you do need more detail and specificity. Q. USE CASE INHERITANCE. We are struggling with "is a kind of" versus "is similar to" in use cases. Let's say we have two use cases: Recording Service Application and Verifying Service Application. Verifying Service Application has all the same functionally as Recording Service application plus a bit more. At first glance it appears that Verifying Service Application is a kind of Recording service application. On the other hand, there are subtle differences in the common functionality, primarily because two different user roles are responsible for these. For example one role may be able to enter a container of information while another may only be able to view it. Do these subtle differences mean that the two use cases are similar--as opposed to one being a kind of the other--or should there be a third use case (that may not actually be developed) that holds the common functionality of which both are a kind of? A. The important thing is to recognize and represent that there is some kind of close relationship among the use cases/task cases without getting too hung up on figuring out the "right" one. From a user interface design standpoint, it is rarely necessary to definitively pin down the exact relationship among task cases. Once you recognize the similarity or commonality, as a designer you know that you need to come up with a single common solution or at least similar ones and that the support for these task cases needs to be found in the same general part of the user interface. In addition to the alternatives you mention, another possibility is that these tasks could be modeled as one common generic task with extensions, some of which support only specific roles. (For example, perhaps, "Entering Container" extends "Recording/Verifying Service Application.") Looking back at my own work, I would guess from your description that I would either model this as a generic (not-enacted) task case with two specializations ("is-a-kind-of") or with extensions. If I am in a hurry, I would probably call it an affinity and write it down as one "resembles" the other; that's enough to keep in mind the similarity. The ultimate consequences in terms of a good user interface design are pretty much the same in any case. Q. SUPPORTING DEPENDENT USE CASES. If one system use case is being used by another, should the dependent use case appear directly on the interaction space of the primary use case or should there just be a tool on the primary use case to link it to a second interaction space, especially if the same use case is used by other use cases? A. Yes. That is, it depends. The issue is a matter of task efficiency and user performance. If you take the user to a new screen, you interrupt the visual and cognitive context. As Alan Cooper says, windows are like rooms; you'd better have a good reason to send a user to another room. On the other hand, if you clutter up the interaction context with the support for many different subtasks, you risk overwhelming the user. Basically, if the subtask is something that will always or usually be performed by the user and the support for it fits into the interaction context for the base case, then it probably makes sense to put it there, so long as the result is not a screen that is cluttered and confusing. Note that the fact that the task case may be used by (included) in other task cases supported elsewhere does not mean you cannot collapse the support for it into the context(s) supporting the base case. It just means that the same collection of widgets in the same arrangement may appear on more than one screen. In short, there is no one right answer. That said, in my experience, initial designs (especially by engineers or by novices) tend to bounce the user around from page to page or screen to screen far too much. In general, better design results when more of what the user needs to complete a task is right in front of them when they need it. This does not mean one should "surface" everything, but it does mean giving users what they need where they need it. That often requires creativity on the part of the designer to keep things available without being in the way, managing the complexity through easily understood organization rather than through hiding things. Q. DATA-CENTRIC DEVELOPERS. A follow-up question. We are currently designing a common system for 3 distinct business areas. In the past we would have developed 3 distinct systems. We have found this approach to be of real value, particularly for identifying the commonality among the 3 areas. We actually used use cases to document the business processes. We adapted a template from Alistair Cockburn. From these we were able to identify the opportunities for system automation within the context of the business processes. The users are using these "business use cases" to develop their business procedures, while we extract and develop the system use cases. We plan to have them use the system use cases to develop their test cases and scenarios, to validate our functional design before we start any coding. Our biggest challenge right now with a usage centered approach is not the users. They love the methodology. Our challenge is getting Oracle developers who are very "data centric" to consider developing forms that focus on the users' tasks. The developers want to develop forms that are one-to-one with each data table, for example one form to create, update, and delete all the data in a single table. Even though our interaction spaces are role- and task-oriented and employ a WYSIWYN approach, I fear a single interaction space will end up being implemented as a number of screens, each one-to-one with a data table. If you have any words of wisdom or articles to read that will bring about a change in mindset, we would greatly appreciate it. A. I don't know about wisdom, but the problem is ever so familiar. It sounds like you have a good handle on the front-end of the process but may have problems with the handoff to development. In our experience, the design team has to fully specify each and every screen to the developers. That means layout, behavior, the works. The Oracle developers should not be left with the option of changing the design that you work out. One of the best ways to get developers in synch with the usage-centered design process is to involve one or more of them on the user interface design team. If they have been involved in the process of screen layout and interaction design, they are more likely to understand why things are the way they are and to respect and preserve the design. It also helps if developers understand basic usability. I'd give them Alan Cooper's _About Face_ or our book (Software for Use: http://www.amazon.com/exec/obidos/ASIN/0201924781/conslockltdsoftf), both of which have proved to be popular with developers. Q. SYSTEM-INITIATED EVENTS. We are also struggling with how to record both system-initiated events and user-initiated events to document the navigation from one interaction space to another. Your book conveniently separates these two types of events, but in enterprise applications you want to employ a combination of methods to navigate from one interaction space to another. For example, the users may desire a drop-down menu and an icon to navigate to the next interaction space. In other cases, it maybe useful to let the system automatically handle the navigation but also provide an icon for the user to navigate to the same place. How can you easily record both system- and user-initiated events on the navigation map without creating too much visual clutter on the map? A. There is no easy answer to this, because complexity is complexity. Ultimately, the visual complexity of the diagrams can only be managed with selectable views in a software tool that allows for showing user-initiated transitions, systems-initiated transitions, or both, as well as allowing selecting subsets of the contexts to be displayed. Barring that, we find that a matrix or tabular format for the navigation map can sometimes be helpful. In this form, you can scan across a row to see all the transitions out of an interaction context or down a column to see all the incoming ones. Color coding by type of transition helps, too. (Note that strictly system-initiated transitions are most likely to be asynchronous extensions on the system responsibility side of the task case, such as error messages. These should be kept as limited as possible, anyway.) Another issue is to what purpose you are documenting these. Who is the consumer of the resulting artifact? Is this map just "for the record" or is it to drive development or for analysis of usability or for user feedback and validation? Or what? As with any other analysis or design artifact for human use, the purpose often points to the best presentation. Users might do better with clearly labeled diagrams chopped up into modest sized chunks; developers might prefer the comprehensive clarity of a matrix. 3.
Do It Yourself =
= = = To unsubscribe, send email with the word "unsubscribe" (no quotes) in the subject and message to: <mailto:unsubscribe@foruse.com> |
||
| Subscribe! |
|
|
|
|
||