UID anna univerrsity curriculum 2008

1. Jun 23, 2015
GUI Design

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

3. 3
Different needs
 Someone who uses the program only occasionally wants to be
able to figure out how to use it
 Simple controls
 Clear, descriptive labels
 Help files
 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
 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

4. 4
“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

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

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

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

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

9. 9
Minimize effort
 One common measure of the effort required to do
something is “mouse clicks”
 Example: Compiling a program in BlueJ vs. Dr. Java
 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]”
 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

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

11. 11
wGetGUI v1.0

12. 12
FileMatrix

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

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

15. 15
The End