Chapter Five

Design Rules and

Implementation Support
 Chapter Content

1. Design Rules (Introduction, Principles to

support usability, Standards, Guidelines,
Golden rules and heuristics, HCI patterns)
2. Implementation Support (Introduction,
Elements of windowing systems,
Programming the application, User
interface management systems)
 Design Rules - Introduction (1.1)

Introduction
• Designing for maximum usability
– the goal of interaction design

• Principles of usability
– general understanding

• Standards and guidelines

– direction for design

• Design patterns
– capture and reuse design knowledge
Types of Design Rules
• Principles
– abstract design rules
– low authority
Guidelines
– high generality

increasing generality
increasing generality
• Standards
– specific design rules
– high authority Standards
– limited application
• Guidelines
increasing authority
– lower authority increasing authority

– more general application

 Design Rules - Principles to Support Usability (1.2)

Learnability
the ease with which new users can begin effective
interaction and achieve maximal performance

Flexibility
the multiplicity of ways the user and system
exchange information

Robustness
the level of support provided the user in
determining successful achievement and assessment
of goal-directed behaviour
Principle of Learnability
Predictability
– determining effect of future actions based on past
interaction history
– operation visibility

Synthesizability
– assessing the effect of past actions
– immediate vs. eventual honesty
Familiarity
– how prior knowledge applies to new system
– guessability; affordance
Generalizability
– extending specific interaction knowledge to new
situations
Consistency
– likeness in input/output behaviour arising from
similar situations or task objectives
Principles of Flexibility
Dialogue initiative
– freedom from system imposed constraints on input dialogue
– system vs. user pre-emptiveness

Multithreading
– ability of system to support user interaction for more than one task at a
time
– concurrent vs. interleaving; multimodality

Task migratability
– passing responsibility for task execution between user and system
Substitutivity
– allowing equivalent values of input and output to
be substituted for each other
– representation multiplicity; equal opportunity

Customizability
– modifiability of the user interface by user
(adaptability) or system (adaptivity)
Principles of Robustness
Observability
– ability of user to evaluate the internal state of the system from its
perceivable representation
– browsability; defaults; reachability; persistence; operation visibility

Recoverability
– ability of user to take corrective action once an error has been
recognized
– reachability; forward/backward recovery; commensurate effort
Responsiveness
– how the user perceives the rate of communication
with the system
– Stability

Task conformance
– degree to which system services support all of the
user's tasks
– task completeness; task adequacy
 Design Rules – Standards (1.3)

• Set by national or international bodies to ensure

compliance by a large community of designers
standards require sound underlying theory and
slowly changing technology.

• Hardware standards more common than

software high authority and low level of detail.

• ISO 9241 defines usability as effectiveness,

efficiency and satisfaction with which users
accomplish tasks.
 Design Rules – Guidelines (1.4)

• more suggestive and general

• many textbooks and reports full of guidelines
• abstract guidelines (principles) applicable
during early life cycle activities
• detailed guidelines (style guides) applicable
during later life cycle activities
• understanding justification for guidelines aids
in resolving conflicts
 Design Rules - Golden Rules and Heuristics (1.5)

• “Broad brush” design rules (not be always be applicable to

every situation)
• Useful check list for good design
• Better design using these than using nothing!
• Different collections e.g.
– Shneiderman’s 8 Golden Rules
– Norman’s 7 Principles
– Nielsen’s 10 Heuristics (not discussed here)
Shneiderman’s 8 Golden Rules of Interface Design
1. Strive for consistency
2. Enable frequent users to use shortcuts
3. Offer informative feedback
4. Design dialogs to yield closure
5. Offer error prevention and simple error handling
6. Permit easy reversal of actions
7. Support internal locus of control
8. Reduce short-term memory load
Norman’s 7 Principles for Transforming Difficult Tasks into
Simple Ones
1. Use both knowledge in the world and knowledge in the
head.
2. Simplify the structure of tasks.
3. Make things visible: bridge the gulfs of Execution and
Evaluation.
4. Get the mappings right.
5. Exploit the power of constraints, both natural and
artificial.
6. Design for error.
7. When all else fails, standardize.
 Design Rules - HCI Design Patterns (1.6)

• An approach to reusing knowledge about successful design

solutions
• Originated in architecture: Alexander
• A pattern is an invariant solution to a recurrent problem
within a specific context.
• Examples
– Light on Two Sides of Every Room (architecture)
– Go back to a safe place (HCI)
• Patterns do not exist in isolation but are linked to other
patterns in languages which enable complete designs to be
generated
Characteristics of patterns
– capture design practice not theory
– capture the essential common properties of good
examples of design
– represent design knowledge at varying levels: social,
organisational, conceptual, detailed
– embody values and can express what is humane in
interface design
– are intuitive and readable and can therefore be used for
communication between all stakeholders
– a pattern language should be generative and assist in the
development of complete designs.
 Implementation Support - Introduction (2.1)

• HCI affect programmer.

• Advances in coding have elevated
programming
– hardware specific
 interaction-technique specific
• Layers of development tools
– windowing systems
– interaction toolkits
– user interface management systems
• Programming tools for interactive systems
– provide a means of effectively translating abstract
designs.
– provide usability principles into an executable
form.
– provide different levels of services for the
programmer.
• Windowing systems
– are a central environment for both the
programmer and user of an interactive system.
– allowing a single workstation to support separate
user – system threads of action simultaneously.
– core support for separate and simultaneous user-
system activity.
– Programming the application and control of
dialogue.
• Interaction toolkits
– abstract away from the physical separation of
input and output devices
– allowing the programmer to describe behaviors of
objects at a level similar to how the user
perceives them.
– bring programming closer to level of user
perception.
• User interface management systems
– are the final level of programming support tools
– allowing the designer and programmer to control
the relationship between the presentation
objects of a toolkit with their functional
semantics in the actual application.
– controls relationship between presentation and
functionality.
 Implementation Support - Elements of Windowing Systems (2.2)

