Cortes L.Designing a graphical user interface.1997

Designing a Graphical User Interface

by Leslie Cortes, MD

Clinical Information Engines Austin, Texas

accepted for publication in Medical Computing Today May 1997

Sections

Design - Event-Driven - Affordance - Principles - Suggested Readings - Comments

Whether you aspire to develop the next big software hit or simply create computer

applications for your personal and office use, your applications will need effective user interfaces to fulfill their potential. Designing such an interface is part discipline (following platform conventions and good design principles), part science (usability testing) and part art (creating screen layouts that are informative, intuitive and visually pleasing).

Tax preparation software illustrates the principles behind effective user interfaces better than almost any other type of application. Tax preparation is a one-time task, practically all the users are new to the program, and none of them will want or have time to read a manual. Despite this, millions of taxpayers, including many barely computer literate ones, manage to prepare their own tax returns on home computers. How is this possible?

The answer: functionality and interface. If functionality is what a program actually does, then interface is how the user interacts with the program, perceives how the program does its work. Concealing the details of a complex technology behind a good task-oriented interface is not a new concept. One does not have to understand the inner workings of an automobile to drive one, or how an ICU monitor works to run a strip.

Although pure text interfaces are still appropriate for some applications, nowadays most

Windows and Mac programmers use the more popular and versatile graphical user interfaces (GUI). The hallmark of GUI programming lies in its graphical control features, such as toolbar buttons or icons. Unlike pure text interfaces which accept only keystroke commands, GUIs allow for a variety of input devices (such as a mouse or penlight) for the user to manipulate text and images as visually displayed. Web pages like this one employ a graphical interface, for example, by using image maps to help users navigate the site.

Visual Basic, Delphi and C++ are tools commonly used for GUI application development; you can also use Help and HTML processors, numerous database scripting tools, ToolBook, Hypercard, and many other products. All simplify the process of writing an application while

(this is critical) simultaneously creating its visual interface. Unless the programmer also devotes attention to this interface the software created may function well, but not be easy or pleasant to use.

In my experience, three main factors conspire against our creating successful GUIs. Each

will be elaborated on in turn: (1) we fail to shift from a problem-centered to a user-centered design process; (2) we fail to fully understand and exploit the power of event-driven programming; and (3) we ignore affordance, metaphors and manipulation. Further, we tend to overlook sound GUI design principles, 10 of which I've summarized below. This article closes with an annotated reading list of several favorite books and web sites, and an editor's note.

1. User-centered Design

In early days of computing, a good software program was one that worked. A great program was one that worked and expended the fewest computing resources. Creating a program was an engineering process, delivering a working solution given the programming constraints imposed by the last decade's computing environment. Computer programmers designed programs for use by other computer professionals and not the general public, so a generic interface permitting expeditious user input was the order of the day. The point of contact between the general population and the computer was not the software application but some output or printed report, such as a bank statement or lab results.

But in today's world, in which computer resources are abundant and computer users are usually non-programmers and computer neophytes, a good program is one that not only works but is also easy to learn. And a great program is one that works and is so user-friendly it does not even need to be learned! With this shift to non-programmers who need computers to perform many essential functions, the focus of software development has extended beyond the traditional problem-centered task to center upon these users' needs.

From a user's perspective, the secret behind successful software is that it makes sense. To create sensible software, user-centered designers involve users throughout the development process. Unlike problem-centered programming, which first and foremost focuses on the task, user-centered designers begin by observing how users confront present manual and automated methods. Their goal is to understand users' work tasks, their mental models of those tasks, and the tools already familiar to them. Programming can then incorporate selected task-solving behaviors. An important component of this process is repeated cycles of user testing and refinement prior to releasing the software.

