************************************************************* * * * TASK-CENTERED USER INTERFACE DESIGN * * A Practical Introduction * * * * by Clayton Lewis and John Rieman * * * * Copyright 1993, 1994: Please see the * * "shareware notice" at the front of the book. * * * ************************************************************* * * * * * * * * * * * * * * * v.1 * * Chapter 3 * * Creating the Initial Design * * The foundation of good interface design is INTELLIGENT BORROWING. That is, you should be building your design on other people's good work rather than coming up with your own design ideas. Borrowing is important for three distinct reasons. First, given the level of quality of the best user interfaces today, it's unlikely that ideas you come up with will be as good as the best ideas you could borrow. Second, there's a good chance, if you borrow from the right sources, that many of your users will already understand interface features that you borrow, whereas they'd have to invest in learning about features you invent. Finally, borrowing can save you tremendous effort in design and implementation and often in maintenance as well. ============================================================ HyperTopic: "Won't I get sued if I follow your advice?" ------------------------------------------------------------ As you read through this chapter you'll realize that much of the borrowing we recommend is not only allowed, it's actually encouraged by the developers of the original system. Apple Computer, for example, provides style guides, software toolkits, and other support for developers who want to produce Macintosh programs that look and act similar to all the other Macintosh programs. In addition, there are a lot of other things you can copy without infringing on the rights of other companies. Unfortunately, there's no clear and simple rule that defines those rights. Appendix L gives an overview of the legal principles and provides a list of "boundary markers," examples of things that can and cannot be legally copied under the current laws. The development process we recommend is to keep those boundary markers in mind, rough out your interface, and then talk over your decisions with your company's attorney. If there's a central feature of the interface you're worried about, such as picking up an entire interface metaphor, you may want to get legal advice a little earlier. Because the law is always changing (and this area of law is especially unsettled) there are some other things you need to do. One is to read the trade journals and keep yourself abreast of the current state of the law. Another is that your business plans should take into account the possibility that, no matter how careful you are, you may become involved in a lawsuit. [end hypertopic]-------------------------------------------- ------------------------------------------------- 3.1 Working Within Existing Interface Frameworks ------------------------------------------------- The first borrowing you should do is to work within one of the existing user interface frameworks, such as Macintosh, Motif or Windows. The choice may have already been made for you: in in-house development your users may have PCs and already be using Windows, or in commercial development it may be obvious that the market you are trying to reach (you've already found out a lot about who's in the market, if you're following our advice) is UNIX-based. If you want to address several platforms and environments you should adopt a framework like XVT that has multi-environment support. The advantages of working in an existing framework are overwhelming, and you should think more than twice about participating in a project where you won't be using one. It's obvious that if users are already familiar with Windows there will be big gains for them if you go along. But there are also big advantages to you, as mentioned earlier. You'll get a STYLE GUIDE that describes the various interface features of the framework, such as menus, buttons, standard editable fields and the like. The style guide will also provide at least a little advice on how to map the interface requirements of your application onto these features, though the guides aren't an adequate source on this. This information saves you a tremendous amount of work: you can, and people in the old days often did, waste huge amounts of time designing scroll bars or ways to nest menus. Nowadays these things have been done for you, and better than you could do them yourself. You also get SOFTWARE TOOLS for implementing your design. Not only does the framework have an agreed design for menus and buttons, but it also will have code that implements these things for you. We'll discuss these implementation aids in a later chapter. ============================================================ HyperTopic: One-of-a-Kind Hardware ------------------------------------------------------------ "We can't use any of the existing frameworks because of our special hardware, which we have to use because of military specs/the customer's hardware base/ the new psychotelekinetic interaction device we're supporting." Make sure your schedule allows for the huge amount of extra work you are buying into, and make sure you are being paid enough. Also think about where your next job is coming from: the record of sustained success for onesy developments is not good, because of all the added costs. Try really hard to find a way to accommodate that psychotelekinetic device as an add- on to one of the standard environments. [end hypertopic]-------------------------------------------- ---------------------------------------- 3.2 Making Use of Existing Applications ---------------------------------------- The next copying you ought to do is to find good existing applications that already provide some of the functionality you need and plan to incorporate those applications into your system. Do users need some database capabilities, and some ability to do calculations of the data they are dealing with in your application? They almost always do. You will not be able to develop your own Dbase, or your own Excel, that will be nearly as good, or as powerful, as existing products that have been shaped by intense and extended competition in the commercial market. Even if you could you and your users are still behind: many of them already know how to use Excel, and they gain nothing by having to learn about your version of a spreadsheet instead. ============================================================ Example: Monte Carlo Modelling Systems ------------------------------------------------------------ Suppose you want to do financial projections, such as you might do with a spreadsheet, but you need to represent uncertainty in the numbers you use: next year's sales should be somewhere around $1.5M, but they could be as low as about $1M or as high as $2M. Costs should be around $1.2M, but they could be as high as $1.4M or as low as $1M. So what's the gross profit picture for next year? You could use a regular spreadsheet by running various what-if's with different numbers, but if you have a few more parameters that gets tedious and error-prone. And suppose you think that sales and costs are probably correlated? Monte Carlo simulation is a modelling technique that lets you specify statistical distributions for parameters, and correlations between them, and estimates the distribution for resulting quantities by sampling from the distributions you provide. Suppose you wanted to sell a Monte Carlo tool to the business world. You could try to build your own system from the ground up, but you'd be wrong. The right thing to do, as Crystal Ball and @Risk have done, is to build and sell a spreadsheet add-on. Modern spreadsheets, and the systems in which they run, permit fairly easy communication between the spreadsheet and your code. This is a huge win, for the following reasons: - The spreadsheet provides for you many functions which you would otherwise have to implement yourself, including data entry and specification of computations in the model. - It provides these functions in a form many users already understand. In fact the same add-on can be made to work with more than one of the popular spreadsheets, so users can choose whichever spreadsheet they already know most about. - The spreadsheet provides many functions that aren't part of what you HAVE TO do in your application but are significant enhancements that you get for nothing. For example, modern spreadsheets offer a wide range of graphical presentations of data. - Chances are users will want to transfer data between your package and their spreadsheet anyway. That'll be much easier with the add-on than if you build a separate package. - The spreadsheet can handle most if not all of the various environmental dependencies for you, such as drivers for various kinds of displays and printers. There is no way that you could afford to put as much coverage of environment options into your package as the spreadsheet developers, with their huge market, can afford to put in theirs. [end example]----------------------------------------------- ------------------------------------------------------ 3.3 Copying Interaction Techniques From Other Systems ------------------------------------------------------ Another kind of borrowing is copying specific interaction techniques from existing systems. If the style guides were good enough you might not have to do this, but the fact is the only way to get an adequate feel for how various interface features should be used, and how different kinds of information should be handled in an interface, is to look at what other applications are doing. The success of the Macintosh in developing a consistent interface style early in its life was based on the early release of a few programs whose interfaces served as models of good practice. An analogous consensus for the IBM PC doesn't really exist even today, but as it forms it is forming around prominent Windows applications like Excel or Word. It follows from the need to borrow from other applications that you can't be a good designer without becoming familiar with leading applications. You have to seek them out, use them, and analyze them. The key to "intelligent" borrowing, as contrasted with borrowing pure and simple, is knowing WHY things are done the way they are. If you know why an application used a tool palette rather than a menu of functions, then you have a chance of figuring out whether you want to have a palette or a menu. If you don't know why, you don't know whether the same or a different choice makes sense for you. Bill Atkinson's MacPaint program was one of the standard- setting early Macintosh programs, and it used a tool palette, a box on the side of the window containing icons. The icons on the palette stand for various functions like "enter text", "move view window", "draw a rectangle", and the like. Why was this a good design choice, rather than just listing these functions in a pull-down menu? In fact, some similar functions are listed in a pulldown menu called "goodies". So should you have a palette for what you are doing or not? Here are some of the considerations: * Operations on menus usually do not permit or require graphical specification of parameters, though they can require responding to queries presented in a dialog box. So an operation like "draw a rectangle", in which you would click on the corners of the intended rectangle, would be odd as a menu item. * A palette selection actually enters a MODE, a special state in which things happen differently, and keeps you there. This doesn't happen when you make a menu selection. For example, if you select the tool for drawing rectangles from a palette, your mouse clicks get interpreted as corners of rectangle until you get out of rectangle drawing mode. If you selected "draw a rectangle" from a menu, assuming the designer hadn't been worried about the point above, you'd expect to be able to draw just one rectangle, and you'd have to go back to the menu to draw another one. So a tool palette is appropriate when it's common to want to do a lot of one kind of thing rather than switching back and forth between different things. * Modes are generally considered bad. An example which influenced a lot of thinking was the arrangement of input and command modes in early text editors, some of which are still around. In one of these editors what you typed would be interpreted either as text to be included in your document, if you were in input mode, or as a command, if you were in command mode. There were two big problems. First, if you forgot what mode you were in you were in trouble. Something you intended as text, if typed in command mode, could cause the system to do something dreadful like erase your file. Second, even if you remembered what mode you were in, you had the bother of changing modes when you needed to switch between entering text and entering commands. * But modes controlled by a tool palette are considered OK because: - there is a change in the cursor to indicate what mode you are in, so it's harder to forget; - you only get into a mode by choosing a tool, so you know you've done it; - it's easy to get out of a mode by choosing another tool. * In a tool palette, tools are designated by icons, that is little pictures, whereas in menus the choices are indicated by text. There are two subissues here. First, for some operations, like drawing a rectangle, it's easy to come up with an easily interpretable and memorable icon, and for others it's not. So sometimes icons will be as good as or better than text, and sometimes not. Second, icons are squarish while text items are long and thin. This means icons PACK differently on the screen: you can have a bunch of icons close together for easy viewing and picking, while text items on a menu form a long column which can be hard to view and pick from. So... this tells you that you should use a tool palette in your application if you have operations that are often repeated consecutively, and you can think of good icons for them, and they require mouse interaction after the selection of the operation to specify fully what the operation does. Depending on the style guide you are using, you may or may not find a good, full discussion of matters like this. One of the places where experience will pay off the most for you, and where talking with more experienced designers will be most helpful, is working out this kind of rationale for the use of various interface features in different situations. ============================================================ HyperTopic: Some Kinds of Why's ------------------------------------------------------------ Analyzing the why's of interface features is complicated and detailed, as the example showed. But it's possible to identify some broad kinds of arguments that crop up often. * Geometrical and Movement Arguments * Small targets are harder (and slower) to hit with a mouse than big targets; long mouse movements are slower than short ones; icons pack differently from text strings; more keystrokes take longer to type; switching between mouse and keyboard is slow. * Memory Arguments * It is easier to recognize something when you see it (for example on a menu) than it is to recall it from scratch (for example in typing in a command); it is hard to remember much information from one step in a process to another (so, for example, having help information available at the same time as the user carries out an operation is a good idea; more generally, information that is used together should be presented together); the interface should present key information, such as the current mode, rather than requiring the user to remember it. * Problem-Solving Arguments * Interface features should help the user to select operations that are relevant to their goals, by labelling the operations in ways that match the way the user thinks about his or her task; the user needs to know what an operation has actually done (the UNIX approach of saying nothing unless something goes wrong is useless if you are a learner and do not already know what the commands do); users will make mistakes, especially if they are exploring options, so give them a way to back out. * Attention Arguments * Information presented with a big change in the display is more likely to be read; information presented close to where the user is looking is more likely to be read; auditory signals cannot be ignored as easily as visual signals (this is a two-edged sword; sometimes you want to be able to ignore things). * Convention arguments * If you do things the way your users are familiar with, they will be happier; conventional ways of using features have stood the test of time, but any innovation you make has not and thus may suffer from hard-to-anticipate problems. * Diversity Arguments * Different users have different preferences for interaction styles, and some users have physical limitations that make it difficult or impossible to use certain features. A blind user, for example, can work with textual menus using a device that translates on-screen text to audible speech, but graphical icons can't be translated by the device. A person with impaired motor control may be able to type but may not have the fine hand control needed to use the mouse, while a person with the use of only one hand might have problems with two-key combinations and prefer the mouse and pulldown menus. For all of these users, providing more than one access to a function may be essential. All of these statements are abstract. It can be hard to see how or whether they apply to a given design problem without some experience in applying them. Spend some time looking at a good interface and seeing if you can make sense of its features in terms of these ideas. [end hypertopic]-------------------------------------------- ============================================================ Example: Copying in the Traffic Modelling System. ------------------------------------------------------------ We did all of the above kinds of copying in the traffic modelling system. To begin with we incorporated a statistics package called S+ bodily: users needed to do statistical treatments and plots, and S+ already had implemented more than they would need. We were working in UNIX so it was fairly easy to run S+ as a separate process, send requests to it and bring back answers from it or have it present its output directly to users. We also adapted an existing package for diagram building called AgentSheets so that users could build their model in diagram form by pointing and clicking on graphical model elements. This was not a simple copy because AgentSheets needed to be extended slightly. AgentSheets is implemented in LISP, and we proposed to do other development in LISP, so we needed LISP-compatible software for other interface features that AgentSheets did not provide. We chose Garnet, a LISP-based user interface support package developed at Carnegie-Mellon University (CMU). Garnet is intended to provide very flexible support for people who want to create their own interface features, rather than adopting an existing framework like MOTIF. Since we didn't really need to create any new features it was not really a good choice for our purposes, but at the time we were doing the work we did not have LISP support for other options. Our experience with Garnet is a good example of the costs of not copying enough. We had to implement interface features in Garnet that would be provided as standard parts of a system like MOTIF today. (Of course this is not a reflection on Garnet but on us: we were trying to use it for purposes for which it was not intended. Garnet was and is a very powerful tool for exploring new interface techniques such as demonstrational interfaces.) Since Garnet was not intended to support any particular interface style it did not have a style guide. This was not a problem, because we simply copied stylistic features from other systems, especially the Macintosh. Our users (we knew exactly who they were) had no experience with ANY graphical user interface, so we considered ourselves free to use Mac- style interaction even though we were implementing on a UNIX platform. But this was probably a bad copying decision, which we would not have made had it been clearer at the time how much acceptance MOTIF would get. One of the ways designers today are fortunate is that these choices have become clearer. Against all of this background we could concentrate on a few areas of the design for which we did not find a clear precedent. One was allowing users to specify model inputs by typing in numbers or by designating a prepared file; another was how to control the execution of the model so as to explore various possible combinations of input values (recall the speed-limit study mentioned in the previous chapter); another was how to capture model results in a form that could be fed into further processing, so as to prepare a graph comparing results from different runs, for example. We didn't need to do anything very clever about these things. We represented data, whether model input or output, as graphical objects that could be connected to other model elements. These objects could be opened, exposing their contents for editing, and the opened object contained a file browser that could be used optionally to select a file from which values could be read or into which values could be placed for later use. Execution control was done by specifying input parameters and values to be used for them, along with other specifications of a run, in a dialog box. [end example]----------------------------------------------- ---------------------------- 3.4 When You Need to Invent ---------------------------- At some point in most projects you'll probably feel that you've done all the copying that you can, and that you've got design problems that really call for new solutions. Here are some things to do. * Think again about copying. Have you really beaten the bushes enough for precedents? Make another try at locating a system that does the kind of thing you need. Ask more people for leads and ideas. * Make sure the new feature is really important. Innovation is risky and expensive. It's just not worth it for a small refinement of your design. The new feature has to be central. * Apply the whole process of this book to the design. This means you can't expect to come up with a good innovation just by thinking about it, any more than you can come up with a good interface just by thinking about it. Be careful and concrete in specifying the requirements for the innovation, that is, the context in which it must work. Rough out some alternatives. Analyze them, as discussed in the next chapter. Then try them out with users, as discussed in the chapter after that. ============================================================ Example: Tog's One-or-more Button. ------------------------------------------------------------ Bruce Tognazzini has a great example of process of innovation in "Tog on Interface" (Reading, MA: Addison Wesley, 1992), a book you should read, especially, but not only, if you are a Mac person. He recounts the design of a kind of button that requires the user to turn on at least one of them. Repeated try-outs with users were completely crucial to success. [end example]----------------------------------------------- ============================================================ HyperTopic: The Good Old Days, When Designers Were Designers ------------------------------------------------------------ If you look at design case studies in the literature you are likely to be misled about what's involved in good design. Many of the most interesting case studies, such as those for the Xerox Star, come from a good while ago (Smith, D.C., Irby, C., Kimball, R., Verplank, W., and Harslem, E. "Designing the Star user Interface." Byte, 7:4 (April 1982), pp. 242-282). They tell you about designing something that was totally revolutionary in its day. Virtually every feature of the interface was an innovation, so virtually every feature was subjected individually to intensive design study including user testing. These studies tell you about the heroic age of design. But you are probably not creating something totally revolutionary. In fact, as we've been advising, you should be trying hard not to, in most situations. Even contemporary case study reports can be misleading. These reports usually focus on the innovations, because that's where the news and interest are. This means you don't really learn how to get your job done from these studies. [end hypertopic]-------------------------------------------- ------------------------------------------------------ 3.4 Graphic Design Principles ------------------------------------------------------ The graphic design of an interface involves decisions about issues such as where to put things on the screen, what size and font if type to use, and what colors will work best. For these questions as for other, more substantive design issues, intelligent borrowing should be your first approach. But that often leaves you with a lot of decisions still to be made. Here are a few principles of graphic design that will not only make your interface more attractive, but will also make it more usable. Each principle is accompanied by a description of WHY it's important, so you'll be able to consider the tradeoffs when there's a conflict between two principles or between a design principle and a borrowed technique. * The Clustering Principle: Organize the screen into visually separate blocks of similar controls, preferably with a title for each block. * "Controls," as we use the word here, include menus, dialog boxes, on-screen buttons, and any other graphic element that allows the user to interact with the computer. Modern WIMP (Windows-Icons-Menus-Pointer) systems are a natural expression of the Clustering Principle. Similar commands should be on the same menu, which places them in close proximity visually and gives them a single title. Large numbers of commands related to a given area of functionality may also show up in a dialog box, again a visually defined block. But the same principle should apply if you are designing a special control screen with many buttons or displays visible, perhaps a touch-screen interface. The buttons for a given function should be grouped together, then visually delineated by color, or a bounding box, or surrounding space ("white space"). The principle should also be applied within WIMP systems when you design a dialog box: If there is a subgroup of related functions, put them together in the box. There are two important reasons for the clustering principle. First, it helps users search for the command they need. If you're looking for the "Print setup" menu, it's easier to find if it's in a box or menu with the label "Printer" then if it's one of hundreds of command buttons randomly distributed on the top of the screen. Second, grouping commands together helps the user acquire a conceptual organization for facts about the program. It's useful to know, for example, that Bold, Italic, and Outline are all one kind of font modification, while Times Roman, Palatino, and Courier are another kind. (That distinction, common to most PC-based word processors, doesn't hold for many typesetting systems, where users have to acquire a different conceptual organization.) * The Visibility Reflects Usefulness Principle: Make frequently used controls obvious, visible, and easy to access; conversely, hide or shrink controls that are used less often. * This is a principle that WIMP systems implement with dialog boxes and, in many recent systems, with "toolbars" of icons for frequently used functions. The reasoning behind this principle is that users can quickly search a small set of controls, and if that set contains the most frequently used items, they'll be able to find and use those controls quickly. A more extended search, through dialog boxes, for example, is justified for controls that are used infrequently. * The Intelligent Consistency Principle: Use similar screens for similar functions. * This is similar to intelligent borrowing, but in this case you're borrowing from one part of your design and applying it to another part. The reasoning should be obvious: Once users learn where the controls are on one screen (the "Help" button, for example), they should be able to apply that knowledge to other screens within the same system. This approach lets you make a concentrated effort to design just a few attractive, workable screens, then modify those slightly for use in other parts of the application. Be careful to use consistency in a meaningful way, however. Screens shouldn't look alike if they actually do significantly different things. A critical error warning in a real-time system should produce a display that's very different from a help screen or an informational message. * The Color As a Supplement Principle: Don't rely on color to carry information; use it sparingly to emphasize information provided through other means. * Color is much easier to misuse than to use well. Different colors mean different things to different people, and that relationship varies greatly from culture to culture. Red, for example, means danger in the U.S., death in Egypt, and life in India. An additional problem is that some users can't distinguish colors: about 7 percent of all adults have some form of color vision deficiency. A good principle for most interfaces is to design them in black and white, make sure they are workable, then add minimal color to the final design. Color is certainly useful when a warning or informational message needs to stand out, but be sure to provide additional cues to users who can't perceive the color change. Unless you're an experienced graphic designer, minimal color is also the best design principle for producing an attractive interface. Try to stick with grays for most of the system, with a small amount of bright color in a logo or a label field to distinguish your product. Remember that many users can -- and frequently do -- revise the color of their windows, highlighting, and other system parameters. Build a product that will work with that user input, not one that fights it. * The Reduced Clutter Principle: Don't put "too much" on the screen. * This loosely defined principle is a good checkpoint to confirm that your design reflects the other principles listed above. If only the most highly used controls are visible, and if controls are grouped into a small number of visual clusters, and if you've used minimal color, then the screen should be graphically attractive. This is also a good principle to apply for issues that we haven't dealt with specifically. Type size and font, for example: the Reduced Clutter Principle would suggest that one or two type styles are sufficient. Don't try to distinguish each menu by its own font, or work with a large range of sizes. Users typically won't notice the distinction, but they will notice the clutter.