usability-supporting architectural patternsbej/usa/publications/icsetutorial04-final...1 usap...

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


Maribel Sanchez-Segura

Computer Science Department

Carlos III University of Madrid

Bonnie E. John

Human-Computer Interaction Institute


Pittsburgh PA 15213

USA

1-412-268-7182

[email protected]

Natalia Juristo

School of Computing

Technical University of Madrid

Campus de Montegancedo s/n

28660 Boadilla del Monte

Spain

34-91-3366922

[email protected]

Len Bass

Software Engineering Institute


Pittsburgh PA 15213

USA

1-412-268-6763

[email protected]

Maribel Sanchez-Segura

Computer Science Department

Universidad Carlos III de Madrid

Avda. de la Universidad, 30

28911 Leganes

Spain

34-91-6249421

[email protected]



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



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



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



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.



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!”



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.



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.



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.



Purposes of Software ArchitectureCommunication among stakeholders • An educational purpose

• A managerial purpose

Artifact for analysis• Embeds early design decisions

Set of blueprints for implementation



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



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



Activities in software development

System Test and Deployment

Implementation

Detailed Design

Architecture Design

Requirements

System Formulation



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:




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:


System Formulation - HCI techniques:




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.



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



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



Outputdevice

Input device

Presentation-Abstraction-Control (PAC)

AbstractionPresentation

ControllerFunctional Core

(presentation

unlikely)

Intermediaries

(presentation

unlikely)

Self contained semanticconcepts


Controller


Controller


Controller


Controller



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



J2EE Model-View-Controller

Outputdevice

Input device

CommandProcessor

CommandProcessor

ModelCommand

Processor

CommandProcessor

View

CommandProcessor

Command

Processor

Controller



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






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




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/



Why separation-basedarchitectural patterns are not sufficient for interactive systems

Remember iterative design?



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



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.



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.



After the break, we’ll start addressing these shortcomings with usability-supportingarchitectural patterns



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



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



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.



What other architecturally-sensitive scenarios can you think of?



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



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



User’s Organizational Setting

Task in an Environment

System

Forces

Forces

Ben

efi

ts

Systems exist in a context



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



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



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.



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.



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)



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



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



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



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.



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.



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.



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.



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.



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



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



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



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



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




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



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.


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.



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.



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



LUNCH



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



Outputdevice

Input device

Presentation-Abstraction-Control (PAC)

Abstraction

Controller

Data base manager

Web browser


Controller

Abstraction

Controller

Abstraction

Controller


Controller

“Cancel”

“Cancel active command”

“Halt current transaction and roll back”



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”



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



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



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



Context of the specific solution: J2EE-MVC

:Controller

:View Active-

Command:Model

:Controller:Controller

:View:View Active-

Command:Model

Active-

Command:Model



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



:Model


:Model

Listener:ControllerListener:Controller

:View:View Active-

Command:Model

Active-

Command:Model

Collaborating-

Process:Model

Collaborating-

Process:Model



Responsibilities of new component –Listener

• Type Controller• Must always listen for the cancel command or

environmental changes (R3)



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.



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.



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)



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.




provided, close it.



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.






provided, close it.



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)



: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



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



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.



Small Group Exercise

Apply sample solution to real-world problem introduced in prior break out

Report-out to entire group



BREAK



Schedule

A second USAP:

?Example with Observing System State USAP4:00-5:15

TopicTime



A Second USAP

Observing System State



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.



USAP Template

Context• Situation• Conditions• Potential usability benefits

Problem and General Solution

Specific Solution



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.



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.



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.



USAP Template

Context


Specific Solution



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



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)



Observing System State:Environmental Forces

1. Resources, be it the network, a database, etc., can become not operational (EF01)



Observing System State:System Forces (1/2)

1. System state changes (SF01)

2. Systems sometimes fail (SF02)

3. Commands sometimes die (SF03)



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





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.




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


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.




Problem/Forces:

EF1: Resources, be it the network, a database, etc., can become not operational


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.




Problem/Forces:

HF01. When some change in system state occurs, the user should be notified.


R04: The software should be able to check the system resources and inform the user about their use.



USAP Template

Context


Specific Solution• General responsibilities• Forces exerted by previous design decisions • Allocation of responsibilities to specific components• Rationale



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



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



Context of the specific solution:J2EE-MVC

:Controller

:View Active-Command:Model


:View:View Active-Command:Model

Active-Command:Model



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.




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




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



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.




Active Command:model

:View

:Controller




Viewer:view

Feedbacker:view


Resource Checker:model

System-Resource-Checker:model

:Controller



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




Viewer:view

Feedbacker:view


Resource Checker:model

System-Resource-Checker:model

:Controller



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



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




Imagine we are faced with a situation where:

The ongoing command is dead




: 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)





There are not enough resources to execute the ongoing command




: Feedbacker: v iew

: User

: Viewer:v iew

: Controller : Activ e-Command: model : Systrem-Resource-Checker:model


(4) CreateCommand()

(IR01) CheckSystemResouces(

(1) Feedback(close-the-sy stem)





The external resources are performing properly




: Feedbacker: view

: User

: Viewer:view

: Controller : Active-Command: model

: External-Resouce

: ResourceChecker:model

IP01 and 1 U ntil end of operat ion


(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()



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.



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



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.


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-


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.


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


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-


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.


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.


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)


• 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.


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.


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.


human desires and

needs, which may

include issues of

salience or control,

among others.


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


general responsibilities

of the software

identified in the

problem description.


forces that come from

design decisions taken

independently of

usability aspects but

that influence the way

in which these aspects

must be designed.


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)

CHI 2004 John, Bass, Juristo & Sanchez-Segura Appendix III-2

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

CH

I 2004

Jo

hn

, B

ass,

Ju

risto

Sa

nch

ez-S

eg

ura

AppIV

-6

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.

usability-supporting architectural patternsbej/usa/publications/icsetutorial04-final...1 usap...

Documents