Most clinician-developers do not have a staff of developers, professional designers and usability testers. In fact, most clinicians develop applications by and for themselves, or for a small target audience such as their office staff. For individual developers, is the distinction between a problem-centered versus user-centered design rhetorical? The answer depends on how much you enjoy training new staffers, undoing their mistakes, and answering questions that result from their not understanding how your programs work. If your goal is to write applications that even a new staffer can use correctly without much training or supervision, you might shift your software development approach from problem-centered to user-centered: critically evaluate and discuss how the tasks are presently performed, decide what aspects should be mirrored by the interface, program the tasks with that interface as part of the blueprint, then allow the future users to finalize your work with comments and suggestions.

2. Event-driven Programming

In procedure-driven programming, tasks are performed in a predictable ordered fashion, one step following the other. For example, in tax software, a procedure-driven program would advance the passive user from one line to the next and through all the tax forms in sequence. The user would enter data when directed and would be unable to jump to another section out of sequence, except as part of a pre-programmed menu. But GUI permits event-driven programming, and therein lies another part of its strength.

In event-driven programming, the user controls the program's tasks via GUI events -- entries using a keystroke, mouse click, pen light, voice command, joystick motion, etc. The variety of events a user can generate is set by the hardware and operating system. For example, if the computer has a single-button mouse, the user cannot perform a right mouse button click even if one is programmed into the software.

Both procedureand event-driven programming restrict the user's possible choices, but only the latter gives the user control over several task steps. Most tax programs today are event-driven, so the user may complete wizards, import financial information from another financial package, follow a user-appropriate predetermined order, or enter expert mode to manually select which form to next complete. Fields may be omitted; estimated amounts accepted to "guesstimate" payments or refunds; and output stored, printed or forwarded electronically to the IRS. Procedureand event-driven programming both arrive at the same calculations, but differ in how the user interacts with the program to create and process the output forms.

The best event-driven programming incorporates user-centered design, and the best of these emphasize the user's knowledge of the real world. As a developer, your programs will excel if you first understand your users' mental models, then create visual metaphors that they will find meaningful. In event-driven tax software the user is completing the familiar 1040 on screen while behind-the-scenes programming uses IRS tax algorithms with spreadsheet calculations. The user experiences a variety of ways to enter data on the tax form and the results of these calculations -- not the complex processes that produce them -- and so perceives the software as user-friendly and simple to use.

3. Affordances, Metaphors, and Manipulations

Real world objects have physical features, and some of those features lend themselves to human manipulation. The ways in which a particular object can be used are its affordances (afford = is for). A mouse button, for example, has one affordance: it can be depressed to produce a mouse button click. Its affordance is obvious; a button has no handle that can be pulled, so there isn't much chance a user would try to pull it.

The mouse itself, on the other hand, is an object with multiple affordances. While clearly fitting the human grasp it is not intuitively obvious that one must move it across a surface to perform its function -- a fact warmly portrayed by futuristic Star Fleet engineer Mr. Scott as he first encounters a 20th century mouse in Star Trek IV - The Voyage Home. The mouse is easy to use, but only after all its affordances have been taught or discovered.

Successful developers exploit a user's knowledge of the affordances of real world objects to create visually meaningful and intuitive environments by using metaphors and analogies. The Macintosh trash can is a classic example. To discard real documents we throw them in the trash. To recover something tossed into the trash, we empty the trash can and pick through its contents. Further, in the real world we deal with objects using direct manipulation. We do not ask a trash can to empty itself, but we pick it up and empty it. Direct manipulation environments are achievable with GUIs using metaphors and analogies.

Such design improves the user's interface dramatically, because they are more intuitively learned and retained than command environments, such as menus and buttons.

Study your users carefully. Look for metaphors that make sense to them. Create analogies to the affordances of the real world objects when it is helpful. Explore the direct manipulation techniques such as drag-and-drop mouse gestures that your platform supports. In this regard I find painting, drawing and image processing programs more illustrative (sic) than tax preparation software.

Ten Principles for Good GUI Design

