Cortes L. - Designing a Graphical User Interface

7/28/2019 Cortes L. - Designing a Graphical User Interface

1/8

igning a Graphic User Interface http://www.medicalcomputingtoday.com/0agui.html

8 15.4.2005 8:54

Designing a Graphical User Interfaceby Leslie Cortes, MD

Clinical Information Engines

Austin, Texas

accepted for publication in Medical Computing TodayMay 1997

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

Whether you aspire to develop the next big software hit or simply create computerapplications 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. Iffunctionality 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 mostWindows 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


2/8


8 15.4.2005 8:54

(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. Eachwill 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 ofevent-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 DesignIn 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 constraintsimposed 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 computersto 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.


3/8


8 15.4.2005 8:54

2. Event-driven ProgrammingIn 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 procedure- and 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. Procedure- and 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 spreadsheetcalculations. 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 ManipulationsReal 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 bepulled, 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 inthe 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.


4/8


8 15.4.2005 8:54

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

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

1.

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

2.

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

3.

Provide adequate user feedback. Like the Consistency Principle, the Principle of User4.


5/8


8 15.4.2005 8:54

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.

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.

5.

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.

6.

Use sound, color, animation and multimedia clips sparingly. Sound, color, animationand 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 thesole 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 andindependent to the task of completing the tax forms.

7.

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; yourfull-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

8.


6/8


8 15.4.2005 8:54

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.

Avoid modal behaviors. Programs using modal behaviorforce 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.

9.

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.

10.

Following these 10 principles should help you create more effective, user-friendlyinterfaces 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 afew of these, too.


7/8


8 15.4.2005 8:54

Suggested ReadingThis 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 anexcellent 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 toHuman-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 GuidelinesApple 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


8/8


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.

Commentsadded at time of original publication by Marjorie Lazoff, MD

Medical EditorMedical Computing Today

Dr. Cortes' excellent article makes no reference to Alan Cooper, the "Father of Visual Basic"

and proponent ofcompletely 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 ofidiomatic 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-2002Medical Computing Today

E-mail Medical Computing Today's editororwebmaster.

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 fromMedical

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 ofMedical Computing Today, who may be reached by contacting:Editor,Medical Computing Today, e-mail:[email protected].

Cortes L. - Designing a Graphical User Interface

Documents

Transcript of Cortes L. - Designing a Graphical User Interface