Human Machine Interface

Terminology
 You Can Call It Human Machine Interface
(HMI)
 • Or:
 - MMI (Man Machine Interface)
 - CHI (Computer Human Interaction)
 - HCI (Human Computer Interaction)
 - USI (User System Interface)
 - UI (User Interface)
 - HCC (Human Computer Communication)

 - OI (Operator Interface)
Human-Computer Interaction (HCI)
 Human
 the end-user of a software
 Computer
 the machine the software runs on
 Interaction
 the user tells the computer what they want
 the computer communicates results
Types of Interfaces

 Between software components

 Between software and external (non-human)
entities
 Between humans and software

Software quality is slowed down by the

frustration and anxiety caused by poorly-
designed interfaces
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 developed
 • Modifications to UI are difficult to make when the UI and the
application are tightly interwoven
 • Difficult to take advantage of new I/O technologies if they do not
match the current model

CIS 260 Software Engineering - I (R.

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

CIS 260 Software Engineering - I (R.

10:18 Akerkar) 6
AM
 Interface Design
Typical Design Errors
lack of consistency
too much memorization
no guidance / help
no context sensitivity
poor response
Arcane/unfriendly

CIS 260 Software Engineering - I (R.

10:18 Akerkar) 7
AM
 Golden Rules

 Place the user in control

 Reduce the user’s memory load

 Make the interface consistent

CIS 260 Software Engineering - I (R.

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

CIS 260 Software Engineering - I (R.

10:18 Akerkar) 9
AM
 Reduce the User’s Memory
LoadReduce demand on short-term memory.
Establish meaningful defaults.
Define shortcuts that are intuitive.
Disclose information in a progressive
fashion.

CIS 260 Software Engineering - I (R.

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

CIS 260 Software Engineering - I (R.

10:18 Akerkar) 11
AM
 User Interface Design
Models
 System perception — the user’s mental image 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, architectural, interface and
procedural representations of the software.

CIS 260 Software Engineering - I (R.

10:18 Akerkar) 12
AM
 User Interface Design
Process

CIS 260 Software Engineering - I (R.

10:18 Akerkar) 13
AM
The design
process

CIS 260 Software Engineering - I (R.

10:18 Akerkar) 14
AM
 Task Analysis and Modeling
 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

CIS 260 Software Engineering - I (R.

10:18 Akerkar) 15
AM
 Interface Design
Activities
1. Establish the goals and intentions for each task.
2. Map each goal/intention to a sequence of specific 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, i.e., what does the interface
likelook
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.

CIS 260 Software Engineering - I (R.

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

CIS 260 Software Engineering - I (R.

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

CIS 260 Software Engineering - I (R.

10:18 Akerkar) 18
AM
Some basic terminology of user interface
design
 Mode: A situation in which the UI restricts
what the user can do.
 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
finished, the following message will come
out.
 Encoding techniques. Ways of encoding
information so as to communicate it to the
user.

CIS 260 Software Engineering - I (R.

10:18 Akerkar) 19
AM
Usability
Principles
 Do not rely only on usability guidelines – always test
with 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.
 Ensure the user does not have to navigate anywhere to do
subsequent steps of a task.

CIS 260 Software Engineering - I (R.

10:18 Akerkar) 20
AM
Usability
Principles
 Ensure that the user always knows what he or she can
and should do 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 they navigate.
 When something goes wrong explain the situation in adequate
detail and help the user to resolve the problem.

CIS 260 Software Engineering - I (R.

10:18 Akerkar) 21
AM
Usability
Principles
 Ensure that the user can always get out, go back or undo
an 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.

CIS 260 Software Engineering - I (R.

10:18 Akerkar) 22
AM
Usability
Principles
 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 ’appearance is 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
disabilities.
 Ensure that the system is usable by both beginners and
experts.

CIS 260 Software Engineering - I (R.

10:18 Akerkar) 23
AM
Usability
Principles
 Provide all necessary help.
 Organize help well.
 Integrate help with the application.
 Ensure that the help is accurate.

 Be consistent.
 Use similar layouts and graphic designs
throughout your application.
 Follow look-and-feel standards.
 Consider mimicking other applications.

CIS 260 Software Engineering - I (R.

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

CIS 260 Software Engineering - I (R.

10:18 Akerkar) 25
AM
 Examples
of Bad
UI

CIS 260 Software Engineering - I (R.

10:18 Akerkar) 26
AM
 Examples of
Good UI

CIS 260 Software Engineering - I (R.

10:18 Akerkar) 27
AM
Evaluating User Interfaces
 Heuristic evaluation
1. Pick some use cases to evaluate.
2. For each window, page or dialog that appears
during the execution of the use case
 Study it in detail to look for possible usability defects.
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.

CIS 260 Software Engineering - I (R.

10:18 Akerkar) 28
AM
Evaluating User Interfaces
 Evaluation by observation of users
 Select users corresponding to each of the most important
actors
 Select the most important 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

CIS 260 Software Engineering - I (R.

10:18 Akerkar) 29
AM
Documentation

 System Documentation

 User Documentation

CIS 260 Software Engineering - I (R.

10:18 Akerkar) 30
AM
User Documentation
 A functional description:
 Explains what the system can do.
 A installation document:
 How to install the system and modify it from particular hardware
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 administrator’s guide:
 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.
CIS 260 Software Engineering - I (R.
10:18 Akerkar) 31
AM
The Document Production Process

CIS 260 Software Engineering - I (R.

10:18 Akerkar) 32
AM
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
boxes, use of mouse.
 Advantages: easy to learn to use, facilitates
switching between tasks (have different things
going in different windows), full screen
interaction.

CIS 260 Software Engineering - I (R.

10:18 Akerkar) 33
AM
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 future of
human-computer interfaces will focus on seamlessly 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, hands-free/heads-up systems, etc.

CIS 260 Software Engineering - I (R.

10:18 Akerkar) 34
AM
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 - Save, Acting
As Go, View, Create
 8 of 9 users were unable to
approve using this screen

CIS 260 Software Engineering - I (R.

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

CIS 260 Software Engineering - I (R.

10:18 Akerkar) 36
AM
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 elements missing
from the left nav (Nav is inconsistent
from page to page)
 Users repeated being "confused" by the
number of fields

CIS 260 Software Engineering - I (R.

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

CIS 260 Software Engineering - I (R.

10:18 Akerkar) 38
AM
Example 3
(before)
 Multiple windows open at one time
 Some Critical Task icons (e.g. quote) are
hidden below the open window
 Important information not front and
center
 Too many steps to complete the
Critical Tasks
 Too many tabs and unnecessary
fields
 0 of 9 sales people successfully created
an account using this product

CIS 260 Software Engineering - I (R.

10:18 Akerkar) 39
AM
Example 3
(After)
 No more than 2 windows open at one
time. Navigation is easy
 Information is grouped and easy to
find
 9 of 9 sales people successfully
created an account

CIS 260 Software Engineering - I (R.

10:18 Akerkar) 40
AM