1.The user must be able to anticipate a widget's behavior from its visual properties. Widgets in this context refer to visual controls such as buttons, menus, check boxes, scroll bars, and rulers. So let's call this the Principle of Consistency at the Widget Level. This principle stresses that every widget in your application should behave consistently. If one button responds to a single mouse click then every button should respond to a single click. In software development environments such as Delphi you can create your own widgets. If your application requires a new widget that behaves differently from a common or closely related widget, anticipate the confusion and give your new widget a distinctive appearance. Use metaphor affordances whenever possible to make your widget's appearance tell the user how that widget behaves.

2.The user must be able to anticipate the behavior of your program using knowledge gained from other programs. This is the Principle of Consistency at the Platform Level. Consistancy is important not only to visual elements like widgets but to abstractions such as mouse gestures, accelerator keys, placement of menus, and icons and toolbar glyphs. There are plenty of decisions regarding GUIs that are arbitrary and platform-specific. Obtain a good GUI application design guide for your target platform, and follow it. If you feel compelled to improve upon conventions, you will more than likely undo your "improvements" after users complain about them. If you are doing cross-platform development, maintain consistency with the host platform.

Maintaining consistency with the host platform trumps achieving consistency of your application across platforms. Your users will change applications on the same platform far more frequently than they will run your application on different platforms.

3.View every user warning and error dialog that your program generates as an opportunity to improve your interface. Good GUI interfaces rarely need or use warnings and error dialogs. Exceptions include those that signal hardware problems such as a disk failure or lost modem connection, or warnings that ask the user's permission to perform an irreversible and potentially erroneous step. Otherwise, error dialogs in GUI interfaces represent interface design flaws. Prevent, don't complain about, user errors. The most common flaws arise from improperly formatted user input and inappropriate task sequencing. Design your program interface to help your users enter appropriate data. If your program requires formatted data (dates, currency, alphanumeric only, or a particular numeric range) use bounded input widgets that appropriately limit the user's input choices. If a certain program step cannot be legitimately performed until your user completes other steps, disable the dependent step until all its dependencies are satisfied. Most GUI environments dim disabled widgets to signal that the widget cannot be selected. Use disabled widgets to limit user actions to those that are valid.

4.Provide adequate user feedback. Like the Consistency Principle, the Principle of User

Feedback applies to widgets and to program activity. Widgets often provide visual feedback; click a button, and it briefly suggests it has been depressed. Click a check box and its new appearance alerts the user it has been selected or deselected. If you create your own widgets, be sure to provide users with visual feedback for each affordance. User feedback at the program level requires that users know whether a step is in progress or completed. Change the cursor (the Mac wristwatch or the Window hourglass) to indicate brief delays, and use progress bars to indicate progress of longer tasks. Design every screen in your application so a novice user can easily tell what steps, especially critical steps, have been performed.

5.Create a safe environment for exploration. Humans are born explorers. Great interfaces invite and reward exploration, and offer the novice both the thrill of discovery and the satisfaction of unassisted accomplishment. Some interfaces encourage users to explore unfamiliar features, others do not. By allowing users to undo or redo, you encourage them to explore your application without fear of corrupting the database. Undo/Redo capabilities also eliminate the need for dialogs requesting permission to perform a seemingly erroneous function. A good interface makes a user feel competent, while poor interfaces leaves the same user feeling incompetent.

6.Strive to make your application self-evident. Good applications have comprehensive manuals and online help materials explaining program features and how to use them to solve real world problems. Great applications are those whose novice users rarely need to refer to the manuals or online help. The difference between good and great is often the degree to which the application and its interface are self-evident. From your choice of labels and widget captions to the arrangement of widgets on the screen, every interface design decision you make needs to be tested by users. Your goal is to create an interface that needs no explanation. A pharmacy management system interface need not be self-evident to a newspaper editor, but it should be to every pharmacist.

