P.

Rajasekar
Asst.Professor
SRM University, Kattankulathur

School of Computing, Department of IT 8/22/2011 1

The contents of the slides are solely for the
purpose of teaching students at SRM
University. All copyrights and Trademarks of
organizations/persons apply even if not
specified explicitly.

School of Computing, Department of IT 8/22/2011 2

implementation support
 programming tools
 levels of services for programmers
 windowing systems
 core support for separate and simultaneous user-system
activity
 programming the application and control of
dialogue
 interaction toolkits
 bring programming closer to level of user perception
 user interface management systems
 controls relationship between presentation and
functionality
How does HCI affect of the programmer?

Advances in coding have elevated programming

hardware specific
 interaction-technique specific

Layers of development tools

 windowing systems
 interaction toolkits
 user interface management systems
Device independence
programming the abstract terminal device drivers
image models for output and (partially) input
 pixels
 PostScript (MacOS X, NextStep)
 Graphical Kernel System (GKS)
 Programmers' Hierarchical Interface to Graphics (PHIGS)
Resource sharing
achieving simultaneity of user tasks
window system supports independent processes
isolation of individual applications
three possible software architectures
 all assume device driver is separate
 differ in how multiple application management is
implemented

1. each application manages all processes

 everyone worries about synchronization
 reduces portability of applications

2. management role within kernel of operating system

 applications tied to operating system

3. management role as separate application

maximum portability
 pixel imaging model with some pointing
mechanism

 X protocol defines server-client communication

 separate window manager client enforces

policies for input/output:
 how to change input focus
 tiled vs. overlapping windows
 inter-client data transfer
repeat
read-event(myevent)
case myevent.type
type_1:
do type_1 processing
type_2:
do type_2 processing
...
type_n:
do type_n processing
end case
end repeat
void main(String[] args) {
Menu menu = new Menu();
menu.setOption(“Save”);
menu.setOption(“Quit”);
menu.setAction(“Save”,mySave)
menu.setAction(“Quit”,myQuit)
...
}

int mySave(Event e) {
// save the current file
}

int myQuit(Event e) {
// close down
}
 system style affects the interfaces
 modal dialogue box
 easy with event-loop (just have extra read-event loop)
 hard with notification (need lots of mode flags)
 non-modal dialogue box
 hard with event-loop (very complicated main loop)
 easy with notification (just add extra handler)

beware!
if you don’t explicitly design it will just happen
implementation should not drive design
Interaction objects
 input and output
intrinsically linked

move press release move

Toolkits provide this level of abstraction
 programming with interaction objects (or
 techniques, widgets, gadgets)
 promote consistency and generalizability
 through similar look and feel
 amenable to object-oriented programming
 Java toolkit – AWT (abstract windowing toolkit)

 Java classes for buttons, menus, etc.

 Notification based;
 AWT 1.0 – need to subclass basic widgets
 AWT 1.1 and beyond -– callback objects

 Swing toolkit
 built on top of AWT – higher level features
 uses MVC architecture (see later)
 UIMS add another level above toolkits
 toolkits too difficult for non-programmers

 concerns of UIMS
 conceptual architecture
 implementation techniques
 support infrastructure

 non-UIMS terms:
 UI development system (UIDS)
 UI development environment (UIDE)
 e.g. Visual Basic
 separation between application semantics and
presentation

 improves:
 portability – runs on different systems
 reusability – components reused cutting costs
 multiple interfaces – accessing same functionality
 customizability – by designer and user
 linguistic: lexical/syntactic/semantic

 Seeheim:
presentation dialogue application

 Arch/Slinky
dialogue
func. core
adaptor lexical

functional
core physical
 lexical syntactic semantic

Functionality
Dialogue
USER
USER Presentation (application APPLICATION
Control
interface)

switch
Seeheim
 arose out of implementation experience
 but principal contribution is conceptual
 concepts part of ‘normal’ UI language

… because of Seeheim …
… we think differently!

e.g. the lower box, the switch

 needed for implementation
 but not conceptual presentation dialogue application
 different kinds of feedback:
 lexical – movement of mouse
 syntactic – menu highlights
 semantic – sum of numbers changes

 semantic feedback often slower

 use rapid lexical/syntactic feedback

 but may need rapid semantic feedback

 freehand drawing
 highlight trash can or folder when file dragged
 Lexical Syntactic Semantic

Application
Dialogue
USER Presentation Interface APPLICATION
Control
Model
 Lexical Syntactic Semantic

