Human Machine Interface Human Machine Interface Design G: R. Akerkar

Human Machine Interface
Design
g
R. Akerkar
CIS 260 Software Engineering - I (R.

10:18 AM Akerkar) 1
Terminology
 You Can Call It Human Machine Interface
(HMI)
 • Or:
 - MMI (Man Machine Interface)
 - CHI (Computer
(C t Human
H Interaction)
I t ti )
 - HCI (Human Computer Interaction)
 - USI (User System Interface)
 - UI (User Interface)
 - HCC (Human Computer Communication)
 - OI (O
(Operator
t Interface)
I t f )

10:18 AM Akerkar) 2
Human-Computer
Human Computer Interaction (HCI)
 Human
 the end-user of a software
 the others in the organization
 Computer
 the machine the software runs on
 Interaction
 the user tells the computer what they want
 the computer communicates results

10:18 AM Akerkar) 3
Human Machine Interface
 The Development of a Human Being’s Interaction with a Computer System
 • Multi-Disciplinary
 - Systems Engineering
 - System Architecture
 - HMI Software Design and Development
 - Human Factors Engineering
 - Cognitive Science
 - Artificial Intelligence
 - Others, e.g. Expert HMI
 • Multi-Phase ((All Phases of the software life-cycle)
y )
 - Proposal
 - Requirement
 - Design
 - Code
 - Integrate and Test
 - Install and Train
 - Operate and Maintain

10:18 AM Akerkar) 4
Why Study User Interfaces?
 Major
j p part of work for “real” p
programs
g
 approximately 50%
 You will work on “real” software

 intended for users other than yourself
 User interfaces are hard to get right

 people
l are unpredictable
di t bl

10:18 AM Akerkar) 5
Types of Interfaces
 Between software components

 Between software and external (non-human)
entities
 Between humans and software
Software quality is slowed down by the

f t ti and
frustration d anxiety
i t caused
d by
b poorly-
l
designed interfaces

10:18 AM Akerkar) 6
Problems with User Interfaces
 User Interface accounts for a large portion of life-cycle costs
 - application algorithms - 40%
 - dialogue management - 40%
 - presentation - 20%
 • UI development is extremely labor intensive
 • UI’s require frequent and extensive modifications due to not
understanding all interactions until the system is completely
p
developed
 • Modifications to UI are difficult to make when the UI and the
application are tightly interwoven
 • Difficult to take advantage
g of new I/O technologies
g if they
y do
not match the current model

10:18 AM Akerkar) 7
Interface Design
g
Easy to learn?
Easy to use?
Easy to understand?

10:18 AM Akerkar) 8
Interface Design
g
Typical Design Errors
lack of consistency
too much memorization
no guidance
id / help
h l
no context sensitivity
poor response
p p
Arcane/unfriendly

10:18 AM Akerkar) 9
Golden Rules
 Place the user in control

 Reduce the user’s memory load
 Make the interface consistent

10:18 AM Akerkar) 10
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.

Reduce the User’s Memoryy Load
Reduce demand on short
short--term memory.
Establish meaningful defaults.
Define shortcuts that are intuitive.
Disclose information in a progressive fashion.

Make the Interface Consistent
Allow the user to p
put the current task into a meaningful
g
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.

User Interface Design
g Models
 System
y perception
p p — the user’s mental imageg of what
the interface is.
 User model — a profile of all end users of the system.
 System image — the “presentation” of the system
projected by the complete interface.
 Design model — data,
data architectural,
architectural interface and
procedural representations of the software.

User Interface Design
g Process

The design process

Task Analysis
y and Modelingg
 All human tasks required to do the job (of the

interface) are defined and classified
 Objects (to be manipulated) and actions
(functions applied to objects) are identified for
each task
 Tasks are refined iteratively until the job is
completely defined

Interface Design
g Activities
1. Establish the goals and intentions for each task.
2 Map each goal/intention to a sequence of specific actions.
2. actions
3. Specify the action sequence of tasks and subtasks, also called a
user scenario, as it will be executed at the interface level.
4. Indicate the state of the system
4 system, ii.e.,
e what does the interface look
like at the time that a user scenario is performed?
5. Define control mechanisms, i.e., the objects and actions available
to the user to alter the system state.
6. Show how control mechanisms affect the state of the system.
7. Indicate how the user interprets the state of the system from
information provided through the interface.

Design Evaluation Cycle
preliminary
design
build
prototype #1
interface
build
prototype #n
interface
user
evaluate's
interface
design
modifications
are made
evaluation
is studied by
designer
Interface design
is complete

