GUI Design
26-Jul-16
HMI design



There are entire college courses taught on HMI
(Human-Machine Interface) design
This is just a very brief presentation on some of the
most essential points
The goal is (usually) to make the design:




“Intuitive”--that is, it behaves as the user expects
Simple--not cluttered
Complete--that is, it lets the user do everything that the
program is capable of doing
From CIT591, day one: A program is elegant if it
combines power with simplicity
2
Different needs

Someone who uses the program only occasionally wants to be
able to figure out how to use it




Frequent users want to minimize effort



Few button clicks, little typing
No long sentences that must be read
You should know what audience you are designing for


Simple controls
Clear, descriptive labels
Help files
Compromises may be necessary, but with care you can design an
interface that isn’t too bad for either group
Nobody likes an interface that encourages mistakes
3
“Intuitive” design


An interface is intuitive if a new user grasps
immediately how to use it
It is impossible to make a very specialized task intuitive
to someone who doesn’t understand the underlying
principles



For example, 3D animation programs
Very few programs are of this nature
What is “intuitive” varies from person to person

However, most computer users have some common
expectations as to how common controls work
4
Principle of Least Surprise



The Principle of Least Surprise says that the GUI should
do the least surprising (= most expected) thing
Users have strong expectations about how GUI
elements, such as Buttons, work
Users also have strong expectations about how and
when files are opened and saved, and a host of other
things

Anything that we “take for granted” in an interface should not
be violated without very good reason
5
Passive GUI elements

When text is entered, it just sits there until the user does
something more--entering text does not cause something to
happen




For example, there may be an OK button to use the text
Exception: Very simple forms with only a text field may respond to the
Enter key (even if an OK button is present)
Checkboxes (squares) and radio buttons (circles) accept
information from the user but don’t take any actions
Selection lists (for example, to choose a language) accept
information but don’t themselves do anything with it

Exception: Lists that modify the view (such as the font or the alignment)
may have an immediate, visible effect
6
Active GUI elements

The most common active GUI element is the Button



When you click a button, you expect something to happen
Buttons that only make settings for future use should not be
Buttons
Menu items may be either active or passive


Menu items that are just settings should have a checkmark in
front of them when “turned on”
Menu items that change their labels (such as On or Off) are
just confusing


Does On mean the feature is on, or you have to click it to turn it on?
Menu items that open a dialog box to get more information
should end in an ellipsis (...), for example, Font...
7
Feedback

Everything the user does in a GUI should result in feedback as to
whether it worked



Example: Checkboxes get checked, radio buttons get “pushed,” typing
shows up in text areas, etc.
Clicking a button should either show the results, display a
message that the action occurred, start a “progress bar” going, or
pop up a dialog box that says what went wrong
Items that cannot be used at the moment should be made inactive
(so that they are visibly “grayed out”)


This also solves the problem of what to do if the user clicks on one—it
can’t happen
Items that cannot be used at the moment should not be removed, which
will cause the user to waste time looking for them
8
Minimize effort

One common measure of the effort required to do
something is “mouse clicks”


For example, if the user’s action is successful, provide
feedback, but don’t pop up a dialog box with a message
such as “Your file has been saved. [OK]”


Example: Compiling a program in BlueJ vs. Dr. Java
Many editors use an asterisk or dot next to the name of any
unsaved file
If the user’s action is not successful, make sure that the
feedback is highly visible

This is a good place to use a dialog box
9
Simple design

Windows that do everything are too cluttered to use
easily



For example, you should not put your preferences and your
working elements in the same window
One ambulance company used a single window for
maintenance information, keeping track of which employees
were on duty, and dispatching ambulances
Separate concerns—present windows that give the user
the right tools for what they are working on now
10
wGetGUI v1.0
11
FileMatrix
12
Progressive disclosure


Simple design does not mean less control
The Principle of Progressive Disclosure says to hide
complexity until it is needed

For example, look at the Preferences... menu on almost any
large program


You don’t see all the possible settings at once
Settings are grouped according to what the user is probably trying to
do—change the appearance, set security levels, etc.
13
User testing


Most important in GUI design, even for experienced
designers, is user testing
Have a classmate or friend try out your program




Watch as they do it
Do not tell them how to use it; let them figure it out
If your test user cannot figure something out, explain how to
do it; but make a note of the problem, and fix it
Even a minimal amount of user testing can greatly
improve the design
14
The End
15