Application
Dialogue
USER Presentation Interface APPLICATION
Control
Model

direct communication
between application
rapid semantic and presentation
feedback but regulated by
dialogue control
 dialogue
func. core
adaptor lexical

functional
core physical
 more layers! – distinguishes lexical/physical
 like a ‘slinky’ spring different layers may be
thicker (more important) in different systems
 or in different components

dialogue
func. core
adaptor lexical

functional
core physical
 Seeheim has big components

 often easier to use smaller ones

 esp. if using object-oriented toolkits

 Smalltalk used MVC – model–view–controller

 model – internal logical state of component
 view – how it is rendered on screen
 controller – processes user input
 view

model

controller
 MVC is largely pipeline model:
input  control  model  view  output
 but in graphical interface
 input only has meaning in relation to output
e.g. mouse click
 need to know what was clicked
 controller has to decide what to do with click
 but view knows what is shown where!

 in practice controller ‘talks’ to view

 separation not complete
 PAC model closer to Seeheim
 abstraction – logical state of component
 presentation – manages input and output
 control – mediates between them

 manages hierarchy and multiple views

 control part of PAC objects communicate

 PAC cleaner in many ways …

but MVC used more in practice
(e.g. Java Swing)
 A P A P
C C

abstraction presentation

control

A P
C A P
C
 Techniques for dialogue controller
• menu networks • state transition diagrams
• grammar notations • event languages
• declarative languages • constraints
• graphical specification

 for most of these see chapter 16

 N.B. constraints
 instead of what happens say what should be true
 used in groupware as well as single user interfaces
(ALV - abstraction–link–view)

see chapter 16 for more details on several of these

 what it is
 draw components on screen
 set actions with script or links to program

 in use
 with raw programming most popular technique
 e.g. Visual Basic, Dreamweaver, Flash

 local vs. global

 hard to ‘see’ the paths through system
 focus on what can be seen on one screen
 internal control
(e.g., read-evaluation loop)

 external control
(independent of application semantics or presentation)

 presentation control
(e.g., graphical specification)
Levels of programming support tools
 Windowing systems
 device independence
 multiple tasks

 Paradigms for programming the application

 read-evaluation loop
 notification-based

 Toolkits
 programming interaction objects
 UIMS
 conceptual architectures for separation
 techniques for expressing dialogue
evaluation techniques
 Evaluation
 tests usability and functionality of system
 occurs in laboratory, field and/or in collaboration with
users
 evaluates both design and implementation
 should be considered at all stages in the design life cycle
 assess extent of system functionality

 assess effect of interface on user

 identify specific problems

 Cognitive Walkthrough
Heuristic Evaluation
Review-based evaluation
Proposed by Polson et al.
 evaluates design on how well it supports user in
learning task
 usually performed by expert in cognitive
psychology
 expert ‘walks though’ design to identify potential
problems using psychological principles
 forms used to guide analysis
 For each task walkthrough considers
 what impact will interaction have on user?
 what cognitive processes are required?
 what learning problems may occur?

 Analysis focuses on goals and knowledge:

does the design lead the user to generate the
correct goals?
 Proposed by Nielsen and Molich.

 usability criteria (heuristics) are identified

 design examined by experts to see if these are
