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:

          o there is a change in the cursor to indicate what mode you are in, so it's harder to forget;

          o you only get into a mode by choosing a tool, so you know you've done it;

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