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.
============================================================
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.
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.
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:
[end example]-----------------------------------------------
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:
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.
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.
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.
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.
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]-----------------------------------------------
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.
"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.)
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.
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.
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.
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.
SHAREWARE NOTICE -- PLEASE READ !
This HTML compilation contains the book:
The suggested shareware fee for the book is $5.00, payable to Clayton Lewis and John Rieman. Send it to:
Clayton Lewis and John Rieman
P.O.Box 1543
Boulder, CO 80306 USA.
If sending U.S. dollars is difficult, for example if you aren't in the U.S., send us something else you think we'd like to have. Or send us two somethings, one for each of us.
COPYRIGHT INFORMATION
This book is copyright 1993, 1994 by Clayton Lewis and John Rieman. You are free to make and distribute copies of the book in electronic or paper form, with the following restrictions: (1) We ask that you pay the shareware fee if you find the book useful and if you can afford it. (2) Every copy must include this "shareware notice." (3) Copies must be unchanged from the original. (4) No part of the book may be sold or included as part of a package for sale without the authors' written permission.
Original files for the book are available via anonymous ftp from ftp.cs.colorado.edu.
We thank you for your support!
Conversion to HTML by D. L. Kimbler, Department of Industrial Engineering, Clemson University, with permission.
This HTML version is subject to the same copyrights and shareware conditions of use as the original text version.
Table of Contents
IT Education | Career | Online & Offline Training | Certification | PM/SW Engineering | SDLC BookShelf | Webmastering | eCommerce
IT Security | Orgs
& Associations | For Consultants | For Women | Volunteer/Donate | Wares | Site
Map
IT TechnoSphere.Net, Education, Training and Learning Resources for IT Professionals