violated

 Example heuristics
 system behaviour is predictable
 system behaviour is consistent
 feedback is provided

 Heuristic evaluation `debugs' design.

 Results from the literature used to support or
refute parts of design.

 Care needed to ensure results are transferable to

new design.

 Model-based evaluation

 Cognitive models used to filter design options

e.g. GOMS prediction of user performance.

 Design rationale can also provide useful

evaluation information
 Advantages:
 specialist equipment available
 uninterrupted environment

 Disadvantages:
 lack of context
 difficult to observe several users cooperating

 Appropriate
 if system location is dangerous or impractical for
constrained single user systems to allow controlled
manipulation of use
 Advantages:
 natural environment
 context retained (though observation may alter it)
 longitudinal studies possible

 Disadvantages:
 distractions
 noise

 Appropriate
 where context is crucial for longitudinal studies
Requires an artefact:
simulation, prototype,
full implementation
 controlled evaluation of specific aspects of
interactive behaviour
 evaluator chooses hypothesis to be tested
 a number of experimental conditions are
considered which differ only in the value of some
controlled variable.
 changes in behavioural measure are attributed to
different conditions
 Subjects
 who – representative, sufficient sample
 Variables
 things to modify and measure
 Hypothesis
 what you’d like to show
 Experimental design
 how you are going to do it
 independent variable (IV)
characteristic changed to produce different conditions
e.g. interface style, number of menu items

 dependent variable (DV)

characteristics measured in the experiment
e.g. time taken, number of errors.
 prediction of outcome
 framed in terms of IV and DV

e.g. “error rate will increase as font size decreases”

 null hypothesis:
 states no difference between conditions
 aim is to disprove this

e.g. null hyp. = “no change with font size”

 within groups design
 each subject performs experiment under each condition.
 transfer of learning possible
 less costly and less likely to suffer from user variation.
 between groups design
 each subject performs under only one condition
 no transfer of learning
 more users required
 variation can bias results.
 Before you start to do any statistics:
 look at data
 save original data

 Choice of statistical technique depends on

 type of data
 information required

 Type of data
 discrete - finite number of values
 continuous - any value
 parametric
 assume normal distribution
 robust
 powerful

 non-parametric
 do not assume normal distribution
 less powerful
 more reliable

 contingency table
 classify data by discrete attributes
 count number of data items in each group
 What information is required?
 isthere a difference?
 how big is the difference?
 how accurate is the estimate?

 Parametric and non-parametric tests mainly

address first of these
More difficult than single-user experiments

Problems with:
 subject groups
 choice of task
 data gathering
 analysis
larger number of subjects
 more expensive

longer time to `settle down’

… even more variation!

difficult to timetable

so … often only three or four groups

must encourage cooperation

perhaps involve multiple channels

options:
 creative task e.g. ‘write a short report on …’
 decision games e.g. desert survival task
 control task e.g. ARKola bottling plant
several video cameras
+ direct logging of application

problems:
 synchronisation
 sheer volume!

one solution:
 record from each perspective
N.B. vast variation between groups

solutions:
 within groups experiments
 micro-analysis (e.g., gaps in speech)
 anecdotal and qualitative analysis

look at interactions between group and media

