Transcript GUI Design Principles - West University of Timișoara

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
–
Perform an objects/actions analysis - This specifies all the conceptual objects that an
–
Object relationships - Conceptual objects may be related to each other in several
–
Develop a lexicon - defining the terminology to be used throughout the software and its
–
Write task scenarios - developers can write use cases or task scenarios depicting people
–
Base UI design on the conceptual model - The user interface should be based on the
serves, the greater the chance that your intended conceptual model will be adopted by the users
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
ways
documentation
using the application, using only terminology from the conceptual model
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