GUI Design Principles - PowerPoint PPT Presentation

Loading...

PPT – GUI Design Principles PowerPoint presentation | free to download - id: 5cdcd1-M2Y5Y



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

GUI Design Principles

Description:

GUI Design Principles The User Interface Is Important User interface strongly affects perception of software Usable software sells better Unusable web sites ... – PowerPoint PPT presentation

Number of Views:21
Avg rating:3.0/5.0
Slides: 54
Provided by: Daniel716
Learn more at: http://web.info.uvt.ro
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: GUI Design Principles


1
GUI Design Principles
2
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

3
The Cost of Getting It Wrong
  • Users time isnt getting cheaper
  • Design it correctly now, or pay for it later
  • Disasters happen
  • Therac-25 radiation therapy machine
  • Aegis radar system in USS Vincennes

4
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 systems fault
  • but the user is not always right
  • Users arent designers

5
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

6
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
  • Well take an extreme position in this
    presentation

7
Usability Engineering Is a Process
8
Design
  • Task analysis
  • Know thy user
  • Design guidelines
  • Avoid bonehead mistakes
  • May be vague or contradictory

9
Implement
  • Prototyping
  • Cheap, throw-away implementations
  • Low-fidelity paper
  • Medium-fidelity HTML, Visual Basic
  • GUI implementation techniques
  • Input/output models
  • Toolkits
  • UI builders

10
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

11
Iterative Design
12
Help and Documentation
  • Users dont 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

13
Visibility of System Status
  • Keep user informed of system state
  • Cursor change
  • Selection highlight
  • Status bar
  • Dont overdo it
  • Response time
  • lt 0.1 s seems instantaneous
  • 0.1-1 s user notices, but no feedback needed
  • 1-5 s display busy cursor
  • gt 1-5 s display progress bar

14
Error Reporting, Diagnosis, Recovery
  • Be precise restate users 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

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

16
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

17
Basic Principle 2 Consider function first,
presentation later
  • does NOT mean design and implement the
    functionality first and worry about the UI
    later.
  • dont jump right into GUI layout
  • Develop a conceptual model

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

19
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

20
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 dont sweat edge cases

21
Basic Principle 5 Dont distract users from
their goals
  • Dont give users extra problems
  • Dont make users reason by elimination

22
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

23
Basic Principle 7 Deliver information, not
just data
  • Design displays carefully get professional help
  • The screen belongs to the user
  • Preserve display inertia

24
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
    isnt
  • 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
    dont want
  • allow users to judge how much time operations
    will take
  • do its best to let users set their own work
    pace.

25
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

26
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 doesnt 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 cant even guess from
    this interface.

27
Usability Example
  • Heres 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.

28
GUI Bloopers
  • GUI Control Bloopers
  • Navigation Bloopers
  • Textual Bloopers
  • Graphic Design and Layout Bloopers
  • Interaction Bloopers
  • Responsiveness Bloopers
  • Management Bloopers

29
GUI Control Bloopers
  • Blooper 1 Confusing checkboxes and radio buttons

30
Avoiding Blooper 1
31
Blooper 3 Using command buttons as toggles
32
Blooper 4 Using tabs as radio buttons
33
Blooper 5 Too many tabs
34
Avoiding Blooper 5
  • Keep the number of tabs small. If you have so
    many panels that their tabs wont 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

35
Avoiding Blooper 5
Never use dancing tabs
36
Blooper 6 Using input controls for display-only
data
37
Avoiding Blooper 6
38
Avoiding Blooper 6
39
Blooper 7 Overusing text fields for constrained
input
  • Alternatives to text fields

40
Blooper 8 Dynamic menus
41
Navigation Bloopers
  • successful navigation cues let people know
  • where they are,
  • where theyve been,
  • where they can go
  • whether the goal is near or far.

42
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
43
Textual Bloopers
44
Graphic Design and Layout Bloopers
45
Graphic Design and Layout Bloopers
46
Interaction Bloopers
  • Deviating from task focus
  • Requiring unnecessary steps
  • Burdening users memory
  • Taking control away from users

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

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

49
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 wont go to
    the effort of ordering them only to discover
    several steps later that they wasted their time.

50
Burdening users memory
51
Taking control away from users
52
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

53
References
Jeff Johnson - GU Bloopers 2.0. Common User
Interface Design Donts and Dos, Morgan Kaufmann
Publishers, 2008
About PowerShow.com