Principles of GUI Design

1
Principles of GUI Design

• Adapted from an online paper by James Hobart at
  http//axp16.iie.org.mx/Monitor/v01n03/ar_ihc2.htm
  

2
Overview

• Causes of bad design
• Good design principles (dos and donts)
• Applying design principles
• Standards

3
Causes of bad design

• Forgetting the user
• Limiting user control
• Too many features at the top level
• Too deep a path to most used features
• Focusing on the cool factor
• Inconstant style

4
Causes of bad design

• Forgetting the user
• Limiting user control
• Too many features at the top level
• Too deep a path to most used features
• Focusing on the cool factor
• Inconstant style

5
Forgetting the user

• Developers often design based on what they know
  not what the user knows

6
Causes of bad design

• Forgetting the user
• Limiting user control
• Too many features at the top level
• Too deep a path to most used features
• Focusing on the cool factor
• Inconstant style

7
Limiting user control

• Applications that attempt to control users
  actions by graying out components
• This is completely opposed to the event driven
  model
• If you are spending a lot of time disabling
  components based on application state, then you
  may have this problem

8
Causes of bad design

• Forgetting the user
• Limiting user control
• Too many features at the top level
• Too deep a path to most used features
• Focusing on the cool factor
• Inconstant style

9
Too many featuresat the top level

• In an unfamiliar setting, human anxiety increases
  with the number of options
• Look at a VCR made in 1985 and one made in 2000
• 1985 version has a ton of buttons on the front
  face
• 2000 version has only the most used buttons on
  the face but probably has more total features
• The more components on an interface the less
  information is available to the user

10
Causes of bad design

• Forgetting the user
• Limiting user control
• Too many features at the top level
• Too deep a path to most used features
• Focusing on the cool factor
• Inconstant style

11
Too deep a path to most used features

• Instead of putting all features at the front,
  some developers tend to go to the extreme in the
  other direction
• If the user has to navigate (click on) more than
  three elements to reach the feature they want,
  reorganization is necessary

12
Causes of bad design

• Forgetting the user
• Limiting user control
• Too many features at the top level
• Too deep a path to most used features
• Focusing on the cool factor
• Inconstant style

13
Focusing on the cool factor

• Related to forgetting about the user
• The developer has a great idea for a cool
  feature
• Unfortunately, the user couldnt care less about
  that feature
• Time spent creating the cool stuff is time not
  spent on creating the right stuff

14
Causes of bad design

• Forgetting the user
• Limiting user control
• Too many features at the top level
• Too deep a path to most used features
• Focusing on the cool factor
• Inconstant style

15
Inconstant style

• An application may be created by many developers
  each designing the interface portion for their
  area
• Each one has a different idea of what would be
  right for their area and all may be correct
• The user will get very confused and frustrated

16
Good GUIs

• More intuitive than character based counterparts
• Real-world metaphors
• Responsiveness
• Avoid repainting until necessary
• Validate fields on a screen basis not
  field-by-field
• Mnemonics, accelerator keys, and toolbar buttons
  with meaningful icons

17
Dos and Donts

• Tried and true principles to keep in mind
• Repeatable rules to follow

18
Understand People

• Applications must reflect the perspectives and
  behaviors of their users
• Developers need to understand the common
  characteristics between people
• People learn more easily by recognition than by
  recall
• Always attempt to provide a list of data values
  to select from rather than have the users key in
  values from memory
• The average person can recall about 2,000 to
  3,000 words yet can recognize more than 50,000
  words

19
Be Careful Of Different Perspectives

• Dont fall into the perspective trap when it
  comes to icon design or the overall behavior of
  the application
• Make sure that the metaphor you are using to
  design your application or icon is easily
  recognizable by the users

20
Design for Clarity

• A common complaint among users is that certain
  terms are not clear or consistent
• When the application is released, one screen may
  say "Item," while the next screen says "Product,"
  and a third says "Merchandise" when all three
  terms denote the same thing
• Develop and use a list of reserved words

21
Design for Clarity (cont.)
List of Reserved Words
22
Design for Consistency

• Good GUIs apply consistent behavior throughout
  the application and build upon a user's prior
  knowledge of other successful applications
• Think McDonalds

23
Provide Visual Feedback

• Most users like to have a message dialog box with
  a progress indicator displayed when operations
  are going to take longer than seven to ten
  seconds
• Error messages that are meaningful to users
• Animations during user-wait periods
• Every meaningful event instigated by the user
  should have some sort of feedback

24
Provide Audible Feedback

• Use audible feedback only when visual or other
  feedback modes are not available or appropriate
• In general, auditory feedback that is pervasive
  will become irritating to the user (and nearby
  coworkers) over time
• Give users the option of disabling standard
  (non-error) auditory feedback

25
Keep Text Clear

• Developers often try to make textual feedback
  clear by adding a lot of words
• Use concise wording of text labels, user error
  messages, and one-line help messages
• If possible, employ trained technical writers for
  this task

26
Provide Traceable Paths

• User I don't know how I got to this window, and
  now that I'm here, I don't know how to get out.
• Its not easy to provide a traceable path
• Start by creating an intuitive menu structure
• identify areas where you can flatten the menu
  structure
• avoid more than two levels of cascading menus
• A descriptive title bar within each dialog box

27
Provide Keyboard Support

• Keyboard accelerators can provide an efficient
  way for users to access specific menu items or
  controls within a window
• Easy to access
• Limited to one or two keys
• Some users MUST use the keyboard dont leave
  having only a mouse control

28
Watch the Presentation Model

• Look and feel must be consistent
• Identifying the appropriate presentation for the
  application will greatly facilitate the
  subsequent windows being developed since they
  will have a common framework in which to reside
• late changes to the look and feel of the
  application will be much more costly and
  time-consuming to fix

29
Modal vs. Modeless Dialogs

• Modal dialogs do not allow the user to interact
  with any other window
• Try to use modal dialogs when a finite task
  exists
• For tasks with no fixed duration, modeless
  dialogs will normally be preferable
• Try to keep the user working in no more than
  three modeless windows at any one time

30
Component Design

• Choosing the appropriate component for each user
  task will result in
• higher productivity
• lower error rates
• higher overall user satisfaction
• Keep the basic behavior and placement consistent

31
Component Design

• Guidelines for using components

32
An Example of a bad design

• Whats wrong with this GUI?

33
An Example of a bad design

• Too many functions at the top level

34
An Example of a bad design

• Too many buttons

35
An Example of a bad design

• Poor navigational assistance

36
An Example of a bad design

• Inappropriate use of controls

37
An Example of a bad design

• Lack of symmetry

38
The Redesigned GUI

• Order out of chaos

39
The Redesigned GUI

• Reordering input fields

40
The Redesigned GUI

• Improved controls

41
Implementing Effective Standards

• How do you get lots of programmers to use the
  same GUI standards?
• Define GUI standards that are easy to use, clear,
  and concise
• Provide them to developers in an online hypertext
  format
• Divide your standards into rules and
  recommendations