Lecture 23 Chapter 12 HumanComputer Interaction Cont. - PowerPoint PPT Presentation

Loading...

PPT – Lecture 23 Chapter 12 HumanComputer Interaction Cont. PowerPoint presentation | free to download - id: 8f8d0-YjMxN



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Lecture 23 Chapter 12 HumanComputer Interaction Cont.

Description:

1. Strive for Consistency ... Apple Macintosh was first to emphasize the benefits of consistency ... E.g. consistency in the menu bar for File, Edit and Format ... – PowerPoint PPT presentation

Number of Views:89
Avg rating:3.0/5.0
Slides: 32
Provided by: andreku
Learn more at: http://www.math.yorku.ca
Category:

less

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

Title: Lecture 23 Chapter 12 HumanComputer Interaction Cont.


1
Lecture 23Chapter 12 - Human-Computer
Interaction - Cont.
2
Document Metaphor
  • A metaphor of HCI in which interaction with the
    computer involves browsing and entering data on
    electronic documents
  • These documents are much like printed documents,
    but because they are in electronic form,
    additional functionality is available to make
    them more interactive
  • Hypertext
  • Documents that allow the user to click on a link
    and jump to a different part of the document or
    to another document
  • Hypermedia
  • Technology that extends the hypertext concepts to
    include multimedia content such as graphics,
    video and audio
  • World Wide Web is organized around document
    metaphor
  • Using HTML (hypertext markup language)
  • Based on document metaphor and browser interface

3
(No Transcript)
4
The Dialog Metaphor
  • A metaphor of HCI in which interacting with the
    computer is much like carrying on a conversation
    or dialog
  • User interface design is often referred to as
    dialog design
  • Carrying on a dialog means that each person is
    listening to and responding to questions and
    comments from the other, exchanging information
    in a sequence
  • The dialog metaphor is a way of thinking about
    HCI since the computer listens to and responds
    to questions or comments from the user, who
    listens to and responds to questions and
    comments from the computer
  • Like the direct manipulation metaphor, the dialog
    metaphor since communication involves messages
    from one object to another

5
(No Transcript)
6
Dialog metaphor (continued)
  • Example of a dialog between a manager and an
    assistant
  • Manager Did I get any messages while I was out?
  • Assistant Yes, you have three messages from
    Bob, Mary and Lim
  • Manager What did Lim have to say?
  • Assistant Lim left a message at 815 pm last
    night regarding the meeting next Monday about the
    inventory management system.
  • Manager I better respond. Say that the change
    is not a problem
  • Assistant Okay, Ill leave him that message. Do
    you want the next message?

7
  • The dialog on the previous slide involves
  • A question
  • A response
  • Another questions
  • A response that might include a request for
    clarification
  • Etc.
  • Not unlike a dialog you carry out with a computer
  • The assistant in the example could have been
    computer application running an intelligent
    assistant
  • Like an email application
  • The user selects a menu item (e.g. read new mail)
  • The computer lists the new mail messages
  • If the user selects one, the computer displays it
  • Etc.

8
  • The user and the computer both send messages
  • But each is forced to use a different language
  • The computer has to adapt to the user and provide
    its messages in a form that is natural to the
    user (text and graphics)
  • Similarly the computer cannot understand complex
    voice messages (although research in speech
    recognition is progressing)
  • Computer advances are improving things but the
    typical user interfaces today still rely on mouse
    and keyboard
  • Next slide shows the dialog between manager and
    assistant transformed into the languages used by
    the user and the computer
  • Interface designers use a variety of informal
    diagrams and written narratives to model
    human-computer interaction next slide is one
    example

9
(No Transcript)
10
Interface Design Guidelines
  • Many interface design guidelines have been
    published to help system developers
  • Range from general to very specific rules
  • System design standards
  • General principles and rules that must be
    followed for the interface of any system
    developed by the organization
  • Helps to ensure that all user interfaces are
    usable and all systems developed by the
    organization have a similar look and feel

11
Visibility and Affordance
  • Two key principles to ensure good human-computer
    interaction (Donald Norman)
  • Visibility
  • A key principle of HCI that states all controls
    should be visible (so users know its
    availability) and provide feedback to indicate
    the control is responding to the users actions
  • E.g. a button that can be clicked should be
    visible, and when it is clicked should look like
    it has been pressed to indicate it is responding
  • Affordance
  • A key principle of HCI that states that the
    appearance of any control should suggest its
    functionality
  • e.g. a button affords clicking, a scroll bar
    affords scrolling, an item in a list affords
    selecting etc.
  • Applies to objects on the desktop

