GUI Design Principles by malj

VIEWS: 16 PAGES: 53

									GUI Design Principles
   The User Interface Is Important

• User interface strongly affects
perception of software
  – Usable software sells better
  – Unusable web sites are abandoned
• Perception is sometimes superficial
  – Users blame themselves for UI failings
  – People who make buying decisions are not
  always end-users
  The Cost of Getting It Wrong

• Users’ time isn’t getting cheaper
• Design it correctly now, or pay for it later
• Disasters happen
– Therac-25 radiation therapy machine
– Aegis radar system in USS Vincennes
 User Interfaces Are Hard to Design

• You are not the user
  – Most software engineering is about
  communicating with other programmers
  – UI is about communicating with users
• The user is always right
  – Consistent problems are the system’s fault
• …but the user is not always right
  – Users aren’t designers
  User Interfaces are Hard to Build

• User interface takes a lot of software
development effort
• UI accounts for ~50% of:
  – Design time
  – Implementation time
  – Maintenance time
  – Code size
  Usability Is Only One Attribute of a System


• Software designers have a lot to worry about:
  – Functionality – Usability
  – Performance – Size
  – Cost – Reliability
  – Security – Standards

• Many design decisions involve tradeoffs among
  different attributes

• We’ll take an extreme position in this
  presentation
Usability Engineering Is a Process
                      Design

• Task analysis
  – “Know thy user”


• Design guidelines
  – Avoid bonehead mistakes
  – May be vague or contradictory
                 Implement

• Prototyping
  – Cheap, throw-away implementations
  – Low-fidelity: paper
  – Medium-fidelity: HTML, Visual Basic


• GUI implementation techniques
  – Input/output models
  – Toolkits
  – UI builders
                   Evaluate

• Evaluation puts prototypes to the test
• Expert evaluation
  –Heuristics and walkthroughs
• Predictive evaluation
  – Testing against an engineering model
(simulated user)
• Empirical evaluation
  –Watching users do it
Iterative Design
        Help and Documentation

• Users don’t read manuals
   – Prefer to spend time working toward their task goals, not learning
      about your system

• But manuals and online help are vital
   – Usually when user is frustrated or in crisis

• Help should be:
   – Searchable
   – Context-sensitive
   – Task-oriented
   – Concrete
   – Short
      Visibility of System Status

• Keep user informed of system state
   – Cursor change
   – Selection highlight
   – Status bar
   – Don’t overdo it…
• Response time
   – < 0.1 s: seems instantaneous
   – 0.1-1 s: user notices, but no feedback needed
   – 1-5 s: display busy cursor
   – > 1-5 s: display progress bar
     Error Reporting, Diagnosis, Recovery

• Be precise; restate user’s input
   – Not “Cannot open file”, but “Cannot open file named
      paper.doc”

• Give constructive help
   – why error occurred and how to fix it

• Be polite and nonblaming
   – Not “fatal error”, not “illegal”

• Hide technical details (stack trace) until requested
                    Usability

• The term “usable” means

  – it must do what the user wants (most important).

  – quick to use

  – relatively error-free.


  – easy to learn (least important).
                   Basic Principle #1:
Focus on the users and their tasks, not on the technology

• Understand the users

   –   Decide who the intended users are
   –   Investigate characteristics of the intended users
   –   Users: Not Just novice vs. experienced
   –   Collaborate with the intended users to learn about them

• Understand the tasks

   – Decide what set of tasks to support
   – Investigate the intended tasks
   – Collaborate with users to learn about the tasks

• Consider the context in which the software will
  function
             Basic Principle #2:
  Consider function first, presentation later


• does NOT mean “design and implement
  the functionality first and worry about
  the UI later.”

• don’t jump right into GUI layout

• Develop a conceptual model
             Basic Principle #2:
  Consider function first, presentation later
• Develop a conceptual model
   –   a conceptual model – a model of an application that the designers want users to
       understand (as simple as possible, the fewer concepts the better)

   –   Task focused - The more direct the mapping between the system’s operation and the tasks it
       serves, the greater the chance that your intended conceptual model will be adopted by the users

   –   Perform an objects/actions analysis - This specifies all the conceptual objects that an
       application will expose to users, the actions that users can perform on each object, the attributes
       (user visible settings) of each type of object, and the relationships between objects

   –   Object relationships - Conceptual objects may be related to each other in several
       ways

   –   Develop a lexicon - defining the terminology to be used throughout the software and its
       documentation

   –   Write task scenarios - developers can write use cases or task scenarios depicting people
       using the application, using only terminology from the conceptual model

   –   Base UI design on the conceptual model - The user interface should be based on the
       conceptual model. It translates the abstract concepts of the conceptual model into concrete
       presentations, controls, and user actions. Scenarios can then be rewritten at the level of the user
       interface design.
             Basic Principle #3:
    Conform to the users’ view of the task


• Strive for naturalness

• Use users’ vocabulary, not
  your own

• Keep program internals
  inside the program

• Find the correct point on
  the power/complexity
  trade-off
                   Basic Principle #4:
              Design for the common case

• Make common results easy to achieve

   – Two types of “common”: “how many users?” vs. “how often?”

   – The more frequently a feature will be used, the fewer clicks it should
     require

   – The more users will use a feature, the more visible it should be

   – Combinations: frequent by many, frequent by few, infrequent by many,
     infrequent by few

• Design for core cases; don’t sweat “edge” cases
              Basic Principle #5:
     Don’t distract users from their goals


• Don’t give users extra problems