controlled experiments may `waste' resources!

Experiments dominated by group formation

Field studies more realistic:

distributed cognition  work studied in context
real action is situated action
physical and social environment both crucial

Contrast:
psychology – controlled experiment
sociology and anthropology – open study and rich data
 Think Aloud
Cooperative evaluation
Protocol analysis
Automated analysis
Post-task walkthroughs
 user observed performing task
 user asked to describe what he is doing and why,
what he thinks is happening etc.

 Advantages
 simplicity - requires little expertise
 can provide useful insight
 can show how system is actually use
 Disadvantages
 subjective
 selective
 act of describing may alter task performance
 variation on think aloud
 user collaborates in evaluation
 both user and evaluator can ask each other
questions throughout

 Additional advantages
 less constrained and easier to use
 user is encouraged to criticize system
 clarification possible
 paper and pencil – cheap, limited to writing speed
 audio – good for think aloud, difficult to match with other
protocols
 video – accurate and realistic, needs special equipment,
obtrusive
 computer logging – automatic and unobtrusive, large amounts
of data difficult to analyze
 user notebooks – coarse and subjective, useful insights, good
for longitudinal studies

 Mixed use in practice.

 audio/video transcription difficult and requires skill.
 Some automatic support tools available
 Workplace project
 Post task walkthrough
 user reacts on action after the event
 used to fill in intention

 Advantages
 analyst has time to focus on relevant incidents
 avoid excessive interruption of task

 Disadvantages
 lack of freshness
 may be post-hoc interpretation of events
 transcript played back to participant for
comment
 immediately fresh in mind
 delayed  evaluator has time to identify
questions
 useful to identify reasons for actions and
alternatives considered
 necessary in cases where think aloud is not
possible
 Interviews
Questionnaires
 analyst questions user on one-to -one basis
usually based on prepared questions
 informal, subjective and relatively cheap

 Advantages
 can be varied to suit context
 issues can be explored more fully
 can elicit user views and identify unanticipated
problems
 Disadvantages
 very subjective
 time consuming
 Set of fixed questions given to users

 Advantages
 quick and reaches large user group
 can be analyzed more rigorously

 Disadvantages
 less flexible
 less probing
 Need careful design
 what information is required?
 how are answers to be analyzed?

 Styles of question
 general
 open-ended
 scalar
 multi-choice
 ranked
 Eye tracking
Physiological measurement
 head or desk mounted equipment tracks the
position of the eye
 eye movement reflects the amount of cognitive
processing a display requires
 measurements include
 fixations: eye maintains stable position. Number and
duration indicate level of difficulty with display
 saccades: rapid eye movement from one point of
interest to another
 scan paths: moving straight to a target with a short
fixation at the target is optimal
 emotional response linked to physical changes
 these may help determine a user’s reaction to an
interface
 measurements include:
 heart activity, including blood pressure, volume and pulse.
 activity of sweat glands: Galvanic Skin Response (GSR)
 electrical activity in muscle: electromyogram (EMG)
 electrical activity in brain: electroencephalogram (EEG)

 some difficulty in interpreting these physiological

responses - more research needed
when in process: design vs. implementation
style of evaluation: laboratory vs. field
how objective: subjective vs. objective
type of measures: qualitative vs. quantitative
level of information: high level vs. low level
level of interference: obtrusive vs. unobtrusive
resources available: time, subjects,
equipment, expertise
universal design
 equitable use
 flexibility in use
 simple and intuitive to use
 perceptible information
 tolerance for error
 low physical effort
 size and space for approach and use
 More than one sensory channel in interaction
 e.g. sounds, text, hypertext, animation, video, gestures, vision
 Used in a range of applications:
 particularly good for users with special needs, and virtual
reality
  Will cover
 general terminology
 speech
 non-speech sounds
 handwriting
 considering applications as well as principles
The 5 senses (sight, sound, touch, taste and smell) are used
by us every day
 each is important on its own
 together, they provide a fuller interaction with the natural world

Computers rarely offer such a rich interaction

Can we use all the available senses?

 ideally, yes
 practically – no

We can use • sight • sound • touch (sometimes)

We cannot (yet) use • taste • smell

 Multi-modal systems
 use more than one sense (or mode ) of interaction
e.g. visual and aural senses: a text processor may speak the words
as well as echoing them to the screen

 Multi-media systems
 use a number of different media to communicate
information
e.g. a computer-based teaching system:may use video, animation,
text and still images: different media all using the visual mode of
interaction; may also use sounds, both speech and non-speech: two
more media, now using a different mode
Human beings have a great and natural
mastery of speech

 makes it difficult to appreciate the complexities

but
 it’s an easy medium for communication
phonemes
 40 of them
 basic atomic units
 sound slightly different depending on the context they
are in, these larger units are …
allophones
 all the sounds in the language
 between 120 and 130 of them
 these are formed into …

morphemes
 smallest unit of language that has meaning.
Other terminology:
• prosody
 alteration in tone and quality
 variations in emphasis, stress, pauses and pitch
 impart more meaning to sentences.

• co-articulation
 the effect of context on the sound
 transforms the phonemes into allophones

• syntax – structure of sentences

• semantics – meaning of sentences
 Different people speak differently:
 accent, intonation, stress, idiom, volume, etc.
 The syntax of semantically similar sentences may vary.
 Background noises can interfere.
 People often “ummm.....” and “errr.....”
 Words not enough - semantics needed as well
 requires intelligence to understand a sentence
 context of the utterance often has to be known
 also information about the subject and speaker

e.g. even if “Errr.... I, um, don’t like this” is recognised, it is a fairly

useless piece of information on it’s own
 Developed for Finnish (a phonetic language, written as it is said)
 Trained on one speaker, will generalise to others.
 A neural network is trained to cluster together similar
sounds, which are then labelled with the corresponding
character.
 When recognising speech, the sounds uttered are allocated
to the closest corresponding output, and the character for
that output is printed.
 requires large dictionary of minor variations to correct general
mechanism
 noticeably poorer performance on speakers it has not been trained on
a a a ah h æ æ ø ø e e e

o a a h r æ l ø y y j i

o o a h r r r g g y j i

o o m a r m n m n j i i

l o u h v vm n n h hj j j

l u v v p d d t r h hi j

. . u v tk k p p p r k s

. . v k pt t p t p h s s
 Single user or limited vocabulary systems
e.g. computer dictation
 Open use, limited vocabulary systems can work
satisfactorily
e.g. some voice activated telephone systems
 general user, wide vocabulary systems …
… still a problem
 Great potential, however
 when users hands are already occupied
e.g. driving, manufacturing
 for users with physical disabilities
 lightweight, mobile devices
The generation of speech

Useful
 natural and familiar way of receiving information
Problems
 similar to recognition: prosody particularly

Additional problems
 intrusive - needs headphones, or creates noise in the
workplace
 transient - harder to review and browse
Successful in certain constrained applications
when the user:
 is particularly motivated to overcome problems
 has few alternatives

Examples:
 screen readers
 read the textual display to the user
utilised by visually impaired people
 warning signals
 spoken information sometimes presented to pilots whose visual
and haptic skills are already fully occupied
 boings, bangs, squeaks, clicks etc.

 commonly used for warnings and alarms

 Evidence to show they are useful
 fewer typing mistakes with key clicks
 video games harder without sound

 Language/culture independent, unlike speech

 Dual mode displays:
 information presented along two different sensory channels
 redundant presentation of information
 resolution of ambiguity in one mode through information in
another
 Sound good for
 transient information
 background status information

e.g. Sound can be used as a redundant mode in the Apple

Macintosh; almost any user action (file selection, window active,
disk insert, search error, copy complete, etc.) can have a
different sound associated with it.
 Use natural sounds to represent different types of object
or action
 Natural sounds have associated semantics which can be
mapped onto similar meanings in the interaction
e.g. throwing something away
~ the sound of smashing glass
 Problem: not all things have associated meanings

 Additional information can also be presented:

 muffled sounds if object is obscured or action is in the
background
 use of stereo allows positional information to be added
 items and actions on the desktop have associated
sounds
 folders have a papery noise
 moving files – dragging sound
 copying – a problem …
sound of a liquid being poured into a receptacle
rising pitch indicates the progress of the copy
 big files have louder sound than smaller ones
 Synthetic sounds used to convey information
 Structured combinations of notes (motives )
represent actions and objects
 Motives combined to provide rich information
 compound earcons
 multiple motives combined to make one more complicated
earcon
 family earcons
similar types of earcons represent similar classes of
action or similar objects: the family of “errors” would
contain syntax and operating system errors

 Earcons easily grouped and refined due to

compositional and hierarchical nature

 Harder to associate with the interface task since

there is no natural mapping
 haptic interaction
 cutaneous perception
 tactile sensation; vibrations on the skin
 kinesthetics
 movement and position; force feedback
 information on shape, texture, resistance,
temperature, comparative spatial factors
 example technologies
 electronic braille displays
 force feedback devices e.g. Phantom
 resistance, texture
 Handwriting is another communication mechanism which
we are used to in day-to-day life

 Technology
 Handwriting consists of complex strokes and spaces
 Captured by digitising tablet
 strokes transformed to sequence of dots
 large tablets available
 suitable for digitising maps and technical drawings
 smaller devices, some incorporating thin screens to
display the information
 PDAs such as Palm Pilot
 tablet PCs
 Problems
 personal differences in letter formation
 co-articulation effects

 Breakthroughs:
 stroke not just bitmap
 special ‘alphabet’ – Graffeti on PalmOS

 Current state:
 usable – even without training
 but many prefer keyboards!
 applications
 gestural input - e.g. “put that there”
 sign language
 technology
 data glove
 position sensing devices e.g MIT Media Room
 benefits
 natural form of interaction - pointing
 enhance communication between signing and non-signing users
 problems
 user dependent, variable and issues of coarticulation
 visual impairment
 screen readers, SonicFinder
 hearing impairment
 text communication, gesture, captions
 physical impairment
 speech I/O, eyegaze, gesture, predictive systems (e.g.
Reactive keyboard)
 speech impairment
 speech synthesis, text communication
 dyslexia
 speech input, output
 autism
 communication, education
 age groups
 older people e.g. disability aids, memory aids,
communication tools to prevent social isolation
 children e.g. appropriate input/output devices,
involvement in design process
 cultural differences
 influence of nationality, generation, gender, race,
sexuality, class, religion, political persuasion etc. on
interpretation of interface features
 e.g. interpretation and acceptability of language,
cultural symbols, gesture and colour
user support
 Issues
 different types of support at different times
 implementation and presentation both important
 all need careful design

 Types of user support

 quick reference, task specific help, full explanation,
tutorial
 Provided by help and documentation
 help - problem-oriented and specific
 documentation - system-oriented and general
 same design principles apply to both
 Availability
 continuous access concurrent to main application
 Accuracy and completeness
 help matches and covers actual system behaviour
 Consistency
 between different parts of the help system and paper documentation
 Robustness
 correct error handling and npredictable behaviour
 Flexibility
 allows user to interact in a way appropriate to experience and task
 Unobtrusiveness
 does not prevent the user continuing with work
 Command assistance
 User requests help on particular command
e.g., UNIX man, DOS help
 Good for quick reference
 Assumes user know what to look for

 Command prompts
 Provide information about correct usage when an error
occurs
 Good for simple syntactic errors
 Also assumes knowledge of the command
 Context sensitive help
 help request interpreted according to context in which
it occurs. e.g. tooltips
 On-line tutorials
 user works through basics of application in a test
environment.
 can be useful but are often in flexible.
 On-line documentation
 paper documentation is made available on computer.
 continually available in common medium
 can be difficult to browse
 hypertext used to support browsing.
 wizards
 task specific tool leads the user through task, step by step,
using user’s answers to specific questions
 example: resumé
 useful for safe completion of complex or infrequent tasks
 constrained task execution so limited flexibility
 must allow user to go back

 assistants
 monitor user behaviour and offer contextual advice
 can be irritating e.g. MS paperclip
 must be under user control e.g. XP smart tags
 Use knowledge of the context, individual user,
task, domain and instruction to provide help
adapted to user's needs.

 Problems
 knowledge requirements considerable
 who has control of the interaction?
 what should be adapted?
 what is the scope of the adaptation?
 All help systems have a model of the user
 single,generic user (non-intelligent)
 user-configured model (adaptable)
 system-configure model (adaptive)
 Quantification
 user moves between levels of expertise
 based on quantitative measure of what he knows.
 Stereotypes
 user is classified into a particular category.
 Overlay
 idealized model of expert use is constructed
 actual use compared to ideal
 model may contain the commonality or difference
Special case: user behaviour compared to known error
catalogue
 Covers
 common errors and tasks
 current task

 Usually involves analysis of command sequences.

 Problems
 representing tasks
 interleaved tasks
 user intention
 involves choosing the correct style of advice for
a given situation.
e.g. reminder, tutorial, etc.

 few intelligent help systems model advisory

strategy, but choice of strategy is still important.
 rule based (e.g. logic, production rules)
 knowledge presented as rules and facts
 interpreted using inference mechanism
 can be used in relatively large domains.
 frame based (e.g. semantic network)
 knowledge stored in structures with slots to be filled
 useful for a small domain.
 network based
 knowledge represented as relationships between facts
 can be used to link frames.
 example based
 knowledge represented implicitly within decision structure
 trained to classify rather than programmed with rules
 requires little knowledge acquisition
 knowledge acquisition

 resources

 interpretation of user behaviour

 Initiative
 does the user retain control or can the system direct the
interaction?
 can the system interrupt the user to offer help?

 Effect
 what is going to be adapted and what information is needed to
do this?
 only model what is needed.

 Scope
 is modelling at application or system level?
 latter more complex
e.g. expertise varies between applications.
 User support is not an `add on’
 should be designed integrally with the system.

 Concentrate on content and context of help

