Transcript Human Computer Interface Design (HCI - Human Computer Interactions Alias MMI, Automation Boundary ©Ian Sommerville 2004 Software Engineering, 7th edition.

Human Computer Interface
Design
(HCI - Human Computer Interactions
Alias MMI, Automation Boundary
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 11
Slide
Interface Design
Easy to learn?
Easy to use?
Easy to understand?
THE OBJECTIVE
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 22
Slide
Objectives of GOOD HCI Design
Reduce Errors
Increase Safety
Improve Reliability
Improve Maintainability
Reduce Fatigue and Stress Increase Comfort
Reduce Boredom
Increase User Acceptance
Reduce loss of time
Increase Efficiency
Improve Information System Performance
Reduce Training Requirements
Reduce Personnel Requirements
Improve Working Environment
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 33
Slide
Interface Design
Typical Design Errors
lack of consistency
too much memorization
no guidance / help
no context sensitivity
poor response
Arcane/unfriendly
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 44
Slide
Golden Rules



Place the user in control
Reduce the user’s memory load
Make the interface consistent
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 55
Slide
Place the User in Control
Define interaction modes in a way that does not force a user
into unnecessary or undesired actions.
Provide for flexible interaction.
Allow user interaction to be interruptible and undoable.
Streamline interaction as skill levels advance and allow the
interaction to be customized.
Hide technical internals from the casual user.
Design for direct interaction with objects that appear on the
screen.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 66
Slide
Reduce the User’s Memory Load
Reduce demand on short-term memory.
Establish meaningful defaults.
Define shortcuts that are intuitive.
The visual layout of the interface should be based on a real
world metaphor.
Disclose information in a progressive fashion.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 77
Slide
Make the Interface Consistent
Allow the user to put the current task into a meaningful
context.
Maintain consistency across a family of applications.
If past interactive models have created user expectations,
do not make changes unless there is a compelling reason
to do so.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 88
Slide
Design Issues






©Ian Sommerville 2004
Response time
Help facilities
Error handling
Menu and command
labeling
Application accessibility
Internationalization
Software Engineering, 7th edition. Chapter 4
Slide 99
Slide
Practical Design Principles




Color
Layout
Typography
Other Considerations
•
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide
Slide 10
10
Design Principles
Color
Use Color to express is what you intended to
communicate.
Use backgrounds that are white or light colored.
Use colors in a consistent manner for all GUI’s
Use color sparingly. 5-7 colors plenty
Use color for a purpose other than ascetics
Be aware all monitors do not display colors the same.
•
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide
Slide 11
11
Design Principles

Color
Which is better?
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide
Slide 12
12
Design Principles

Layout
Group components by functional area.
Grids help the eyes to eliminate clutter
Keep screens simple
Make sure each component is useful to the user
Which is better?
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide
Slide 13
13
Design Principles

Typography
Keep type styles and faces consistent
Use limited styles and faces (5 to 7)
Use bold, italics and underline functions for
understanding
Chose fonts for legibility
Use blinking for drawing attention.
Which is better?
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide
Slide 14
14
Design Principles

Other Considerations
Be consistent
Be practical
Allow users to select components, colors, locations if
possible.
Do not rely solely on a mouse for navigation.
Which is better?
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide
Slide 15
15
Prototyping
Definition
• Prototyping is the process of
building a model of a system. In
terms of an information system,
prototypes are employed to help
system designers build an
information system that intuitive
and easy to manipulate for end
users.
Which is better?
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide
Slide 16
16
Prototyping
•
•
When is prototyping used?
Prototyping is an iterative process that is
generally used in the analysis workflow.
•
However, you can do a prototype for various
reasons. You might want to prototype the use of
a database management system (DBII, Oracle),
prototype the use of a session management tool
or other software that you may use.
•
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide
Slide 17
17
Prototyping
Advantages of Prototyping:
Reduces development time.
Reduces development costs.
Requires user involvement.
Developers receive quantifiable user feedback.
Helps implementation - users know expectations.
Results in higher user satisfaction.
Which is better?
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide
Slide 18
18
Prototyping
Disadvantages of Prototyping:
Can lead to insufficient analysis.
Users expect the performance of the ultimate system to
be the same as the prototype.
Developers can become too attached to their prototypes
Can cause systems to be left unfinished and/or
implemented before they are ready.
Sometimes leads to incomplete documentation.
If sophisticated software prototypes (4th GL or CASE
Tools) are employed, the time saving benefit of
prototyping can be lost.
Which is better?
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide
Slide 19
19
Prototyping
In the early 1980's, organizations used
prototyping approximately thirty percent
(30%) of the time in development projects.
In the early 1990's, its use had doubled to
sixty percent (60%).
The use of object-oriented technology
has slowed down this trend since
developers
are spending more of their
Which is better?
time on OO concerns.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide
Slide 20
20
Prototyping
When should I use prototyping?
When users are able to actively participate in the project.
When developers have prototyping experience or
training.
When users have be informed on the purpose of
prototyping.
When experimentation and learning are needed before
there can be full commitment to a project.
When cost is an issue for driving out requirements.
Which is better?
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide
Slide 21
21
Analysis and Prototyping
GOAL:
produce the most reasonable interface
within practical business constraints.
Which is better?
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide
Slide 22
22
Analysis and Prototyping
Benefits To Early Analysis And Prototyping Of GUIs
Keeps ultimate product vision in sight
Allows definition of base functionality
Helps scope out critical features
Makes management more committed
Helps to avoid misinterpretation or oversights
Allows clarification of details
Helps to develop release criteria
Aids to establish minimum and target goals
Which is better?
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide
Slide 23
23