7.Use sound, color, animation and multimedia clips sparingly. Sound, color, animation and multimedia presentations are appropriate for education or entertainment, but effective use in other applications is difficult. Most platforms have written conventions that describe the appropriate use of sound, color and animation. Follow them, and remember never to use color or sound as the sole means of communicating with the user (many users are colorblind or hearing-impaired). Remember that these components must pass the same usability tests as all other application features: include them only if they improve your users' ability to accomplish tasks. Returning to our example, tax programs may use multimedia clips to extend the utility of the software as part of their online educational strategy, for interested users seeking added tax information. They are a software asset because these clips are under user control and independent to the task of completing the tax forms.

8.Help users customize and preserve their preferred work environment. If your application will be installed and operated by a single user, preserving the work environment may be as simple as creating a few registry entries such as the window's latest size and position. However, applications designed for multiple users or installed on different computers must address additional issues. Most common among these are video issues -- both hardware-specific involving the display (screen size, video resolution and color depth) and user-specific such as poor visual accommodation and acuity or colorblindness. Keep in mind that regardless of programming, the characteristics of the user's display will affect your application's appearance; your full-screen interface may look fine on a 14-inch VGA display, but will those 8-point Times-Roman labels and captions be legible on a 17-inch display at a resolution of 1152x864? One popular solution to any hardware irregularities or user preferences is to

permit the user to tailor the basic interface. Common user-tailored details include fonts, toolbar location and appearance, menu entries, and (especially important for users with impairments) color and sound. It is helpful to give users a way to choose among several predefined schemes, and always include a way to return to the default color or sound scheme. If multiple users take turns using your application at a single workstation, consider recording preferences as user-specific profiles rather than as a single description of the application's appearance the last time it was run.

9.Avoid modal behaviors. Programs using modal behavior force the user to perform tasks in a specific order or otherwise modify the user's expected responses. Modal behaviors generally feel uncomfortable to the user because they restrict more intuitive or natural responses, but if consciously and thoughtfully applied they can be used to advantage. For example, "Wizard" type tools simplify complex tasks by modal behavior. Warnings and error messages are also typically modal, forcing users to first address a critical issue before returning to the task. Modality in this latter context is necessary but interrupts the user's concentration and goal-oriented behavior, and so is another reason to avoid unnecessary warning and error messages (see Principles 3 and 5 above). The best modal behaviors are subtle but not hidden, and come forth naturally as a consequence of the metaphor.

In a typical painting program, for example, selecting a widget generally alters the subsequent function of the program and therefore results in modal behavior. Pick the brush widget, and you are ready to paint. Pick the letter stencil widget, and you type some text. Pick a shape widget, and you then draw that shape. This rarely causes confusion because the modal behavior is based on a real world analogy; we already know that by selecting a drawing instrument we are limiting the color, texture and line thickness that will appear on our paper. Good interfaces reveal the palette selection at a glance, and change the cursor to provide additional visual feedback once a selection is made.

So if your application absolutely requires modal behavior, bind that behavior to a strong metaphor and give your user visual feedback so the mode is natural and obvious.

10.Design your interface so that your users can accomplish their tasks while being minimally aware of the interface itself. We could call this the Principle of Transparency. Interface transparency occurs when the user's attention is drawn away from the interface and naturally directed at the task itself. It is the product of several factors, including a screen layout that puts both tools and information where the user expected them to be; icons and labels that are meaningful to the user; and metaphors (including gestures) that are easy for users to recognize, learn, remember, and perform. Choosing good metaphors and adhering to the above principles are an important start, but the most direct way to insure a transparent interface is to perform user testing throughout the program's creation.

Following these 10 principles should help you create more effective, user-friendly

interfaces while avoiding many design errors. Unfortunately, following sound design principles cannot alone guarantee success. It is entirely possible to create completely unworkable interfaces while strictly adhering to the rules. I know, because I have written a few of these, too.

Suggested Reading

This is my personal collection of background materials. It is not exhaustive and certainly omits many important works. But life is too short to read everything, and we must set aside some time to learn by doing!

