User Interface
Designer
Many people consider the primary criterion for a good user interface to be the degree to which it is easy to learn. This is indeed a laudable quality of any user interface, but it is not necessarily the most important.
The goal of the user interface should be foremost in the design process. Consider the example of a visitor information system located on a kiosk. In this case it makes perfect sense that the primary goal for the interface designers should be ease of operation for the first-time user. The more the interface walks the user through the system step by step, the more successful the interface would be.
In contrast, consider a data entry system used daily by an office of heads-down operators. Here the primary goal should be that the operators can input as much information as possible as efficiently as possible. Once the users have learned how to use the interface, anything intended to make first-time use easier will only get in the way.
User interface design is not a "one size fits all" process. Every system has its own considerations and accompanying design goals. The Requirements Phase is designed to elicit from the design team the kind of information that should make these goals clear.
When the GUI first entered the market, it was heralded most of all for its use of metaphors. Careful consideration of what really made the GUI successful, however, would appear to indicate that the use of metaphors was actually a little further down in the list. Metaphors were really nothing new. The term computer "file" was chosen as a metaphor for a collection of separate but related items held in a single container. This term dates back to the very early days of computers.
The single most significant aspect of the GUI was the way in which it presented all possible options to the users rather than requiring them to memorize commands and enter them without error. This has nothing to do with metaphor and everything to do with focusing the user interface on the needs of the user rather than mandating that the user conform to the needs of the computer. The visual aspect of the GUI was also a tremendous advancement. People often confuse this visual presentation with pure metaphor, but closer inspection reveals that this is not necessarily the case. The "desktop" metaphor was the first thing to hit users of the GUI. Since it was a global metaphor and the small pictures of folders, documents, and diskettes played directly into it, people bought the entire interface as one big metaphor. But there are significant aspects of the GUI that have nothing to do with metaphor.
If someone says that a person "wants to have his cake and eat it too," we can intuit the meaning of the expression through its metaphoric content. The cake is a metaphor for that which we desire, and the expectation of both possessing it and consuming it is metaphoric for the assumption that acquisition of our desires comes at no cost. But if someone says that his pet turtle "croaked," it is not possible to intuit the meaning through the metaphoric content of the expression. The expression "croaked" is an idiom. We know instantly that the turtle didn't make a funny noise but rather that it died. The meaning of the idiom must be learned, but it is learned quickly and, once learned, retained indefinitely.
Most visual elements of the GUI are better thought of as idioms. A scroll bar, for example, is not a metaphor for anything in the physical world. It is an entirely new construct, yet it performs an obvious function, its operation is easily mastered, and users easily remember how it works. It is the visual aspect of the scroll bar that allow it to be learned so quickly. Users operate it with visual clues rather than remembering the keys for line up, line down, page up, page down, etc.
The use of metaphor can be helpful when it fits well into a situation, but it is not a panacea and is not guaranteed to add value. The use of icons as metaphors for functions is a good example. It can be a gamble if someone will understand the connection between an icon and the function. Anyone who has played Pictionary knows that the meaning of a picture is not always clear.
|
Consider the Microsoft Word 5.0 toolbar. Some icons area readily identifiable, some are not. The meaning of the identifiable icons will likely be gleaned from the icon, but is still not a guarantee. The unidentifiable icons, however, can be utterly perplexing, and rather than helping they can create confusion and frustration. And with so many pictographs crammed into such a small space, the whole thing reads like a row of enigmatic, ancient Egyptian hieroglyphs.
|
The Netscape toolbar, by contrast, can be considered to be much more graceful and useful. The buttons are a bit larger, which makes them generally more readable. Their added size also allows the inclusion of text labels indicating the command to which the icon corresponds. Once the meaning of each icon has become learned the icon can serve as a visual mnemonic, but until then the text label clearly and unambiguously relays the function the button will initiate.
The Netscape toolbar admittedly consumes more valuable window real estate than the Microsoft Word toolbar does. There are keystroke shortcuts for every button, however, and users who have mastered them can easily hide the toolbar from view. Users who prefer to use the toolbar are probably willing to sacrifice that small bit of real estate in order to have a toolbar that is presentable and easy to use.
One major pitfall into which metaphors can lead us is the "Global Metaphor," which is a metaphor that is intended to encompass an entire application. The "desktop" concept is an example of a global metaphor.
The global metaphor becomes a quagmire when reality begins to diverge from the metaphor. Consider carefully the desktop metaphor. It can be seen how it deviates from reality immediately. The trash can is a wonderful metaphor for the deletion function, but trash cans are generally not situated on the top of a desk.
The use of the trash can to eject a disk is a perfect example of contorting the metaphor to accommodate the divergence from reality. The expectation is that "trashing" a disk will delete its contents, yet the interface designers needed a way to eject a disk and the trash can came closer than anything else. Once learned it becomes an idiom that works fine, but it is initially counter-intuitive to the point that it is shocking.
The vertical aspect of the desktop also subverts the metaphor. It's closer to a refrigerator on which one can randomly place differently shaped magnets, or the old-fashioned displays on which TV weathermen placed various symbols. The fact that the desktop metaphor has to be explained to first-time users is an indication that it might not be terribly intuitive.
The global metaphor is an example of the "bigger is better" mentality. Metaphors are perceived as being useful, so some people assume that the more all-encompassing a metaphor is the more useful it will be. As in all other situations, the usefulness of a global metaphor is dictated by the overall goals of the interface. If the goal of the interface is to present a non-threatening face on a system that will be used primarily by non-technical first-time users, a global metaphor might be useful. But if the goal of the interface is to input large quantities of data quickly and effectively, a global interface might be an enormous hindrance.
While metaphors aren't always as useful as other solutions, it is important to note that in the right situation they can be a vital part of a quality user interface. The folder is a particularly useful and successful metaphor. Its purpose is immediately apparent, and by placing one folder inside another the user creates a naturally intuitive hierarchy. The counterpart in the character user interface is the directory/subdirectory construct. This has no clear correspondence to anything in the physical world, and many non-technical people have difficulty grasping the concept.
The bottom line is that if a metaphor works naturally, use it by all means. But at the first hint that the metaphor is not clearly understood or has to be contorted in order to accommodate reality, it should be strongly considered as to whether it will really help or not.
It is generally perceived that the most fundamental quality of any good user interface should be that it is intuitive. The problem is that "intuitive" means different things to different people. To some an intuitive user interface is one that users can figure out for themselves. There are some instances where this is helpful, but generally the didactic elements geared for the first-time user will hamper the effectiveness of intermediate or advanced users.
A much better definition of an intuitive user interface is one that is easy to learn. This does not mean that no instruction is required, but that it is minimal and that users can "pick it up" quickly and easily. First-time users might not intuit how to operate a scroll bar, but once it is explained they generally find it to be an intuitive idiom.
Icons, when clearly unambiguous, can help to make a user interface intuitive. But the user interface designer should never overlook the usefulness of good old-fashioned text labels. Icons depicting portrait or landscape orientation, for example, are clearly unambiguous and perhaps more intuitive than the labels themselves, but without the label of "orientation," they could make no sense at all.
|
Labels should be concise, cogent, and unambiguous. A good practice is to make labels conform to the terminology of the business that the application supports. This is a good way to pack a lot of meaning into a very few words.
Designing intuitive user interfaces is far more an art than a science. It draws more upon skills of psychology and cognitive reasoning than computer engineering or even graphic design. The process of Usability Testing, however, can assess the intuitiveness of a user interface in an objective manner. Designing an intuitive user interface is like playing a good game of tennis. Instructors can tell you how to do it, but it can only be achieved through hard work and practice with a lot of wins and losses on the way.
Consistency between applications is always good, but within an application it is essential. The standard GUI design elements go a long way to bring a level of consistency to every panel, but "look and feel" issues must be considered as well. The use of labels and icons must always be consistent. The same label or icon should always mean the same thing, and conversely the same thing should always be represented by the same label or icon.
In addition to consistency of labeling, objects should also be placed in a consistent manner. Consider the example of the Employee Essentials Address Update panels (available through Bear Access).
There is a different panel for every address that can be updated, each with its own set of fields to be displayed and modified. Note that each panel is clearly labeled, with the label appearing in the same location on every panel. A button bank appears in the same place along the left side of every panel. Some buttons must change to accommodate the needs of any given panel, but positionality was used consistently. The closer buttons are to the top the less likely they are to change, and the closer to the bottom the more likely.
|
Note especially the matrix of buttons at the top left corner of every panel. These buttons are the same in every panel of the entire Employee Essentials application. They are known as "permanent objects." Early navigators used stars and constellations as unchanging reference points around which they could plot their courses. Similarly, modern aviation navigators use stationary radar beacons. They know that wherever the plane is, they can count on the radar beacon always being in the same place.
User interface designers should always provide permanent objects as unchanging reference points around which the users can navigate. If they ever get lost or disoriented, they should be able to quickly find the permanent objects and from there get to where they need to be. On the Macintosh, the apple menu and applications menu are examples of permanent objects. No matter what application the user is in, those objects will appear on the screen.
Most all Macintosh applications provide "File" and "Edit" as the first two pull-down menus. The "File" menu generally has "New" "Open" "Close" "Save" and "Save As" as the first selections in the menu, and "Quit" as the last selection. The "Edit" menu generally has "Cut," "Copy," and "Paste" as the first selections. The ubiquity of these conventions has caused them to become permanent objects. The users can count on finding them in virtually all circumstances, and from there do what they need to do.
|
Bear Access itself is becoming a permanent object at Cornell. If a user is at an unfamiliar workstation, all he or she needs to do is locate Bear Access, and from there an extensive suite of applications will be available.
The complexity of computers and the information systems they support often causes us to overlook Occam's Razor, the principle that the most graceful solution to any problem is the one which is the most simple.
A good gauge of simplicity is often the number of panels that must be displayed and the number of mouse clicks or keystrokes that are required to accomplish a particular task. All of these should be minimized. The fewer things users have to see and do in order to get their work done, the happier and more effective they will be.
A good example of this is the way in which the user sets the document type in Microsoft Word version 5.0 as compared to version 4.0. In version 4.0, the user clicks a button on the save dialog that presents another panel in which there is a selection of radio buttons indicating all the valid file types. In version 5.0, there is simply a popup list on the save dialog. This requires fewer panels to be displayed and fewer mouse clicks to be made, and yet accomplishes exactly the same task.
A pitfall that should be avoided is "featuritis," providing an over-abundance of features that do not add value to the user interface. New tools that are available to developers allow all kinds of things to be done that weren't possible before, but it is important not to add features just because it's possible to do so. The indiscriminate inclusion of features can confuse the users and lead to "window pollution." Features should not be included on a user interface unless there is a compelling need for them and they add significant value to the application.
A fundamental tenet of graphic user interfaces is that it is preferable to prevent users from performing an inappropriate task in the first place rather than allowing the task to be performed and presenting a message afterwards saying that it couldn't be done. This is accomplished by disabling, or "graying out" certain elements under certain conditions.
Consider the average save dialog. A document can not be saved if it has not been given a name. Note how the Save button is disabled when the name field is blank, but is enabled when a name has been entered.
|
|
One of the advantages of graphic user interfaces is that with all the options plainly laid out for users, they are free to explore and discover things for themselves. But this requires that there always be a way out if they find themselves somewhere they realize the shouldn't be, and that special care is taken to make it particularly difficult to "shoot themselves in the foot." A good tip to keep users from inadvertently causing damage is to avoid the use of the Okay button in critical situations. It is much better to have button labels that clearly indicate the action that will be taken.
|
|
Consider the example when the user closes a document that contains changes that have not been saved. It can be very misleading to have a message that says "Continue without saving?" and a default button labeled "Okay." It is much better to have a dialog that says "Document has been changed" and a default button labeled "Save", with a "Don't save" button to allow the user not to save changes if that is, in fact, the desired action.
|
Likewise, it can be helpful in potentially dangerous situations to have the Cancel button be the default button so that it must be a deliberate action on the part of the user to execute the function. An example is a confirmation dialog when a record is being deleted.
Finally, it is important that a user interface be aesthetically pleasing. It is possible for a user interface to be intuitive, easy to use, and efficient and still not be terribly nice to look at. While aesthetics do not directly impact the effectiveness of a user interface, users will be happier and therefore more productive if they are presented with an attractive user interface.