12
Implications for designers
  • If designers make all controls visible and clear
    more likely the interface will be usable
  • Most users are now familiar with Windows user
    interface and common Windows controls
  • These principles should also be applied carefully
    to design of web pages, where there are new types
    of controls and possible designs of interfaces
    (not standardized)

13
Eight Golden Rules
  • Ben Shneiderman proposes eight underlying
    principles applicable to most interactive systems
    (and key to usability)
  • Strive for consistency
  • Enable frequent users to use short cuts
  • Offer informative feedback
  • Design dialogs to yield closure
  • Offer simple error handling
  • Permit easy reversal of actions
  • Support internal locus of control
  • Reduce short-term memory load

14
1. Strive for Consistency
  • Information arranged on forms, the names and
    arrangement of menus, the size and shape of icons
    etc. should be consistent throughout the system
  • This allows for many actions to become automatic
  • If a new application comes along with a different
    way of functioning have to relearn all the basic
    operations
  • Apple Macintosh was first to emphasize the
    benefits of consistency
  • Mac applications were consistent and a standards
    document was created for people writing Mac
    applications (so if you knew one you could figure
    out other applications easily since they were
    consistent)
  • E.g. consistency in the menu bar for File, Edit
    and Format
  • However some applications may not fit such
    guidelines and inconsistency may be useful for
    differentiating applications (for running and
    learning)

15
2. Enable Frequent Users to Use Short Cuts
  • Users who work with one application all the time
    are willing to invest time to learn short cuts
  • They begin to lose patience with long menu
    sequences when they know exactly what they want
    to do
  • Short-cut keys can reduce the number of
    interactions for a given task
  • Designers can provide macro facilities for users
    to create their own short cuts
  • E.g. mail order entry clerks at RMO wouldnt want
    long multiple menus to slow them down, but
    instead short-cuts would make them more productive

16
3. Offer Informative Feedback
  • Every action a user takes should result in some
    type of feedback from the computer
  • Eg. If the user clicks a button it should
    visually change and perhaps make a sound to
    indicate it has responded
  • Feedback of information to the user is also
    important
  • E.g. if a mail-order clerk enters a customer ID
    number in the screen, the computer should display
    the name and address for confirmation by the
    clerk
  • E.g. if the clerk enters a product ID for the
    order, the system should display a description of
    the product

17
4. Design Dialogs to Yield Closure
  • Each dialog with the system should be organized
    with a clear sequence (with a beginning and an
    end)
  • Reading ones email
  • If the system requirements are defined as events
    to which the system responds, each event leads to
    processing of one specific, well-defined activity
  • Traditional approach
  • Each activity is defined by data flow diagrams
    and structured English
  • Object-oriented approach
  • Each activity (a use case) might be further
    defined as multiple scenarios, each with a flow
    of events

18
5. Offer Simple Error Handling
  • Errors can be costly so designers must try to
    prevent users from making errors
  • Chief way is by limiting available options and
    allowing user to choose from valid options at any
    point in the dialog
  • Adequate feedback also reduces errors
  • When errors occur need ways to handle it
  • Error messages should state specifically what is
    wrong and explain how to create it
  • Avoid message that scare or blame the user
  • e.g. FATAL ERROR 2001
  • Also provide information that makes it easy to
    correct the error
  • e.g. The date of birth entered is not valid.
    Check to be sure only numeric characters in
    appropriate ranges are entered in the date of
    birth fields

19
6. Permit Easy Reversal of Actions
  • Users need to feel that they can explore options
    and take actions that can be canceled or reversed
    easily
  • Allows users to learn about the system by
    exploring
  • If they make a mistake, they can cancel the
    action
  • Should include cancel buttons on all dialog boxes
  • Also if user is going to delete something
    substantial (e.g. a file) the system should ask
    the user to confirm the action

20
7. Support Internal Locus of Control
  • Experienced users want to feel they are in charge
    of the system and the system responds to them
  • They should not be forced to do anything or made
    to feel the system is controlling them
  • Much of this comfort and control is provided by
    the wording of prompts and messages
  • Writing out a dialog (like example we saw) can
    help to lead to such a design