• Don’t make users reason by elimination
                Basic Principle #6:
                Facilitate learning
• Think “outside-in,” not
  “inside-out”
     • Example: Textual ambiguity

     • Example: Ambiguous button
       label

     • Example: Graphical
       ambiguity

• Consistency, consistency,
  consistency

• Provide a low-risk
  environment
              Basic Principle #7:
      Deliver information, not just data


• Design displays carefully; get professional
  help

• The screen belongs to the user

• Preserve display inertia
                   Basic Principle #8:
                Design for responsiveness
• What is responsiveness?

• Designing for responsiveness

   ■ acknowledge user actions instantly, even if returning the answer will
      take time;

   ■ let users know when it is busy and when it isn’t;

   ■ free users to do other things while waiting for a function to finish;

   ■ animate movement smoothly and clearly;

   ■ allow users to abort lengthy operations they don’t want;

   ■ allow users to judge how much time operations will take;

   ■ do its best to let users set their own work pace.
               Basic Principle #9:
        Try it out on users, then fix it!

• Test results can
  surprise even
  experienced
  designers
• Schedule time to
  correct problems
  found by tests
• Testing has two
  goals: Informational
  and social
• There are tests for
  every time and
  purpose
Usability Example
          The first clue that there might
             be a problem here is the
             long help message on the
             left side. Why so much help
             for a simple selection task?
             Because the interface is
             bizarre! The scrollbar is used
             to select an award template.
             Each position on the
             scrollbar represents a
             template, and moving the
             scrollbar back and forth
             changes the template
             shown. This is a cute but bad
             use of a scrollbar. Notice
             that the scrollbar doesn’t
             have any marks on it. How
             many templates are there?
             How are they sorted? How
             far do you have to move the
             scrollbar to select the next
             one? You can’t even guess
             from this interface.
Usability Example
            • Here’s one way it might
              be redesigned. The
              templates now fill a list
              box on the left;
            • selecting a template
              shows its preview on
              the right. This interface
              suffers from none of the
            • problems of its
              predecessor: list boxes
              clearly afford selection
              to new or infrequent
              users;
            • random access is trivial
              for frequent users. And
              no help message is
              needed.
              GUI Bloopers

•   GUI Control Bloopers
•   Navigation Bloopers
•   Textual Bloopers
•   Graphic Design and Layout Bloopers
•   Interaction Bloopers
•   Responsiveness Bloopers
•   Management Bloopers
          GUI Control Bloopers
• Blooper 1: Confusing
  checkboxes and radio
  buttons
Avoiding Blooper 1
Blooper 3: Using command buttons as toggles
Blooper 4: Using tabs as radio buttons
Blooper 5: Too many tabs
                  Avoiding Blooper 5

•   Keep the number of tabs small. If you have so many panels that their tabs won’t fit
    into a single row, the real problem is that you have too many panels. Reorganize
    them into fewer panels, requiring fewer tabs.




     •   Use Another control instead of tabs
Avoiding Blooper 5

            Never use dancing tabs
Blooper 6: Using input controls for display-only
                     data
Avoiding Blooper 6
Avoiding Blooper 6
    Blooper 7: Overusing text fields for
            constrained input

• Alternatives to text fields
Blooper 8: Dynamic menus
           Navigation Bloopers

• successful navigation cues let people
  know:
  –   where they are,
  –   where they’ve been,
  –   where they can go
  –   whether the goal is near or far.
      Blooper 18: Too many levels of dialog boxes




The general rule is: Avoid more than two levels of dialog boxes. A dialog box
can bring up another one, but beyond that, users may lose their way
Textual Bloopers
Graphic Design and Layout Bloopers
Graphic Design and Layout Bloopers
        Interaction Bloopers

• Deviating from task focus

• Requiring unnecessary steps

• Burdening users’ memory

• Taking control away from users
       Deviating from task focus
• The first three interaction bloopers concern user interfaces that are
  poorly focused on the tasks the software is intended to support. Some UIs
  needlessly expose the implementation, impose unnecessary constraints, or
  present confusable concepts, distracting users from their goals and
  impeding their learning of the software.
    Requiring unnecessary steps

• A UI should be designed so that the most common tasks that the
  software is intended to support are quick and easy to do (Basic
  Principle 4). That means minimizing the steps required to do those
  tasks. If users have to do unnecessary steps to accomplish their
  tasks, that is a blooper. This section describes three such bloopers.
          Burdening users’ memory
•   If an employee of your company offered a customer choices that were not really available, the
    customer would consider the employee, and your company, to be either misinformed and
    incompetent or deliberately lying and untrustworthy. When your software lists “available”
    products or services, they must be available.
•   You can list out-of-stock items or booked-up dates so customers can see them, but they should
    be marked as unavailable so customers won’t go to the effort of ordering them only to discover
    several steps later that they wasted their time.
Burdening users’ memory
Taking control away from users
           Responsiveness Bloopers




•Responsiveness Principle 1: Responsiveness is not the same as performance
•Responsiveness Principle 2: Processing resources are always limited
•Responsiveness Principle 3: The user interface is a real-time interface
•Responsiveness Principle 4: All delays are not equal: software need not do everything immediately
•Responsiveness Principle 5: Software need not do tasks in the order in which they were requested
•Responsiveness Principle 7: Human users are not computer programs
                References

Jeff Johnson - GU Bloopers 2.0. Common User Interface
Design Don’ts and Dos, Morgan Kaufmann Publishers,
2008

								
To top