Some basic terminology of user interface
design
 Dialog: A specific window with which a user can interact
interact,
but which is not the main UI window.
 Control or Widget: Specific components of a user
i t f
interface.
 Affordance: The set of operations that the user can do at
anyy g
given p
point in time.
 State: At any stage in the dialog, the system is displaying
certain information in certain widgets, and has a certain
affordance.
affordance

Some basic terminology of user interface
design
 Mode: A situation in which the UI restricts
what
h t the
th user can do.d
 Modal dialog: A dialog in which the system
is in a very restrictive mode.
 Feedback: The response from the system
whenever the user does something, is
called feedback. For example, in the task
of changing the user password, when it’s
fi i h d the
finished, th following
f ll i message willill come
out.
 Encoding techniques. Ways of encoding
information so as to communicate it to the
user.

Usability Principles
 Do not rely only on usability guidelines – always test
with users.
users
 Usability guidelines have exceptions; you can only be
confident that a UI is good if you test it successfully with
users.
 Base UI designs on users’ tasks.
 Perform use case analysis to structure the UI.
 Ensure that the sequences of actions to achieve a
task are as simple as possible.
 Reduce the amount of reading and manipulation the user
has to do
do.
 Ensure the user does not have to navigate anywhere to do
subsequent steps of a task.

 Ensure that the user always knows what he or she
can and should do next
next.
 Ensure that the user can see what commands are available
and are not available.
 Make the most important commands stand out.
 Provide good feedback including effective error
messages.
 Inform users of the progress of operations and of their
location as theyy navigate.
g
 When something goes wrong explain the situation in
adequate detail and help the user to resolve the problem.

 Ensure that the user can always get out, go back or
undo an action
action.
 Ensure that all operations can be undone.
 Ensure it is easy to navigate back to where the user came
from.
 Ensure that response time is adequate.
 Users are very sensitive to slow response time
 They compare your system to others.
 Keep response time less than a second for most
operations.
 Warn users of longer delays and inform them of progress.

 Use understandable encoding techniques.
 Choose encoding techniques with care.
 Use labels to ensure all encoding techniques are fully
understood by users.
 Ensure that the UI’s
UI s appearance is uncluttered.
uncluttered
 Avoid displaying too much information.
 Organize the information effectively.
 Consider the needs of different groups of users.
 Accommodate people from different locales and people
with
ith disabilities.
di biliti
 Ensure that the system is usable by both beginners and
experts.

 Provide all necessary help.
 Organize
O i h help
l well.
ll
 Integrate help with the application.
 Ensure that the help is accurate
accurate.
 Be consistent.
consistent
 Use similar layouts and graphic designs
throughout your application.
 Follow look-and-feel standards.
 Consider mimicking other applications.

Some encoding techniques
 Text and fonts
 Icons
 Photographs
 Diagrams and abstract graphics
 Colours
 Grouping and bordering
 Music
 Spoken words
 Other sounds
 Animations and video
 Flashing

Examples
of Bad UI

Examples of
Good UI

Evaluating User Interfaces
 Heuristic evaluation
1. Pick some use cases to evaluate.
2. For each window, page or dialog that appears
d i th
during the execution
ti off th
the use case
 Study it in detail to look for possible usability defects.
3
3. When you discover a usability defect write down
the following information:
 A short description of the defect.
 Your ideas for how the defect might be fixed.

Evaluating User Interfaces
 Evaluation by observation of users
 Select users corresponding to each of the most important
actors
 Select the most important
p use cases
 Write sufficient instructions about each of the scenarios
 Arrange evaluation sessions with users
 Explain the purpose of the evaluation
 Preferably videotape each session
 Converse with the users as they are performing the tasks
 Take note of any difficulties experienced by the users
 Formulate recommended changes

Documentation
 System Documentation
 User Documentation

User Documentation
 A functional description:
 Explains
p what the system
y can do.
 A installation document:
 How to install the system and modify it from particular hardware
g
configuration.
 An introductory manual:
 How to get started with the system.
 A reference manual:
 Describes in detail all of the system facilities available to the user
and how these facilities can be used.
 A system
t administrator’s
d i i t t ’ guide:
id
 Explains how to react to situations which arise while the system
is in use and how to do housekeeping tasks such as making a
system backup
backup.
The Document Production Process

Graphical user interfaces (GUIs)
 GUIs are a long way from completely

replacing text/command based systems, but
are the most common form of interface these
days.
 Windows, icons, pull-down menus, dialog