rather than technological issues.
 How is help requested?
 command, button, function (on/off), separate
application
 How is help displayed?
 new window, whole screen, split screen,
 pop-up boxes, hint icons
 Effective presentation requires
 clear, familiar, consistent language
 instructional rather than descriptive language
 avoidance of blocks of text
 clear indication of summary and example information
Is help What resources are
 operating system command available?
 meta command  screen space
 application  memory capacity
 speed

Structure of help data

 single file Issues
 file hierarchy  flexibility and extensibility
 database  hard copy
 browsing
 Alan Dix- Janet Finlay Gregory D. Abowd-
Russel Beale- Human – Computer Interaction,
Pearson Education- 3 rd Edition- 2004.
 John M.Caroll, Human – Computer
Interaction in the Millennium, Pearson
Education- 3rd Edition- 2000.

School of Computing, Department of IT 8/22/2011 119

1. What is cognitive walkthrough?
2. What is heuristic evaluation?
3. List the methods for recording user actions.
4. List the two types of query techniques.
5. Mention the different styles of questions
that are included in questionnaire.
6. What is haptic interaction?

School of Computing, Department of IT 8/22/2011 120

7. How do you design an interface for visually
impaired persons?
8. Suggest few input devices for young
children other than keyboard. Why are they
preferred over the key board?
9. Mention the four types of assistance that
user’s require.
10. What is wizard?
11. What are the main goals of evaluation?
12. List at least four factors that distinguish
different evaluation techniques.

School of Computing, Department of IT 8/22/2011 121