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 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.

Note: This chapter was copyrighted before the Web took off. One of the main reasons we're using html is its cross-platform 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 (Note: Like Front Page) 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 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 into theirs.

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 pull-down 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.

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.

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.