b
boxes, use off mouse.
 Advantages: easy to learn to use, facilitates
switching between tasks (have different
things going in different windows), full screen
interaction.
Future interfaces
 In an ideal world one would not need to sit at a monitor and type
on a keyboard (or click mouse buttons) to use a computer. The
f t
future off human-computer
h t interfaces
i t f will
ill ffocus on seamlessly
l l
integrating computers into everyday life.
 In addition to the current common GUI and keyboard interfaces,
computerized systems will be able to react to
 touch and pressure
 movement (e.g. hand waving, a person's position in a room, the
direction a person is facing)
 speech
 There is already substantial interest and investment in virtual
reality "intelligent" clothing
reality, clothing, hands
hands-free/heads-up
free/heads up systems,
systems etc
etc.

Example 1 (Before)
 Poor Button Location
 Important Information not
prominently displayed
 Less important information
(Acting As GO) takes up
valuable real estate
 Confusing navigation to the
left and at the top
 Bad Language
Lang age - Save,
Sa e
Acting As Go, View, Create
 8 of 9 users were unable to
approve using this screen

Example 1 ( After)
 Appropriate Button Location
 Clear Language
 Important Information displayed at the
top
 Easy to use left-nav
left nav
 9 of 9 users successfully approved
using this screen

Example 2 (Before)
 Too many fields (60+ fields)
 Important information (fields that 80%
of users search by 80% of the time) is
not prominently displayed
 Useful navigational
g elements missing g
from the left nav (Nav is inconsistent
from page to page)
 Users repeated being "confused" by
the number of fields

Example 2 (After)
 Eliminated uneccessary fields
 Ability to search and browse by only
the useful fields
 Useful links in the left-nav

Example 3 (before)
 Multiple windows open at one time
 S
Some Critical
C iti l TTask
k iicons ((e.g. quote)
t )
are hidden below the open window
 Important information not front and
center
 T many steps
Too t to
t complete
l t theth
Critical Tasks
 Too many tabs and unnecessary fields
 0 of 9 sales people successfully
created
t d an accountt using
i thithis product
d t

Example 3 (After)
 No more than 2 windows open at one
ti
time. Navigation
N i ti iis easy
 Information is grouped and easy to
find
 9 of 9 sales p
people
p successfully
y
created an account


Human Machine Interface Human Machine Interface Design G: R. Akerkar

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Human Machine Interface Human Machine Interface Design G: R. Akerkar

Uploaded by

Copyright:

Available Formats

Human Machine Interface

CIS 260 Software Engineering - I (R.

CIS 260 Software Engineering - I (R.

CIS 260 Software Engineering - I (R.

CIS 260 Software Engineering - I (R.

 You will work on “real” software

 User interfaces are hard to get right

CIS 260 Software Engineering - I (R.

 Between software components

Software quality is slowed down by the

CIS 260 Software Engineering - I (R.

CIS 260 Software Engineering - I (R.

CIS 260 Software Engineering - I (R.

CIS 260 Software Engineering - I (R.

 Place the user in control

 Make the interface consistent

CIS 260 Software Engineering - I (R.

CIS 260 Software Engineering - I (R.

CIS 260 Software Engineering - I (R.

CIS 260 Software Engineering - I (R.

CIS 260 Software Engineering - I (R.

CIS 260 Software Engineering - I (R.

CIS 260 Software Engineering - I (R.

 All human tasks required to do the job (of the

CIS 260 Software Engineering - I (R.

CIS 260 Software Engineering - I (R.

CIS 260 Software Engineering - I (R.

CIS 260 Software Engineering - I (R.

CIS 260 Software Engineering - I (R.

CIS 260 Software Engineering - I (R.

CIS 260 Software Engineering - I (R.

CIS 260 Software Engineering - I (R.

CIS 260 Software Engineering - I (R.

CIS 260 Software Engineering - I (R.

CIS 260 Software Engineering - I (R.

CIS 260 Software Engineering - I (R.

CIS 260 Software Engineering - I (R.

CIS 260 Software Engineering - I (R.

CIS 260 Software Engineering - I (R.

CIS 260 Software Engineering - I (R.

CIS 260 Software Engineering - I (R.

 GUIs are a long way from completely

CIS 260 Software Engineering - I (R.

CIS 260 Software Engineering - I (R.

CIS 260 Software Engineering - I (R.

CIS 260 Software Engineering - I (R.

CIS 260 Software Engineering - I (R.

CIS 260 Software Engineering - I (R.

CIS 260 Software Engineering - I (R.

You might also like