Feature of a Windowing System

• The first important feature of a windowing system is its ability to
provide programmer independence from the specifics of the
hardware devices.
– It is imperative to be able to program an application that will
run on a wide range of devices.
– To do this, the programmer wants to direct commands to an
abstract terminal, which understands a more generic language
and can be translated to the language of many other specific
devices (translation program – or device driver).
– Benefit - making the programming task easier + the makes
portability of application programs possible.
• The second important feature of a windowing
system is its ability to support several
separate user tasks simultaneously.
(Resource sharing)
– sharing the resources of a single hardware
configuration with several copies of an abstract
terminal.
– achieving simultaneity of user tasks
– window system supports independent processes
– isolation of individual applications
Roles of Windowing System
Architectures of Windowing Systems
• Possible architectures of a windowing system is to
achieve two tasks:
– independence from the specifics of programming separate
hardware devices.
– management of multiple, independent but simultaneously
active applications.
• three possible architectures for the software to
implement the roles of a windowing system.
– Assumptions:
• device drivers are separate from the application programs.
• differ in how multiple application management is
implemented
1. Each (separate) application manages all (multiple)
processes.
– implement and replicate the management of the
multiple processes within each of the separate
applications.
– Problem
• it forces each application to consider the difficult
problems of resolving synchronization conflicts
with the shared hardware devices. (everyone
worries about synchronization)
• reduces portability of the separate applications.
2. Management role within kernel of operating system
– applications tied to operating system
– centralizing the management task by freeing it
from the individual applications.
– Problem:
• Applications must still be developed with the
specifics of the particular operating system in
mind.
3. Management role as separate application
maximum portability
• the management function is written as a
separate application in its own right
• can provide an interface to other application
programs that is generic across all operating
systems.
• provides the most portability
• referred to as the client–server architecture.
The client-server architecture
Implementation Support - Programming the Application (2.3)

• Is studying a client in the client–server architecture.

• Interactive applications are generally user driven in
the sense that the action the application takes is
determined by the input received from the user.
• There are two programming paradigms which can be
used to organize the flow of control within the
application.
• The windowing system does not necessarily determine
which of these two paradigms is to be followed.
– read–evaluation loop
– notification based
Read-evaluation Loop
• Programming on the Macintosh follows this paradigm.
• The server sends user inputs as structured events to
the client application.
• As far as the server is concerned, the only importance
of the event is the client to which it must be directed.
• The client application is programmed to read any
event passed to it and determine all of the application-
specific behavior that results as a response to it.
• The application has complete control over the
processing of events that it receives.
• The downside is that the programmer must execute
this control over every possible event that the client
will receive, which could prove a very cumbersome
task.
Read-evaluation Loop

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
Notification based
• in which the main control loop for the event processing does not
reside within the application.
• a centralized notifier receives events from the window system and
filters them to the application program in a way declared by the
program.
• The application program informs the notifier what events are of
interest to it, and for each event declares one of its own
procedures as a callback before turning control over to the notifier.
• Control flow is centralized in the notifier, which relieves the
application program of much of the tedium of processing every
possible event passed to it by the window system.
• Problem: pre-emptive dialog
Notification-based

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
}
Tool Kits
• user’s perspective is that input and output behaviors
are intrinsically linked to independent entities on the
display screen.
• To aid the programmer in fusing input and output
behaviors, another level of abstraction is placed on top
of the window system – the toolkit.
• A toolkit provides the programmer with a set of ready-
made interaction objects – alternatively called
interaction techniques, gadgets or widgets – which
he/she can use to create his/her application programs.
• Interaction objects comes for free without any further
programming effort.
• Toolkits exist for all windowing environments.
• To provide flexibility, the interaction objects can be tailored
to the specific situation in which they are invoked by the
programmer.
• Programming with toolkits is suited to the notification-
based programming paradigm.
• One of the advantages of programming with toolkits is that
they can enforce consistency in both input form and output
form by providing similar behavior to a collection of
widgets. This consistency of behavior for interaction objects
is referred to as the look and feel of the toolkit.
• Two features of interaction objects and
toolkits make them amenable to an object
oriented approach to programming:
instantiation and inheritance.
Using toolkits
Interaction objects
– input and output
intrinsically linked

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
 Implementation Support - User Interface Management Systems (2.4)

• Toolkits are expensive to create and are still

very difficult to use by non-programmers.
• Even experienced programmers will have
difficulty using them to produce an interface
that is predictably usable.
• There is a need for additional support for
programmers in the design and use of toolkits
to overcome their deficiencies - user interface
management systems (UIMS).
The main concerns of a UIMS are:
• a conceptual architecture for the structure of an
interactive system which concentrates on a
separation between application semantics and
presentation;
• techniques for implementing a separated
application and presentation whilst preserving
the intended connection between them;
• support techniques for managing, implementing
and evaluating a run-time interactive
environment.
• non-UIMS terms:
– UI development system (UIDS)
– UI development environment (UIDE)
• e.g. Visual Basic
 Summary

Principles for usability

– repeatable design for usability relies on
maximizing benefit of one good design by
abstracting out the general properties which can
direct purposeful design
– The success of designing for usability requires
both creative insight (new paradigms) and
purposeful principled practice

Using design rules

– standards and guidelines to direct design activity
 Summary

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