21
8. Reduce Short-Term Memory Load
  • People have short-term memory limitations
  • People remember only about seven chunks of
    information at a time
  • Interface designer cannot assume the user will
    remember anything from form to form, or dialog
    box to dialog box
  • If user has to stop and ask Now what was the
    filename? The customer ID? then the design is
    placing a burden on the users memory

22
Visibility and Affordance
  • Two key principles to ensure good human-computer
    interaction (Donald Norman)
  • Visibility
  • A key principle of HCI that states all controls
    should be visible (so users know its
    availability) and provide feedback to indicate
    the control is responding to the users actions
  • E.g. a button that can be clicked should be
    visible, and when it is clicked should look like
    it has been pressed to indicate it is responding
  • Affordance
  • A key principle of HCI that states that the
    appearance of any control should suggest its
    functionality
  • e.g. a button affords clicking, a scroll bar
    affords scrolling, an item in a list affords
    selecting etc.
  • Applies to objects on the desktop

23
Eight Golden Rules
  • Ben Shneiderman proposes eight underlying
    principles applicable to most interactive systems
    (and key to usability)
  • Strive for consistency
  • Enable frequent users to use short cuts
  • Offer informative feedback
  • Design dialogs to yield closure
  • Offer simple error handling
  • Permit easy reversal of actions
  • Support internal locus of control
  • Reduce short-term memory load

24
Application of Rules in Usability Engineering
  • Can use guidelines, like the rules above to
    create coding schemes for analyzing video tapes
    of users interacting with systems
  • Can also use them for usability inspection
  • Usability inspection involves walking through
    an interface to see if there are problems or
    things that could be improved
  • Usability inspector (analyst) conducts the
    walkthrough
  • For example, try stepping through a web site and
    evaluating (which allows direct customer
    ordering) in terms of the following (see the
    assignment)
  • Visibility
  • Affordance
  • The eight rules above
  • Can evaluate sites in terms of these criteria and
    note problems with the interface (and areas for
    improvement)

25
Documenting Dialog Designs
  • There are many techniques to help design dialogs
  • These are used to create a menu hierarchy
  • Allows the user to navigate each diaglog
  • Storyboards, protoypes and UML diagrams can be
    used to complete the design

26
Events, Subsystems and Menu Hierarchy
  • In chapter 11 we saw how inputs and outputs are
    obtained from data-flow diagrams (traditional
    approach)
  • Also saw how how inputs and outputs were obtained
    from sequence diagrams (OO approach)
  • Each input obtained interactively from a user
    requires a dialog design
  • Each output produced at the request of a user
    also requires a dialog design
  • Events documented early in analysis are key to
    listing needed dialogs (external events are
    triggered by inputs and temporal events produce
    outputs)

27
  • Dialog design must be done simultaneously with
    other design activities
  • Traditional approach
  • Structure charts for each subsystem (transaction
    analysis) includes details about menu structure
    of the interactive parts
  • Structure chart for each event (transform
    analysis of each DFD fragment) also includes
    details about the dialog
  • OO approach
  • Sequence diagrams and collaboration diagrams
    contain details about the dialog

28
Menu Hierarchy
  • From the standpoint of the user, the overall
    system structure is reflected in the menus
    available
  • Each menu contains a hierarchy of options, and
    they are arranged by sub-system or by actions on
    objects
  • RMO example includes
  • Order entry subsystem
  • Order fulfillment subsystem
  • Customer maintenance subsystem
  • Catalog maintenance subsystem
  • Reporting subsystem
  • Alternatively, menus could be arranged based not
    on subsystems but on objects
  • Customers
  • Orders
  • inventory, and shipments

29
Menus continued
  • Sometimes several versions of the menus are
    needed based on type of user
  • E.g. mail-order clerks at RMO do not need to know
    many of the options available since they only
    process new orders
  • Menus should also include options not in the
    event list
  • E.g. options related to controls (see Chapter 11)
  • Backup and recovery of databases
  • User account maintenance
  • User preferences are usually provided to allow
    the user to tailor the interface
  • Menus should always include help facilities
  • See next slide for the menu hierarchy for RMO
    customer support system

30
(No Transcript)
31
  • A dialog design is created for each menu option
    (e.g. for each menu option on previous slide)
  • After completing the dialog design for all
    options, the designer can define the structure of
    the menus for different types of users
  • Menu hierarchies can be rearranged easily as the
    design evolves
About PowerShow.com