Norman DA. The Design of Everyday Things 1988 Doubleday; ISBN 0-385-26774-6 Learn more about affordances, mental models and effective user interfaces. This is an excellent introduction to user-centered design. Norman's analysis of design errors covers topics ranging from door handles to airplane cockpits. The lessons are just as applicable to software development.

Tognazzini B. Tog on Interface1993 Addison-Wesley; ISBN 0-201-60842-1 Although this book is about the Apple Macintosh interface it addresses many design issues common to all GUIs. Most of the design principles in my column are addressed by Tog. This book is a "must read" for anyone who still thinks the command line interface is faster.

Mandel T. The GUI-OOUI War Windows vs. OS/2 - The Designer's Guide to Human-Computer Interfaces 1994 Van Nostrand Reinhold; ISBN 0-442-01750-2 There is a lot here -- some history, some design principles. There is a good discussion about guidelines being both a foundation and hindrance to good design. The book compares and contrasts the features, virtues and shortcomings of a variety of computer interfaces while focusing primarily on the essential differences between a graphical user interface (Windows) and an object-oriented user interface (OS/2). OOUI is similar to GUI but allows the user to interface with some types of data as if they were objects. Object manipulation simplifies such tasks as data entry and transfer between applications.

The Windows Interface - An Application Design Guide 1991 Microsoft Press; ISBN 1-55615-439-9

This is the Windows 3.x interface guide. The more recent Win95 version, The Windows Interface Guidelines for Software Design, is ISBN 1-55615-679-0.

Knudson R. User Interface Design Guidelines - A Brief Overview for Skiers and Applications Developers. The Information Management Group

This brief web page summarizes the important differences between the Windows 3.x and Win95 interfaces.

Macintosh Human Interface Guidelines Apple Computer

This is the complete online book of Mac-specific interface guidelines. In the context of the issues discussed in the preceding column, Chapter One on The Human Interface Design Principles is particularly relevant. This book is not only excellent reading but completely free!

NASA User-Interface Guidelines (Goddard Space Flight Center)

These are generic rather than platform-specific user interface guidelines. If my 10 design principles seem too general to satisfy your craving for detail, you need to read these. This 1996 book contains literally hundreds of admonitions and requirements for you to relish.

Miller RH.Web Interface Design: Learning from Our Past

Bell Communications

This short but thoughtful paper addresses interface design issues as they pertain to both web page layout and legacy software applications deployed across the web.

Comments

added at time of original publication by Marjorie Lazoff, MD

Medical Editor

Medical Computing Today

Dr. Cortes' excellent article makes no reference to Alan Cooper, the "Father of Visual Basic" and proponent of completely separating design from programming during software creation. He even recommends distinguishing software design from graphic design, as illustrated in Cooper's design test (and if he likes your answers he may offer you a job). Cooper's Goal Directed Design extends the concept of Dr. Cortes' user-centered design by challenging designers to use logic and creativity (rather than analyze users or employ user testing). Coincidently, Cooper used the same Star Trek sequence as did Dr. Cortes to explain his preference of idiomatic over metaphoric paradigms.

Articles by Cooper and others also contain information on his well-regarded 1995 paperback, "About Face." The Association for Software Design lists even more resources, in addition to software designers' articles, listserv messages, etc.

Comments or questions for posting?

of other articles

© Copyright 1997-2002 Medical Computing Today

E-mail Medical Computing Today's editor or webmaster.

Copyright: This article is copyright © Medical Computing Today and the individual author(s). Permission is granted for nonprofit purposes to download, print, and distribute material from Medical

Computing Today for educational purposes, provided that the material is not altered and that this copyright notice is included. No individual or corporation shall charge for this content, or include any of it in a larger document for which charges are levied, without the prior permission of Medical Computing Today, who may be reached by contacting: Editor, Medical Computing Today, e-mail:editor@medicalcomputingtoday.com.