usability-supporting architectural patternsbej/usa/publications/icsetutorial04-final...1 usap...
TRANSCRIPT
1 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 1
Len Bass
Software Engineering Institute
Carnegie Mellon University
Natalia Juristo
School of Computing
Technical University of Madrid
Usability-SupportingArchitectural Patterns
Sponsored by the U.S. Department of Defense, NASA, and the European Union.
Bonnie E. John
Human-Computer Interaction Institute
Carnegie Mellon University
Maribel Sanchez-Segura
Computer Science Department
Carlos III University of Madrid
Bonnie E. John
Human-Computer Interaction Institute
Carnegie Mellon University
Pittsburgh PA 15213
USA
1-412-268-7182
Natalia Juristo
School of Computing
Technical University of Madrid
Campus de Montegancedo s/n
28660 Boadilla del Monte
Spain
34-91-3366922
Len Bass
Software Engineering Institute
Carnegie Mellon University
Pittsburgh PA 15213
USA
1-412-268-6763
Maribel Sanchez-Segura
Computer Science Department
Universidad Carlos III de Madrid
Avda. de la Universidad, 30
28911 Leganes
Spain
34-91-6249421
2 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 2
BREAK10:30-11:00
Separation based architectural patterns and their
motivation
? J2EE-MVC
? PAC
Why separation is inadequate for interactive systems
9:45-10:30
How software architecture and usability techniques fit
into a software development activities
9:30-9:45
What is Software Architecture & What is Usability?
? Basic Concepts of each
9:15-9:30
Instructor introduction & tutorial objectives9:00-9:15
TopicTime
Schedule
3 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 3
Schedule
LUNCH12:30-2:00
Small Group Exercise:
? Applying the problem statement and forces to a real-
world problem brought by the members of the
breakout group (one group per instructor)
? Report-out to the entire group
11:30-12: 30
Usability-Supporting Architectural Patterns (USAP)
? Introduction to the parts of a USAP
? Example of a USAP - problem statement, forces, and
general responsibilities
11:00-11:30
TopicTime
4 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 4
Schedule
Tutorial wrap-up5:15-5:30
A second USAP:
?Example with Observing System State USAP
4:00-5:15
BREAK3:30-4:00
Small Group Exercise:? Apply sample solution to real-world problem
introduced in prior break out? Report-out to entire group
2:30-3:30
Sample solution for example problem.2:00-2:30
TopicTime
5 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 5
Introductions
Who are we?• Len Bass
• Bonnie John• Natalia Juristo
• Maribel Sanchez-Segura
Who are you?
What do you want to get out of this tutorial?
Bonnie John is an engineer (B.Engr., The Cooper Union, 1977; M. Engr. Stanford, 1978) and cognitive psychologist (M.S. Carnegie Mellon, 1984; Ph. D. Carnegie Mellon, 1988) who has worked both in industry (Bell Laboratories,
1977-1983) and academe (Carnegie Mellon University,1988-present). She is an Associate Professor in the Human-
Computer Interaction Institute and the Director of the Masters Program in HCI. Her research includes human
performance modeling, usability evaluation methods, and the relationship between usability and software architecture.
She consults for many industrial and government organizations.
Len Bass is an expert in software architecture & architecture design methods. Author of six books including two
textbooks on software architecture & UI development, Len consult s on large-scale software projects in his role as
Senior MTS on the Architecture Trade-off Analysis Initiative at the Software Engineering Institute. His research area
is the achievement of various software quality attributes through software architecture and he is the developer of software architecture analysis and design methods. Len is also the past chair of the International Federation of
Information Processing Working Group on User Interface Engineering.
Dr. Natalia Juristo is a professor of software engineering with the Computing School at the Universidad Politecnica de Madrid. From 1992 until 2002 she was the Director of the MSc in Software Engineering. Dr. Juristo has a B.S. and a
Ph.D. in Computing. She was fellow of the European Centre for Nuclear Research (CERN) in Switzerland in 1988,
and staff of the European Space Agency (ESA) in Italy in 1989 and 1990. During 1992 she was a resident affiliate of
the Software Engineering Institute at Carnegie Mellon University. She was program chair for SEKE97 and general
chair for SEKE01 and SNPD02. Prof. Juristo has been the keynote speaker for CSEET03. She has been the guest
editor of special issues in several journals, including the Journal of Software and Systems, Data and Knowledge Engineering and the International Journal of Software Engineerin g and Knowledge Engineering Dr. Juristo has been a
member of several editorial boards, including IEEE Software and the Journal of Empirical Software Engineering. She
is a senior member of IEEE.
Maribel Sanchez-Segura has been a faculty member of the Computer Science Department in the Carlos III Technical
University of Madrid since 1998. Her research interests include software engineering, interactive systems, and
usability. Maribel holds a B.S. in Computer Science, a M.S. in Software Engineerin g and a Ph.D. in Computer Science
from the Technical University of Madrid.
6 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 6
Tutorial objectives: The sceneThe usability analyses or user test data are in; the
development team is poised to respond. The software had been carefully modularized so that modifications to the UI
would be fast and easy. When the usability problems are presented, someone around the table exclaims, “Oh, no,
we can’t change THAT!”
7 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 7
Tutorial objectives: The sceneThe usability analyses or user test data are in; the
development team is poised to respond. The software had been carefully modularized so that modifications to the UI
would be fast and easy. When the usability problems are presented, someone around the table exclaims, “Oh, no,
we can’t change THAT!”
The requested modification, feature, functionality, reaches
too far in to the architecture of the system to allow
economically viable and timely changes to be made.
• Even when the functionality is right,
• Even when the UI is separated from that functionality,
• Architectural decisions made early in development can
preclude the implementation of a usable system.
8 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 8
Tutorial objectives:
• Understand basic principles of software architecture for interactive systems and its relationship to the usability of
that system• Be able to evaluate whether common usability scenarios
will arise in the systems you are developing and what implications these usability scenarios have for software
architecture design
• Understand patterns of software architecture that facilitate usability, and recognize architectural decisions
that preclude usability of the end-product, so that you can effectively bring usability considerations into early
architectural design.
9 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 9
What is Software Architecture?
Enumeration of all major software components
Each component has enumeration of responsibilities
Interaction among components specified• Control and data flow• Sequencing information• Protocols of interaction• Allocation to hardware
There are many ways to document this information (Clements, et. al. 2003)
Clements, P., Bachmann, F., Bass, L., Garlan, D., Ivers, J., Little, R.,
Nord, R., & Stafford J., (2003) Documenting Software Architectures:
Views and Beyond, Addison Wesley.
10 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 10
Purposes of Software ArchitectureCommunication among stakeholders • An educational purpose
• A managerial purpose
Artifact for analysis• Embeds early design decisions
Set of blueprints for implementation
11 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 11
What does usability mean?
As many definitions as there are authors!
What’s important depends on context of use
Some commonly-seen aspects• efficiency of use• time to learn to use efficiently• support for exploration and problem-solving• user satisfaction (e.g., trust, pleasure, acceptance by
discretionary users)
Our concern is which of these can be influenced by architectural decisions
12 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 12
A usability benefits hierarchy
Increases individual user effectiveness• Expedites routine performance
- Accelerates error-free portion of routine performance- Reduces the impact of routine user errors (slips)
• Improves non-routine performance- Supports problem-solving- Facilitates learning
• Reduces the impact of user errors caused by lack of knowledge (mistakes)- Prevents mistakes- Accommodates mistakes
Reduces the impact of system errors• Prevents system errors• Tolerates system errors
Increases user confidence and comfort
13 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 13
Activities in software development
System Test and Deployment
Implementation
Detailed Design
Architecture Design
Requirements
System Formulation
14 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 14
Activities in software development + HCI techniques
System Test and Deployment - HCI techniques:
User testing in the field, Log analysis, etc.
Implementation - HCI techniques:
UI Toolkits
Detailed Design - HCI techniques:
Heuristic Evaluation, Cognitive Walkthrough, GOMS, PICTIVE,
Rapid prototyping+user testing, etc.
Architecture Design - HCI techniques:
What we’ll learn today
Requirements - HCI techniques:
Interviewing, questionnaires, Contextual Inquiry
System Formulation - HCI techniques:
Interviewing, questionnaires, Contextual Inquiry
15 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 15
Detailed Design - CommonPractice for Interactive Systems
System Test and Deployment - HCI techniques:
Think-aloud Usability Testing, Log analysis, etc.
Implementation - HCI techniques:
UI Toolkits
Detailed Design - HCI techniques:
Heuristic Evaluation, Cognitive Walkthrough, GOMS, PICTIVE,
Rapid prototyping+user testing, etc.
Architecture Design - HCI techniques:
What we’ll learn today
Requirements - HCI techniques:
Interviewing, questionnaires, Contextual Inquiry
System Formulation - HCI techniques:
Interviewing, questionnaires, Contextual Inquiry
16 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 16
Detailed Design - CommonPractice for Interactive SystemsThe HCI techniques supporting detailed design of the user interface are all based on iterative design
• i.e.,design, test (analyze or measure), change, and re-test.
Once software has been designed, iteration implies
change.
Software engineers plan for change through isolating
section to be changed (separation).
In detailed design, the items to be separated are those
relating to presentation, input, possibly dialog.
17 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 17
Separation Based Architectural Patterns for Usability
Presentation-Abstraction-Control (PAC)• Developed in 1980s by group at the University of
Grenoble• Reaction to shortcomings of Smalltalk Model-View-
Controller (MVC)
J2EE Model-View-Controller (J2EE MVC)
• Developed by Sun to support J2EE• Adaptation of Smalltalk MVC to web environment
Separation based patterns are commonly used in practice
and have proven quite successful
PAC is documented in:
Buschmann, F., Meuneir, R, Rohnert, H., Sommerlad, P. and Stal, M.,
(1996) Pattern-Oriented Software Architecture, A System of Patterns,
Chichester, Eng: John Wiley and Sons.
J2EE-MVC is documented at http://java.sun.com/blueprints/patterns/MVC-
detailed.html
18 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 18
Presentation-Abstraction-Control(PAC)Hierarchical series of agents• Top-level agent provides functional core• Bottom level agents are self contained semantic concepts such
as spread sheets or forms.• Intermediate level agents act as intermediaries between top level
and bottom level agents and determines which bottom level agents are active.
Each agent has three portions:• Presentation - Input/output manager (unlikely to occur
except in bottom level)• Abstraction - Application functionality• Control - Mediator between Presentation & Abstraction
and communicator to controls at other levels
19 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 19
Outputdevice
Input device
Presentation-Abstraction-Control (PAC)
AbstractionPresentation
ControllerFunctional Core
(presentation
unlikely)
Intermediaries
(presentation
unlikely)
Self contained semanticconcepts
AbstractionPresentation
Controller
AbstractionPresentation
Controller
AbstractionPresentation
Controller
AbstractionPresentation
Controller
20 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 20
J2EE Model-View-Controller
Object-oriented
Model - Application state and functionality
View - Renders models, sends user gestures to
Controller
Controller - Updates model, selects view, defines application
behavior
Differences from PAC
• Separates management of the input from the output
• View updates itself directly from the model
• PAC hierarchical concept managed outside of J2EE-MVC
21 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 21
J2EE Model-View-Controller
Outputdevice
Input device
CommandProcessor
CommandProcessor
ModelCommand
Processor
CommandProcessor
View
CommandProcessor
Command
Processor
Controller
22 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 22
Software architectural patternsPAC and J2EE MVC are “software architectural patterns” (Buschmann, et. al., 1996)
Independent of application
Provides some indication of assignment of responsibilities to components
Much left unspecified:• Allocation to processes• Synchronous/asynchronous communication• Decomposition of components• Class structure• Other responsibilities of components• Exceptions
Sufficient to give overall guidance for design approach
Buschmann, F., Meuneir, R, Rohnert, H., Sommerlad, P. and Stal, M.,
(1996) Pattern-Oriented Software Architecture, A System of Patterns,
Chichester, Eng: John Wiley and Sons.
23 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 23
Software architectural patterns - 2
Patterns community has a variety of styles and levels of detail for writing about patterns
• Buschmann, et. al., (1996) provide prose descriptions, architecture-level diagrams, and sample code.
• Gamma, et. al., (1995) provide prose descriptions, class diagrams, and code samples
• Hillside Group advocates mainly prose and emphasizes
pattern languages above individual patterns
Buschmann, F., Meuneir, R, Rohnert, H., Sommerlad, P. and Stal, M.,
(1996) Pattern-Oriented Software Architecture, A System of Patterns,
Chichester, Eng: John Wiley and Sons.
Gamma, E., Helm, R., Johnson, R., Vlissides, J. (1995). Design Patterns.
Boston, Massachusetts: Addison-Wesley.
Information about the Hillside Group and patterns and pattern languages can
be found at http://www.hillside.net/
24 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 24
Why separation-basedarchitectural patterns are not sufficient for interactive systems
Remember iterative design?
25 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 25
How does J2EE MVC support iterative design?Change color of font• Modify only View
- View contains all display logic; font changes only require modifying the display
Change order of dialogs
• Modify only Controller
- Controller defines the presentation flow, so changing dialog order involves modifying the controller logic
26 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 26
What happens to other usability changes?Add the ability to cancel a long-running command• Requires modification of all three modules
- View – must have cancel button or other means for user to specify cancel
- Controller – logic to respond to the View’s menu selection and execute the appropriate Model function
- Model – free allocated resources, etc.
27 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 27
Shortcomings of separation patterns for solving the “We can’t change THAT!” problem With respect to adding the ability to cancel
• Involved all components
• Not much localization
• If requirement for cancel discovered late, then will require extensive modification to the architecture.
28 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 28
After the break, we’ll start addressing these shortcomings with usability-supportingarchitectural patterns
29 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 29
Beyond separation-basedarchitectural patterns Our goal is to provide software designers and usability specialist tools to recognize and prevent common usability problems that are not supported by separation.
We are doing this by:• Identifying those aspects of usability that are
“architecturally sensitive” and embodying them in small scenarios
• Providing a way to reason about the forces acting on architecture design in these scenarios
• Providing checklist of important software responsibilities and possible architecture patterns to satisfy these scenarios
30 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 30
What does architecturally-sensitive mean?A scenario is architecturally-sensitive if it is difficult to add the scenario to a system after the architecture has been designed.
Solution may:• Insure that multiple components interact in particular
ways• Insure that related information and actions can be found
in a single component and easily changed
Separation patterns intended to localize changes to presentation. Therefore,• Changing color of font – NOT architecturally-sensitive• Adding cancellation – IS architecturally-sensitive
31 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 31
An architecturally-sensitive scenario:Canceling commands
The user issues a command then changes his or her mind, wanting to stop the operation and return the software to its
pre-operation state. It doesn’t matter why the user wants to stop; he or she could have made a mistake, the system
could be unresponsive, or the environment could have
changed.
32 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 32
What other architecturally-sensitive scenarios can you think of?
33 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 33
Here are some others we have thought ofAggregating DataAggregating Commands AlertCanceling Commands Checking for CorrectnessEvaluating the SystemForm/Field ValidationHistory LoggingMaintaining Device Independence
(Different Access Methods)Maintaining Compatibility with
Other SystemsMaking Views AccessibleModifying InterfacesNavigating Within a Single ViewObserving System StateOperating Consistently Across
ViewsProviding Good Help
(Context-Sensitive Help)Predicting Task DurationRecovering from Failure
Reusing InformationRetrieving Forgotten PasswordsShortcutsStatus indicationSupporting Comprehensive
SearchingSupporting International Use
(Different Languages)Supporting Multiple ActivitiesSupporting Personalization
(User Profile)Supporting Undo Supporting VisualizationTourUsing Applications Concurrently
(Multi-Tasking)Verifying Resources WizardWorkflow modelWorking at the User’s Pace Working in an Unfamiliar Context
This list of architecturally-sensitive usability scnearios is compiled from
Bass, L., John, B. E., & Kates, J. (2001). Achieving usability through
software architecture (CMU/SEI-2001-TR-005). Pittsburgh, PA:
Software Engineering Institute.
http://www.sei.cmu.edu/publications/documents/01.re
ports/01tr005.html
And
Juristo , N., Moreno, A. M., & Sanchez, M. (2003) Deliverable D.3.4.
Techniques, patterns and styles for architecture- level usability improvement. -
ESPRIT project (IST-2001-32298)
http://www.ls.fi.upm.es/status/results/deliverables.html
34 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 34
Need more than just architecturally sensitive scenario
Architecturally sensitive scenarios are potential requirements for a particular system to support usability
Need
• to determine whether the benefit of supporting the scenario outweighs the cost
• to provide guidance to the development team as to the
issues associated with implementing a solution
35 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 35
User’s Organizational Setting
Task in an Environment
System
Forces
Forces
Ben
efi
ts
Systems exist in a context
36 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 36
Context for computer system
Computer systems fulfill “business” goals• “Business goals” could be mission, academic,
entertainment, etc.• User using the system creates certain benefits for the
“organization” that created it• Creating system has costs.
Cost/Benefit• Implementation support for total scenario• Implementation support for pieces of the scenario
But more detail is necessary to be able to understand cost/benefit and implications of implementation
37 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 37
User«s Organizational Settings
Task in an Environment
Forces
System
Users
Human
desires and
capabilities
Software
Benefits
realized
when the solution is
provided
State of the
software
General
responsibilities
Specific Solution (more
detail): e.g., architecture,
software tactics
Forces
Forces
Forces
Previous
design
decisions
ForcesBenefits
Forces acting on architecture design
38 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 38
Reasoning about architecture designDiffering forces motivate particular aspects of solution.
Forces come from three sources:• Task and environment in which user is operating.
- E.g., Cancel is only useful if operation is long running.• Human desires and capabilities.
- E.g., User makes mistakes, Cancel allows one type of
correction of mistake.• State of the software.
- E.g., Networks fail. Giving the user the ability to cancel may prevent the user from being blocked
because of this failure.
39 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 39
Architecture Design
Many different methods for satisfying a particular scenario.
Most systems use separation based architectural pattern as a basis for overall design of system.
We provide two different solutions:
• General solution – responsibilities of the software that
must be fulfilled by any solution• Specific solution. An architectural pattern that shows how
to implement the general solution in the context of a separation based pattern. For example, we’ll assume
J2EE-MVC as an overarching separation based pattern.
40 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 40
Software Architectural Patterns
We have given you two examples of architectural patterns (PAC and J2EE-MVC)
These are examples of the solution portion of an
architectural pattern
The patterns community has developed a set of common
concepts that should be included in descriptions of a pattern.
We embody these concepts in Usability-Supporting
Architectural Patterns (USAPs)
41 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 41
Usability-Supporting Architectural Patterns - 1
Context• Situation – architecturally sensitive usability scenarios
• Conditions – constraints on when the situation is relevant• Usability benefits – enumeration of benefits to the user
from supporting this scenario
Problem - Forces in conflict
• Forces exerted by the task and environment• Forces exerted by human desires and capabilities
• Forces exerted by the state of the software when the user wishes to apply the architecturally sensitive usability
scenario
42 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 42
Usability-Supporting Architectural Patterns - 2
General solution – set of responsibilities that any solution to situation must satisfy
Specific solution – architectural pattern to solve situation
assuming an overarching separation based pattern• In our slides, we’ll assume J2EE-MVC
43 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 43
USAP Context template
Potential Usability Benefits: A brief description of the benefits to
the user if the solution is implemented. We use the usability benefit
hierarchy given earlier
Conditions on the Situation: Any conditions on the situation
constraining when the pattern is useful
Situation: A brief description of the situation from the user’s
perspective that makes this pattern useful
44 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 44
USAP Context for Cancel - 1
Conditions on the Situation: A user is working in a system where
the software has long-running commands, i.e., more than one
second.
The cancellation command could be explicitly issued by the user,
or through some sensing of the environment (e.g., a child’s hand in
a power car window).
Situation: The user issues a command then changes his or her
mind, wanting to stop the operation and return the software to its
pre-operation state. It doesn’t matter why the user wants to stop;
he or she could have made a mistake, the system could be
unresponsive, or the environment could have changed.
45 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 45
Benefits of Cancel - 1
Potential Usability Benefits:
A. Increases individual user effectiveness
A.1 Expedites routine performance
A.1.2 Reduces the impact of routine user errors (slips) by
allowing users to revoke accidental commands and return to
their task faster than waiting for the erroneous command to
complete.
A.2 Improves non-routine performance
A.2.1 Supports problem-solving by allowing users to apply
commands and explore without fear, because they can
always abort their actions.
46 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 46
Benefits of Cancel – 2
Potential Usability Benefits:
A. Increases individual user effectiveness
A.3 Reduces the impact of user errors caused by lack of
knowledge (mistakes)
A.3.2 Accommodates mistakes by allowing users to abort
commands they invoke through lack of knowledge and
return to their task faster than waiting for the erroneous
command to complete.
B. Reduces the impact of system errors
B.2 Tolerates system errors by allowing users to abort
commands that aren’t working properly (for example, a user
cancels a download because the network is jammed).
C.Increases user confidence and comfort by allowing users to
perform without fear because they can always abort their
actions.
47 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 47
Cost/Benefit
There is a cost to implementing cancel. The software engineer can calculate this.
There is a benefit to the organization (as we explained) from implementing cancel.• Benefit to current user immediately from recovered time• Benefit to current user later from cleaning up local
resources so system will not subsequently crash• Benefit to other users from cleaning up shared
resources.
Development team (or project manager) can do cost/benefit analysis to determine whether to implement cancel.
48 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 48
First row of problem/general solution template always scenario
The first row provides the rationale for the scenario in terms of the forces.
This enables the development team to decide whether to
implement the scenario at all.
It may be that forces are not applicable to current
development.
It may also be that forces cause consideration of scenario when it may be have been overlooked.
49 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 49
USAP Problem/General Solution Template
Responsibilities
of the general
solution that
resolve the forces
in the row.
Forces
exerted by
the state of
the software .
Each row
contains a
different force.
Forces
exerted by
human
desires and
capabilities.
Each row
contains a
different
force.
Forces
exerted by the
environment
and the task.
Each row
contains a
different force
General
SolutionProblem
50 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 50
Cancel Problem/General Solution:Responsibility R1 is essentially the scenario itself
R1.
Must provide
a means to
cancel a
command
Software is
sometimes
unresponsive
Users slip or
make mistakes,
or explore
commands and
then change
their minds, but
do not want to
wait for the
command to
complete.
Networks are
sometimes
unresponsive.
Sometimes
changes in the
environment
require the
system to
terminate.
General
SolutionProblem
51 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 51
Template Problem/General Solution -other rows
Each subsequent row of the problem general solution template provides rationale for one or more responsibilities.
Usually one row per responsibility, but sometimes rationale
for multiple responsibilities are the same and so multiple responsibilities are included in one row.
Allows development team to understand reason for responsibility and make cost/benefit decisions about:
• Necessity• Utility
52 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 52
Cancel Problem/General Solution: Responsibility R2
R2.
Provide a button,
menu item,
keyboard shortcut
and/or other means
to cancel the active
command.
Software
has to
receive an
action from
the user to
do
something
Users have to
communicate
their intentions
to the software
through overt
acts (e.g., finger
movements)
General SolutionProblem
53 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 53
Cancel Problem/General Solution: Responsibilities R3 and R4
R3.
Must always listen for the
cancel command or
environmental changes
R4.
Must be always gathering
information (state, resource
usage, actions, etc.) that
allow for recovery of the
state of the system prior to
the execution of the current
command
No one can
predict when the
users will want to
cancel
commands
No one can
predict when
the
environment
will change
General SolutionProblem
54 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 54
Appendix contains the full table of forces and general responsibilities for canceling commands.
• We have enumerated 21 responsibilities• Some are conditional
- on aspects of the task - or state of the software
55 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 55
Summary of responsibilities that any implementation of cancel must consider
R1. Must provide a means to cancel a commandR2. Provide a button, menu item, keyboard shortcut and/or other
means to cancel the active command.R3. Must always listen for the cancel command or environmental
changesR4. Must always gather information (state, resource usage,
actions, etc.) that allow for recovery of the state of the systemprior to the execution of the current command
R5. Must acknowledge receipt of the cancellation command appropriately within 150 msec. The acknowledgement must be appropriate to the manner in which the command was issued. For example, if the user pressed a cancel button, changing the color of the button will be seen. If the user used a keyboard shortcut, flashing the menu that contains that command might be appropriate.
… to R21 (see Tutorial Notes)
Either the command itself is responsive
R6. The command must have the ability to cancel itself (I.e., it must fulfill
Responsibilities R10 to R21 (e.g., an object-oriented system would have a
cancel method in each object)
Or the command itself is not responsive
R7. An active portion of the application must ask the infrastructure to cancel the
command, or
R8. The infrastructure itself must provide a means to request the cancellation of
the application (e.g., task manager on Windows, force quit on MacOS)
R9. If either R7 or R8, then the infrastructure must have the ability to cancel the
active command (I.e., it must fulfill Responsibilities R10 to R21)
If the command has invoked collaborating processes
R10. The collaborating processes have to be informed of the cancellation of the
invoking command (these processes have their own responsibilities that they
must perform in response to this information, possibly treat it as a
cancellation.). The information given to collaborating processes may include
the request for cancellation, the progress of cancellation, and/or the
completion of cancellation.
56 USAP Tutorial ICSE2004
Continuation of responsibilities that any implementation of cancel
must consider
Either the system is capable of rolling back all changes to the state prior to execution
of the command.
R11. Restore the system back to its state prior to execution of the command.
Or the system is not capable of rolling back all changes to the state prior to execution
of the command.
R12. Restore the system back to as close to the state prior to execution of the
command as possible
R13. Inform the user of the difference between the prior state and the restored
state.
Either all resource can be restored
R14. Resources must be freed
Or some resources has been irrevocably consumed and cannot be restored
R15. Inform the user of the partially-restored resources in a manner that they will
see it.
For critical tasks with incomplete state or resource restoration,
R16. Require acknowledgement from the user that they are aware of the partially-
restored nature of the cancellation.
R17. Return control to the user, or not, depending on the forces from the task
R18. If control cannot be returned to the user, inform the user of this fact (and
ideally, why that is the case)
R19. Estimate the time it will take to cancel within 20%
R20. Inform the user of this estimate.
· If the estimate is between 1 and 10 seconds, changing the cursor shape is sufficient.
· If the estimate is more than 10 seconds, and time estimate is with 20%, then a
progress indicator is better.
· If estimate is more than 10 seconds but cannot be estimated accurately, consider
other alternatives (see TN, footnote 8)
R21. Once the cancellation has finished the system must provide feedback to the
user that cancellation is finished, e.g., if cursor was changed to busy indicator,
change it back to normal; if progress bar was displayed was displayed,
remove it; if dialog box was provided, close it.
57 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 57
Observations on general responsibilities
Many details might be overlooked by implementer• Free resources
• Provide feedback if not able to completely cancel• Inform collaborators
Table provides rationale which enables cost/benefit
possibilities. e.g. “return control to the user immediately”
• Benefit is that user wants to multi-task – increasedefficiency
• Cost may be too high depending on system environment.
58 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 58
Small Group Exercise:
Apply the problem statement and forces to a real-worldproblem brought by the members of the breakout group.
(one group per instructor)
Report-out to the entire group
60 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 60
Overarching patterns
Designers do not build system design around desire for architecturally sensitive usability scenarios.
Designers have some overarching pattern that they use.e.g. PAC or J2EE-MVC
This overarching pattern introduces additional software forces on specific solution.
Consider “inform collaborating processes” responsibility when canceling web-based data base application.
Notice the difference in communication from PAC to J2EE-MVC
61 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 61
Outputdevice
Input device
Presentation-Abstraction-Control (PAC)
Abstraction
Controller
Data base manager
Web browser
AbstractionPresentation
Controller
Abstraction
Controller
Abstraction
Controller
AbstractionPresentation
Controller
“Cancel”
“Cancel active command”
“Halt current transaction and roll back”
62 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 62
J2EE MVC version of “inform collaborators”
Outputdevice
Input device
CommandProcessor
CommandProcessor
ModelCommand
Processor
CommandProcessor
View
CommandProcessor
Command
Processor
Controller
“Cancel
buttonpushed”
“Cancel”
No communication among collaborators shown
“Cancel”
63 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 63
We’ll use J2EE-MVC as overarching pattern to illustrate our USAPs
Overarching pattern will affect specific solution in our USAPs
We’ll use J2EE-MVC as overarching pattern because it is
widely used in web applications.
Open question as to how, in general, choice of a different
overarching pattern would affect specific solutions
64 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 64
We’ll use a non-critical task for the exampleThis implies that• The user can have control while the cancellation is
happening• The user need not acknowledge the results of the
cancellation
65 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 65
Specific Solution
Architectural view: Presentation of one (or more) aspects of the architecture.
Common views:
• Component Diagram – shows major units of software but does not show dynamic behavior or assignment of units
to various processors.
• Sequence Diagram – shows sequence of activities for a single thread through the system
66 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 66
Context of the specific solution: J2EE-MVC
:Controller
:View Active-
Command:Model
:Controller:Controller
:View:View Active-
Command:Model
Active-
Command:Model
67 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 67
Component diagram for a specific solution to Cancel
Prior-State-
Manager:Model
:Controller
Cancellation-Manager
:Model
Listener:Controller
:View Active-
Command:Model
Collaborating-
Process:Model
Prior-State-
Manager:Model
Prior-State-
Manager:Model
:Controller:Controller
Cancellation-Manager
:Model
Cancellation-Manager
:Model
Listener:ControllerListener:Controller
:View:View Active-
Command:Model
Active-
Command:Model
Collaborating-
Process:Model
Collaborating-
Process:Model
68 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 68
Responsibilities of new component –Listener
• Type Controller• Must always listen for the cancel command or
environmental changes (R3)
69 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 69
Responsibilities of new component –Cancellation Manager
• Type Model• Always listen and gather information (R3, R4)
• If the Active Command is not responding, handle the cancellation (R7, R10, R11, R12)
• Free resources (R14)• Estimate time to cancel (R19)
• Inform the user of Progress of the cancellation (R13,
R15, R20, R21)
Full text of responsibilities assigned to the Cancellation Manager in this example solution
R3. Must always listen for the cancel command or environmental changes
R4. Must always gather information (state, resource usage, actions, etc.) that allow for
recovery of the state of the system prior to the execution of the current command
R7. An active portion of the application must ask the infrastructure to cancel the command,
If R7, then R10. The collaborating processes have to be informed of the cancellation of the
invoking command (these processes have their own responsibilities that they must
perform in response to this information, possibly treat it as a cancellation.). The
information given to collaborating processes may include the request for cancellation,
the progress of cancellation, and/or the completion of cancellation.
If R7, then R11. Restore the system back to its state prior to execution of the command. OR
R12. Restore the system back to as close to the state prior to execution of the command
as possible
If R12, then R13. Inform the user of the difference between the prior state and the restored
state.
R14. All resources that can be freed must be freed.
If any resources are not capable of being freed, then R15. Inform the user of the partially-
restored resources in a manner that they will see it.
R19. Estimate the time it will take to cancel within 20%
R20. Inform the user of this estimate.
R21. Once the cancellation has finished the system must provide feedback to the user that
cancellation is finished, e.g., if cursor was changed to busy indicator, change it back to
normal; if progress bar was displayed was displayed, remove it; if dialog box was
provided, close it.
70 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 70
Responsibilities of new component –Prior State Manager
• Type Model
• Must always gather information (state, resource usage, actions, etc.) that allow for recovery of the state of the
system prior to the execution of the current command (R4)
• If the Active Command is not responding (R7), work with
the Cancellation Manager to restore the system back to its state prior to execution of the command (R11) or as
close as possible to that state (R12)
71 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 71
New responsibilities for old components - View
• Type View• Provide a button, menu item, keyboard shortcut and/or
other means to cancel the active command (R2)• Must always listen for the cancel command or
environmental changes (R3)• Provide feedback to the user about the progress of the
cancellation (R5, R13, R15, R20, R21)
Full text of responsibilities assigned to the View in this examp le solution
R2. Provide a button, menu item, keyboard shortcut and/or other means to cancel the active
command
R3. Must always listen for the cancel command or environmental changes
R5. Must acknowledge receipt of the cancellation command appropriately within 150 msec.
If any module did R12, then R13. Inform the user of the difference between the prior state and
the restored state.
If any module did R14, then R15. Inform the user of the partially -restored resources in a
manner that they will see it.
R20. Inform the user of the time estimate.
R21. Once the cancellation has finished the system must provide feedback to the user that
cancellation is finished, e.g., if cursor was changed to busy indicator, change it back to
normal; if progress bar was displayed was displayed, remove it; if dialog box was
provided, close it.
72 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 72
New responsibilities for old components - Active Command• Type Model
• Always gather information (R4)
• Handle the cancellation by terminating processes, and
restoring state and resources (R6, R10, R11, R12, R14)
• Provide appropriate feedback to the user (R13, R15, R19,
R20, R21)
Full text of responsibilities assigned to the Active Command in this example solution
R4. Must always gather information (state, resource usage, actions, etc.) that allow for
recovery of the state of the system prior to the execution of the current command
R6. The command must respond by canceling itself (I.e., it must fulfill Responsibilities R10 to
R21 (e.g., an object-oriented system would have a cancel method in each object)
If R6 then R10. The collaborating processes have to be informed of the cancellation of the
invoking command (these processes have their own responsibilities that they must
perform in response to this information, possibly treat it as a cancellation.). The
information given to collaborating processes may include the request for cancellation,
the progress of cancellation, and/or the completion of cancellation.
If R6, then R11. Restore the system back to its state prior to execution of the command. Or
R12. Restore the system back to as close to the state prior to execution of the command
as possible
If R12, then R13. Inform the user of the difference between the prior state and the restored
state.
R14. Resources that can be freedmust be freed
If any resources are not capable of being freed, then R15. Inform the user of the partially-
restored resources in a manner that they will see it.
R19. Estimate the time it will take to cancel within 20%
R20. Inform the user of this estimate.
R21. Once the cancellation has finished the system must provide feedback to the user that
cancellation is finished, e.g., if cursor was changed to busy indicator, change it back to
normal; if progress bar was displayed was displayed, remove it; if dialog box was
provided, close it.
73 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 73
Responsibilities not assigned or shown in our diagrams and why.• We are not considering a “critical task” where the
progress and results of the cancellation must effect user
behavior, therefore R16 and R18 are not assigned.• J2EE-MVC implicitly returns control to the user during
cancellation, so R17is not assigned.• Our diagram does not show the infrastructure in which
the application runs, therefore responsibilities assigned
to the infrastructure are not shown (R8, R9)
List of responsibilities not assigned to our components or not shown in the diagrams.
R8. The infrastructure itself must provide a means to request the cancellation of the application (e.g., task manager on Windows, force quit on MacOS)
R9. If either R7 or R8, then the infrastructure must have the ability to cancel the active
command (I.e., it must fulfill Responsibilities R10 to R21)
R16 Require acknowledgement from the user that they are aware of the partially-
restored nature of the cancellation. (we’re not doing a “critical task” in this example)
R17. Return control to the user, or not, depending on the forces from the task (implicit
in J2EE-MVC)
R18. If control cannot be returned to the user, inform the user of this fact (and ideally,
why that is the case) (we’re not doing a “critical task” in this example)
74 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 74
:View
Sequence diagram of activities prior to issuing cancel command
:Controller Active-
Command:Model
Prior-State-
Manager:Model
Cancellation-
Manager:Model
:User
normal
operation
invokeregister (R4)
save current state (R4)
normal
operation
Xxx put in note about the components that don’t show up in this sequence
75 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 75
command (R5)
:View Listener
:Controller
Active-
Command:Model
Prior-State-
Manager:Model
Cancellation
-Manager:Model
presscancelbutton (R1,2) send cancel
request (R2, R3) cancel activecommand (R3)
change cursor shape (R20)
acknowledgeuser’s
estimates cancel
time between1 and 10 secs
(R19, busy cursor needed)
are you alive? (R6)
yes (R6)
return original state (R11)
original state (R11)
releaseresources (R14)
exiting R21)
xrestore cursor (R21)
:User
Sequence diagram of activities after issuing cancel command
Xxx put in note about the components that don’t show up in this sequence
76 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 76
Comment on sequence diagrams
Important portion of cancel is that listener is on separate thread of control (otherwise listener may be blocked
because command is not responding and command owns the active thread).
Sequence diagram does not make this explicit. It is implicit
in fact that listener responds regardless of state of active
command.
Sequence diagram is UML (standard). Difficult to show threads in UML.
77 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 77
Small Group Exercise
Apply sample solution to real-world problem introduced in prior break out
Report-out to entire group
79 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 79
Schedule
A second USAP:
?Example with Observing System State USAP4:00-5:15
TopicTime
81 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 81
Types of Feedback
Observing System state: To inform users of the internal system state and state changes.
Progress indicator: To inform users that the system is processing an action that will take some time to complete.
Interaction Feedback: To inform users that the system has registered a user interaction, that is, that the system has heard users.
Warning: To inform users of any irreversible action.
82 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 82
USAP Template
Context• Situation• Conditions• Potential usability benefits
Problem and General Solution
Specific Solution
83 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 83
Observing System State:Situation
Potential Usability Benefits
Conditions
Situation: When some change in system state occurs, the user should be notified, specially when the state change affects to state information that is displayed.
84 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 84
Observing System State:Conditions
Potential Usability Benefits
Conditions: • A user may not be given the system state data necessary to operate the system (e.g., uninformative error messages, no file size given for folders). • The system state may be given in a way that violates human tolerances (e.g., displayed too quickly for people to read). • The system state may also be given unclearly, thereby confusing the user. • System designers should account for human needs and capabilities when deciding what aspects of a system state to display and how to do so.
Situation: When some change in system state occurs, the user should be notified.
85 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 85
Observing System State:Potential Usability Benefits
Potential Usability Benefits:A. Increase individual user effectiveness
A.1 Expedite routine performanceA.1.2 Reduce the impact of routine user errors (slips)
A.2 Improve non-routine performanceA.2.1 Support problem-solvingA.2.2 Facilitate learning
A.3 Reduce the impact of user mistakesA.3.2 Accommodate mistakes
C. Increase user confidence and comfort
Conditions: • A user may not be given the system state data necessary to…
Situation: When some change in system state occurs, the user should be notified.
86 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 86
USAP Template
Context
Problem and General Solution
Specific Solution
87 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 87
USAP Template
Context
Problem and General Solution• Forces exerted by the environment and the task
• Forces exerted by human desires and capabilities
• Forces exerted by the state of the software
• Responsibilities of the general solution that resolve the forces
Specific Solution
88 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 88
Observing System State:Human Forces (1/2)
1. When some change in system state occurs, the user should be notified (HF01)
2. If the system fails, the user should be notified(HF02)
3. Users need to be alerted of the fact that a command does not respond (HF03)
89 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 89
Observing System State:Environmental Forces
1. Resources, be it the network, a database, etc., can become not operational (EF01)
90 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 90
Observing System State:System Forces (1/2)
1. System state changes (SF01)
2. Systems sometimes fail (SF02)
3. Commands sometimes die (SF03)
91 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 91
Observing System State:Problem - Responsibilities
Responsibilities of thesoftware system thatresolve the forces
Forcesexerted by the state ofthe software
Forcesexerted by human desires andcapabilities
Forcesexerted by theenvironmentand the task
General SolutionProblem
92 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 92
Observing System State:Problem - Responsibilities
Problem/Forces:
SF01. The software changes
HF01. When some change in system state occurs, the user should be notified.
Solution/Responsibilities:
R01. The software should be able to listen to active commands, because they can provide information about the state of the system. If this information is useful to the user, the system should be able to provide this information to the user in the appropriate manner and in the proper location.
93 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 93
Observing System State:Problem - Responsibilities
Problem/Forces:
SF03. Commands sometimes fail to be operational
HF02: If the system fails, the user should be notified
HF03: To alert users of the fact that a command does not respond
Solution/Responsibilities:
R02: As active commands can fail, the software system should be able to check at any time whether a given command is being executed and, if the command fails, inform users that the command is not operational.
94 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 94
Observing System State:Problem - Responsibilities
Problem/Forces:
EF1: Resources, be it the network, a database, etc., can become not operational
Solution/Responsibilities:
R03: The software should be able to listen to or query external resources, like networks or databases, about their state, to inform properly the user if any resource is not performing properly.
95 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 95
Observing System State:Problem - Responsibilities
Problem/Forces:
HF01. When some change in system state occurs, the user should be notified.
Solution/Responsibilities:
R04: The software should be able to check the system resources and inform the user about their use.
96 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 96
USAP Template
Context
Problem and General Solution
Specific Solution• General responsibilities• Forces exerted by previous design decisions • Allocation of responsibilities to specific components• Rationale
97 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 97
Observing System State:General Responsibilities
R01: Listen to active commandsR02: Ascertain the state of active commandsR03: Listen to or query external sourcesR04: Check the state of system resources
98 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 98
Observing System State:Forces from design decisions
Architectural styles for the system will affect specific solution
We have used J2EE-MVC as an architectural style for designing a specific solution
99 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 99
Context of the specific solution:J2EE-MVC
:Controller
:View Active-Command:Model
:Controller:Controller
:View:View Active-Command:Model
Active-Command:Model
100 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 100
Observing System State:Allocation of responsibilities
R1. The software should be able to listen to active commands. If this information is useful to the user, the system should be able to provide this information to the user in the appropriate manner not only through the display.
Model: Should include an element that listens to active commands and, if the info is useful, sends it to the controller.View: Should be able to inform the user in the appropriate manner.Controller: Should be able to select the appropriate view to show the information to the user.
101 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 101
Observing System State:Allocation of responsibilities
R1
Model: Should include an element that listens to active commands and, if the info is useful, sends it to the controller.View: Should be able to inform the user in the appropriate manner.Controller: Should be able to select the appropriate view to show the information to the user.
Active Command: Represents the command in progress and should inform the appropriate feedbacker if the user is to be notified of somethingFeedbacker: Receives the
information to be displayed from the model or a change of view from the controller
Controller: Should be listening to the Viewer and, if the user requests an action creates the required command, an instance of active command
102 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 102
Observing System State:Allocation of responsibilities
Controller: Should be listening to the Viewer and, if the user requests an action creates the required command, an instance of active command
Controller: Should be able to select the appropriate view to show the information to the user.
Feedbacker: Receives the information to be displayed from the model or a change of view from the controller
View: Should be able to inform the user in the appropriate manner.
Active command: Represents the command in progress and should inform appropriate feedbacker if the user is to be notified of something
Model: The model should include an element that listens to active commands and, if the information is useful, sends the information to be passed on to the user (see model decomposition)
R01:The software should be able to listen to active commands, because they can provide information about the state of the system. If this information is useful to the user, the system should be able to provide this information to the user in the appropriate manner and in the appropriate location, not only through the display.
Allocation of responsibilities to specific components
Forces exerted by previous design decisions
General Responsibilities of the software
103 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 103
Observing System State:Specific Solution
Check whether or not the ongoing command is dead.
Check whether or not external resources are dead.
Check whether or not the system has enough resources to execute the ongoing command.
104 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 104
Observing System State:Specific Solution
Active Command:model
:View
:Controller
105 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 105
Observing System State:Specific Solution
Viewer:view
Feedbacker:view
Active Command:model
Resource Checker:model
System-Resource-Checker:model
:Controller
106 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 106
Observing System State:Responsibilities of new components
Must be able to check whether or not the system can provide enough resources to properly execute the ongoing command (R04)
System Resource Checker
(Type Model)
Must be able to check whether or not the ongoing command is alive (R02)Must be able to check whether or not the external resources are alive (R03)
Resource Checker(Type Model)
Receive info from Resource Checker and select the appropriate feedback (R02, R03, R04)
Feedbacker(Type Model)
RESPONSIBILITIESNEW COMPONENT
107 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 107
Observing System State:Specific Solution
Viewer:view
Feedbacker:view
Active Command:model
Resource Checker:model
System-Resource-Checker:model
:Controller
108 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 108
Observing System State:Responsibilities of old components
Must always listen for the viewer requests to create the respective active command.
Controller(Type Controller)
Represents the command in progress and should inform the Feedbacker about any change produced.
Active Command(Type Model)
Must be able to gather user requests.Viewer(Type View)
RESPONSABILITIESOLD COMPONENT
109 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 109
Observing System State:Responsibilities related to control
The Active Command should run in a different thread from the Resource Checker component
The Active Command should run in a different thread from the System Resource Checker component
110 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 110
Observing System State:Specific Solution
Imagine we are faced with a situation where:
The ongoing command is dead
111 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 111
Observing System State:Specific Solution
: Feedbacker: view
: User
: Viewer:view
: Controller : Active-Command: model : ResourceChecker:model
(EI02) Action( )(3) Action( )
(4) CreateCommand()
IP02 CheckCriticity( )
(IP01) CalculateElapsedTime( )
(IP03) CheckKindOfOperat ion()
(7) AreYouAliv e( )
(1) Feedback (ongoing command dead)
112 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 112
Observing System State:Specific Solution
Imagine we are faced with a situation where:
There are not enough resources to execute the ongoing command
113 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 113
Observing System State:Specific Solution
: Feedbacker: v iew
: User
: Viewer:v iew
: Controller : Activ e-Command: model : Systrem-Resource-Checker:model
(EI02) Action( )(3) Action( )
(4) CreateCommand()
(IR01) CheckSystemResouces(
(1) Feedback(close-the-sy stem)
114 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 114
Observing System State:Specific Solution
Imagine we are faced with a situation where:
The external resources are performing properly
115 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 115
Observing System State:Specific Solution
: Feedbacker: view
: User
: Viewer:view
: Controller : Active-Command: model
: External-Resouce
: ResourceChecker:model
IP01 and 1 U ntil end of operat ion
(EI02) Action( )(3) Action( )
(4) CreateCommand()
IP02 CheckCri ti city( )
(IP01) CalculateElapsedTime( )
(IP03) CheckKindOfOperation()
(1) Feedback(Kind-of-feedback, information)
(1) Feedback (end-of-operation)
(ER01) CheckExternalResources()
(ER02) ExternalResourceAv ailable()
116 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 116
Current status of USAPs
We have about two dozen architecturally sensitive scenarios
Four of these have been elaborated into force => general responsibilities
We are elaborating additional scenarios.
We are also looking for additional scenarios.
Goal is to produce a handbook.
117 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 117
Experiences of USAPs in development
Several Architectural Tradeoff Analyses conducted by the SEI used some of the architecturally-sensitive usability scenarios
NASA’s MERBoard, a large-screen collaborative tool used in the Mars Exploration Rover mission this winter, redesigned their architecture using the scenarios and USAPs
118 USAP Tutorial ICSE2004
USAP Tutorial ICSE 2004 - page 118
Tutorial Summary
Software architectural design can support iterative design through separation based patterns, but some usability issues are difficult to resolve through iterative design.
Architecturally sensitive scenarios are examples of problems that are difficult to implement once architecture is designed.
USAPs are an attempt to capture some of these problems, provide rationale to support cost/benefit analysis, provide general set of responsibilities for any solution, and provide sample specific solution to further guide software designer.
Currently have about two dozen architecturally sensitive scenarios and are in process of turning these into USAPs.
CHI 2004 John, Bass, Juristo & Sanchez-Segura Appendix I-1
Appendix IGeneral Usability Scenarios
(excerpt of Bass, L., John, B. E., & Kates, J. (2001). Achieving usabilitythrough software architecture (CMU/SEI-2001-TR-005). Pittsburgh, PA:Software Engineering Institute, Carnegie Mellon University)
This section enumerates the usability scenarios that we have identified as being architec-
turally sensitive. A general usability scenario describes an interaction that some
stakeholder (e.g., end user, developer, system administrator) has with the system under
consideration from a usability point of view.
We generated the list of usability scenarios by surveying the literature, by personal expe-
rience, and by asking colleagues [Gram 1996, Newman 1995, Nielsen 1993]. We also
screened the list so that all entries have explicit software architectural implications and
solutions. Section 5 provides an architectural pattern that implements each scenario given
in this report.
1. Aggregating Data
A user may want to perform one or more actions on more than one object. For example,
an Adobe® Illustrator® user may want to enlarge many lines in a drawing. It could be-
come tedious to perform these actions one at a time. Furthermore, the specific aggrega-
tions of actions or data that a user wishes to perform cannot be predicted; they result from
the requirements of each task. Systems, therefore, should allow users to select and act
upon arbitrary combinations of data.
2. Aggregating Commands
A user may want to complete a long-running, multi-step procedure consisting of several
commands. For example, a psychology researcher may wish to execute a batch of com-
mands on a data file during analysis. It could become tedious to invoke these commands
one at a time, or to provide parameters for each command as it executes. If the computer
is unable to accept the required inputs for this procedure up front, the user will be forced
to wait for each input to be requested. Systems should provide a batch or macro capabil-
ity to allow users to aggregate commands.
3. Canceling Commands
A user invokes an operation, then no longer wants the operation to be performed. The
user now wants to stop the operation rather than wait for it to complete. It does not matter
why the user launched the operation. The mouse could have slipped. The user could have
mistaken one command for another. The user could have decided to invoke another op-
eration. For these reasons (and many more), systems should allow users to cancel opera-
tions.
4. Using Applications Concurrently
A user may want to work with arbitrary combinations of applications concurrently. These
applications may interfere with each other. For example, some versions of IBM® Via-
Voice and Microsoft® Word contend for control of the cursor with unpredictable results.
CHI 2004 John, Bass, Juristo & Sanchez-Segura Appendix I-2
Systems should ensure that users can employ multiple applications concurrently without
conflict. (See: Supporting Multiple Activities)
5. Checking for Correctness
A user may make an error that he or she does not notice. However, human error is fre-
quently circumscribed by the structure of the system; the nature of the task at hand, and
by predictable perceptual, cognitive, and motor limitations. For example, users often type
“hte” instead of “the” in word processors. The frequency of the word “the” in English and
the fact that “hte” is not an English word, combined with the frequency of typing errors
that involve switching letters typed by alternate hands, make automatically correcting to
“the” almost always appropriate. Computer-aided correction becomes both possible and
appropriate under such circumstances. Depending on context, error correction can be en-
forced directly (e.g., automatic text replacement, fields that only accept numbers) or sug-
gested through system prompts.
6. Maintaining Device Independence
A user attempts to install a new device. The device may conflict with other devices al-
ready present in the system. Alternatively, the device may not function in certain specific
applications. For example, a microphone that uses the Universal Serial Bus (USB) may
fail to function with older sound software. Systems should be designed to reduce the se-
verity and frequency of device conflicts. When device conflicts occur, the system should
provide the information necessary to either solve the problem or seek assistance. (Devices
include printers, storage/media, and I/O apparatus.)
7. Evaluating the System
A system designer or administrator may be unable to test a system for robustness, cor-
rectness, or usability in a systematic fashion. For example, the usability expert on a de-
velopment team might want to log test users’ keystrokes, but may not have the facilities
to do so. Systems should include test points and data gathering capabilities to facilitate
evaluation.
8. Recovering from Failure
A system may suddenly stop functioning while a user is working. Such failures might
include a loss of network connectivity or hard drive failure in a user’s PC. In these or
other cases, valuable data or effort may be lost. Users should be provided with the means
to reduce the amount of work lost from system failures.
9. Retrieving Forgotten Passwords
A user may forget a password. Retrieving and/or changing it may be difficult or may
cause lapses in security. Systems should provide alternative, secure mechanisms to grant
users access. For example, some online stores ask each user for a maiden name, birthday,
or the name of a favorite pet in lieu of a forgotten password.
10. Providing Good Help
A user needs help. The user may find, however, that a system’s help procedures do not
adapt adequately to the context. For example, a user’s computer may crash. After re-
CHI 2004 John, Bass, Juristo & Sanchez-Segura Appendix I-3
booting, the help system automatically opens to a general table of contents rather than to
a section on restoring lost data or searching for conflicts. Help content may also lack the
depth of information required to address the user’s problem. For example, an operating
system’s help area may contain an entry on customizing the desktop with an image, but
may fail to provide a list of the types of image files that can be used. Help procedures
should be context dependent and sufficiently complete to assist users in solving problems.
11. Reusing Information
A user may wish to move data from one part of a system to another. For example, a tele-
marketer may wish to move a large list of phone numbers from a word processor to a da-
tabase. Re-entering this data by hand could be tedious and/or excessively time-
consuming. Users should be provided with automatic (e.g., data propagation) or manual
(e.g., cut and paste) data transports between different parts of a system. When such trans-
ports are available and easy to use, the user’s ability to gain insight through multiple per-
spectives and/or analysis techniques will be enhanced.
12. Supporting International Use
A user may want to configure an application to communicate in his or her language or
according to the norms of his or her culture. For example, a Japanese user may wish to
configure the operating system to support a different keyboard layout. However, an appli-
cation developed in one culture may contain elements that are confusing, offensive, or
otherwise inappropriate in another. Systems should be easily configurable for deployment
in multiple cultures.
13. Leveraging Human Knowledge
People use what they already know when approaching new situations. Such situations
may include using new applications on a familiar platform, a new version of a familiar
application, or a new product in an established product line.
New approaches usually bring new functionality or power. When, however, users are un-
able to apply what they already know, a corresponding cost in productivity and training
time is incurred. For example, new versions of applications often assign items to different
menus or change their names. As a result, users skilled in the older version are reduced to
the level of novices again, searching menus for the function they know exists.
System designers should strive to develop upgrades that leverage users’ knowledge of
prior systems and allow them to move quickly and efficiently to the new system.
14. Modifying Interfaces
Iterative design is the lifeblood of current software development practice, yet a system
developer may find it prohibitively difficult to change the user interface of an application
to reflect new functions and/or new presentation desires. System designers should ensure
that their user interfaces can be easily modified.
CHI 2004 John, Bass, Juristo & Sanchez-Segura Appendix I-4
15. Supporting Multiple Activities
Users often need to work on multiple tasks more or less simultaneously (e.g., check mail
and write a paper). A system or its applications should allow the user to switch quickly
back and forth between these tasks.
16. Navigating Within a Single View
A user may want to navigate from data visible on-screen to data not currently displayed.
For example, he or she may wish to jump from the letter “A” to the letter “Q” in an on-
line encyclopedia without consulting the table of contents. If the system takes too long to
display the new data or if the user must execute a cumbersome command sequence to
arrive at her or his destination, the user’s time will be wasted. System designers should
strive to ensure that users can navigate within a view easily and attempt to keep wait
times reasonably short. (See: Working at the User’s Pace)
17. Observing System State
A user may not be presented with the system state data necessary to operate the system
(e.g., uninformative error messages, no file size given for folders). Alternatively, the sys-
tem state may be presented in a way that violates human tolerances (e.g., is presented too
quickly for people to read. See: Working at the User’s Pace). The system state may also
be presented in an unclear fashion, thereby confusing the user. System designers should
account for human needs and capabilities when deciding what aspects of system state to
display and how to present them.
A special case of Observing System State occurs when a user is unable to determine the
level of security for data entered into a system. Such experiences may make the user
hesitate to use the system or avoid it altogether.
18. Working at the User’s Pace
A system might not accommodate a user’s pace in performing an operation. This may
make the user feel hurried or frustrated. For example, ATMs often beep incessantly when
a user “fails” to insert an envelope in time. Also, Microsoft Word’s scrolling algorithm
does not take system speed into account and becomes unusable on fast systems (the data
flies by too quickly for human comfort). Systems should account for human needs and
capabilities when pacing the stages in an interaction. Systems should also allow users to
adjust this pace as needed.
19. Predicting Task Duration
A user may want to work on another task while a system completes a long running op-
eration. For example, an animator may want to leave the office to make copies or to eat
while a computer renders frames. If systems do not provide expected task durations, users
will be unable to make informed decisions about what to do while the computer “works.”
Thus, systems should present expected task durations.
20. Supporting Comprehensive Searching
A user wants to search some files or some aspects of those files for various types of con-
tent. For example, a user may wish to search text for a specific string or all movies for a
CHI 2004 John, Bass, Juristo & Sanchez-Segura Appendix I-5
particular frame. Search capabilities may be inconsistent across different systems and
media, thereby limiting the user’s opportunity to work. Systems should allow users to
search data in a comprehensive and consistent manner by relevant criteria.
21. Supporting Undo
A user performs an operation, then no longer wants the effect of that operation. For ex-
ample, a user may accidentally delete a paragraph in a document and wish to restore it.
The system should allow the user to return to the state before that operation was per-
formed. Furthermore, it is desirable that the user then be able to undo the prior operation
(multi-level undo).
22. Working in an Unfamiliar Context
A user needs to work on a problem in a different context. Discrepancies between this new
context and the one the user is accustomed to may interfere with the ability to work. For
example, a clerk in business office A wants to post a payment for a customer of business
unit B. Each business unit has a unique user interface, and the clerk has only used unit
A’s previously. The clerk may have trouble adapting to business unit B’s interface (same
system, unfamiliar context.) Systems should provide a novice (verbose) interface to offer
guidance to users operating in unfamiliar contexts.
23. Verifying Resources
An application may fail to verify that necessary resources exist before beginning an op-
eration. This failure may cause errors to occur unexpectedly during execution. For exam-
ple, some versions of Adobe® PhotoShop® may begin to save a file only to run out of
disk space before completing the operation. Applications should verify that all necessary
resources are available before beginning an operation.
24. Operating Consistently Across Views
A user may become confused by functional deviations between different views of the
same data. Commands that had been available in one view may become unavailable in
another or may require different access methods. For example, users cannot run a spell
check in the Outline View utility found in a mid-90’s version of Microsoft Word. Systems
should make commands available based on the type and content of a user’s data, rather
than the current view of that data, as long as those operations make sense in the current
view.
For example, allowing users to perform operations on individual points in a scatter plot
while viewing the plot at such a magnification that individual points cannot be visually
distinguished does not make sense. A naïve user is likely to destroy the underlying data.
The system should prevent selection of single points when their density exceeds the
resolution of the screen, and inform the user how to zoom in, access the data in a more
detailed view, or otherwise act on single data points. (See: Providing Good Help and
Supporting Visualization)
25. Making Views Accessible
Users often want to see data from other viewpoints. For example, a user may wish to see
the outline of a long document and the details of the prose. If certain views become un-
CHI 2004 John, Bass, Juristo & Sanchez-Segura Appendix I-6
available in certain modes of operation, or if switching between views is cumbersome,
the user’s ability to gain insight through multiple perspectives will be constrained. (See:
Supporting Visualization)
26. Supporting Visualization
A user wishes to see data from a different viewpoint. Systems should provide a reason-
able set of task-related views to enhance users’ ability to gain additional insight while
solving problems. For example, Microsoft Word provides several views to help users
compose documents, including Outline and Page Layout modes.
27. Supporting Personalization(not in CMU/SEI-2001-TR-005)
A user wants to work in a particular configuration of features that the system provides.
The user may want this configuration to persist over multiple uses of the system (as op-
posed to having to set it up each time). Systems should enable a user to specify their pref-
erences for features and provide the possibility for these preferences to endure. For ex-
ample, customizing Netscape’s toolbar or saving a hierarchical structure of bookmarks.
CHI 2004 John, Bass, Juristo & Sanchez-Segura Appendix II-1
Appendix II
Details of the Usability Benefit Hierarchy
(excerpt from Bass, L., John, B. E., & Kates, J. (2001). Achiev-ing usability through software architecture (CMU/SEI-2001-TR-005). Pittsburgh, PA: Software Engineering Institute, CarnegieMellon University)
To create usable systems, designers must first ensure that their proposed products provide
the functionality their users actually need to perform work as opposed to the functionality
that the marketing or development team imagines they need. In other words, systems
must provide functionality that fits the individual, organizational, and social structure of
the work context. Although specifying and identifying needed functionality are funda-
mental steps in the development process, these design phases do not typically involve
architectural concerns. Thus, we will not discuss them here. (We refer readers interested
in these issues to Contextual Design [Beyer 1998].)
Assuming that the functionality needed by a system’s users is correctly identified and
specified, the usability of such a system can still be seriously compromised by architec-
tural decisions that hinder or even prevent the required benefits. In extreme cases, the
resulting system can become virtually unusable.
This section organizes and presents scenarios by their usability benefits. We arrived at the
hierarchy of usability benefits presented in Table 1 using a bottom-up process called the
affinity process [Beyer 1998]. We took this approach rather than taking an existing defi-
nition of usability and sorting the scenarios into it because it was not clear that architec-
turally sensitive scenarios would cover the typical range of usability benefits. However,
the resulting hierarchy does not differ significantly from organizations of usability given
by other authors [e.g., Newman 1995; Nielsen 1993; Shneiderman 1998], and we view
this as partial confirmation that our set of architecturally sensitive scenarios covers, in
some sense, the usability space. Each scenario occurs in one or more positions in the hi-
erarchy.
The entries in this chapter discuss each item of the usability benefit hierarchy. One prem-
ise of this work has been that the design of a system embodies tradeoffs between benefits
(usability) and cost (software engineering). Hence in each section, we discuss the appro-
priate messages for each benefit. This will enable the usability engineer to better argue
the potential benefits of each scenario and the software engineer to know what instru-
mentation should be embedded into the system to support the benefit calculations.
CHI 2004 John, Bass, Juristo & Sanchez-Segura Appendix II-2
Table 1. Usability Benefits Heirarchy
Increases individual user effectiveness
Expedites routine performance
Accelerates error-free portion of routine performance
Reduces the impact of routine user errors (slips)
Improves non-routine performance
Supports problem-solving
Facilitates learning
Reduces the impact of user errors caused by lack of knowledge (mistakes)
Prevents mistakes
Accommodates mistakes
Reduces the impact of system errors
Prevents system errors
Tolerates system errors
Increases user confidence and comfort
1 Increases Individual User Effectiveness
If addressed properly, the scenarios included in this category will improve the perform-
ance of individual users. Such increases in productivity, though seemingly small when
considered discretely, can aggregate to produce substantial benefits for an organization as
a whole.
1.1 Expedites routine performance
In a routine task, a user recognizes a situation, knows what the next goal should be, and
knows what to do to accomplish that goal. No problem-solving is necessary. All that re-
mains is for the user to recall and execute the commands necessary to complete the task.
When performing routine tasks, even skilled users will become faster but will probably
not develop new methods to complete their tasks [Card 1983]. This is in contrast to aproblem-solving or learning situation where the user is likely to discover or learn a new
method while performing a task. (For an example of learning and problem-solving be-
havior, see non-routine performance.)
Although users know what to do to accomplish routine tasks, they will still make errors.
In fact, observations of skilled users performing routine tasks reveal that about 20% of a
user’s time may be consumed by making, then recovering from, mistakes. These “routine
errors” result from “slips” in execution (e.g., hitting the wrong key or selecting the menu
item next to the one desired), rather than from a lack of knowledge (i.e., not knowing
which command to use). Slips can never be totally prevented if there are multiple actions
available to a user, but some system designs accommodate these errors more successfully
than others.
CHI 2004 John, Bass, Juristo & Sanchez-Segura Appendix II-3
Accelerates error-free portion of routine performance
Routine tasks take time for a user to recognize the situation, recall the next goal and the
method used to accomplish it, and to mentally and/or physically execute the commands to
accomplish the goal. We call the minimum required time to accomplish a task, assuming
no slips, the error-free portion of routine performance.
In practice, the actual performance time is the sum of this minimum time and the time it
takes to make and recover from slips. Systems can be designed to maximize error-free
performance time, thereby reducing time to perform routine tasks and increasing individ-
ual effectiveness.
Reduces the impact of routine user errors (slips)
The negative impact of routine user errors can be reduced in two ways. First, since users
will always slip, reducing the number of opportunities for error (roughly corresponding to
the number and difficulty of steps in a given procedure) will usually reduce its occur-
rence. Second, systems can be designed to better accommodate user slips by providing
adequate recovery methods.
1.2 Improves non-routine performance
In a non-routine task, a user does not know exactly what to do. In this situation, the user
may experiment within the interface by clicking on buttons either randomly or systemati-
cally to observe the effects. The user might guess at actions based on previous experi-
ence. He or she might also use a tutorial, a help system, or documentation. Success inthese “weak methods” of dealing with a new situation can be helped or hindered through
system design.
Supports problem-solving
Users employ problem-solving behavior when they do not know exactly what to do. This
behavior can be described as a search through a problem space [Newell and Simon 1972].
When confronted with a new problem, people guess at solutions based on previous expe-
rience, try things at random to see what happens, or search for the desired effect.
For this discussion, we assume that the user understands the goal of the task (e.g., I would
like to replace all occurrences of “bush” with “shrub”), but the user may have to search
through the system’s available commands to achieve the desired outcome.
Measures of how well a system supports problem-solving include
• the time it takes to accomplish a novel task
• the number of incorrect paths the user takes while accomplishing a novel task
• the type of incorrect paths the user takes while accomplishing a novel task (e.g., paths
that have unforeseen and permanent side effects or benign paths that change nothing
but simply add to the problem-solving time)
CHI 2004 John, Bass, Juristo & Sanchez-Segura Appendix II-4
• the time necessary to recover from incorrect paths (Systems that support UNDO usu-
ally score well on this measure.)
In addition to reducing time spent on incorrect paths, well-designed systems may actually
enhance users’ problem-solving capabilities, further improving productivity.
Facilitates learning
Humans continuously learn as they perform tasks. Even in routine situations, humans
continue to speed up with each repetition, eventually reaching a plateau where further
improvements in performance become nearly imperceptible. In non-routine situations,
people learn by receiving training, consulting instructions (using a help system, docu-
mentation, or asking a friend), by exploring the system, by applying previous experience
to the new situation, and/or by reasoning based on what they know (or think they know)
about a system. They may also learn by making a mistake, observing that the erroneous
action does not produce the desired result, and by remembering not to perform this action
again.
Measures of how well a system supports learning typically include
• the number of times a task must be performed by a user before it is completed with-
out error. (Often investigators include a repetition requirement to avoid the “luck”
factor; for example, a user must perform a task n times without error.)
• the time before a user fulfills the error-free repetition requirement (defined above)
• incidental learning measures, in which a user first performs a task until some level of
mastery is reached. The user then performs a different task that he or she has not
practiced. The problem-solving and learning measures associated with this second
task are measures of incidental learning.
1.3 Reduces the impact of user errors caused by lack of
knowledge (mistakes)
In addition to the errors people make even when they know how to accomplish their tasks
(slips, discussed above), people make errors when they do not know what to do in the
current situation. In a typical scenario, a user does not understand that the current situa-
tion differs in important ways from previously encountered situations, and therefore he or
she misapplies knowledge of procedures that have worked before.1 Errors due to lack of
knowledge are called mistakes.
1 It is often difficult to distinguish a mistake from an exploratory problem-solving action.Typically, a mistake is when the user “knows” what to do and is wrong; while prob-lem-solving is when the user doesn’t know what to do and is trying to find the correctway. Therefore, the difference can only be detected through means other than theobservation of actions – think-aloud protocols or interviews about what a person in-tended when taking an action, or his or her response when the action does not havethe intended result (which indicates a mistake) typically allow observers to make thisdistinction. However, for architecture design, this distinction is not important; someusers may be problem-solving and others making mistakes, but the architectureshould support both.
CHI 2004 John, Bass, Juristo & Sanchez-Segura Appendix II-5
Design cannot prevent all mistakes, but careful design can prevent some of them. For ex-
ample, a typical technique to help prevent mistakes is to gray out inapplicable menu
items. Since some mistakes will still occur, systems should also be designed to accom-
modate them.
Prevents mistakes
The following are typical measures of how well a system helps to prevent mistakes:
• the number of mistaken actions that a user could make while completing a task
• the type of mistakes the user could make while accomplishing a task (e.g., paths that
have unforeseen and permanent side effects, or benign paths that change nothing)
(While these measures appear similar to those associated with problem-solving; that case
focuses on how well the system guides the user back to the correct path. Preventing mis-
takes focuses on how well the system guides the user away from an incorrect path. The
difference is subtle.)
Accommodates mistakes
Since mistakes will occur if the user has the freedom to stray from a correct path, the
system should accommodate these errors. The most telling measures of such accommo-
dation are
• the degree to which the system can be restored to the state prior to the mistake
• the time necessary to recover from mistakes (Systems that support UNDO usually
score well on this measure.) This duration includes the time needed to restore all data
and resources to the state before the error.
2 Reduces the Impact of System Errors
Systems will always operate with some degree of error. Networks will go down, power
failures will occur, and applications will contend for resources and conflict. Design can-
not prevent all system errors, but careful design can prevent some of them. All systems
should be designed to tolerate system errors. This section differs from section 3.1. “Re-
duces the impact of routine user errors” only in the source of the error discussed. Here,
we address system
error, not user error. The measures stay the same but the object of measurement becomes
the system.
2.1 Prevents system errors
As with preventing mistakes, the measures associated with preventing system errors are
the number and type of error that occur as a user performs a task.
CHI 2004 John, Bass, Juristo & Sanchez-Segura Appendix II-6
2.2 Tolerates system errors
Since system errors will occur, systems should be set up to tolerate them. Again, as with
accommodating mistakes, the most telling measures of error tolerance are
• the degree to which the system state can be restored to the state before the error.
• the time necessary to recover from errors. This duration includes the time needed to
restore all data and resources to the system state before the error.
3 Increases user confidence and comfortIn the scenarios included in this category, the benefits do not involve users’ effi-ciency, problem-solving processes, ability to learn, or propensity to make mis-takes. The benefits do involve how they feel about the system; for some architec-tural decisions do facilitate or inhibit capabilities that increase user confidenceand comfort, and this may be of value to an organization. Measures of confidenceand comfort are more indirect than the time- and error-based metrics in the pre-ceding categories, and typically involve questionnaires or interviews, or analysisof buying behavior (e.g., return customers and referrals).
CHI 2004 John, Bass, Juristo & Sanchez-Segura Appendix III-1
Appendix III: Usability Supporting Architectural Pattern TemplateBonnie E. John, Len Bass, Maribel Sanchez-Segura, and Rob J. Adams, Sept. 2004
Name: Usability Supporting Architectural Patterns must have suggestive names, which give an idea of the
problem addressed and the solution in a word or two.
Usability Context
The context is divided into three parts: the situation (or general usability scenario), the conditions under
which this situation is relevant, and the potential benefits to the users if the problem arising from this
situation is solved.
Situation: A brief description of the situation that makes this pattern useful from the user’s
viewpoint.
Conditions: Any conditions concerning the situation constraining when the pattern is useful
Potential Usability Benefits: A brief description of the benefits to the user if the solution is
implemented. We use the usability benefit hierarchy taken from Bass & John to express these
benefits.
Problem
The problem is expressed as the requirements arising from human desires and capabilities and the task
versus the constraints deriving from the state of the software or the environment. These forces result in
responsibilities that the software must fulfil to solve the problem. The responsibilities are part of the
solution, but it is valuable to see how they arise. They are, therefore, presented here.
Forces exerted by the
environment and task
Forces exerted by
human desires and
capabilities
Forces exerted by the
state of the software
system
Responsibilities of the general
solution
This field describes the
state of the
environment and the
task, which may
include issues of task
criticality or control,
among others.
This field describes the
human desires and
needs, which may
include issues of
salience or control,
among others.
This field describes the
state of the software,
which may include
issues of resources and
control, among others.
This field contains the
responsibility of the software
and an argument about why this
responsibility is necessary
given the user/task needs and/or
the system/environment
constraints.
Specific Solution
The specific solution is situated in a partial design that reflects requirements that the designer believes are
more important than cancel. The designer will make particular choices of overall architecture, MVC is one
example, we need to present our table as an example of how the general solution is customised for the
overall architecture.
General
responsibilities of the
software
Forces exerted by
previous design
decisions
Allocation of
responsibilities to
specific components
Rationale
This field describes the
general responsibilities
of the software
identified in the
problem description.
This field describes the
forces that come from
design decisions taken
independently of
usability aspects but
that influence the way
in which these aspects
must be designed.
This field describes the
responsibilities of the
software components
involved in the design
of the usability aspects.
Justification of how this
allocation of responsibilities to
specific modules satisfies the
problem.
Components diagram of specific solution
Sequence diagram of specific solution
Deployment diagram of specific solution (if necessary)
Fo
rces
ex
erte
d b
y t
he
env
iro
nm
ent
an
d t
ask
Fo
rces
ex
erte
d b
y h
um
an
des
ires
an
d c
ap
ab
ilit
ies
Res
po
nsi
bil
itie
s th
at
mu
st
be
sati
sfie
d b
y a
ny
so
ftw
are
des
ign
so
luti
on
:
Net
wo
rks
are
som
etim
es
un
resp
on
siv
e.
So
met
imes
ch
ang
es i
n t
he
env
iro
nm
ent
req
uir
e th
e sy
stem
to
ter
min
ate
Use
rs h
ave
to c
om
mu
nic
ate
thei
r in
ten
tio
ns
to t
he
soft
war
e th
rou
gh
o
ver
t ac
ts (
e.g
., f
ing
er
mo
vem
ents
)
R2
. P
rov
ide
a b
utt
on
, m
enu
it
em,
key
bo
ard
sh
ort
cut
and
/or
oth
er m
ean
s to
can
cel
the
acti
ve
com
man
d.
R4
. M
ust
alw
ays
gat
her
in
form
atio
n (
stat
e, r
eso
urc
e u
sag
e, a
ctio
ns,
etc
.) t
hat
all
ow
fo
r re
cov
ery
of
the
stat
e o
f th
e sy
stem
pri
or
to t
he
exec
uti
on
of
the
curr
ent
com
man
d
Re
lati
on
sh
ip o
f F
orc
es
to
Ge
ne
ral
Re
sp
on
sib
ilit
ies
fo
r C
an
ce
llin
g C
om
ma
nd
s
Bo
nn
ie E
. J
oh
n,
Le
n B
as
s,
Ma
rib
el
Sa
nc
he
z-S
eg
ura
, R
ob
Ad
am
s,
Els
a G
old
en
19
-Fe
b-2
00
4
So
ftw
are
has
to
rec
eiv
e an
act
ion
fr
om
th
e u
ser
to d
o s
om
eth
ing
R1
. M
ust
pro
vid
e a
mea
ns
to
cance
l a
com
man
d
Fo
rces
ex
erte
d b
y t
he
sta
te o
f
the
soft
wa
re
No
on
e ca
n p
red
ict
wh
en t
he
env
iro
nm
ent
wil
l ch
ang
eN
o o
ne
can
pre
dic
t w
hen
th
e u
sers
w
ill
wan
t to
can
cel
com
man
ds
Ap
pe
nd
ix I
V
R3
. M
ust
alw
ays
list
en f
or
the
can
cel
com
man
d o
r
Use
rs s
lip
or
mak
e m
ista
kes
, o
r ex
plo
re c
om
man
ds
and
th
en
chan
ge
thei
r m
ind
s, b
ut
do
no
t w
ant
to w
ait
for
the
com
man
d t
o
com
ple
te.
So
ftw
are
is s
om
etim
es
un
resp
on
siv
e
CH
I 2004
Jo
hn
, B
ass,
Ju
risto
Sa
nch
ez-S
eg
ura
AppIV
-1
Use
r n
eed
s to
kn
ow
th
at t
he
com
man
d w
as r
ecei
ved
wit
hin
1
50
mse
c, o
r th
ey w
ill
try
ag
ain
.
R5
. M
ust
ack
no
wle
dg
e re
ceip
t of
the
cance
llat
ion c
om
man
d
app
rop
riat
ely
wit
hin
15
0 m
sec.
T
he
ack
no
wle
dg
emen
t m
ust
be
app
rop
riat
e to
th
e m
ann
er i
n
wh
ich
th
e co
mm
and
was
iss
ued
.
It c
an b
e as
sum
ed t
hat
a u
ser
is
lookin
g a
t a
butt
on a
s th
ey c
lick
it
. P
eop
le c
an s
ee c
han
ges
in
co
lor
in t
hei
r fo
vea
.
Fo
r ex
amp
le,
if t
he
use
r p
ress
ed a
can
cel
bu
tto
n,
chan
gin
g t
he
colo
r o
f th
e b
utt
on
wil
l b
e se
en.
Peo
ple
can
see
ch
ang
es i
n
inte
nsi
ty i
n t
hei
r p
erip
her
al
vis
ion
.
If t
he
use
r u
sed
a k
eyb
oar
d
sho
rtcu
t, f
lash
ing
th
e m
enu
th
at c
onta
ins
that
com
man
d
mig
ht
be
app
rop
riat
e.
EIT
HE
RR
6.
Th
e co
mm
and
mu
st r
esp
on
d
by
can
cell
ing
its
elf
(I.e
., i
t m
ust
fu
lfil
l R
esp
on
sib
ilit
ies
R1
0 t
o
R2
1 (
e.g
., a
n o
bje
ct-o
rien
ted
sy
stem
wo
uld
hav
e a
can
cel
met
hod i
n e
ach o
bje
ct)
R7
. A
n a
ctiv
e p
ort
ion
of
the
app
lica
tio
n m
ust
ask
th
e in
fras
tru
ctu
re t
o c
ance
l th
e co
mm
and, or
R8
. T
he
infr
astr
uct
ure
its
elf
mu
st p
rov
ide
a m
ean
s to
req
ues
t th
e ca
nce
llat
ion o
f th
e ap
pli
cati
on
(e.
g.,
tas
k m
anag
er
on
Win
do
ws,
fo
rce
qu
it o
n
Mac
OS
)
Th
e co
mm
and
its
elf
is
resp
on
siv
e at
th
e ti
me
of
cance
llat
ion
OR
Th
e co
mm
and
its
elf
is
no
t re
spo
nsi
ve
at t
he
tim
e o
f ca
nce
llat
ion
Th
e ta
sk o
r en
vir
on
men
t h
as
indic
ated
that
the
com
man
d
sho
uld
sto
p (
e.g
., t
he
OS
has
d
eter
min
ed t
hat
th
ere
is n
ot
enough m
emory
to c
onti
nue)
Use
r h
as c
om
mu
nic
ated
a d
esir
e fo
r th
e co
mm
and
to
sto
p
CH
I 2004
Jo
hn
, B
ass,
Ju
risto
Sa
nch
ez-S
eg
ura
AppIV
-2
R9
. If
eit
her
R7
or
R8
, th
en t
he
infr
astr
uct
ure
mu
st h
ave
the
abil
ity t
o c
ance
l th
e ac
tive
com
man
d w
ith
wh
atev
er h
elp
is
avai
lab
le f
rom
th
e ac
tiv
e p
ort
ion
o
f th
e ap
pli
cati
on
(I.
e.,
it m
ust
fu
lfil
l R
esp
on
sib
ilit
ies
R1
0 t
o
R21)
R10. T
he
coll
abora
ting
pro
cess
es h
ave
to b
e in
form
ed o
f th
e ca
nce
llat
ion o
f th
e in
vokin
g
com
man
d (
thes
e p
roce
sses
hav
e th
eir
ow
n r
esp
on
sib
ilit
ies
that
th
ey m
ust
per
form
in
res
po
nse
to
th
is i
nfo
rmat
ion
, p
oss
ibly
tre
at i
t as
a c
ance
llat
ion
.).
Th
e in
form
atio
n g
iven
to
co
llab
ora
tin
g p
roce
sses
may
in
clu
de
the
req
ues
t fo
r ca
nce
llat
ion
, th
e p
rog
ress
of
cance
llat
ion, an
d/o
r th
e co
mple
tion o
f ca
nce
llat
ion.
EIT
HE
Rth
e sy
stem
is
cap
able
of
roll
ing
bac
k a
ll c
han
ges
to
th
e st
ate
pri
or
to
exec
uti
on
of
the
com
man
d.
R1
1.
Res
tore
th
e sy
stem
bac
k t
o
its
stat
e p
rio
r to
ex
ecu
tio
n o
f th
e co
mm
and.
R1
2.
Res
tore
th
e sy
stem
bac
k t
o
as c
lose
to
th
e st
ate
pri
or
to
exec
uti
on
of
the
com
man
d a
s p
oss
ible
R1
3.
Info
rm t
he
use
r o
f th
e d
iffe
ren
ce b
etw
een
th
e p
rio
r st
ate
and
th
e re
sto
red
sta
te.
Use
r w
ish
es t
o o
per
ate
the
syst
em
as i
f th
eir
com
man
d h
ad n
ot
bee
n
issu
ed.
OR
the
syst
em i
s n
ot
cap
able
o
f ro
llin
g b
ack
so
me
of
the
chan
ges
mad
e d
uri
ng
th
e o
per
atio
n o
f th
e co
mm
and
pri
or
to
cance
lati
on
The
com
man
d h
as i
nvoked
co
llab
ora
tin
g p
roce
sses
CH
I 2004
Jo
hn
, B
ass,
Ju
risto
Sa
nch
ez-S
eg
ura
AppIV
-3
Th
e sy
stem
sh
ou
ld r
emai
n s
tab
le
ov
er t
ime
(if
ther
e ar
e re
sou
rces
n
ot
retu
rned
, it
may
lea
d t
o
sub
seq
uen
t sy
stem
cra
sh,
e.g
.,
mem
ory
lea
k)
Use
r w
ants
th
e so
ftw
are
to r
etu
rn
to t
he
pre
-co
mm
and
sta
te.
R1
4.
All
res
ou
rces
th
at c
an b
e fr
eed
mu
st b
e fr
eed
Use
rs n
eed
to
kn
ow
to
wh
at
deg
ree
this
des
ire
was
ach
iev
ed
(bec
ause
it
may
eff
ect
wh
at t
hey
d
o i
n t
hei
r c
urr
ent
or
futu
re t
ask
s)
IFso
me
reso
urc
es h
as b
een
ir
rev
oca
bly
co
nsu
med
an
d c
ann
ot
be
rest
ore
d
R1
5.
Info
rm t
he
use
r o
f th
e p
arti
ally
-res
tore
d r
eso
urc
es i
n a
m
ann
er t
hat
th
ey w
ill
see
it.
Fo
r cr
itic
al t
ask
s, t
he
inab
ilit
y t
o
rest
ore
sta
te o
r re
sou
rces
may
re
qu
ire
exte
rnal
act
ion
s to
ac
kn
ow
led
ge
the
par
tial
res
tore
Use
rs m
ay n
ot
alw
ays
be
pay
ing
at
ten
tio
n,
or
may
fo
rget
to
tak
e ac
tion
R1
6.
Req
uir
e ac
kn
ow
led
gem
ent
fro
m t
he
use
r th
at t
hey
are
aw
are
of
the
par
tial
ly-r
esto
red
nat
ure
o
f th
e ca
nce
llat
ion
.
Use
r w
ants
to
mu
lti-
task
dep
endin
g o
n t
he
tim
e it
wil
l ta
ke
to c
ance
l th
e co
mm
and, ty
pic
ally
m
ore
th
an 1
sec
on
d.
R1
7.
Ret
urn
co
ntr
ol
to t
he
use
r,
or
no
t, d
epen
din
g o
n t
he
forc
es
fro
m t
he
task
R1
8.
If c
on
tro
l ca
nn
ot
be
retu
rned
to
th
e u
ser,
in
form
th
e u
ser
of
this
fac
t (a
nd
id
eall
y,
wh
y t
hat
is
the
case
)R
19
. E
stim
ate
the
tim
e it
wil
l ta
ke
to c
ance
l w
ithin
20%
R2
0.
Info
rm t
he
use
r o
f th
is
esti
mat
e.If
th
e es
tim
ate
is b
etw
een
1
and
10
sec
on
ds,
ch
ang
ing
th
e cu
rso
r sh
ape
is s
uff
icie
nt.
If t
he
esti
mat
e is
mo
re t
han
10
se
con
ds,
an
d t
ime
esti
mat
e is
w
ith
20
%,
then
a p
rog
ress
in
dic
ato
r is
bet
ter.
EIT
HE
R i
t is
no
t cr
itic
ally
im
po
rtan
t to
th
e ta
sk t
hat
th
e ca
nce
llat
ion
be
com
ple
te b
efo
re
anoth
er a
ctio
n c
an b
e ta
ken
Use
rs e
xp
ect
accu
rate
fee
db
ack
(w
ith
in 2
0%
, se
e T
N)
so t
hey
can
p
lan
th
eir
mu
ltit
ask
ing
.
Th
e co
mm
and
tak
es m
ore
th
an 1
se
con
d t
o c
ance
l
OR
it
is c
riti
call
y i
mp
ort
ant
to
the
task
that
the
cance
llat
ion b
e co
mp
lete
bef
ore
an
oth
er a
ctio
n
can b
e ta
ken
CH
I 2004
Jo
hn
, B
ass,
Ju
risto
Sa
nch
ez-S
eg
ura
AppIV
-4
If e
stim
ate
is m
ore
th
an 1
0
seco
nd
s b
ut
can
no
t b
e es
tim
ated
acc
ura
tely
, co
nsi
der
o
ther
alt
ern
ativ
es (
see
TN
, fo
otn
ote
8)
Use
r w
ants
to
be
no
tifi
ed w
hen
th
e ca
nce
llat
ion
has
fin
ish
edR
21
. O
nce
th
e ca
nce
llat
ion
has
fi
nis
hed
th
e sy
stem
mu
st p
rov
ide
feed
bac
k t
o t
he
use
r th
at
can
cell
atio
n i
s fi
nis
hed
, e.
g.,
if
curs
or
was
ch
ang
ed t
o b
usy
in
dic
ator,
chan
ge
it b
ack t
o
no
rmal
; if
pro
gre
ss b
ar w
as
dis
pla
yed
was
dis
pla
yed
, re
mo
ve
it;
if d
ialo
g b
ox
was
pro
vid
ed,
clo
se i
t.
CH
I 2004
Jo
hn
, B
ass,
Ju
risto
Sa
nch
ez-S
eg
ura
AppIV
-5
CHI 2004 John, Bass, Juristo & Sanchez-Segura ref-1
References
References in Usability and Software Architecture
Bass, L. J. & John, B. E. (2000) Achieving Usability Through Software Ar-chitectural Styles. Extended Abstracts of CHI, 2000 (The Hague, TheNetherlands, April 1-6, 2000) ACM, New York. pp. 502-509.
Bass, L., John, B. E. (2002) Supporting the CANCEL command throughsoftware architecture, CMU/SEI-2002-TN-021. Pittsburgh, PA: SoftwareEngineering Institute, Carnegie Mellon University.http://www.sei.cmu.edu/publications/documents/02.reports/02tn021.html
Bass, L. J. & John, B. E. (2003) Linking usability to software architecturepatterns through general scenarios. Journal of Systems and Software,66(3), 187-197.
John, B. E. & Bass, L. J. (2001) Usability and software architecture. Be-haviour and Information Technology, 20(5), 329-338.
Bass, L., John, B. E. & Kates, J. (2000) Achieving usability through soft-ware architecture (CMU/SEI-2001-TR-005). Pittsburgh, PA: Software En-gineering Institute, Carnegie Mellon University.http://www.sei.cmu.edu/publications/documents/01.reports/01tr005.html
Juristo , N., Moreno, A. M., & Sanchez, M. (2003) Deliverable D.3.4.Techniques, patterns and styles for architecture-level usability improve-ment. - ESPRIT project (IST-2001-32298)http://www.ls.fi.upm.es/status/results/deliverables.html
References in software engineering and software architec-ture
Bachmann, F., Bass, L., Chastek, G., Donohoe, P., & Peruzzi, F. (2000)The architecture based design method (CMU/SEI-2000-TR-001). Pitts-burgh, PA: Software Engineering Institute, Carnegie Mellon University.http://www.sei.cmu.edu/publications/documents/00.reports/00tr001.html
Bass, L.; Clements, P. & Kazman, R. (2003). Software Architecture inPractice. 2nd edition. Reading, MA: Addison Wesley Longman.
Buschmann, F., Meuneir, R, Rohnert, H., Sommerlad, P. and Stal, M.,(1996) Pattern-Oriented Software Architecture, A System of Patterns,Chichester, Eng: John Wiley and Sons.Clements, P., Bachmann, F., Bass, L., Garlan, D., Ivers, J., Little, R.,Nord, R., & Stafford J., (2003) Documenting Software Architectures: Viewsand Beyond, Addison Wesley.
Clements, P., Kazman, R, & Klein, M. (2001). Evaluating software archi-tectures: Methods and case studies. Boston: Addison-Wesley.
CHI 2004 John, Bass, Juristo & Sanchez-Segura ref-2
Gamma, E., Helm, R., Johnson, R., Vlissides, J., (1995) Design Patterns,Elements of Reusable Object-Oriented Software, Reading, Ma: AddisonWesley Longman.
Hillside Group: Information about patterns and pattern languages can befound at http://www.hillside.net/ (19 February 2004).
J2EE-MVC is documented athttp://java.sun.com/blueprints/patterns/MVC-detailed.html(19 February 2004).
Klein, M. & Bachmann, F. (2000). Quality Attribute Design Primitives(CMU/SEI-2000-TN-2000-017). Pittsburgh, PA: Software Engineering In-stitute, Carnegie Mellon University.www.sei.cmu.edu/publications/documents/00.reports/00tr017.html
Laprie, J.-C. (1992) Dependability: Basic Concepts and Terminology.Springer-Verlag: Vienna.McCall, J. (2001) Quality Factors. In Encyclopedia of Software Engi-neering (2nd edition) John Marciniak, ed., John Wiley, New York, pp 1083-1093Smith, C. & Williams, L., (2001) Performance Solutions: A Practical Guideto Creating Responsive, Scalable Software. Reading, Ma.:Addison WesleyLongman.
References in human performance usability
Beyer, H. & Holtzblatt, K. (1998) Contextual Design. San Francisco, CA:Morgan Kaufmann Publishers, Inc.
Card, S. K., Moran, T. P. & Newell, A. (1983) The Psychology of Human-Computer Interaction. Hillsdale, NJ: Erlbaum.
Gram, C. & Cockton, G. (1996) Design Principles for Interactive Systems.London, England: Chapman and Hall.
Newell, A. & Simon, H. A. (1972) Human Problem Solving. EnglewoodCliffs, NJ: Prentice-Hall.
Newman, W. & Lamming, M. (1985) Interactive System Design. Woking-ham, England: Addison-Wesley Publishing.
Nielsen, J. (1993) Usability Engineering. Boston, MA: Academic Press Inc.
Shneiderman, B. (1998) Designing the User Interface, 3rd ed. Reading,MA: Addison-Wesley.
1
Usa
bil
ity
Su
pp
orti
ng
Arch
itectu
ra
l P
att
ern
(te
mp
late
)
Na
me:
Usa
bil
ity
Su
pp
ort
ing
Arc
hit
ectu
ral
Pat
tern
s m
ust
hav
e su
gg
esti
ve
nam
es,
wh
ich
giv
e an
id
ea o
f th
e
pro
ble
m a
ddre
ssed
and t
he
solu
tion i
n a
word
or
two.
Usa
bil
ity
Co
nte
xt
Th
e c
on
tex
t is
div
ided
in
to t
hre
e p
arts
: th
e si
tuat
ion
(o
r g
ener
al u
sab
ilit
y s
cen
ario
), t
he
con
dit
ion
s u
nd
er
wh
ich
th
is si
tuat
ion
is
re
lev
ant,
an
d th
e p
ote
nti
al b
enef
its
to th
e u
sers
if
th
e p
rob
lem
ar
isin
g fr
om
th
is
situ
atio
n i
s so
lved
.
Sit
ua
tio
n:
A
bri
ef
des
crip
tio
n
of
the
situ
atio
n th
at m
akes
th
is p
atte
rn u
sefu
l fr
om
th
e u
ser’
s
vie
wp
oin
t.
Co
nd
itio
ns:
An
y c
on
dit
ion
s co
nce
rnin
g t
he
situ
atio
n c
on
stra
inin
g w
hen
th
e p
atte
rn i
s u
sefu
l
Po
ten
tia
l U
sab
ilit
y B
enef
its:
A
b
rief
d
escr
ipti
on
o
f th
e b
enef
its
to th
e u
ser
if th
e so
luti
on
is
imp
lem
ente
d.
We
use
th
e u
sab
ilit
y b
enef
it h
iera
rch
y t
aken
fro
m B
ass
& J
oh
n t
o e
xp
ress
th
ese
ben
efit
s.
Pro
ble
m
Th
e p
rob
lem
is
ex
pre
ssed
as
th
e re
qu
irem
ents
ar
isin
g fr
om
h
um
an d
esir
es an
d ca
pab
ilit
ies
and
th
e ta
sk
vers
us
the c
on
stra
ints
deri
vin
g f
rom
th
e s
tate
of
the
soft
war
e o
r th
e en
vir
on
men
t. T
hes
e fo
rces
res
ult
in
resp
on
sib
ilit
ies
that
th
e so
ftw
are
mu
st
fulf
il
to
solv
e th
e p
rob
lem
. T
he
resp
on
sib
ilit
ies
are
par
t o
f th
e
solu
tio
n,
bu
t it
is
val
uab
le t
o s
ee h
ow
th
ey a
rise
. T
hey
are
, th
eref
ore
, p
rese
nte
d h
ere.
Forc
es e
xer
ted
by t
he
en
vir
on
men
t a
nd
ta
sk
Fo
rces
ex
erte
d b
y
hu
ma
n d
esir
es a
nd
cap
ab
ilit
ies
Fo
rces
ex
erte
d b
y t
he
state
of
the
soft
ware
syst
em
Res
po
nsi
bil
itie
s o
f th
e g
ener
al
solu
tio
n
Th
is f
ield
des
crib
es t
he
stat
e o
f th
e
env
iro
nm
ent
and
th
e
task
, w
hic
h m
ay
incl
ud
e is
sues
o
f ta
sk
crit
ical
ity
o
r co
ntr
ol,
among o
ther
s.
Th
is f
ield
des
crib
es t
he
hu
man
d
esir
es
and
need
s,
wh
ich
m
ay
inclu
de
issu
es
of
sali
ence
o
r co
ntr
ol,
amo
ng
oth
ers.
Th
is f
ield
des
crib
es t
he
stat
e o
f th
e so
ftw
are,
wh
ich
m
ay
in
clu
de
issu
es o
f re
sou
rces
an
d
con
tro
l, a
mo
ng
oth
ers.
This
fi
eld
conta
ins
the
resp
on
sib
ilit
y
of
the
soft
war
e
and
an
arg
um
ent
abo
ut
wh
y t
his
res p
on
sib
ilit
y
is
nec
essa
ry
giv
en t
he
use
r/ta
sk n
eed
s an
d/o
r
the
syst
em/e
nv
iro
nm
ent
co
nst
rain
ts.
2
Sp
ecif
ic S
olu
tio
n
Th
e sp
ecif
ic s
olu
tio
n i
s si
tuate
d i
n a
part
ial
desi
gn
th
at
refl
ects
req
uir
em
en
ts t
hat
the d
esi
gn
er
beli
ev
es
are
mo
re i
mp
ort
ant
than
can
cel.
Th
e d
esig
ner
wil
l m
ake
par
ticu
lar
cho
ices
of
ov
eral
l ar
chit
ectu
re,
MV
C i
s o
ne
ex
am
ple
, w
e n
eed
to
pre
sen
t o
ur
tab
le a
s an
ex
am
ple
of
how
th
e g
en
era
l so
luti
on
is
cu
sto
mis
ed
fo
r th
e
ov
eral
l ar
chit
ectu
re.
Gen
era
l
resp
on
sib
ilit
ies
of
the
soft
wa
re
Fo
rces
ex
erte
d b
y
prev
iou
s d
esi
gn
dec
isio
ns
All
oca
tio
n o
f
resp
on
sib
ilit
ies
to
spec
ific
com
pon
ents
Ra
tio
na
le
Th
is f
ield
des
crib
es t
he
gen
eral
re
spo
nsi
bil
itie
s
of
the
soft
ware
iden
tifi
ed
in
the
pro
ble
m d
escr
ipti
on.
Th
is f
ield
des
crib
es t
he
forc
es
that
co
me
fro
m
des
ign
d
ecis
ion
s ta
ken
ind
ep
en
den
tly
o
f
usa
bil
ity
asp
ects
b
ut
that
in
flu
ence
th
e w
ay
in w
hic
h th
ese
as p
ects
mu
st b
e d
esig
ned
.
This
fie
ld d
escri
bes
the
resp
on
sib
ilit
ies
of
the
soft
ware
co
mp
on
en
ts
inv
olv
ed
in
the
des
ign
of
the
usa
bil
ity
asp
ects
.
Just
ific
atio
n
of
how
th
is
allo
cati
on
of
resp
on
sib
ilit
ies
to
specif
ic
mo
du
les
sati
sfie
s th
e
pro
ble
m.
Co
mp
on
en
ts d
iag
ra
m o
f sp
ecif
ic s
olu
tio
n
Seq
uen
ce
dia
gra
m o
f sp
ecif
ic s
olu
tio
n
Dep
loy
men
t d
iag
ra
m o
f sp
ecif
ic s
olu
tio
n (
if n
ecess
ary
)
3
Usa
bil
ity
Su
pp
orti
ng
Arch
itectu
ra
l P
att
ern
Ob
serv
ing
Sy
stem
Sta
te
Na
me:
Ob
serv
ing
sy
stem
sta
te
Usa
bil
ity
Co
nte
xt
Sit
ua
tio
n:
A u
ser
may
no
t b
e p
rese
nte
d
wit
h t
he
syst
em s
tate
dat
a n
eces
sary
to
op
erat
e th
e sy
stem
(e.
g.,
un
info
rmat
ive
erro
r m
essa
ges
, n
o f
ile
size
giv
en f
or
fold
ers)
. A
lter
nat
ivel
y,
the
syst
em s
tate
may
be
pre
sen
ted
in
a w
ay t
hat
vio
late
s h
um
an t
ole
ran
ces
(e.g
., i
s p
rese
nte
d t
oo
qu
ick
ly f
or
peo
ple
to r
ead.
See
:
Wo
rkin
g a
t th
e U
ser'
s P
ace).
Th
e s
yst
em
sta
te m
ay
als
o b
e p
rese
nte
d i
n a
n u
ncle
ar
fash
ion
, th
ere
by
co
nfu
sin
g t
he u
ser.
Sy
stem
desi
gn
ers
sh
ou
ld a
cco
un
t fo
r
hu
man
nee
ds
and
cap
abil
itie
s w
hen
dec
idin
g w
hat
asp
ects
of
syst
em s
tate
to
dis
pla
y an
d h
ow
to p
rese
nt
them
.
Co
nd
itio
ns
of
the S
itu
ati
on
: A
use
r is
wo
rkin
g i
n a
sy
stem
an
d w
ants
to
kn
ow
ab
ou
t th
e p
rog
ress
of
the
task
th
at i
s b
ein
g e
xec
ute
d.
Po
ten
tia
l U
sab
ilit
y B
en
efi
ts (
TO
TH
E U
SE
R):
A.
Incre
ase
s in
div
idu
al
use
r eff
ecti
ven
ess
A.1
Exped
ite
s ro
uti
ne p
erf
orm
an
ce
A1
.1 A
ccele
ra
tes
erro
r-fr
ee p
orti
on
of
ro
uti
ne p
erfo
rm
an
ce
A 1
.2 R
edu
ces
the
imp
act
of
rou
tin
e u
ser
erro
rs (
slip
s):
Wh
en t
he
inev
itab
le s
lip
hap
pen
s, i
f th
e sy
stem
sta
te i
s re
adil
y a
nd
eas
ily
ob
serv
ed,
the
use
r
wil
l know
how
to c
orr
ect
the
slip
bef
ore
conti
nuin
g f
urt
her
dow
n a
n i
nco
rrec
t pat
h.
A.2
Im
pro
ves
no
n-r
ou
tin
e p
erf
orm
an
ce
A 2
.1 S
up
po
rts
pro
ble
m-s
olv
ing
:H
um
an p
rob
lem
so
lvin
g d
epen
ds
on
kn
ow
led
ge
of
curr
ent
stat
e (w
her
e y
ou
are
), t
he
go
al s
tate
(w
her
e y
ou
wan
t to
be)
, an
d a
war
enes
s of
the
range
of
avai
lable
act
ions.
Thus,
bei
ng a
ble
to o
bse
rve
the
curr
ent
syst
em s
tate
is
centr
al t
o t
he
pro
cess
of
pro
ble
m s
olv
ing.
A 2
.2 F
acil
ita
tes
lea
rn
ing
:L
earn
ing
co
rrec
t ac
tio
ns
dep
end
s o
n k
no
win
g t
he
syst
em s
tate
wh
en t
he
acti
on
pro
du
ced
a
des
ired
res
po
nse
. T
hu
s, i
f th
e
syst
em s
tate
is
ob
scu
red
or
un
ob
serv
able
, th
e u
ser’
s ab
ilit
y t
o l
earn
wil
l b
e in
hib
ited
.
A.3
Red
uce
s th
e im
pact
of
use
r er
rors
cau
sed b
y la
ck o
f kn
ow
ledge
(mis
takes
)
A 3
.1 P
reven
ts m
ista
kes
A 3
.2 A
cco
mm
od
ate
s m
ista
kes
: If
th
e sy
stem
sta
te i
s re
adil
y a
nd
eas
ily
ob
serv
ed,
the
use
r w
ill
kn
ow
ho
w t
o c
orr
ect
the
mis
tak
e b
efo
re c
on
tin
uin
g
furt
her
dow
n a
n i
nco
rrec
t pat
h.
B.
Red
uce
s th
e im
pact
of
syst
em e
rrors
B.1
Pre
ven
ts s
yste
m e
rrors
B.2
Tole
rate
s sy
stem
err
ors
:
C.
Incre
ase
s u
ser
co
nfi
den
ce a
nd
co
mfo
rt:
Th
is a
pp
lies
to t
he s
pecia
l ca
se o
f th
e u
ser
bein
g u
na
ble
to
dete
rmin
e t
he l
evel
of
secu
rity
fo
r d
ata
en
tere
d i
nto
a s
yst
em
.
Su
ch
exp
eri
en
ces
ma
y m
ake t
he u
ser
hesi
tate
to
use
th
e s
yst
em
or
avo
id i
t a
lto
geth
er.
Th
us,
syst
em
s th
at
pro
min
en
tly d
isp
lay s
ecu
rity
po
licie
s a
nd
secu
rity
levels
(bo
th o
f w
hic
h a
re f
ea
ture
s o
f sy
stem
sta
te)
incre
ase
use
r co
nfi
den
ce a
nd
co
mfo
rt.
4
Pro
ble
m (
see
ap
pen
dix
for
refe
ren
ces)
Fo
rces
ex
erte
d
by
the
en
vir
on
men
t
an
d t
ask
Fo
rces
ex
erte
d
by
h
um
an
d
esi
res
an
d c
ap
ab
ilit
ies
Fo
rces
ex
erte
d b
y t
he s
tate
of
the s
oft
wa
re
Gen
era
l R
esp
on
sib
ilit
ies
of
the s
oft
wa
re:
ST
01
:T
he
arte
fact
(S
W ap
pli
cati
on
in
th
is ca
se)
mu
st
dis
pla
y
stat
e in
form
atio
n
that
is
li
kel
y
to
chan
ge
ov
er t
ime,
esp
ecia
lly
if
that
sta
te i
nfo
rmat
ion
re
pre
sents
m
any
var
iable
s (e
.g.,
stat
us
bar
on
win
dow
s ap
pli
cati
ons;
tra
in,
bus
or
airl
ine
sched
ule
;
VC
R d
ispla
y....)
[Tid
wel
l, 9
9]
ST
02:
Wh
en s
om
e ch
ang
e in
sy
stem
sta
te o
ccu
rs,
the
use
r sh
ould
be
noti
fied
. [C
ora
m.
96]
R01:T
he
softw
are
should
be
able
to
lis
te
n t
o a
ctive
com
mands,
because t
hey c
an p
rovid
e i
nfo
rmation a
bout
the
sta
te o
f th
e s
yste
m.
If t
his
in
form
atio
n is u
se
ful to
th
e
user,
th
e
syste
m
should
be
able
to
pro
vid
e
this
info
rma
tio
n t
o t
he
use
r in
th
e a
pp
rop
ria
te m
an
ne
r a
nd
in
th
e a
ppro
priate
location
, not
only
thro
ugh t
he d
ispla
y.
ST
03:
(In
cas
e of
syst
em f
ailu
re)
[Nie
lsen
, 93]
C1
:T
he
syst
em s
om
etim
es j
ams
up b
ecau
se a
giv
en
com
man
d d
oes
no
t re
spo
nd
; it
th
en i
s im
po
rtan
t to
aler
t use
rs
to
the
fact
th
at
this
co
mm
and
has
jam
med
.
R0
2:
As th
e s
yste
m c
an
fa
il, t
he
so
ftw
are
sh
ou
ld b
e a
ble
to
a
sce
rta
in
the
sta
te
of
active
co
mm
an
ds,
be
ca
use
use
rs
sh
ou
ld
be
in
form
ed
if
the
co
mm
an
d
is
no
tperf
orm
ing d
ue t
o e
xte
rnal circum
sta
nces.
Th
e s
yste
m s
ho
uld
be
eq
uip
pe
d w
ith
a m
ech
an
ism
by
me
an
s o
f w
hic
h it ca
n c
he
ck a
t a
ny t
ime
wh
eth
er
a g
ive
n
co
mm
an
d i
s b
ein
g e
xe
cu
ted
an
d,
if t
he
co
mm
an
d f
ails
, in
form
use
rs t
ha
t th
e c
om
ma
nd
is n
ot
op
era
tio
na
l.
ST
03
: (I
n
case
of
syst
em
fail
ure
)
[Nie
lsen
, 9
3]
C2
:T
he
syst
em
giv
es
a w
arn
ing
th
at
a g
iven
re
sou
rce,
be
it t
he
net
wo
rk,
a d
atab
ase,
etc
., i
s n
ot
oper
atio
nal
.
R0
3:
Th
e s
oft
wa
re s
ho
uld
be
ab
le t
o l
iste
n t
o o
r q
ue
ry
exte
rna
l re
so
urc
es,
like
n
etw
ork
s o
r d
ata
ba
se
s,
ab
ou
t
the
ir sta
te,
to in
form
th
e u
se
r if a
ny re
so
urc
e is
n
ot
perf
orm
ing p
roperly.
Th
e syste
m sh
ou
ld b
e e
qu
ipp
ed
with
a m
ech
an
ism
by
means o
f w
hic
h i
t can a
scert
ain
at
any t
ime t
he s
tate
of
giv
en
exte
rna
l re
so
urc
es,
su
ch
as n
etw
ork
s,
da
tab
ase
s,
etc
., s
o t
ha
t it c
an
in
form
use
rs if
an
y o
f th
ese
re
so
urc
es
are
not
opera
tional.
C4
: T
he s
yst
em
ale
rts
use
rs t
o t
he
fact
th
at t
hey
hav
e to
do a
giv
en p
revio
usl
y p
rogra
mm
ed t
ask.
C5
: T
he
syst
em a
lert
s u
sers
to
th
e fa
ct t
hat
th
ey
sho
uld
sav
e w
hat
th
ey a
re d
oin
g,
as t
he
syst
em w
ill
swit
ch o
ff i
n 1
min
ute
bec
ause
th
e b
atte
ry i
s lo
w a
nd
use
rs w
ill
lose
ever
yth
ing t
hat
is
open
.
R0
4:
Th
e s
oft
wa
re s
ho
uld
be
ab
le t
o c
he
ck t
he
sta
te o
f th
e s
yste
m r
eso
urc
es a
nd
ale
rt u
se
rs in
ad
va
nce
to
sa
ve
the
ir w
ork
, b
eca
use
th
e s
yste
m is r
un
nin
g o
ut
of
a g
ive
n
resourc
e a
nd w
ill h
ave t
o s
hut
dow
n.
5
Pro
ble
m (
see
ap
pen
dix
for
refe
ren
ces)
Fo
rces
ex
erte
d
by
the
en
vir
on
men
t
an
d t
ask
Fo
rces
ex
erte
d
by
h
um
an
d
esi
res
an
d c
ap
ab
ilit
ies
Fo
rces
ex
erte
d b
y t
he s
tate
of
the s
oft
wa
re
Gen
era
l R
esp
on
sib
ilit
ies
of
the s
oft
wa
re:
LA
03
:S
yst
em t
ask
s th
at t
ake
a lo
ng
tim
e
(ty
pic
ally
mo
re t
han
a f
ew s
eco
nd
s) a
nd
mu
st b
e co
mp
lete
d b
efo
re t
he
nex
t ta
sks
can b
e st
arte
d [
Wel
ie,
00]
LA
07
:1
0 s
eco
nd
s is
ab
ou
t th
e li
mit
fo
r
kee
pin
g t
he
use
r’s
atte
nti
on
fo
cuse
d o
n t
he
dia
logue.
F
or
longer
del
ays,
use
rs
wil
l
wan
t to
per
form
oth
er t
ask
s w
hil
e w
aiti
ng
for
the
com
pute
r to
fin
ish [
Nie
lsen
, 93]
LA
10:
Pro
vid
e co
nti
nuous
feed
bac
k a
bout
pro
gre
ss [
Ben
son,
02]
LA
01
: A
tim
e-co
nsu
min
g p
roce
ss i
s goin
g o
n,
the
resu
lts
of
wh
ich
are
of
inte
rest
to
th
e u
ser
[Tid
wel
l,
99
]L
A0
2:
Use
a
pro
gre
ss
ind
icato
r w
hen
a
tim
e-
con
sum
ing
o
per
atio
n in
terr
up
ts th
e U
I fo
r lo
ng
er
than
2 s
eco
nd
s o
r so
sh
ow
th
e an
imat
ed i
nd
icat
or
of
how
much
[T
idw
ell,
02]
R05:
For
each a
ction r
equired b
y t
he u
sers
, th
e s
oftw
are
must
be a
ble
to c
alc
ula
te t
he e
lapsed t
ime t
o f
inis
h e
ach r
equeste
d
opera
tion:
1.If
ela
psed t
ime i
s l
ess t
han 2
seconds,
then c
hangin
g t
he
curs
or
shape is s
uffic
ient.
2.If
ela
psed t
ime is m
ore
or
equal to
2 s
econds,
then:
?If
th
e o
ng
oin
g a
ctio
n is
cri
tica
l fo
r th
e s
yste
m o
r fo
r th
e
resourc
es involv
ed in t
he
curr
ent actio
n then:
?E
ither:
S
how
th
e
pro
gre
ss,
continuously
(e
very
2 seconds,
LA
03),
usin
g pro
gre
ss
indic
ato
r if t
he t
ime e
stim
ate
is w
ithin
20%
. (L
A10).
G
ive
an
indic
ation
of
the
tim
ere
main
ing,
either
as a
fig
ure
, or
gra
phic
ally
(a
s a
tim
e b
ar,
as a
clock,.
.)O
R:
Show
the
pro
gre
ss,
continuously
(e
very
2 seconds,
LA
03),
usin
g p
rogre
ss i
ndic
ato
r. I
f th
e t
ime
cannot
be estim
ate
d accura
tely
, consid
er
oth
er
altern
atives.
(LA
10).
If
tim
ing c
annot
be
estim
ate
d,
but
the
pro
cess
has
identifiab
le p
hases,
giv
e a
n indic
atio
n o
f th
e
phases
com
ple
ted
and
of
the
phases
rem
ain
ing.
?D
o n
ot re
turn
the c
ontr
ol to
the u
ser
?N
otify
the u
ser
when t
he t
ask i
n p
rogre
ss
has f
inis
hed
?P
rovid
e a
Sto
p o
r C
ancel button
?If the o
ngoin
g a
ction is n
ot c
ritica
l fo
r th
e s
yste
m o
r fo
r
the r
esourc
es involv
ed in t
he c
urr
ent
actio
n t
hen:
?S
how
th
e pro
gre
ss,
continuously
(e
very
2
seconds,
LA
03)
(LD
10)
?R
etu
rn the c
ontr
ol to
the u
ser
?P
rovid
e a
Sto
p o
r C
ancel button
?N
otify
the u
ser
when t
he t
ask i
n p
rogre
ss
has
fin
ish
ed
6
Pro
ble
m (
see
ap
pen
dix
for
refe
ren
ces)
Fo
rces
ex
erte
d
by
the
en
vir
on
men
t
an
d t
ask
Fo
rces
ex
erte
d
by
h
um
an
d
esi
res
an
d c
ap
ab
ilit
ies
Fo
rces
ex
erte
d b
y t
he s
tate
of
the s
oft
wa
re
Gen
era
l R
esp
on
sib
ilit
ies
of
the s
oft
wa
re:
LA
05:
0.1
sec
on
d i
s ab
ou
t th
e li
mit
fo
r
hav
ing
th
e u
ser
feel
th
at
the
syst
em
is
reac
ting i
nst
anta
neo
usl
y [
Nie
lsen
, 93]
IF01:
Peo
ple
nee
d t
o k
no
w t
hat
th
e sy
stem
has
reg
iste
red
an
in
tera
ctio
n e
ven
t, s
uch
as
mo
use
cl
ick
, m
ou
se
mo
vem
ent,
ar
row
movem
ent,
key
boar
d p
ress
, et
c. (
wher
e an
inte
ract
ion e
ven
t is
only
par
t of
a se
quen
ce
of
com
man
ds
to a
syst
em,
or
wh
ere
no
exp
lici
t u
ser
per
cep
tib
le e
ffec
t is
ach
iev
ed,
peo
ple
can
bec
om
e an
xio
us
that
they
hav
e
no
t b
een
“h
eard
” b
y t
he
syst
em,
and
may
repea
tth
e cl
ick o
r m
ovem
ent)
[B
righto
n
98
][B
enso
n 0
2]
R0
6: In
an
y c
ase
th
e s
oft
wa
re s
ho
uld
be
ab
le to
no
tify
th
e
user
about
the r
egis
tration o
f an i
nte
raction e
vent
within
100 m
illis
econds.
LA
09
:S
yst
ems
sho
uld
let
use
rs k
no
w h
ow
inp
ut
fro
m
the
use
rs
was
in
terp
rete
d.
[Const
anti
ne,
99]
IF01:
Peo
ple
nee
d t
o k
no
w t
hat
th
e sy
stem
has
reg
iste
red
an
in
tera
ctio
n e
ven
t, s
uch
as
mo
use
cl
ick
, m
ou
se
mo
vem
ent,
ar
row
movem
ent,
key
boar
d p
ress
, et
c. (
wher
e an
inte
ract
ion e
ven
t is
only
par
t of
a se
quen
ce
of
com
man
ds
to
a sy
stem
, o
r w
her
e n
o
exp
lici
t u
ser
per
cep
tib
le e
ffec
t is
ach
iev
ed,
peo
ple
can
bec
om
e an
xio
us
that
they
hav
e
no
t b
een
“h
eard
” b
y t
he
syst
em,
and
may
repea
t th
e cl
ick o
r m
ovem
ent)
[B
righto
n
98]
R0
7:
Th
e s
oft
wa
re s
ho
uld
be
ab
le t
o s
ho
w u
se
rs h
ow
th
eir r
equired i
nte
raction h
as b
een inte
rpre
ted.
W01:
Th
e u
ser
may
un
inte
nti
on
ally
cau
se
a p
rob
lem
si
tuat
ion
w
hic
h
nee
ds
to
be
solv
ed [
Wel
ie,
03]
R0
8:
Th
e s
oft
wa
re m
ust
be
pro
vid
ed
with
th
e a
bili
ty t
o
ask th
e u
se
r fo
r co
nfirm
atio
n if th
e u
se
r h
as r
eq
ue
ste
d a
n
irre
vers
ible
action.
7
Sp
ecif
ic S
olu
tion
Gen
era
l
Resp
on
sib
ilit
ies
of
the
soft
wa
re
Fo
rces
tha
t co
me
fro
m
desi
gn
d
ecis
ion
s a
lrea
dy
ma
de
All
oca
tio
n o
f re
spo
nsi
bil
itie
s to
sp
ecif
ic c
om
po
nen
tsR
ati
on
ale
Mo
de
l:A
cti
ve
co
mm
an
d:
Th
e f
irst
tim
e a
n a
ctive
co
mm
an
d i
s c
rea
ted
by t
he
co
ntr
olle
r (4
)1 th
en
th
e
active
co
mm
an
d
mu
st
cre
ate
a
n
insta
nce
o
f R
eso
urc
e c
he
cke
r (5
) a
nd
an
in
sta
nce
of
Syste
m R
eso
urc
e C
he
cke
r (6
),
both
of them
runnin
g in a
diffe
rent
thre
ad f
rom
active c
om
mand.
Vie
w:
Fe
ed
ba
ck
er:
Re
ce
ive
s t
he
in
form
atio
n t
o b
e d
isp
laye
d f
rom
th
e a
ctive
co
mm
an
d.
(1).
An
d r
ep
rese
nts
th
e a
pp
rop
ria
te f
ee
db
ack i
n e
ach
ca
se
to
th
e u
ser
(EI0
2)
Vie
we
r: m
ust
pro
vid
e a
wa
y t
o l
iste
n
actio
ns r
eq
ue
ste
d f
rom
th
e u
se
r
(EI0
1)
R0
7:
Th
e
so
ftw
are
sh
ou
ld b
e a
ble
to
sh
ow
users
how
th
eir
req
uire
d in
tera
ctio
n h
as
been inte
rpre
ted.
Co
ntr
oll
er:
Co
ntr
oll
er:
Sh
ou
ld b
e l
iste
nin
g t
o t
he
Vie
we
r (3
) a
nd
if
the
use
r re
qu
est
so
me
actio
n c
rea
tes t
he
aske
d c
om
ma
nd
, a
n in
sta
nce
of
active
co
mm
an
d,
(4).
Mo
de
l:
Th
e
mo
de
l sh
ou
ldin
clu
de
a
n
ele
me
nt
tha
tlis
ten
s to
a
ctive
co
mm
an
ds
an
d,
if
the
in
form
atio
n
isu
se
ful, s
en
ds t
he
in
form
atio
n
to b
e p
asse
d o
n t
o t
he
use
r (s
ee
mo
de
l d
eco
mp
ositio
n)
Acti
ve
co
mm
an
d:
Re
pre
se
nts
th
e
co
mm
an
d
in
pro
gre
ss a
nd s
hould
in
form
ap
pro
pri
ate
fe
ed
ba
cke
r if th
e u
se
r is
to
be
no
tifie
d o
f so
me
thin
g.
(1).
R
01:T
he
softw
are
sh
ou
ld b
e a
ble
to
lis
ten
to
a
ctive
com
mands,
because
they
can
pro
vid
e
info
rma
tio
na
bo
ut
the
sta
te o
f th
e
syste
m.
If
this
info
rma
tio
n i
s u
se
ful
to
the
u
se
r,
the
syste
m
Vie
w:
Sh
ou
ld
be
ab
le
toin
form
th
e
use
r in
th
ea
pp
rop
ria
te m
an
ne
r.
Fe
ed
ba
ck
er:
Re
ce
ive
s t
he
in
form
atio
n t
o b
e d
isp
laye
d f
rom
th
e m
od
el (1
) o
r a
ch
an
ge
of
vie
w f
rom
th
e c
on
tro
ller
(2)
Th
e a
ctive
co
mm
an
d s
ho
uld
ru
n in
a
diffe
ren
t th
rea
d
fro
m
the
lis
ten
er,
be
ca
use
if
the
co
mm
an
d in
pro
gre
ss
is d
ea
d,
this
eve
nt
ca
n b
e n
otifie
d t
o
the
u
se
r th
rou
gh
som
e
oth
er
co
mp
on
en
t.S
ep
ara
tio
n
of
vie
w
an
d
fee
db
ack
allo
w t
he
“fe
ed
ba
cke
r” c
om
po
ne
nt
to
sp
ecia
lise
in
m
essa
ge
s
an
dfe
ed
ba
ck f
or
the
use
r, a
nd
th
en
th
e
1
Thes
e co
des
are
use
d i
n t
he
UM
L s
equen
ce d
iagra
mas
as
foll
ow
:
Num
ber
s: i
nte
ract
ion b
etw
een c
lass
es
?E
I: f
or
exte
rnal
in
tera
ctio
n
?E
R:
for
exte
rnal
res
ou
rces
in
tera
ctio
n
?IR
: fo
r in
tern
al r
eso
urc
es i
nte
ract
ion
?IP
: fo
r in
tern
al p
roce
dure
s
Comment:
Th
is h
as
a v
ery
bro
ad
mea
nin
g
8
sh
ou
ld
be
a
ble
to
pro
vid
e t
his
in
form
atio
n
to
the
u
se
r in
th
ea
pp
rop
ria
te m
an
ne
r a
nd
in
th
e
appro
priate
loca
tio
n,
no
t o
nly
thro
ug
h th
e d
isp
lay.
Co
ntr
oll
er:
Sh
ou
ld b
e a
ble
to
se
lect
the
ap
pro
pri
ate
vie
w t
o
sh
ow
th
e in
form
atio
n to
th
euser.
Co
ntr
oll
er:
Sh
ou
ld b
e l
iste
nin
g t
o t
he
Vie
we
r (3
) a
nd
if
the
use
r re
qu
est
so
me
actio
n c
rea
tes t
he
aske
d c
om
ma
nd
, a
n in
sta
nce
of
active
co
mm
an
d,
(4).
“vie
w”
co
mp
on
en
t sp
ecia
lise
s j
ust
in
ga
the
rin
g
the
u
se
r-to
- syste
m
inte
ractions.
Mo
de
l:
Th
e
mo
de
l is
in
ch
arg
e o
f ch
eckin
g t
ha
t th
e
co
mm
an
d
in
pro
gre
ss
isa
live
.
Acti
ve co
mm
an
d: C
om
munic
ate
d w
ith a com
ponent
calle
d “r
esourc
es
checker”
, ru
nn
ing
in a
diffe
ren
t th
rea
d, w
he
n th
e a
ctive
co
mm
an
d is
alive
, it
answ
ers
the R
esourc
e C
hecker
(8).
Re
so
urc
es
c
he
ck
er:
fr
om
tim
e to
tim
e,
it a
sks th
e a
ctive
co
mm
an
d
wh
eth
er
it is a
live
(7
); if
the
re is n
o a
nsw
er
fro
m t
he
Active
co
mm
an
d,
the
n
the
Re
so
urc
e C
he
cke
r a
ssu
me
s th
at th
e c
om
ma
nd
in p
rog
ress is
de
ad
an
d
se
lects
th
e a
pp
rop
ria
te f
ee
db
acke
r to
akn
ow
led
ge
th
e u
se
r o
f su
ch
eve
nt.
(9
)
Vie
w:
Fe
ed
ba
ck
er:
Re
ce
ive
s t
he
in
form
atio
n t
o b
e d
isp
laye
d f
rom
th
e A
ctive
co
mm
an
d (
1),
fro
m t
he
Re
so
urc
e c
he
cke
r (9
) o
r fr
om
th
e S
yste
m r
eso
urc
e
ch
ecke
r (1
0).
Als
o t
he
co
ntr
olle
r can s
ele
ct
the a
ppro
priate
feedbacker
(2)
R0
2: A
s th
e s
yste
m c
an
fa
il, th
e s
oft
wa
re s
ho
uld
be
ab
le t
o a
sce
rta
in t
he
sta
te
of
active
co
mm
an
ds,
because
users
should
be
info
rmed
if
the
co
mm
an
d
is
no
tperf
orm
ing
due
to
exte
rnal circum
sta
nces.
Co
ntr
oll
er:
Co
ntr
oll
er:
(noth
ing r
equired)
The
resourc
e
checker
com
ponent
sh
ou
ld r
un
in
a d
iffe
ren
t th
rea
d f
rom
the
active
com
mand
com
ponent,
be
ca
use
th
en
th
e
use
r can
be
no
tifie
d
if
the
a
ctive
co
mm
an
d
or
exte
rna
l re
so
urc
es a
re b
locke
d.
Mo
de
l:
Th
e
mo
de
l is
in
ch
arg
e o
f ch
eckin
g t
ha
t th
ee
xte
rna
l re
so
urc
es,
da
tab
ase
s,
ne
two
rks,
etc
.,a
re a
live
.
Re
so
urc
es
ch
ec
ke
r: f
rom
tim
e t
o t
ime
, it a
sks t
he
exte
rna
l re
so
urc
es i
f th
ey a
re a
live
(E
R0
1);
if
the
re i
s n
o a
nsw
er
fro
m t
he
re
queste
d e
xte
rnal
reso
urc
e,
the
n
the
R
eso
urc
e
Ch
ecke
r a
ssu
me
s
the
re
so
urc
e
is
no
t
pe
rfo
rmin
g
pro
pe
rly
an
d
info
rms
the
u
se
r tr
ou
gh
th
e
ap
pro
pri
ate
fee
db
acke
r. (
9).
If
the
re
so
urc
es a
re p
erf
orm
ing
pro
pe
rly,
the
y a
nsw
er
the
R
esourc
e c
hecker
(ER
02).
Vie
w:
Fe
ed
ba
ck
er:
Receiv
es t
he i
nfo
rmation t
o b
e d
ispla
yed f
rom
the r
esourc
e
checker.
(9)
R0
3:
Th
e
so
ftw
are
sh
ou
ld b
e a
ble
to
lis
ten
to
o
r q
ue
ry
exte
rna
l
reso
urc
es,
like
netw
ork
s o
r data
bases,
ab
ou
t th
eir
sta
te,
toin
form
th
e u
se
r if a
ny
resourc
e
is
not
pe
rform
ing p
roperly.
Co
ntr
oll
er:
Co
ntr
oll
er:
(noth
ing r
equired)
Mo
de
l:T
he
mo
de
lshould
be
ab
le t
o c
he
ck t
he
sta
te o
f th
e
reso
urc
es b
ein
g u
se
d b
y t
he
ongoin
g c
om
mand.
Sy
ste
m
Re
so
urc
e
Ch
ec
ke
r:
Sh
ou
ld
be
a
ble
to
ch
eck
the
syste
mre
so
urc
es (IR
01
) th
at
the
on
go
ing
co
mm
an
d is u
sin
g;
wh
en
th
ey a
re u
nd
er
a s
pe
cific
lim
it,
it s
ho
uld
se
nd
a m
essa
ge
to
th
e a
pp
rop
ria
te f
ee
db
acke
r (1
0)
to in
form
th
e u
se
r a
bo
ut w
ha
t to
do
in th
is s
itu
atio
n (
pro
ba
bly
clo
se
th
e
ap
plic
atio
n,
sa
ve
, e
tc.)
Vie
w:
Fe
ed
ba
ck
er:
Re
ce
ive
s t
he
in
form
atio
n t
o b
e d
isp
laye
d f
rom
th
e S
yste
m
Re
so
uce
ch
ecke
r. (
10
)
R0
4:
Th
e
so
ftw
are
sh
ou
ld b
e a
ble
to
ch
eck
the
sta
te o
f th
e s
yste
m
resourc
es
and
ale
rt
users
in
advance
tosave
their
work
,b
eca
use
th
e s
yste
m i
s
run
nin
g o
ut
of
a g
ive
n
reso
urc
e a
nd
will
ha
ve
to
shut
dow
n.
Contr
olle
r:C
on
tro
lle
r:(n
oth
ing r
equired)
9
Mo
de
l:.
Ac
tiv
e C
om
ma
nd
: S
ho
uld
be
ab
le t
o c
alc
ula
te t
he
tim
e t
ake
n t
o f
inis
h
ea
ch
re
qu
este
d o
pe
ratio
n (
IP0
1),
an
d t
o d
ete
rmin
e w
he
the
r th
e o
ng
oin
g
co
mm
an
d n
ee
ds t
o b
e c
om
ple
ted
be
fore
an
y o
the
r ta
sk c
an
be
pe
rfo
rme
d
(IP
02
).
1.I
f e
lap
sed
tim
e is le
ss t
ha
n 2
se
co
nd
s,
the
n c
ha
ng
ing
th
e c
urs
or
sh
ap
e is
su
ffic
ien
t.2.If
ela
psed t
ime is m
ore
or
equal to
2 s
econds,
then:
?If
th
e o
ng
oin
g a
ctio
n is c
ritica
l fo
r th
e s
yste
m o
r fo
r th
e r
eso
urc
es
involv
ed in t
he c
urr
ent
action t
hen:
?B
lock th
e vie
we
r so no re
quest
from
th
e user
can be
accepte
d (
11)
?R
ecalc
ula
te
the
rem
ain
ig
tim
e
each
2
seconds
(IP
01),
and
pro
vid
e fe
ed
ba
ck to
th
e u
se
r.?
Eith
er:
S
ho
w
the
p
rog
ress,
co
ntin
uo
usly
(e
ve
ry
2
se
co
nd
s),
usin
g p
rog
ress in
dic
ato
r if t
he
tim
e e
stim
ate
is
within
20%
. G
ive
an
in
dic
atio
n o
f th
e t
ime
re
ma
inin
g,
eith
er
as a
fig
ure
, o
r g
rap
hic
ally
(a
s a
tim
e b
ar,
as a
clo
ck,.
.) (1
)
?O
R:
Sh
ow
th
e p
rog
ress,
co
ntin
uo
usly
(e
ve
ry 2
se
co
nd
s),
u
sin
g p
rog
ress in
dic
ato
r. I
f th
e t
ime
ca
nn
ot
be
estim
ate
d
accu
rate
ly,
co
nsid
er
oth
er
alte
rna
tive
s.
If t
imin
g c
an
no
t be e
stim
ate
d,
but
the p
rocess h
as i
dentifiable
phases,
giv
e a
n i
nd
ica
tio
n o
f th
e p
ha
se
s c
om
ple
ted
an
d o
f th
e
ph
ase
s r
em
ain
ing
. (1
)
?P
rovid
e a
Sto
p o
r C
an
ce
l b
utt
on
(1
)
?N
otify
th
e u
se
r w
he
n t
he
ta
sk i
n p
rog
ress h
as f
inis
he
d (
Se
lec
tsth
e a
pp
rop
ria
te f
ee
db
ack,
1)
Vie
w:
Fe
ed
ba
ck
er:
Re
ce
ive
s t
he
in
form
atio
n t
o b
e d
isp
laye
d f
rom
th
e a
ctive
co
mm
an
d.
(1).
Pro
vid
es a
sto
p o
r ca
nce
l b
utt
on
(E
I02
)
Vie
we
r:W
hen t
he v
iew
er
must
not
accept
any r
equest
from
the u
ser
the
vie
wer
is b
locker
from
the a
ctive c
om
mand (
11)
R05:
For
each
actio
n
required b
y t
he u
sers
, th
e
softw
are
m
ust
be able
to
calc
ula
te t
he e
lapsed t
ime
to
finis
h
each
requeste
do
pera
tion:..........
Contr
olle
r:C
on
tro
lle
r:(n
oth
ing r
equired)
Mo
de
l:
Vie
w:
R0
6:
In
an
y
ca
se
th
eso
ftw
are
sh
ou
ld b
e a
ble
to n
otify
th
e u
se
r a
bo
ut
the
re
gis
tra
tio
n
of
an
inte
ractio
n e
ve
nt
with
in
100 m
illis
econds.
Contr
olle
r:
In a
ny c
ase
, th
e t
ime
be
twe
en
th
e v
iew
rece
ivin
g t
he inte
raction f
rom
the
use
r, s
en
din
g t
his
in
tera
ctio
n t
o t
he
co
ntr
olle
r, t
he
co
ntr
olle
r n
otify
ing
th
e
mo
de
l, t
he
mo
de
l a
nsw
eri
ng
th
e c
on
tro
ller,
an
d t
he
co
ntr
olle
r se
lectin
g t
he
appro
priate
vie
w s
hould
be n
o m
ore
than 1
00 m
illis
econds.
10
Mo
de
l:A
cti
ve
Co
mm
an
d:
Th
e a
ctive
co
mm
an
d sh
ou
ld b
e a
ble
to
a
sce
rta
in
wh
eth
er
or
no
t th
e r
eq
ue
ste
d a
ction is irr
evers
ible
. (I
P03)
If
the
re
qu
este
d
actio
n
is
irre
ve
rsib
le,
the
o
ng
oin
g
Active
co
mm
an
dco
mp
on
en
t sh
ou
ld n
otify
th
e u
se
r to
co
nfirm
th
e r
eq
ue
ste
d o
pe
ratio
n b
y
se
lectin
g th
e a
pp
rop
ria
te fe
ed
ba
cke
r (1
)
Vie
w:
Vie
w:
Re
ce
ive
s
the
in
tera
ctio
n
fro
m
the
u
se
r (E
I02
) a
nd
se
nd
s
this
info
rmation t
o t
he c
ontr
olle
r (3
).
R0
8: T
he
so
ftw
are
mu
st
be
p
rovid
ed
w
ith
th
ea
bili
ty to
a
sk th
e u
se
r fo
r co
nfirm
atio
n
if
the
use
r h
as r
eq
ue
ste
d a
n
irre
vers
ible
action.
Contr
olle
r:C
on
tro
lle
r:R
eceiv
es an in
tera
ction fr
om
th
e vie
w (3
) and sends th
is
info
rmation t
o t
he a
ctive c
om
mand (
12).
Su
mm
ary
of
inte
ract
ion
s:
1:
fro
m a
ctiv
e co
mm
and
to
fee
db
ack
er t
o s
elec
t th
e ap
pro
pri
ate
feed
bac
k
2:
fro
m c
on
tro
ller
to
fee
db
ack
er b
ecau
se c
an b
e co
mm
un
icat
ion
bet
wee
n c
on
tro
ller
an
d f
eed
bac
ker
(ty
pe
vie
w)
wit
ho
ut
inte
rven
tio
n o
f th
e m
od
el3:
from
vie
wer
to c
ontr
oll
er t
o s
end t
he
use
r in
tera
ctio
n r
eques
ted
4:
from
co
ntr
oll
er t
o a
ctiv
e co
mm
and
to
cre
ate
the
acti
ve
com
man
d c
orr
esp
on
din
g t
he
inte
ract
ion
req
ues
ted
fro
th
e u
ser
5:
fro
m a
ctiv
e co
mm
and
to
res
ou
rce
chec
ker
to
cre
ate
it.
6:
fro
m a
ctiv
e co
mm
and
to
sy
stem
res
ou
rce
chec
ker
to
cre
ate
it.
7:
from
res
ourc
e ch
ecker
to
act
ive
com
man
d t
o a
sk w
het
her
th
e ac
tiv
e co
mm
and
is
aliv
e o
r n
ot.
8:
fro
m a
ctiv
e co
mm
and
to
res
ou
rce
chec
ker
to
in
dic
ate
the
acti
ve
com
man
d i
s al
ive.
9:
fro
m r
eso
urc
e ch
eck
er t
o f
eed
bac
ker
to
sel
ect
the
app
rop
riat
e fe
edb
ack
, in
dic
atin
g t
o t
he
use
r th
e co
mm
and i
n c
ours
e is
dea
d o
r so
me
exte
rnal
re
sou
ce i
s d
ead
.
10
: fr
om
sy
stem
res
ou
rce
chec
ker
to
fee
db
ack
er t
o s
elec
t th
e ap
pro
pri
ate
feed
bac
k,
ind
icat
ing
th
ere
are
no
t en
ou
gh
sy
stem
res
ou
rces
to
ex
ecu
te
the
com
man
d i
n c
ours
e.
11
: fr
om
act
ive
com
man
d t
o v
iew
er
to i
nd
icat
e th
e v
iew
er t
hat
no
req
ues
t fr
om
th
e u
ser
mu
st b
e ac
cete
d u
nti
l th
e co
mm
and
in
co
urs
e h
as
fin
ish
ed
.1
2:
fro
m c
on
tro
ller
to
act
ive
com
man
d t
o i
nd
icat
e th
e se
lect
ed o
pti
on
in
th
e ca
se t
he
com
man
d i
n c
ou
rse
hav
e ir
rev
ersi
ble
co
nse
qu
esce
s an
d t
he
use
r m
ust
be a
sked
.
EI0
1:
from
use
r to
vie
wer
to r
eques
t a
com
man
d e
xec
uti
on
EI0
2: fr
om
fee
db
ack
er to
use
r to
giv
e in
form
atio
n
11
IP0
1:
an a
ctiv
e co
mm
and
in
tern
al p
roce
du
re t
o c
alcu
late
th
e ti
me
to f
inis
h r
equ
este
d o
per
atio
n
IP0
2:
an a
ctiv
e co
mm
and
in
tern
al p
roce
du
re to
det
erm
ine
the
crit
yci
ty o
f th
e o
ng
oin
g c
om
man
dIP
03
: an
act
ive
com
man
d i
nte
rnal
pro
ced
ure
to
det
erm
ine
wh
eth
er o
r n
ot
the
req
ues
ted
act
ion
is
irre
ver
sib
le.
ER
01
: fr
om
res
ou
rce
chec
ker
to
ex
tern
al r
eso
urc
es t
o k
no
w a
bo
ut
thei
r st
atu
sE
R02: fr
om
ex
tern
al r
eso
urc
es t
o r
eso
urc
e ch
eck
er t
o a
nsw
er i
n c
ase
ever
yth
ing
is
OK
.IR
01
: a
syst
em r
eso
urc
e ch
eck
er p
roce
du
re t
o k
no
w a
bo
ut
the
stat
us
of
syst
em r
eso
urc
es.
Bef
ore
cre
atin
g t
he
UM
L c
om
ponen
ts m
odel
, w
e pre
sent
in F
igure
1, a
fir
st a
pp
roac
h t
o t
his
mo
del
usi
ng
a g
ener
al b
ox
es a
nd
arr
ow
s m
od
el
wh
ere
also
ap
pea
r th
e ac
tors
bo
th u
sers
an
d e
xte
rnal
res
ou
rces
.
CO
NT
RO
LL
ER
VIE
W
MO
DE
L
Vie
wer
Fee
db
ack
er
EI0
1
Contr
oll
er
3
2A
ctiv
e
Co
mm
and
Res
ourc
e
Chec
ker
Syst
em
Res
ourc
es
Chec
ker
Net
work
ER
02
4,
12
9
10
7 5
, 8
EI0
2
6
ER
01
11
Fig
ure
1 F
irst
ap
pro
ach
to U
ML
com
pon
ents
mod
el
12
Com
pon
ents
dia
gra
m o
f sp
ecif
ic s
olu
tion
:
Vie
we
r:v
iew
Fe
ed
ba
cke
r:v
iew
Active
Com
mand:m
odel
Resourc
eC
hecker:
model
Syste
m-R
esourc
e-C
hecker:
model
:Contr
olle
r
13
Seq
uen
ce d
iag
ram
s o
f sp
ecif
ic s
olu
tio
n
: F
ee
db
acke
r: v
iew
: U
se
r
:
Vie
we
r:vie
w
: C
on
tro
lle
r :
Active
-Co
mm
an
d:
mo
de
l
IP0
1 a
nd
1 U
ntil
en
d o
f o
pe
ratio
n
(EI0
2) A
ction( )
(3) A
ction( )
(4)
Cre
ate
Co
mm
an
d()
IP0
2 C
he
ckC
riticity(
)
(IP
01
) C
alc
ula
teE
lap
se
dT
ime
( )
(11) F
reezeV
iew
()
(IP
03
) C
he
ckK
ind
OfO
pe
ratio
n()
(1) F
ee
db
ack(K
ind
-of-
fee
db
ack, in
form
atio
n)
(1)
Fe
ed
ba
ck (
en
d-o
f-o
pe
ratio
n)
Fig
ure
2 T
he e
xecu
tio
n o
f th
e co
mm
an
d i
s cr
itic
al
for
the
syst
em a
nd
th
e ex
ecu
tio
n c
om
ma
nd
in
co
urs
e is
no
t ir
rev
ersi
ble
14
: F
ee
db
acke
r: v
iew
: U
se
r
:
Vie
wer:
vie
w
: C
on
tro
lle
r : A
ctive
-Co
mm
an
d: m
od
el
IP0
1 a
nd
1 U
ntil
en
d o
f o
pe
ratio
n
(EI0
2)
Action(
)(3
) A
ction( )
(4)
Cre
ate
Co
mm
an
d()
IP0
2 C
he
ckC
riticity(
)
(IP
01
) C
alc
ula
teE
lap
se
dT
ime
( )
(11)
Fre
ezeV
iew
()
(IP
03
) C
he
ckK
ind
OfO
pe
ratio
n()
(1)
Fe
ed
ba
ck(K
ind
-of-
fee
db
ack,
info
rma
tio
n)
(1) F
ee
db
ack (e
nd
-of-
op
era
tio
n)
(1)
Irre
ve
rsib
leA
ctio
n()
(EI0
1)
OK
()
(3)
Exe
cu
teA
ctio
n()
(12
) C
on
tin
ue
()
Fig
ure
3 T
he
exec
uti
on
of
the
com
man
d i
s cr
itic
al
for
the
syst
em a
nd
th
e ex
ecu
tion
com
man
d h
as
irre
ver
sib
le c
on
seq
uen
ces
15
: A
ctive
-Co
mm
an
d: m
od
el
: F
ee
db
acke
r: v
iew
: U
ser
:
Vie
we
r:vie
w
: C
on
tro
ller
IP0
1 a
nd
1 U
ntil
en
d o
f o
pe
ratio
n
(EI0
2) A
ctio
n( )
(3)
Actio
n(
)(4
) C
rea
teC
om
ma
nd
()
IP0
2 C
he
ckC
riticity(
)
(IP
01
) C
alc
ula
teE
lap
se
dT
ime
( )
(IP
03
) C
he
ckK
ind
OfO
pe
ratio
n()
(1)
Fe
ed
ba
ck(K
ind
-of-
fee
db
ack,
info
rma
tio
n)
(1)
Fe
ed
ba
ck (
en
d-o
f-o
pe
ratio
n)
Fig
ure
4 T
he
exec
uti
on
of
the
com
man
d i
s n
ot
crit
ical
fo
r th
e sy
stem
16
: F
ee
db
acke
r: v
iew
: U
se
r
:
Vie
we
r:vie
w
: C
on
tro
lle
r :
Acti
ve
-Co
mm
an
d:
mo
de
l :
Reso
urc
eC
heck
er:m
odel
IP0
1 a
nd
1 U
ntil
en
d o
f o
pe
ratio
n
(EI0
2)
Action(
)(3
) A
ction(
)(4
) C
rea
teC
om
ma
nd
()
IP0
2 C
he
ckC
riticity(
)
(IP
01
) C
alc
ula
teE
lap
se
dT
ime
( )
(IP
03
) C
he
ckK
ind
OfO
pe
ratio
n()
(1)
Fe
ed
ba
ck(K
ind
-of-
fee
db
ack,
info
rma
tio
n)
(1)
Fe
ed
ba
ck (
en
d-o
f-o
pe
ratio
n)
(8)
Ye
sIa
m(
)
(7)
Are
Yo
uA
live
( )
Fig
ure
5 T
he
on
go
ing
co
mm
an
d i
s n
ot
dead
17
: F
ee
db
acke
r: v
iew
: U
ser
:
Vie
we
r:vie
w
: C
on
tro
lle
r :
Acti
ve
-Co
mm
an
d:
mo
de
l :
Reso
urc
eC
heck
er:m
odel
(EI0
2)
Action(
)(3
) A
ctio
n( )
(4)
Cre
ate
Co
mm
an
d()
IP0
2 C
he
ckC
riticity(
)
(IP
01
) C
alc
ula
teE
lap
se
dT
ime
( )
(IP
03
) C
he
ckK
ind
OfO
pe
ratio
n()
(7)
Are
Yo
uA
live
( )
(1)
Fe
ed
ba
ck (
on
go
ing
co
mm
an
d d
ea
d)
Fig
ure
6 T
he o
ng
oin
g c
om
ma
nd
is
dea
d
18
: F
ee
db
acke
r: v
iew
: U
se
r
:
Vie
we
r:vie
w
: C
ontr
olle
r :
Active
-Co
mm
an
d:
mo
de
l :
Sys
trem
-Reso
urc
e-C
heck
er:m
odel
(EI0
2)
Action(
)
(3)
Actio
n(
)(4
) C
rea
teC
om
ma
nd
()
(IR
01)
Check
Sys
tem
Reso
uce
s( )
Fig
ure
7 E
nou
gh
syst
em r
esou
rces
19
: F
ee
db
acke
r: v
iew
: U
se
r
:
Vie
we
r:vie
w
: C
on
tro
lle
r :
Acti
ve
-Co
mm
an
d:
mo
de
l :
Systrem
-Resourc
e-C
hecker:m
odel
(EI0
2)
Actio
n(
)
(3)
Acti
on
( )
(4)
Cre
ate
Co
mm
an
d()
(IR
01)
CheckS
yste
mR
esouces(
)
(1)
Fe
ed
ba
ck(c
lose
-th
e-s
yste
m)
Fig
ure
8 N
ot
eno
ug
h s
yst
em r
eso
urc
es
20
: F
eedback
er: v
iew
: U
ser
:
Vie
wer:vi
ew
: C
ontrolle
r : A
ctiv
e-C
om
mand: m
odel
: E
xtern
al-R
eso
uce
:
Reso
urc
eC
heck
er:m
odel
IP01 a
nd 1
Until
end o
f opera
tion
(EI0
2)
Actio
n(
)
(3)
Actio
n(
)(4
) C
reate
Com
mand()
IP02 C
heckC
ritic
ity(
)
(IP
01)
Calc
ula
teE
lapsedT
ime(
)
(IP
03)
CheckK
indO
fOpera
tion()
(1)
Feedback
(Kin
d-o
f-fe
edback
, in
form
atio
n)
(1) F
eedback (end-o
f-opera
tion)
(ER
01
) C
he
ckE
xte
rna
lRe
so
urc
es()
(ER
02
) E
xte
rna
lRe
so
urc
eA
va
ila
ble
()
Fig
ure
9 E
xte
rnal
res
ou
rces
per
form
ing
pro
per
ly
21
: A
ctiv
e-C
om
mand: m
odel
: F
eedback
er: v
iew
: U
se
r
:
Vie
wer:vi
ew
: C
ontr
olle
r :
Re
so
urc
eC
he
cke
r: :
Exte
rna
l-R
e
IP01 a
nd 1
Until
end o
f opera
tion
(EI0
2)
Actio
n(
)
(3)
Actio
n(
)(4
) C
reate
Com
mand()
IP02 C
heckC
ritic
ity(
)
(IP
01) C
alc
ula
teE
lapsedT
ime( )
(1)
Feedback
(Kin
d-o
f-fe
edback
, in
form
atio
n)
(1)
Fe
ed
ba
ck (
en
d-o
f-o
pe
ratio
n)
(ER
01
) C
he
ckE
xte
rna
lRe
so
urc
es()
(IP
03)
Check
Kin
dO
fOpera
tion()
(1)
Fe
ed
ba
ck(E
xte
rna
lRe
so
uce
No
tAva
ila
ble
)
Fig
ure
10 E
xte
rnal
res
ou
rces
no
t p
erfo
rmin
g p
rop
erly
Dep
loy
men
t d
iag
ram
of
spec
ific
so
luti
on
(if
nec
essa
ry)
22
REFERENCES
Amgi, October 28, 2003 http://www.greta-web-desing-tips.com/web-usability/96.html
Baeker, R. M, Gruding, J, Buxton W, Greenberg, S. Readings in human computer
interaction: toward the year 2000. Morgan Kaufmann. 1995
Benson, C, Elman, A., et al., October, 28 2003. GNOME Human Interface Guidelines http://developer.gnome.org/projects/gup/hig/
Brighton, October, 23 2003. Usability Pattern Collection. http://www.cmis.brighton.ac.uk/research/patterns/
Constantine, L., Lockwood, L. (1999). Software for Use : A Practical Guide to the
Models and Methods of Usage -Centered Design . Addison-Wesley.
Coram T, Lee J, October 23, 2003 Experiences: A Pattern Language for User Interface Design. http://www.maplefish.com/todd/papers/experiences/Experiences.html
Heckel, P. (1991) The elements of friendly software design. (2nd ed.) CA: Sybex Inc.
Hix, D., Harston, H. (1993). Developing user interface: ensuring usability trough
product and process. Wiley and Sons.
Matthews, W. November 10 2003, http://c2.com/cgi-bin/wiki?WebsitePatterns
Nielsen, J. (1993) Usability Engineering . Academic Press, Inc.
Perzel D., Kane D. (1999) Usability Patterns for Applications to the World Wide Web. PloP'99 : The 6th Annual Conference on the Pattern Languages of Programs . August
15-18, 1999, Robert Allerton Park and Conference Center, University of Illinois at Urbana-Champaign. Urbana, IL, USA .
Rubinstein, R, Hersh, H. (1984). "The Human Factor", Digital Press, Bedford, MA .
Shneiderman, B. (1998). Designing the User Interface: Strategies for Effective Human-
Computer Interaction. (3rd ed. ed.). Menlo Park, CA: Addison Wesley.
Tidwell, October, 22 2003. The Case for HCI Design Patterns. http://www.mit.edu/ jdidwell/common_ground_onefile.htm
Welie M. Amsterdam Collection of Patterns in User Interface Design. October 23 2003.
http://www.welie.com/
Welie, M.Traetteberg. Interaction Patterns in User Interfaces. PloP'00 :7th. Pattern Languages of Programs Conference ,August 13 to 16, 2000 Allerton Park. Monticello,
Illinois, USA. http://jerry.cs.uiuc.edu/~plop/plop2k/.
23
APPENDIX
Experts in human -computer interaction, software system design or networks, who can
give their view on the usability aspect in question, should be involved in this.
C1. The system sometimes jams up because a given command does not
respond; it then is important to alert users to the fac t that this command has jammed.
C2. The system gives a warning that a given resource, be it the network,
a database, etc., is not operational.
C3. When a web agent finds something users are looking for on the web,
it returns feedback to users or delivers a new e-mail, etc., that is, this
point includes all the information that the system wants to supply to
users, while the system is operating on other tasks.
C4. The system alerts users to the fact that they have to do a given
previously programmed task.
C5. The system alerts users to the fact that they should save what they are doing, as the system will switch off in 1 minute because the battery is
low and users will lose everything that is open.
C6. Users sometimes run several processes at the same time and want feedback to know that it finished.
C7. The system informs users how much longer it will take to complete a
task, while allowing multitasking if the task in question can be performed at the same time as others. On the other hand, for example, when
installing an operating system, users will only be informed of the progress
of the task and will not be allowed to execute any other command in parallel.
C8. The system has to alert users to the fact that it has heard the interaction that they requested so that they not request the same service
again because they think the system has not heard them.
C9. The system should warn users if they decide to invoke an action whose consequences are irreversible.
C10. The system, especially hypermedia navigational systems, should tell users where they are to assure that they do not get lost.
This section has been described according to the different types of feedback
that have been identified in the literature.
24
Sys
tem
Sta
tus
Au
tho
rU
sab
ilit
y N
am
eW
hen
Ho
w
Usa
bil
ity
Pat
tern
s
Tid
wel
l 9
9S
tatu
s D
ispla
yS
T01:
Th
e ar
tefa
ct (
SW
appli
cati
on i
n t
his
cas
e) m
ust
dis
pla
y s
tate
info
rmat
ion t
hat
is
likel
y t
o c
han
ge
over
tim
e,
esp
ecia
lly
if
that
sta
te i
nfo
rmat
ion
rep
rese
nts
man
y v
aria
ble
s (e
.g.,
stat
us
bar
on
win
do
ws
appl
icat
ions;
tra
in,
bus
or
airl
ine
sch
ed
ule
; V
CR
dis
pla
y..
..)
Ch
oo
se w
ell-d
esig
ned
dis
pla
ys
of
the
info
rmat
ion
to
be
sho
wn
an
d p
ut
them
to
get
her
in a
way
th
at e
mp
has
izes
th
e im
po
rtan
t th
ing
s, d
e-e
mphas
ises
the
triv
ial,
does
n’t
hid
e
or
obsc
ure
anyth
ing,
and p
rev
ents
co
nfu
sin
g o
ne
pie
ce o
f in
form
atio
n w
ith
an
oth
er.
Nev
er r
earr
ang
e it
, u
nle
ss t
he
use
rs d
o i
t th
emse
lves
. C
all
atte
nti
on
to
im
po
rtan
t
info
rmat
ion
wit
h b
rig
ht
colo
urs
, b
lin
kin
g o
r m
oti
on
, so
un
d o
r al
l th
ree
– b
ut
use
a
tech
niq
ue
app
rop
riat
e to
th
e ac
tual
im
port
ance
of
the
situ
atio
n t
o t
he
use
r.
Use
th
e p
osi
tio
nin
g o
f an
ite
m w
ith
in t
he
Sta
tus
Dis
pla
y t
o g
oo
d e
ffec
t; r
emem
ber
that
peo
ple
born
into
a E
uro
pea
n o
r A
mer
ican
cult
ure
ten
d t
o r
ead l
eft-t
o-r
igh
t, t
op
-
to-b
ott
om
, an
d t
hat
so
met
hin
g i
n t
he
up
per
lef
t co
rner
wil
l b
e lo
ok
ed a
t m
ost
oft
en.
Cora
m 9
6M
od
elli
ng
Fee
db
ack
Are
a
ST
02:
When
som
e ch
ange
in
syst
em s
tate
occ
urs
, th
e use
r
should
be
noti
fied
.
Use
a s
tatu
s ar
ea,
rath
er t
han
dia
log
bo
xes
or
po
p-u
p w
ind
ow
s, t
o d
isp
lay
in
form
atio
n
about
the
curr
ent
stat
e of
the
appli
cati
on.
Pla
ce i
t nea
r th
e m
ain d
ispla
y a
rea,
so t
hat
use
rs c
an v
iew
this
info
rmat
ion w
hen
they
dee
m a
ppro
pri
ate
(e.g
., W
ord
sta
tus
bar
or
Net
scap
e co
nnec
tion i
nfo
rmat
ion i
n t
he
bott
om
lef
t-h
and c
orn
er o
f th
e sc
reen
).
Web
Usa
bil
ity
Patt
ern
s
Usa
bil
ity
Heu
rist
ics
Nie
lsen
93
Fee
dbac
k (
In c
ase
of
syst
em f
ailu
re)
ST
03:
(In c
ase
of
syst
em f
ailu
re)
Sy
stem
s ca
n b
e d
esig
ned
fo
r g
race
ful
deg
rad
atio
n,
enab
lin
g t
hem
to
pro
vid
e so
me
feed
bac
k t
o u
sers
even
when
they
are
most
ly d
ow
n.
Ru
bin
stei
n84
(ref
eren
ced
in
Baek
er
95
)
Mak
e st
ates
vis
ible
and v
isib
ly
dis
tin
gu
ish
ed
Hix
93
Sta
tus
Indic
ator
Giv
e th
e u
ser
the
app
rop
riat
e st
atu
s in
dic
ato
r
Web
Usa
bil
ity
Heu
rist
ics
Am
gy
20
03
Vis
ibil
ity o
f W
eb
Sit
e S
tatu
s
25
Lon
g A
ctio
ns
Au
tho
rU
sab
ilit
y N
am
eW
hen
Ho
w
Usa
bil
ity
Pat
tern
s
Tid
wel
l 9
9P
rog
ress
In
dic
ato
rL
A0
1:
A t
ime-
con
sum
ing
pro
cess
is
goin
g o
n,
the
resu
lts
of
whic
h a
re o
f
inte
rest
to
th
e u
ser
Sh
ow
th
e u
ser
a st
atu
s d
isp
lay
of
som
e k
ind
, in
dic
atin
g h
ow
far
alo
ng
th
e p
roce
ss i
s
in r
eal
tim
e. I
f th
e ex
pec
ted
en
d t
ime
is k
no
wn
or
som
e o
ther
rel
evan
t q
uan
tity
(such
as
the
size
of
a fi
le b
eing d
ow
nlo
aded
) th
en a
lway
s sh
ow
what
pro
port
ion o
f
the
pro
cess
has
bee
n f
inis
hed
so f
ar,
so t
he
use
r ca
n e
stim
ate
how
much
tim
e is
lef
t.
If n
o q
uan
titi
es a
re k
now
n– j
ust
that
the
pro
cess
may
tak
e a
whil
e- then
sim
ply
show
som
e in
dic
ator
that
it’
s st
ill
goin
g o
n.
Anim
atio
n i
s oft
en u
sed t
o g
ood e
ffec
t in
this
pat
tern
. M
oti
on d
raw
s th
e use
r’s
atte
nti
on,
and i
ts c
essa
tion i
mpli
es a
new
rel
axed
, st
able
sta
te o
f bei
ng.
Sound c
an
also
be
use
d t
his
way
, fo
r th
e sa
me
reas
on.
Be
subtl
e, t
hough,
and b
e aw
are
of
the
imp
ort
ance
of
the
pro
cess
rel
ativ
e to
th
e o
ther
th
ing
s d
eman
din
g t
he
use
r’s
atte
nti
on
.
Tid
wel
l 0
2P
rog
ress
In
dic
ato
rL
A02:
Use
wh
en a
tim
e-co
nsu
min
g
op
erat
ion
in
terr
up
ts t
he
UI
for
lon
ger
th
an t
wo
sec
on
ds
or
so
Sh
ow
th
e an
imat
ed i
nd
icat
or
of
ho
w m
uch
pro
gre
ss h
as b
een
mad
e. E
ith
er v
erb
ally
of
gra
phic
ally
(or
both
), t
ell
the
use
r:
?w
hat
’s c
urr
entl
y g
oin
g o
n
?w
hat
pro
po
rtio
n o
f th
e o
per
atio
n i
s d
on
e so
far
,
?h
ow
mu
ch t
ime
rem
ains,
and
?how
to s
top i
t
Weli
e 0
0P
rog
ress
LA
03:
Syst
em t
asks
that
tak
e a
long
tim
e (t
ypic
ally
more
than
a f
ew
seco
nds)
and m
ust
be
com
ple
ted
bef
ore
th
e n
ext
task
s ca
n b
e st
arte
d
Pro
vid
e fe
edb
ack
at
a ra
te t
hat
giv
es t
he
use
r th
e im
pre
ssio
n t
hat
th
e o
per
atio
n i
s
stil
l bei
ng p
erfo
rmed
, e.
g.
ever
y 2
sec
onds
usi
ng a
nim
atio
n.
Addit
ional
ly,
pro
vid
e a
val
id i
nd
icat
ion
of
pro
gre
ss.
Pro
gre
ss i
s ty
pic
ally
th
e ti
me
rem
ain
ing
un
til
com
ple
tion,
the
num
ber
of
unit
s pro
cess
ed o
r th
e per
centa
ge
of
work
done.
Pro
gre
ss
can b
e sh
ow
n u
sing a
wid
get
such
as
a pro
gre
ss b
ar.
The
pro
gre
ss b
ar m
ust
hav
e a
label
sta
ting t
he
rela
tive
pro
gre
ss o
r th
e unit
in w
hic
h i
t is
mea
sure
d.
Weli
e 0
3P
rog
ress
LA
04:
Syst
em t
asks
that
tak
e a
long
tim
e (t
ypic
ally
more
than
a f
ew
seco
nds)
and m
ust
be
com
ple
ted
bef
ore
oth
er s
ucc
essi
ve
task
s ca
n
star
t
Sh
ow
th
at t
he
app
lica
tio
n i
s st
ill
wo
rkin
g a
nd
giv
e an
in
dic
atio
n o
f th
e p
rog
ress
.
Pro
vid
e fe
edb
ack
at
a ra
te t
hat
giv
es t
he
use
r th
e im
pre
ssio
n t
hat
th
e o
per
atio
n i
s
stil
l b
ein
g p
erfo
rmed
, e.
g.
ever
y 2
sec
onds.
Addit
ional
ly,
pro
vid
e a
val
id i
ndic
atio
n
of
the
pro
gre
ss.
Pro
gre
ss r
epre
sen
ts t
yp
ical
ly t
he
rem
ain
ing
tim
e fo
r co
mp
leti
on
, th
e
num
ber
of
unit
s pro
cess
ed o
r th
e per
centa
ge
of
work
done.
The
pro
gre
ss b
ar m
ust
stat
e th
e re
lati
ve
pro
gre
ss o
r th
e u
nit
in
wh
ich
it
is m
easu
red
.
Bri
ghto
n
98
Sh
ow
Co
mp
ute
r is
Th
ink
ing
LA
04
V1
:W
hen
an
in
tern
al
com
pu
ter
op
erat
ion
tak
es a
n
indet
erm
inat
e, b
ut
pote
nti
ally
sub
stan
tial
am
ou
nt
of
tim
e, p
eop
le
Giv
e fe
edb
ack
to
th
e us
er t
hat
th
e sy
stem
is
bas
ical
ly f
un
ctio
nin
g (
by
an
imat
ed
imag
e dri
ven
by e
ven
ts g
ener
ated
in t
he
pro
cess
) an
d i
f poss
ible
indic
ate
the
stag
e
of
the
pro
cess
th
at h
as b
een
rea
ched
.
26
Lon
g A
ctio
ns
Au
tho
rU
sab
ilit
y N
am
eW
hen
Ho
w
may
ass
um
e so
met
hin
g h
as g
on
e
wro
ng
Tim
e to
Do
So
meth
ing
Els
e
LA
04
V2
:W
hen
th
e co
mp
ute
r is
inv
olv
ed i
n a
len
gth
y i
nte
rnal
pro
cess
use
rs d
o n
ot
know
if
they
hav
e th
e o
pp
ort
un
ity
to
car
ry o
ut
ano
ther
tas
k o
r ta
ke
a b
reak
If t
he
tim
ing c
an b
e ca
lcula
ted,
giv
e an
indic
atio
n o
f th
e ti
me
rem
ainin
g,
eith
er a
s a
fig
ure
, o
r g
rap
hic
ally
(as
a t
ime
bar
, as
a c
lock
,..)
If t
imin
g c
ann
ot
be
esti
mat
ed,
bu
t th
e p
roce
ss h
as i
den
tifi
able
ph
ases
, g
ive
an
indic
atio
n o
f th
e phas
es c
om
ple
ted,
and o
f th
e phas
es r
emai
nin
g.
If n
eith
er o
f th
ese
po
ssib
ilit
ies
exis
ts,
then
at
leas
t in
dic
ate
the
nu
mb
er o
f u
nit
s
pro
cess
ed (
reco
rds,
vec
tors
...
.)
Cora
m 9
6M
od
elli
ng
Fee
db
ack
Are
a
LA
04
V3
:T
he
app
lica
tio
n m
ust
kee
p t
he
use
r in
form
ed,
esp
ecia
lly
when
it
is b
usy
pro
cess
ing a
req
ues
t, o
r th
e u
ser
wil
l b
eco
me
impat
ient
and m
ay t
hin
k t
hat
the
appli
cati
on h
as f
aile
d.
Use
a s
tatu
s ar
ea,
rath
er t
han
dia
log
bo
xes
or
po
p-u
p w
ind
ow
s, t
o d
isp
lay
info
rmat
ion a
bout
the
curr
ent
stat
e of
the
appli
cati
on.
Pla
ce i
t nea
r th
e m
ain d
ispla
y
area
, so
th
at u
sers
can
vie
w t
his
in
form
atio
n w
hen
th
ey d
eem
ap
pro
pri
ate
(e.g
.,
Wo
rd s
tatu
s b
ar o
r N
etsc
ape
con
nec
tio
n i
nfo
rmat
ion i
n t
he
bott
om
lef
t-han
d c
orn
er
of
the
scre
en).
Usa
bil
ity
Heu
rist
ics
Nie
lsen
93
Fee
db
ack
Fee
db
ack
bec
om
es e
spec
iall
y
imp
ort
ant
if t
he
syst
em h
as l
on
g
resp
onse
tim
es f
or
cert
ain
op
erat
ion
s. B
asic
ad
vic
e re
gar
din
g
resp
on
se t
imes
has
bee
n a
bo
ut
the
sam
e f
or
man
y y
ears
[M
ille
r, 6
8,
Car
d,
91
]:
-0.1
sec
ond i
s ab
out
the
lim
it f
or
hav
ing t
he
use
r fe
el t
hat
the
syst
em i
s re
acti
ng
inst
anta
neo
usl
y(L
A05)
-1.0
sec
ond i
s ab
out
the
lim
it f
or
the
use
r’s
flow
of
thought
to
stay
un
inte
rru
pte
d, ev
en t
ho
ug
h
the
use
r w
ill
noti
ce t
he
del
ay.
(LA
06)
--
10
sec
on
ds
is a
bo
ut
the
lim
it
for
kee
pin
g t
he
use
r’s
atte
nti
on
-N
o s
pec
ial
feed
bac
k i
s nec
essa
ry,
exce
pt
to d
isp
lay
th
e re
sult
-N
orm
ally
, no s
pec
ial
feed
bac
k i
s nec
essa
ry d
uri
ng d
elay
s of
more
than
0.1
and
less
than
1.0
, but
the
use
r does
lose
the
feel
ing o
f oper
atin
g d
irec
tly o
n t
he
dat
a.
-U
sers
sh
ou
ld b
e g
iven
fee
db
ack
in
dic
atin
g w
hen
th
e co
mp
uter
expec
ts t
o b
e
done.
Fee
dbac
k d
uri
ng t
he
del
ay i
s es
pec
iall
y i
mport
ant
if t
he
resp
onse
tim
e is
lik
ely
to
be
hig
hly
var
iab
le,
sin
ce u
sers
wil
l th
en n
ot
kn
ow
wh
at t
o e
xp
ect.
27
Lon
g A
ctio
ns
Au
tho
rU
sab
ilit
y N
am
eW
hen
Ho
w
focu
sed o
n t
he
dia
logue.
For
lon
ger
del
ays,
use
rs w
ill
wan
t
to p
erfo
rm o
ther
tas
ks
whil
e
wai
ting f
or
the
com
pute
r to
finis
h(L
A0
7)
Sh
neid
erm
an,
98
Info
rmat
ive
feed
back
LA
08:
Infr
equen
t an
d m
ajor
acti
ons
-T
he r
esp
onse
should
be
subst
anti
al
Vis
ual
pre
sen
tati
on
of
the
ob
ject
s o
f in
tere
st p
rov
ide
a co
nv
enie
nt
env
iro
nm
ent
for
sho
win
g c
han
ges
ex
pli
citl
y
Co
nst
anti
n
e, 9
9
Feed
back
Pri
ncip
leL
A09:
Sy
stem
s sh
ou
ld l
et u
sers
know
how
input
from
the
use
rs w
as
inte
rpre
ted
.
Asi
de
from
the
spot
on t
he
scre
en w
her
e use
rs w
ork
, use
rs a
re m
ost
lik
ely t
o a
tten
d
to f
eedbac
k a
t th
e ce
ntr
e or
at t
he
top o
f th
e sc
reen
, an
d a
re l
east
lik
ely t
o n
oti
ce i
t
at t
he
bott
om
edge.
The
stan
dar
d p
ract
ice
of
putt
ing i
nfo
rmat
ion a
bout
chan
ges
of
stat
e on a
sta
tus
line
at t
he
bott
om
of
a w
indow
is
par
ticu
larl
y u
nfo
rtunat
e,
esp
ecia
lly
if
the
sty
le g
uid
e ca
lls
for
lig
htw
eig
ht
typ
e o
n a
gre
y b
ack
gro
un
d (
for
exam
ple
, w
ord
)
Ben
son
02
Fee
db
ack
LA
10:
Pro
vid
e co
nti
nu
ou
s fe
edb
ack
abo
ut
pro
gre
ss
-V
erif
y t
hat
yo
ur
app
lica
tio
n p
rov
ides
fee
db
ack
wit
hin
10
0 m
illi
seco
nd
s af
ter
each
key
pre
ss,
movem
ent
of
the
mouse
, or
oth
er p
hysi
cal
input
from
the
use
r
-V
erif
y t
hat
your
appli
cati
on t
akes
no l
onger
than
1 s
econd t
o d
ispla
y e
ach
pro
gre
ss i
ndic
ator.
If
a co
mm
and m
ight
tak
e lo
ng
er t
han
5 s
eco
nd
s to
co
mp
lete
its
work
on a
n o
bje
ct,
allo
w u
sers
to i
nte
ract
wit
h a
ny p
arts
of
the
obje
ct a
nd
par
ts o
f th
e ap
pli
cati
on t
hat
are
not
dir
ectl
y a
ffec
ted b
y t
he
com
man
d.
If
a
com
man
d p
rovid
es l
ength
y o
utp
ut,
show
par
tial
res
ult
s as
they
bec
om
e
avai
lable
. S
croll
the
resu
lts
if n
eces
sary
unti
l th
e use
r m
oves
input
focu
s to
a
com
po
nen
t in
vo
lved
in
th
e sc
roll
ing
Des
crip
tio
n o
f fe
edb
ack
ty
pes
: p
oin
ter,
an
imat
ion
(p
rog
ress
bar
) an
d w
hen
to
use
each
one
Web
Usa
bil
ity
Heu
rist
ics
Am
gy
20
03
Vis
ibil
ity o
f W
eb
Sit
e S
tatu
s (e
.g.,
cred
it c
ard
pro
cess
ing)
LA
11:
Your
web
sit
e sh
ould
alw
ays
kee
p u
sers
in
form
ed a
bo
ut
wh
at i
s
go
ing
on
at
any
giv
en m
om
ent
Ex
amp
le,
let’
s sa
y y
ou
r e-
com
mer
ce s
ite
is p
roce
ssin
g a
cre
dit
car
d t
ran
sact
ion
.
Your
web
sit
e sh
ould
in
form
th
e cu
sto
mer
th
at t
he
tran
sact
ion
is
bei
ng
pro
cess
ed.
Most
web
sit
es d
o w
arn u
sers
that
it
may
tak
e 30-4
5 s
econds
to p
roce
ss t
hei
r cr
edit
card
, bef
ore
they
subm
it t
he
ord
er.
I re
com
men
d t
hat
you t
ake
this
one
step
furt
her
.
For
exam
ple
, dis
pla
y a
n a
nim
ated
ho
urg
lass
wh
ile
the
cred
it c
ard
is
bei
ng
pro
cess
ed.
28
Inte
racti
on
Feed
ba
ck
Au
tho
rU
sab
ilit
y N
am
eW
hen
How
Usa
bil
ity P
atte
rns
Bri
gh
ton
98
Inte
ract
ion
Feed
back
IF01:
Peo
ple
nee
d t
o k
no
w t
hat
th
e sy
stem
has
reg
iste
red
an
in
tera
ctio
n e
ven
t, s
uch
as
mouse
cli
ck,
mouse
movem
ent,
arr
ow
mo
vem
ent,
key
bo
ard
pre
ss,
etc.
(w
her
e an
inte
ract
ion e
ven
t is
only
par
t of
a se
quen
ce
of
com
man
ds
to a
syst
em,
or
wher
e no
exp
lici
t u
ser
per
cep
tib
le e
ffec
t is
ach
iev
ed,
peo
ple
can
bec
om
e an
xio
us
that
they
hav
e
not
bee
n “
hea
rd”
by t
he
syst
em,
and m
ay
rep
eat
the
clic
k o
r m
ov
emen
t)
This
anxie
ty c
an b
e re
liev
ed b
y g
ivin
g s
om
e
feed
bac
k,
pro
po
rtio
nal
to
th
e sc
ale
of
the
inte
ract
ion
even
t an
d i
ts s
ign
ific
ance
, to
co
nfi
rm t
o t
he
use
r
that
th
e sy
stem
has
reg
iste
red
th
e ev
ent.
Poss
ibil
itie
s in
clu
de
ind
enti
ng
a b
utt
on
,
bac
kli
gh
tin
g a
wo
rd,
chan
gin
g t
he
shap
e o
f th
e
curs
or,
mak
ing
an
au
dib
le c
lick
or
bee
p.
“Giv
e vis
ual
fee
dbac
k a
nd a
llow
the
use
r to
enab
le
audio
fee
dbac
k f
or
ever
y i
nte
ract
ion e
ven
t”.
Co
ram
96
Mo
del
lin
g
Fee
db
ack
Are
a
IF02:
Fo
r ev
ery
act
ion
th
e u
ser
tak
es,
the
syst
em s
ho
uld
pro
vid
e so
me
feed
bac
k t
hat
the
pro
gra
m h
as a
ccep
ted t
he
com
man
d.
Use
a s
tatu
s ar
ea,
rath
er t
han
dia
log b
oxes
or
pop
-
up
win
do
ws,
to
dis
pla
y i
nfo
rmat
ion
ab
ou
t th
e
curr
ent
stat
e of
the
appli
cati
on.
Pla
ce i
t nea
r th
e
mai
n d
ispla
y a
rea,
so t
hat
use
rs c
an v
iew
this
info
rmat
ion
wh
en t
hey
dee
m a
pp
rop
riat
e (e
.g.,
Wo
rd s
tatu
s b
ar o
r N
etsc
ape
con
nec
tio
n
info
rmat
ion i
n t
he
bott
om
lef
t-h
and c
orn
er o
f th
e
scre
en).
Usa
bil
ity H
euri
stic
sS
hnei
der
man
, 98
Info
rmat
ive
feed
back
IF03:
Fre
qu
ent
and
min
or
acti
on
s-
Th
e sy
stem
res
po
nse
mu
st b
e m
od
est
Vis
ual
pre
senta
tion o
f th
e obje
cts
of
inte
rest
pro
vid
es a
co
nv
enie
nt
env
iro
nm
ent
for
sho
win
g
chan
ges
ex
pli
citl
y
Hix
93
Art
icu
lato
ry
feed
back
IF04:-
To t
ell
the
use
r th
at t
he
inte
nd
ed
men
u w
as t
he
one
sele
cted
Sem
an
tic F
eed
back
IF04:
That
the
inte
nded
men
u w
as t
he
right
men
u t
o c
hoose
for
the
task
at
han
d
Hec
kel
91
(ref
eren
ced
in
Bae
ker
95)
Res
pond t
o t
he
use
r’s
acti
on
s
Ben
son
02
Feed
back
IF0
5:
Ack
no
wle
dg
e ea
ch u
ser
req
ues
tV
erif
y t
hat
your
appli
cati
on p
rovid
es f
eedbac
k
wit
hin
100 m
illi
seco
nds
afte
r ea
ch k
ey p
ress
,
mo
vem
ent
of
the
mo
use
, o
r o
ther
ph
ysi
cal
inp
ut
from
the
use
r
29
Warn
ings
Au
tho
rU
sab
ilit
y N
am
eW
hen
How
Usa
bil
ity P
atte
rns
Weli
e 0
3W
arn
ing
W01:
The
use
r m
ay u
nin
ten
tio
nal
ly c
ause
a p
rob
lem
sit
uat
ion
wh
ich
nee
ds
to b
e
solv
ed
The
war
nin
g s
hould
conta
in t
he
foll
ow
ing e
lem
ents
.
A s
um
mar
y o
f th
e pro
ble
m a
nd t
he
condit
ion t
hat
has
tri
gg
ered
th
e w
arn
ing
. A
qu
esti
on
ask
ing
th
e
use
rs i
f th
ey i
nte
nd t
o c
onti
nue
wit
h t
he
acti
on o
r
take
oth
er a
ctio
ns.
Tw
o m
ain c
hoic
es f
or
the
use
r,
an a
ffir
mat
ive
and a
choic
e to
abort
. T
he
war
nin
g
mig
ht
also
incl
ude
a m
ore
det
aile
d d
escr
ipti
on o
f
the
situ
atio
n t
o h
elp
th
e u
ser
mak
e th
e ri
gh
t
dec
isio
n.
The
choic
es s
hould
be
stat
ed i
ncl
ud
ing
a
ver
b t
hat
ref
ers
to t
he
acti
on
wan
ted
. In
so
me
case
s,
ther
e m
ay b
e m
ore
than
tw
o c
hoic
es.
Incr
easi
ng t
he
nu
mb
er o
f ch
oic
es m
ay b
e ac
cep
tab
le i
n s
om
e
case
s, b
ut
stri
ve
to m
inim
ize
the
nu
mb
er o
f ch
oic
es.
Bri
gh
ton
03
Th
ink
Tw
ice
W0
2:
A u
ser
may
acc
iden
tall
y c
arry
out
an
acti
on
th
at h
as s
erio
us
con
seq
uen
ces,
su
ch
as d
elet
ing a
fil
e, .
...
Fo
r ea
ch a
ctio
n t
hat
a u
ser
may
tak
e, h
avin
g r
egar
d
for:
th
e re
ver
sib
ilit
y o
f th
e ac
tio
n,
the
pro
po
rtio
n o
f
rev
ersi
ble
act
ion
s th
at t
he
syst
em s
up
po
rts,
th
e
freq
uen
cy w
ith w
hic
h t
he
acti
on i
s ta
ken
, th
e deg
ree
of
dam
age
that
may
be
cause
d,
and t
he
imm
edia
cy
of
feed
bac
k,
consi
der
whet
her
a w
arnin
g,
con
firm
atio
n,
auth
ori
zati
on
or
auto
mat
ic o
ver
rid
e
may
be
appro
pri
ate
Usa
bil
ity H
euri
stic
sN
iels
en 9
3F
eed
back
(In
case
of
use
r ir
rever
sible
acti
on
)
W03:
In c
ase
the
use
r is
goin
g t
o p
erfo
rm
an i
rrev
ersi
ble
act
ion
E.g
. O
ver
wri
te f
iles
. B
ette
r fe
edbac
k w
ould
incl
ude
the
nam
e of
the
file
, an
d t
he
attr
ibute
s of
such
fil
es,
such
as
file
type
and m
odif
icat
ion d
ate.
30
Yo
u A
re H
ere
Auth
or
Nam
eW
hen
How
Web
Usa
bil
ity
Pat
tern
sP
erze
l, 9
9Y
ou
are
Her
eP
rov
ide
use
rs w
ith
in
form
atio
n a
bo
ut
thei
r cu
rren
t lo
cati
on,
allo
win
g t
hem
to l
eave
a tr
ail
to b
e ab
le t
o r
eturn
to
that
pla
ce q
uic
kly
Mat
thew
s, 2
00
3B
read
Cru
mbs
YA
H0
1:
Sh
ow
th
e u
sers
wh
ere
in
a W
eb s
ite
they
curr
entl
y a
re
Ty
pic
ally
fo
un
d i
n t
he
site
’s h
ead
er,
it
ten
ds
to l
oo
k s
om
eth
ing
lik
e th
is:
Ro
ot
>F
oo
t>B
ar>
Pag
e
Vis
ible
Co
nte
xt
YA
H02:
In a
web
sit
e w
ith m
any
cross
-lin
ks,
to
hel
p t
he
read
er
know
wher
e th
ey a
re i
n a
web
sit
e
Incl
ude
a sm
all
map
or
nav
igat
ion b
ar
on e
ach p
age
that
lin
ks
to p
ages
nea
r
the
curr
ent
pag
e. T
his
mig
ht
incl
ude
pag
es t
hat
lea
d t
o t
he
curr
ent
pag
e,
pag
es r
elat
ed t
o t
he
curr
ent
pag
e, a
nd
pag
es t
hat
giv
e m
ore
det
ail
abo
ut
top
ics
on
th
e cu
rren
t p
age.
31
CATALOGUING INFORMATION
System status (ST): to inform users of the internal system state and state changes (including
system failures)
? ST01: The artefact (SW application in this case) must display state information that is
likely to change over time, especially if that state information represents variables (e.g., status bar on window application, train, bus or airline schedule, VCR displays...)
? ST02: When some change in system state occurs, the user should be notified.
? ST03: If the system fails, the user should be notified.
Long Actions (LA): to inform users that the system is processing an action that will take some time to complete.
? LA01: When a time-consuming process is going on, the results of which are of interest
to the user, the user must be informed:
o If the on-going process is critical, users should not be allowed to do anything
else until this task is completed. (LA03: System tasks that take a long time
(typically more than a few seconds) and must be completed before the next
tasks can be started,
o LA07: If the on-going task is not critical and takes over 10 seconds, users
should be allowed to run another operation if they so wish. Users should be
informed when the on-going operation finishes.
? LA02: Use when a time-consuming operation interrupts the UI for longer than two
seconds or so.
? LA04: is equivalent to LA03
? LA04V1: is equivalent to LA01
? LA04V2: is equivalent to LA01
? LA04V3: redundant
? LA05: The system response to user actions should arrive with at the latest 0.1 second
after user interaction.
? LA06: redundant
? LA08: redundant
? LA09: Systems should let users know how input from the users was interpreted.
? LA10: The software must provide continuous feedback about progress.
? LA11: For web systems, the web site should always keep users informed about what is
going on at any given moment.
LA11, has been ignored because represents a specific kind of software systems, while the
solution for the USAP must be a general solution.
Interaction Feedback (IF): to inform users that the system has registered user interaction, that
is, that the system has heard users.
? IF01: The feedback must be provided within 100 ms.
? IF02: is equivalent to IF01
32
? IF03: redundant
? IF04: This feedback is covered in the error or critical cases, because it does not make
sense to provide this type of feedback in all cases.
? IF05: is equivalent to IF01
Warning (W): To inform users of any irreversible action.
? W01: The system must be provided with the ability to ask the user before executing the
irreversible action.
? W02: is equivalent to W01
? W03: is equivalent to W01
You are here (YAH): to inform users where they are in the application (mainly for web sites).
? YAH01: In a web site with many cross-links, a feedback procedure must be developed
to help users to know where they currently are.
? YAH02: is equivalent to YAH01
These two cases have been ignored because they are refered to a specific kind
of software system while the solution for the USAP should be indeoendent of the kind of software to be developed.