Information System Analyst

Supportingdoc.zip

Home >Information Systems homework help >Information System Analyst

ASSIGNMENT.doc

INSTRUCTION:

· You should submit your exam to your assignment folder in WebTycho in a MS-Word, MS-RTF, PDF or ASCII file. Please scan your file against viruses before submitting.

· Please keep the full text of the question as part of your answering sheet.

· Be as clear and objective as you can in all questions and be sure you are answering what is asked.

· Justify all your numerical answers and answer all the questions using your own words. Show all your work, including how you found your answer (this is very important and essential to have your answer graded appropriately!).

Make sure that you read, acknowledge, and follow the following rules

Rules:

· This is an open-book exam, but you are only allowed to use your textbook and information posted in our classroom. Please do not use any other sources that are not listed in our classroom. For example, you can refer to our class lecture notes, and all links posted in the lecture notes, but you should not search the Web for information to solve exam questions.

You should not discuss exam questions with other students or anyone else.

· Problem I - (40 points)

Part A: Your systems analysis team is close to completing a system for Meecham Feeds. Roger is quite confident that the programs that he has written for Meecham’s inventory system will perform as necessary, because they are similar to programs he has done before. Your team has been very busy and would ideally like to begin full systems testing as soon as possible.

Two of your junior team members have proposed the following:

a) Skip desk checking of the programs (because similar programs were checked in other installations; Roger has agreed). (10 points)

b) Do link testing with large amounts of data to prove that the system will work. (10 points)

c) Do full systems testing with large amounts of live data to show that the system is working. (10 points)

Respond to each of the three steps in their proposed test schedule. Use a paragraph to explain your response.

Part B: Mr. Bruce Schnieder, the owner of A&A Office Supplies Company, had contacted you for your advices on a new information system installed recently at his company to help improving his company inventory tasks. He told you that the team that came to install the system does not have any evaluation mechanism and he also mentioned to you that some of his employees had complained about the new system’s inputs and outputs. Since he wants to obtain the inventory result of this quarter, he would like to delay or skip the new system evaluation and use the new system for inventory right away. Given the above conditions, he would like to have your advices on his decision and on the evaluation of his new system.

a) In a paragraph, explain to Mr. Schnieder about problems that can occur when a system is not evaluated systematically? (5 points)

b) Devise a checklist or form that helps Mr. Schnieder’s employees evaluate the utilities of the new information system. Suggest a second way to evaluate the information system, if any. Please be specific and explain your answers. (5 points)

Problem II - (40 points)

Cherry Jones owns a homeopathic medicine company called Faithhealers. She sells vitamins and other relatively nonperishable products for those who want choices regarding alternative medicine. Cherry is developing a new system that would require her staff to be retrained.

a) Construct a PERT diagram for her and identify the critical path. (10 points)

Description Task Must Follow Time

Interview Executives A None 6

Interview staff in orders fulfillment B None 3

Design input prototype C B 2

Design output pro-type D A,C 3

Write use cases E A,C 4

Record staff reactions to prototypes F D 2

Develop system G E,F 5

Write up training manual H B,G 3

Train staff working in order fulfillment I H 2

b) If Cherry could find away to save time on the “write use cases” phase, how would it help? (30 points)

Problem III- (40 points)

The problem is that the orders are not easily placed to the European plant, which is compounded whenever demand for the products increases dramatically. The company is looking for a systems solution that will address the problem and the solution should stress collaboration, flexibility, adaptability, and access.

One of your systems analyst team members proposed the following simple network solution that is to create an intranet that links the U.S. distributors with the European headquarters.

image1.wmf

Distribution

Centers

European

Plant

Intranet

Order

Processing

Production

Control

As a systems analyst, would you approve this proposal? (The diagram is the proposal)

Please explain the reasons why you support or do not support this proposal. …need to offer some modifications to improve it.

Problem IV - (40 points)

All Pets Clinic Pharmacy has offered to give you a free lifetime supply of medicine if you design its database.

Given the rising cost of veterinarian care, you agree.

The following is the information you gathered:

· Pets are identified by a code #, and their names, addresses, and ages must be recorded

· Veterinarians are identified by an SSN. For each veterinarian, the name. specialty, and years of experience must be recorded.

· Each pharmaceutical company is identified by name and has a phone number

· For each medication, the trade name and formula must be recorded. Each medication is sold by a given pharmaceutical company, and the trade name identifies a medication uniquely from among the products of that company. Each pharmacy has a name, address, and phone number

· Pharmaceutical companies have long-term contracts with pharmacies. A pharmaceutical company can contract with several pharmacies, and a pharmacy can contract with several pharmaceutical companies. For each contract, you have to store a start date, an end date, and the text of the contract.

· Pharmacies appoint a supervisor for each contract. There must always be a supervisor for each contract, but the contract supervisor can change over the lifetime of the contract.

· Each pharmacy sells several medications and has a price for each. A medication could be sold at several pharmacies, and the price could vary from one pharmacy to another.

· Each medication has a date and a quantity associated with it. You can assume that, if a veterinarian prescribes the same medication for the same pet more than once, only the last such medication needs to be stored.

Note: Draw an ER diagram that captures the preceding information.

1. How would your design change if each medication must be sold at a fixed price by the pharmacies? (Requirement: Provide a written explanation) (20pts.)

2. How would your design change if the design requirements change as follows: If a veterinarian prescribes the same medication for the same pet more than once, several such prescriptions may have to be stored? (Requirement: Provide a written explanation) 20pts.

Problem V - (40 points)

Consider a school advising system in which a faculty advisor can advise many students, each of whom can register for one or many courses. The following is an example of an un-normalized STUDENT table for three students.

STUDENT

Student Number	Student Name	Total Credits	GPA	Advisor Number	Advisor Name	Course Number	Course Description	Course Credits	Grade
1034	Linda	47	3.60	59	Smith	CSC101	Computer Science I	4	B
						MKT211	Marketing Management	3	A
						ENG101	English Composition	3	B
						CHM111	General Chemistry I	4	A
						BUS101	Introduction to Business	2	A
3397	Sam	29	3.00	59	Smith	ENG101	English Composition	3	A
						MKT211	Marketing Management	3	B
						CSC101	Computer Science I	4	B
4070	Kelly	14	3.20	23	Jones	CSC101	Computer Science I	4	B
						CHM111	General Chemistry I	4	A
						ENG101	English Composition	3	B
						BUS101	Introduction to Business	2	B

Perform the normalization process to convert the above un-normalized table to:

1. First normal form (1NF).

2. Second normal form (2NF).

3. Third normal form (3NF).

Please show all your work. Please show each step along the way and identify primary keys, if any, in each table in each step.

An Example of Database Normalization.docx

ITEC 630

Information Systems Analysis, Modeling, and Design

Lecture Notes

An Example of Database Normalization

Created by Daniel Le Revised by Daniel Le 07/31/2016

Consider a project management system in which each employee is assigned to a specific department and employees from several departments often are assigned to special project teams, however, when a new product is launched or for major marketing events. Note that the project hours are the number of hours that employees charge to their assigned projects. The following is an example of an un-normalized PROJECT-DATA table for two projects.

PROJECT-DATA

Project Number	Project Name	Start Date	Employee Number	Employee Name	Job Title	Department Number	Department Name	Project Hours
1	ACORN	04/10/2015	2489	Smith	Manager	1	Web Design	450
			1887	Jones	Engineer	1	Web Design	400
			9540	Mike	Technician	5	Desktop	450
2	IMPPOAS	12/15/2015	3436	Catherine	Programmer	2	Software	1500
			2489	Smith	Manager	1	Web Design	100

Perform the normalization process to convert the above un-normalized table to:

1. First normal form (1NF)

2. Second normal form (2NF)

3. Third normal form (3NF)

SOLUTION

UNNORMALIZED PROJECT-DATA (Figure 1)

Project Number	Project Name	Start Date	Employee Number	Employee Name	Job Title	Department Number	Department Name	Project Hours
1	ACORN	04/10/2015	2489	Smith	Manager	1	Web Design	450
			1887	Jones	Engineer	1	Web Design	400
			9540	Mike	Technician	5	Network	450
2	IMPPOAS	12/15/2015	3436	Catherine	Programmer	2	Software	1500
			2489	Smith	Manager	1	Web Design	100

This PROJECT-DATA table shown in Fig. 1 is un-normalized because it contains a repeating group (enclosed within a pair of square brackets. The PROJECT-DATA table design can be written as:

PROJECT-DATA (Project Number, Project Name, Start Date, [Employee Number, Employee Name, Job Title, Department Number, Department Name, Project Hours])

1NF PROJECT-DATA (Figure 2A)

Project Number	Project Name	Start Date
1	ACORN	04/10/2015
2	IMPPOAS	12/15/2015

EMPLOYEE-INFORMATION (Figure 2B)

Project Number	Employee Number	Employee Name	Job Title	Department Number	Department Name	Project Hours
1	2489	Smith	Manager	1	Web Design	450
1	1887	Jones	Engineer	1	Web Design	400
1	9540	Mike	Technician	5	Network	450
2	3436	Catherine	Programmer	2	Software	1500
2	2489	Smith	Manager	1	Web Design	100

PROJECT-DATA (Project Number, Project Name, Start Date)

EMPLOYEE-INFORMATION (Project Number, Employee Number, Employee Name, Job Title, Department Number, Department Name, Project Hours)

As shown in each record of the 1NF EMPLOYEE-INFORMATION table, (1) the field Employee Name, Job Tile, Department Number, and Department Name depend on the Employee Number key, and (2) the field Project Hours is the only one that depends on the combined primary key “Project Number and Employee Number).

2NF PROJECT-DATA (Figure 3A)

Project Number	Project Name	Start Date
1	ACORN	04/10/2015
2	IMPPOAS	12/15/2015

EMPLOYEE-DEPARTMENT (Figure 3B)

Employee Number	Employee Name	Job Title	Department Number	Department Name
2489	Smith	Manager	1	Web Design
1887	Jones	Engineer	1	Web Design
9540	Mike	Technician	5	Network
3436	Catherine	Programmer	2	Software
2489	Smith	Manager	1	Web Design

EMPLOYEE-PROJECT-HOURS (Figure 3C)

Project Number	Employee Number	Project Hours
1	2489	450
1	1887	400
1	9540	450
2	3436	1500
2	2489	100

Based on the above analysis of field dependencies to the primary key, we will keep the PROJECT-DATA table (Fig. 3A) unchanged but we should break the EMPLOYEE-INFORMATION table into two tables EMPLOYEE-DEPARTMENT (Fig. 3B) and EMPLOYEE-PROJECT-HOURS (Fig. 3C).

The 2NF PROJECT-DATA table design can be written as:

PROJECT-DATA (Project Number, Project Name, Start Date)

The 2NF EMPLOYEE-DEPARTMENT table design can be written as:

EMPLOYEE-DEPARTMENT (Employee Number, Employee Name, Job Title, Department Number, Department Name)

The 2NF EMPLOYEE-PROJECT-HOURS table design can be written as:

EMPLOYEE-PROJECT-HOURS (Project Number, Employee Number, Project Hours)

In each of these three tables, every non-key field depends on their entire primary key. Are these three tables in 3NF? The PROJECT-DATA and EMPLOYEE-PROJECT-HOURS tables are in 3NF but the EMPLOYEE-DEPARTMENT table is not in 3NF because the non-key field Department Name depends on the non-key field Department Number. In 3NF, no non-key field should be dependent on another non-key field so the EMPLOYEE-DEPARTMENT table should be broken into two tables called EMPLOYEE and DEPARTMENT. The DEPARTMENT table consists of two fields Department-Number and Department-Name where the Department-Number acts as the primary key. The entire set of 3NF tables are shown in Fig. 4A, 4B, 4C, and 4D below.

3NF PROJECT-DATA (Figure 4A)

Project Number	Project Name	Start Date
1	ACORN	04/10/2015
2	IMPPOAS	12/15/2015

EMPLOYEE (Figure 4B)

Employee Number	Employee Name	Job Title	Department Number
2489	Smith	Manager	1
1887	Jones	Engineer	1
9540	Mike	Technician	5
3436	Catherine	Programmer	2
2489	Smith	Manager	1

DEPARTMENT (Figure 4C)

Department Number	Department Name
1	Web Design
5	Network
2	Software

EMPLOYEE-PROJECT-HOURS (Figure 4D)

Project Number	Employee Number	Project Hours
1	2489	450
1	1887	400
1	9540	450
2	3436	1500
2	2489	100

The final 3NF design is as follows:

The 3NF PROJECT-DATA table design can be written as:

PROJECT-DATA (Project Number, Project Name, Start Date)

The 3NF EMPLOYEE table design can be written as:

EMPLOYEE (Employee Number, Employee Name, Job Title, Department Number)

The 3NF DEPARTMENT table design can be written as:

DEPARTMENT (Department Number, Department Name)

The 3NF EMPLOYEE-PROJECT-HOURS table design can be written as:

EMPLOYEE-PROJECT-HOURS (Project Number, Employee Number, Project Hours)

ITEC-630.Data.Oriented.Analysis1 (Week 7).docx

ITEC 630

Information Systems Analysis, Modeling, and Design

Lecture Notes

Data-Oriented Analysis

Conceptual Data Modeling and the E-R Model

Created by Daniel Le

Learning objectives

1. Learn the definitions of data-oriented analysis terms

2. Learn the conceptual data model and the entity relationship (ER) modeling

3. Understand the business rules applicable to the logical data model

4. Understand rules and style guidelines for creating ERDs.

5. Learn how to create an ERD.

Overview

This week lecture presents entity relationship (ER) diagramming, one of the most common data modeling techniques used in industry. This data model describes the data that flow through the business processes in an organization. In the previous phases, the data model presents the logical organization of data without indicating how the data are stored, created, or manipulated. In the design phase, the data model is changed to reflect exactly how the data will be stored in databases and files.

DEFINITION OF DATA-ORIENTED ANALYSIS TERMS

An Entity-Relationship Diagram (ERD)

· An ERD describes the normalized data environment and data scope of the application.

· For data modeling, the major activity is the creation and refinement of an ERD.

An Entity Type or Entity

· An entity is some person, object, concept, application, or event from the real world about which we want to maintain data.

· All entities are drawn on the ERD as rectangles.

· There are three kinds of entities: fundamental, attributive, and associative.

· A fundamental entity is independent of all other entities and can be defined without thinking about other entities.

· An attributive entity is an entity whose existence depends on the presence of a fundamental entity.

· Attributive entities contain repeating information relating to a fundamental entity.

· An associative entity is used to simplify and define complex relationships between entities.

Relationships and Cardinalities

· A relationship is a mutual association between two or more entities.

· It is shown as a line connecting the entities.

· A relationship has cardinality, or the number of the relationship.

· Cardinalities may be one-to-one, one-to-many, or many-to-many.

· Cardinality is shown on a diagram by crows' feet to indicate a 'many' relationship and a single line to indicate a singular relationship.

Refinement of an ERD

· The refinement of an ERD consists of two activities:

· Attributes (fields or data items) are defined, and

· The ERD is normalized.

· Attributes are named properties or characteristics of an entity which take on values.

Normalization

· Normalization is the refinement of data relationships to remove repeating information, partial key dependencies, and non-key dependencies.

· Normalization can be directly applied to the ERD by examination of the relationship cardinalities and the attributes of entities.

· For m:n relationships, and for entities with repetitive information in the entity, we create (or validate) attributive entities.

· For an m:n relationship, the relationship is promoted to create an associative entity (or relationship entity). The cardinalities of m:n are reversed to create two 1:m relationships.

CONCEPTUAL DATA MODEL

Conceptual data model is a detailed model that captures the overall structure of organizational data that is independent of any database management system or other implementation considerations.

INTRODUCTION TO E-R MODELING

· An entity-relationship data model (E-R model) is a detailed, logical representation of the entities, associations, and data elements for an organization or business area.

· An entity-relationship diagram (E-R diagram) is a graphical representation of an E-R model.

· An entity type is a collection of entities that share common properties or characteristics.

· An entity instance (instance) is a single occurrence of an entity type.

· An attribute is a named property or characteristic of an entity that is of interest to the organization.

· A Candidate key is an attribute (or combination of attributes) that uniquely identifies each instance of an entity type.

· An identifier is a candidate key that has been selected as the unique, identifying characteristic for an entity type.

· A multivalued attribute is an attribute that may take on more than one value for each entity instance.

· A repeating group is a set of two or more multivalued attributes that are logically related.

CONCEPTUAL DATA MODELING AND THE E-R MODEL

· The degree of a relationship is the number of entity types that participate in that relationship.

· A unary relationship is a relationship between the instances of one entity type. It is also called a recursive relationship.

· A binary relationship is a relationship between the instances of two entity types. This is the most common type of relationship encountered in data modeling.

· A ternary relationship is a simultaneous relationship among instances of three entity types.

· The Cardinality of a relationship is the number of instances of entity B that can be associated with each instance of entity A.

· An associative entity is an entity type that associates the instances of one or more entity types and contains attributes that are peculiar to the relationship between those entity instances.

BUSINESS RULES

· Business rules are specifications that preserve the integrity of the logical data model.

· A domain is the set of all data types and values that an attribute can assume.

· A triggering operation (or trigger) is an assertion or rule that governs the validity of data manipulation operations such as insert, update, and delete.

DEVELOP ENTITY-RELATIONSHIP DIAGRAM

Rules for Entity-Relationship Diagram

The steps to building an entity relationship diagram (ERD) are as follows:

1. Define fundamental entities and their primary keys.

2. Define the relationships between the fundamental entities.

3. Identify all attributes of entities, including primary keys.

4. Add attributive entities, where needed, to simplify one-to-many relationships.

5. Promote all many-to-many relationships to define associative entities.

6. Normalize the fundamental entities, analyzing if there are other entities which are hidden in the current definitions. Place new entities in the ERD. Define the new entities' attributes and primary keys.

7. Analyze the entities and their relationships to determine if a class structure is needed. If some instances of entities have identifiable differences in processing, data stored, or relationship participation, classes probably are needed.

References

1. J.B. Dixit and Raj Kumar (2007). Structured System Analysis and Design, Laxmi Publications.

Disclaimer: Some articles or sites I select or refer you to may include materials or opinions associated with particular political or other ideological positions. My pointing to these sites in no way suggests that I am encouraging a particular ideology or position on this or any other related topic; these are simply some of the more interesting and informative sites I have found to cover the topic(s) at hand. As always, you must consider the source when reading any materials that may reflect a particular ideological point of view on an issue.

ITEC-630.Data.Storage.Design1 (Week 8).docx

ITEC 630

Information Systems Analysis, Modeling, and Design

Lecture Notes

Designing Databases

Created by Daniel Le

Learning objectives

1. Understand database design concepts

2. Learn the relational database model

3. Learn how to use normalization to efficiently store data in a database

4. Learn how to transform E-R diagrams into relations

5. Learn how to design physical files and databases

6. Understand the role of the data base administrator

7. Understand the relationship of business intelligence to data warehouses, big data, business analytics and text analytics in helping systems and people make decisions.

Overview

During the system analysis phase, data flow diagrams are used to create a logical design for the information system. In this systems design phase, a physical design for data organization, storage, and retrieval will be developed for the system. This week lecture presents database concepts, discusses file-based systems and database systems, shows how to create entity-relationship diagrams, and concludes with a discussion of data warehouses and data mining. We will learn guidelines for well-structured and efficient database files and about logical and physical database design.

DATABASE DESIGN & RELATIONAL DATABASE MODEL

· Primary key is an attribute whose value is unique across all occurrences of a relation.

· Relational database model is data represented as a set of related tables or relations.

· Well-structured relation (or table) is a relation that contains a minimum amount of redundancy and allows users to insert, modify, and delete the rows without errors or inconsistencies.

NORMALIZATION

· Normalization is the process of converting complex data structures into simple, stable data structures.

· Functional dependency is a particular relationship between two attributes.

· Second normal form (2NF) A relation for which every nonprimary key attribute is functionally dependent on the whole primary key.

· Third normal form (3NF) A relation that is in second normal form and that has no functional (transitive) dependencies between two (or more) nonprimary key attributes.

Three steps of data normalization

A. Remove all repeating groups and identify the primary key.

· First Normal Form (lNF).

B. Ensure that all non-key attributes are fully dependent on the primary key. Remove partial key dependencies.

· Second Normal Form (2NF).

C. Remove any transitive dependencies, attributes that are dependent on other non-key attributes. Remove non-key dependencies.

· Third Normal Form (3NF).

TRANSFORMING E-R DIAGRAMS INTO RELATIONS

· Foreign key is an attribute that appears as a nonprimary key attribute in one relation and as a primary key attribute (or part of a primary key) in another relation.

· Referential integrity An integrity constraint specifying that the value (or existence) of an attribute in one relation depends on the value (or existence) of the same attribute in another relation.

· Recursive foreign key is a foreign key in a relation that references the primary key values of that same relation.

MERGING RELATIONS

· Synonyms are two different names that are used for the same attribute.

· Homonym is a single attribute name that is used for two or more different attributes.

PHYSICAL FILE AND DATABASE DESIGN

· A field is the smallest unit of named application data recognized by system software.

· A data type is a coding scheme recognized by system software for representing organizational data.

· Calculated (or computed or derived) field is a field that can be derived from other database fields.

· A default value is a value a field will assume unless an explicit value is entered for that field.

· A null value is a special field value, distinct from a zero, blank, or any other value, that indicates that the value for the field is missing or otherwise unknown.

· A physical table is a named set of rows and columns that specifies the fields in each row of the table.

· Denormalization is the process of splitting or combining normalized relations into physical tables based on affinity of use of rows and fields.

· A physical file is a named set of table rows stored in a contiguous section of secondary memory.

· File organization is a technique for physically arranging the records of a file.

· A pointer is a field of data that can be used to locate a related field or row of data.

· In a sequential file organization the rows in the file are stored in sequence according to a primary key value.

· In an indexed file organization the rows are stored either sequentially or nonsequentially and an index is created that allows software to locate individual rows.

· An index is a table used to determine the location of rows in a file that satisfy some condition.

· Secondary key is one or a combination of fields for which more than one row may have the same combination of values.

· In a hashed file organization the address for each row is determined using an algorithm.

THE ROLE OF THE DATA BASE ADMINISTRATOR

· Managing the data base requires a data base administrator (DBA) whose key functions are to manage data activities, the data base structure, and the DBMS.

· In addition to a managerial background, the DBA needs technical knowledge to deal with data base designers. Important for the success of this important job is the support of the senior MIS staff and upper management for the overall data base function.

DATA WAREHOUSES, BIG DATA, BUSINESS ANALYTICS AND TEXT ANALYTICS

Data warehouses are used organize information for handling queries quickly and effectively. There are many differences between data warehouse and database. When data sets are too big and/or too complex then big data is used to handle it. In order to make use of available data, techniques such as business analytics and text analytics are used to extract and/or convert data into useful information.

References

1. Conger, Sue (2008). The New Software Engineering. A Creative Commons Attribution 3.0 License.

2. J.B. Dixit and Raj Kumar (2007). Structured System Analysis and Design, Laxmi Publications.

3. http://www.w3computing.com/systemsanalysis/data-warehouses/

ITEC-630.Human.Computer.Interaction1 (Week 10).docx

ITEC 630

Information Systems Analysis, Modeling, and Design

Lecture Notes

Human Computer Interaction

Created by Daniel Le

Learning objectives

1. Understand human-computer interaction

2. Design a variety of user interfaces

3. Learn two methods of usability inspections

4. Recognize human factor in HCI Design

5. Design effective onscreen dialog for HCI

6. Understand the importance of user feedback

7. Understand guidelines for usability in both GUIs and Web interface design

Overview

The human-computer interaction (HCI) is a very important aspect in computer information technology. It is considered as a layer of communications and interactions between humans and the computer. The study of HCI focuses on improving the interactions between users and computers by making computers more usable and receptive to the user's needs. Some organizations employ professional HCI designers, who specialize in applying design processes to the creation of graphical user interfaces and Web interfaces. In this lecture, we will learn about the history of HCI and the design of user interface, usability applicable to both GUIs and Web design, human factors, types of user interfaces, dialog design, feedback for users and some considerations in Web interface design.

UNDERSTANDING HUMAN-COMPUTER INTERACTION

Human-computer interaction (HCI) is an interaction between a human user and a computer system to perform tasks. The study of HCI focuses on making this interaction work better and its goal is to offer users with a high degree of usability.

Usability covers the effectiveness and efficiency of the user interface and the satisfaction of users in using that interface. As a result, two main factors are considered in measuring of usability are “ease of learning” and “ease of use”. Regarding the World Wide Web, even though there are some differences between graphic user interfaces and the Web, the HCI usability principles apply equally to both GUIs and Web interface design.

USABILITY INSPECTIONS

Two inspection methods for evaluating the usability are heuristic evaluation and walkthroughs. The first one uses a set of usability principles known as heuristics to evaluate whether user-interface elements conform to the principles. The second one “walks through a task with the system and noting problematic usability features.”

HUMAN FACTOR IN HCI DESIGN

One of the important factors to consider in the design of HCI is the human factor, which includes sensors (vision, hearing, taste, smell, and touch), responders, and a brain. The variability humans bring a big challenge when creating a GUI system that is expected to work well for everyone. As a result, it would help GUI designers to overcome this challenge by understanding aspects of the human that affect HCI.

TYPES OF USER INTERFACES

The user interface is the system that allows users to communicate with the computer systems. There are quite a few of interface types covering about 20 interface types, starting with command-based and ending with brain–computer. Therefore, GUI designers need to know how to apply particular interfaces to different environments, people, places, and activities.

PRINCIPLES AND GUIDELINES FOR DIALOG DESIGN

Dialogs describe the conversation between the user and the computer and two main components of dialog design are dialog outline and dialog control. The first one is for representation of on-line screen activities and the second one is for representation of execution sequence. There are several types of dialogs including command, menu, form-fill-in, direct manipulation, or a combination of these.

FEEDBACK FOR USERS

Use feedback to indicate that an action is happening and was either successful or unsuccessful. Provide feedback responsively so that users remain confident and know what is going on. There are many ways to provide feedback, so choose the least intrusive form that communicates well.

WORLD WIDE WEB DESIGN CONSIDERATIONS

As mentioned in the above, the HCI usability principles apply equally to both GUIs and Web interface design regardless their differences. However, in addition to differences, usability designers should take into account to the predominant and recurring usability problems in the Web. Therefore, extra considerations are needed when developing Web interfaces by paying particular attention to Web usability and strategy, learning to avoid mistakes, and taking advantages of new available technologies.

Mashups

A mashup is a web page or a web application created by combining or integrating information from different application programming interfaces (API).

References

1. Albert N. Badre (2002). Shaping Web Usability: Interaction Design in Context, Addison-Wesley Professional.

2. Everett N. McKay (2013). UI is Communication: How to Design Intuitive, User-Centered Interfaces by Focusing on Effective Communication, Morgan Kaufmann Publishers.

3. Florian Daniel and Maristella Matera (2014). Mashups: Concepts, Models and Architectures, Springer.

4. I. Scott MacKenzie (2013). Human-Computer Interaction: An Empirical Research Perspective, Morgan Kaufmann Publishers.

5. Rajendra Kumar (2011). Human Computer Interaction, Second Edition, Laxmi Publications.

6. Smashing Magazine (2013). How to Create Selling E-Commerce Websites.

7. Yvonne Rogers, Helen Sharp, and Jenny Preece (2011). INTERACTION DESIGN: beyond human-computer interaction, 3rd Edition, John Wiley & Sons

8. https://www.usability.gov/sites/default/files/documents/guidelines_book.pdf

Disclaimer: Some articles or sites that I refer you to may include materials or opinions associated with particular political or other ideological positions. My pointing to these sites in no way suggests that I am encouraging a particular ideology or position on this or any other related topic; these are simply some of the more interesting and informative sites I have found to cover the topic(s) at hand. As always, you must consider the source when reading any materials that may reflect a particular ideological point of view on an issue.

ITEC-630.Quality.Assurance.and.Implementation1 (Week 11).docx

ITEC 630

Information Systems Analysis, Modeling, and Design

Lecture Notes

Quality Assurance and Implementation

Created by Daniel Le

Learning objectives

1. Recognize the importance of users and analysts taking a total quality approach to improve the quality of software design and maintenance.

2. Realize the importance of testing and maintenance.

3. Understand how client–server architectures and cloud computing is changing the nature of information system design.

4. Be familiar with the system construction process.

5. Explain different types of tests and when to use them.

6. Describe how to develop user documentation.

7. Explain the system installation process.

8. Describe the elements of a migration plan.

9. Explain different types of conversion strategies and when to use them.

10. Describe several techniques for managing change.

11. Outline postinstallation processes.

Overview

Quality is a very important factor in the analysis and design of the information systems and it should be concerned in the entire SDLC. Implementation of the information system is defined as “the process of ensuring that the information system is operational and then allowing users to take over its operation for use and evaluation”.

In this lecture “Quality Assurance and Implementation”, we will learn (1) approaches to quality assurance including designing systems and software with a top-down approach and modular approach, (2) several approaches to implementation including distributed computing, cloud computing, and service-oriented architecture, (3) the move into the implementation phase , and (4) the transition to the new system.

THE TOTAL QUALITY MANAGEMENT APPROACH

Total Quality Management (TQM)

· The International Organization for Standardization (ISO) defines TQM as “a management approach for an organization, centered on quality, based on the participation of all its members, and aiming at long-term success through customer satisfaction and benefits to all members of the organization and to society.”

Six Sigma

· Six Sigma is a top-down approach to quality management and it is developed by Motorola in the 1980s. Systems analysts and systems users need should apply some of its principles to their systems analysis projects for quality assurance management.

· The goal of Six Sigma is to eliminate all defects and it consists of seven steps as follows:

1. Define the problem

2. Observe the problem

3. Analyze the causes

4. Act on the causes

5. Study the results

6. Standardize the changes

7. Draw conclusions

Responsibility for TQM

In order to apply the total quality management to systems projects, the full organizational support from management is required in action by measuring "how the quality of information systems and information itself affects people work." In addition, the systems analysts and business users of the system should make real commitment to quality throughout the systems development life cycle.

Structured walkthrough

In a total quality management approach, structured walkthroughs can be used by the systems analysis team for quality assurance. Structured walkthroughs offer ways to monitor the system’s programming and overall development, identify problems, and allow making suitable changes.

Three major approaches to quality assurance: designing systems and software with a top-down, modular approach, documenting systems and software, and testing systems and software. Several approaches to implementation considered by systems analysts in the area of distributed computing include client-server technology and cloud computing.

DESIGNING SYSTEMS AND SOFTWARE WITH A TOP-DOWN AND MODULAR APPROACH

Using the top-down design, the systems analysts consider at first the overall system and then they could divide that system into subsystems and further into manageable sized modules where modular programming techniques could be applied.

Structure Charts

The structure chart is an important top-down technique that helps the analyst design the program for the new system. It shows all the functional components of the program at a high level, arranged in a hierarchical format that implies order and control. The structure chart is the recommended tool for designing a modular, top-down system.

DISTRIBUTING PROCESSING

Two technologies are considered in the area of distributing processing are: client-server technology and cloud computing.

Client-Server Technology

· In Client–server architectures, the client is responsible for the presentation logic and the server is responsible for the data access logic and data storage.

· In thin Client–server architectures, the server performs the application logic, while in thick Client–server architectures; the application logic is shared between the servers and clients.

· In a two-tiered Client–server architecture, there are two groups of computers: one client and a set of servers.

· In a three-tiered Client–server architecture, there are three groups of computers: a client, a set of application servers, and a set of database servers.

Cloud Computing

· The cloud computing can be defined as the set of hardware, networks, storage, services, and interfaces that combine to deliver

· The cloud computing is applicable when organizations and users can use Web-based services such as database services, application services, etc. over the Internet without investing any hardware and software resources.

· Cloud computing can be implemented in three ways: private cloud, public cloud, and hybrid clouds.

MOVING INTO IMPLEMENTATION

As the implementation phase begins, the construction of the new system is started. A major component of building the system is writing programs and during this phase, it is the responsibility of the systems analysts to finalize the system documentation and develop the user documentation.

MANAGING THE PROGRAMMING PROCESS

Programming is done by programmers and the project manager or systems analyst must ensure that the process of programming is conducted successfully by executing the following tasks: assigning programming tasks, coordinating the activities, and managing the programming schedule.

TESTING

Tests must be carefully planned to eliminate as much as possible the remaining system bugs because it usually costs too much if major bugs are discovered after the system is installed. A test plan contains several tests that examine different aspects of the system.

There are four general stages of tests as follows:

1. Unit tests: A unit test examines a module or program within the system.

2. Integration tests: An integration test examines how well several modules work together.

3. System tests: A system test examines the system as a whole.

4. Acceptance tests: An acceptance test is done by the users to determine whether the system is acceptable to them.

DEVELOPING DOCUMENTATION

There are two fundamentally different types of documentation: system documentation and user documentation. System documentation is intended to help programmers and systems analysts understand the application software. User documentation is designed to help the user operate the system. Today, documentation is moving away from paper-based documents to online documentation for easy access. There are three types of user documentation: reference documents, procedures manuals, and tutorials.

MAKING THE TRANSITION TO THE NEW SYSTEM

The Lewin's three-step model of organizational change consisting of unfreeze, move, and refreeze is used to make the transition to the new system.

THE MIGRATION PLAN

The migration plan includes the decisions, plans, and procedures that will be used to guide the transition. In this plan, issues related to business, technology, and people are addressed. For preparing the business, two issues “select a conversion strategy” and “prepare a business contingency plan” are discussed. For preparing the technology, three issues “install hardware”, “install software”, and “convert data” are discussed. Finally, for preparing the people, four issues to be covered are “revise management policies”, “access costs and benefits”, “motivate adoption”, and “conduct training”. It is important for the project managers or systems analysts to know that “understanding the sources of resistance to change and the costs and benefits that the users perceive will help analysts develop a successful migration plan.”

POSTIMPLEMENTATION ACTIVITIES

The goal of postimplementation stage is to institutionalize the use of the new system and there are three key activities in this stage: system support, system maintenance, and project assessment. System support is performed by the operations group by providing online and help-desk support to the users. System maintenance responds to change requests to fix bugs and improve the business value of the system. Project assessment measures what was successful about the system, what activities were good, and what activities need to be improved. The project assessment consists of two parts: project team review and system review.

References

1. Alan Dennis, Barbara Haley Wixom, and Roberta M. Roth (2012). System Analysis and Design, Fifth Edition, John Wiley & Sons.

2. Murali Chemuturi (2010). Mastering Software Quality Assurance, J. Ross Publishing.

3. www.w3computing.com

ITEC-630.User.Interface.Design1 (Week 10).docx

ITEC 630

Information Systems Analysis, Modeling, and Design

Lecture Notes

User Interface Design

Created by Daniel Le

Learning objectives

1. Describe several fundamental user interface design principles.

2. Explain the process of user interface design.

3. Discuss how to design the user interface structure.

4. Explain how to design the user interface standards.

5. Be able to design a user interface.

Overview

In general, interface design is the process of defining how the system will interact with external entities such as users or other systems. Therefore, there are user interfaces and system interfaces but this week lecture focuses on the design of user interfaces. A user includes the screen displays, the screens and forms that capture data, and the reports that the system produces. This week lecture presents the basic principles and processes of interface design and discusses how to design the interface structure and standards.

The user interface includes the input mechanism, the output mechanism, and the navigation mechanism. The input mechanism is the way in which the system captures information from users. The output mechanism is the way in which the system provides information to the user. The navigation mechanism is the way in which the user gives instructions to the system and tells it what to do.

This week lecture describes several fundamental user interface design principles and an overview of the user interface design process. It then provides an overview of the input mechanism, the output mechanism, and the navigation mechanism of user interface. This lecture focuses on the design of Web-based interfaces and graphical user interfaces (GUI) that use windows, menus, icons, and a mouse (e.g., Windows, Macintosh).

PRINCIPLES FOR USER INTERFACE DESIGN

User interface design is an art and its goal is to make the interface visually appealing and simple to use. Several fundamental interface design principles that are common for navigation design, input design, and output design should be considered are layout, content awareness, aesthetics, user experience, consistency, and minimize user effort.

USER INTERFACE DESIGN PROCESS

The user interface design consists of a five-step process as follows:

1. Use Scenario Development

2. Interface Structure Design

3. Interface Standards Design

4. Interface Design Prototyping

5. Interface Evaluation

This process is iterative where systems analysts often move back and forth between steps. For the last step “interface evaluation”, it can be conducted by heuristic evaluation, walk-through evaluation, interactive evaluation, or formal usability testing.

NAVIGATION DESIGN

The goal of the navigation design is to make the system easy to use for users and to communicate to users with meaningful messages and/or recommended actions regarding the system conditions and statuses. The design should help prevent users from making mistakes, simplify the recovery from mistakes, and use consistent grammar order.

Menus (such as menu bar, drop-down menu, hyper-link menu, embedded hyperlinks, pop-up menu, tab menu, buttons and toolbars, and image maps), command languages, natural languages, and direct manipulation are used in navigation.

Error messages, confirmation messages, acknowledgment messages, delay messages, and help messages are common types of messages that the system responds to users.

INPUT DESIGN

The input design means designing a mechanism (screens, forms, etc.) to capture data into the system by using online or batch processing, capturing data at the source, and minimizing keystrokes. The goal of input design is to simply and easily capture accurate information for the system.

There are many different types of inputs including text fields, number fields, check boxes, radio buttons, on-screen list boxes, drop-down list boxes, and sliders. All data entered into the system should be validated by some combination of validation checks for minimizing users’ mistakes, reducing invalid information, and ensuring accuracy. There are six different types of validation checks: completeness check, format check, range check, check digit check, consistency check, and database check.

OUTPUT DESIGN

Outputs are the most visible part of a system and they can be presented on the screen, on paper, or in other media, such as the World Wide Web. The goal of output design is to let system users accurately understand presented information with the least effort.

There are many types of reports: detail reports, summary reports, exception reports, turnaround documents, and graphs.

References

1. Alan Dennis, Barbara Haley Wixom, and Roberta M. Roth (2012). System Analysis and Design, Fifth Edition, John Wiley & Sons.

W10.Safari.References.docx

W10.Safari.References

Ctrl+Click the following links to go to their place in this document

· From Human Factors to Usability: A Short History of HCI

· HCI Principles for the Web

· Inspections: Heuristic Evaluation and Walkthroughs

· Types of User Interfaces

· Web Usability

· Web Usability Strategy

· Principles for User Interface Design

· User Interface Design Process

· Navigation Design

· Input Design

· Output Design

From Human Factors to Usability: A Short History of HCI

During the past two decades, both the number and diversity of people using computers have increased dramatically. Computers now mediate everyday activities in business, industry, education, entertainment, and the home, whereas until the early 1980s computer use was restricted to the technically sophisticated. This rise in use led to a flurry of interface research and design activities during the 1980s and 1990s, which produced the Graphic User Interface (GUI) and, eventually, the Web.

Origins

Scientific interest in the interaction between human beings and computers and user interface design is rooted in the more general area of human-machine systems, human factors engineering, and ergonomics. Systematic investigations of human factors engineering go back to the early time-and-motion studies of Frank Gilbreth. These and all other studies conducted between the world wars concentrated on the operator's muscular capabilities and limitations. During World War II, the emergence of radar and the technology associated with aircraft cockpits led to a shift in emphasis away from physical interaction with machines to the perceptual and decision-making capabilities of operators.

Toward the end of the 1950s, interest in human-computer interfaces arose out of this system's engineering tradition and crystallized around Licklider's concept of symbiosis. Licklider described a relationship in which the human operator and the computer and its software form two distinct but interdependent systems. They cooperate to attain a goal because each component has unique abilities to bring to bear on a given task. The human component is more suited to engaging in tasks that require creativity, such as raising the “important questions,” posing the “original problems,” or making the “critical decisions.” Computers, on the other hand, excel at performing such functions as rapid and accurate data storage and retrieval, as well as rapid aggregate analysis, calculation, and plotting of retrieved data. Human operators and computer systems could thus have a symbiotic relationship in which they augment each other's capabilities in performing complex, multifaceted tasks.

Throughout the 1960s and early 1970s, human factors researchers paid more attention to mapping out the information-processing and decision-making skills of the typical user than to engineering a symbiotic association between operators and specific systems. It was not until well into the 1970s that technological advances made real-time interaction commonplace and with it made Licklider's idea of symbiosis feasible. As a result, the late 1970s and early 1980s saw a deeper interest in the now-blossoming field of cognitive psychology and adapting its findings to the design of user interface strategies. Of particular interest was the focus on interaction with databases.

We also began to see the emergence of theoretical constructs of the interaction between users and computers. These included the keystroke-level and GOMS models of Card, et al. The GOMS model is specified by four components: a set of goals, a set of operators, a set of goal-achieving methods, and a set of selection rules to choose among methods. Another theoretical construct was the levels of interactions model, with its four interaction levels of conceptual, semantic, syntactic, and lexical, initially proposed by Foley and Wallace and expanded by Foley and Van Dam.

Focus on the User Interface

In the late 1970s and early 1980s, a flurry of psychological research, mostly carried out in industrial research laboratories, dealt with the user interface was during those years that the field of HCI was officially “born.” For the first time, books with the words “human computer interaction” in their titles were published The Association for Computing Machinery (ACM) Special Interest Group in Computer Human Interaction was established, and in 1982 the first conference on Human Factors in Computing Systems, which became the annual CHI conference, was held.

Along with the explosion in popular and personal computing in the 1980s, there arose a parallel emphasis on usability issues: how to make software and computer systems easy to learn and use. Until the mid-1980s the interface was embedded in application software. There were, however, some graphic utilities, and the interface began to emerge as a separate component. The introduction of the Xerox Star began a new generation of interfaces using the desktop as metaphor. These interfaces displayed high-quality graphics and used the point-and-click mouse to invoke actions and manipulate screen objects. Thus emerged the GUI interface, which was popularized with Apple's computers: first Lisa, then the Macintosh.

As the GUI interface evolved, the new discipline of Human Computer Interaction matured. Key HCI principles of User-Centered Design and Direct Manipulation emerged. We saw the first textbook—Designing the User Interface: Strategies for Effective Human-Computer Interaction by B. Shneiderman—and the first influential HCI design idea book—The Psychology of Everyday Things by D. A. Norman. This was followed in the 1990s by several textbooks and the introduction of the ACM HCI Curriculum.

User Interface Software

Other researchers during the 1980s worked to develop tools and methods for user interface design. This research arose from the belated recognition by computer scientists that the user interface is as vital a component of computing systems as an operating system or database. Those scientists and engineers were primarily concerned with inventing tools and systems of tools that help create interfaces, such as User Interface Management Systems (UIMS) and User Interface Design Environments (UIDE).

Usability

In parallel with the research and academic evolution of HCI, the software industry focused on designing user-compatible interfaces and making software systems increasingly more usable. Starting in the mid-1980s and gaining strength in the 1990s, the interface development community employed usability engineering methods to design and test software systems for ease of use, ease of learning, memorability, lack of errors, and satisfaction.

It was no longer enough for a designer to be sensitive to usability concerns or to adopt an intangible user-centered perspective. Designers must also set objective, measurable, operational usability goals. An operational definition of usability, in turn, must include some identifiable and measurable concept of effort. For example, the effort to complete a task may be measured in terms of both the time it takes a user to perform a task successfully and the number of observable actions taken in the process.

Usability practitioners of the 1990s considered two factors as measures of usability.

· Ease of Learning: We can measure usability by comparing the time it takes users to learn to do a job when working with an unfamiliar computer system to the time it takes them to learn to do the same job some other way. As measured by time, it takes the user more effort to learn a system that does not incorporate and build on the user's existing habits. The users will have to ignore what they already know about the job to develop a new collection of habits.

· Ease of Use: The minimum number of actions required to complete a task successfully becomes an increasingly important measure of usability for more experienced operators. For example, the number of mouse clicks entered per procedure is a good way to compare the ease of use of two designs. Other factors being equal, the design that requires fewer keystrokes per procedure will be more usable.

Focusing on the Web

At the same time that usability practitioners were becoming pervasive in the software development industry, the World Wide Web was becoming a force in information sharing and a popular medium for business advertising and transactions. Web usability became a particular focus of the HCI community during the late 1990s. This interest was heightened by the fact that Web developers were poorly designing corporate Web sites. The developer's training was limited to Web authoring tools and languages, which can be learned in a relatively short period of time. These early developers were not sensitized to the usability issues that had become an integral part of the software development culture. As the evolution in technology made it possible for “new media” style Web sites to be developed with graphics and animation, the number of usability problems increased, with a correspondingly greater negative impact on business revenues and customer retention.

· Visibility of system status

The system should always keep users informed about what is going on, through appropriate feedback within reasonable time.

· Match between system and the real world

The system should speak the users' language, with words, phrases, and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order.

· User control and freedom

Users often choose system functions by mistake and will need a clearly marked emergency exit to leave the unwanted state without having to go through an extended dialog. Support undo and redo.

· Consistency and standards

Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions.

· Error prevention

Even better than good error messages is a careful design that prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action.

· Recognition rather than recall

Minimize the user's memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the dialog to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate.

· Flexibility and efficiency of use

Accelerators – unseen by the novice user – may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions.

· Aesthetic and minimalist design

Dialogues should not contain information that is irrelevant or rarely needed. Every extra unit of information in a dialog competes with the relevant units of information and diminishes their relative visibility.

· Help users recognize, diagnose, and recover from errors

Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution.

· Help and documentation

Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user's task, list concrete steps to be carried out, and not be too large.

These heuristics are intended to be used by judging them against aspects of the interface. For example, if a new social networking system is being evaluated, the evaluator might consider how a user would find out how to add friends to her network. The evaluator is meant to go through the interface several times inspecting the various interaction elements and comparing them with the list of usability principles, i.e. the heuristics. At each iteration, usability problems will be identified or their diagnosis will be refined, until she is satisfied that the majority of them are clear.

Although many heuristics apply to most products (e.g. be consistent and provide meaningful feedback), some of the core heuristics are too general for evaluating products that have come onto the market since Nielsen and Mohlich first developed the method, such as mobile devices, digital toys, online communities, ambient devices, and new web services. Nielsen (2010) suggests developing category-specific heuristics that apply to a specific class of product as a supplement to the general heuristics. Evaluators and researchers have therefore typically developed their own heuristics by tailoring Nielsen's heuristics with other design guidelines, market research, and requirements documents. Exactly which heuristics are appropriate and how many are needed for different products is debatable and depends on the goals of the evaluation, but most sets of heuristics have between five and ten items. This number provides a good range of usability criteria by which to judge the various aspects of an interface. More than ten becomes difficult for evaluators to remember; fewer than five tends not to be sufficiently discriminating.

A key question that is frequently asked is how many evaluators are needed to carry out a thorough heuristic evaluation? While one evaluator can identify a large number of problems, she may not catch all of them. She may also have a tendency to concentrate more on one aspect at the expense of missing others. For example, in a study of heuristic evaluation where 19 evaluators were asked to find 16 usability problems in a voice response system allowing customers access to their bank accounts, Nielsen (1992) found a substantial difference between the number and type of usability problems found by the different evaluators. He also notes that while some usability problems are very easy to find by all evaluators, there are some problems that are found by very few experts. Therefore, he argues that it is important to involve multiple evaluators in any heuristic evaluation and recommends between three and five evaluators. His findings suggest that they can typically identify around 75% of the total usability problems, as shown in Figure 15.1 (Nielsen, 1994a).

However, employing multiple experts can be costly. Skillful experts can capture many of the usability problems by themselves and some consultancies now use this technique as the basis for critiquing interactive devices – a process that has become known as an expert critique or expert crit in some countries. But using only one or two experts to conduct a heuristic evaluation can be problematic since research has challenged Nielsen's findings and questioned whether even three to five evaluators is adequate. For example, Cockton and Woolrych (2001) and Woolrych and Cockton (2001) point out that the number of experts needed to find 75% of problems depends on the nature of the problems. Their analysis of problem frequency and severity suggests that highly misleading findings can result.

Figure 15.1 Curve showing the proportion of usability problems in an interface found by heuristic evaluation using various numbers of evaluators. The curve represents the average of six case studies of heuristic evaluation

The conclusion from this is that more is better, but more is expensive. However, because users and special facilities are not needed for heuristic evaluation and it is comparatively inexpensive and quick, it is popular with developers and is often known as discount evaluation. For a quick evaluation of an early design, one or two experts can probably identify most potential usability problems but if a thorough evaluation of a fully working prototype is needed then having a team of experts conducting the evaluation and comparing their findings would be advisable.

Heuristic Evaluation for Websites

As more attention focuses on the web, heuristics for evaluating websites have become increasingly important. Several slightly different sets of heuristics exist. Box 15.1 contains an extract from a version compiled by web developer Andy Budd that places a stronger emphasis on information content than Nielsen's heuristics.

BOX 15.1

Extract from the heuristics developed by Budd (2007) that emphasize web design issues

Clarity

Make the system as clear, concise, and meaningful as possible for the intended audience.

· Write clear, concise copy

· Only use technical language for a technical audience

· Write clear and meaningful labels

· Use meaningful icons.

Minimize unnecessary complexity and cognitive load

Make the system as simple as possible for users to accomplish their tasks.

· Remove unnecessary functionality, process steps, and visual clutter

· Use progressive disclosure to hide advanced features

· Break down complicated processes into multiple steps

· Prioritize using size, shape, color, alignment, and proximity.

Provide users with context

Interfaces should provide users with a sense of context in time and space.

· Provide a clear site name and purpose

· Highlight the current section in the navigation

· Provide a breadcrumb trail

· Use appropriate feedback messages

· Show number of steps in a process

· Reduce perception of latency by providing visual cues (e.g. progress indicator) or by allowing users to complete other tasks while waiting.

Promote a pleasurable and positive user experience

The user should be treated with respect and the design should be aesthetically pleasing and promote a pleasurable and rewarding experience.

· Create a pleasurable and attractive design

· Provide easily attainable goals

· Provide rewards for usage and progression.

ACTIVITY 15.1

1. Select a website that you regularly visit and evaluate it using the heuristics in Box 15.1. Do these heuristics help you to identify important usability and user experience issues?

2. Does being aware of the heuristics influence how you interact with the website in any way?

Comment

1. The heuristics focus on key usability criteria such as whether the interface seemed unnecessarily complex and how color was used. Budd's heuristics also encourage consideration of how the user feels about the experience of interacting with the website.

2. Being aware of the heuristics leads to a stronger focus on the design and the interaction, and raises awareness of what the user is trying to do and how the website is responding.

Turning Design Guidelines into Heuristics

There is a strong relationship between design guidelines and the heuristics used in heuristic evaluation. As a first step to developing new heuristics, evaluators sometimes translate design guidelines into questions for use in heuristic evaluation. This practice has become quite widespread for addressing usability and user experience concerns for specific types of interactive product. For example Väänänen-Vainio-Mattila and Waljas (2009) from the University of Tempere in Finland took this approach when developing heuristics for web service user experience. They tried to identify, what they called ‘hedonic heuristics,’ which is a new kind of heuristic that directly addresses how users feel about their interactions. These were based on design guidelines concerning whether the user feels that the web service provides a lively place where it is enjoyable to spend time, and whether it satisfies the user's curiosity by frequently offering interesting content. When stated as questions these become: Is the service a lively place where it is enjoyable to spend time? Does the service satisfy users' curiosity by frequently offering interesting content?

ACTIVITY 15.2

Consider the following design guidelines for information design and for each one suggest a question that could be used in heuristic evaluation:

1. Good graphical design is important. Reading long sentences, paragraphs, and documents is difficult on screen, so break material into discrete, meaningful chunks to give the website structure (Horton, 2005).

2. Avoid excessive use of color. Color is useful for indicating different kinds of information, i.e. cueing (Koyani et al, 2004).

3. Avoid gratuitous use of graphics and animation. In addition to increasing download time, graphics and animation soon become boring and annoying.

Comment

We suggest the following questions; you may have identified others:

1. Good graphical design is important. Is the page layout structured meaningfully? Is there too much text on each page?

2. Avoid excessive use of color. How is color used? Is it used as a form of coding? Is it used to make the site bright and cheerful? Is it excessive and garish? Does it have an impact on the user's enjoyment (i.e., user's experience)?

3. Avoid gratuitous use of graphics and animation. Are there any flashing banners? Are there complex introduction sequences? Can they be short-circuited? Do the graphics add to the site and improve the user's experience?

Another important issue when designing and evaluating web pages and other types of system is their accessibility to a broad range of users, as mentioned in Chapter 1 and throughout this book. In the USA, a requirement known as Section 508 of the Rehabilitation Act came into effect in 2001. The act requires that all federally funded IT systems be accessible for people with disabilities. The guidelines provided by this Act can be used as heuristics to check that systems comply with it (see Case Study 14.1). Mankoff et al (2005) also used guidelines as heuristics to evaluate specific kinds of usability. They discovered that developers doing a heuristic evaluation using a screen reader found 50% of known usability problems – which was more successful than user testing directly with blind users.

Figure 15.2 A screen showing MoFax on a cell phone

Heuristic evaluation has been used for evaluating mobile technologies (Brewster and Dunlop, 2004). An example is provided by Wright et al (2005) who evaluated a mobile fax application, known as MoFax. MoFax users can send and receive faxes to conventional fax machines or to other MoFax users. This application was created to support groups working with construction industry representatives who often send faxes of plans to each other. Using MoFax enables team members to browse and send faxes on their cell phones while out in the field (see Figure 15.2). At the time of the usability evaluation, the developers knew there were some significant problems with the interface, so they carried out a heuristic evaluation using Nielsen's heuristics to learn more. Three expert evaluators performed the evaluation and together they identified 56 problems. Based on these results, the developers redesigned MoFax.

Heuristic evaluation has also been used to evaluate abstract aesthetic peripheral displays that portray non-critical information at the periphery of the user's attention (Mankoff et al, 2003). Since these devices are not designed for task performance, the researchers had to develop a set of heuristics that took this into account. They did this by developing two ambient displays: one indicated how close a bus is to the bus-stop by showing its number move upwards on a screen; the other indicated how light or dark it was outside by lightening or darkening a light display (see Figure 15.3). Then they modified Nielsen's heuristics to address the characteristics of ambient displays and asked groups of experts to evaluate the displays using them.

Figure 15.3 Two ambient devices: (a) bus indicator, (b) lightness and darkness indicator

The heuristics that they developed included some that were specifically geared towards ambient systems such as:

· Visibility of state: The state of the display should be clear when it is placed in the intended setting.

· Peripherality of display: The display should be unobtrusive and remain so unless it requires the user's attention. Users should be able to easily monitor the display.

In this study the researchers found that three to five evaluators were able to identify 40–60% of known usability issues. In a follow-up study, different researchers used the same heuristics with different ambient applications (Consolvo and Towle, 2005). They found 75% of known usability problems with eight evaluators and 35–55% were found with three to five evaluators, suggesting that the more evaluators you have, the more accurate the results will be – as other researchers have also reported.

The drive to develop heuristics for other products continues and includes video games (Pinelle et al, 2008), online communities (Preece and Shneiderman, 2009), and information visualization (Forsell and Johansson, 2010).

Doing Heuristic Evaluation

Heuristic evaluation has three stages:

1. The briefing session, in which the experts are told what to do. A prepared script is useful as a guide and to ensure each person receives the same briefing.

2. The evaluation period, in which each expert typically spends 1–2 hours independently inspecting the product, using the heuristics for guidance. The experts need to take at least two passes through the interface. The first pass gives a feel for the flow of the interaction and the product's scope. The second pass allows the evaluator to focus on specific interface elements in the context of the whole product, and to identify potential usability problems.

If the evaluation is for a functioning product, the evaluators need to have some specific user tasks in mind so that exploration is focused. Suggesting tasks may be helpful but many experts suggest their own tasks. However, this approach is less easy if the evaluation is done early in design when there are only screen mockups or a specification; the approach needs to be adapted to the evaluation circumstances. While working through the interface, specification, or mockups, a second person may record the problems identified, or the evaluator may think aloud. Alternatively, she may take notes herself. Evaluators should be encouraged to be as specific as possible and to record each problem clearly.

3. The debriefing session, in which the evaluators come together to discuss their findings and to prioritize the problems they found and suggest solutions.

The heuristics focus the evaluators' attention on particular issues, so selecting appropriate heuristics is critically important. Even so, there is sometimes less agreement among evaluators than is desirable, as discussed in the Dilemma below.

There are fewer practical and ethical issues in heuristic evaluation than for other methods because users are not involved. A week is often cited as the time needed to train evaluators (Nielsen and Mack, 1994), but this depends on the person's initial expertise. Typical users can be taught to do heuristic evaluation, although there have been claims that this approach is not very successful (Nielsen, 1994a). A variation of this method is to take a team approach that may involve users.

ACTIVITY 15.3

Look at the Nielsen (2010) heuristics and consider how you would use them to evaluate a website for purchasing clothes (e.g. www.REI.com, which has a homepage similar to that in Figure 15.4).

1. Do the heuristics help you focus on the web site more intently than if you were not using them?

2. Might fewer heuristics be better? Which might be combined and what are the trade-offs?

Figure 15.4 Homepage of REI.com

Comment

1. Most people find that using the heuristics encourages them to focus on the design more than when they are not using them.

2. Some heuristics can be combined and given a more general description. For example, ‘the system should speak the user’s language’ and ‘always keep users informed’ could be replaced with ‘help users to develop a good mental model,’ but this is a more abstract statement and some evaluators might not know what is packed into it.

An argument for keeping the detail is that it reminds evaluators of the issues to consider.

DILEMMA

Classic problems or false alarms?

You might have the impression that heuristic evaluation is a panacea for designers, and that it can reveal all that is wrong with a design. However, it has problems. Shortly after heuristic evaluation was developed, several independent studies compared heuristic evaluation with other methods, particularly user testing. They found that the different approaches often identify different problems and that sometimes heuristic evaluation misses severe problems (Karat, 1994). This argues for using complementary methods. Furthermore, heuristic evaluation should not be thought of as a replacement for user testing.

Another problem concerns experts reporting problems that don't exist. In other words, some of the experts' predictions are wrong (Bailey, 2001). Bailey cites analyses from three published sources showing that only around 33% of the problems reported were real usability problems, some of which were serious, others trivial. However, the heuristic evaluators missed about 21% of users' problems. Furthermore, about 43% of the problems identified by the experts were not problems at all; they were false alarms! Bailey points out that this means only about half the problems identified are true problems: “More specifically, for every true usability problem identified, there will be a little over one false alarm (1.2) and about one half of one missed problem (0.6). If this analysis is true, heuristic evaluators tend to identify more false alarms and miss more problems than they have true hits.”

How can the number of false alarms or missed serious problems be reduced? Checking that experts really have the expertise that they claim would help, but how can this be done? One way to overcome these problems is to have several evaluators. This helps to reduce the impact of one person's experience or poor performance. Using heuristic evaluation along with user testing and other methods is also a good idea.

15.2.2 Walkthroughs

Walkthroughs are an alternative approach to heuristic evaluation for predicting users' problems without doing user testing. As the name suggests, they involve walking through a task with the product and noting problematic usability features. Most walkthrough methods do not involve users. Others, such as pluralistic walkthroughs, involve a team that includes users, developers, and usability specialists.

In this section we consider cognitive and pluralistic walkthroughs. Both were originally developed for desktop systems but, as with heuristic evaluation, they can be adapted to web-based systems, handheld devices, and products such as DVD players.

Cognitive Walkthroughs

“Cognitive walkthroughs involve simulating a user's problem-solving process at each step in the human–computer dialog, checking to see if the user's goals and memory for actions can be assumed to lead to the next correct action” (Nielsen and Mack, 1994, p. 6). The defining feature is that they focus on evaluating designs for ease of learning – a focus that is motivated by observations that users learn by exploration (Wharton et al, 1994). The steps involved in cognitive walkthroughs are:

1. The characteristics of typical users are identified and documented and sample tasks are developed that focus on the aspects of the design to be evaluated. A description or prototype of the interface to be developed is also produced, along with a clear sequence of the actions needed for the users to complete the task.

2. A designer and one or more expert evaluators come together to do the analysis.

3. The evaluators walk through the action sequences for each task, placing it within the context of a typical scenario, and as they do this they try to answer the following questions:

· Will the correct action be sufficiently evident to the user? (Will the user know what to do to achieve the task?)

· Will the user notice that the correct action is available? (Can users see the button or menu item that they should use for the next action? Is it apparent when it is needed?)

· Will the user associate and interpret the response from the action correctly? (Will users know from the feedback that they have made a correct or incorrect choice of action?)

In other words: will users know what to do, see how to do it, and understand from feedback whether the action was correct or not?

4. As the walkthrough is being done, a record of critical information is compiled in which:

· The assumptions about what would cause problems and why are identified.

· Notes about side issues and design changes are made.

· A summary of the results is compiled.

5. The design is then revised to fix the problems presented.

As with heuristic and other evaluation methods, developers and researchers sometimes modify the method to meet their own needs more closely. One example of this is provided by a company called Userfocus (www.userfocus.com) that uses the following four questions, rather than those listed in point 3 above, as they are more suitable for evaluating physical devices such as TV remote controllers:

· Will the customer realistically be trying to do this action. (This question does not presume that users will actually carry out certain actions.)

· Is the control for the action visible?

· Is there a strong link between the control and the action?

· Is feedback appropriate?

When doing a cognitive walkthrough it is important to document the process, keeping account of what works and what doesn't. A standardized feedback form can be used in which answers are recorded to each question. Any negative answers are carefully documented on a separate form, along with details of the system, its version number, the date of the evaluation, and the evaluators' names. It is also useful to document the severity of the problems: for example, how likely a problem is to occur and how serious it will be for users. The form can also record the process details outlined in points 1 to 4 as well as the date of the evaluation.

Compared with heuristic evaluation, this technique focuses more closely on identifying specific user problems at a high level of detail. Hence, it has a narrow focus that is useful for certain types of system but not others. In particular, it can be useful for applications involving complex operations. However, it is very time-consuming and laborious to do and evaluators need a good understanding of the cognitive processes involved.

The following example shows a cognitive walkthrough of buying this book at www.Amazon.com.

· Task: to buy a copy of this book from www.Amazon.com

· Typical users: students who use the web regularly

The steps to complete the task are given below. Note that the interface for www.Amazon.com may have changed since we did our evaluation.

Step 1. Selecting the correct category of goods on the homepage Q: Will users know what to do? Answer: Yes, they know that they must find books.

Q: Will users see how to do it? Answer: Yes, they have seen menus before and will know to select the appropriate item and to click ‘go.’

Q: Will users understand from feedback whether the action was correct or not? Answer: Yes, their action takes them to a form that they need to complete to search for the book.

Step 2. Completing the form Q: Will users know what to do? Answer: Yes, the online form is like a paper form so they know they have to complete it. Answer: No, they may not realize that the form has defaults to prevent inappropriate answers because this is different from a paper form.

Q: Will users see how to do it? Answer: Yes, it is clear where the information goes and there is a button to tell the system to search for the book.

Q: Will users understand from the feedback whether the action was correct or not? Answer: Yes, they are taken to a picture of the book, a description, and purchase details.

ACTIVITY 15.4

Activity 15.3 asked you to do a heuristic evaluation of www.REI.com or a similar online retail site. Now go back to that site and do a cognitive walkthrough to buy something, say a pair of skis. When you have completed the evaluation, compare your findings from the cognitive walkthrough with those from heuristic evaluation.

Comment

The cognitive walkthrough probably took longer than the heuristic evaluation for evaluating the same part of the site because it examines each step of a task. Consequently, you probably did not see as much of the website. It is also likely that the cognitive walkthrough resulted in more detailed findings. Cognitive walkthrough is a useful method for examining a small part of a system in detail, whereas heuristic evaluation is useful for examining a whole system or large parts of systems. As the name indicates, the cognitive walkthrough focuses on the cognitive aspects of interacting with the system. It was developed before there was much emphasis on aesthetic design and other user experience goals.

Another variation of cognitive walkthrough was developed by Rick Spencer of Microsoft, to overcome some problems that he encountered when using the original form of cognitive walkthrough (Spencer, 2000). The first problem was that answering the three questions in step 3 and discussing the answers took too long. Second, designers tended to be defensive, often invoking long explanations of cognitive theory to justify their designs. This second problem was particularly difficult because it undermined the efficacy of the method and the social relationships of team members. In order to cope with these problems, Rick Spencer adapted the method by reducing the number of questions and curtailing discussion. This meant that the analysis was more coarse-grained but could be completed in about 2.5 hours. He also identified a leader, the usability specialist, and set strong ground rules for the session, including a ban on defending a design, debating cognitive theory, or doing designs on the fly.

These adaptations made the method more usable, despite losing some of the detail from the analysis. Perhaps most important of all, Spencer directed the social interactions of the design team so that they achieved their goals.

Pluralistic Walkthroughs

“Pluralistic walkthroughs are another type of walkthrough in which users, developers and usability experts work together to step through a [task] scenario, discussing usability issues associated with dialog elements involved in the scenario steps” (Nielsen and Mack, 1994, p. 5). In a pluralistic walkthrough, each of the evaluators is asked to assume the role of a typical user. Scenarios of use, consisting of a few prototype screens, are given to each evaluator who writes down the sequence of actions they would take to move from one screen to another, without conferring with fellow panelists. Then the panelists discuss the actions they each suggested before moving on to the next round of screens. This process continues until all the scenarios have been evaluated (Bias, 1994).

The benefits of pluralistic walkthroughs include a strong focus on users' tasks at a detailed level, i.e. looking at the steps taken. This level of analysis can be invaluable for certain kinds of systems, such as safety-critical ones, where a usability problem identified for a single step could be critical to its safety or efficiency. The approach lends itself well to participatory design practices by involving a multidisciplinary team in which users play a key role. Furthermore, the group brings a variety of expertise and opinions for interpreting each stage of an interaction. Limitations include having to get all the experts together at once and then proceed at the rate of the slowest. Furthermore, only a limited number of scenarios, and hence paths through the interface, can usually be explored because of time constraints.

Types of User Interfaces

6.1 Introduction

Until the mid-1990s, interaction designers concerned themselves largely with developing efficient and effective user interfaces for desktop computers aimed at the single user. This involved working out how best to present information on a screen such that users would be able to perform their tasks, including determining how to structure menus to make options easy to navigate, designing icons and other graphical elements to be easily recognized and distinguished from one another, and developing logical dialog boxes that are easy to fill in. Advances in graphical interfaces, speech, gesture and handwriting recognition, together with the arrival of the Internet, cell phones, wireless networks, sensor technologies, and an assortment of other new technologies providing large and small displays, have changed the face of human–computer interaction. During the last decade designers have had many more opportunities for designing user experiences. The range of technological developments has encouraged different ways of thinking about interaction design and an expansion of research in the field. For example, innovative ways of controlling and interacting with digital information have been developed that include gesture-based, touch-based, and even brain–computer interaction. Researchers and developers have combined the physical and digital in novel ways, resulting in mixed realities, augmented realities, tangible interfaces, and wearable computing. A major thrust has been to design new interfaces that extend beyond the individual user: supporting small- and large-scale social interactions for people on the move, at home, and at work.

There is now a diversity of interfaces. The goal of this chapter is to consider how to design interfaces for different environments, people, places, and activities. We present a catalog of 20 interface types, starting with command-based and ending with brain–computer. For each one, we present an overview and outline the key research and design concerns. Some are only briefly touched upon while others – that are more established in interaction design – are described in more depth. It should be stressed that the chapter is not meant to be read from beginning to end but dipped into to find out about a particular type of interface.

6.2 Interface Types

Numerous adjectives have been used to describe the different kinds of interfaces that have been developed, including graphical, command, speech, multimodal, invisible, ambient, mobile, intelligent, adaptive, tangible, touchless, and natural. Some of the interface types are primarily concerned with a function (e.g. to be intelligent, to be adaptive, to be ambient), while others focus on the interaction style used (e.g. command, graphical, multimedia), the input/output device used (e.g. pen-based, speech-based), or the platform being designed for (e.g. PC, mobile, tabletop). The interface types are loosely ordered in terms of when they were developed. They are numbered to make it easier to find a particular one (see Table 6.1 for complete set). It should be noted, however, that this classification is for convenience. The interface entries are not mutually exclusive since some products can appear in two categories. For example, a smartphone can be considered to be either mobile or touch. Table 6.1 suggests which interfaces are related or have design issues in common.

Interface type	See also
1. Command-based
2. WIMP and GUI
3. Multimedia	WIMP and web
4. Virtual reality	Augmented and mixed reality
5. Information visualization	Multimedia
6. Web	Mobile and multimedia
7. Consumer electronics and appliances	Mobile
8. Mobile	Augmented and mixed reality
9. Speech
10. Pen	Shareable, touch
11. Touch	Shareable, air-based gesture
12. Air-based gesture	Tangible
13. Haptic	Multimodal
14. Multimodal	Speech, pen, touch, gesture, and haptic
15. Shareable	Touch
16. Tangible
17. Augmented and mixed reality	Virtual reality
18. Wearable
19. Robotic
20. Brain-computer

Table 6.1 The types of interfaces covered in this chapter

6.2.1 Command-Based

Early interfaces required the user to type in commands that were typically abbreviations (e.g. ls) at the prompt symbol appearing on the computer display, which the system responded to (e.g. by listing current files using a keyboard). Another way of issuing commands is through pressing certain combinations of keys (e.g. Shift+Alt+Ctrl). Some commands are also a fixed part of the keyboard, such as delete, enter, and undo, while other function keys can be programmed by the user as specific commands (e.g. F11 standing for print).

BOX 6.1

Command-based interfaces for virtual worlds

virtual worlds such as Second Life have become popular places for learning and socializing. Unfortunately people who are visually impaired cannot join in. A command-based interface, called TextSL, was developed to enable them to participate by using a screen reader (Folmer et al, 2009). Commands can be issued to enable the user to move their avatar around, interact with others, and find out about the environment they are in. Figure 6.1 shows that the user has issued the command for their avatar to smile and say hello to other avatars sitting by a log fire.

Figure 6.1 Second Life command-based interface for visually impaired users

Command-line interfaces have been largely superseded by graphical interfaces that incorporate commands such as menus, icons, keyboard shortcuts, and pop-up/predictable text commands as part of an application. Where command line interfaces continue to have an advantage is when users find them easier and faster to use than equivalent menu-based systems (Raskin, 2000) and for performing certain operations as part of a complex software package, such as for CAD environments, (e.g. Rhinoceros 3D and AutoCAD), to enable expert designers to be able to interact rapidly and precisely with the software. They also provide scripting for batch operations and are being increasingly used on the web, where the search bar acts as a general-purpose command line facility, e.g. www.yubnub.org. Many programmers prefer managing their files at the DOS/UNIX shell level of an operating system, while using command line text editors, like vi, when coding and debugging. They have also been developed for visually impaired people to enable them to interact in virtual worlds, such as Second Life (see Box 6.1).

Research and design issues

In the 1980s, much research investigated ways of optimizing command-based interfaces. The form of the commands (e.g. use of abbreviations, full names, familiar names), syntax (e.g. how best to combine different commands), and organization (e.g. how to structure options) are examples of some of the main areas that have been investigated (Shneiderman, 1998). A further concern was which names to use as commands that would be the easiest to remember. A number of variables were tested, including how familiar users were with the chosen names. Findings from a number of studies, however, were inconclusive; some found specific names were better remembered than general ones (Barnard et al, 1982), others showed names selected by users themselves were preferable (e.g. Ledgard et al, 1981; Scapin, 1981), while yet others demonstrated that high-frequency words were better remembered than low-frequency ones (Gunther et al, 1986).

The most relevant design principle is consistency (see Chapter 1). The method used for labeling/naming the commands should be chosen to be as consistent as possible, e.g. always use first letters of operation when using abbreviations.

6.2.2 WIMP and GUI

The Xerox Star interface (described in Chapter 2) led to the birth of the WIMP and subsequently the GUI, opening up new possibilities for users to interact with a system and for information to be presented and represented at the interface. Specifically, new ways of visually designing the interface became possible, that included the use of color, typography, and imagery (Mullet and Sano, 1995). The original WIMP comprises:

· Windows (that could be scrolled, stretched, overlapped, opened, closed, and moved around the screen using the mouse).

· Icons (to represent applications, objects, commands, and tools that were opened or activated when clicked on).

· Menus (offering lists of options that could be scrolled through and selected in the way a menu is used in a restaurant).

· Pointing device (a mouse controlling the cursor as a point of entry to the windows, menus, and icons on the screen).

The first generation of WIMP interfaces was primarily boxy in design; user interaction took place through a combination of windows, scroll bars, checkboxes, panels, palettes, and dialog boxes that appeared on the screen in various forms (see Figure 6.2). Application programmers were largely constrained by the set of widgets available to them, of which the dialog box was most prominent. (A widget is a standardized display representation of a control, like a button or scroll bar, that can be manipulated by the user.)

The basic building blocks of the WIMP are still part of the modern GUI, but have evolved into a number of different forms and types. For example, there are now many different types of icons and menus, including audio icons and audio menus, 3D animated icons, and 2D icon-based menus. Windows have also greatly expanded in terms of how they are used and what they are used for; for example, a variety of dialog boxes, interactive forms, and feedback/error message boxes have become pervasive. In addition, a number of graphical elements that were not part of the WIMP interface have been incorporated into the GUI. These include toolbars and docks (a row or column of available applications and icons of other objects such as open files) and rollovers (where text labels appear next to an icon or part of the screen as the mouse is rolled over it). Here, we give an overview of the design issues concerning the basic building blocks of the WIMP/GUI: windows, menus, and icons.

Figure 6.2 The boxy look of the first generation of GUIs. The window presents several check boxes, notes boxes, and options as square buttons

Window design. Windows were invented to overcome the physical constraints of a computer display, enabling more information to be viewed and tasks to be performed at the same screen. Multiple windows can be opened at any one time, e.g. web pages and word processor documents, enabling the user to switch between them, when needing to look or work on different documents, files, and applications. Scrolling bars within windows also enable more information to be viewed than is possible on one screen. Scrollbars can be placed vertically and horizontally in windows to enable upwards, downwards, and sideways movements through a document.

One of the disadvantages of having multiple windows open is that it can be difficult to find specific ones. Various techniques have been developed to help users locate a particular window, a common one being to provide a list as part of an application menu. Mac OS also provides a function that shrinks all windows that are open so they can be seen side by side on one screen. The user needs only to press one function key and then move the cursor over each one to see what they are called. This technique enables users to see at a glance what they have in their workspace and also enables them to easily select one to come to the forefront. Another option is to display all the windows open for a particular application, e.g. Word. The web browser, Safari, has an option of showing 12 shrunken web pages that you have recently visited (history) or most commonly visited (top sites) as a window pane that enables quick scanning (see Figure 6.3).

Figure 6.3 A window management technique provided in Safari: pressing the 4 × 3 icon in the top left corner of the bookmarks bar displays the 12 top sites visited, by shrinking them and placing them side by side. This enables the user to see them all at a glance and be able to rapidly switch between them

A particular kind of window that is commonly used in GUIs is the dialog box. Confirmations, error messages, checklists, and forms are presented through them. Information in the dialog boxes is often designed to guide user interaction, with the user following the sequence of options provided. Examples include a sequenced series of forms (i.e. Wizards) presenting the necessary and optional choices that need to be filled in when choosing a PowerPoint presentation or an Excel spreadsheet. The downside of this style of interaction is that there can be a tendency to cram too much information or data entry fields into one box, making the interface confusing, crowded, and difficult to read (Mullet and Sano, 1995).

BOX 6.2

The joys of filling in forms on the web

For many of us, shopping on the Internet is generally an enjoyable experience. For example, choosing a book on Amazon or flowers from Interflora can be done at our leisure and convenience. The part we don't enjoy, however, is filling in the online form to give the company the necessary details to pay for the selected items. This can often be a frustrating and time-consuming experience. It starts with having to create an account and a new password. Once past this hurdle, a new interactive form pops up for the delivery address and credit card details. The standard online form has a fixed format making it cumbersome and annoying to fill in, especially for people whose address does not fit within its constraints. Typically, boxes are provided (asterisked for where they must be filled in) for: address line 1 and address line 2, providing no extra lines for addresses that have more than two lines; a line for the town/city; and a line for the zip code (if the site is based in the USA) or other postal code (if based in another country). The format for the codes is different, making it difficult for non-US residents (and US residents for other country sites) to fill in this part. Further boxes are provided for home, work, and cell phone number, fax number, and email address (is it really necessary to provide all of these?) and credit card type, name of the owner, and credit card number.

Figure 6.4 A scrolling menu

One of the biggest gripes about online registration forms is the country of residence box that opens up as a never-ending menu, listing all of the countries in the world in alphabetical order. Instead of typing in the country they live in, users are forced to select the one they are from, which is fine if they happen to live in Australia or Austria but not if they live in Venezuela or Zambia. Some menus place the host site country first, but this can be easily overlooked if the user is primed to look for the letter of their country (see Figure 6.4).

This is an example of where the design principle of recognition over recall (see Chapter 3) does not apply and where the converse is true. A better design might be to have a predictive text option, where users need only to type in the first two or so letters of the country they are from to cause a narrowed down list of choices to appear that they can then select from at the interface.

ACTIVITY 6.1

Go to the Interflora site (interflora. co.uk) and click on the international delivery option at the top of the homepage. How are the countries ordered? Is it an improvement to the scrolling pop-up menu?

Figure 6.5 An excerpt of the listing of countries in alphabetical order from interfl ora.co.uk

Comment

Earlier versions such as shown in Figure 6.4 listed eight countries at the top starting with the United Kingdom, then the USA, France, Germany, Italy, Switzerland, Austria, and Spain. This was followed by the remaining set of countries listed in alphabetical order. The reason for having this particular ordering is likely to have been because the top eight are the countries who have most customers, with the UK residents using the service the most. More recently, the website had changed to using a table format grouping all the countries in alphabetical order using four columns across the page (see Figure 6.5). Do you think this is an improvement? It took me about 8 seconds to select Ireland, having overshot the target the first time I scrolled through, and 4 seconds to scroll through the more recent table using the web browser scrollbar. The use of letter headings and shading also make searching quicker.

Research and design issues

A key research concern is window management – finding ways of enabling users to move fluidly between different windows (and monitors) and to be able to rapidly switch their attention between them to find the information they need or to work on the document/task within each of them – without getting distracted. Studies of how people use windows and multiple monitors have shown that window activation time (i.e. the time a window is open and interacted with) is relatively short, an average of 20 seconds, suggesting that people switch frequently between different documents and applications (Hutchings et al, 2004). Widgets like the taskbar in the Windows environment are used as the main method of switching between windows.

To increase the legibility and ease of use of information presented in windows, the design principles of spacing, grouping, and simplicity should be used (discussed in Chapter 3). An early overview of window interfaces – that is still highly relevant today – is Myers's taxonomy of window manager interfaces (Myers, 1988).

Menu design. Just like restaurant menus, interface menus offer users a structured way of choosing from the available set of options. Headings are used as part of the menu to make it easier for the user to scan through them and find what they want. Figure 6.6 presents two different styles of restaurant menu, designed to appeal to different cultures: the American one is organized into a number of categories including starters (new beginnings), soups and salads (greener pastures), and sandwiches, while the Japanese burger menu is presented in three sequential categories: first the main meal, next the side order, and lastly the accompanying drink. The American menu uses enticing text to describe in more detail what each option entails, while the Japanese one uses a combination of appetizing photos and text.

Interface menu designs have employed similar methods of categorizing and illustrating options available that have been adapted to the medium of the GUI. A difference is that interface menus are typically ordered across the top row or down the side of a screen using category headers as part of a menu bar. The contents of the menus are also for the large part invisible, only dropping down when the header is selected or rolled over with a mouse. The various options under each menu are typically ordered from top to bottom in terms of most frequently used options and grouped in terms of their similarity with one another, e.g. all formatting commands are placed together.

There are numerous menu interface styles, including flat lists, drop-down, pop-up, contextual, and expanding ones, e.g. scrolling and cascading. Flat menus are good at displaying a small number of options at the same time or where the size of the display is small, e.g. cell phones, cameras, iPod. However, they often have to nest the lists of options within each other, requiring several steps to be taken by a user to get to the list with the desired option. Once deep down in a nested menu the user then has to take the same number of steps to get back to the top of the menu. Moving through previous screens can be tedious.

Figure 6.6 Two different ways of classifying menus designed for different cultures

Expanding menus enable more options to be shown on a single screen than is possible with a single flat menu list. This makes navigation more flexible, allowing for the selection of options to be done in the same window. However, as highlighted in Figure 6.4 it can be frustrating having to scroll through tens or even hundreds of options. To improve navigation through scrolling menus, a number of novel controls have been devised. For example, the original iPod provided a physical scrollpad that allows for clockwise and anti-clockwise movement, enabling long lists of tunes or artists to be rapidly scrolled through.

Figure 6.7 A cascading menu

The most common type of expanding menu used as part of the PC interface is the cascading one (see Figure 6.7), which provides secondary and even tertiary menus to appear alongside the primary active drop-down menu, enabling further related options to be selected, e.g. selecting track changes from the tools menu leads to a secondary menu of three options by which to track changes in a Word document. The downside of using expanding menus, however, is that they require precise mouse control. Users can often end up making errors, namely overshooting or selecting the wrong options. In particular, cascading menus require users to move their mouse over the menu item, while holding the mouse pad or button down, and then when the cascading menu appears on the screen to move their cursor over to the next menu list and select the desired option. Most of us (even expert GUI users) have experienced the frustration of under- or over-shooting a menu option that leads to the desired cascading menu and worse, losing it as we try to maneuver the mouse onto the secondary or tertiary menu. It is even worse for people who have poor motor control and find controlling a mouse difficult.

Contextual menus provide access to often-used commands associated with a particular item, e.g. an icon. They provide appropriate commands that make sense in the context of a current task. They appear when the user presses the Control key while clicking on an interface element. For example, clicking on a photo in a website together with holding down the Control key results in a small set of relevant menu options appearing in an overlapping window, such as open it in a new window, save it, or copy it. The advantage of contextual menus is that they provide a limited number of options associated with an interface element, overcoming some of the navigation problems associated with cascading and expanding menus.

Windows 7 jump lists are a hybrid form of contextual window and contextual menu that provide short-cuts to files, sites, etc., that are commonly visited. Depending on the program, such as a web browser or media player, it will show frequently viewed sites or commonly played tunes (see Figure 6.8).

Figure 6.8 Windows jump list

ACTIVITY 6.2

Open an application that you use frequently (e.g. word processor, email, web browser) and look at the menu header names (but do not open them just yet). For each one (e.g. File, Edit, Tools) write down what options you think are listed under each. Then look at the contents under each header. How many options were you able to remember and how many did you put in the wrong category? Now try to select the correct menu header for the following options (assuming they are included in the application): replace, save, spelling, and sort. Did you select the correct header each time or did you have to browse through a number of them?

Comment

Research and design issues

The choice of which type of menu to use will often be determined by the application and type of system. Which is best will depend on the number of options that are on offer and the size of the display to present them in. Flat menus are best for displaying a small number of options at one time, while expanding menus are good for showing a large number of options, such as those available in file and document creation/editing applications.

Icon design. The appearance of icons at the interface came about following the Xerox Star project. They were used to represent objects as part of the desktop metaphor, namely, folders, documents, trashcans, and in- and out-trays. An assumption behind using icons instead of text labels is that they are easier to learn and remember, especially for non-expert computer users. They can also be designed to be compact and variably positioned on a screen.

Icons have become a pervasive feature of the interface. They now populate every application and operating system, and are used for all manner of functions besides representing desktop objects. These include depicting tools (e.g. paintbrush), applications (e.g. web browser), and a diversity of abstract operations (e.g. cut, paste, next, accept, change). They have also gone through many changes in their look and feel: black and white, color, shadowing, photorealistic images, 3D rendering, and animation have all been used.

While there was a period from the late 1980s into the early 1990s when it was easy to find poorly designed icons at the interface (see Figure 6.9), icon design has now come of age. Interface icons look quite different; many have been designed to be very detailed and animated, making them both visually attractive and informative. The result is the design of GUIs that are highly inviting and emotionally appealing, and that feel alive. For example, Figure 6.10 contrasts the simple and jaggy Mac icon designs of the early 1990s with those that were developed as part of the Aqua range for the more recent operating environment Mac OS X. Whereas early icon designers were constrained by the graphical display technology of the day, they now have more flexibility. For example, the use of anti-aliasing techniques enables curves and non-rectilinear lines to be drawn, enabling more photo-illustrative styles to be developed (anti-aliasing means adding pixels around a jagged border of an object to visually smooth its outline).

Figure 6.9 Poor icon set from the early 1990s. What do you think they mean and why are they so bad?

Figure 6.10 Early and more recent Mac icon designs for the TextEdit application

Icons can be designed to represent objects and operations at the interface using concrete objects and/or abstract symbols. The mapping between the representation and underlying referent can be similar (e.g. a picture of a file to represent the object file), analogical (e.g. a picture of a pair of scissors to represent cut), or arbitrary (e.g. the use of an X to represent delete). The most effective icons are generally those that are isomorphic since they have direct mapping between what is being represented and how it is represented. Many operations at the interface, however, are of actions to be performed on objects, making it more difficult to represent them using direct mapping. Instead, an effective technique is to use a combination of objects and symbols that capture the salient part of an action through using analogy, association, or convention (Rogers, 1989). For example, using a picture of a pair of scissors to represent cut in a word processing application provides sufficient clues as long as the user understands the convention of cut for deleting text.

The greater flexibility offered by current GUI interfaces has enabled developers to create icon sets that are distinguishable, identifiable, and memorable. For example, different graphical genres have been used to group and identify different categories of icons. Figure 6.11 shows how colorful photo-realistic images have been used, each slanting slightly to the left, for the category of user applications (e.g. email) whereas monochrome straight on and simple images have been used for the class of utility applications (e.g. printer set-up). The former have a fun feel to them, whereas the latter have a more serious look about them.

Figure 6.11 Contrasting genres of Aqua icons used for the Mac. The top row of icons have been designed for user applications and the bottom row for utility applications

Another approach has been to develop glossy, logo-style icons that are very distinctive, using only primary colors and symbols, having the effect of making them easily recognizable, such as those developed by Microsoft Office to represent their different products (see Figure 6.12).

Icons that appear in toolbars or palettes as part of an application or presented on small device displays (e.g. cell phones and digital cameras) have much less screen estate available. Because of this, they are typically designed to be simple, emphasizing the outline form of an object or symbol and using only grayscale or one or two colors. They tend to convey the tool and action performed on them using a combination of concrete objects and abstract symbols, e.g. a blank piece of paper with a plus sign representing a new blank document, an open envelope with an arrow coming out of it indicating a new message has arrived. Again, the goal should be to design a palette or set of icons that are easy to recognize and distinguishable from one another.

Figure 6.12 Logo-based Microsoft Office Mac icons

ACTIVITY 6.3

Sketch simple icons to represent the following operations to appear on a digital camera LCD screen:

· Delete last picture taken.

· Delete all pictures stored.

· Format memory card.

Show them to your peers or friends, tell them that they are icons for a new digital camera intended to be really simple to use, and see if they can understand what each represents.

Comment

Figure 6.13 shows Toshiba's icons based on analogy and convention that are presented on the LCD display of the camera. The trashcan, which has become the conventional GUI icon to represent the command ‘to delete,’ has been used in combination with a representation of a single photo or a stack of photos, indicating what is deleted. The icon (to the left of them) uses a combination of an object and symbol: the image is of a memory card and the arrow conveys a complete circle. (The reason why one occasionally needs to format a memory card is to remove any residual memory files that can accumulate.) A key design issue is to make the three icons distinct from one another, especially the ‘delete last photo taken’ from the ‘delete all saved photos.’

Figure 6.13 Icons used by Toshiba for three of its digital camera operations

Research and design issues

Various books on how to design icons (e.g. Caplin, 2001; Horton, 1994) are now available together with sets of guidelines and style guides. There are also many icon builders and icon sets, e.g. ClipArt, providing a wealth of resources for designers, so that they do not have to draw or invent icons from scratch. Apple provides its developers with style guides, explaining why certain designs are preferable to others and how to design icon sets. On its developers' website (developer.apple.com), advice is given on how and why certain graphical elements should be used when developing different types of icon. Among the various guidelines, it suggests that different categories of application (e.g. user, utility) should be represented by a different genre and recommends displaying a tool to communicate the nature of a task, e.g. a magnifying glass for searching, a camera for a photo editing tool. Microsoft also provides extensive guidance and step-by-step procedures on how to design icons for its applications on its website. There are also numerous online tutorials and blogs that outline the dos and don'ts with many examples. For example, Denis Kortunov's (2008) blog called Secret's From the Chef has a great entry called 10 Mistakes in Icon Design.

To help disambiguate the meaning of icons, text labels can be used under, above, or to the side of their icons. This method is effective for toolbars that have small icon sets, e.g. those appearing as part of a web browser, but is not as good for applications that have large icon sets, e.g. photo editing or word processing, since the screen can get very cluttered and busy; making it sometimes harder and longer to find an icon. To prevent text/icon clutter at the interface, a rollover function can be used, where a text label appears adjacent to or above an icon, after one second of the user holding the cursor over it and for as long as the user keeps the cursor on it. This method allows identifying information to be temporarily displayed when needed.

6.2.3 Multimedia

Multimedia, as the name implies, combines different media within a single interface, namely, graphics, text, video, sound, and animations, and links them with various forms of interactivity. It differs from previous forms of combined media, e.g. TV, in that the different media are interactive (Chapman and Chapman, 2004). Users can click on hotspots or links in an image or text appearing on one screen that leads them to another part of the program where, say, an animation or a video clip is played. From there they can return to where they were previously or move on to another place.

Many multimedia narratives and games have been developed that are designed to encourage users to explore different parts of the game or story by clicking on different parts of the screen. An assumption is that a combination of media and interactivity can provide better ways of presenting information than can either one alone. There is a general belief that more is more and the whole is greater than the sum of the parts (Lopuck, 1996). In addition, the added value assumed from being able to interact with multimedia in ways not possible with single media (i.e. books, audio, video) is easier learning, better understanding, more engagement, and more pleasure (see Scaife and Rogers, 1996).

One of the distinctive features of multimedia is its ability to facilitate rapid access to multiple representations of information. Many multimedia encyclopedias and digital libraries have been designed based on this multiplicity principle, providing an assortment of audio and visual materials on a given topic. For example, if you want to find out about the heart, a typical multimedia-based encyclopedia will provide you with:

· One or two video clips of a real live heart pumping and possibly a heart transplant operation.

· Audio recordings of the heart beating and perhaps an eminent physician talking about the cause of heart disease.

· Static diagrams and animations of the circulatory system, sometimes with narration.

· Several columns of hypertext, describing the structure and function of the heart.

Hands-on interactive simulations have also been incorporated as part of multimedia learning environments. An early example was the Cardiac Tutor, developed to teach students about cardiac resuscitation, that required students to save patients by selecting the correct set of procedures in the correct order from various options displayed on the computer screen (Eliot and Woolf, 1994). Several educational websites now provide multimedia educational content. For example, NASA has a multimedia section that provides simulation models based on their research to enable students to develop and test their own designs for a life support system for use on the Moon (see Figure 6.14). The learning environment provides a range of simulators that are combined with online resources.

Multimedia has largely been developed for training, educational, and entertainment purposes. It is generally assumed that learning (e.g. reading and scientific inquiry skills) and playing can be enhanced through interacting with engaging multimedia interfaces. But what actually happens when users are given unlimited, easy access to multiple media and simulations? Do they systematically switch between the various media and ‘read’ all the multiple representations on a particular subject? Or, are they more selective in what they look at and listen to?

Anyone who has interacted with educational multimedia knows just how tempting it is to play the video clips and animations, while skimming through accompanying text or static diagrams. The former are dynamic, easy and enjoyable to watch, while the latter are viewed as static, boring, and difficult to read from the screen. For example, in an evaluation of an early interactive book students consistently admitted to ignoring the text at the interface in search of clickable icons of the author, which when selected would present an animated video of him explaining some aspect of design (Rogers and Aldrich, 1996). Given the choice to explore multimedia material in numerous ways, ironically, users tend to be highly selective as to what they actually attend to, adopting a channel hopping mode of interaction. While enabling the users to select for themselves the information they want to view or features to explore, there is the danger that multimedia environments may in fact promote fragmented interactions where only part of the media is ever viewed. This may be acceptable for certain kinds of activities, e.g. browsing, but less optimal for others, e.g. learning about a topic. One way to encourage more systematic and extensive interactions (when it is considered important for the activity at hand) is to require certain activities to be completed that entail the reading of accompanying text, before the user is allowed to move on to the next level or task.

Figure 6.14 Screen dump from the multimedia environment BioBLAST

BOX 6.3

Accessible interactive TV services for all

TV now provides many digital channels, of which sports, news, and movie channels are very popular. In addition, a range of interactive TV services are being offered that enable users to browse the web, customize their viewing choices, play interactive games, do their banking and shopping, and take an active part in a number of broadcast shows, e.g. voting. Besides offering a wide diversity of choices to the general public, there is much potential for empowering disabled and elderly users, by enabling them to access the services from the comfort of their own armchair. But it requires a new sensitivity to interactive design, taking into account specific usability issues for those with impaired motor control, poor vision, and hearing difficulties (Newell, 2003). For example, remote controls need to be designed that can be manipulated with poor dexterity, text/icons need to be readable for those with poor eyesight, while navigation methods need to be straightforward for viewers who are not experienced with multimedia-based interfaces.

Research and design issues

A key research question is how to design multimedia to help users explore, keep track of, and integrate the multiple representations of information provided, be it a digital library, a game, or learning material. As mentioned above, one technique is to provide hands-on interactivities and simulations at the interface that require the user to complete a task, solve a problem, or explore different aspects of a topic. Specific examples include electronic notebooks that are integrated as part of the interface, where users can copy, download, or type in their own material; multiple-choice quizzes that give feedback on how the user has done; interactive puzzles where the user has to select and position different pieces in the right combination; and simulation-type games where the user has to follow a set of procedures to achieve some goal for a given scenario. Another approach is to employ dynalinking, where information depicted in one window explicitly changes in relation to what happens in another. This can help users keep track of multiple representations and see the relationship between them (Scaife and Rogers, 1996).

Specific guidelines are available that recommend how best to combine multiple media in relation to different kinds of task, e.g. when to use audio with graphics, sound with animations, and so on for different learning tasks. For example, Alty (1991) suggests that audio information is good for stimulating imagination, movies for action information, text for conveying details, whilst diagrams are good at conveying ideas. From such generalizations it is possible to devise a presentation strategy for learning. This can be along the lines of: first, stimulate the imagination through playing an audio clip; then, present an idea in diagrammatic form; then, display further details about the concept through hypertext. Sutcliffe and his colleagues have also developed guidelines, based on cognitive engineering principles, that recommend how to link different media together to give coherent and comprehensive presentations (Faraday and Sutcliffe, 1997; Sutcliffe, 2003). Quintana et al (2002) have developed a set of guidelines for learner-centered design that outline various features that can be used to guide and prompt students in multimedia learning environments. Examples include process maps and flow diagrams.

6.2.4 Virtual Reality

Virtual reality (VR) uses computer-generated graphical simulations to create “the illusion of participation in a synthetic environment rather than external observation of such an environment” (Gigante, 1993, p. 3). VR is a generic term that refers to the experience of interacting with an artificial environment, which makes it feel virtually real. The term virtual environment (VE) is used more specifically to describe what has been generated using computer technology (although both terms are used interchangeably). Images are displayed stereoscopically to the users – most commonly through shutter glasses – and objects within the field of vision can be interacted with via an input device like a joystick. The 3D graphics can be projected onto CAVE (Cave Automatic Virtual Environment) floor and wall surfaces, desktops, 3DTV, or large shared displays, e.g. IMAX screens.

One of the main attractions of VR is that it can provide opportunities for new kinds of experience, enabling users to interact with objects and navigate in 3D space in ways not possible in the physical world or a 2D graphical interface. The resulting user experience can be highly engaging; it can feel as if one really is flying around a virtual world. People can become immersed in and highly captivated by the experience (Kalawsky, 1993). For example, in the Virtual Zoo project, Allison et al (1997) found that people were highly engaged and very much enjoyed the experience of adopting the role of a gorilla, navigating the environment, and watching other gorillas respond to their movements and presence (see Figure 6.15).

Figure 6.15 The Virtual Gorilla Project. On the left a student wears a head-mounted display and uses a joystick to interact with the virtual zoo. On the right are the virtual gorillas she sees and which react to her movements

One of the advantages of VR is that simulations of the world can be constructed to have a higher level of fidelity with the objects they represent compared with other forms of graphical interface, e.g. multimedia. The illusion afforded by the technology can make virtual objects appear to be very life-like and behave according to the laws of physics. For example, landing and take-off terrains developed for flight simulators can appear to be very realistic. Moreover, it is assumed that learning and training applications can be improved through having a greater fidelity with the represented world. A sense of presence can also make the virtual setting seem convincing. By presence is meant “a state of consciousness, the (psychological) sense of being in the virtual environment” (Slater and Wilbur, 1997, p. 605), where someone is totally engrossed by the experience, and behaves in a similar way to how they would if at an equivalent real event.

Another distinguishing feature of VR is the different viewpoints it can offer. Players can have a first-person perspective, where their view of the game or environment is through their own eyes, or a third-person perspective, where they see the world through an avatar visually represented on the screen. An example of a first-person perspective is that experienced in first-person shooter games such as DOOM, where the player moves through the environment without seeing a representation of themselves. It requires the user to imagine what he might look like and decide how best to move around. An example of a third-person perspective is that experienced in Tomb Raider, where the player sees the virtual world above and behind the avatar of Lara Croft. The user controls Lara's interactions with the environment by controlling her movements, e.g. making her jump, run, or crouch. Avatars can be represented from behind or from the front, depending on how the user controls its movements. First-person perspectives are typically used for flying/driving simulations and games, e.g. car racing, where it is important to have direct and immediate control to steer the virtual vehicle. Third-person perspectives are more commonly used in games, learning environments, and simulations where it is important to see a representation of self with respect to the environment and others in it. In some virtual environments it is possible to switch between the two perspectives, enabling the user to experience different viewpoints on the same game or training environment.

Early VR was developed using head-mounted displays. However, they have been found to be uncomfortable to wear, sometimes causing motion sickness and disorientation. They are also expensive and difficult to program and maintain. Nowadays, desktop VR is mostly used; software toolkits are now available that make it much easier to program a virtual environment, e.g. Alice (www.alice.org/). Instead of moving in a physical space with a head-mounted display, users interact with a desktop virtual environment – as they would any other desktop application – using mice, keyboards, or joysticks as input devices. The desktop virtual environment can also be programmed to present a more realistic 3D effect (similar to that achieved in 3D movies shown at IMAX cinemas), requiring users to wear a pair of shutter glasses.

Research and design issues

VR has been developed to support learning and training for numerous skills. Researchers have designed them to help people learn to drive a vehicle, fly a plane, and perform delicate surgical operations – where it is very expensive and potentially dangerous to start learning with the real thing. Others have investigated whether people can learn to find their way around a real building/place before visiting it by first navigating a virtual representation of it, e.g. Gabrielli et al (2000). VEs have also been designed to help people practice social skills, speaking skills, and confront their social phobias, e.g. Cobb et al (2002) and Slater et al (1999). An underlying assumption is that the environment can be designed as a safe place to help people gently overcome their fears (e.g. spiders, talking in public) by confronting them through different levels of closeness and unpleasantness (e.g. seeing a small virtual spider move far away, seeing a medium one sitting nearby, and then finally touching a large one). Studies have shown that people can readily suspend their disbelief, imagining a virtual spider to be a real one or a virtual audience to be a real audience. For example, Slater et al (1999) found that people rated themselves as being less anxious after speaking to a virtual audience that was programmed to respond to them in a positive fashion than after speaking to virtual audiences programmed to respond to them negatively.

Core design issues that need to be considered when developing virtual environments are: how to prevent users experiencing nausea; determining the most effective ways of enabling users to navigate through them, e.g. first versus third person; how to control their interactions and movements, e.g. use of head and body movements; how best to enable them to interact with information in them, e.g. use of keypads, pointing, joystick buttons; and how to enable users to collaborate and communicate with others in the virtual environment. A central concern is the level of realism to aim for. Is it necessary to design avatars and the environments they inhabit to be life-like, using rich graphics, or can simpler and more abstract forms be used, but which nonetheless are equally capable of engendering a sense of presence? For more on this topic see the dilemma box below.

Guidelines are available for helping to design virtual environments, which focus on how best to support navigation and user control, including where to place landmarks and objects in large-scale environments to ease navigation (Vinson, 1999) and the rules of everyday life that can be contravened, e.g. enabling avatars to walk through virtual walls and buildings (Sutcliffe, 2002).

DILEMMA

Realism versus abstraction?

One of the challenges facing interaction designers is whether to use realism or abstraction when designing an interface. This means designing objects either to (i) give the illusion of behaving and looking like real-world counterparts or (ii) appear as abstractions of the objects being represented. This concern is particularly relevant when implementing conceptual models that are deliberately based on an analogy with some aspect of the real world. For example, is it preferable to design a desktop to look like a real desktop, a virtual house to look like a real house, or a virtual terrain to look like a real terrain? Or, alternatively, is it more effective to design representations as simple abstract renditions, depicting only a few salient features?

One of the main benefits of using realism at the interface is that it can enable people to feel more comfortable when first learning an application. The rationale behind this is that such representations can readily tap into people's understanding of the physical world. Hence, realistic interfaces can help users initially understand the underlying conceptual model. In contrast, overly schematic and abstract representations can appear to be too computer-like and may be off-putting to the newcomer. The advantage of more abstract interfaces, however, is that they can be more efficient to use. Furthermore, the more experienced users become, the more they may find comfortable interfaces no longer to their liking. A dilemma facing designers, therefore, is deciding between creating interfaces to make novice users feel comfortable (but more experienced users less comfortable) and designing interfaces to be effective for more experienced users (but maybe harder to learn by novices).

One of the earliest attempts at using realism at the interface was General Magic's office system Magic Cap, which was rendered in 3D. To achieve this degree of realism required using various perceptual cues such as perspective, shadowing, and shading. The result was a rather cute interface (see Figure 6.16). Although their intentions were well-grounded, the outcome was less successful. Many people commented on how childish and gawky it looked, having the appearance of illustrations in a children's picture book rather than a work-based application.

Figure 6.16 Magic Cap's 3D desktop interface

Mullet and Sano (1995) also point out how a 3D rendition of an object like a desk nearly always suffers from both an unnatural point of view and an awkward rendering style that ironically destroy the impression of being in a real physical space. One reason for this is that 3D depictions conflict with the effective use of display space, especially when 2D editing tasks need to be performed. As can be seen in Figure 6.16, these kinds of task were represented as flat buttons that appear to be floating in front of the desk, e.g. mail, program manager, task manager.

For certain kinds of applications, using realism can be very effective for both novices and experienced users. Computer-based games fall into this category, especially those where users have to react rapidly to dynamic events that happen in a virtual world in real time, say flying a plane or playing a game of virtual football. Making the characters in the game resemble humans in the way they look, move, dress, and behave also makes them seem more convincing and lifelike, enhancing the enjoyment and fun factor.

ACTIVITY 6.4

Many games have been ported from the PC platform to the cell phone. Because of the screen size, however, they tend to be simpler and sometimes more abstract. To what extent does this adaptation of the interface affect the experience of playing the same game?

Figure 6.17 Two screenshots from the game Snake – the one on the left is played on a PC and the one on the right on a cell phone. In both games, the goal is to move the snake (the blue thing and the black squares, respectively) towards targets that pop up on the screen (e.g. the bridge, the star) and to avoid obstacles (e.g. a flower, the end of the snake's tail). When a player successfully moves his snake head over or under a target, the snake increases its length by one blob or block. The longer the snake gets the harder it is to avoid obstacles. If the snake hits an obstacle the game is over. On the PC version there are lots of extra features that make the game more complicated, including more obstacles and ways of moving. The cell phone version has a simple 2D bird's eye representation, whereas the PC version adopts a 3D third-person avatar perspective

Comment

The most effective games to have been ported over to the cell phone are highly addictive games that use simple graphics and do not require the user to navigate between different windows. Examples are Snake (see Figure 6.17), Tetris, and Snood, where the goal of the game is to move an object (e.g. a snake, abstract shapes, a shooter) small distances in order to eat food, fill a container, or delete shapes. More complex games, like World of Warcraft – which are very popular on the PC platform – would not port over nearly as well. It is simply too difficult to navigate and engage in the same level of interaction that makes the game enjoyable and addictive when played on a PC.

6.2.5 Information Visualization

Information visualizations are computer-generated graphics of complex data that are typically interactive and dynamic. The goal is to amplify human cognition, enabling users to see patterns, trends, and anomalies in the visualization and from this to gain insight (Card et al, 1999). Specific objectives are to enhance discovery, decision-making, and explanation of phenomena. Most interactive visualizations have been developed for use by experts to enable them to understand and make sense of vast amounts of dynamically changing domain data or information, e.g. satellite images or research findings, that take much longer to achieve if using only text-based information.

Common techniques that are used for depicting information and data are 3D interactive maps that can be zoomed in and out of and which present data via webs, trees, clusters, scatterplot diagrams, and interconnected nodes (Bederson and Shneiderman, 2003; Chen, 2004). Hierarchical and networked structures, color, labeling, tiling, and stacking are also used to convey different features and their spatial relationships. At the top of Figure 6.18 is a typical treemap, called MillionVis, that depicts one million items all on one screen using the graphical techniques of 2D stacking, tiling, and color (Fekete and Plaisant, 2002). The idea is that viewers can zoom in to parts of the visualization to find out more about certain data points, while also being able to see the overall structure of an entire data set. The treemap has been used to visualize file systems, enabling users to understand why they are running out of disk space, how much space different applications are using, and also for viewing large image repositories that contain Terabytes of satellite images. Similar visualizations have been used to represent changes in stocks and shares over time, using rollovers to show additional information, e.g. Marketmap on SmartMoney.com.

The visualization at the bottom of Figure 6.18 depicts the evolution of co-authorship networks over time (Ke et al, 2004). It uses a canonical network to represent spatially the relationships between labeled authors and their place of work. Changing color and thickening lines that are animated over time convey increases in co-authoring over time. For example, the figure shows a time slice of 100 authors at various US academic institutions, in which Robertson, Mackinlay, and Card predominate, having published together many times more than with the other authors. Here, the idea is to enable researchers to readily see connections between authors and their frequency of publishing together with respect to their location over time. (Note: Figure 6.18 is a static screen shot for 1999.) Again, an assumption is that it is much easier to read this kind of diagram compared with trying to extract the same information from a text description or a table.

Figure 6.18 Two types of visualizations, one using flat colored blocks and the other animated color networks that expand and change color over time

Research and design issues

Much of the research in information visualization has focused on developing algorithms and interactive techniques to enable viewers to explore and visualize data in novel ways. There has been less research evaluating the visualizations in terms of how they help scientists, traders, and others discover and make better-informed decisions, about policy or research. Key design issues include whether to use animation and/or interactivity, what form of coding to use, e.g. color or text labels, whether to use a 2D or 3D representational format, what forms of navigation, e.g. zooming or panning, and what kinds of and how much additional information, e.g. rollovers or tables of text, to provide. The type of metaphor to be used is also an important concern, e.g. one based on flying over a geographical terrain or one that represents documents as part of an urban setting. An overriding principle is to design a visualization that is easy to comprehend and easy to make inferences from. If too many variables are depicted in the same visualization it can make it much more difficult for the viewer to read and make sense of what is being represented.

6.2.6 Web

Early websites were largely text-based, providing hyperlinks to different places or pages of text. Much of the design effort was concerned with how best to structure information at the interface to enable users to navigate and access it easily and quickly. For example, Nielsen (2000) adapted his and Mohlich's usability guidelines (Nielsen and Mohlich, 1990) to make them applicable to website design, focusing on simplicity, feedback, speed, legibility, and ease of use. He also stressed how critical download time was to the success of a website. Simply, users who have to wait too long for a page to appear are likely to move on somewhere else.

Since the 1990s, many web designers have tried to develop sites that are aesthetically pleasing, usable, and easy to maintain. Graphical design was viewed as a top priority. A goal was to make web pages distinctive, striking, and pleasurable for the user when they first view them and also to make them readily recognizable on their return. Sometimes, they were able to meet all three criteria whilst other times they have managed to make a website look good but terrible to navigate and even worse to update content. Other times, they managed to design easy to navigate sites that looked dreadful. Krug (2005) characterized the debate on usability versus attractiveness in terms of the difference between how designers create websites and how users actually view them. He argues that web designers create sites as if the user was going to pore over each page, reading the finely crafted text word for word, looking at the use of images, color, icons, etc., examining how the various items have been organized on the site, and then contemplating their options before they finally select a link. Users, however, behave quite differently. They will glance at a new page, scan part of it, and click on the first link that catches their interest or looks like it might lead them to what they want. Much of the content on a web page is not read. In his words, web designers are “thinking great literature” (or at least “product brochure”) while the user's reality is much closer to a “billboard going by at 60 miles an hour” (Krug, 2005, p. 21). While somewhat of a caricature of web designers and users, his depiction highlights the discrepancy between the meticulous ways designers create their websites with the rapid and less than systematic approach that users take to look at them.

Website design took off in a big way in the early 2000s when user-centered editing tools (e.g. Dreamweaver) and programming languages (e.g. php, Flash and XML) emerged providing opportunities for both designers and the general public to create websites to look and behave more like multimedia environments. New languages, such as HTML5, and web development techniques, such as Ajax, started to appear, enabling applications to be built that are largely executed on a user's computer, allowing the development of web applications that mimic desktop apps. Wikis and blogs also became very popular, enabling any number of interlinked web pages to be created and edited using a simple browser-based text editor. A number of previously PC-based applications became web-based, such as email, (e.g. Gmail) and photo storing and sharing (e.g. Flickr). Customized web pages also started to be developed for smart phones browsers that listlinked (i.e. provided scrolling lists of articles, games, tunes that could be clicked on) rather than hyperlinked pages.

BOX 6.4

In-your-face web ads

Web advertising has become pervasive and invasive. Advertisers realized how effective flashing and animated ads were for promoting their products, taking inspiration from the animated neon light adverts used in city centers, such as London's Piccadilly Circus. But since the banner ads (the 728 × 90 pixel ads that were placed at the top of web pages) emerged in the 1990s, they have become even more cunning and aggressive in their tactics. In addition to designing even flashier banner ads, more intrusive kinds of web ads have begun to appear on our screens. Short movies and garish cartoon animations – often with sound – now pop up in floating windows that zoom into view or tagged on at the front end of an online newspaper or magazine news videoclip. Moreover, this new breed of in-your-face web ads often requires the user to either sit and wait till it ends or find a check box to close the window down. This can be really annoying to have to do especially when multiple ad windows open up. Sites that provide free services, such as Facebook, YouTube, and Gmail, have also become populated with web ads. Many people choose to ignore them or simply put up with them. However, as advertisers get even more aggressive in their tactics there will be a point where that will become harder to do. The problem is advertisers pay significant revenues to online companies to have their adverts placed on their websites entitling them to say where, what, and how they should appear.

Research and design issues

There are numerous classic books on web design and usability that have been updated as new editions, e.g. Krug (2005); Cooper et al (2007); Hoekman and Spool (2009); Nielsen and Loranger (2006). In addition, there are many good online sites offering guidelines and tips, together with pointers to examples of bad websites. Increasingly, it is the case that today's web interfaces are not that different from GUIs; both need to consider how best to design, present, and structure information and system behavior. The main difference is the web's emphasis on content and the use of links for navigation.

Key design issues for websites, which differ from other interfaces, are captured very well by three questions proposed by Keith Instone (quoted in Veen, 2001): Where am I? What's here? Where can I go? Jeffrey Veen (2001) expands on these questions. He suggests that a simple way to view a web page is to deconstruct it into three areas (see Figure 6.19). Across the top would be the answer to ‘Where am I?’ Because users can arrive at a site from any direction (and rarely through the front door, or homepage), telling them where they are is critical. Having an area at the top of the page that ‘brands’ the page instantly provides that information. Down the left-hand side is an area in which navigation or menus sit. This should allow users to see immediately what else is available on the site, and answers the question ‘Where can I go?’

The most important information, and the reason a user has come to the site in the first place, is provided in the third area, the content area, which answers the question ‘What’s here?’ These three fundamental questions are still very relevant for today's websites, even though their placement may vary. Krug (2005) also suggests the importance of breaking up pages into clearly defined areas, making it obvious what is clickable and minimizing noise. He promotes creating a clear visual hierarchy on each page, so it is easy for a user to grasp in a hurry, showing which things are related and what's what (e.g. a link, a search box) and capitalizing on conventions (e.g. using a shopping cart icon on e-commerce sites to indicate the link to make a purchase) rather than reinventing the wheel.

Figure 6.19 Any web page has three main areas

Web Content Accessibility Guidelines (WCAG) are available to enable developers to know how to design websites that are inclusive. The latest version WCAG 2.0 was published in 2008. These guidelines include designing websites for:

· Users who may not be able to see, hear, move, or may not be able to process some types of information easily or at all.

· Users who have difficulty reading or comprehending text.

· Users who may not have or be able to use a keyboard or mouse.

· Users who may have a text-only screen, a small screen, or a slow Internet connection.

Website content also needs to be designed for:

· Users who may not speak or understand fluently the language in which the document is written.

· Users who are in a setting where their eyes, ears, or hands are busy or interfered with, e.g. driving to work.

Users who may have an early version of a browser, a different browser entirely, a voice browser, or a different operating system.

ACTIVITY 6.5

Look at a fashion brand's website, such as Nike or Levi's, and describe the kind of interface used. How does it contravene the design principles outlined by Veen? Does it matter? What kind of user experience is it providing for? What was your experience of engaging with it?

Comment

Fashion companies sites, like Nike's or Levi's, are designed to be more like a cinematic experience and use rich multimedia elements, e.g. videos, sounds, music, animations, and interactivity. Branding is central. In this sense, it is a far cry from a conventional website and contravenes many of the usability guidelines. Specifically, the site has been designed to entice the visitor to enter the virtual store and watch high quality and innovative movies that show cool dudes wearing their products. Often multimedia interactivities are embedded into the sites to help the viewer move to other parts of the site, e.g. clicking on parts of an image or animation. Screen widgets are also provided, e.g. menus, skip over, and next buttons. It is easy to become immersed in the experience and forget it is a commercial store. It is also easy to get lost and to not know: Where am I? What's here? Where can I go? But this is precisely what companies such as Nike and Levi's want their visitors to do and enjoy the experience.

6.2.7 Consumer Electronics and Appliances

Consumer electronics and appliances include machines for everyday use in the home, public place, or car (e.g. washing machines, DVD players, vending machines, remotes, photocopiers, printers, and navigation systems) and personal devices (e.g. MP3 player, digital clock, and digital camera). What they have in common is that most people using them will be trying to get something specific done in a short period of time, such as putting the washing on, watching a program, buying a ticket, changing the time, or taking a snapshot. They are unlikely to be interested in spending time exploring the interface or spending time looking through a manual to see how to use the appliance.

Research and design issues

Cooper et al (2007) suggest that appliance interfaces require the designer to view them as transient interfaces, where the interaction is short. All too often, however, designers provide full-screen control panels or an unnecessary array of physical buttons that serve to frustrate and confuse the user and where only a few in a structured way would be much better. Here, the two fundamental design principles of simplicity and visibility are paramount. Status information, such as what the photocopier is doing, what the ticket machine is doing, and how much longer the washing is going to take should be provided in a very simple form and at a prominent place on the interface. A key design question is: as soft displays, e.g. LCD and touch screens, increasingly become part of an appliance interface, what are the trade-offs with replacing the traditional physical controls, e.g. dials, buttons, knobs? .

ACTIVITY 6.6

Look at the controls on your toaster (or the one in Figure 6.20 if you don't have one nearby) and describe what each does. Consider how these might be replaced with an LCD screen. What would be gained and lost from changing the interface in this way?

Comment

Standard toasters have two main controls, the lever to press down to start the toasting and a knob to set the amount of time for the toasting. Many now come with a small eject button intended to be pressed if the toast starts to burn. In Figure 6.20 it is to the left of the timer knob. Some also come with a range of settings for different ways of toasting (e.g. one side, frozen), selected by moving a dial or pressing buttons.

To design the controls to appear on an LCD screen would enable more information and options to be provided, e.g. only toast one slice, keep the toast warm, automatically pop up when the toast is burning. It would also allow precise timing of the toasting in minutes and seconds. However, as has happened with the design evolution of microwave ovens, a downside is that it is likely to increase the complexity of what previously was a set of logical and very simple actions – placing something in an oven and heating it up – making it more difficult to use.

Figure 6.20 A typical toaster with basic physical controls

6.2.8 Mobile

Mobile devices have become pervasive, with people increasingly using them in all aspects of their everyday and working lives. They have become business tools to clinch important deals; a remote control for the real world, helping people cope with daily travel delay frustrations; and a relationship appliance to say goodnight to loved ones when away from home (Jones and Marsden, 2006). People spend many hours a day on their phone, checking for emails, texting, googling, downloading apps, watching YouTube videos, reading the news, listening to music, and so on.

Handheld devices, such as cell phones and iPods, differ from PCs, laptops, and iPads, essentially in terms of their size and portability. They can be kept in someone's pocket, purse, or in a case on their belt so as to be ready at hand 24/7. A buzz or the first second of a familiar jingle is all that it takes for someone to down tools and listen or look at what new has popped up on their phone. Handheld devices can also be held and used by people in mobile settings where they need access to real time data or information whilst walking around. For example, they are now commonly used in restaurants to take orders, car rentals to check in car returns, supermarkets for checking stock, and on the streets for multiplayer gaming.

The phenomenal uptake of cell phones across the globe has resulted in all manner of services and apps being ported over, from web browsers to social networking. The introduction of Apple's iPhone in 2008 introduced the world to the app – a whole new user experience that is designed primarily for people to enjoy. There are now 100 000s of apps available with many new ones appearing each day for many different categories, including games, entertainment, social networking, music, productivity, lifestyle, travel, and navigation. Many apps are not designed for any need, want, or use but purely for idle moments to have some fun. An example of an early highly successful fun app was iBeer (see Figure 6.21), developed by magician Steve Sheraton. Within months of release, hundreds of thousands of people had downloaded the app, then showed their friends who also then downloaded it and showed it to their friends. It became an instant hit, a must have, a party piece – quite unlike any other kind of software. Moreover, a magician created it – rather than an interaction designer – who really understood what captivates people. Part of its success is due to the ingenious use of the accelerometer that is inside the phone. It detects the tilting of the iPhone and uses this information to mimic a glass of beer being drunk. The graphics and sounds are also very enticing; the color of the beer together with frothy bubbles and accompanying sound effects gives the illusion of virtual beer being swished around a virtual glass. The beer can be drained if the phone is tilted enough, followed by a belch sound when it has been finished.

Figure 6.21 The iBeer smartphone app

Figure 6.22 Pepsi MAX QR code

Cell phones can also be used to download contextual information by scanning bar codes in the physical world. Consumers can instantly download product information by scanning bar codes using their iPhone when walking around a supermarket, including allergens, such as nuts, gluten, and dairy. For example, the GoodGuide app enables shoppers to scan products in a store by taking a photo of their barcode to see how they rate for healthiness and impact on the environment. Another method that provides quick access to relevant information is the use of QR (quick response) codes that store URLs and look like black and white chequered squares. They can appear in magazines, on billboards, business cards, clothing, etc., and even on soda cans (see Figure 6.22). They work by people taking a picture using their camera phone which then instantly takes them to a particular website.

People now Google on the go as part of their daily life, speaking to their phone to find out where to eat, what to see, and so on while at the same time checking their email, texts, etc. Sharing new apps has also become an intergenerational pastime – for example, my niece on first meeting up with me will demonstrate her latest cool app she has just downloaded. For many people, their phone has become an extension of themselves, providing for all of their desires and wants, and replacing the need to use a tethered PC computer. It has even taken over many of our cognitive functions, as poignantly described by the philosopher David Chalmers:

[the iPhone] has replaced part of my memory, storing phone numbers and addresses that I once would have taxed my brain with. It harbors my desires: I call up a memo with the names of my favorite dishes when I need to order at a local restaurant. I use it to calculate, when I need to figure out bills and tips. It is a tremendous resource in an argument, with Google ever present to help settle disputes … I even daydream on the iPhone, idly calling up words and images when my concentration slips.(Chalmers, 2008)

Phone companies are increasing the range of their phones that have touch screens (see Section 6.2.11 on touch). There are, however, still many mobile devices that use a mix of hard and soft keys for input. A number of physical controls have been developed for mobile interfaces, including a roller wheel positioned on the side of a phone and a rocker positioned on the front of a device – both designed for rapid scrolling of menus; the up/down lips on the face of the phone; and two-way directional keypads and four-way navigational pads that encircle a central push button for selecting options. Soft keys (which usually appear at the bottom of a screen) and silk-screened buttons (icons that are printed on or under the glass of a touchscreen display) have been designed for frequently selected options and for mode changing.

The preference for and ability to use these control devices varies, depending on the dexterity and commitment of the user when using the handheld device. For example, some people find the rocker device fiddly to use for the fine control required for scrolling through menus on a small screen. Conversely, others are able to master them and find them much faster to use compared with using up and down arrow buttons that have to be pressed each time a menu option is moved through.

Location-based services that allow people to see where they are by the geographical position of their mobile device have started to appear. Examples include apps that help someone get from A to B, locating others on a map displayed on the phone, and receiving ads and alerts, such as a traffic jam ahead. Location based sharing apps, such as FourSquare and PlanCast, allow groups of friends to keep tabs on each other's current activities and track what their friends are planning to do in the future. One of the benefits is it allows people to let others know in real time all the cool places they go to. However, some people may find it an invasion of their privacy having their every move tracked by others. The privacy of others can be respected, however, by providing various forms of real-time feedback (e.g. SMS messages) to them that indicate whenever someone has been checking up on them (Jedrzejczyk et al, 2010). Figure 6.23 shows screen shots of a prototype system that provides this kind of visibility.

Figure 6.23 Real-time feedback on a person's mobile device showing who is checking up on them using a location sharing app

Research and design issues

Mobile interfaces typically have a small screen and limited control space. Designers have to think carefully about what type of dedicated controls (i.e. hard wired) to use, where to place them on the device, and then how to map them onto the software. Applications designed for mobile interfaces need to take into account that navigation will be restricted and text input entry slow, whether using touch, pen, or keypad input. The use of vertical and horizontal scrolling provides a rapid way of scanning though images, menus, and lists. A number of mobile browsers have also been developed that allow users to view and navigate the Internet, magazines, or other media, in a more streamlined way compared with how it is typically viewed via PC-based web browsers. For example, Edge Browser was one of the first cell phone browser apps to not have an address bar or navigation buttons. The trade-off, however, is it makes it less obvious how to perform the functions that are no longer visible on the screen.

A number of guidelines exist providing advice on how to design interfaces for mobile devices (e.g. Weiss, 2002). Windows Phone and Apple also provide extensive guidelines for developing cell phone interfaces and apps. Case study 11.2 presented on our website describes how prototyping can be used for developing mobile interfaces.

Privacy issues are also becoming more prevalent as social networking and location sharing applications become available. As mentioned above it is important for people to feel comfortable by providing socially translucent feedback (see Chapter 4) that provides feedback when someone is checking up on the whereabouts of another person.

6.2.9 Speech

A speech or voice user interface is where a person talks with a system that has a spoken language application, like a train timetable, a travel planner, or a phone service. It is most commonly used for inquiring about specific information (e.g. flight times) or to perform a transaction (e.g. buy a ticket or top-up a cell phone account). It is a specific form of natural language interaction that is based on the interaction type of conversing (see Chapter 2), where users speak and listen to an interface. There are many commercially available speech-based applications that are now being used by corporations, especially for offering their services over the phone. Speech-to-text systems have also become popular as PC and smartphone apps, such as Dragon Dictate. Speech technology has also advanced applications that can be used by people with disabilities, including speech recognition word processors, page scanners, web readers, and speech recognition software for operating home control systems, including lights, TV, stereo, and other home appliances.

Technically, speech interfaces have come of age, being much more sophisticated and accurate than the first generation of speech systems in the early 1990s, which earned a reputation for mishearing all too often what a person said (see cartoon). Actors are increasingly used to record the messages and prompts provided that are much friendlier, more convincing, and pleasant than the artificially sounding synthesized speech that was typically used in the early systems.

One of the most popular applications of speech technology is call routing, where companies use an automated speech system to enable users to reach one of their services. Many companies are replacing the frustrating and unwieldy touchtone technology for navigating their services (which was restricted to 10 numbers and the # and * symbols) with the use of caller-led speech. Callers can now state their needs in their own words (rather than pressing a series of arbitrary numbers), for example, ‘I'm having problems with my voice mail,’ and in response are automatically forwarded to the appropriate service (Cohen et al, 2004).

In human conversations we often interrupt each other, especially if we know what we want, rather than waiting for someone to go through a series of options. For example, at a restaurant we may stop the waitress in mid-flow when describing the specials if we know what we want rather than let her go through the whole list. Similarly, speech technology has been designed with a feature called barge-in that allows callers to interrupt a system message and provide their request or response before the message has finished playing. This can be very useful if the system has numerous options for the caller to choose from and the chooser knows already what he wants.

There are several ways a dialog can be structured. The most common is a directed dialog where the system is in control of the conversation, asking specific questions and requiring specific responses, similar to filling in a form (Cohen et al, 2004):

System: Which city do you want to fly to?

Caller: London

System: Which airport – Gatwick, Heathrow, Luton, Stansted, or City?

Caller: Gatwick

System: What day do you want to depart?

Caller: Monday week

System: Is that Monday 5th May?

Caller: Yes

Other systems are more flexible, allowing the user to take more initiative and specify more information in one sentence (e.g. ‘I'd like to go to Paris next Monday for two weeks’). The problem with this approach is that there is more chance of error, since the caller might assume that the system can follow all of her needs in one go as a real travel agent can (e.g. ‘I'd like to go to Paris next Monday for two weeks and would like the cheapest possible flight, preferably leaving Stansted airport and definitely no stop-overs …’). The list is simply too long and would overwhelm the system's parser. Carefully guided prompts can be used to get callers back on track and help them speak appropriately (e.g. 'Sorry, I did not get all that. Did you say you wanted to fly next Monday?).

Research and design issues

Key research questions are concerned with how to design systems that can recognize speech and keep the conversation on track. Some researchers focus on making it appear natural (i.e. like human conversations) while others are concerned more with how to help people navigate efficiently through a menu system, by enabling them to recover easily from errors (their own or the system's), be able to escape and go back to the main menu (cf. to the undo button of a GUI), and to guide those who are vague or ambiguous in their requests for information or services using prompts. The type of voice actor, e.g. male, female, neutral, or dialect and form of pronunciation are also topics of research. Do people prefer to listen to and are more patient with a female or male voice? What about one that is jolly or one that is serious?

Cohen et al (2004) discuss the pros and cons of using different techniques for structuring the dialog and managing the flow of voice interactions, the different ways of expressing errors, and the use of conversational etiquette. A number of commercial guidelines are available for voice interfaces and for the visually impaired.

A number of speech-based phone apps exist that enable people to use them while mobile, making them more convenient to use than text-based entry. For example, people can speak their queries into their phone using an app such as Google Mobile rather than entering text manually. Mobile translators are also coming into their own, allowing people to communicate in real-time with others who speak a different language, by letting a software app on their phone do the talking. People speak in their own language using their own phone while the software translates what each person is saying into the language of the other one. Potentially, that means people from all over the world (there are over 6000 languages) can talk to one another without ever having to learn another language.

6.2.10 Pen

Pen-based devices enable people to write, draw, select, and move objects at an interface using lightpens or styluses that capitalize on the well-honed drawing and writing skills that are developed from childhood. They have been used to interact with tablets and large displays, instead of mouse or keyboard input, for selecting items and supporting freehand sketching. Digital ink, such as Anoto, uses a combination of ordinary ink pen with a digital camera that digitally records everything written with the pen on special paper. The pen works by recognizing a special non-repeating dot pattern that is printed on the paper. The non-repeating nature of the pattern means that the pen is able to determine which page is being written on, and where on the page the pen is. When writing on the digital paper with a digital pen, infrared light from the pen illuminates the dot pattern, which is then picked up by a tiny sensor. The pen decodes the dot pattern as the pen moves across the paper and stores the data temporarily in the pen. The digital pen can transfer data that has been stored in the pen via Bluetooth or USB port to a PC. Handwritten notes can also be converted and saved as standard typeface text.

Another advantage of digital pens is that they allow users to quickly and easily annotate existing documents, such as spreadsheets, presentations, and diagrams (see Figure 6.24) – in a similar way to how they would do when using paper-based versions. A number of usability studies have been carried out comparing different ways of entering text using pen input, for children and adults. For example, a study by Read (2005) compared three methods for text input using digital ink technologies; handwriting with a stylus on a Tablet PC, handwriting with a graphics tablet and pen on a standard PC, and handwriting with a digital pen on digital paper. The user group was made up of children aged between 7 and 8, and 12 and 13. The findings showed that the older children were able to use the digital pens best but that both sets of children were able to use the stylus with the Tablet PC without making many errors.

A problem with using pen-based interactions on small screens, such as PDAs, is that sometimes it can be difficult to see options on the screen because a user's hand can occlude part of it when writing. Conversely, a problem with using digital pens on a large display is that the flow of interaction can be more easily interrupted. In particular, it can be more difficult to select menu options that appear along one side of the screen or that require a virtual keyboard to be opened – especially if more than one person is working at a whiteboard. Users often have to move their arms long distances and sometimes have to ask others to get out of the way so they can select a command (or ask them to do it). To overcome these usability problems, Guimbretière et al (2001) developed novel pen-based techniques for very large wall displays that enable users to move more fluidly between writing, annotating, and sketching content while at the same time performing commands. Thus, instead of having to walk over to a part of the wall to select a command from a fixed menu, users can open up a context-sensitive menu (called a FlowMenu) wherever they were interacting with information at the wall by simply pressing a button on top of the pen to change modes.

Figure 6.24 Microsoft's digital ink in action showing how it can be used to annotate a scientific diagram

BOX 6.5

Electronic ink

Digital ink is not to be confused with the term electronic ink (or e-ink). Electronic ink is a display technology designed to mimic the appearance of ordinary ink on paper. The display used reflects light like ordinary paper. Examples include Amazon's Kindle, Sony's Reader, and the Iliad reader (see Figure 6.25).

Figure 6.25 The Dutch lliad e-reader

6.2.11 Touch

Touchscreens, such as walk-up kiosks (e.g. ticket machines, museum guides), ATMs, and till machines (e.g. restaurants), have been around for some time. They work by detecting the presence and location of a person's touch on the display; options are selected by tapping on the screen. More recently, multitouch surfaces have been developed as the interface for tabletops and cell phones that support a range of more dynamic finger tip actions, such as swiping, flicking, pinching, pushing, and tapping. These have been mapped onto specific kinds of operations, e.g. zooming in and out of maps, moving photos, selecting letters from a virtual keyboard when writing, and scrolling through lists. Two hands can also be used together to stretch and move objects on a tabletop surface, similar to how both hands are used to stretch an elastic band or scoop together a set of objects.

The flexibility of interacting with digital content afforded by finger gestures has resulted in new ways of experiencing digital content. Most notable are the richer ways of reading, scanning, and searching interactive magazines and books on the iPad. Wired magazine, for example, was the first to enhance reading through accompanied experiencing of its online version. Similar to the idea behind multimedia, the idea is to enable the reader to readily switch between reading about something (e.g. the history of Mars landings) and experiencing it (e.g. by exploring a virtual simulation of the planet) – only rather than through mouse clicking on hyperlinks to do it by deft finger movements. A new conceptual model has also been used; content is organized in stacks to support rapid finger-flicking navigation, allowing readers to go directly to stories while still maintaining a sense of place.

Research and design issues

A research question is whether finger-flicking, stroking, and touching a screen rather than pointing, dragging, and clicking with a mouse will result in new ways of consuming, reading, creating, and searching digital content. On the one hand, it can be much faster to scroll through wheels, carousels, and bars of thumbnail images or lists of options by finger flicking. On the other, it can be more cumbersome, error-prone, and slower to type using a virtual keyboard on a touch display than using a physical keyboard. A novel method that has been developed for multitouch displays is to allow people to swipe their fingers across a virtual keyboard rather than tap at it (see Figure 6.26). Examples include Swype and Nuance's T-9 Trace. Swiping allows the user to move their finger from letter to letter on a virtual keyboard without lifting it. The software senses which are the intended letters by where the user pauses and changes direction. One of the benefits of typing by sliding your fingers across a screen rather than pecking at the keys is that it can make typing faster while also reducing error rate.

Figure 6.26 The swipe interface developed for mobile touch displays

Figure 6.27 Sony's EyeToy: the image of the player is projected onto the TV screen as part of the game, showing her using her arms and elbows to interact with the virtual game

6.2.12 Air-Based Gestures

Camera capture, sensor, and computer vision techniques have advanced such that it is now possible to fairly accurately recognize people's body, arm, and hand gestures in a room. An early commercial application that used gesture interaction was Sony's EyeToy, which used a motion-sensitive camera that sat on top of a TV monitor and plugged into the back of a Sony PlayStation. It could be used to play various video games. The camera filmed the player when standing in front of the TV, projected her image onto the screen, and made her the central character of the video game. The game could be played by anyone, regardless of age or computer experience, simply by moving her legs, arms, head, or any part of the body (see Figure 6.27).

Since then, Sony has introduced a motion-sensing wand, called the Move, that uses the Playstation Eye camera to track players' movements using light recognition technology. Nintendo's Wii gaming console also introduced the Wii Remote (Wiimote) controller as a novel input device. It uses accelerometers for gesture recognition. The sensors enable the player to directly input by waving the controller in front of a display, such as the TV. The movements are mapped onto a variety of gaming motions, such as swinging, bowling, hitting, and punching. The player is represented on the screen as an avatar that shows him hitting the ball or swinging the bat against the backdrop of a tennis court, bowling alley, or boxing ring. Like Sony's EyeToy, it was designed to appeal to anyone, from young children to grandparents, and from professional gamers to technophobes, to play games such as tennis or golf, together in their living room. The Wiimote also plays sound and has force feedback, allowing the player to experience rumbles that are meant to enhance the experience when playing the game. The Nunchuk controller can also be used in conjunction with the Wiimote to provide further input control. The analog stick can be held in one hand to move an avatar or characters on the screen while the Wiimote is held in the other to perform a specific action, such as throwing a pass in football.

In late 2010, Microsoft introduced another gesture-based gaming input system for the Xbox: the Kinect (see Figure 6.28). It is more similar to the EyeToy than the Wii in that it does not use a sensor-controller for gesture recognition but camera technology together with a depth sensor and a multi-array microphone (this enables speech commands). An RGB camera sits on the TV, and works by looking for your body; on finding it locks onto it, and measures the three-dimensional positioning of the key joints in your body. The feedback provided on the TV screen in response to the various air-gestures has proven to be remarkably effective. Many people readily see themselves as the avatar and learn how to play games in this more physical manner. However, sometimes the gesture/body tracking can misinterpret a player's movements, and make the ball or bat move in the wrong direction. This can be disconcerting, especially for expert gamers.

Figure 6.28 Microsoft's Xbox Kinect comprising a RGB camera for facial recognition plus video capturing, a depth sensor (an infrared projector paired with a monochrome camera) for movement tracking, and downward-facing mics for voice recognition

A number of air-based gesture systems have also been developed for controlling home appliances. Early systems used computer vision techniques to detect certain gesture types (e.g. location of hand, movement of arm) that were then converted into system commands. Other systems then began using sensor technologies to detect touch, bend, and speed of movement of the hand and/or arm. Ubi-Finger was developed to allow users to point at an object, e.g. a switch, using his/her index finger and then control it by an appropriate gesture, e.g. pushing the finger down as if flicking on the switch (Tsukada and Yasumura, 2002). Sign language applications have also been built to enable hearing-impaired people to communicate with others without needing a sign language interpreter (Sagawa et al, 1997).

Research and design issues

A key design concern for using air-based gestural input is to consider how a computer system recognizes and delineates the user's gestures. In particular, how does it determine the start and end point of a hand or arm movement and how does it know the difference between a deictic gesture (a deliberate pointing movement) and hand waving (an unconscious gesticulation) that is used to emphasize what is being said verbally? Another key design issue is whether holding a control device feels more intuitive for the game or other activity than controller - free gestures. Sometimes it clearly is better to be holding something – when for example, hitting a ball with a bat. Other times it may be better hands-free such as when dancing or doing aerobics.

6.2.13 Haptic

Haptic interfaces provide tactile feedback, by applying vibration and forces to the person, using actuators that are embedded in their clothing or a device they are carrying, such as a cell phone. We have already mentioned above how the Wiimote provides rumbles as a form of haptic feedback. Other gaming consoles have also employed vibration to enrich the experience. For example, car steering wheels that are used with driving simulators can vibrate in various ways to provide a feel of the road. As the driver makes a turn the steering wheel can be programmed to feel like it is resisting – in the way a real steering wheel does.

Vibrotactile feedback can also be used to simulate the sense of touch between remote people who want to communicate. Actuators embedded in clothing can be designed to recreate the sensation of a hug or a stroke through being buzzed on various parts of the body (see Huggy Pajama in Chapter 4). Another use of haptics is to provide feedback to guide people when learning a musical instrument, such as a violin or drums. For example, the MusicJacket (van der Linden, 2011) was developed to help novice violin players learn how to hold their instrument correctly and develop good bowing action. Vibrotactile feedback is provided via the jacket to give nudges at key places on the arm and torso to inform the student when either they are holding their violin incorrectly or their bowing trajectory has deviated from a desired path (see Figure 6.29). A user study with novice players showed that players were able to react to the vibrotactile feedback, and adjust their bowing or their posture in response.

Figure 6.29 The MusicJacket prototype with embedded actuators that nudge the player

Research and design issues

Haptics are now commonly used in gaming consoles and controllers to heighten the experience. Haptic feedback is also being developed in clothing and other wearables as a way of simulating being touched, stroked, prodded, or buzzed. A promising application area is sensory-motor skills, such as in sports training and learning to play a musical instrument. For example, patterns of vibrations have been placed across snowboarders' bodies to indicate which moves to take whilst snowboarding. A study reported faster reaction times than when the same instructions were given verbally (Spelmezan et al, 2009). A key design question is where best to place the actuators on the body, whether to use a single or a sequence of touches, when to activate, and at what intensity and how often to use them to make the feeling of being touched convincing (e.g. Jones and Sarter, 2008). Providing continuous haptic feedback would be simply too annoying. People would also habituate too quickly to the feedback. Intermittent buzzes can be effective at key moments when a person needs to attend to something but not necessarily tell them what to do. For example, a study by Johnson et al (2010) of a commercially available haptic device, intended to improve posture through giving people a vibrotactile buzz whenever they slouched, found that while the buzzing did not show them how to improve their posture it did improve their body awareness.

6.2.14 Multimodal

Multimodal interfaces are intended to provide enriched and complex user experiences by multiplying the way information is experienced and controlled at the interface through using different modalities, i.e. touch, sight, sound, speech (Bouchet and Nigay, 2004). Interface techniques that have been combined for this purpose include speech and gesture, eye-gaze and gesture, and pen input and speech (Oviatt et al, 2004). An assumption is that multimodal interfaces can support more flexible, efficient, and expressive means of human–computer interaction, that are more akin to the multimodal experiences humans experience in the physical world (Oviatt, 2002). Different input/outputs may be used at the same time, e.g. using voice commands and gestures simultaneously to move through a virtual environment, or alternately using speech commands followed by gesturing. The most common combination of technologies used for multimodal interfaces is speech and vision processing (Deng and Huang, 2004), such as used by Microsoft's Kinect.

Speech-based mobile devices that allow people to interact with information via a combination of speech and touch are beginning to emerge. An example is SpeechWork's multimodal interface developed for one of Ford's SUV concept cars, which allows the occupants to operate on-board systems including entertainment, navigation, cell phone, and climate control by speech.

Research and design issues

Multimodal systems rely on recognizing aspects of a user's behavior – be it her handwriting, speech, gestures, eye movements, or other body movements. In many ways, this is much harder to accomplish and calibrate than single modality systems that are programmed to recognize one aspect of a user's behavior. The most researched modes of interaction are speech, gesture, and eye gaze tracking. A key research question is what is actually gained from combining different input and outputs and whether talking and gesturing as humans do with other humans is a natural way of interacting with a computer (see Chapter 4). Guidelines for multimodal design can be found in Reeves et al (2004).

6.2.15 Shareable

Shareable interfaces are designed for more than one person to use. Unlike PCs, laptops, and mobile devices – that are aimed at single users – they typically provide multiple inputs and sometimes allow simultaneous input by collocated groups. These include large wall displays, e.g. SmartBoards (see Figure 6.30a), where people use their own pens or gestures, and interactive tabletops, where small groups can interact with information being displayed on the surface using their fingertips. Examples of interactive tabletops include Microsoft's Surface, Smart's SmartTable, and Mitsubishi's DiamondTouch (Dietz and Leigh, 2001, see Figure 6.30b). The DiamondTouch tabletop is unique in that it can distinguish between different users touching the surface concurrently. An array of antennae is embedded in the touch surface and each one transmits a unique signal. Each user has their own receiver embedded in a mat they stand on or a chair they sit on. When a user touches the tabletop very small signals are sent through the user's body to their receiver, which identifies which antenna has been touched and sends this to the computer. Multiple users can touch the screen at the same time.

An advantage of shareable interfaces is that they provide a large interactional space that can support flexible group working, enabling groups to create content together at the same time. Compared with a collocated group trying to work around a single-user PC – where typically one person takes control of the mouse, making it more difficult for others to take part – large displays have the potential of being interacted with by multiple users, who can point to and touch the information being displayed, while simultaneously viewing the interactions and having the same shared point of reference (Rogers et al, 2009).

Shareable interfaces have also been designed to literally become part of the furniture. For example, Philips designed the Café Table that displays a selection of contextually relevant content for the local community. Customers can drink coffee together while browsing digital content by placing physical tokens in a ceramic bowl placed in the center of the table. The Drift Table (see Figure 6.31), developed as part of Equator's Curious Home project, enables people to very slowly float over the countryside in the comfort of their own sitting room (Gaver et al, 2004). Objects placed on the table, e.g. books and mugs, control which part of the countryside is scrolled over, which can be viewed through the hole in the table via aerial photographs. Adding more objects to one side enables faster motion while adding more weight generally causes the view to ‘descend,’ zooming in on the landscape below.

Figure 6.30 (a) A SmartBoard in use during a meeting and (b) Mitsubishi's interactive tabletop interface, where collocated users can interact simultaneously with digital content using their fingertips

Figure 6.31 The Drift Table: side and aerial view

Roomware has designed a number of integrated interactive furniture pieces, including walls, table, and chairs, that can be networked and positioned together so they can be used in unison to augment and complement existing ways of collaborating (see Figure 6.32). An underlying premise is that the natural way people work together is by congregating around tables, huddling and chatting besides walls and around tables. The Roomware furniture has been designed to augment these kinds of informal collaborative activities, allowing people to engage with digital content that is pervasively embedded at these different locations.

Figure 6.32 Roomware furniture

Research and design issues

Early research on shareable interfaces focused largely on interactional issues, such as how to support electronically based handwriting and drawing, and the selecting and moving of objects around the display (Elrod et al, 1992). The PARCTAB system (Schilit et al, 1993) investigated how information could be communicated between palm-sized, A4-sized, and whiteboard-sized displays using shared software tools, such as Tivoli (Rønby-Pedersen et al, 1993). Since then, there has been continuing interest in developing more fluid and direct styles of interaction with large displays, both wall-based and tabletop, involving freehand and pen-based gestures (e.g. Shen et al, 2003). Ecologies of devices have been developed where groups can share and create content across multiple devices, such as tabletops and wall displays.

A key research issue is whether shareable surfaces can facilitate new and enhanced forms of collaborative interaction compared with what is possible when groups work together using their own devices, like laptops and PCs (see Chapter 4). One benefit is easier sharing and more equitable participation. For example, tabletops have been designed to support more effective joint browsing, sharing, and manipulation of images during decision-making and design activities (Shen et al, 2002; Rogers et al, 2009). Core design concerns include whether size, orientation, and shape of the display have an effect on collaboration. User studies have shown that horizontal surfaces compared with vertical ones support more turn-taking and collaborative working in collocated groups (Rogers and Lindley, 2004), while providing larger-sized tabletops does not improve group working but encourages more division of labor (Ryall et al, 2004). The need for both personal and shared spaces has been investigated to see how best to enable users to move between working on their own and together as a group. Several researchers have begun to investigate the pros and cons of providing users with complementary devices, such as iPods, digital pens, and other wall displays that are used in conjunction with the shareable surface. Tangible devices (see Section 6.2.16), such as blocks, pucks, and paper models, have also been designed to be used in conjunction with tabletops. An example of this mixed form of interface (described in Chapter 4) is the Reactable, which is an interactive tool for computer music performers. Design guidelines and summaries of empirical research on tabletops and multitouch can be found in Scott et al (2003), O'Hara et al (2003), and Müller-Tomfelde (2010).

6.2.16 Tangible

Tangible interfaces use sensor-based interaction, where physical objects, e.g. bricks, balls, and cubes, are coupled with digital representations (Ishii and Ullmer, 1997). When a person manipulates the physical object(s), it is detected by a computer system via the sensing mechanism embedded in the physical object, causing a digital effect to occur, such as a sound, animation, or vibration (Fishkin, 2004). The digital effects can take place in a number of media and places, or they can be embedded in the physical object itself. For example, Zuckerman and Resnick's (2005) Flow Blocks (see Figure 6.33) depict changing numbers and lights that are embedded in the blocks, depending on how they are connected together. The flow blocks are designed to simulate real-life dynamic behavior and react when arranged in certain sequences. Another type of tangible interface is where a physical model, e.g. a puck, a piece of clay, or a model, is superimposed on a digital desktop. Moving one of the physical pieces around the tabletop causes digital events to take place on the tabletop. For example, a tangible interface, called Urp, was built to facilitate urban planning; miniature physical models of buildings could be moved around on the tabletop and used in combination with tokens for wind and shadow-generating tools, causing digital shadows surrounding them to change over time and visualizations of airflow to vary (see Figure 6.33b).

Figure 6.33 (a) Tangible Flow Blocks designed to enable children to create structures in time that behave like patterns in life, e.g. chain reactions; (b) Urp, a tangible interface for urban planning where digital shadows are cast from physical models that are moved around the table surface to show how they vary with different lighting conditions

The technologies that have been used to create tangibles include RFID tags embedded in physical objects and digital tabletops that sense the movements of objects and subsequently provide visualizations surrounding the physical objects. Many tangible systems have been built with the aim of encouraging learning, design activities, playfulness, and collaboration. These include planning tools for landscape and urban planning (e.g. Hornecker, 2005; Underkoffler and Ishii, 1998). Another example is Tinkersheets, which combines tangible models of shelving with paper forms for exploring and solving warehouse logistics problems (Zufferey et al, 2009). The underlying simulation allows students to set parameters by placing small magnets on the form.

Tangible computing (Dourish, 2001) has been described as having no single locus of control or interaction. Instead of just one input device such as a mouse, there is a coordinated interplay of different devices and objects. There is also no enforced sequencing of actions and no modal interaction. Moreover, the design of the interface objects exploits their affordances to guide the user in how to interact with them. Tangible interfaces differ from the other approaches insofar as the representations are artifacts in their own right that the user can directly act upon, lift up, rearrange, sort, and manipulate.

What are the benefits of using tangible interfaces compared with other interfaces, like GUI, gesture, or pen-based? One advantage is that physical objects and digital representations can be positioned, combined, and explored in creative ways, enabling dynamic information to be presented in different ways. Physical objects can also be held in both hands and combined and manipulated in ways not possible using other interfaces. This allows for more than one person to explore the interface together and for objects to be placed on top of each other, beside each other, and inside each other; the different configurations encourage different ways of representing and exploring a problem space. In so doing, people are able to see and understand situations differently, which can lead to greater insight, learning, and problem-solving than with other kinds of interfaces (Marshall et al, 2003).

Research and design issues

Because tangible interfaces are quite different from GUI-based ones, researchers have developed alternative conceptual frameworks that identify their novel and specific features, e.g. Fishkin (2004) and Ullmar et al (2005). A key design concern is what kind of coupling to use between the physical action and effect. This includes determining where the digital feedback is provided in relation to the physical artifact that has been manipulated: for example, should it appear on top of the object (as in Figure 6.33a), beside it, or some other place. The type and placement of the digital media will depend to a large extent on the purpose of using a tangible interface. If it is to support learning then an explicit mapping between action and effect is critical. In contrast, if it is for entertainment purposes, e.g. playing music or storytelling, then it may be better to design them to be more implicit and unexpected. Another key design question is what kind of physical artifact to use to enable the user to carry out an activity in a natural way. Bricks, cubes, and other component sets are most commonly used because of their flexibility and simplicity, enabling people to hold them in both hands and to construct new structures that can be easily added to or changed. Sticky notes and cardboard tokens can also be used for placing material onto a surface that is transformed or attached to digital content, e.g. Klemmer et al (2001) and Rogers et al (2006).

Design guidance has so far been in terms of implications for using tangible interfaces for specific applications, e.g. learning (O'Malley and Stanton Fraser, 2005). An extensive overview of the area outlining the important research and design questions has been written by Shaer and Hornecker (2010).

6.2.17 Augmented and Mixed Reality

Other ways that the physical and digital worlds have been bridged include augmented reality, where virtual representations are superimposed on physical devices and objects, and mixed reality, where views of the real world are combined with views of a virtual environment (Drascic and Milgram, 1996). One of the precursors of this work was the Digital Desk (Wellner, 1993). Physical office tools, like books, documents, and paper, were integrated with virtual representations, using projectors and video cameras. Both virtual and real documents were combined.

Figure 6.34 Two augmented reality applications showing (a) a scanned womb overlaying a pregnant woman's stomach and (b) a head-up display (HUD) used in airline cockpits to provide directions to aid flying during poor weather conditions

To begin with, augmented reality was mostly experimented with in medicine, where virtual objects, e.g. X-rays and scans, were overlaid on part of a patient's body to aid the physician's understanding of what is being examined or operated on. Figure 6.34(a) shows an overlaid three-dimensional model of a fetus on top of the mother's womb. The aim was to give the doctor X-ray vision, enabling her to see inside the womb (Bajura et al, 1992). Since then augmented reality has been used to aid controllers and operators in rapid decision-making. One example is air traffic control, where controllers are provided with dynamic information about the aircraft in their section that is overlaid on a video screen showing the real planes landing, taking off, and taxiing. The additional information enables the controllers to easily identify planes that are difficult to make out – something especially useful in poor weather conditions. Similarly, head-up displays (HUDs) are used in military and civil planes to aid pilots when landing during poor weather conditions. A HUD provides electronic directional markers on a fold-down display that appears directly in the field of view of the pilot (see Figure 6.34(b)). Instructions for building or repairing complex equipment, such as photocopiers and car engines, have also been designed to replace paper-based manuals, where drawings are superimposed upon the machinery itself, telling the mechanic what to do and where to do it.

Another approach is to augment everyday graphical representations, e.g. maps, with additional dynamic information. Such augmentations can complement the properties of the printed information in that they enable the user to interact with geographically embedded information in novel ways. An illustrative application is the augmentation of paper-based maps with photographs and video footage to enable emergency workers to assess the effects of flooding and traffic (Reitmayr et al, 2005). A camera mounted above the map tracks the map's locations on the surface while a projector augments the maps with projected information from overhead. Figure 6.35 shows areas of flooding that have been superimposed on a map of Cambridge (UK), together with images of the city center captured by cameras.

Figure 6.35 An augmented map showing the flooded areas at high water level overlaid on the paper map. The handheld device is used to interact with entities referenced on the map

Augmented reality has also been developed for smartphone apps to aid people walking in a city or town. Directions (in the form of a pointing hand or arrow) and local information (e.g. the nearest McDonald's) are overlaid on a picture of the street the person holding the phone is walking in. Real estate apps have also been developed that combine an image of a residential property with its price per square meter. The directions and information change as the person walks or drives up the street. Some have argued that this kind of augmentation makes people spend most of their time glued to their smartphone rather than looking at the sites, and even causing logjams on the sidewalk. What do you think?

BOX 6.6

Larger than life: interactive installations and mixed reality games

A number of large interactive installations have been built in museums for visitors to have a user experience with a difference. Instead of entering a 3D virtual world they enter a 3D physical world that has been augmented with digital interfaces. An example is the healthy heart exhibition at the Franklin Institute in Philadelphia (see Figure 6.36), where a giant size model of the heart can be walked through presenting 3D sounds, lights, and video. One part is an eight-foot-long crawl through arteries device that enables children to pretend they are blood cells navigating through clear and clogged arteries.

Another form of interactive experience is mixed reality games that are played in a blend of physical and virtual worlds using novel interfaces. For example, the Hunting of the Snark adventure game (Rogers et al, 2002a) was designed as a series of interlinked mixed reality spaces intended to provoke children's imagination and creativity. Young children (8–10 years old) were given the task of finding out as much as they could about an elusive creature called the Snark, by interacting with it in various physical/digital spaces. For example, in the Snooper room they hunt for hidden virtual tokens that can then be transformed into physical counterparts that enable them to interact with the Snark. The physical tokens are used to feed the Snark at a well (see Figure 6.37), fl y with it in the air, or walk with it in a cave. The game was inspired by Lewis Carroll's poem in which a group of adventurers describe their encounters with a never really found fantasy creature. Similarly, in the Snark game, the Snark never shows itself in its entirety, only revealing aspects of itself, e.g. its likes/dislikes, personality, and so forth, depending on what the children do inthe different spaces.

Figure 6.36 The Healthy Heart interactive installation at the Franklin Institute

Figure 6.37 Two girls interacting with the Hunting of the Snark mixed reality game: the Snark registers disgust after having been fed a physical token of an onion

Research and design issues

A key research concern when designing mixed reality environments and augmented reality is what form the digital augmentation should take and when and where it should appear in the physical environment (Rogers et al, 2005). The information needs to stand out but not distract the person from his ongoing activity in the physical world. For example, ambient sounds need to be designed to be distinct from naturally occurring sounds so that they draw a person's attention without distracting him and then allow him to return to what he was doing. Information that is superimposed on the physical world, e.g. digital information overlaying video footage of a runway to identify vehicles and planes, needs to be simple and easy to align with the real-world objects.

It is important to understand how designing for playful learning experiences is very different from designing for military or medical applications. Ambiguity and uncertainty may be exploited to good effect in mixed reality games but could be disastrous in the latter categories. The type of technology will also determine what guidance will be of relevance. A guideline for the use of an optical see-through display, e.g. shutter glasses or head-mounted display, may not be relevant for a video see-through display. Likewise, a guideline for a mobile augmented reality solution may not be relevant for a fixed display application. Published design guidelines include Cawood and Fiala (2008) and Wetzel et al (2008).

6.2.18 Wearables

Imagine being at a party and being able to access the Facebook of a person whom you have just met, while or after talking to her, to find out more about her. The possibility of having instant information before one's very own eyes that is contextually relevant to an ongoing activity and that can be viewed surreptitiously (i.e. without having to physically pull out a smartphone) is very appealing. Since the early experimental days of wearable computing, where Steve Mann (1997) donned head and eye cameras to enable him to record what he saw while also accessing digital information on the move, there have been many innovations and inventions. New flexible display technologies, e-textiles, and physical programming (e.g. Arduino) provide opportunities for thinking about how to embed such technologies on people in the clothes they wear. Jewelry, head-mounted caps, glasses, shoes, and jackets have all been experimented with to provide the user with a means of interacting with digital information while on the move in the physical world. A motivation was to enable people to carry out tasks (e.g. selecting music) while moving without having to take out and control a handheld device. Examples include a ski jacket with integrated MP3 player controls that enable wearers to simply touch a button on their arm with their glove to change a track and automatic diaries that keep users up-to-date on what is happening and what they need to do throughout the day. More recent applications have focused on embedding various textile, display, and haptic technologies to promote new forms of communication and have been motivated by aesthetics and playfulness. For example, CuteCircuit develops fashion clothing, such as the KineticDress, that is embedded with sensors which follow the body of the wearer to capture their movements and interaction with others. These are then displayed through electroluminescent embroidery that covers the external skirt section of the dress. Depending on the amount and speed of the wearer's movement it will change pattern, displaying the wearer's mood to the audience and creating a magic halo around her. CuteCircuit also developed the Hug Shirt (see Chapter 4).

Research and design issues

A core design concern – that is specific to wearable interfaces – is comfort. Users need to feel comfortable wearing clothing that is embedded with technology. It needs to be light, small, not get in the way, fashionable, and (with the exception of the displays) preferably hidden in the clothing. Another related issue is hygiene – is it possible to wash or clean the clothing once worn? How easy is it to remove the electronic gadgetry and replace it? Where are the batteries going to be placed and how long is their life-time? A key usability concern is how does the user control the devices that are embedded in his clothing – is touch, speech, or more conventional buttons and dials preferable?

Two other major concerns are social acceptance and privacy. Is it acceptable in our society for people to be looking up other's details while talking to them and how do people feel about others recording their intimate conversations or taking photos of them without necessarily knowing this is happening and what happens subsequently to that information? .

6.2.19 Robots

Robots have been with us for some time, most notably as characters in science fiction movies, but also playing an important role as part of manufacturing assembly lines, as remote investigators of hazardous locations (e.g. nuclear power stations and bomb disposal), and as search and rescue helpers in disasters (e.g. fires) or far-away places (e.g. Mars). Console interfaces have been developed to enable humans to control and navigate robots in remote terrains, using a combination of joysticks and keyboard controls together with camera and sensor-based interactions (Baker et al, 2004). The focus has been on designing interfaces that enable users to effectively steer and move a remote robot with the aid of live video and dynamic maps.

Domestic robots that help with the cleaning and gardening have become popular. Robots are also being developed to help the elderly and disabled with certain activities, such as picking up objects and cooking meals. Pet robots, in the guise of human companions, are being commercialized, having first become a big hit in Japan. A somewhat controversial idea is that sociable robots should be able to collaborate with humans and socialize with them – as if they were our peers (Breazeal, 2005).

Several research teams have taken the ‘cute and cuddly’ approach to designing robots, signaling to humans that the robots are more pet-like than human-like. For example, Mitsubishi has developed Mel the penguin (Sidner and Lee, 2005) whose role is to host events while the Japanese inventor Takanori Shibata has developed Paro, a baby harp seal, whose role is to be a companion (see Figure 6.38). Sensors have been embedded in the pet robots enabling them to detect certain human behaviors and respond accordingly. For example, they can open, close, and move their eyes, giggle, and raise their flippers. The robots afford cuddling and talking to – as if they were pets or animals. The appeal of pet robots is thought to be partially due to their therapeutic qualities, being able to reduce stress and loneliness among the elderly and infirm (see Chapter 5 for more on cuddly robot pets).

Figure 6.38 Left: Mel, the penguin robot, designed to host activities; right: Japan's Paro, an interactive seal, designed as a companion, primarily for the elderly and sick children

Research and design issues

An ethical concern is whether it is acceptable to create robots that exhibit behaviors that humans will consider to be human- or animal-like. While this form of attribution also occurs for PC-based agent interfaces (see Chapter 2), having a physical embodiment – as robots do – can make people suspend their disbelief even more, viewing the robots as pets or humans. This raises the moral question as to whether such anthropomorphism should be encouraged. Should robots be designed to be as human-like as possible, looking like us with human features, e.g. eyes and mouth, behaving like us, communicating like us, and emotionally responding like us? Or should they be designed to look like robots and behave like robots, e.g. vacuum cleaner robots that serve a clearly defined purpose? Likewise, should the interaction be designed to enable people to interact with the robot as if it was another human being, e.g. talking, gesturing, holding its hand, and smiling at it, or should the interaction be designed to be more like human–computer interaction, e.g. pressing buttons, knobs, and dials to issue commands?

For many people, the cute pet approach to robotic interfaces seems preferable to one that aims to design them to be more like fully fledged human beings. Humans know where they stand with pets and are less likely to be unnerved by them and, paradoxically, are more likely to suspend their disbelief in the companionship they provide.

6.2.20 Brain–Computer

Brain–computer interfaces (BCI) provide a communication pathway between a person's brain waves and an external device, such as a cursor on a screen or a tangible puck that moves via airflow). The person is trained to concentrate on the task (e.g. moving the cursor or the puck). Several research projects have investigated how this technique can be used to assist and augment human cognitive or sensory-motor functions. The way BCIs work is through detecting changes in the neural functioning in the brain. Our brains are filled with neurons that comprise individual nerve cells connected to one another by dendrites and axons. Every time we think, move, feel, or remember something, these neurons become active. Small electric signals rapidly move from neuron to neuron – that can to a certain extent be detected by electrodes that are placed on a person's scalp. The electrodes are embedded in specialized headsets, hairnets, or caps (see Figure 6.39). Tan Le, in her 2010 TED talk, demonstrated how it is possible, using the Emotiv Systems headset, for a participant to move virtual objects, such as a cube, on a screen (see www.ted.com/talks/tan_le_a_headset_that_reads_your_brainwaves.html).

Figure 6.39 The Brainball game using a brain–computer interface

Brain–computer interfaces have also been developed to control various games. For example, a game called Brainball is controlled by players' brain waves in which players compete to control a ball's movement across a table by becoming more relaxed and focused. Other possibilities include controlling a robot and being able to fly a virtual plane by thinking of lifting the mind.

6.3 Natural User Interfaces

As we have seen, there are many kinds of interface that can be used to design for user experiences. The staple for many years was the GUI (graphical user interface) which without doubt has been very versatile in supporting all manner of computer-based activities, from sending email to managing process control plants. But is its time up? Will NUIs (short for natural user interfaces) begin to overtake them?

But what exactly are NUIs? A NUI is one that enables us to interact with a computer in the same ways we interact with the physical world, through using our voice, hands, and bodies. Instead of using a keyboard and a mouse (as is the case with GUIs), a natural user interface allows us to speak to machines, stroke their surfaces, gesture at them in the air, dance on mats that detect our feet movements, smile at them to get a reaction, and so on. The naturalness refers to the way they exploit the everyday skills we have learned, such as talking, writing, gesturing, walking, and picking up objects. In theory, they should be easier to learn and map more readily onto how we interact with the world than compared with learning to use a GUI. For example, as Steve Ballmer, CEO of Microsoft, notes:

I believe we will look back on 2010 as the year we expanded beyond the mouse and keyboard and started incorporating more natural forms of interaction such as touch, speech, gestures, handwriting, and vision – what computer scientists call the ‘NUI’ or natural user interface. (Ballmer, 2010)

Instead of having to remember which function keys to press to open a file, a NUI means a person only has to raise their arm or say ‘open’. But how natural are NUIs? Is it more natural to say ‘open’ than to flick a switch when wanting to open a door? And is it more natural to raise both arms to change a channel on the TV than to press a button on the remote? Whether a NUI is more natural than a GUI will depend on a number of factors, including how much learning is required, the complexity of the application/device's interface, and whether accuracy and speed are needed (Norman, 2010). Sometimes a gesture is worth a thousand words. Other times, a word is worth a thousand gestures. It depends on how many functions the system supports.

Consider the sensor-based faucets that were described in Chapter 1. The gesture-based interface works mostly (with the exception of people wearing black clothing that cannot be detected) because there are only two functions: (i) turning on by waving one's hands under the tap, and (ii) turning off by removing them from the sink. Now think about other functions that faucets usually provide, such as controlling water temperature and flow. What kind of a gesture would be most appropriate for changing the temperature and then the flow? Would one decide on the temperature first by raising one's left hand and the flow by raising one's right hand? How would we know when to stop raising our hand to get the right temperature? We would need to put a hand under the tap to check. If we put our right hand under that might have the effect of decreasing the flow. And when does the system know what the desired temperature and flow has been reached? Would it require having both hands suspended in mid-air for a few seconds to register that was the desired state? We would all need to become water conductors. It is hardly surprising that such a system of control does not exist – since it simply would not work. Hence, the reason why sensor-based faucets in public toilets all have their temperature and flow set to a default.

This caricature illustrates how it can be more difficult to design even a small set of gestures to map onto a set of control functions, which can be accurately recognized by the system while also readily learnt and remembered by the general public. It also highlights how gestural, speech, and other kinds of NUIs will not replace GUIs as the new face of interaction design. However, it does not mean they will not be useful. They are certainly effective and fun to do when controlling and manipulating digital content in a number of tasks and activities. For example, using gestures and whole body movement has proven to be highly enjoyable as a form of input for many computer games and physical exercises, such as those that have been developed for the Wii and Kinect systems. Furthermore, new kinds of gesture, speech, and touch interfaces have proven to be very empowering for people who are visually impaired and who have previously had to use specialized tools to interface with GUIs. For example, the iPhone's VoiceOver control features enable visually impaired people to send email, surf the net, play music, and so on, without having to buy an expensive customized phone or screen reader. Moreover, being able to purchase a regular phone means not being singled out for special treatment, which can be liberating, as noted by Sandi Wassmer (2009) in her blog. And while some gestures may feel cumbersome for sighted people to learn and use they may not be for blind or visually impaired people. The VoiceOver press and guess feature that reads out what you tap on the screen (e.g. ‘messages,’ ‘calendar,’ ‘mail: 5 new items’) can open up new ways of exploring an application while a three finger tap can become a natural way to turn the screen off. But although NUIs will certainly become more pervasive, the GUI will remain a powerful mode of input.

6.4 Which Interface?

In this chapter we have given an overview of the diversity of interfaces that is now available or currently being researched. There are many opportunities to design for user experiences that are a far cry from those originally developed using command-based interfaces in the 1980s. An obvious question this raises is: but which one and how do you design it? In many contexts, the requirements for the user experience that have been identified during the design process (to be discussed in Chapter 10) will determine what kind of interface might be appropriate and what features to include. For example, if a healthcare application is being developed to enable patients to monitor their dietary intake, then a mobile device – that has the ability to scan barcodes and/or take pictures of food items that can be compared with a database – would appear to be a good interface to use, enabling mobility, effective object recognition, and ease of use. If the goal is to design a work environment to support collocated group decision-making activities then combining shareable technologies and personal devices that enable people to move fluidly between them would be a good choice.

But how do we decide which interface is preferable for a given task or activity? For example, is multimedia better than tangible interfaces for learning? Is speech as effective as a command-based interface? Is a multimodal interface more effective than a monomodal interface? Will wearable interfaces be better than mobile interfaces for helping people find information in foreign cities? Are virtual environments the ultimate interface for playing games? Or will mixed reality or tangible environments prove to be more challenging and captivating? Will shareable interfaces, such as interactive furniture, be better at supporting communication and collaboration compared with using networked desktop PCs? And so forth. These questions are currently being researched. In practice, which interface is most appropriate, most useful, most efficient, most engaging, most supportive, etc., will depend on the interplay of a number of factors, including reliability, social acceptability, privacy, ethical, and location concerns.

Assignment

In Activity 6.4 we asked you to compare the experience of playing the game of Snake on a PC with playing on a cell phone. For this assignment, we want you to consider the pros and cons of playing the same game using different interfaces. Select three interfaces, other than the GUI and mobile ones (e.g. tangible, wearable, and shareable) and describe how the game could be redesigned for each of these, taking into account the user group being targeted. For example, the tangible game could be designed for young children, the wearable interface for young adults, and the shareable interface for elderly people.

a. Go through the research and design issues for each interface and consider whether they are relevant for the game setting and what issues they raise. For the wearable interface, issues to do with comfort and hygiene are important when designing the game.

b. Describe a hypothetical scenario of how the game would be played for each of the three interfaces.

c. Consider specific design issues that will need to be addressed. For example, for the shareable surface would it be best to have a tabletop or a wall-based surface? How will the users interact with the snake for each of the different interfaces; by using a pen, fingertips, or other input device? Is it best to have a representation of a snake for each player or one they take turns to play with? If multiple snakes are used, what will happen if one person tries to move another person's snake? Would you add any other rules? And so on.

d. Compare the pros and cons of designing the Snake game using the three different interfaces with respect to how it is played on the cell phone and the PC.

Summary

This chapter has given an overview of the diversity of interfaces that can be designed for user experiences, identifying key design issues and research questions that need to be addressed. It has highlighted the opportunities and challenges that lie ahead for designers and researchers who are experimenting with and developing innovative interfaces. It has also explicated some of the assumptions behind the benefits of different interfaces – some that are supported, others that are still unsubstantiated. It has presented a number of interaction techniques that are particularly suited (or not) for a given interface type. It has also discussed the dilemmas facing designers when using a particular kind of interface, e.g. abstract versus realism, menu selection versus free-form text input, human-like versus non-human-like. Finally, it has presented pointers to specific design guidelines and exemplary systems that have been designed using a given interface.

Key points

· Many interfaces have emerged post the WIMP/GUI era, including speech, wearable, mobile, and tangible.

· A range of design and research questions need to be considered when deciding which interface to use and what features to include.

· So called natural user interfaces may not be as natural as graphical user interfaces – it depends on the task, user, and context.

· An important concern that underlies the design of any kind of interface is how information is represented to the user (be it speech, multimedia, virtual reality, augmented reality), so that they can make sense of it with respect to their ongoing activity, e.g. playing a game, shopping online, or interacting with a pet robot.

Web Usability

Although HCI principles apply equally well to both graphic user interfaces and Web interface design, there are significant differences between GUIs and the Web. There are several unique Web features to which GUI-experienced usability designers should pay particular attention. Among the more prominent are compatibility with device and browser diversity, user-initiated and -controlled navigation, and low cost of switching between sites. Other Web-specific factors include multiple points of page entry into a site, ease of being distracted with the enormity of information available, and the easy ability to personalize what visitors want to see.

In a course I teach to professional developers on Web usability, I asked a group of 15 participants, who were experienced in both GUI and Web design, to brainstorm about the differences between GUIs and the Web that should concern designers. Here are the ten most important differences the group identified.

1. The Web is less secure.

2. There is less privacy on the Web.

3. The Web is platform independent.

4. Web sites contain more dynamic content.

5. The Web has a broader audience.

6. Web devices and browsers have compatibility problems.

7. Users have different expectations for the Web.

8. Learning is expected with GUIs, but not with the Web.

9. There is more than one entry point into a site on the Web.

10. Navigation is user controlled on the Web.

In addition to understanding the differences between GUI and Web design environments, usability designers should pay particular attention to the predominant and recurring usability problems infesting the World Wide Web. In the same usability course, I asked participants to name the ten most important Web design problems. They were first asked as a group to generate a list of problems. Then the 15 participants voted on what they considered to be the most important problems.

1. The Web end user is not considered; the design is not user centered.

2. It is slow due to large multimedia files and useless Java scripts and plug-ins.

3. The information is disorganized and poorly structured.

4. There is a lack of standards and consistency.

5. “Design” consists of showing off technology.

6. Designers treat the Web as a brochure.

7. Pages are cluttered.

8. Developers do not maintain and update sites.

9. Pervasive banner ads are annoying.

10. Page layout is poor.

Designing usable Web sites requires more attention to context than designing usable GUIs. Sensitivity to the factors that surround user interaction with the Web takes on added importance because of the ease with which users can turn off one site and put on another. As Web usability designers, we must make sure not only that the interaction is simple but also that the user feels comfortable in the physical, mental, and emotional environment of the interaction. The Web interaction context can be as small as a page or as large as the physical, cognitive, social, and emotional surrounds of the user in the act of using the Web.

Furthermore, providing the right functionality forms the essence of a usable Web site. As designers we must recognize that the usability quality of a Web interface diminishes and becomes insignificant if the site does not support the tasks that users want to perform or does not provide the information for which visitors are searching.

Web Usability Strategy

Chapter 2. Web Usability Strategy

People often ask me either to design a “usable” Web site or to review one and make comments and recommendations on its usability. My first step is to generate all the realistic scenarios of use we can either construct or envision. In creating such scenarios, a designer specifies interface objects and actions for given contexts from the perspective of the user. Identifying relevant design objects for given contexts, as well as specifying user actions from a human-centered perspective, is at the core of what I call the “userview” process.

Specifying context is important to the Web design process because context helps us understand how objects within a universe of discourse relate to each other to form a coherent whole and provides us with a framework in which to relate objects to their surrounding environments. Focus on the user early in the design process produces user-centered Web design. Let's examine more carefully the three design concepts of scenario, context, and userview.

Scenarios

To create successful scenarios, we first must answer four questions.

1. Where and under what conditions will the Web site be used?

2. For what purpose will the site be used?

3. Who will use the site (the target audience)?

4. How will the site be used?

There may be many answers to each question. The permutations of the different combined answers constitute all the possible scenarios. Some combinations are naturally more realistic than others. A good designer is able to weed out the unsuitable ones.

As an example, let's say you want to design a Web site for a museum. Two different scenarios for the site are (A) a kiosk situated in the museum's entrance lobby to be used by visitors to get information, survey special exhibits, and print out spatial directions, using touch screen and 3-D spatial navigation, and (B) a Web site for local people who can use Web TV remote controls at home to get information on museum exhibits. For scenario A, these are the answers to the preceding four questions.

1. Kiosk in the museum

2. To get information and print directions

3. Museum visitors

4. Touch selection and VRML spatial navigation

For scenario B, the answers are the following.

1. Television at home

2. To get information on exhibits

3. Families at home in the museum's locale

4. Selection and navigation using TV remote control

Of course, by changing only one of the answers each time, many other scenarios are possible.

Context

Scenario development helps us envision the objects and actions needed for design. Context is the relationship of these objects and actions to each other and to their environments. “The weaving together of parts into a coherent whole” describes the object's relationship to other objects. This is an important sense of context in Web design because it addresses the issue of how information should be organized. For example, it determines the placement on a Web page of a label relative to a field or a header to text—that is, the spatial placement of objects that are semantically close (similar in meaning) to each other.

A second essential way in which to define the context of an object for Web site design is to view context as “that which surrounds the object.” In this sense, context can be either cognitive or physical. For example, cognitively, the context of a word is a function of the sentence containing the word. An example of physical context is a book on a shelf of books in the library. The other books and the library are both contexts in that they surround the target book. As we will see in Chapter 3, the union of physical and cognitive contexts is quite important to Web design.

In Web site design we must also consider an object's relationships to many environmental levels, which can be represented as ever-larger concentric circles. Figure 2.1 is a graphic example of the environmental context of a jar of Folgers decaffeinated coffee. The Folgers jar is in the section of decaffeinated coffees, which is in the coffees section. The coffees are on the aisle containing coffees and teas, which is in the dry foods area, which is in the supermarket.

Figure 2.1. Context as that which surrounds

A cognitive example of context as “that which surrounds” an object is the selection of words to convey meaning. Here we need to consider the relationship of the word we select to the sentence, the paragraph, the document, the topic, the field of specialization, and the reading audience. Each of these environments, starting with the sentence, is a successively larger context in which to consider the choice of words to use.

In our design philosophy, the largest context is assigned the highest precedence for consideration. For example, to convey the meaning, “an area of cleared, enclosed land used for pasture,” we should not use the word field if the Web site audience is primarily athletes. For an athletic audience, the predominant meaning of the word field is “an athletic or sports area.” We know that when we read a sentence, we process predominant meanings first and then consider secondary meanings (Foss, 1970; Cairns and Kamerman, 1975). If a word has a meaning other than the predominant one for members of the intended audience, then it will take longer to process the sentence. The point of this example is that there are costs associated with not considering the environments in which the objects of design reside.

Using a contextual strategy to design Web sites requires us to consider five levels of design context:

· The environment context

· The user context

· The genre context

· The site context

· The page context

Designing contextually for each level means considering not only how objects relate to each other on any given level but also how the contexts relate to each other generally.

Figure 2.2 shows levels represented as concentric circles where design decisions made in the larger circle supersede those made in the smaller ones. This order of supersession is fundamental to the strategy of contextual design. The extrinsic design context refers to the actual physical and cognitive spaces in which users visit a Web site. The user context refers to the audience requirements, such as Web user cultural constraints or a user's physical limitations. The genre context specifies the type of site, such as news media, tourism, or shopping. The site context refers to the user, or human, interface relating to characteristics such as site navigation and organization. The page context addresses design constraints inherent in a single page.

Figure 2.2. Contextual order of supersession for design decisions

Design decisions made at higher levels supersede decisions made at any lower level. Let's say we are designing a tourism site. In the tourism genre, the proportion of graphics to text is high on a given page. If we are designing for a culture where information is usually conveyed textually, then this user constraint of textual pages would supersede the tourism genre characteristic of a high proportion of graphics.

Using another museum scenario example, we start by considering design decisions relative to the location where the Web site will be used. If we determine that the site is intended to be used mostly in K–12 classrooms, then the environment context suggests that the visitors to the site will be groups of children rather than individuals. This “group” characteristic carries with it a certain set of constraints that will impact how to design interaction and navigation at the site level. Under such constraints, the designer may have to consider using voice, video, audio, and possibly a remote control. The “group usage” characteristic will also require that pages be designed with relatively large objects that can be seen from a group distance. The museum genre context will call for a site with color graphics and possibly spatial navigation, even though for the sake of simplicity we recommend that the designer avoid 3-D elements for navigation at the site level and avoid graphics at the page level. Here the design decision at the genre level supersedes those at the site and page levels.

The Userview Process

The contextual approach to Web design is concerned mainly with how successively larger, more encompassing contexts relate to each other and to design objects. Within any given context, we need a systematic strategy that allows us to specify design solutions. That strategy is grounded in the human-centered approach (Norman, 1986) to designing usable interactive systems. The general methodology consists of a sequence of tasks that a designer performs in defining the Web user interface and implementing site usability. It also involves iterative modifications and compromises. The process derives from the following set of accepted usability design principles of practice (Gould, 1988; Whiteside et al., 1988).

User-centered approach. Defining the user culture—including user characteristics and types, a user level of expertise, and user task descriptions—is a prerequisite to Web interface development and testing. Methods for user-centered designs range from user interviews and observations to videotaping users as they work and administering attitude and information surveys.

Early human factors input. Consideration should be given to the human factors and user interface design guidelines very early in the process. Usability guidelines come from three sources: results from experimental human behavior research, accepted conventions of practice, and consensus of experts. It is easier and less costly to introduce human factors and user interface design constraints in the early stages of development.

Iterative design. The iterative design process for developing Web interfaces (see Figure 2.3) stems from the knowledge that “first designs,” no matter how well founded in experience and background, contain unanticipated flaws. Iterative interface designers start by profiling the audience and performing task analysis. Developing and implementing a prototype of the design, based on guidelines, principles, and examples, follows. Depending on the environment, the prototype is presented to the user for testing and feedback. During subsequent testing rounds, the interface is refined and changed according to the results of the analyses.

Figure 2.3. The iterative development cycle

Continuous testing. Usability evaluation should begin very early in Web site development and continue throughout the process. In the early phases, testing involves focus groups, interviews, and questionnaires. This stage is followed by storyboard paper designs, simulations, and prototypes. In later stages, usability evaluations involve lab tests, field testing, and sequential data analysis.

Integrated design. Certain questions need to be considered simultaneously at the very start of the process and on a continuing basis because of their interdependency in formulating a cohesive usability design. Designers should focus initially and concurrently on the following questions: (1) What functions does the user need to perform the tasks? (2) How should the user be allowed to invoke those functions? (3) How should we tell the user how to invoke the functions?

Figure 2.4 depicts the structure of the systematic and repeatable user view process. We start by generating four Web design documents. The first is a discovery document, which specifies the Web site's projected functionality and goals. The results of this discovery will help us generate a second document that specifies the user culture and a third that establishes Web interface design guidelines and human factors principles specific to the Web application under development. The fourth document, which defines a comprehensive usability plan, comes early in the userview process. This document takes established usability evaluation techniques, data collection methods, and measuring instruments and adapts them to the current development project.

Figure 2.4. The userview process for Web site design

The next sequence of steps uses the generated documents to specify a storyboard representation of the design, construct an interactive prototype, and build the first version of the Web site. Throughout this process, we will implement the specialized usability evaluation plan, which will be detailed in Chapter 12. As you can see in Figure 2.4, we collect data and conduct usability evaluation using different techniques for the different stages of the userview process.

Goals and Requirements

Each Web site development project begins with a goal in mind: for example, to gain exposure, to increase efficiency, or to do something better via the Internet. Coupled with this motivation is a set of perceived needs that the Web site could fulfill. The transformation of these vague needs to a requirements specification document for the Web is a complex process.

Our initial task of scenario making is an informal activity of specifying goals, functionality, audience, and conditions of use via discussions with the Web site procurer or owner. Then, in a more formal process, we develop the requirements discovery document needed at the outset of the userview process. A requirements definition is a statement in a natural language of what user services the Web site should provide. We call this goals and functionality document a discovery document because, as designers, we have the task of discovering client objectives and what the client would like Web site visitors to accomplish. The document should be geared to the customers (users) of the Web site to facilitate corrections and additions. It is a formal statement specifying user services and Web site functionality in more detail than what is in the scenario specification and with enough precision to serve as a contract between system procurer and Web site developer.

As we know from software engineering practice, the need for a functional requirements specification arises from the lack of verifiability of natural language documents. Although as Web designers we should make every effort to write complete, consistent, and unambiguous requirements definitions, there is no formal way to verify the adequacy or correctness of the result. Functional requirements specifications, on the other hand, rely on a formalism that we can validate by checking consistency, completeness, and correctness. Both documents, natural language and formal, should only specify external behavior. In other words, at this point in the userview process, the requirements specify what the system should do, not how it should do it. We deal with the how issues as we specialize Web interface design guidelines to user culture.

Requirements, which we must be able to test to ensure that they are met by the final Web site implementation, fall into two major categories: functional and nonfunctional. Functional requirements specify what the Web site should do, such as what services it should provide. Nonfunctional requirements set constraints and standards for the system. For example, a nonfunctional standard could be a requirement that the maximum system response time be no more that two seconds.

As an example of defining goals and requirements, consider being commissioned to develop a Web site for a fast-food business with delivery service. This is a regional chain of brick and mortar hamburger restaurants that wants to establish an online order and delivery service via the Internet. The goal for the Web site is to enlarge the customer base by making it more convenient for customers to order food. This high-level goal can be broken down into subgoals in two categories: general goals, affecting the operation of each store as a whole, and user-specific goals, designed to meet the needs of different user groups.

General Goals

General goals affect the operation of the virtual restaurant as a whole or the relationships between entities in the restaurant. Here are some examples.

· To provide consistent information for all users of the Web site

· To provide accurate and reliable information to all Web site users

· To provide reliable and continuous access to information for all the Web site users

· To provide Web site users with a communication tool that is effective for the tasks performed in the actual store

· To optimize the resources (time, staff, or others) used to perform an operation in the store

· To promote activities and operations that, without a Web site, are not possible, feasible, or practical in existing stores

User-Specific Goals

Such goals are set to meet the demands of different user groups. The concept and assessment of these demands are covered in Chapter 4, but let me point out here that the needs of different user groups for a given Web site may sometimes conflict. For example, it is reasonable to assume that there are at least two kinds of fast-food consumers: health-aware people and those who only want speed and convenience. Within those groups there are repeat customers, who know what they want and are looking for a fast text index search, and people interested in meandering through a visual, graphic presentation of the various foods. Conflicting needs among users have to be identified during the audience definition and task analysis stages, then solved by a decision process that will affect the design of the final product.

Requirements are the basis for the development of a system and are defined after a study of the goals of the system. Although a task analysis or a complete audience definition may not be necessary for the requirements definition, requirements should be set forth with end users and tasks in mind.

Functional Requirements

These describe the desired functions of the Web site. Not every type of user needs to perform every function. For example, customers need not, and should not, set the prices of products offered by the store. We start by listing some high-level functional requirements. Here are some of the functions for the fast-food ordering Web site.

1. Indicate the location of a store in the user's zip code area.

2. Give navigation directions for people who want to go to the store to order or pick up in person.

3. Identify specials of the day.

4. Offer orders by groups of items (a meal).

5. Allow a user to browse through the entire selection of individual foods and order any single item or combination of items.

6. Allow users to select delivery to a specific location or pick up at the store.

7. Handle the complete purchase transaction process, from information to selection to payment.

8. Permit advance ordering, specifying time and date.

9. Look for sales and promotional offers.

10. Announce new stores in various locations and changes in existing stores.

11. Announce the past or future closing of stores.

12. Allow store managers to enter information about their products, prices, sales, and promotions.

The preceding requirements are only high-level requirements and are meant to illustrate the types of functions available on the Web site. In an actual requirements definition document, much more detail would have to be provided about each requirement, which should be made complete, consistent, and nonambiguous. Terminology in the requirements document should be clearly defined in a glossary. Box 2.1 outlines the features of a requirements document. In this brief requirements presentation, my goal is simply to provide you with an overview of the system requirements and to emphasize the importance of the need for the development of a good requirements document. For further details on the elaboration of a good requirements document, see Davis (1993).

The preceding functional requirements are not needed by or meaningful to all users of the Web site. The matrix in Table 2.1 indicates which of the 12 functional requirements are important for each of two user categories. The principles illustrated by the use of these two user categories are generic ones that hold in other situations.

Nonfunctional Requirements

Nonfunctional requirements express constraints to be imposed upon the final system. Although they are important, and a good definition of nonfunctional requirements is key to a successful system design, their importance is often downplayed because of the difficulty in transforming nonfunctional requirements into design features using a procedural process.

Nonfunctional requirements for a fast-food ordering site are numerous. The following brief list gives an idea of the types of nonfunctional requirements at play.

· Users must feel that they are deriving a benefit by using the Web site.

· The costs of developing and maintaining the operation of the Web site should not exceed the benefits derived from its introduction.

· The Web site should be easily accessible by customers.

· The site should be accessible from a home or office computer, a PDA, and an in-store kiosk.

Box 2.1: A Web Site Goals and Functional Requirements Document

A requirement document should have the following structure.

Introduction: This section should describe the motivation, need, and objectives for the Web site. It should place the Web site in context, briefly describing its functions and presenting a rationale for it. It should describe how the system fits into the overall strategic objectives of the organization commissioning the Web site.

The Web site model: This section should set out the contextual model showing the relationships between the Web site components and its environment.

Functional requirements: The functional requirements of the system should be described in this section.

Hardware: The hardware and its interfaces should be described here.

Information structure requirements: The logical organization of the data used by the Web site and its interrelationships should be described here.

Nonfunctional requirements: This section describes the nonfunctional requirements of the Web site.

Maintenance information: This section should describe the fundamental assumptions on which the Web site is based and describe anticipated changes due to hardware evolution, changing user needs, and so forth.

Glossary: This section should define all the technical terms used in the document.

Index: A variety of indices (alphabetic, functions, etc.) is desirable.

These nonfunctional requirements, though general, should encourage Web site developers to consider such constraints early on when designing and building a Web site.

Table 2.1. Functional Requirements and User Groups
Requirement	Customer	Manager
R1: Locate store	✓
R2: Provide directions		✓
R3: Search for an item	✓
R4: Compare prices	✓	✓
R5: Browse	✓
R6: Order and purchase	✓
R7: Advance ordering	✓
R8: Window shopping	✓
R9: Looking for sales	✓
R10: New stores	✓	✓
R11: Closing stores	✓	✓
R12: Data entry		✓

User Culture

Knowing the users, their environment, and the activities or tasks is crucial to the design of Web sites. Also, understanding how users represent the activity in a brick and mortar context is prerequisite to designing that activity for the Web. We collect information about users, tasks, and user environment by conducting structured interviews, administering questionnaires, and observing users engaged in similar real-world activities. Chapter 12 covers the elements of Web site usability evaluation, including how to collect, validate, and apply user culture data.

Audience

Designers should not rely on their own preferences and experiences when designing Web sites but should identify the target users of the site and design with their needs and characteristics in mind. The audience definition should identify the appropriate characteristics, as well as specific individual differences, that may impact the interface design. Identifying the target audience also facilitates the selection of representative samples for evaluating the usability of the site. Important differences exist in people's experiences, abilities, backgrounds, motivations, personalities, and work styles. A well-designed Web site should accommodate this inherent heterogeneity, a topic treated comprehensively in Chapter 4.

Writing an audience definition starts with considering general categories of user characteristics and requirements and general questions that apply regardless of the Web application at hand. As an example, for the category of “user experience,” standard generic questions deal with issues such as computer experience, Web experience, past use of various interactive technologies, and application domain experience. In addition, for any specific Web site, we need to specialize the general categories. In the case of the fast-food ordering site, the “domain experience” user category leads to answering questions such as these:

· What frequency of customers are first timers versus repeaters?

· What do customers order?

· How often do they change what they order?

· Is there a relationship between customers' orders and repetition frequency?

· Who orders lunch, breakfast, and dinner?

· Do people eat in the restaurant or take out?

· Do people order individually or in groups? When in groups, are they mostly adults, adults with children, for lunch, dinner, and so on?

· Are they office workers at lunch and families in the evening?

· Do customers of a rural store have requirements different from suburban or urban customers?

These are only some possible questions dealing with the “user experience” category as applied to the domain of fast-food ordering. We collect information of this kind via focus groups, structured questionnaires, and field observations.

Environment

As part of specifying the user culture, we need to understand the details of the user's external environment. Designers should specify constituents based on the environment from which the users access the site. The home, the office, and mobile environments are very different ones, potentially leading to different uses of a given Web site and therefore different interface designs.

For the fast-food ordering site, customers logging on from home in the evening are most likely interested in dinner foods. Under these conditions the design should highlight the dinner aspect of the Web presentation. A midday order from a customer in an office may call for designing a Web interface that facilitates group orders. An order from a mobile customer in the morning might mean that the customer will stop and pick up the order on the way to work. Unlike an office order, a midday home or mobile order may mean the customer will be coming in to eat at the restaurant. In that case, a menu tailored to sit-down customers should be made available as a first priority on the Web page.

The kind of user interface may also be affected by the location of the customer. From home, people may have the time to browse a visual presentation; from the office, where the pace is faster, we may need to provide a text-only option; from the car, an auditory interface is desirable. Chapter 3 contains a comprehensive treatment of the Web environment.

Task Analysis

Defining user culture depends, along with other components, on identifying and understanding user tasks. Designers should know what tasks or activities the users will perform and how, as well as how often they perform each task. The purpose of task analysis is to determine the functionality of the Web site by decomposing functions into tasks and subtasks that the user performs while using the site. Designers should pay particular attention to the categories of frequent tasks, occasional tasks, exceptional tasks, and errors. The process of conducting this analysis educates designers about the sequences of events that a user may undergo to accomplish a task. An identification of goals and the strategies (combinations of tasks) used to reach those goals is also part of a good task analysis.

We perform task analysis with varying emphases and detail. A transaction-oriented task analysis is intended to identify times and other statistics associated with different components of a transaction. On the other hand, a user-oriented task analysis takes into account the various cognitive aspects of interaction, attempting to identify specific problems associated with Web interaction. Whether the analysis is transaction-oriented or user-oriented, we typically perform it in two stages. First, we identify goals, strategies, and the activities performed. Second, we give structure in order to analyze the information to uncover deficiencies and sources of inefficiency and to suggest improvements.

Task Identification

We usually design Web sites either to create a new service or to augment or replace a set of activities now being done in a physical environment, so it is important to start by identifying and analyzing how people perform similar tasks in equivalent or related environments. Techniques a designer can use include automatic event logging, verbal protocols, video, natural observation, and other methods. To illustrate task identification and analysis using the fast-food Web site, here is a brief description of the observation technique.

The goal of observation is to isolate and identify the components and structure of a task in situations relevant to human interaction with the Web site under development. A good selection of real-world environments and tasks to observe is critical to the success of the task identification and ideally should include all of the following.

· People performing the same or similar tasks manually

· People performing the same or similar tasks using other Web sites or computer systems

· People using other Web sites that they visit frequently

· People using systems that share common properties with the new Web site

· People working in an environment similar to the one where the new Web site will be installed

Natural observation of how people order fast food means using the actual fast-food restaurant to identify and study the tasks. The first step is to do on-site videotaping of customers' food selection and ordering activities with the customers' knowledge. We can do this by installing a video camera in the ceiling above the counter where customers place their orders. The tasks are then decomposed and identified. Task sequences and frequencies from the videotape are transcribed, and the data is then analyzed using statistical analysis routines.

We conduct a transaction-oriented task analysis to obtain, for example, such information as average times, percentages, and perhaps distributions related to task performance. We correlate the information with data collected from customers via questionnaires and from store workers via structured interviews. For instance, from the questionnaires, we can find out how often a customer orders from the restaurant. Then the frequency of repetitions can be correlated with order content or with the time it takes to perform the ordering task, information that we derive from an analysis of the videotape. Using these findings, we can make decisions about a look and feel as well as an interaction style to accommodate different levels of customer experience.

Task Structuring

The second stage of task analysis is structuring the information we identified in the first stage. A range of techniques exists to accomplish this, from less restrictive and informal methods to highly organized and structured formal ones.

Hierarchical decomposition of tasks into subtasks is by far the most popular representation of tasks. High-level tasks are decomposed into tasks of a lower level, which, in turn, are further decomposed until no more decomposition is necessary (atomic actions). A “tree” structure of tasks is created in this way, and, though simple and strong, this representation fails to account for important features such as decisions, individual differences, and errors. Figure 2.5 shows a hierarchy example for a portion of the fast-food ordering task.

Figure 2.5. Task structuring for foodrightnow.com

The Users' Task Representation Analysis

Once we have gained an understanding of the target audience, the next goal is to use those findings to determine what tasks the Web site should perform. Our focus remains on the target audience, however, because it is crucial to understand what our target users think the Web site should do and how they model those processes mentally. Several activities are necessary to accomplish this goal. First, the functional needs of users must be ascertained and analyzed. Specifically, we need to answer the question “In what way and in what sequence are customers most likely to use the Web site to perform tasks?” For fast food ordering, for example, do they first look at a menu, or do they just order what they already had planned?

The second step is to understand how users model these tasks. How do they describe the tasks? What common terms or analogies do they employ? Even if their models are difficult to implement, they should be incorporated into the design. Essentially, we want to design a metaphor for the Web site that our users will recognize and understand. For instance, at shopping Web sites, a common metaphor is the shopping cart or shopping bag. In the case of the fast-food customers, do they think of the food items as a menu of single items, or do they represent the items as a selection of plates of food or meals? An understanding of the most likely mental model could affect how we present the items on the Web page.

To gain an understanding of how potential site visitors represent the tasks at hand, we use techniques that include controlled experimentation, thinking-aloud methods, and structured interviews where the users are encouraged to describe the tasks they are performing. We should pay particular attention to their terminology and analogies and incorporate these into our designs.

Web Interface Guidelines Specialization

Usability guidelines for Web interface design come from three main sources: psychological research, convention, and consensus of expert practitioners.

These can be found in style guides, Web design handbooks, professional and trade journal articles, textbooks, and usability Web sites. Guidelines are usually general and need to be specialized to the particular application and predefined user culture. Box 2.2 shows examples of some Web usability guidelines.

Box 2.2: Selected Web Design Guidelines

· Page layouts should be consistent.

· Minimize the need for scrolling.

· Use text links for easy navigation.

· Users should be able to reach goal in minimum number of clicks.

· Provide links to navigation aids such as content, index, site map, and home page from every page in the site.

· Navigational buttons should be available on both the top and bottom of every page.

· Make sure there is a distinction between a list of contents on a page, links to other pages, and links to other sites.

· All links of a given type should have the same default characteristics such as color, underlining, type, font, and so forth.

· Minimize the use of graphics for sites where the purpose is to complete a transaction; graphics are too slow to download.

· Provide a text-only option.

· If graphics must be used, use small images, and repeat them if possible.

· In using graphics, minimize the number of colors.

· Do not use more than six colors for information coding on a single screen.

· A home page should fit on one screen. Avoid the requirement to scroll.

· On a page where reading is necessary, do not use flashing or motion because this can interfere with reading.

· Patterned backgrounds make it difficult to read text.

· Use consistent terminology.

· Provide on every page navigational aids for returning to previous page and to home page.

The use of guidelines is an important first step in the iterative design process. Specializing general guidelines in the context of a specific Web site reduces the number of potential iterations required to finalize the design of a Web site before fielding it. Let's consider the fast-food example for the guideline that users should be able to reach their goal in a minimum number of clicks. If in studying the audience and the users' task representation we discover that the frequent customers' mental model of their order is a meal representation instead of a menu of individual items, then by designing for clusters of items we reduce the number of clicks.

Constructing Storyboards and Interactive Prototypes

There are a variety of ways to model a hypothetical Web site. One approach that I advocate and use is the storyboard, a device that is common in many fields such as filmmaking and choreography. Specific plans—whether for a film or play scene or a dance sequence (Andriole, 1988)—are represented in a succession of sketches. We use this sketching technique in user interface and Web site design to show the prototypical content of pages and how these relate to each other in a site representation. We also use the storyboard to represent the navigation options available to site users. We use static storyboards to conduct walkthroughs, as we will explain in Chapter 12. Also, constructing static storyboards is a prerequisite to building an interactive storyboard or prototype on which we can do usability testing. Figure 2.6 is an example of a storyboard for a segment of the fast-food Web site.

Figure 2.6. A partial storyboard

Metaphor Design

Web technology is still relatively new. When people visit a Web site, they draw from previous knowledge and expectations, gradually building a mental model of how they think the Web operates. When the Web site's behavior clashes with the model, the user will most likely become confused and annoyed. A well-designed interface will help the Web user to form a consistent and usable model. One way of developing such a model is metaphor design.

A metaphor is a representation of a real-world environment that depicts real-world actions, concepts, and objects (Carroll, et al., 1988). Metaphors are powerful techniques for making a Web site less imposing to new users. It also can decrease the learning curve because the user can take advantage of previous knowledge and is not forced to learn everything from scratch. Designing a good metaphor is not a simple task. A poorly designed metaphor is much more damaging than the lack of a metaphor because it will mislead the user, undermining his or her trust in the system, and, therefore, confidence in using it. The following are guidelines for metaphor design.

Design a metaphor for the naive user. Because people learn how to use computers by building on previous knowledge and expectations, the metaphor should be meaningful for beginning users. It is important to realize that beginning users will form some mental model while using the Web site. Therefore, we should present the metaphor in a way that is clear and takes advantage of common beginner activities.

Choose metaphors that are congruent with the Web site behavior and that encompass most (if not all) aspects of the site. Make sure not to mislead the user when selecting an explicit metaphor. Exclude aspects of the site that do not follow the metaphor.

Ensure that the emotional tone of the metaphor is sympathetic to the emotional attitude of the user. It is possible to design a metaphor that convincingly models the Web site but that is entirely inappropriate in its emotional resonance.

When one metaphor cannot model all aspects of an entire system, use a set of metaphors that follows a certain theme. Choose metaphors drawn from a single real-world domain, but do not choose objects or procedures that are exclusive alternatives from within that domain. A popular example is the desktop metaphor where the individual metaphors (files, trash cans) all fall within the domain of the office environment. When choosing sets of metaphors, it is also important not to use objects that have similar meanings in the real world to model different aspects of the Web site.

Ensure that metaphors do not encumber the expert user. Metaphors designed for the novice will often hinder an intermediate or expert user. Allow more experienced users to remove the metaphorical shield and use accelerated navigational and interactive schemes. Another potential solution is to replace the metaphor with a series of new, more sophisticated metaphors that will encourage users to learn more about the system. New metaphors continue to make the system interesting.

Principles for User Interface Design

PRINCIPLES FOR USER INTERFACE DESIGN

In many ways, user interface design is an art. The goal is to make the interface pleasing to the eye and simple to use, while minimizing the effort users expend to accomplish their work. The system is never an end in itself; it is merely a means to accomplish the business of the organization.

FIGURE 9-1 Principles of User Interface Design

We have found that the greatest problem facing experienced designers is using space effectively. Simply put, there is more information to present than room to present it. Analysts must balance the need for simplicity and pleasant appearance against the need to present the information across multiple pages or screens, which decreases simplicity. In this section, we discuss some fundamental interface design principles, which are common for navigation design, input design, and output design 3 (Figure 9-1).

Layout

The first principle of user interface design deals with the layout of the screen, form, or report. Layout refers to organizing areas of the screen or document for different purposes and using those areas consistently throughout the user interface. Most software designed for personal computers follows the standard Windows or Macintosh approach for screen layout. This approach divides the screen into three main areas: The top area provides the user with ways to navigate through the system; the middle (and largest) area is for display of the user's work; and the bottom area contains status information about what the user is doing.

In many cases (particularly on the Web), multiple layout areas are used. Figure 9-2 shows a screen with five navigation areas, each of which is organized to provide different functions and navigation within different parts of the system. The top area provides the standard web browser navigation and command controls that change the contents of the entire system. The navigation area on the left edge maneuvers between sections and changes all content to its right. The other two section navigation areas at the top and bottom of the page provide other ways to navigate between sections. The content in the middle of the page displays the results (i.e., software review articles) and provides additional navigation within the page about these reviews.

FIGURE 9-2 Web Page Layout with Multiple Navigation Areas

This use of multiple layout areas for navigation also applies to inputs and out-puts. Data areas on reports and forms are often subdivided into subareas, each of which is used for different types of information. These areas are almost always rectangular in shape, although sometimes space constraints will require odd shapes. Nonetheless, the margins on the edges of the screen should be consistent. Each of the areas within the report or form is designed to hold different information. For example, on an order form (or order report), one part may be used for customer information (e.g., name, address), one part for information about the order in general (e.g., date, payment information), and one part for the order details (e.g., how many units of which items at what price each). Each area is self-contained so that information in one area does not run into another.

The areas and information within areas should have a natural intuitive flow to minimize users' movement from one area to the next. People in Western nations (e.g., Europe, North America) tend to read top to bottom, left to right, so that related information should be placed so that it is used in this order (e.g., address lines, followed by city, state/province, and then ZIP code/postal code.) Sometimes, the sequence is in chronological order, or from the general to the specific, or from most frequently to least frequently used. In any event, before the areas are placed on a form or report, the analyst should have a clear understanding of what arrangement makes the most sense for how the form or report will be used. The flow between sections should also be consistent, whether horizontal or vertical (Figure 9-3). Ideally, the areas will remain consistent in size, shape, and placement for the forms used to enter information (whether on paper or on a screen) and the reports used to present it.

Content Awareness

Content awareness refers to the ability of an interface to make the user aware of the information it contains with the least amount of effort by the user. All parts of the interface, whether navigation, input, or output, should provide as much content awareness as possible, but it is particularly important for forms or reports that are used quickly or irregularly (e.g., a Web site).

Content awareness applies to the interface in general. All interfaces should have titles (on the screen frame, for example). Menus should show where the user is and, if possible, where the user came from to get there. For example, in Figure 9-2, the top line in the center site navigation bar shows that the user is in the Small Business Computing Channel section of the winplanet.com site.

Content awareness also applies to the area within forms and reports. All areas should be clear and well defined (with titles if space permits) to reduce the chances that users become confused about the information in any area. Then users can quickly locate the part of the form or report that is likely to contain the information they need. Sometimes the areas are marked by lines, colors, or headings (e.g., the site navigation links on the left side in Figure 9-2); in other cases, the areas are only implied (e.g., the page links in the center of Figure 9-2).

Content awareness also applies to the fields within each area. Fields are the individual elements of data that are input or output. The field labels that identify the fields on the interface should be short and specific—objectives that often conflict. There should be no uncertainty about the format of information within fields, whether for entry or display. For example, a date of 10/5/12 means different things, depending on whether you are in the United States (October 5, 2012) or in Canada (May 10, 2012). Any fields for which there is the possibility of uncertainty or multiple interpretations should provide explicit explanations.

Content awareness also applies to the information that a form or report contains. In general, all forms and reports should contain a preparation date (i.e., the date printed or the date data were completed) so that the age of the information is obvious. Likewise, all printed forms and software should provide version numbers so that users, analysts, and programmers can identify outdated materials.

FIGURE 9-3 Interface Flow between Sections

Figure 9-4, a form from the University of Georgia, illustrates the logical grouping of fields into areas with an explicit box (top left), as well as an implied area with no box (lower left). The address fields within the address area follow a clear, natural order. Field labels are short where possible (see the top left), but long where more information is needed to prevent misinterpretation (see the bottom left).

Aesthetics

Aesthetics refers to designing interfaces that are pleasing to the eye. Interfaces do not have to be works of art, but they do need to be functional and inviting to use. In most cases, “less is more,” meaning that a simple, minimalist design is the best.

Space usually is at a premium on forms and reports, and often there is the temptation to squeeze as much information as possible onto a page or a screen. Unfortunately, this can make a form or report so unpleasant that users do not want to complete it. In general, all forms and reports need at least a minimum amount of white space that is intentionally left blank.

What was your first reaction when you looked at Figure 9-4? This is the most unpleasant form at the University of Georgia, according to staff members. Its density is too high; it has too much information packed into too small a space with too little white space. Although it may be efficient in saving paper by being one page instead of two, it is not effective for many users.

In general, novice or infrequent users of an interface, whether on a screen or on paper, prefer interfaces with low density, often one with a density of less than 50% (i.e., less than 50% of the interface occupied by information). More experienced users prefer higher densities, sometimes approaching 90% occupied, because they know where information is located and high densities reduce the amount of physical movement through the interface. We suspect that the form in Figure 9-4 was designed for the experienced staff in the personnel office, who use it daily, rather than for the clerical staff in academic departments, who have less personnel experience and use the form only a few times a year.

The design of text is equally important. In general, there should be one font for the entire form or report and no more than two sizes of that font on the form or report. A larger font size may be used for titles, section headings, etc., and a smaller font for the report or form content. If the form or report will be printed, the smaller font should be at least 8 points in size. A minimum of 10 points is preferred if the users will be older people. For forms or reports displayed on the screen, consider a minimum of a 12-point font size if the display monitor is set for a high screen resolution. Italics and underlining should be avoided because they make text harder to read.

Serif fonts (i.e., those having letters with serifs, or “tails,” such as Times Roman or the font you are reading right now) are the most readable for printed reports, particularly for small letters. Sans serif fonts (i.e., those without serifs, such as Tahoma or Arial or the ones used for the chapter titles in this book) are the most readable for computer screens and are often used for headings in printed reports. Never use all capital letters, except possibly for titles—all-capitals text “shouts” and is harder to read.

Color and patterns should be used carefully and sparingly and only when they serve a purpose. (About 10% of men are color blind, so the improper use of color can impair their ability to read information.) A quick trip around the Web will demonstrate the problems caused by indiscriminate use of colors and patterns. Remember, the goal is pleasant readability, not art; colors and patterns should be used to strengthen the message, not overwhelm it. Color is best used to separate and categorize items, such as showing the difference between headings and regular text, or to highlight important information. Therefore, colors with high contrast should be used (e.g., black and white). In general, black text on a white background is the most readable, with blue on red the least readable. (Most experts agree that background patterns on Web pages should be avoided.) Color has been shown to affect emotion, with red provoking intense emotion (e.g., anger) and blue provoking lowered emotions (e.g., drowsiness).

FIGURE 9-4 Form Example

User Experience

User experience refers to designing the user interface with the users' level of computer experience in mind. A computer system will be used by people with experience and by people with no experience; the user interface should be designed for both types. Novice users usually are most concerned with ease of learning—how quickly and easily they can learn to use the system. Expert users are typically more concerned with ease of use —how quickly and easily they can complete a task with the system once they have learned how to use it. Often, these two objectives are complementary and lead to similar design decisions, but sometimes, there are trade-offs. Novices, for example, often prefer menus that show all available system functions, because these promote ease of learning. Experts, on the other hand, sometimes prefer fewer menus that are organized around the most commonly used functions.

Systems that will end up being used by many people on a daily basis are more likely to have a majority of expert users (e.g., order entry systems). Although inter-faces should try to balance ease of use and ease of learning, these types of systems should put more emphasis on ease of use rather than on ease of learning. Users should be able to access the commonly employed functions quickly, with few keystrokes or a small number of menu selections.

In many other systems (e.g., decision support systems), most people will remain occasional users for the lifetime of the system. In this case, greater emphasis may be placed on ease of learning rather than on ease of use.

Although ease of use and ease of learning often go hand in hand, sometimes they don't. Research shows that expert and novice users have different requirements and behavior patterns in some cases. For example, novices virtually never look at the bottom area of a screen that presents status information, but experts refer to the status bar when they need information. Most systems should be designed to support frequent users, except for systems that are to be used infrequently or those for which many new users or occasional users are expected (e.g., the Web). Likewise, systems that contain functionality that is used only occasionally must contain a highly intuitive interface, or an interface that contains explicit guidance regarding its use.

The balance between quick access to commonly used and well-known functions and guidance through new and less-well-known functions is challenging to the interface designer, and this balance often requires elegant solutions. Microsoft Office, for example, addresses this issue through the use of the “show me” functions that demonstrate the menus and buttons for specific functions. These features remain in the background until they are needed by novice users (or even experienced users when they use an unfamiliar part of the system).

Consistency

Consistency in design is probably the single most important factor in making a system simple to use, because it enables users to predict what will happen. When interfaces are consistent, users can interact with one part of the system and then know how to interact with the rest—aside, of course, from elements unique to those parts. Consistency usually refers to the interface within one computer system, so that all parts of the same system work in the same way. Ideally, however, the system also should be consistent with other computer systems in the organization and with whatever commercial software is used (e.g., Windows). For example, many users are familiar with the Web, so the use of Web-like interfaces can reduce the amount of learning required by the user. In this way, the user can reuse Web knowledge, thus significantly reducing the learning curve for a new system.

Consistency occurs at many different levels. Consistency in the navigation controls conveys how actions in the system should be performed. For example, using the same icon or command to change an item clearly communicates how changes are made throughout the system. Consistency in terminology is also important. This refers to using the same words for elements on forms and reports (e.g., not “customer” in one place and “client” in another). We also believe that consistency in report and form design is important, although one study suggests that being too consistent can cause problems.4 When reports and forms are very similar except for minor changes in titles, users sometimes mistakenly use the wrong report or form and either enter incorrect data or misinterpret its information. The implication for design is to make the reports and forms similar, but give them some distinctive elements (e.g., color, size of titles) that enable users to immediately detect differences.

Minimize User Effort

Finally, interfaces should be designed to minimize the amount of effort needed to accomplish tasks. This means using the fewest possible mouse clicks or keystrokes to move from one part of the system to another. Most interface designers follow the three-clicks rule: Users should be able to go from the start or main menu of a system to the information or action they want in no more than three mouse clicks or three keystrokes.

YOUR TURN: 9-1 WEB PAGE CRITIQUE

Visit the Web home page for your university and navigate through several of its Web pages. Evaluate the extent to which they meet the six design principles.

User Interface Design Process

User interface design 5 is a five-step process that is iterative—analysts often move back and forth between steps rather than proceed sequentially from step 1 to step 5 (Figure 9-5). First, the analysts examine the DFDs and use cases developed in the analysis phase (see Chapters 4 and 5) and interview users to develop use scenarios that describe users' commonly employed patterns of actions so that the interface can enable users to quickly and smoothly perform these scenarios. Second, the analysts develop the interface structure diagram (ISD) that defines the basic structure of the interface. This diagram (or set of diagrams) shows all the interfaces (e.g., screens, forms, and reports) in the system and how they are connected. Third, the analysts design interface standards, which are the basic design elements on which interfaces in the system are based. Fourth, the analysts create an interface design prototype for each of the individual interfaces in the system, such as navigation controls, input screens, output screens, forms (including preprinted paper forms), and reports. Finally, the individual interfaces are subjected to interface evaluation to determine whether they are satisfactory and how they can be improved.

Interface evaluations almost always identify improvements, so the interface design process is repeated in a cyclical process until no new improvements are identified. In practice, most analysts interact closely with the users during the interface design process, so that users have many chances to see the interface as it evolves rather than waiting for one overall interface evaluation at the end of the interface design process. It is better for all concerned (both analysts and users) if changes are identified sooner rather than later. For example, if the interface structure or standards need improvement, it is better to identify changes before most of the screens that use the standards have been designed.

FIGURE 9-5 User Interface Design Process

Use Scenario Development

A use scenario is an outline of the steps that the users perform to accomplish some part of their work. A use scenario is one commonly used path through a use case. Recall that use cases and data flow diagrams may include multiple ways in which the response to the event can be completed. For example, think back to the Search and Browse Tunes use case from Figure 4-14 in Chapter 4 that was modeled in a level 1 DFD shown in Figure 5-18 in Chapter 5. This figure shows process 1.2 (Process Search Requests) as being distinct from process 1.3 (Process Tune Selection). We model the two processes separately and write the programs separately because they are separate processes within process 1 (Search and Browse Tunes).

The DFD was designed to model all possible uses of the system—that is, its complete functionality or all possible paths through the use case. But use scenarios are just one path through the use case. In one use scenario, for example, a user will browse through many tunes, much like someone browsing through a real music store looking for interesting music. He or she will search for a tune, listen to a sample, perhaps add it to the shopping cart, browse for more, and so on. Eventually, the user will want to purchase the download(s), perhaps removing some selections from the shopping cart beforehand.

In another use scenario, a user will want to buy one specific tune. He or she will go directly to the tune, price it, and buy it immediately, much like someone running into a store, making a beeline for the one item he or she wants, and immediately paying and leaving the store. This user will enter the tune information in the search portion of the system, look at the resulting cost information, and immediately buy the download or leave. Anything that slows him or her down will risk losing the sale. For this use scenario, we need to ensure that the path through the DFD as presented by the interface is short and simple, with very few menus and mouse clicks.

Use scenarios are presented in a simple narrative description that is tied to the DFD. Figure 9-6 shows the two use scenarios just described. The key point in using use scenarios for interface design is not to document all possible use scenarios within a use case, because then you end up just repeating the DFD in a different form. The goal is to describe the handful of most commonly occurring use scenarios so that the interface can be designed to enable the most common uses to be performed simply and easily.

YOUR TURN: 9-2 USE SCENARIO DEVELOPMENT FOR THE WEB

Visit the Web site for your university and navigate through several of its Web pages. Develop two use scenarios for it.

FIGURE 9-6 Two Use Scenarios for the Search and Browse Tunes Use Case

Interface Structure Design

The interface structure design defines the basic components of the interface and how they work together to provide functionality to users. An interface structure diagram (ISD) is used to show how all the screens, forms, and reports used by the system are related and how the user moves from one to another. Most systems have several ISDs, one for each major part of the system.

An ISD is somewhat similar to a DFD in that it uses boxes and lines to show structure. However, unlike DFDs, there are no commonly used rules or standards for their development. With one approach, each interface element (e.g., screen, form, report) on an ISD is drawn as a box and is given a unique number (at the top) and a unique name (in the middle). The numbers usually follow a tree-type structure, although this is not always done. Unlike the DFDs, however, the numbers do not mean that all the screens belong to “parents” higher in the tree; instead, they usually imply relationships between a menu and a submenu. The lines denote the ability to navigate from one menu to another.

Each box on the ISD also shows (at the bottom) the DFD process that is supported by the interface (Figure 9-7). Sometimes, there is more than one interface for a given process (e.g., in Figure 9-7, interfaces 1.1 through 1.3 support process 1.1.1); in other cases, there is only one interface for each process (e.g., interfaces 3.1 through 3.3 support processes 1.1.3.1 through 1.1.3.3).

YOUR TURN: 9-3 USE SCENARIO DEVELOPMENT FOR AN AUTOMATED TELLER MACHINE

Pretend that you have been charged with the task of redesigning the interface for the ATM at your local bank. Develop two use scenarios for it.

FIGURE 9-7 Example Interface Structure Diagram

Each interface is linked to other interfaces by lines that show how users can transition from one interface to the next. In most cases, the interfaces form a hierarchy, or a tree; but sometimes, an interface is linked to one outside of the hierarchy, as shown by the link from Form J to Form B (e.g., the ability to update customer information, such as address, while entering a new order).

The basic structure of the interface follows the basic structure of the business process itself as defined in the process model. The analyst starts with the DFD and develops the fundamental flow of control of the system as it moves from process to process. There are usually several major parts to an information system, each of them distinct, in the same way that there are several high-level processes in a DFD. In general—but not always—there is one ISD for each process on the level 0 DFD.

The analyst then examines the use scenarios to see how well the ISD supports them. Quite often, the use scenarios identify paths through the ISD that are more complicated than they should be. The analyst then reworks the ISD to simplify the ability of the interface to support the use scenarios, sometimes by making major changes to the menu structure, sometimes by adding shortcuts.

Interface Standards Design

The interface standards are the basic design elements that are common across the individual screens, forms, and reports within the system. Depending on the application, there may be several sets of interface standards for different parts of the system (e.g., one for Web screens, one for paper reports, one for input forms). For example, the part of the system used by data-entry operators may mirror other data-entry applications in the company, whereas a Web interface for displaying information from the same system may adhere to some standardized Web format. Likewise, each individual interface may not contain all the elements in the standards (e.g., a report screen may not have an “edit” capability), and they may contain additional characteristics beyond the standard ones, but the standards serve as the touchstone which ensures that the interfaces are consistent across the system.

Interface Metaphor First of all, the analysts must develop the fundamental interface metaphor(s) that defines how the interface will work. An interface metaphor is a concept from the real world that is used as a model for the computer system. The metaphor helps the user to understand the system and enables the user to predict what features the interface might provide, even without actually using the system. Sometimes systems have one metaphor, whereas in other cases there are several metaphors in different parts of the system.

In many cases, the metaphor is explicit. Quicken, for example, uses a check-book metaphor for its interface, even to the point of having the users type information into an on-screen form that looks like a real check register. In other cases, the metaphor is implicit, or unstated, but it is there nonetheless. Many Windows systems use the paper form or table as a metaphor.

In some cases, the metaphor is so obvious that it requires no thought. The Tune Source Digital Music Download system, for example, will use the retail music store as the metaphor (e.g., shopping cart). In other cases, a metaphor is hard to identify. In general, it is better not to force a metaphor that really doesn't fit a system, because an ill-fitting metaphor will confuse users by promoting incorrect assumptions.

Interface Templates The interface template defines the general appearance of all screens in the information system and the paper-based forms and reports that are used. The template design, for example, specifies the basic layout of the screens (e.g., where the navigation area[s], status area, and form/report area[s] will be placed) and the color scheme(s) that will be applied. It defines whether windows will replace one another on the screen or will cascade on top of each other. The template defines a standard placement and order for common interface actions (e.g., “File, Edit, View” rather than “File, View, Edit”). In short, the template draws together the other major interface design elements: metaphors, objects, actions, and icons.

YOUR TURN: 9-4 INTERFACE STRUCTURE DESIGN

Pretend that you have been charged with the task of redesigning the interface for the ATM at your local bank. Design an ISD that shows how a user would navigate among the screens.

Interface Objects The template specifies the names that the interface will use for the major interface objects, the fundamental building blocks of the system such as the entities and data stores. In many cases, the object names are straightforward, such as calling the shopping cart the “shopping cart.” In other cases, it is not simple. For example, Tune Source has chosen to call its digital music downloads “tunes.” Some people may refer to individual music selections as “tracks” or “cuts.” Obviously, the object names should be easily understood and should help promote the interface metaphor.

In general, in cases of disagreements between the users and the analysts over names, whether for objects or actions (discussed later), the users should win. A more understandable name always beats a more precise or more accurate name.

Interface Actions The template also specifies the navigation and command language style (e.g., menus) and grammar (e.g., object–action order; see “Navigation Design” later in this chapter). The template gives names to the most commonly used interface actions in the navigation design (e.g., “buy” versus “purchase,” or “exit” versus “quit”).

Interface Icons The interface objects and actions, and also their status (e.g., deleted, error), may be represented by interface icons. Icons are pictures that will appear on command buttons as well as in reports and forms to highlight important information. Icon design is very challenging because it means developing a simple picture less than half the size of a postage stamp that needs to convey an often-complex meaning. The simplest and best approach is to adopt icons developed by others (e.g., a blank page to indicate “create a new file,” a diskette to indicate “save”). This has the advantage of quick icon development, and the icons may already be well understood by users because users have seen them in other software.

Commands are actions that are especially difficult to represent with icons because they are in motion, not static. Many icons have become well known from widespread use, but icons are not as well understood as it was at first believed that they would be. The use of icons can sometimes cause more confusion than insight. (For example, did you know that a picture of a sweeping paintbrush in Microsoft Word means “format painter”?) Icon meanings become clearer with use, but because they are often cryptic, many applications now provide text tool tips that appear when the pointer hovers over an icon. This feature explains the purpose of the icon in words.

YOUR TURN: 9-5 INTERFACE STANDARDS DEVELOPMENT

Pretend that you have been charged with the task of redesigning the interface for the ATM at your local bank. Develop an interface standard that includes metaphors, objects, actions, icons, and a template.

Interface Design Prototyping

An interface design prototype is a mock-up or a simulation of a computer screen, form, or report. A prototype is prepared for each interface in the system to show the users and the programmers how the system will perform. In the “old days,” an interface design prototype was usually specified on a paper form that showed what would be displayed on each part of the screen. Paper forms are still used today, but more and more interface design prototypes are being built with computer tools instead of on paper. The three most common approaches to interface design prototyping are storyboards, HTML prototypes, and language prototypes.

Storyboard At its simplest, an interface design prototype is a paper-based storyboard. The storyboard shows hand-drawn pictures of what the screens will look like and how they will flow from one screen to another, in the same way that a storyboard for a cartoon shows how the action will flow from one scene to the next (Fig. 9-8). Storyboards are the simplest technique because all they require is paper (often on a flip chart) and a pen—and someone with some artistic ability.

FIGURE 9-8 An Example Storyboard

HTML Prototype One of the most common types of interface design prototypes used today is the HTML prototype. As the name suggests, an HTML prototype is built with the use of Web pages created in HTML (hypertext mark-up language). The designer uses HTML to create a series of Web pages that show the fundamental parts of the system. The users can interact with the pages by clicking on buttons and entering pretend data into forms (but because there is no system behind the pages, the data are never processed). The pages are linked together so that, as the user clicks on buttons, the requested part of the system appears. HTML prototypes are superior to storyboards in that they enable users to interact with the system and gain a better sense of how to navigate among the different screens. However, HTML has limitations—the screens shown in HTML will never appear exactly like the real screens in the system (unless, of course, the real system will be a Web system in HTML).

Language Prototype A language prototype is an interface design prototype built in the actual language or by the actual tool that will be used to build the system. Language prototypes are designed in the same ways as HTML prototypes. (They enable the user to move from screen to screen, but they perform no real processing). For example, in Visual Basic, it is possible to create and view screens without actually attaching program code to the screens. See Figure 9-9 for a sample Visual Basic Language prototype. Language prototypes take longer to develop than do storyboards or HTML prototypes, but they have the distinct advantage of showing exactly what the screens will look like. The user does not have to guess about the shape or position of the elements on the screen.

FIGURE 9-9 Sample Language Prototype—Part A

FIGURE 9-9 Sample Language Prototype—Part B

FIGURE 9-9 Sample Language Prototype—Part C

CONCEPTS IN ACTION: 9-A INTERFACE DESIGN PROTOTYPES FOR A DSS APPLICATION

I was involved in the development of several decision support systems (DSS) while working as a consultant. On one project, a future user was frustrated because he could not imagine what a DSS looked like and how one would be used. He was a key user, but the project team had a difficult time involving him in the project because of his frustration. The team used SQL Windows (one of the most popular development tools at the time) to create a language prototype that demonstrated the future systems appearance, proposed menu system, and screens (with fields, but no processing).

The team was amazed at the user's response to the prototype. He appreciated being given a context with which to visualize the DSS, and he soon began to recommend improvements to the design and flow of the system, and to identify some important information that was overlooked during the analysis phase. Ultimately, the user became one of the strongest supporters of the system, and the project team felt sure that the prototype led to a much better product in the end. Barbara Wixom

QUESTIONS:

1. Why do you think the team chose to use a language prototype rather than a storyboard or HTML prototype?

2. What trade-offs were involved in the decision?

Selecting the Appropriate Techniques Projects often use a combination of different interface design prototyping techniques for different parts of the system. Storyboarding is the fastest and least expensive, but provides the least amount of detail. Language prototyping is the slowest, most expensive, and most detailed approach. HTML prototyping falls between the two extremes. Therefore, storyboarding is used for parts of the system in which the interface is well understood and when more expensive prototypes are thought to be unnecessary. HTML prototypes and language prototypes are used for parts of the system that are critical, yet not well understood.

Interface Evaluation

The objective of interface evaluation is to understand how to improve the interface design. Interface design is subjective; there are no formulas that guarantee a great user interface. Most interface designers intentionally or unintentionally design an interface that meets their personal preferences, which may or may not match the preferences of the users. The key message, therefore, is to have as many people as possible evaluate the interface—and the more users, the better. Most experts recommend involving at least 10 potential users in the evaluation process.

Many organizations save interface evaluation for the very last step in the SDLC before the system is installed. Ideally, however, interface evaluation should be performed while the system is being designed—before it is built—so that any major design problems can be identified and corrected before the time and cost of programming have been spent on a weak design. It is not uncommon for the system to undergo one or two major changes after the users see the first interface design prototype, because they identify problems that are overlooked by the project team.

As with interface design prototyping, interface evaluation can take many different forms, each with different costs and different levels of detail. Four common approaches are heuristic evaluation, walk-through evaluation, interactive evaluation, and formal usability testing. As with interface design prototyping, the different parts of a system can be evaluated by different techniques.

Heuristic Evaluation A heuristic evaluation examines the interface by comparing it to a set of heuristics, or principles, for interface design. The project team develops a checklist of interface design principles—from the list at the start of this chapter, for example, as well as the lists of principles in the navigation, input, and output design sections. At least three members of the project team then individually work through the interface design prototype, examining each interface to ensure that it satisfies each design principle on the formal checklist. After each member has gone through the prototype separately, they all meet as a team to discuss their evaluation and identify specific improvements that are required. Because this technique does not involve the users, it is considered the weakest type of evaluation.

Walk-through Evaluation An interface design walk-through evaluation is a meeting conducted with the users who will ultimately have to operate the system. The project team presents the prototype to the users and walks them through the various parts of the interface. The project team shows the storyboard or actually demonstrates the HTML or language prototype and explains how the interface will be used. The users identify improvements to each of the interfaces that are presented.

Interactive Evaluation With an interactive evaluation, the users themselves actually work with the HTML or language prototype in one-on-one sessions with members of the project team. (An interactive evaluation cannot be used with a storyboard.) As the user works with the prototype (often by going through the use scenarios or just navigating at will through the system), he or she tells the project team members what he or she likes and doesn't like and what additional information or functionality is needed. As the user interacts with the prototype, team members record the situation when the user appears to be unsure of what to do, makes mistakes, or misinterprets the meaning of an interface component. If the pattern of uncertainty, mistakes, or misinterpretations recurs across several evaluation sessions with several users, it is a clear indication that those parts of the interface need improvement.

Formal Usability Testing Formal usability testing is commonly done with commercial software products and products developed by large organizations that will be widely used through the organization. As the name suggests, it a very formal— almost scientific—process that can be used only with language prototypes (and systems that have been completely built and are awaiting installation or shipping).6 As with interactive evaluation, usability testing is done in one-on-one sessions in which a user works directly with the software. However, it is typically done in a special lab equipped with video cameras and special software that records each and every keystroke and mouse operation so that they can be replayed to help in understanding exactly what the user did.

YOUR TURN: 9-6 PROTOTYPING AND EVALUATION

Pretend that you have been charged with the task of redesigning the interface for the ATM at your local bank. What type of prototyping and interface evaluation approach would you recommend?

The user is given a specific set of tasks to accomplish (usually the use scenarios), and after some initial instructions the project teams member(s) are not permitted to interact with the user to provide assistance. The user must work with the software without help, which can be hard on the user if he or she becomes confused with the system. It is critical that users understand that the goal is to test the interface, not their abilities, and if they are unable to complete the task, the interface— not the user—has failed the test. Several performance measures are used, such as time to complete the task, error rate, and user satisfaction.

Formal usability testing is very expensive. Each one-user session (which typically lasts one to two hours) can take one to two days to analyze due to the volume of detail collected in the computer logs and videotapes. Most usability testing involves 5 to 10 users. Fewer than 5 users makes the results depend too much on the specific individual users who participated, but more than 10 users is often too expensive to justify (unless you work for a large commercial software developer).

Navigation Design

The navigation component of the interface enables the user to enter commands to navigate through the system and perform actions to enter and review information it contains. The navigation component also presents messages to the user about the success or failure of his or her actions. The goal of the navigation system is to make the system as simple as possible to use. A good navigation component is one that the user never really notices. It simply functions the way the user expects, and thus the user gives it little thought.

Basic Principles

One of the hardest things about using a computer system is learning how to manipulate the navigation controls to make the system do what you want. Analysts usually must assume that users have not read the manual, have not attended training, and do not have external help readily at hand. All controls should be clear and understandable and placed in an intuitive location on the screen. Ideally, the controls should anticipate what the user will do and simplify his or her efforts. For example, many set-up programs are designed so that, for a typical installation, the user can simply keep pressing the “Next” button.

Prevent Mistakes The first principle of designing navigation controls is to prevent the user from making mistakes. A mistake costs time and creates frustration. Worse still, a series of mistakes can cause the user to discard the system. Mistakes can be reduced by labeling commands and actions appropriately and by limiting choices. Too many choices can confuse the user, particularly when they are similar and hard to describe in the short space available on the screen. When there are many similar choices on a menu, consider creating a second level of menu or a series of options for basic commands.

Never display a command that cannot be used. For example, many Windows applications gray-out commands that cannot be used; they are displayed on pull-down menus in a very light-colored font, but they cannot be selected. This shows that they are available, but that they cannot be used in the current context. It also keeps all menu items in the same place.

When the user is about to perform a critical function that is difficult or impossible to undo (e.g., deleting a file), it is important to confirm the action with the user (and make sure the selection was not made by mistake). This is usually done by having the user respond to a confirmation message that explains what the user has requested and asks the user to confirm that this action is correct.

Simplify Recovery from Mistakes No matter what the system designer does, users will make mistakes. The system should make it as easy as possible to correct these errors. Ideally, the system will have an “Undo” button that makes mistakes easy to override; however, writing the software for such buttons can be very complicated.

Use Consistent Grammar Order One of the most fundamental decisions is the grammar order. Most commands require the user to specify an object (e.g., file, record, word) and the action to be performed on that object (e.g., copy, delete). The interface can require the user to first choose the object and then the action (an object-action order) or first choose the action and then the object (an action-object order). Most Windows applications use an object-action grammar order (e.g., think about copying a block of text in your word processor).

The grammar order should be consistent throughout the system, both at the data element level and at the overall menu level. Experts debate about the advantages of one approach over the other, but because most users are familiar with the object-action order, most systems today are designed with that approach.

Types of Navigation Controls

There are two traditional hardware devices that can be used to control the user interface: the keyboard and a pointing device, such as a mouse, trackball, or touch screen. In recent years, voice recognition systems have made an appearance, but they are not yet common. There are three basic software approaches for defining user commands: languages, menus, and direct manipulation.

Languages With a command language, the user enters commands in a special language developed for the computer system (e.g., UNIX and SQL both use command languages). Command languages sometimes provide greater flexibility than do other approaches, because the user can combine language elements in ways not predetermined by developers. However, they put a greater burden on users because users must learn syntax and type commands rather than select from a well-defined, limited number of choices. Systems today use command languages sparingly, except in cases in which there are an extremely large number of command combinations, making it impractical to try to build all combinations into a menu (e.g., SQL queries for databases).

YOUR TURN: 9-7 DESIGN A NAVIGATION SYSTEM

Design a navigation system for a form into which users must enter information about customers, products, and orders. For all three information categories, users will want to change, delete, find one specific record, and list all records.

Natural language interfaces are designed to understand the user's own language (e.g., English, French, Spanish). These interfaces attempt to interpret what the user means, and often they present back to the user a list of interpretations from which to choose. Many “help” systems today enable the user to ask free-form questions to get help.

Menus The most common type of navigation system today is the menu. A menu presents the user with a list of choices, each of which can be selected. Menus are easier to learn than languages because the user sees an organized, but limited, set of choices. Clicking on an item with a pointing device or pressing a key that matches the menu choice (e.g., a function key) takes very little effort. Therefore, menus are usually preferred to languages.

Menus should be designed with care, because the submenus behind a main menu are hidden from users until they click on the menu item. It is better to make menus broad and shallow (i.e., with each menu containing many items and each item containing only one or two layers of menus) rather than narrow and deep (i.e., with each menu containing only a few items, but each item leading to three or more layers of menus). A broad and shallow menu presents the user with the most information initially, so that he or she can see many options, and requires only a few mouse clicks or keystrokes to perform an action. A narrow and deep menu makes users hunt and seek for items hidden behind menu items and requires many more clicks or keystrokes to perform an action.

Research suggests that in an ideal world, any one menu should contain no more than eight items and it should take no more than two mouse clicks or keystrokes from any menu to perform an action (or three from the main menu that starts a system).7 However, analysts sometimes must break this guideline in the design of complex systems. In this case, menu items are often grouped together and separated by a horizontal line (Fig. 9-10). Often, menu items have hot keys that enable experienced users to quickly invoke a command with keystrokes in lieu of a menu choice (e.g., Control-F in Word invokes the Find command, whereas Alt-F opens the File menu).

Menus should put together similar categories of items so that the user can intuitively guess what each menu contains. Most designers recommend grouping menu items by interface objects (e.g., Customers, Purchase Orders, Inventory) rather than by interaction actions (e.g., New, Update, Format), so that all actions pertaining to one object are in one menu, all actions for another object are in a different menu, and so on. However, this is highly dependent on the specific interface. As Figure 9-10 shows, Microsoft Visual Studio groups menu items by interface objects (e.g., File, Project, Window) and by interface actions (e.g., Edit, View, Build) on the same menu. Some of the more common types of menus include menu bars, drop-down menus, pop-up menus, tab menus, tool bars, and image maps. (See Figures 9-10 and 9-11.)

FIGURE 9-10 Common Types of Menus—Part A

Direct Manipulation With direct manipulation, the user enters commands by working directly with interface objects. For example, users can change the size of objects in Microsoft PowerPoint by clicking on objects and moving the sides, or they can move files in Windows Explorer by dragging the file names from one folder to another. Direct manipulation can be simple, but it suffers from two problems. First, users familiar with language-or menu-based interfaces don't always expect it. Second, not all commands are intuitive. (For example, how do you copy [not move] files in Windows Explorer?)

FIGURE 9-10 Common Types of Menus—Part B

Messages

Messages are the way in which the system responds to a user and informs him or her of the status of the interaction. There are many different types of messages, such as error messages, confirmation messages, acknowledgment messages, delay messages, and help messages (Figure 9-12). In general, messages should be clear, concise, and complete, which are sometimes conflicting objectives. All messages should be grammatically correct and free of jargon and abbreviations (unless they are users'jargon and abbreviations). Avoid negatives, because they can be confusing (e.g., replace “Are you sure you do not want to continue?” with “Do you want to quit?”). Likewise, avoid humor, because it wears off quickly after the same message appears dozens of times.

FIGURE 9-11 Types of Menus

Messages should require the user to acknowledge them (by clicking, for example), rather than being displayed for a few seconds and then disappearing. The exceptions are messages that inform the user of delays in processing, which should disappear once the delay has passed. In general, messages are text, but sometimes standard icons are used. For example, Windows 7 displays a revolving circle when the system is busy.

FIGURE 9-12 Types of Messages

All messages should be carefully crafted, but error messages and help messages require particular care. Messages (and especially error messages) should always explain the problem in polite, succinct terms (e.g., what the user did incorrectly) and explain corrective action as clearly and as explicitly as possible so that the user knows exactly what needs to be done. In the case of complicated errors, the error message should display what the user entered, suggest probable causes for the error, and propose possible user responses. When in doubt, provide either more information than the user needs or the ability to get additional information. Error messages should provide a message number. Message numbers are not intended for users, but their presence makes it simpler for those staffing help desks and customer support lines to identify problems and help users, because many messages use similar wording.

Input Design

Input mechanisms facilitate the entry of data into the computer system, whether highly structured data, such as order information (e.g., item numbers, quantities, costs), or unstructured information (e.g., comments). Input design means designing the screens used to enter the information, as well as any forms on which users write or type information (e.g., time cards, expense claims).

Basic Principles

The goal of input design is to capture accurate information for the system simply and easily. The fundamental principles for input design reflect the nature of the inputs (whether batch or online) and ways to simplify their collection.

Use Online and Batch Processing Appropriately There are two general approaches for entering inputs into a computer system: online processing and batch processing. With online processing (sometimes called transaction processing), each input item (e.g., a customer order, a purchase order) is entered into the system individually, usually at the same time as the event or transaction prompting the input. For example, when you borrow a book from the library, buy an item at the store, or make an airline reservation, the computer system that supports each process uses online processing to immediately record the transaction in the appropriate database(s). Online processing is most commonly used when it is important to have real-time information about the business process. For example, when you reserve an airline seat, the seat is no longer available for someone else to use, so that piece of information must be recorded immediately.

With batch processing, all the inputs collected over some period are gathered together and entered into the system at one time in a batch. Some business processes naturally generate information in batches. For example, most hourly payrolls are done by batch processing because time cards are gathered together in batches and processed at once. Batch processing also is used for transaction processing systems that do not require real-time information. For example, most stores send sales information to district offices so that new replacement inventory can be ordered. This information could be sent in real time as it is captured in the store, so that the district offices are aware within a second or two that a product is sold. If stores do not need up-to-the-second real-time data, they will collect sales data throughout the day and transmit the data every evening in a batch to the district office. This batching simplifies the data communications process and often cuts communications costs. It does mean, however, that inventories are not accurate in real time, but rather are accurate only at the end of the day after the batch has been processed.

Capture Data at the Source Perhaps the most important principle of input design is to capture the data in an electronic format at the original source or as close to the original source as possible. In the early days of computing, computer systems replaced traditional manual systems that were based on paper forms. As these business processes were automated, many of the original paper forms remained, either because no one thought to replace them or because it was too expensive to do so. Instead, the business process continued to contain manual forms that were taken to the computer center in batches to be typed into the computer system by a data-entry operator.

Many business processes still operate this way today. For example, many organizations have expense claim forms that are completed by hand and submitted to an accounting department, which approves them and enters them into the system in batches. There are three problems with this approach. First, it is expensive because it duplicates work. (The form is filled out twice, once by hand and once by keyboard.) Second, it increases processing time because the paper forms must be physically moved through the process. Third, it increases the cost and the probability of error, because it separates the entry from the processing of information; someone may misread the handwriting on the input form, data could be entered incorrectly, or the original input may contain an error that invalidates the information.

Most transaction processing systems today are designed to capture data at its source. Source data automation refers to using special hardware devices to automatically capture data without requiring anyone to type it. Stores commonly use bar code readers that automatically scan products and enter data directly into the computer system. No intermediate formats, such as paper forms, are used. Similar technologies include optical character recognition, which can read printed numbers and text (e.g., on checks); magnetic stripe readers, which can read information encoded on a stripe of magnetic material similar to a diskette (e.g., credit cards); and smart cards that contain microprocessors, memory chips, and batteries (much like credit card-size calculators). A recent development is the RFID (radio frequency identification) tag, combining a microprocessor chip with an antenna to broadcast its information to electronic readers. Information can be read from or written to the RFID tag. As well as reducing the time and cost of data entry, these systems reduce errors because they are far less likely to capture data incorrectly. Today, portable computers and scanners allow data to be captured at the source even in mobile settings (e.g., air courier deliveries, use of rental cars).

A lot of information, however, cannot be collected by these automatic systems. Today, with the widespread use of the Web, much data is captured directly from the customer. Consequently, the forms for capturing information on-screen should provide a logical flow and should allow the user to easily complete the forms and check their entries before submitting them. Since data entered by the user is prone to inaccuracies, validation checks (see Figure 9-15) should be used whenever possible.

Minimize Keystrokes Another important principle is to minimize keystrokes. Key-strokes cost time and money, whether they are performed by a customer, user, or trained data-entry operator. The system should never ask for information that can be obtained in another way (e.g., by retrieving it from a database or by performing a calculation). Likewise, a system should not require a user to type information that can be selected from a list; selecting reduces errors and speeds entry.

In many cases, data have values that often recur. These frequent values should be used as the default value for the data so that the user can simply accept the value and not have to retype it time and time again. Examples of default values are the current date, the area code held by the majority of a company's customers, and a billing address that is based on the customer's residence. Most systems permit changes to default values to handle data entry exceptions as they occur.

YOUR TURN: 9-8 CAREER SERVICES

Pretend that you are designing the new interface for a career services system at your university that accepts student résumés and presents them in a standard format to recruiters. Describe how you could incorporate the basic principles of input design into your interface design. Remember to include the use of online versus batch data input, the capture of information, and plans to minimize keystrokes.

CONCEPTS IN ACTION: 9-B PUBLIC SAFETY DEPENDS ON A GOOD USER INTERFACE

Police officers in San Jose, California, experienced a number of problems with a new mobile dispatch system that included a Windows-based touch-screen computer in every patrol car. Routine tasks were difficult to perform, and the essential call for assistance was considered needlessly complicated.

The new system, costing $4.7 million, was an off-the-shelf system purchased from Intergraph Corp. It replaced a 14-year-old text-based system that was custom developed. Initially, the system was unstable, periodically crashing a day or two after installation and down for the next several days.

At the request of the San Jose police union, a user-interface design consulting firm was brought in to evaluate the new system. A number of errors were discovered in the system, including inaccurate map information, screens cluttered with unnecessary information, difficult-to-read on-screen type, and difficult-to-perform basic tasks, such as license plate checks. In addition, the police officers themselves were not consulted about the design of the interface. Many users felt that the Windows desktop GUI with its complex hierarchical menu structure was not suitable for in-vehicle use. While driving, officers found that the repeated taps on the screen required to complete tasks were very distracting, and one officer crashed his vehicle into a parked car because of the distraction of working with the system.

Further complicating the transition to the new system was the bare-bones training program. Just three hours of training were given on a desktop system, using track pads on the keyboards, not the 12-inch touch screen that would be found in the patrol cars.

After the rocky start, the software vendor worked closely with the city of San Jose to fix bugs and smooth out work flows. It seems clear, however, that the rollout could have been much easier if the officers and dispatchers had been involved in planning the system in the first place.

Source: “Wanted by the Police: A Good Interface,” The New York Times, November 11, 2004, by Katie Hafner.

QUESTION:

If you were involved in the acquisition of a new system for the police force in your community, what steps could you take to ensure the success of the project?

Types of Inputs

Each data item that has to be input is linked to a field, on the form into which its value is typed. Each field also has a field label, which is the text beside, above, or below the field, that tells the user what type of information belongs in the field. Often, the field label is similar to the name of the data element, but the two do not have to have identical wording. In some cases, a field will display a template over the entry box to show the user exactly how data should be typed. There are many different types of inputs, in the same way that there are many different types of fields. (See Fig. 9-13.)

Text As the name suggests, a text box is used to enter text. Text boxes can be defined to have a fixed length or can be scrollable and accept a virtually unlimited amount of text. In either case, boxes can contain single or multiple lines of textual information. Never use a text box if you can use a selection box.

Text boxes should have field labels placed to the left of the entry area, with their size clearly delimited by a box (or a set of underlines in a non-GUI interface). If there are multiple text boxes, their field labels and the left edges of their entry boxes should be aligned. Text boxes should permit standard GUI functions such as cut, copy, and paste.

FIGURE 9-13 User Input Options

Numbers A number box is used to enter numbers. Some software can automatically format numbers as they are entered, so that 3452478 becomes $34,524.78. Dates are a special form of numbers that sometimes have their own type of number box. Never use a number box if you can use a selection box.

Selection Box A selection box enables the user to select a value from a predefined list. The items in the list should be arranged in some meaningful order, such as alphabetical for long lists, or in order of most frequently used. The default selection value should be chosen with care. A selection box can be initialized as “unselected” or, better still, start with the most commonly used item already selected.

There are six commonly used types of selection boxes: check boxes, radio buttons, on-screen list boxes, drop-down list boxes, combo boxes, and scroll bars (Figs. 9-13, 9-14). The choice among the types of text selection boxes generally comes down to one of screen space and the number of choices the user can select. If screen space is limited and only one item can be selected, then a drop-down list box is the best choice, because not all list items need to be displayed on the screen. If screen space is limited, but the user can select multiple items, an on-screen list box that displays only a few items can be used. Check boxes (for multiple selections) and radio buttons (for single selections) both require all list items to be displayed at all times, thus requiring more screen space, but since they display all choices, they are often simpler for novice users.

FIGURE 9-14 Types of Selection Boxes

Input Validation

All data entered into the system must be validated in order to ensure accuracy. Input validation (also called edit checks) can take many forms. Ideally, to prevent invalid information from entering the system, computer systems should not accept data that fail any important validation check. However, this can be very difficult, and invalid data often slip by data-entry operators and the users providing the information. It is up the system to identify invalid data and either make changes or notify someone who can resolve the information problem.

There are six different types of validation checks: completeness check, format check, range check, check digit check, consistency check, and database check. (See Figure 9-15.) Every system should use at least one validation check on all entered data and, ideally, will perform all appropriate checks where possible.

YOUR TURN: 9-9 CAREER SERVICES

Consider a Web form that a student would use to input student information and résumé information into a career services application at your university. Sketch out how this form would look and identify the fields that the form would include. What types of validity checks would you use to make sure that the correct information is entered into the system?

FIGURE 9-15 Types of Input Validation

Output Design

Outputs are the reports that the system produces, whether on the screen, on paper, or in other media, such as the Web. Outputs are perhaps the most visible part of any system, because a primary reason for using an information system is to access the information that it produces.

Basic Principles

The goal of the output mechanism is to present information to users so that they can accurately understand it with the least effort. The fundamental principles for output design reflect how the outputs are used and ways to make it simpler for users to understand them.

Understand Report Usage The first principle in designing reports is to understand how they are used. Reports can be used for many different purposes. In some cases—but not very often—reports are read cover to cover because all information is needed. In most cases, reports are used to identify specific items or are used as references to find information, so the order in which items are sorted on the report or grouped within categories is critical. This is particularly important for the design of electronic or Web-based reports. Web reports that are intended to be read end to end should be presented in one long scrollable page, whereas reports that are primarily used to find specific information should be broken into multiple pages, each with a separate link. Page numbers and the date on which the report was prepared also are important for reference reports.

The frequency of the report may also play an important role in its design and distribution. Real-time reports provide data that are accurate to the second or minute at which they were produced (e.g., stock market quotes). Batch reports are those that report historical information that may be months, days, or hours old, and they often provide additional information beyond the reported information (e.g., totals, summaries, historical averages).

There are no inherent advantages to real-time reports over batch reports. The only advantages lie in the time value of the information. If the information in a report is time critical (e.g., stock prices, air traffic control information), then realtime reports have value. This is particularly important because real-time reports often are expensive to produce; unless they offer some clear business value, they may not be worth the extra cost.

Manage Information Load Most managers get too much information, not too little (i.e., the information load confronting the manager is too great). The goal of a well-designed report is to provide all the information needed to support the task for which it was designed. This does not mean that the report should provide all the information available on the subject—just what the users decide they need to perform their jobs. In some cases, this may result in the production of several different reports on the same topics for the same users, because they are used in different ways. This is not bad design.

For users in Westernized countries, the most important information generally should be presented first, in the top left corner of the screen or paper report. Information should be provided in a format that is usable without modification. The user should not need to re-sort the report's information, highlight critical information to find it more easily amid a mass of data, or perform additional mathematical calculations.

Minimize Bias No analyst sets out to design a biased report. The problem with bias is that it can be very subtle; analysts can introduce it unintentionally. Bias can be introduced by the way in which lists of data are sorted, because entries that appear first in a list may receive more attention than those appearing later in the list. Data often are sorted in alphabetic order, making those entries starting with the letter A more prominent. Data can be sorted in chronological order (or reverse chronological order), placing more emphasis on older (or most recent) entries. Data may be sorted by numeric value, placing more emphasis on higher or lower values. For example, consider a monthly sales report by state. Should the report be listed in alphabetic order by state name, in descending order by the amount sold, or in some other order (e.g., geographic region)? There are no easy answers to this, except to say that the order of presentation should match the way in which the information is used.

Graphic displays and reports can present particularly challenging design issues. The scale on the axes in graphs is particularly subject to bias. For most types of graphs, the scale should always begin at zero; otherwise, comparisons among values can be misleading. For example, in Fig. 9-16, have sales increased by very much since 2006? The numbers in both charts are the same, but the visual images the two present are quite different. A glance at Fig. 9-16a would suggest only minor changes, whereas a glance at Fig. 9-16b might suggest that there have been some significant increases. In fact, sales have increased by a total of 15% over five years, or 3% per year. Fig. 9-16a presents the most accurate picture; Fig. 9-16b is biased because the scale starts very close to the lowest value in the graph and misleads the eye into inferring that there have been major changes (i.e., more than doubling from “two lines” in 2006 to “five lines” in 2011). Fig. 9-16b is the default graph produced by Microsoft Excel, so be aware of how easy it is to unintentionally introduce bias in graphs.

Types of Outputs

There are many different types of reports, such as detail reports, summary reports, exception reports, turnaround documents, and graphs (Fig. 9-17). Classifying reports is challenging because many reports have characteristics of several different types. For example, some detail reports also produce summary totals, making them summary reports.

YOUR TURN: YOUR 9-10 FINDING BIAS

Read through recent copies of a newspaper or popular press magazine such as Time, Newsweek, or BusinessWeek and find four graphs. How many are biased and how many are unbiased?

FIGURE 9-16 Bias in Graphs: (a) Unbiased Graph with Scale Starting at 0; (b) Biased Graph with Scale Starting at 90.

Media

There are many different types of media used to produce reports. The two dominant media today are paper and electronic. Paper is the more traditional medium and is relatively permanent, easy to use, and accessible in most situations. It also is highly portable, at least for short reports.

Paper also has several rather significant drawbacks. It is inflexible. Once the report is printed, it cannot be sorted or reformatted to present a different view of the information. Likewise, if the information on the report changes, the entire report must be reprinted. Paper reports are expensive, are hard to duplicate, and require considerable supplies (paper, ink) and storage space. Paper reports are also hard to quickly move long distances (e.g., from a head office in Toronto to a regional office in Bermuda).

Many organizations are therefore moving to electronic production of reports, whereby reports are “printed,” but stored in electronic format on file servers or Web servers so that users can easily access them. Often, the reports are available in more predesigned formats than are their paper-based counterparts, because the cost of producing and storing different formats is minimal. Electronic reports also can be produced on demand as needed, and they enable the user to search more easily for certain words. Furthermore, electronic reports can provide a means to support ad hoc reports when users customize the contents of the report at the time the report is generated. Some users may still print the electronic report on their own printers. The reduced cost of electronic delivery over distance and improved user access to the reports usually offsets the cost of local printing.

FIGURE 9-17 Types of Reports

CONCEPTS IN ACTION: 9-C SELECTING THE WRONG STUDENTS

I helped a university department develop a small decision support system to analyze and rank students who applied to a specialized program. Some of the information was numeric and could easily be processed directly by the system (e.g., grade point average, standardized test scores). Other information required the faculty to make subjective judgments among the students (e.g., extracurricular activities, work experience). The users entered their evaluations of the subjective information via several data analysis screens in which the students were listed in alphabetical order.

In order to make the system “easier to use,” the reports listing the results of the analysis were also presented in alphabetical order by student name, rather than in order from the highest ranked student to the lowest ranked student. In a series of tests prior to installation, the users selected the wrong students to admit in 20 percent of the cases. They assumed, wrongly, that the students listed first were the highest ranked students and simply selected the first students on the list for admission. Neither the title on the report, nor the fact that all the students' names were in alphabetical order made them realize that they had read the report incorrectly. Alan Denis

QUESTION:

What concerns could this problem raise about the rest of the system?

CONCEPTS: 9-D CUTTING PAPER TO SAVE MONEY

One of the Fortune 500 firms with which I have worked had an 18-story office building for its world headquarters. It devoted two full floors of this building to nothing more than storing “current” paper reports (a separate warehouse was maintained outside the city for “archived” reports such as tax documents). Imagine the annual cost of office space in the headquarters building tied up in these paper reports. Now imagine how a staff member would gain access to the reports, and you can quickly understand the driving force behind electronic reports, even if most users end up printing them. Within one year of switching to electronic reports (for as many reports as practical) the paper report storage area was reduced to one small storage room.

Alan Vernis

QUESTION:

What types of reports are most suited to electronic format? What types of reports are less suited to electronic reports?

Reference

Badre, Albert N. (2002) Shaping Web Usability: Interaction Design in Context. Addison-Wesley Professional.

W11.Safari.References.docx

W11.Safari.References

Ctrl+Click the following links to go to their place in this document

· Total Quality Management

· Structure Charts

· Elements of an Architecture Design (Go to the section “Client–Server Architectures”)

· Elements of an Architecture Design (Go to the section “Cloud Computing”)

· Moving into Implementation

· Managing the Programming Process

· Testing

· Developing Documentation

· Making the Transition to the New System

· The Migration Plan

· Postimplementation Activities

Total Quality Management

The most popular quality concept in the manufacturing industry today is total quality management (TQM). Almost all professionally managed manufacturing companies have implemented TQM and practice it diligently. The software development industry, knowingly or unknowingly, leapfrogged into TQM through process quality certifications such as ISO and CMMI®. ISO defines TQM as “a management approach for an organization, centered on quality, based on the participation of all its members, and aiming at long-term success through customer satisfaction and benefits to all members of the organization and to society.”

TQM is an organization-wide quality initiative, which means it involves the entire organization in the management of quality. One major aim of TQM is to reduce process variation within the organization. In Japan, TQM includes four steps:

1. Kaizen—Focus on continuous process improvement, to make every process in the organization visible, repeatable, and measurable.

2. Atarimae hinshitsu—Belief that products will function as they are designed to function.

3. Kansei—Study the way a user uses the product, to facilitate improvement of the product.

4. Miryoketuki hinshitsu—Belief that products should have aesthetic value along with usability. For example, a car needs to look attractive in addition to its capability to transport people.

TQM advocates quality standards in all aspects of organizational functioning, as well as the philosophy of “do it right the first time.” It also recommends elimination of waste in all its forms. As it stands today, TQM is adopted to some degree in organizations that have quality assurance at their heart, with inspection, testing, and standards implemented thoroughly and consistently.

Although the concept of quality was developed in manufacturing organizations, all of the concepts discussed above are relevant to software development organizations as well.

Structure Charts

The structure chart is an important technique that helps the analyst design the program for the new system. The structure chart shows all the components of code that must be included in a program at a high level, arranged in a hierarchical format that implies sequence (in what order components are invoked), selection (under what condition a module is invoked), and iteration (how often a component is repeated). The components are usually read from top to bottom, left to right, and they are numbered by a hierarchical numbering scheme in which lower levels have an additional level of numbering (e.g., the third level of modules would be numbered 1.1.1, 1.1.2, 1.1.3).

Structure charts historically have been used to create transaction-based mainframe applications, which have many lines of code that must be carefully monitored. They help analysts create programs that are easy to understand and maintain, because the use of self-contained modules keeps changes from rippling throughout the programs. We believe that structure charts can be helpful in the building of many types of systems because they emphasize structure and reusability, characteristics of any good program.

Suppose that an academic system needs a program that will print a listing of students along with their grade point averages (GPAs), both for the current semester and overall. First, the program must retrieve the student grade records; then it must calculate the current and cumulative GPAs; finally, the grade list can be printed. The structure chart shown in Figure 10-6 communicates the basic components of this program and shows the interrelatedness of the modules. For example, by looking at this structure chart, a programmer can tell that there are four main code modules involved in creating a student grade listing: getting the student grade records, calculating current GPA, calculating cumulative GPA, and printing the listing. Also, there are various pieces of information that are either required by each module or created by it (e.g., the grade record, the cumulative GPA). The sections that follow use this example to describe each component of the structure chart.

Syntax

Module A structure chart is composed of modules (lines of program code that perform a single function) that work together to form a program (Figure 10-7). The modules are depicted by a rectangle and connected by lines, which represent the passing of control. A control module is a higher-level component that contains the logic for performing other modules, and the components that it calls and controls are considered subordinate modules. For example, in Figure 10-6, module 1.0 is the control module that directs modules 1.1 through 1.4 as its subordinates.

FIGURE 10-6 Structure Chart Example (GPA = grade point average)

At times, modules are reused. These modules, called library modules, have vertical lines on both sides of the rectangle to communicate that they will appear several times on the structure chart (see Figure 10-7). The library module in Figure 10-6 is module 1.1, get student grade record, and this module is a generic module that will be depicted several times in other parts of the diagram. Library modules are highly encouraged because their reusability can save programmers from rewriting the same piece of code over and over again.

The lines that connect the modules communicate the passing of control. In Figure 10-6, the control is linear, whereby all of the modules are performed in order from top to bottom, left to right. There are two symbols that describe special types of control that can appear on the structure chart. The curved arrow, or loop, indicates that the execution of some or all subordinate modules is repeated, and a conditional line (depicted by a diamond) denotes that execution of one or more of the subordinate modules occurs in some cases but not in others. (See Figure 10-7.)

Look at the structure chart in Figure 10-8 and see how the loops and conditional line affect the meaning of the diagram. First, the loop through the lines to modules 1.1, 1.2, and 1.3 means that, before the next two modules are invoked, the first three modules will be repeated until their functionality is completed (i.e., all of the student grades will be read and the two GPAs will be calculated before moving to the print modules). Second, the lines connected by the conditional line convey that both the dean's list report and grade listing are not printed each time this program is run, but instead are performed upon the basis of some condition. Therefore, there are times when one or both of the print modules may not be invoked.

Another new symbol found on the structure chart in Figure 10-8 is the connector. (See Figure 10-7.) Structure charts can become quite unwieldy, especially when they depict a large or complex program. A circle is used to connect parts of the structure chart when there are space constraints and a diagram needs to be continued on another part of the page (i.e., an on-page connector), and a hexagon is used to continue the diagram on another page entirely (i.e., an off-page connector).

FIGURE 10-7 Structure Chart Elements

FIGURE 10-8 Revised Structure Chart Example

In Figure 10-8, notice that modules 1.4 and 1.5 are depicted on another page of the diagram.

Couples Couples, shown by arrows, are drawn on the structure chart to show that information is passed between modules, with the arrowhead indicating which way the information is being sent. (See Figure 10-7.) Data couples, shown by arrows with empty circles, are used to represent the passing of pieces of data or data structures to other modules. For example, in Figure 10-8, a student grade record must be sent to module 1.2 for the GPA to be calculated, so a data couple is used to show the grade data structure being passed along.

Control couples, drawn with the use of arrows with filled-in circles, are used to pass parameters or system-related messages back and forth among modules. If some type of parameter needed to be passed (e.g., the customer is a new customer; the end of a file has been reached), a control couple (also called a flag) would be used. In Figure 10-8, module 1.1 sends an end-of-file parameter when the program reaches the end of the student grade file.

In general, control flags should be passed from subordinates to control modules, but not the other way around. Control flags are passed so that the control modules can make decisions about how the program will operate (e.g., module 1.1 passes the end-of-file marker to indicate that all records have been processed). Passing a control flag from higher to lower modules suggests that a lower-level module has control over the higher-level module.

The presence of couples signals that modules on the structure chart depend on each other in some way. A general rule is to be very conservative when applying couples to your diagram. In a later section, we will discuss style guidelines for couples to help you determine “good” from “bad” coupling situations.

Building the Structure Chart

Now that you understand the individual components of the structure chart, the next step is to learn how to put them together to form an effective design for the new system. Many times, process models are used as the starting point for structure charts. There are three basic kinds of processes on a process model: afferent, central, and efferent. Afferent processes are processes that provide inputs into the system, central processes perform critical functions in the operation of the system, and efferent processes deal with system outputs. Identify these three kinds of processes in Figure 10-9.

Each process of a DFD tends to represent one module on the structure chart, and if leveled DFDs are used, then each DFD level tends to correspond to a different level of the structure chart hierarchy (e.g., the process on the context-level DFD would correspond to the top module on the structure chart).

The difficulty comes when determining how the components on the structure chart should be organized. As we mentioned earlier, the structure chart communicates sequence, selection, and iteration, but none of these concepts is depicted explicitly in the process models. It is up to the analyst to make assumptions from the DFDs and read the process model descriptions to really understand how the structure chart should be drawn.

FIGURE 10-9 Transform and Transaction Structures

Transaction Structure Luckily, there are two basic arrangements, or structures, for combining structure chart modules. The first arrangement is used when each module performs one of a group of individual transactions. This transaction structure contains a control module that calls subordinate modules, each of which handles a particular transaction. Pretend that Figure 10-10 illustrates the highest level of a student grade system. Module 1 is the control module that accepts a user's selection for what activity needs to be performed (e.g., maintain grade), and depending on the choice, one of the subordinate modules (1.1 through 1.4) is invoked. Transaction structures often occur where the actual system contains menus or submenus, and they are usually found higher up in the levels of a structure chart.

If the project team has used leveled DFDs to illustrate the processes for the system, the high levels of the DFD usually represent activities that belong in a transaction structure. In the current example, student grade system could correspond to the single process on the context-level DFD, and the four modules (1.1 through 1.4) would be the four processes on the level 0 diagram. If a leveled DFD approach is not used, then it may be a bit more difficult to differentiate a control module from its subordinates by using the process model. One hint is to look for points on the DFD in which a single data flow enters a process that produces multiple data flows as output—this usually indicates a transaction structure. See Figure 10-9 for an example of a process model that has transaction structure; notice how it contains many efferent processes and few afferent processes.

Transform Structure A second type of module structure, called a transform structure, has a control module that calls several subordinate modules in sequence, after which something “happens.” These modules are related because together they form a process that transforms some input into an output. Often, each module accepts an input from the module preceding it, works on the input, then passes it to the next module for more processing. For example, Figure 10-8 shows a control module that calls five subordinates. The control module describes what the subordinates will do (e.g., create student grade listing), and the subordinates are invoked from left to right and transform the student grade records into two types of listings for student grades.

FIGURE 10-10 Transaction Structure

In a leveled DFD, the lowest levels usually represent transform structures. If a leveled DFD approach is not used, then you should look for the processes on the DFD for which an input is changed into an output of a different form. In this situation, the process in which the change is made likely will become a control module. All the processes leading up to the control module are subordinates that are performed first by the control module, followed by the processes that come after the control module. See Figure 10-9 for an example of transform structure; notice how there are many afferent processes and few efferent processes.

Applying the Concepts at Tune Source

Now that you are familiar with the basic components of the structure chart, the best way to learn how to build the diagram is to walk through an example that shows how to create one. Creating a structure chart is usually a four-step process. First, the analyst identifies the top-level modules and then decomposes them into lower levels. (This process is similar in some ways to identifying high-level processes in a DFD and then decomposing them into lower-level processes.) Second, the analyst adds the control connections among modules, such as loops and conditional lines that show when modules call subordinates. Third, he or she adds couples, the information that modules pass among themselves. Finally, the analyst reviews the structure chart and revises it again and again until it is complete.

The goal for this example is to create a structure chart that contains the modules of code that need to be programmed and shows how they need to be organized. The physical process model can be used as its starting point. Although it may neither map exactly into the future program nor contain enough levels of detail, the DFD will form a good rough-draft structure chart that can then be changed and improved. The requirements definition and use cases will provide additional detail. Let's walk through a structure chart example for Tune Source.

Step 1: Identify Modules and Levels First, identify the modules that belong on the diagram by converting the DFD processes into structure chart modules. Modules should perform only one function, so if, for some reason, a process contains more than one function, it should be broken into more than one module.

The various levels of the DFD generally translate into different levels of the structure chart. Look back at the DFDs that we created for Tune Source in Chapter 5 (Figures 5-15 through 5-20). The context-level DFD (the overall system) is placed at the top of the structure chart in Figure 10-11 to represent the overall control module of the system that manages the highest level of system functions. Then, the level 0 DFD processes are placed below it as subordinates. You should recognize that this particular structure of modules is a transaction structure, because the subordinates represent different functions that can be called by the control module.

This pattern continues through all the DFD levels. For example, the level 1 DFD that we created for the search and browse tunes process is placed below the search and browse tunes process control module. The subordinate modules are load Web site, process search requests, and process tune selection, the three processes from the search and browse tunes process level 1 DFD. Note that this structure of modules is a transform structure because the subordinate modules are carried out in a sequence to perform the process that is represented by the control module, search and browse tunes (Figure 10-11).

FIGURE 10-11 Step 1: Identify Modules and Levels for the Structure Chart

Likely, you will need to include additional levels of detail to the structure chart, until modules have enough detail so that they each perform only one function. Additional detail for the structure can be found within the use cases (Chapter 4) and requirements definition (Chapter 3) for the system. For example, if you read the use case for the search and browse tunes process in Figure 4-14, notice that step 3 includes listening to a sample, adding the tune to the Favorites list, and selecting the tune to buy. Modules have been added to the last row of Figure 10-11 to reflect our detailed understanding of these processes.

Finally, you must determine whether any modules on the diagram are reusable; if they are, they should be represented as library modules. In this particular portion of the structure chart, Jason has marked two modules as library modules, with vertical lines on the sides. He believes that these modules currently exist in the CD sales system and can be reused in this system.

Step 2: Identify Special Connections The next step is to add loops and conditional lines to represent modules that are repeated or optional. For example, a customer of the Digital Music Download system can search for multiple tunes. Thus in Figure 10-12, we place a curved arrow around the line under the search and browse tunes process to show that modules 1.1.1 through 1.1.3 can be repeated several times. Can you think of other modules on the structure chart that will be iterated? According to Figure 10-12, one module under the process payment process also can happen several times before the system will accept payment information from the customer.

A diamond is placed below a control module that directs subordinates, which may or may not be performed. For example, customers may choose to listen to a tune sample, add it to the Favorites list, or buy it—they do not necessarily use all three alternatives. So a diamond is added below the process tune selection module to communicate this to the programmer. What other part of the structure chart contains subordinates that are invoked conditionally?

Step 3: Add Couples Next, we must identify the information that has to pass among the modules. This information can be data attributes (denoted by an arrow with an empty circle) or special control parameters (denoted by an arrow with a filled-in circle). The arrowheads on the arrows indicate which way information is passed along. The DFD data flows provide us with some guidance about the couples to add, because the information that flows in and out of the DFD processes likely will also flow in and out of the corresponding structure chart modules.

We will illustrate the addition of couples to our structure chart by focusing just on the purchase tunes module and its subordinate modules. The DFD in Figure 5-19 shows that a new customer can provide customer information or can access existing customer information by signing in to his or her account. Therefore, one module on our structure chart (1.2.1) returns customer details for new customers, and one module (1.2.2) returns customer details for customers having existing accounts. The driver module (1.2 Purchase Tunes) calls the correct subordinate, depending on the existence of a customer account for the customer. The driver module then calls the process payment module (1.2.3). This module repeatedly calls its subordinate module, gather purchased tunes (1.2.3.1), to find all tunes the customer wants to purchase. These are then passed to the compute amount due module (1.2.3.2), which returns that result. Library module accept payment info (1.2.3.3) returns the customer's payment information, which is then used by the get payment authorization library module (1.2.3.4). A control couple is returned by that module, indicating the result of the authorization step. The process payment module (1.2.3) returns the authorized payment data couple to its parent module, purchase tunes (1.2). The purchase tunes module calls the confirm purchase module (1.2.4) to obtain the customer's purchase confirmation, shown as a control couple. Finally, information about the purchased tune(s) is passed to the release download module (1.2.5) to complete the customer's purchase.

FIGURE 10-12 Step 2: Add Special Connections to the Structure Chart

Revise Structure Chart By now we have created the initial version of the structure chart based on the DFDs, use cases, and requirements definition, but rarely is a structure chart completed in one attempt. There are many gray areas and decisions that need to be confirmed by other information gleaned during analysis. There are several tools that can help when we are fine-tuning the structure chart. First, we can look at the process descriptions in the CASE repository to see whether there are any details of the processes that haven't yet been captured on the diagram. The process descriptions may uncover couples that were overlooked or explain more about how modules should be broken down. Second, we can examine the data model to confirm that the right records and specific fields have been passed using the data couples. This exercise also will confirm that data being passed are actually being captured by the system.

As with most diagrams about which you have learned, the structure chart will evolve and contain more detail as new information is uncovered over the course of the project. Structure charts are not easy. The example that we have presented is much more straightforward than charts found in the real world. The following section explains some guidelines and good practices that you should apply to the chart as you work to improve it:

Design Guidelines

As you construct a structure chart, there are several guidelines that you can use to improve its quality. High-quality structure charts result in programs that are modular, reusable, and easy to implement. Measures of good design include cohesion, coupling, and appropriate levels of fan-in and/or fan-out.

Build Modules with High Cohesion Cohesion refers to how well the lines of code within each structure chart module relate to each other. Ideally, a module should perform only one task, making it highly cohesive. Cohesive modules are easy to understand and build because their code performs one function, and they are built to perform that function very efficiently. The more tasks that a module has to perform, the more complex the logic in the code must be to implement the tasks correctly. Typically, you can detect modules that are not cohesive from titles that have an and in them, signaling that the module performs multiple tasks.

YOUR TURN: 10-1 STRUCTURE CHART

Using the structure chart in Figure 10-13 as a starting point, add modules that correspond to other parts of the Digital Music Download system. Use the data flow diagrams in Chapter 5 and the use case in Chapter 4 to help you.

QUESTION:

Do the modules that you added have a transform structure or a transaction structure—or both? Add any special connections to the chart as appropriate. Add necessary data and control couples.

FIGURE 10-13 Step 3: Add Couples to the Structure Chart

Look back at the example in Figure 10.6. Currently, each module has good cohesion. Imagine, however, that module 1.3 actually said calculate current and cumulative GPA and that module 1.4 was print grade listing and dean s list. The and in both cases would signal a problem. These modules would not be considered cohesive, because they each perform two different tasks, limiting the flexibility of the modules and making the modules much more difficult to build and understand. If the program had to calculate only the current GPA while the module performed both functions, it would require much more complex logic in the code to make that happen.

Another signal of poor cohesion is the presence of control flags that are passed down to subordinate modules; their presence suggests that the subordinate has multiple functions from which one is chosen. Placing this kind of power in a subordinate module is not advisable, because it requires complex logic within the module to determine what functions to perform. In the previous example, if our subordinate module were print grade listing and dean s list, then a control flag would need to be sent to the subordinate module so that it could determine which report (or both) to print; the subordinate would have to make decisions regarding how to perform its functions.

There are various types of cohesion, some of which are better than others. For example, functional cohesion occurs when all elements of the module contribute to performing a single task, and this form of cohesion is highly desirable. By contrast, temporal cohesion takes place when functions within a module may not have much in common other than being invoked at the same time, and coincidental cohesion occurs when there is no apparent relationship among a module's functions (definitely something to avoid). Figure 10-14 lists seven types of cohesion, along with examples of each type. If you have difficulty differentiating different types of cohesion, use the decision tree in Figure 10-15 for guidance.

Factoring is the process of separating out a function from one module into a module of its own. If you find that a module is not cohesive or that it displays characteristics of a “bad” form of cohesion, you can apply factoring to create a better structure. For example, a more cohesive design for the print grade listing and dean s list example would be to factor out print dean's list and print grade listing into two separate modules. A control flag is not needed for this approach because subordinate modules would not have to make any kind of decision; each would perform one task—to print a report.

Build Loosely Coupled Modules Coupling involves how closely modules are interrelated, and the second guideline for good structure chart design states that modules should be loosely coupled. In this way, modules are independent from each other, which keeps code changes from rippling throughout the program. The numbers and kinds of couples on the structure chart reveal the presence of coupling between modules. Basically, the fewer the arrows on the diagrams, the easier it will be to make future alterations to the program.

Notice the coupling in the structure chart in Figure 10-8. The data couples (e.g., grade record) denote data that are passed among modules, and the control couple (e.g., end of file) shows that a message is being sent. Although the modules are communicating with one another, notice that the communication is quite limited (only one data couple passed in and out of the module) and there are no superfluous couples (data that are passed for no reason).

There are five types of coupling, each falling on different parts of a good-to-bad continuum. Data coupling occurs when modules pass parameters or specific pieces of data to each other, and this is a form of coupling that you want to see on your structure chart. A bad coupling type is content coupling, whereby one module actually refers to the inside of another module. Figure 10-16 presents the types of coupling and examples of each type.

Create High Fan-In Fan-in describes the number of control modules that communicate with a subordinate; a module with high fan-in has many different control modules that call it. This is a very good situation because high fan-in indicates that a module is reused in many places on the structure chart, which suggests that the module contains well-written generic code. (Fan-in also occurs when library modules are used.) Structures with high fan-in improve the reusability of modules and make it easier for programmers to recode when changes are made or mistakes are uncovered, because a change can be made in one place. Figures 10-17a and 10-17b show two different approaches for representing the functionality of reading an employee record. Example a is better.

FIGURE 10-14 Types of Cohesion (GPA = grade-point average)

FIGURE 10-15 Cohesion Decision Tree (Adapted from Page-Jones, 1980)

Avoid High Fan-Out Although we desire a subordinate to have multiple control modules, we want to avoid a large number of subordinates associated with a single control. Think of the management concept “span of control,” which states that there is a limit to the number of employees that a boss can effectively manage. This concept applies to structure charts as well, in that a control module will become much less effective when given large numbers of modules to control. The general rule of thumb is to limit a control module's subordinates to approximately seven. One exception to this is a control module within a transaction structure. If a control module coordinates the invocation of subordinates, each of which performs unique functions, then it usually can handle whatever number of transactions exist. Figures 10-17c and 10-17d show high and low fan-out situations, respectively.

Assess the Chart for Quality Finally, we have compiled a checklist (Figure 10-18) that may help you assess the quality of your structure chart. In addition, you should be aware that some CASE tools will critique the quality of your structure chart by using predetermined heuristics. Visible Analyst Workbench, for example, checks to make sure that all modules are labeled and connected and that data couples are labeled. It then reviews the connections between modules for correctness of connection, complexity of interface, and completeness of design. The analyzer gives warnings for low fan-in and high fan-out situations.

FIGURE 10-16 Types of Coupling (GPA = grade-point average)

FIGURE 10-17 Examples of Fan-In and Fan-Out: (a) High Fan-In; (b) Low Fan-In; (c) High Fan-Out; (d) Low Fan-Out (IRA individual retirement account)

FIGURE 10-18 Checklist for Structure Chart Quality

Elements of an Architecture Design

ELEMENTS OF AN ARCHITECTURE DESIGN

The objective of architecture design is to determine how the software components of the information system will be assigned to the hardware devices of the system. In this section, we first discuss the major functions of the software to understand how the software can be divided into different parts. Then we briefly discuss the major types of hardware onto which the software can be placed. Although there are numerous ways in which the software components can be placed on the hardware components, the most common architecture is the client–server architecture, so we focus on it here.

Architectural Components

The major architectural components of any system are the software and the hardware. The major software components of the system being developed have to be identified and then allocated to the various hardware components on which the system will operate. Each of these components can be combined in a variety of different ways.

All software systems can be divided into four basic functions. The first is data storage. Most information systems require data to be stored and retrieved, whether a small file, such as a list of lawn chemicals that are no longer authorized for residential applications, or a large database that stores an organization's human resources records. These are the data entities documented in ERDs. The second function is the data access logic: the processing required to access data, often meaning database queries in Structured Query Language (SQL). The third function is the application logic: the logic documented in the DFDs, use cases, and functional requirements. The fourth function is the presentation logic: the display of information to the user and the acceptance of the user's commands (the user interface). These four functions (data storage, data access logic, application logic, and presentation logic) are the basic building blocks of any information system.

The three primary hardware components of a system are client computers, servers, and the network that connects them. Client computers are the input–output devices employed by the user and are usually desktop or laptop computers, but can also be handheld devices, smartphones, special-purpose terminals, and so on. Servers typically are larger multi-user computers used to store software and data that can be accessed by anyone who has permission. The network that connects the computers can vary in speed from slow cell phones or modem connections that must be dialed, to medium-speed always-on frame relay networks, to fast always-on broadband connections such as cable modem, DSL, or T1 circuits, to high-speed always-on Ethernet, T3, or ATM circuits.2

Client–Server Architectures

Most organizations today are utilizing or moving to client–server architectures, which attempt to balance the processing between client devices and one or more server devices. In these architectures, the client is responsible for the presentation logic, whereas the server is responsible for the data access logic and data storage. The application logic may reside on the client, reside on the server, or be split between both (Figure 8-1). If the client shown in Figure 8-1 contained all or most of the application logic, it is called a thick or fat client. Currently, thin clients, containing just a small portion of the application logic, are popular because of lower overhead and easier maintenance. For example, many Web-based systems are designed with the Web browser performing presentation and only minimal application logic using such programming languages as JavaScript, while the server side has most of the application logic, all of the data access logic, and all of the data storage.

FIGURE 8-1 Two-Tiered Client–Server Architecture

Client–server architectures have four important benefits. First and foremost, they are scalable. That means it is easy to increase or decrease the storage and processing capabilities of the servers. If one server becomes overloaded, you simply add another server so that many servers are used to perform the application logic, data access logic, or data storage. The cost to upgrade is gradual, and you can upgrade in small increments.

Second, Client–server architectures can support many different types of clients and servers. It is possible to connect computers that use different operating systems so that you are not locked into one vendor. Users can choose which type of computer they prefer (e.g., combining both Windows computers and Apple Macintoshes on the same network). Middleware is a type of system software designed to translate between different vendors' software. Middleware is installed on both the client computer and the server computer. The client software communicates with the middleware, which can reformat the message into a standard language that can be understood by the middleware, which assists the server software.

Third, for thin Client–server architectures that use Internet standards, it is simple to clearly separate the presentation logic, the application logic, and the data access logic and design each to be somewhat independent. For example, the presentation logic can be designed in HTML or XML to specify how the page will appear on the screen (e.g., the colors, fonts, order of items, specific words used, command buttons, type of selection lists, and so on; see Chapter 9). Simple program statements are used to link parts of the interface to specific application logic modules that perform various functions. These HTML or XML files defining the interface can be changed without affecting the application logic. Likewise, it is possible to change the application logic without changing the presentation logic or the data, which are stored in databases and accessed by SQL commands.

Finally, if a server fails in a Client–server architecture, only the applications requiring that server will fail. The failed server can be swapped out and replaced and the applications can then be restored.

Client–server architectures also have some critical limitations, the most important of which is their complexity. All applications in Client–server computing have two parts, the software on the client side and the software on the server side. Writing this software is more complicated than writing the traditional all-in-one software used in server-based architectures (discussed in a later section). Updating the overall system with a new version of the software is more complicated, too. With Client–server architectures, you must update all clients and all servers and you must ensure that the updates are applied on all devices.

Client–server Tiers

There are many ways in which the application logic can be partitioned between the client and the server. The arrangement in Figure 8-1 is a common configuration.

FIGURE 8-2 Three-Tiered Client–server Architecture

In this case, the server is responsible for the data and the client is responsible for the application and presentation. This is called a two-tiered architecture because it uses only two sets of computers—clients and servers.

A three-tiered architecture uses three sets of computers, as shown in Figure 8-2. In this case, the software on the client computer is responsible for presentation logic, an application server(s) is responsible for the application logic, and a separate database server(s) is responsible for the data access logic and data storage. Typically, the user interface runs on a desktop PC or workstation and uses a standard graphical user interface. The application logic may consist of one or more separate modules running on a workstation or application server. Finally, a relational DBMS running on a database server contains the data access logic and data storage. The middle tier may be divided into tiers itself, resulting in an overall architecture called an “n-tier architecture”.

An n-tiered architecture distributes the work of the application (the middle tier) among multiple layers of more specialized server computers. This type of architecture is common in today's Web-based e-commerce systems. See Figure 8-3. The browser software on client computers makes HTTP requests to view pages from the Web server(s), and the Web server(s) enable the user to view merchandise for sale by responding with HTML documents. As the user shops, components on the application server(s) are called as needed to allow the user to put items in a shopping cart; determine item pricing and availability; compute purchase costs, sales tax, and shipping costs; authorize payments, etc. These elements of business logic, or detailed processing, are stored on the application server(s) and are accessible to any application. For example, the cash register application that needs item price look-ups could use the same price determination business logic that is used by the e-commerce Web site. The modular business logic can be used by multiple, independent applications that need that particular business logic. The database server(s) manage the data components of the system. Each of these four components is separate, which makes it easy to spread the different components on different servers and to partition the application logic on a Web-oriented server and a business-oriented server.

The primary advantage of an n-tiered Client–server architecture compared with a two-tiered architecture (or a three-tiered with a two-tiered) is that it separates out the processing that occurs to better balance the load on the different servers; it is more scalable. In Figure 8-3, we have three separate server types, a configuration that provides more power than if we had used a two-tiered architecture with only one server. If we discover that the application server is too heavily loaded, we can simply replace it with a more powerful server or just put in several more application servers to share the load. Conversely, if we discover that the database server is underused, we could store data from another application on it.

FIGURE 8-3 n-Tiered Client–server Architecture

There are two primary disadvantages to an n-tiered architecture compared with a two-tiered architecture (or a three-tiered with a two-tiered). First, the configuration puts a greater load on the network. If you compare Figures 8-1, 8-2, and 8-3, you will see that the n-tiered model requires more communication among the servers; it generates more network traffic, so you need a higher-capacity network. Second, it is much more difficult to program and test software in n-tiered architectures than in two-tiered architectures, because more devices have to communicate properly to complete a user's transaction.

Less Common Architectures

The Client–server architecture has become the predominant architecture in use today. Two other architectures are less commonly found, but still used in certain situations.

Server-Based Architectures The very first computing architectures were server-based, with the server (usually, a central mainframe computer) performing all four application functions. The clients (usually, terminals) enabled users to send and receive messages to and from the server computer. The clients merely captured keystrokes and sent them to the server for processing, and accepted instructions from the server on what to display (Figure 8-4).

FIGURE 8-4 Server-Based Architecture

This very simple architecture often works very well. Application software is developed and stored on the server, and all data are on the same computer. There is one point of control because all messages flow through the one central server. Software development and software administration are simplified because a single computer hosts the entire system (operating system and application software).

The server-based architecture was the first architecture used in information systems, but did not remain the only option as hardware and software evolved. The fundamental problem with early server-based systems was that the server processed all the work in the system. As the demands for more and more applications and the number of users grew, server computers became overloaded and unable to quickly process all the users' demands. Response time became slower, and IS managers were required to spend increasingly more money to upgrade the server computer. In the early days, upgrading to a larger server computer (usually a mainframe) required a substantial financial commitment. Increased capacity came only in large, expensive chunks.

Today, the server-based architecture remains a viable architecture choice. Zero client, or ultrathin client, is a server-based computing model that is often used today in a virtual desktop infrastructure (VDI). A typical zero client device is a small box that connects a keyboard, mouse, monitor, and Ethernet connection to a remote server. The server hosts everything: the client's operating system and all software applications. The server can be accessed wirelessly or with cable.

Zero client computing has a number of benefits. Power usage can be significantly reduced compared to fat client configurations. This benefit is increasing in importance as more companies are investigating green computing. The devices used are much less expensive than PCs or even thin client devices. Since there is no software at the client device, there is no vulnerability to malware. The zero client computing model provides an efficient and secure way to deliver applications to end users. Administration is easy and multiple virtual PCs can be run on server class hardware in VDI environments, significantly reducing the number of physical PCs that must be acquired and maintained. In addition, the server-based zero-client model limits the non-business use of the client computer (e.g., no Facebook; no Farmville, etc.).

Client-Based Architectures With client-based architectures, the clients are microcomputers on a local area network, and the server is a server computer on the same network. The application software on the client computers is responsible for the presentation logic, the application logic, and the data access logic; the server simply provides storage for the data (Figure 8-5).

FIGURE 8-5 Client-Based Architecture

This simple architecture often works very well in situations with low numbers of users or limited data access requirements. The fundamental problem in the client-based architecture is that all data on the server must travel to the client for processing. For example, suppose that the user wishes to display a list of all employees with company life insurance. All the data in the employee database must travel from the server, where the database is stored, over the network to the client, which then executes the query to find each record that matches the data requested by the user. In the other computing models we have discussed, the data access logic would be executed on the server and only the results of the query transmitted to the client. In the client-based computing model, the data access logic is executed on the client system. Therefore, the entire database must be transmitted to the client before processing can take place. This can overload both the network and the power of the client computers.

Elements of an Architecture Design

Advances in Architecture Configurations

Advances in hardware, software, and networking have given rise to a number of new architecture options. A detailed discussion of all of these options is beyond the scope of this book. Two advances that are currently getting a lot of attention, visualization and cloud computing, will be described here briefly.

Visualization This term, in the computing domain, refers to the creation of a virtual device or resource, such as a server or storage device. You may be familiar with this concept if you have partitioned your computer's hard drive into more than one separate hard drive. While you only have one physical hard drive in your system, you treat each partitioned, “virtual” drive as if it is a distinct physical hard drive. Today, this term has become a common buzz word, as we hear about server virtualization, storage virtualization, network virtualization, and other variations of virtualization.

Server virtualization involves partitioning a physical server into smaller virtual servers. Software is used to divide the physical server into multiple virtual environments, called virtual or private servers. This capability overcomes the primary limitation of the older style server-based architectures that were based on single, large, expensive, monolithic computers. Today, a physical server device can be used to provide many virtual servers that are independent of each other, but co-reside on the same physical server. Each virtual server runs an operating system and can be rebooted independently of the other virtual servers. Less hardware is required to provide a set of virtual servers as compared to equivalent physical servers, so costs are reduced. This arrangement can also optimize the utilization of the physical server, saving on operational costs.

A recent Gartner survey 3 of mid-sized businesses found that over 75% of midsized businesses intend to make widespread use of server virtualization by 2012. These organizations indicate they are aggressively seeking ways to lower costs, improve utilization, and increase availability, and have found server virtualization to be an important contributor to those goals.

Storage virtualization involves combining multiple network storage devices into what appears to be single storage unit. A storage area network (SAN) uses storage virtualization to create a high-speed subnetwork of shared storage devices. In this environment, tasks such as backup, archiving, and recovery are easier and faster.

Cloud Computing It is no longer necessary for organizations to own, manage, and administer their own computing infrastructure. We are in the midst of the rise of cloud computing, wherein everything, from computing power to computing infrastructure, applications, business processes to personal collaboration— can be delivered as a service wherever and whenever needed. The “cloud” in cloud computing can be defined as the set of hardware, networks, storage, services, and interfaces that combine to deliver aspects of computing as a service. Cloud services include the delivery of software, infrastructure, and storage over the Internet (either as separate components or a complete platform) based on user demand.

Cloud computing can be implemented in three ways: private cloud, public cloud, and hybrid clouds. With public clouds, services are provided “as a service” over the Internet with little or no control over the underlying technology infrastructure. Private clouds offer activities and functions “as a service,” but are deployed over a company intranet or hosted data center. Hybrid clouds combine the power of both public and private clouds. In this scenario, activities and tasks are allocated to private or public clouds as required.

At this time, cloud computing is in its early stages of development. Proponents of cloud computing point to a number of advantages of the cloud computing model. First, when utilizing the cloud, the resources allocated can be increased or decreased based upon demand. This capability, termed elasticity, makes the cloud scalable—the cloud can scale up for periods of peak demand and scale down for times of less demand. Applications in the cloud can scale up as users are added and when the application's requirements change. Second, cloud customers can obtain cloud resources in a straightforward fashion. Arrangements are made with the cloud service provider for a certain amount of computing, storage, software, process, or other resources. After using these resources, they can be released if no longer required. Third, cloud services typically have standardized APIs (application program interfaces). This means that the services have standardized the way that programs or data sources communicate with each other. This capability lets the customer more easily create linkages between cloud services. Finally, the cloud computing model enables customers to be billed for resources as they are used. Usage of the cloud is measured and customers pay only for resources used—much like your use of electricity in your apartment. This feature makes cloud computing very attractive from a financial perspective.

Cloud computing suppliers utilize virtualization as a key enabling technology. For cloud computing customers, however, the point is to outsource IT technology, applications, and skills with a pay per usage model. The concept of cloud computing has captured the attention and imagination of organizations of all sizes. Through the cloud computing model, the power of virtualization is converted into measurable business value.

Although the benefits of the cloud computing model are many (scalability, cost reduction, device independence, performance, and more), it is still in its infancy and companies are still learning how best to utilize it. Recently, Amazon, one of the prominent suppliers of cloud computing, experienced a catastrophic failure that affected hundreds of organizations that use Amazon's cloud services to run their businesses.4 Therefore, organizations should be prepared to carefully structure their cloud computing arrangements and include redundancy in their applications so that the negative consequences of a catastrophic failure are minimized.

Comparing Architecture Options

Most systems are built to use the existing infrastructure in the organization, so often the current infrastructure restricts the choice of architecture. For example, if the new system will be built for a mainframe-centric organization, server-based architecture may be the best option. Other factors like corporate standards, existing licensing agreements, and product/vendor relationships also can mandate the project team's architecture choice. Many organizations now have a variety of infrastructures in use, however, or are actively looking for pilot projects to test new architectures and infrastructures, enabling the project team to select an architecture on the basis of other important factors.

Each of the architectures just discussed has its strengths and weaknesses. Client–server architectures are strongly favored on the basis of the cost of infrastructure (the hardware, software, and networks that will support the application system). The Client–server architecture is highly scalable because servers can be added to (or removed from) the infrastructure when processing needs change. The GUI development tools used to create applications for Client–server architectures can be intuitive and easy to use. The development of applications for these architectures can be fast and painless. Keep in mind, however, that Client–server architectures do involve the added complexity of several layers of hardware (e.g., database servers, Web servers, client workstations) that must communicate effectively with each other. Project teams often underestimate the difficulty associated with creating secure, efficient Client–server applications.

Moving into Implementation

As the design phase is completed, the systems analyst begins to focus on the tasks associated with building the system, ensuring that it performs as designed and developing documentation for the system. Programmers will carry out the time-consuming and costly task of writing programs, while the systems analyst prepares plans for a variety of tests that will verify that the system performs as expected. Several different types of documentation will also be designed and written during this part of the systems development life cycle.

INTRODUCTION

As the implementation phase begins, foremost on people' s minds is construction of the new system. A major component of building the system is writing programs. In fact, some people mistakenly believe that programming is the focal point of systems development. We hope you agree that doing a good, thorough job on the analysis and design phases is essential to a smooth and successful implementation phase.

The implementation phase consists of developing and testing the system' s software, documentation, and new operating procedures. These topics are presented in this chapter. Chapter 13 discusses additional issues that are essential to a successful system implementation, including installation of the new system, selection of the most suitable conversion approach, preparing the organization and the users to adapt to the new system, and ensuring that the system is supported after it is put into production.

Developing the system' s software (writing programs) can be the largest single component of any systems development project in terms of both time and cost. It is generally also the best understood component and may offer the fewest problems of all the aspects of the SDLC. Since the systems analyst is usually not actually doing the programming (programmers are), in this chapter we concentrate our attention on managing the programming process.

While programmers are transforming program specifications into working program code, the systems analysts will be designing a variety of tests that will be performed on the new system. As the programs are finalized, the systems analysts may conduct these tests to verify that the system actually does what it was designed to do. Testing may be a major element of the implementation phase for the systems analysts. (In some organizations, testing is performed by specialized quality assurance personnel.)

During this phase, it is also the responsibility of the systems analysts to finalize the system documentation and develop the user documentation. The final section of this chapter discusses the various types of documentation that must be prepared.

Managing the Programming Process

The programming process is quite well understood and generally flows smoothly. When system development projects fail, it is usually not because the programmers were unable to write the programs. Flaws in analysis, design, or project management are the leading contributors to project failure. In order to ensure that the process of programming is conducted successfully, we discuss several tasks that the project manager must do to manage the programming effort: assigning programming tasks, coordinating the activities, and managing the programming schedule.1

Assigning Programming Tasks

During project planning (Chapter 2), the project manager identified the programming support required for constructing the system in terms of the numbers and skill levels of programmers. Now the project manager must assign program modules to the programming staff. As discussed in Chapter 10, each programming module should be as separate and distinct as possible from the other modules. The project manager first groups together modules that are related. These groups of modules are then assigned to programmers on the basis of their experience and skill level. Experienced, skilled programmers will be assigned the most complex modules, while novice programmers will be given less complex ones.

CONCEPTS IN ACTION: 12-A THE COST OF A BUG

My first programming job in 1977 was to convert a set of application systems from one version of COBOL to another version of COBOL for the government of Prince Edward Island. The testing approach was to first run a set of test data through the old system and then run it through the new system to ensure that the results from the two matched. If they matched, then the last three months of production data were run through both to ensure they, too, matched.

Things went well until I began to convert the gas tax system that kept records on everyone authorized to purchase gasoline without paying tax. The test data ran fine, but the results using the production data were peculiar. The old and new systems matched, but rather than listing several thousand records, the report listed only 50. I checked the production data file and found it listed only 50 records, not the thousands that were supposed to be there.

The system worked by copying the existing gas tax records file into a new file and making changes in the new file. The old file was then copied to tape backup. There was a bug in the program such that if there were no changes to the file, a new file was created, but no records were copied into it.

I checked the tape backups and found one with the full set of data that was scheduled to be overwritten three days after I discovered the problem. The government was only three days away from losing all gas tax records.

Alan Vermis

QUESTION:

What might have happened if this bug hadn't been caught and all gas tax records were lost?

It is quite likely that there will be a mismatch between the available programming skills and the programming skills that are needed to complete the programming. Consequently, the project manager must take steps at this time to ensure that skill deficiencies are eliminated through additional training or through mentoring arrangements with more experienced, skilled programmers. When the required skills are not readily available, the project manager must recognize the need for additional time in the project schedule.

While it will be tempting to speed up the programming process by adding more programming staff to the project, an ironic fact of system development is that the more programmers who are involved, the longer the project will take. As the size of the programming team increases, the need for coordination increases exponentially, and the more coordination that is required, the less time programmers can spend actually writing programs. The best size is the smallest feasible programming team. When projects are so complex that they require a large team, the best strategy is to try to break the project into a series of smaller parts that can function as independently as possible.

Coordinating Activities

Coordination can be done through both high-tech and low-tech means. The simplest approach is to have a weekly project meeting to discuss any changes to the system that have arisen during the past week—or just any issues that have come up. Regular meetings, even if they are brief, encourage the widespread communication and discussion of issues before they become problems.

Another important way to improve coordination is to create and follow standards that can range from formal rules for naming files to forms that must be completed when goals are reached to programming guidelines. (See Chapter 2.) When a team forms standards and then follows them, the project can be completed faster because task coordination is less complex.

The project manager must put mechanisms in place to keep the programming effort well organized. Many project teams set up three “ areas” in which programmers can work: a development area, a testing area, and a production area. These areas can be different directories on a server hard disk, different servers, or different physical locations, but the point is that files, data, and programs are separated on the basis of their status of completion. At first, programmers access and build files within the development area. Then they copy them to the testing area when they are “ finished.” If a program does not pass a test, it is sent back to development. Once all the programs are tested and ready to support the new system, they are copied into the production area—the location where the final system will reside.

Keeping files and programs in different places according to completion status helps manage change control, the action of coordinating a program as it changes through construction. Another change control technique is keeping track of what programs are being changed by whom, through the use of a program log. The log is merely a form on which programmers sign out programs to write, and sign in the programs when they are completed. Both the programming areas and program log help the analysts understand exactly who has worked on what and the program's status. Without these techniques, files can be put into production without the proper testing, two programmers can start working on the same program at the same time, files can be overlooked, and so on. Code management systems are available that facilitate the “ checkout” of programs and maintain various versions of a module.

Many CASE tools are set up to track the status of programs and help manage programmers as they work. In most cases, maintaining coordination is not conceptually complex. It just requires a lot of attention and discipline to track small details.

Managing the Schedule

The time estimates that were produced during the initial planning phase and refined during the analysis and design phases must almost always be refined as the project progresses during construction, because it is virtually impossible to develop an exact assessment of the project' s schedule. As we discussed in Chapter 2, a well-done set of time estimates will usually have a 10% margin of error by the time implementation is reached. It is critical that the time estimates be revised as the construction step proceeds. If a program module takes longer to develop than expected, then the prudent response is to move the expected completion date later by the same amount of time.

One of the most common causes for schedule problems is scope creep. Scope creep occurs when new requirements are added to the project after the system design has been finalized. Scope creep can be very expensive because changes made late in the SDLC can require much of the completed system design (and even programs already written) to be redone. Any proposed change during construction will require the approval of the project manager and should be addressed only after a quick cost—benefit analysis has been done.

Another common cause is the unnoticed day-by-day slippages in the schedule. One module is a day late here; another one, a day late there. Pretty soon these minor delays add up, and the project is noticeably behind schedule. Once again, the key to managing the programming effort is to watch these minor slippages carefully and update the schedule accordingly. It is especially critical to monitor slippage of all tasks on the critical path, since falling behind on these tasks will affect the final completion date for the project.

Typically, a project manager will create a risk assessment that tracks potential risks, along with an evaluation of their likelihood and potential impact. As programming progresses, the list of risks will change as some items are removed and others surface. The best project managers, however, work hard to keep risks from having an impact on the schedule and costs associated with the project.

Testing

Writing programs is a fun, creative activity. Novice programmers tend to get caught up in the development of the programs themselves and are often much less enchanted with the tasks of testing and documenting their work. Testing and documentation aren't fun; consequently, they receive less attention than writing the programs.

PRACTICAL TIP: 12-1 AVOIDING CLASSIC IMPLEMENTATION MISTAKES

In previous chapters, we discussed classic mistakes and how to avoid them. Here, we summarize four classic mistakes in the implementation phase:

1. Research-oriented development: Using state-of-the-art technology requires research-oriented development that explores the new technology, because “ bleeding-edge” tools and techniques are not well understood, are not well documented, and do not function exactly as promised.

Solution: If you use state-of-the-art technology, you should significantly increase the project' s time and cost estimates even if (some experts would say especially if) such technologies claim to reduce time and effort.

2. Using low-cost personnel: You get what you pay for. The lowest-cost consultant or staff member is significantly less productive than the best staff. Several studies have shown that the best programmers produce software six to eight times faster than the least productive (yet cost only 50% to 100% more).

Solution: If cost is a critical issue, assign the best, most expensive personnel; never assign entry-level personnel in an attempt to save costs.

3. Lack of code control: On large projects, programmers must coordinate changes to the program source code (so that two programmers don' t try to change the same program at the same time and one doesn't overwrite the other' s changes). Although manual procedures appear to work (e.g., sending e-mail notes to others when you work on a program to tell them not to work on that program), mistakes are inevitable.

Solution: Use a source code library that requires programmers to check out programs and prohibits others from working on them at the same time.

4. Inadequate testing: The number-one reason for project failure during implementation is ad hoc testing —in which programmers and analysts test the system without formal test plans.

Solution: Always allocate sufficient time in the project plan for formal testing.

Source: Adapted from Rapid Development, Redmond, WA: Microsoft Press, 1996, pp. 29-50, by Steve McConnell.

Programming and testing are very similar to writing and editing, however. No professional writer (or serious student writing an important term paper) would stop after writing the first draft. Rereading, editing, and revising the initial draft into a good paper is the hallmark of good writing. Likewise, thorough testing is the hallmark of professional software developers. Most professional organizations devote more time and money to testing (and to revision and retesting) than to writing the programs in the first place.

The attention paid to testing is justified by the high costs associated with downtime and failures caused by software bugs.2 Software bugs are estimated to cost the U.S. economy $59.5 billion annually.3 One serious bug that causes an hour of downtime can cost more than one year' s salary of a programmer—and how often are bugs found and fixed in an hour? Testing is therefore a form of insurance. Organizations are willing to spend a lot of time and money to prevent the possibility of major failures after the system is installed. Figure 12-1 lists some estimated income losses for several industries that cannot function without their computer systems.

A program is not considered finished until it has passed its testing. For this reason, programming and testing are tightly coupled. Testing is frequently the primary focus of the systems analysts as the system is being constructed. The analysts must resist the temptation to rush into testing as soon as the very first program module is complete, however. Spontaneously testing different events and possibilities without spending time to develop a comprehensive test plan is dangerous, because important tests may be overlooked. If an error does occur, it may be difficult to reproduce the exact sequence of events that cause it. Instead, testing must be performed and documented systematically so that the project team always knows what has and has not been tested.

FIGURE 12-1 Estimated Lost Income Resulting from One Hour of System Downtime, By Industry

The sections that follow describe a number of different types of tests that must be performed prior to installing the new system. Each type of test checks different features and/or scope of the system, until ultimately it is tested for acceptance by the users.

Test Planning

Testing starts with the tester' s developing a test plan that defines a series of tests that will be conducted. Figure 12-2 shows a typical test plan form. A test plan often has 20 to 30 pages, with a separate page for each individual test in the plan. Each individual test has a specific objective, describes a set of very specific test cases to examine, and defines the expected results and the actual results observed. The test objective is taken directly from the program specification or from the program source code. For example, suppose that the program specification stated that the order quantity must be between 10 and 100 cases. The tester would develop a series of test cases to ensure that the quantity is validated before the system accepts it.

It is impossible to test every possible combination of input and situation; there are simply too many possible combinations. In this example of an order quantity that must be between 10 and 100 cases, the test requires a minimum of 3 test cases: one with a valid value (e.g., 15), one with an invalid value too low (e.g., 7), and one with an invalid value too high (e.g., 110). Most tests would also include a test case with a non-numeric value to ensure that the data types were checked (e.g., ABCD). A really good test would include a test case with nonsensical, but potentially valid, data (e.g., 21.4).

In some cases, test cases cannot be conducted by entering data values, but must instead be handled by selecting certain combinations of commands or menu choices. The script area on the test plan is used to describe the sequence of keystrokes or mouse clicks and movements for this type of test.

Not all program modules are likely to be finished at the same time, so the programmer usually writes stubs for the unfinished modules to enable the modules around them to be tested. A stub is a placeholder for a module that usually displays a simple test message on the screen or returns some hardcoded value 5 when it is selected. For example, consider an application system that provides the five standard functions discussed in Chapter 5 for some data objects such as customers, vehicles, or employees: creating, changing, deleting, finding, and printing (whether on the screen or on a printer). Each of these functions could be a separate module that needs to be tested, and in fact, printing might be two separate modules, one for an on-screen list and one for the printer (Figure 12-3).

Suppose that the main menu module in Figure 12-3 was complete. It would be impossible to test it properly without the other modules, because the function of the main menu is to navigate to the other modules. In this case, a stub would be written for each of the other modules. These stubs would simply display a message on the screen when they were activated (e.g., “ Delete item module reached”). In this way, the main menu module could pass module testing before the other modules were completed.

There are four general stages of tests: unit tests, integration tests, system tests, and acceptance tests. Although each application system is different, most errors are found during integration and system testing (Figure 12-4).

FIGURE 12-2 Test Plan

FIGURE 12-3 Testing Separate Modules

FIGURE 12-4 Error Discovery Rates for Different Stages of Tests

YOUR TURN: 12-1 TEST PLANNING FOR AN AUTOMATED TELLER MACHINE

Pretend that you are a project manager for a bank developing software for automated teller machines (ATMs). Develop a unit test plan for the user interface component of the ATM.

Unit Tests

Unit tests focus on one unit—a program or a program module that performs a specific function that can be tested. The purpose of a unit test is to ensure that the module or program performs its function as defined in the program specification. Unit testing is performed after the programmer has developed and tested the code and believes it to be error free. These tests are based strictly on the program specification and may discover errors resulting from the programmer' s misinterpretation of the specifications. Unit tests are often conducted by the systems analyst or, sometimes, by the programmer who developed the unit.

There are two approaches to unit testing: black-box and white-box (Figure 12-5). Black-box testing is the most commonly used. In this case, the test plan is developed directly from the program specification: Each item in the program specification becomes a test, and several test cases are developed for it. White-box testing is reserved for special circumstances in which the tester wants to review the actual program code, usually when complexity is high.

Integration Tests

Integration tests assess whether a set of modules or programs that must work together do so without error. They ensure that the interfaces and linkages between different parts of the system work properly. At this point, the modules have passed their individual unit tests, so the focus now is on the flow of control among modules and on the data exchanged among them. Integration testing follows the same general procedures as unit testing: the tester develops a test plan that has a series of tests. Integration testing is often done by a set of programmers and/or systems analysts.

There are four approaches to integration testing: user interface testing, use scenario testing, data flow testing, and system interface testing. (See Figure 12-5.) Most projects use all four approaches.

System Tests

System tests are usually conducted by the systems analysts to ensure that all modules and programs work together without error. System testing is similar to integration testing, but is much broader in scope. Whereas integration testing focuses on whether the modules work together without error, system tests examine how well the system meets business requirements and its usability, security, and performance under heavy load (see Figure 12-5). It also tests the system' s documentation.

FIGURE 12-5 Types of Tests

Acceptance Tests

Acceptance tests are done primarily by the users with support from the project team. The goal is to confirm that the system is complete, meets the business needs that prompted the system to be developed, and is acceptable to the users. Acceptance testing is done in two stages: alpha testing, in which users test the system using made-up data, and beta testing, in which users begin to use the system with real data and carefully monitor the system for errors. (See Figure 12-5.)

The users' perceptions of the new system will be significantly influenced by their experiences during acceptance testing. Since first impressions are sometimes difficult to change, analysts should strive to ensure that acceptance testing is conducted only following rigorous (and successful) system testing. In addition, listening to and responding to user feedback will be essential in shaping a positive reaction to and acceptance of the new system by the users.

Developing Documentation

There are two fundamentally different types of documentation. System documentation is intended to help programmers and systems analysts understand the application software and enable them to build it or maintain it after the system is installed. System documentation is a by-product of the systems analysis and design process and is created as the project unfolds. Each step and phase produces documents that are essential in understanding how the system is built or is to be built, and these documents are stored in the project binder(s).

User documentation (such as user manuals, training manuals, and online help systems) is designed to help the user operate the system. Although most project teams expect users to have received training and to have read the user manuals before operating the system, unfortunately, this is not always the case. It is more common today—especially in the case of commercial software packages for microcomputers—for users to begin using the software without training or reading the user manuals. In this section, we focus on user documentation 6.

CONCEPTS IN ACTION: 12-B MANAGING A DATABASE PROJECT

A consulting project involved a credit card “ bottom feeder” (let' s call it Credit Wonder). This company bought credit card accounts that were written off as uncollectable debts by major banks. Credit Wonder would buy the write-off accounts for 1 or 2 percent of their value and then would call the owners of the written-off accounts and “ offer a deal” to the credit card account holders.

Credit Wonder wanted a database for these accounts. Legally, it did own them and so could contact the people who had owed the money—but as prescribed in credit law. For example, Credit Wonder could call only during certain hours and no more than once a week, and they had to speak to the actual account holder. Any amount collected over the 1 to 2 percent of the original debt would be considered a gain. In its database, Credit Wonder wanted a history of what settlement was offered, the date the account holder was contacted, and additional notes.

QUESTIONS:

1. How might a systems analyst manage such a system project?

2. Who would the systems analyst need to interview to get the system requirements?

3. How would a database analyst help in structuring the database requirements?

User documentation is often left until the end of the project, which is a dangerous strategy. Developing good documentation takes longer than many people expect, because it requires much more than simply writing a few pages. Producing documentation requires designing the documents (whether paper or online), writing the text, editing them, and testing them. For good-quality documentation, this process usually takes about 3 hours per page (single-spaced) for paper-based documentation or 2 hours per screen for online documentation. Thus, a “ simple” set of documentation such as a 10-page user manual and a set of 20 help screens takes 70 hours. Of course, lower-quality documentation can be produced faster.

The time required to develop and test user documentation should be built into the project plan. Most organizations plan for documentation development to start once the interface design and program specifications are complete. The initial draft of documentation is usually scheduled for completion immediately after the unit tests are complete. This reduces—but doesn't eliminate—the chance that the documentation will need to be changed because of software changes, and it still leaves enough time for the documentation to be tested and revised before the acceptance tests are started.

Although paper-based manuals are still important, online documentation is becoming the predominant form. Paper-based documentation is simpler to use because it is more familiar to users, especially novices who have less computer experience; online documentation requires the users to learn one more set of commands. Paper-based documentation also is easier to flip through to gain a general understanding of its organization and topics and can be used far away from the computer itself.

There are four key strengths of online documentation, however, which all but guarantee its position as the dominant form for the foreseeable future. First, searching for information is often simpler (provided that the help search index is well designed). The user can type in a variety of keywords to view information almost instantaneously, rather than having to search through the index or table of contents in a paper document. Second, the same information can be presented several times in many different formats, so that the user can find and read the information in the most informative way. (Such redundancy is possible in paper documentation, but the cost and intimidating size of the resulting manual make it impractical.) Third, online documentation enables the user to interact with the documentation in many new ways that are not possible with static paper documentation. For example, it is possible to use links or “ tool tips” (i.e., pop-up text; see Chapter 9) to explain unfamiliar terms, and programmers can write “ show me” routines that demonstrate on the screen exactly what buttons to click and what text to type. Finally, online documentation is significantly less expensive to distribute and keep up to date than paper documentation.

Types of Documentation

There are three fundamentally different types of user documentation: reference documents, procedures manuals, and tutorials. Reference documents (also called the help system) are designed to be used when the user needs to learn how to perform a specific function (e.g., updating a field, adding a new record). Typically, people read reference information only after they have tried and failed to perform the function. Writing reference documents requires special care because users are often impatient or frustrated when they begin to read them.

Procedures manuals describe how to perform business tasks (e.g., printing a monthly report, taking a customer order). Each item in the procedures manual typically guides the user through a task that requires several functions or steps in the system. Therefore, each entry is typically much longer than an entry in a reference document.

Tutorials teach people how to use major components of the system (e.g., an introduction to the basic operations of the system). Each entry in the tutorial is typically longer still than the entries in procedures manuals, and the entries are usually designed to be read in sequence, whereas entries in reference documents and procedures manuals are designed to be read individually.

Regardless of the type of user documentation, the overall process for developing it is similar to the process of developing interfaces (see Chapter 9). The developer first designs the general structure for the documentation and then develops the individual components within it.

Designing Documentation Structure

In this section, we focus on the development of online documentation because we believe that it is the most common form of user documentation. The general structure used in most online documentation, whether reference documents, procedures manuals, or tutorials, is to develop a set of documentation navigation controls that lead the user to documentation topics. The documentation topics are the material that users want to read, whereas the navigation controls are the way in which users locate and access a specific topic.

Designing the structure of the documentation begins by identifying the different types of topics and navigation controls that must be included. Figure 12-6 shows a commonly used structure for online reference documents (i.e., the help system). The documentation topics generally come from three sources. The first and most obvious source of topics is the set of commands and menus in the user interface. This set of topics is very useful if the user wants to understand how a particular command or menu is used.

However, users often don' t know what commands to look for or where they are in the system' s menu structure. Instead, users have tasks they want to perform, and rather than thinking in terms of commands, they think in terms of their business tasks. Therefore, the second and often more useful set of topics focuses on how to perform certain tasks, usually those in the use scenarios from the user interface design. (See Chapter 9.) These topics walk the user through the set of steps (often involving several keystrokes or mouse clicks) needed to perform some task.

The third set of topics are definitions of important terms. These terms are usually the entities and data elements in the system, but sometimes they also include commands.

There are five general types of navigation controls for topics, but not all systems use all five types. (See Figure 12-6.) The first is the table of contents that organizes the information in a logical form, as though the users were to read the reference documentation from start to finish. The second, the index, provides access into the topics via important keywords, in the same way that the index at the back of a book helps you to find topics. Third, text search provides the ability to search through the topics either for any text the user types or for words that match a developer-specified set of words that is much larger than the list of words in the index. Unlike the index, text search typically provides no organization to the words (other than alphabetic). Fourth, some systems provide the ability to use an intelligent agent to help in the search. The fifth and final navigation control to topics are the Web-like links between topics that enable the user to click and move among topics.

FIGURE 12-6 Organizing Online Reference Documents

Procedure manuals and tutorials are similar, but often simpler in structure. When the new system significantly changes the way things are done, these resources are very important. Topics for procedures manuals usually come from the use scenarios developed during interface design and from other basic tasks the users must perform. Topics for tutorials are usually organized around major sections of the system and the level of experience of the user. Most tutorials start with basic, most commonly used commands and then move into more complex and less frequently used commands.

Writing Documentation Topics

The general format for topics is fairly similar across application systems and operating systems (Figure 12-7). Topics typically start with very clear titles, followed by some introductory text that defines the topic, and then provide detailed, step-by-step instructions on how to perform what is being described (where appropriate). Many topics include screen images to help the user find items on the screen; some also have “ show me” examples in which the series of keystrokes and/or mouse movements and clicks needed to perform the function are demonstrated to the user. Most also include navigation controls to enable movement among topics, usually at the top of the window, plus links to other topics. Some also have links to related topics that include options or other commands and tasks the user may want to perform in concert with the topic being read.

FIGURE 12-7 A Help Topic in Microsoft Windows

YOUR TURN: 12-2 DOCUMENTATION FOR AN AUTOMATED TELLER

Pretend that you are a project manager for a bank, developing software for automated teller machines. Develop an online help system.

Writing the topic content can be challenging. It requires a good understanding of the users (or, more accurately, the range of users) and a knowledge of what skills the users currently have and can be expected to import from other systems and tools they are using or have used (including the system the new system is replacing). Topics should always be written from the viewpoint of the user and describe what the user wants to accomplish, not what the system can do. Figure 12-8 provides some general guidelines to improve the quality of documentation text.

Identifying Navigation Terms

As you write the documentation topics, you also begin to identify the terms that will be used to help users find topics. The table of contents is usually the most straightforward, because it is developed from the logical structure of the documentation topics, whether reference topics, procedure topics, or tutorial topics. The items for the index and search engine require more care because they are developed from the major parts of the system and the users' business functions. Every time you write a topic, you must also list the terms that will be used to find the topic. Terms for the index and search engine can come from four distinct sources.

The first source for index terms is the set of the commands in the user interface, such as open file, modify customer, and print open orders. All commands contain two parts (action and object). It is important to develop the index for both parts because users could search for information by using either part. A user looking for more information about saving files, for example, might search by using the term save or the term files.

The second source is the set of major concepts in the system, which are often the entities, data stores, and data elements in the data flow diagrams. In the case of Tune Source, for example, this might include music genre, artist, and tune.

A third source is the set of business tasks the user performs, such as ordering replacement units or making an appointment. Often these will be contained in the command set, but sometimes they require several commands and use terms that do not always appear in the system. A good source for these terms is the use scenarios developed by interface design. (See Chapter 9.)

FIGURE 12-8 Guidelines for Crafting Documentation Topics

CONCEPTS IN ACTION: 12-C SYSTEMS FOR COMPLEX ELECTRICAL SYSTEMS

Systems integration across platforms and companies grows more complex with time. In a case study from Florida in 2008, an electrical company realtime system detected a minor problem in the power grid and shut down the entire system, plunging over two million people into the dark. The system experts placed the blame on a substation software system that detected the minor fluctuation, but had the ability to immediately shut the entire system down. Although there may be times when such a rapid response is vital (such as the nuclear disasters in Chernobyl Ukraine and Three Mile Island), this was a case where such a response was not warranted.

QUESTIONS:

1. Since software controls substation operations, how might a systems analyst approach this problem as a systems project?

2. Are there special considerations that a systems analyst needs to think about when dealing with real-time systems?

A fourth, often controversial, source is the set of synonyms for the three sets of items mentioned previously. Users sometimes don't think in terms of the nicely defined terms used by the system. They may try to find information on how to stop or quit rather than exit, or on how to erase rather than delete. Including synonyms in the index increases the complexity and size of the documentation system but can greatly improve the value of the system to the users.

Making the Transition to the New System

In many ways, using a computer system or set of work processes is much like driving on a dirt road. Over time with repeated use, the road begins to develop ruts in the most commonly used parts of the road. Although these ruts show where to drive, they make change difficult. As people use a computer system or set of work processes, those system/work processes begin to become habits or norms; people learn them and become comfortable with them. These system or work processes then begin to limit people's activities and make it difficult for them to change because they begin to see their jobs in terms of these processes rather than in terms of the final business goal of serving customers.

One of the earliest models for managing organizational change was developed by Kurt Lewin.1 Lewin argued that change is a three-step process: unfreeze, move, refreeze (Figure 13-1). First, the project team must unfreeze the existing habits and norms (the as-is system) so that change is possible. Most of the SDLC to this point has laid the groundwork for unfreezing. Users are aware of the new system being developed, some have participated in an analysis of the current system (and so are aware of its problems), and some have helped design the new system (and so have some sense of the potential benefits of the new system). These activities have helped to unfreeze the current habits and norms.

The second step of Lewin's three-step model is to move, or transition, from the old system to the new. The migration plan incorporates many issues that must be addressed to facilitate this transition. First, the conversion strategy needs to be selected, determining the style of the switch from the old to the new system, what parts of the organization will be converted when, and how much of the system is converted at a time. Plans to handle potential business disruption due to technical problems during conversion should be outlined in the business contingency plan. Arrangements for the hardware and software installation should be completed, and decisions about how the data will be converted into the new system will be made. The final major segment of the migration plan involves helping the people who are affected by the new system understand the change and motivating them to adopt the new system. The next section of this chapter discusses these aspects of the migration plan.

FIGURE 13-1 Implementing Change

Lewin's third step is to refreeze the new system as the habitual way of performing the work processes—ensuring that the new system successfully becomes the standard way of performing the business functions it supports. This refreezing process is a key goal of the postimplementation activities discussed in the final section of this chapter. By providing ongoing support for the new system and immediately beginning to identify improvements for the next version of the system, the organization helps solidify the new system as the new habitual way of doing business. Postimplementation activities include system support, which means providing help desk and telephone support for users with problems; system maintenance, which means fixing bugs and improving the system after it has been installed; and project assessment, which is the process of evaluating the project to identify what went well and what could be improved for the next system development project.

The Migration Plan

The transition from the old business processes and computer programs to the new business processes and computer programs will be facilitated by ensuring that a number of business, technical, and people issues are addressed. The decisions, plans, and procedures that will guide the transition are outlined in the migration plan. (See Figure 13-2.) The migration plan specifies what activities will be performed when and by whom as the transition is made from the old to the new system.

In order to ensure that business is ready to make the transition, the project team must determine the best conversion strategy to use as the new system is introduced to the organization. Also, plans should be made to ensure that the business can continue its operations even in the event of technical glitches in the new system. These plans are termed business contingency plans.

FIGURE 13-2 Elements of a Migration Plan

Technical readiness is achieved by arranging for and installing any needed hardware and software, and converting data as needed for the new system. These arrangements, while essential, are usually the least difficult of all the issues dealt with in the migration plan.

Ensuring that the people who will be affected by the new system are ready and able to use it is the most complex element of the migration plan. Managing the “people” side of change requires the team to understand the potential for resistance to the new system, develop organizational support and encouragement for the change, and prepare the users through appropriate training activities.

Selecting the Conversion Strategy

The process by which the new system is introduced into the organization is called the conversion strategy. Those implementing this strategy must consider three different aspects of introducing the system: how abruptly the change is made (the conversion style), the organizational span of the introduction (conversion locations), and the extent of the system that is introduced (conversion modules). The choices made in these three dimensions will affect the cost, time, and risk associated with the transition, as explained in the sections that follow. (See Figure 13-3.)

Conversion Style The switch from the old system to the new system can be made abruptly or gradually. An abrupt change is called direct conversion, and, as the name implies, involves the instant replacement of the old system with the new system. In essence, the old system is turned off and the new is turned on, often coinciding with a fiscal-year change or other calendar event.

Direct conversion is simple and straightforward, but also risky. Any problems with the new system that have not been detected during testing may seriously disrupt the organization's ability to function.

A more gradual introduction is made with parallel conversion, in which both the old and the new systems are used simultaneously for a period of time. The two systems are operated side by side, and users must work with both the old and new systems. For example, if a new accounting system is introduced with a parallel conversion style, data must be entered into both systems. Output from both systems is carefully compared to ensure that the new system is performing correctly. After some period (often one to two months) of parallel operation and intense comparison between the two systems, use of the old system is discontinued.

FIGURE 13-3 Conversion Strategies

Parallel conversion reduces risk by providing the organization with a fallback position if major problems are encountered with the new system. It adds expense, however, as users are required to do their job tasks twice: once with each system that performs the same function.

Conversion Locations The new system can be introduced to different parts of the organization at different times, or it can be introduced throughout the organization at the same time. A pilot conversion selects one or more locations (or units or work groups within a location) to be converted first as a part of a pilot test. If the conversion at the pilot location is successful, then the system is installed at the remaining locations.

Pilot conversion has the advantage of limiting the effect of the new system to just the pilot location. In essence, an additional level of testing is provided before the new system is introduced organization-wide. This type of conversion can be done only in organizations that can tolerate different locations using different systems and business processes for a certain length of time. It also obviously requires a considerable time before the system is installed at all organizational locations.

In some situations, it is preferable to introduce the system to different locations, in phases. With phased conversion, a first set of locations is converted, then a second set, then a third set, and so on, until all locations are converted. Sometimes there is a deliberate delay between the phases, so that any problems with the system are detected before too much of the organization is affected. In other circumstances, the project team may begin a new phase immediately following the completion of the previous phase.

Phased conversion has the same advantages and disadvantages as pilot conversion. It also involves a smaller set of people to perform the actual conversion (and any associated training) than if all locations were converted at once.

It may be necessary to convert all locations at the same time, suggesting the need for simultaneous conversion. The new system is installed at all locations at once, thus eliminating the problem of having different organizational units using different systems and processes. The drawback of this option is that there must be sufficient staff to perform the conversion and train the users at all locations simultaneously.

Conversion Modules Although we typically expect that systems are installed in their entirety, this is not always the case. It may be desirable to decide how much of the new system will be introduced into the organization at a time. When the modules within the system are separate and distinct, organizations may convert to the new system one module at a time, using modular conversion. Modular conversion requires special care in developing the system (and usually adds extra cost), because each module must be written to work with both the old and the new systems. When modules are tightly integrated, this is very challenging and is therefore seldom done. When the software is written with loose association between modules, however, it becomes easier.

Modular conversion reduces the amount of training needed for people to begin using the new system, since users need to be trained only for the new module being implemented. Modular conversion does require significant time to introduce each module of the system in sequence.

Whole-system conversion, installing the entire system at one time, is most common. This approach is simple and straightforward and is required if the system consists of tightly integrated modules. If the system is large and/or extremely complex, however (e.g., an enterprise resource planning system such as SAP or Oracle), the whole system may prove too difficult for users to learn in one conversion step.

Evaluating the Strategy Choices Each of the segments in Figure 13-3 are independent, so a conversion strategy can be developed by combining any of the options just discussed.

CONCEPTS IN ACTION: 13-A CONVERTING TO THE EURO (PART 1)

When the European Union decided to introduce the euro, the European Central Bank had to develop a new computer system (called Target) to provide a currency settlement system for use by investment banks and brokerages. Prior to the introduction of the euro, settlement was performed between the central banks of the countries involved. After the introduction, the Target system, which consists of 15 national banking systems, would settle trades and perform currency conversions for cross-border payments for stocks and bonds.

Source: “Debut of Euro Nearly Flawless,” Computerworld, 33(2) p. 16, January 11, 1999, by Thomas Hoffman.

QUESTION:

Implementing Target was a major undertaking for a number of reasons. If you were an analyst on the project, what kinds of issues would you have to address to make sure the conversion happened successfully?

FIGURE 13-4 Characteristics of Conversion Strategies

For example, one commonly used approach is to begin with a pilot conversion of the whole system, using parallel conversion in a handful of test locations. Once the system has passed the pilot test at these locations, it is then installed in the remaining locations by phased conversion with direct cutover. There are three important factors to consider in selecting a conversion strategy: risk, cost, and the time required (Figure 13-4).

Risk The introduction of the new system exposes the organization to risk associated with problems and errors that may impede business operations. After the system has passed a rigorous battery of unit, integration, system, and acceptance testing, it should be bug free—maybe. Because humans make mistakes, undiscovered bugs may exist. Depending on the choices made, the conversion process provides one last step in which bugs can be detected and fixed before the system is in widespread use.

The parallel conversion strategy is less risky than direct conversion because of the security of continuing to operate the old system. If bugs are encountered, the new system can be shut down and fixed while the old system continues to function. Converting a pilot location is less risky than phased conversion or simultaneous conversion because the effects of bugs are limited to the pilot location. Those involved, knowing the installation is a pilot test, expect to encounter bugs. Finally, converting by modules is less risky than simultaneous conversion. The number of bugs encountered at any one time should be fewer when a few modules at a time are converted, making it easier to deal with problems as they occur. If numerous bugs are experienced together during simultaneous conversion, the total effect may be more disruptive than if the bugs were encountered gradually.

The significance of the risk factor in selecting a conversion strategy depends on the system being implemented. The team must weigh the probability of undetected bugs remaining in the system against the potential consequences of those undetected bugs. If the system has undergone extensive methodical testing, including alpha and beta testing, then the probability of undetected bugs is lower than if testing were less rigorous. There remains the chance, however, that mistakes were made in analysis and that the new system may not properly fulfill the business requirements.

Assessing the consequences (or cost) of a bug is challenging. Most analysts and senior managers are capable of making a reasonable guess at the relative significance of a bug, however. For example, it is obvious that the importance of negative consequences of a bug in an automated stock market trading system or a medical life-support system is much greater than in a computer game or word processing program. (Recall Figure 12-1.) Therefore, risk is likely to be a very important factor in the selection of a conversion strategy if the system has had limited testing and/or if the significance of bugs is high. If the system has been thoroughly tested and/or the cost of bugs is not too high, then risk becomes less important to the conversion strategy decision.

Cost The various conversion strategies have different costs. These costs can include salaries for people who work with the system (e.g., users, trainers, system administrators, external consultants), travel expenses, operation expenses, communication costs, and hardware leases. Parallel conversion is more expensive than direct cutover because it requires that two systems (the old and the new) be operated at the same time. Employees must now perform twice the usual work and also cross-check the results of the two systems.

Pilot conversion and phased conversion have somewhat similar costs. Simultaneous conversion has higher costs because more staff are required to support all the locations as they simultaneously switch from the old to the new system. Modular conversion is more expensive than whole system conversion because it requires more programming. The old system must be updated to work with selected modules in the new system, and modules in the new system must be programmed to work with selected modules in both the old and new systems.

Time The final factor is the amount of time required to convert between the old and the new system. Direct conversion is the fastest because it is immediate. Parallel conversion takes longer because the full advantages of the new system do not become available until the old system is turned off. Simultaneous conversion is fastest because all locations are converted at the same time. Phased conversion generally takes longer than pilot conversion because usually (but not always), once the pilot test is complete, all remaining locations are simultaneously converted. Phased conversion proceeds in waves, often requiring several months before all locations are converted. Likewise, modular conversion takes longer than whole-system conversion because the modules are introduced one after another.

Preparing a Business Contingency Plan

It is tempting to believe that doing careful and thorough work in analysis and design and managing the IT project correctly will produce a successful system implementation. It is common for the team to view their prospects for success with optimism. With new systems, however, it may be more appropriate to always expect the worst.

YOUR TURN: 13-1 DEVELOPING A CONVERSION STRATEGY

Suppose that you are leading the conversion from one word processor to another at your university. Develop a conversion strategy. You have also been asked to develop a conversion strategy for the university's new Web-based course registration system. How would the second conversion strategy be similar to or different from the one you developed for the word processor?

CONCEPTS IN ACTION: 13-B U.S. ARMY INSTALLATION SUPPORT

Throughout the 1960s, 1970s, and 1980s, the U.S. Army automated its installations (“army bases,” in civilian terms). Automation was usually a local effort at each of the more than 100 bases. Although some bases had developed software together (or borrowed software developed at other bases), each base often had software that performed different functions or performed the same function in different ways. In 1989, the army decided to standardize the software so that the same software would be used everywhere. This would greatly reduce software maintenance and also reduce training when soldiers were transferred between bases.

The software took four years to develop. The system was quite complex, and the project manager was concerned that there was a high risk that not all requirements of all installations had been properly captured. Cost and time were less important, since the project had already run four years and cost $100 million.

Therefore, the project manager chose a modular pilot conversion using parallel conversion. The manager selected seven installations, each representing a different type of army installation (e.g., training base, arsenal, depot) and began the conversion. All went well, but several new features were identified that had been overlooked during the analysis, design, and construction. These were added and the pilot testing resumed. Finally, the system was installed in the rest of the army installations using a phased direct conversion of the whole system. Alan Dennis

QUESTION:

1. Do you think the conversion strategy was appropriate?

2. Regardless of whether you agree, what other conversion strategy could have been used?

Keeping small technology glitches in the new system from turning into major business disasters is known as business contingency planning. Contingency plans help the business withstand relatively small problems with the new system so that major business disruptions are prevented.

Some might say that business disasters are prevented with good project management and migration planning; therefore, developing contingency plans to cope with disasters is unnecessary. Large projects spanning multiple business processes and involving huge amounts of code, however, provide numerous combinations of relatively small technical problems that together can have devastating consequences. Enterprise resource planning software projects are good examples. In 2004, Hewlett-Packard experienced an estimated $160 million financial impact when a $30-million SAP project in the Industry Standard Server division experienced relatively minor programming problems. In 2001, Nike experienced small IT problems in an SAP installation that cost the company $100 million in lost revenue.2 It may be less risky to plan for how to cope with system failure (contingency plan) than to try to prevent failure purely through project management techniques.

YOUR TURN: 13-2 COMPARING CONVERSION STRATEGIES

· Develop the combination of conversion strategy dimensions that produces the least risk; the most risk.

· Develop the combination of conversion strategy dimensions that produces the least cost; the most cost.

· Develop the combination of conversion strategy dimensions that requires the least time; the most time.

Now, compare these strategies. Do you see any relationships? Based on your analysis, what advice might you give a team selecting a conversion strategy?

Choosing parallel conversion is one approach to contingency planning. Operating the old and new systems together for a time ensures that a fallback system is available if problems occur with the new system. Parallel conversion is not always feasible, however. Consequently, the worstcase outcome —no system at all— should be imagined and planned for, potentially going back to simple manual procedures.

One of the limitations of problem prevention through perfect project management techniques is the constant pressure of budget constraints and limited time that most projects face. With no budget or time pressure, it might be possible to prevent problems from occurring, but this is rarely the situation. Therefore, during the development of the migration plan, the project team should devote some attention to identifying the worst-case scenarios for the project, understanding the total business impact of those worst-case scenarios, and developing procedures and work-arounds that will enable the business to withstand those events. Since the contingency plan focuses on keeping the business up and running in the event of IT problems, it will be important to involve key business managers and users in the plan development.

Preparing the Technology

There are three major steps involved in preparing the technical aspects of the new system for operations: install the hardware, install the software, and convert the data. (See Figure 13-2.) Although it may be possible to do some of these steps in parallel, they usually must be performed sequentially at any one location.

The first step is to buy and install any needed hardware. In many cases, no new hardware is needed, but sometimes the project requires new servers, client computers, printers, and networking equipment. The new hardware requirements should have been defined in the hardware and software specifications during design (see Chapter 8) and used to acquire the needed resources. It is now critical to work closely with vendors who are supplying needed hardware and software to ensure that the deliveries are coordinated with the conversion schedule so that the equipment is available when it is needed. Nothing can stop a conversion plan in its tracks as easily as the failure of a vendor to deliver needed equipment.

Once the hardware is installed, tested, and certified as being operational, the second step is to install the software. This includes the to-be system under development, and sometimes, additional software that must be installed to make the system operational. For example, the Tune Source Digital Music Download system needs Web server software. At this point, the system is usually tested again to ensure that it operates as planned.

The third step is to convert the data from the as-is system to the to-be system. Data conversion is usually the most technically complicated step in the migration plan. Often, separate programs must be written to convert the data from the as-is system to the new formats required in the to-be system and store it in the to-be system files and databases. This process is often complicated by the fact that the files and databases in the to-be system do not exactly match the files and databases in the as-is system (e.g., the to-be system may use several tables in a database to store customer data that was contained in one file in the as-is system). Formal test plans are always required for data conversion efforts. (See Chapter 12.)

Preparing People for the New System

In the context of a systems development project, people who will use the new system need help to adopt and adapt to the new system. The process of helping them adjust to the new system and its new work processes without undue stress is called change management.3 There are three key roles in any major organizational change. The first is the sponsor of the change—the person who wants the change. This person is the business sponsor who first initiated the request for the new system. (See Chapter 1.) Usually the sponsor is a senior manager of the part of the organization that must adopt and use the new system. It is critical that the sponsor be active in the change management process, because a change that is clearly being driven by the sponsor, not by the project team or the IS organization, has greater legitimacy in the eyes of the users. The sponsor has direct management authority over those who will adopt the system.

The second role is that of the change agent—the person(s) leading the change effort. The change agent, charged with actually planning and implementing the change, is usually someone outside of the business unit adopting the system and therefore has no direct management authority over the potential adopters. Because the change agent is an outsider from a different organizational culture, he or she has less credibility than do the sponsor and other members of the business unit. After all, once the system has been installed, the change agent usually leaves and thus has no ongoing impact.

The third role is that of potential adopter, or target of the change—the people who actually must change. These are the people for whom the new system is designed and who will ultimately choose to use or not use the system.

In the early days of computing, many project teams simply assumed that their job ended when the old system was converted to the new system at a technical level. The philosophy was “build it and they will come.” Unfortunately, that happens only in the movies. Resistance to change is common in most organizations. Therefore, the change management plan is an important part of the overall migration plan that glues together the key steps in the change management process. Successful change requires that people want to adopt the change and are able to adopt the change. The change management plan has four basic steps: revising management policies, assessing the cost and benefit models of potential adopters, motivating adoption, and enabling people to adopt through training. (See Figure 13-2.) Before we can discuss the change management plan, however, we must first understand why people resist change.

Understanding Resistance to Change

People resist change—even change for the better—for very rational reasons.4 What is good for the organization is not necessarily good for the people who work there. For example, consider an order-processing clerk who used to receive orders to be shipped on paper shipping documents, but now uses a computer to receive the same information. Rather than typing shipping labels with a typewriter, the clerk now clicks on the print button on the computer and the label is produced automatically. The clerk can now ship many more orders each day, which is a clear benefit to the organization. The clerk, however, probably doesn't really care how many packages are shipped. His or her pay doesn't change; it's just a question of whether the clerk prefers a computer or typewriter. Learning to use the new system and work processes—even if the change is minor—requires more effort than continuing to use the existing, well-understood system and work processes.

So why do people accept change? Simply put, every change has a set of costs and benefits associated with it. If the benefits of accepting the change outweigh the costs of the change, then people change. And sometimes the benefit of change is avoidance of the pain that you would experience if you did not adopt the change (e.g., if you don't change, you are fired, so one of the benefits of adopting the change is that you still have a job).

In general, when people are presented with an opportunity for change, they perform a cost—benefit analysis (sometimes consciously, sometimes subconsciously) and decide the extent to which they will embrace and adopt the change. They identify the costs of and benefits from the system and decide whether the change is worthwhile. However, it is not that simple, because most costs and benefits are not certain. There is some uncertainty as to whether a certain benefit or cost will actually occur; so both the costs of and benefits from the new system will need to be weighted by the degree of certainty associated with them (Figure 13-5). Unfortunately, most humans tend to overestimate the probability of costs and underestimate the probability of benefits.

There are also costs and benefits associated with the actual transition process itself. For example, suppose that you found a nicer house or apartment than your current one. Even if you liked it better, you might decide not to move, simply because the cost of moving outweighed the benefits of the new house or apartment itself. Likewise, adopting a new computer system might require you to learn new skills, which could be seen as a cost by some people, but as a benefit by others who perceive that those skills may somehow provide other benefits beyond the use of the system itself. Once again, any costs and benefits from the transition process must be weighted by the certainty with which they will occur. (See Figure 13-5.)

Taken together, these two sets of costs and benefits (and their relative certainties) affect the acceptance of change or resistance to change that project teams encounter when installing new systems in organizations. The first step in change management is to understand the factors that inhibit change—the factors that affect the perception of costs and benefits and certainty that they will be generated by the new system. It is critical to understand that the “real” costs and benefits are far less important than the perceived costs and benefits. People act on what they believe to be true, not on what is true. Thus, any understanding of how to motivate change must be developed from the viewpoint of the people expected to change, not from the viewpoint of those leading the change.

FIGURE 13-5 The Costs and Benefits of Change

Revising Management Policies

The first major step in the change management plan is to change the management policies that were designed for the as-is system to new management policies designed to support the to-be system. Management policies provide goals, define how work processes should be performed, and determine how organizational members are rewarded. No computer system will be successfully adopted unless management policies support its adoption. Many new computer systems bring changes to business processes; they enable new ways of working. Unless the policies that provide the rules and rewards for those processes are revised to reflect the new opportunities that the system permits, potential adopters cannot easily use it.

Management has three basic tools for structuring work processes in organizations.5 The first is the standard operating procedures (SOPs) that become the habitual routines for how work is performed. The SOPs are both formal and informal. Formal SOPs define proper behavior. Informal SOPs are the norms that have developed over time for how processes are actually performed. Management must ensure that the formal SOPs are revised to match the to-be system. The informal SOPs will then evolve to refine and fill in details absent in the formal SOPs.

The second aspect of management policy is defining how people assign meaning to events. What does it mean to “be successful” or “do good work”? Policies help people understand meaning by defining measurements and rewards. Measurements explicitly define meaning because they provide clear and concrete evidence about what is important to the organization. Rewards reinforce measurements because “what gets measured gets done” (an overused, but accurate, saying). Measurements must be carefully designed to motivate desired behavior. The IBM credit example (“Your Turn 3-3” in Chapter 3) illustrates the problem when flawed measurements drive improper behavior. (When the credit analysts became too busy to handle credit requests, they would “find” nonexistent errors so that they could return the requests unprocessed.)

A third aspect of management policy is resource allocation. Managers can have a clear and immediate impact on behavior by allocating resources. They can redirect funds and staff from one project to another, create an infrastructure that supports the new system, and invest in training programs. Each of these activities has both a direct and a symbolic effect. The direct effect comes from the actual reallocation of resources. The symbolic effect shows that management is serious about its intentions. There is less uncertainty about management's long-term commitment to a new system when potential adopters see resources being committed to support it.

YOUR TURN: 13-3 STANDARD OPERATING PROCEDURES

Identify and explain three standard operating procedures for the course in which you are using this book. Discuss whether they are formal or informal.

Assessing Costs and Benefits

The next step in developing a change management plan is to develop two clear and concise lists of costs and benefits provided by the new system (and the transition to it), compared with the as-is system. The first list is developed from the perspective of the organization, which should flow easily from the business case developed during the feasibility study and refined over the life of the project. (See Chapter 1.) This set of organizational costs and benefits should be distributed widely so that everyone expected to adopt the new system clearly understands why the new system is valuable to the organization.

The second list of costs and benefits is developed from the viewpoints of the different potential adopters expected to change, or stakeholders in the change. For example, one set of potential adopters may be the front-line employees, another may be the first-line supervisors, and yet another might be middle management. Each of these potential adopters or stakeholders may have a different set of costs and benefits associated with the change—costs and benefits that can differ widely from those of the organization. In some situations, unions may be key stakeholders that can make or break successful change.

Many systems analysts naturally assume that front-line employees are the ones whose set of costs and benefits are the most likely to diverge from those of the organization and thus are the ones who most resist change. However, these employees usually bear the brunt of problems with the current system. When problems occur, they often experience them firsthand. Middle managers and first-line supervisors are the most likely to have a divergent set of costs and benefits; therefore, they resist change because new computer systems often change how much power those individuals have. For example, a new computer system may improve the organization's control over a work process (a benefit to the organization), but reduce the decision-making power of middle management (a clear cost to middle managers).

An analysis of the costs and benefits for each set of potential adopters or stakeholders will help pinpoint those who will likely support the change and those who may resist the change. The challenge at this point is to try to change the balance of the costs and benefits for those expected to resist the change so that they support it (or at least do not actively resist it).

This analysis may uncover some serious problems that have the potential to block the successful adoption of the system. It may be necessary to reexamine the management policies and make significant changes to ensure that the balance of costs and benefits is such that important potential adopters are motivated to adopt the system.

Figure 13-6 summarizes some of the factors that are important to successful change. The first and most important is a compelling personal reason to change. All change is made by individuals, not organizations. If there are compelling reasons for the key groups of individual stakeholders to want the change, then the change is more likely to be successful. Factors such as increased salary, reduced unpleasantness, and—depending on the individuals—opportunities for promotion and personal development can be important motivators. If the change makes current skills less valuable, however, individuals may resist the change because they have invested a lot of time and energy in acquiring those skills and anything that diminishes those skills may be perceived as diminishing the individual (because important skills bring respect and power).

FIGURE 13-6 Major Factors in Successful Change

CONCEPTS IN ACTION: 13-C MANAGING GLOBAL PROJECTS

Shamrock Foods is a major food distributor centered in Tralee, Ireland. Originally a dairy cooperative, Shamrock branched into various food components (dried milk, cheese solids, flavorings [or flavorings, as the Irish would spell it]) and has had substantial growth in the past 10 years, most of which came by way of acquisition of existing companies or facilities. For example, Iowa Soybean in the United States is now a subsidiary of Shamrock Foods, as is a large dairy cooperative in Wisconsin.

Shamrock has processing facilities in over 12 countries and distribution and sales in over 30 countries. With the rapid growth by acquisition, the company has generally adopted a “hands-off” policy keeping the systems separated and not integrated into a unified ERP system. Thus, each acquired company is still largely autonomous, although it reports to Shamrock Foods and is managed by Shamrock Foods.

This separation concept has been a problem for Conor Lynch, CFO of Shamrock Foods. The board of directors would like some aggregated data for direction and analysis of acquired businesses. Conor has the reports from the various subsidiaries but has to have his staff convert the figures reported in them to a consistent basis (generally, either Euros or American dollars).

QUESTIONS:

1. When should a multinational/multisite business consolidate data systems?

2. There are costs associated with consolidating data systems that have a variety of hardware and software systems. For example, the various acquired companies already had their own functioning accounting systems. What justification should Conor use to push for a consolidated, unified ERP system?

3. At times, Conor has to deal with incomplete and incompatible data. For instance, inventory systems might be FIFO for some of the subsidiaries and LIFO for other subsidiaries. How might a CFO with multinational interests deal with incomplete and incompatible data?

There must also be a compelling reason for the organization to need the change; otherwise, individuals become skeptical in regard to whether the change is important and are less certain that it will in fact occur. Probably the hardest organization to change is an organization that has been successful, because individuals come to believe that what worked in the past will continue to work. By contrast, in an organization that is on the brink of bankruptcy, it is easier to convince individuals that change is needed. Commitment and support from credible business sponsors and top management are also important in increasing the certainty that the change will occur.

The likelihood of successful change is increased when the cost of the transition to individuals who must change is low. The need for significantly different new skills or disruptions in operations and work habits may create resistance. A clear migration plan developed by a credible change agent who has support from the business sponsor is an important factor in increasing the certainty about the costs of the transition process.

Motivating Adoption

The single most important factor in motivating a change is providing clear and convincing evidence of the need for change. Simply put, everyone who is expected to adopt the change must be convinced that the benefits from the to-be system outweigh the costs of changing.

There are two basic strategies to motivating adoption: informational and political. Both strategies are often used simultaneously. With an informational strategy, the goal is to convince potential adopters that the change is for the better. This strategy works when the cost–benefit set of the target adopters has more benefits than costs. In other words, there really are clear reasons for the potential adopters to welcome the change.

Using this approach, the project team provides clear and convincing evidence of the costs and benefits of moving to the to-be system. The project team writes memos and develops presentations that outline the costs and benefits of adopting the system from the perspective of the organization and from the perspective of the target group of potential adopters. This information is disseminated widely throughout the target group, much like an advertising or public relations campaign. It must emphasize the benefits as well as increase the certainty in the minds of potential adopters that these benefits will actually be achieved. In our experience, it is always easier to sell painkillers than vitamins; that is, it is easier to convince potential adopters that a new system will remove a major problem (or other source of pain) than that it will provide new benefits (e.g., increase sales). Therefore, informational campaigns are more likely to be successful if they stress the reduction or elimination of problems, rather than focus on the provision of new opportunities.

The other strategy to motivate change is a political strategy. With a political strategy, organizational power, not information, is used to motivate change. This approach is often used when the cost–benefit set of the target adopters has more costs than benefits. In other words, although the change may benefit the organization, there are no reasons for the potential adopters to welcome the change.

The political strategy is usually beyond the control of the project team. It requires someone in the organization who holds legitimate power over the target group to influence the group to adopt the change. This may be done in a coercive manner (e.g., “adopt the system or you're fired”) or in a negotiated manner, in which the target group gains benefits in other ways that are linked to the adoption of the system (e.g., linking system adoption to increased training opportunities). Management policies can play a key role in a political strategy by linking salary to certain behaviors desired with the new system.

In general, for any change that has true organizational benefits, about 20% to 30% of potential adopters will be ready adopters. They recognize the benefits, quickly adopt the system, and become proponents of the system. Another 20% to 30% are resistant adopters. They simply refuse to accept the change, and they fight against it, either because the new system has more costs than benefits for them personally or because they place such a high cost on the transition process itself that no amount of benefits from the new system can outweigh the change costs. The remaining 40% to 60% are reluctant adopters. They tend to be apathetic and will go with the flow to either support or resist the system, depending on how the project evolves and how their coworkers react to the system. Figure 13-7 illustrates the actors who are involved in the change management process.

YOUR TURN: 13-4 OVERCOMING RESISTANCE TO A NEW EXECUTIVE INFORMATION SYSTEM

How would you motivate adoption if you were the developer of a new executive information system designed to provide your organization's top executives with key performance measures and economic trend information?

FIGURE 13-7 Actors in the Change Management Process

The goal of change management is to actively support and encourage the ready adopters and help them win over the reluctant adopters. There is usually little that can be done about the resistant adopters because their set of costs and benefits may be divergent from those of the organization. Unless there are simple steps that can be taken to rebalance their costs and benefits or the organization chooses to adopt a strong political strategy, it is often best to ignore this small minority of resistant adopters and focus on the larger majority of ready and reluctant adopters.

Enabling Adoption: Training

Potential adopters may want to adopt the change, but unless they are capable of adopting it, they won't. Adoption is enabled by providing employees the skills needed to adopt the change through careful training. Training is probably the most self-evident part of any change management initiative. How can an organization expect its staff members to adopt a new system if they are not trained? We have found that training is one of the most commonly overlooked parts of the process, however. Many organizations and project managers simply expect potential adopters to find the system easy to learn. Since the system is presumed to be so simple, it is taken for granted that potential adopters should be able to learn with little effort. Unfortunately, this is usually an overly optimistic assumption.

Every new system requires new skills, either because the basic work processes have changed (sometimes radically in the case of business process reengineering [BPR]; see Chapter 3) or because the computer system used to support the processes is different. The more radical the changes to the business processes, the more important it is to ensure that the organization has the new skills required to operate the new business processes and supporting information system. In general, there are three ways to get these new skills. One is to hire new employees who have the needed skills that the existing staff does not. Another is to outsource the processes to an organization that has the skills that the existing staff does not. Both of these approaches are controversial and are usually considered only in the case of BPR when the new skills needed are likely to be the most different from the set of skills of the current staff. In most cases, organizations choose the third alternative: training existing staff in the new business processes and the to-be system. Every training plan must consider what to train and how to deliver the training.

YOUR TURN: 13-5 DEVELOPING A TRAINING PLAN

Suppose that you are leading the conversion from one word processor to another in your organization. Develop an outline of topics that would be included in the training. Develop a plan for training delivery.

What to Train What training should you provide to the system users? It's obvious: how to use the system. The training should cover all the capabilities of the new system, so that users understand what each module does, right?

Wrong. Training for business systems should focus on helping the users to accomplish their jobs, not on how to use the system. The system is simply a means to an end, not the end in itself. This focus on performing the job (i.e., the business processes), not using the system, has two important implications. First, the training must focus on those activities around the system, as well as on the system itself. The training must help the users understand how the computer fits into the bigger picture of their jobs. The use of the system must be put in the context of the manual and computerized business processes, and it must also cover the new management policies that were implemented along with the new computer system.

Second, the training should focus on what the user needs to do, not on what the system can do. This is a subtle—but very important—distinction. Most systems will provide far more capabilities than the users will need to use (e.g., when was the last time you wrote a macro in Microsoft Word?). Rather than attempting to teach the users all the features of the system, training should instead focus on the much smaller set of activities that users perform on a regular basis and ensure that users are truly expert in those. When the focus is on the 20% of functions that the users will use 80% of the time (instead of attempting to cover all functions), users become confident about their ability to use the system. Training should mention the other little-used functions, but only so that users are aware of their existence and know how to learn about them when their use becomes necessary.

One source of guidance for designing training materials is the use cases and use scenarios. The use cases and use scenarios outline the common activities that users perform and thus can be helpful in understanding the business processes and system functions that are likely to be most important to the users.

How to Train There are many ways to deliver training. The most commonly used approach is classroom training. This has the advantage of training many users at one time with only one instructor and creates a shared experience among the users.

It is also possible to provide one-on-one training in which one trainer works closely with one user at a time. This is obviously more expensive, but the trainer can design the training program to meet the needs of individual users and can better ensure that the users really do understand the material. This approach is typically used only when the users are very important or when there are very few users.

Another approach that is becoming more common is to use some form of computer based training (CBT), in which the training program is delivered via computer, either on DVD or over the Web. CBT programs can include text slides, audio, and even video and animation. CBT is typically more costly to develop, but is cheaper to deliver because no instructor is needed to actually provide the training.

FIGURE 13-8 Selecting a Training Method

Figure 13-8 summarizes four important factors to consider in selecting a training method. CBT is typically more expensive to develop than one-on-one or classroom training, but it is less expensive to deliver. One-on-one training has the most impact on the user because it can be customized to the user's precise needs, knowledge, and abilities, whereas CBT has the least impact. However, CBT has the greatest reach—the ability to train the most users over the widest distance in the shortest time—because it is so much simpler to distribute, compared with classroom and one-on-one training, since no instructors are needed.

Figure 13-8 suggests a clear pattern for most organizations. If there are only a few users to train, one-on-one training is the most effective. If there are many users to train, many organizations turn to CBT. We believe that the use of CBT will increase in the future. Quite often, large organizations use a combination of all three methods. Regardless of which approach is used, it is important to leave the users with a set of easily accessible materials that can be referred to long after the training has ended (usually a quick reference guide and a set of manuals, whether on paper or in electronic form).

CONCEPTS IN ACTION: 13-D FINISHING THE PROCESS

As a great analyst, you've planned, analyzed, and designed a good solution. Now you need to implement it. As part of implementation, do you think that training is just a wasted expense?

Stress is common in a help-desk call center. Users of computing services call to get access to locked accounts, get help when technology isn't working as planned, and frequently can become very upset. Employees of the help-desk call center can get stressed out, and this can result in a greater number of sick days, less productivity, and higher turnover. Max Productivity Incorporated (MPI) is a training company that works with people in high-stress jobs. MPI's training program helps employees learn how to relax, how to “shake off” tough users, and how to create “win-win” scenarios. MPI claims to be able to reduce employee turnover by 50 percent, increase productivity by 20 percent, and reduce stress, anger, and depression by 75 percent.

QUESTIONS:

1. How would you challenge MPI to verify its claims regarding reducing turnover, increasing productivity, and decreasing stress and anger?

2. How would you conduct a “cost–benefit” analysis aimed at deciding whether to hire MPI to do ongoing training for your help-desk call center employees?

Post-implementation Activities

The goal of postimplementation activities is to institutionalize the use of the new system—that is, to make it the normal, accepted, routine way of performing the business processes. The postimplementation activities attempt to refreeze the organization after the successful transition to the new system. Although the work of the project team naturally winds down after implementation, the business sponsor and, sometimes, the project manager are actively involved in refreezing. These two—and, ideally, many other stakeholders—actively promote the new system and monitor its adoption and usage. They usually provide a steady flow of information about the system and encourage users to contact them to discuss issues.

In this section, we examine three key postimplementation activities; support (providing assistance in the use of the system), maintenance (continuing to refine and improve the system), and project assessment (analyzing the project to understand what activities were done well—and should be repeated—and what activities need improvement in future projects).

System Support

Once the project team has installed the system and performed the change management activities, the system is officially turned over to the operations group. This group is responsible for the operation of the system, whereas the project team is responsible for the development of the system. Members of the operations group usually are closely involved in the installation activities because they are the ones who must ensure that the system actually works. After the system is installed, the project team leaves but the operations group remains.

Providing system support means helping the users to use the system. Usually, this means providing answers to questions and helping users understand how to perform a certain function; this type of support can be thought of as on-demand training.

Online support is the most common form of on-demand training. This includes the documentation and help screens built into the system, as well as separate Web sites that provide answers to frequently asked questions (FAQs) that enable users to find answers without contacting a person. Obviously, the goal of most systems is to provide sufficiently good online support so that the user doesn't need to contact a person, because providing online support is much less expensive than is providing a person to answer questions.

Most organizations provide a help desk that provides a place for a user to talk with a person who can answer questions (usually over the phone, but sometimes in person). The help desk supports all systems, not just one specific system, so it receives calls about a wide variety of software and hardware. The help desk is operated by level 1 support staff who have very broad computer skills and are able to respond to a wide range of requests, from network problems and hardware problems to problems with commercial software and with the business application software developed in house.

The goal of most help desks is to have the level 1 support staff resolve 80% of the help requests they receive on the first call. If the issue cannot be resolved by level 1 support staff, a problem report (Figure 13-9) is completed (often using a special computer system designed to track problem reports) and passed to a level 2 support staff member.

FIGURE 13-9 Elements of a Problem Report

The level 2 support staff members are people who know the application system well and can provide expert advice. For a new system, they are usually selected during the implementation phase and become familiar with the system as it is being tested. Sometimes, the level 2 support staff members participate in training during the change management process to become more knowledgeable with the system, the new business processes, and the users themselves.

The level 2 support staff works with users to resolve problems. Most problems are successfully resolved by the level 2 staff. In the first few months after the system is installed, however, the problem may turn out to be a bug in the software that must be fixed. In this case, the problem report becomes a change request that is passed to the system maintenance group. (See the next section.)

System Maintenance

System maintenance is the process of refining the system to make sure it continues to meet business needs. Over a system's lifetime, more money and effort are devoted to system maintenance than to the initial development of the system, simply because a system continues to change and evolve as it is used. Most beginning systems analysts and programmers work first on maintenance projects; usually only after they have gained some experience are they assigned to new development projects.

CONCEPTS IN ACTION: 13-E CONVERTING TO THE EURO (PART 2)

When the European Union decided to introduce the euro, the European Central Bank had to develop a new computer system (called Target) to provide a currency settlement system for use by investment banks and brokerages. The euro opened at an exchange rate of U.S. $1.167. However, a rumor that the Target system malfunctioned sent the value of the euro plunging two days later.

That evening, it was determined that the malfunction was not due to system problems. Instead, operators at some German banks had misunderstood how to use the system and had entered incorrect data. Once the problems were identified and the operators quickly retrained, the Target system continued to operate and the euro quickly regained its lost value.

Source: “Debut of Euro Nearly Flawless,” Computerworld, January 11, 1999, 33(2), p. 16, by Thomas Hoffman.

QUESTION:

Target could be considered a high-risk system because of its effects on the European economy. What kinds of system support activities could be put in place to mitigate problems with Target?

FIGURE 13-10 Processing a Change Request

Every system is “owned” by a project manager in the IS group (Figure 13-10). This individual is responsible for coordinating the systems maintenance effort for that system. Whenever a potential change to the system is identified, a change request is prepared and forwarded to the project manager. The change request is a “smaller” version of the system request discussed in Chapters 1 and 2. It describes the change requested and explains why the change is important.

Changes can be small or large. Change requests that are likely to require a significant effort are typically handled in the same manner as system requests: They follow the same process as the project described in this book, starting with project initiation in Chapter 1 and following through installation in this chapter.

Minor changes typically follow a “smaller” version of this same process. There is an initial assessment of feasibility and of costs and benefits, and the change request is prioritized. Then a systems analyst (or a programmer/analyst) performs the analysis, which may include interviewing users, and prepares an initial design before programming begins. The new (or revised) program is then extensively tested before it is put into production.

Change requests typically come from five sources. The most common source is problem reports from the operations group that identify bugs in the system that must be fixed. These are usually given immediate priority because a bug can cause significant problems. Even a minor bug can cause major problems by upsetting users and reducing their acceptance of and confidence in the system.

The second most common source of change requests is enhancements to the system from users. As users work with the system, they often identify minor changes in the design that can make the system easier to use or identify additional functions that are needed. These enhancements are important in satisfying the users and are often key in ensuring that the system changes as the business requirements change. Enhancements are often given second priority after bug fixes.

A third source of change requests is other system development projects. For example, as part of Tune Source's Digital Music Download project, Tune Source likely had to make some minor changes to its existing Web-based CD sales system to ensure that the two systems would work together. These changes, required by the need to integrate two systems, are generally rare, but are becoming more common as system integration efforts become more common.

CONCEPTS IN ACTION: 13-F SOFTWARE BUGS

The awful truth is that every operating system and application system is defective. System complexity, the competitive pressure to hurry applications to market, and simple incompetence contribute to the problem.

Will software ever be bug free? Not likely. Microsoft Windows Group General Manager Chris Jones believes that bigger programs breed more bugs. Each revision is usually bigger and more complex than its predecessor, which means that there will always be new places for bugs to hide. Former Microsoft product manager Richard Freedman agrees that the potential for defects increases as software becomes more complex, but he believes that users ultimately win more than they lose. “I'd say the features have gotten exponentially better, and the product quality has degraded a fractional amount.”

Still, the majority of users who responded to our survey said they'd buy a software program with fewer features if it were bug free. This sentiment runs counter to what most software developers believe. “People buy features, plain and simple,” explains Freedman. “There have been attempts to release stripped-down word processors and spreadsheets, and they don't sell.” Freedman says a trend toward smaller, less-bug-prone software with fewer features will “never happen.”

Eventually, the software ships and the bug reports start rolling in. What happens next is what separates the companies you want to patronize from the slackers. While almost every vendor provides bug fixes eventually, some companies do a better job of it than others. Some observers view Microsoft's market dominance as a roadblock to bug-free software. Todd Paglia, an attorney with the Washington, D.C.-based Consumer Project on Technology, says, “If actual competition for operating systems existed and we had greater competition for some of the software that runs on the Microsoft operating system, we would have higher quality than we have now.”

Source: “Software Bugs Run Rampant,” PC World, January 1999 17(1): p. 46, by Scott Spanbauer.

QUESTION:

If commercial systems contain the amount of bugs that this article suggests, what are the implications for systems developed in house? Would in-house systems be more likely to have a lower or higher quality than commercial systems? Explain.

A fourth source of change requests is those that occur when underlying software or networks change. For example, a new version of Windows often will require an application to change the way it interacts with Windows or enable application systems to take advantage of new features that improve efficiency. While users may never see these changes (because most changes are inside the system and do not affect its user interface or functionality), these changes can be among the most challenging to implement because analysts and programmers must learn about the new system characteristics, understand how application systems use (or can use) those characteristics, and then make the needed programming changes.

The fifth source of change requests is senior management. These change requests are often driven by major changes in the organization's strategy (e.g., the Tune Source Digital Music Download project) or operations. These significant change requests are typically treated as separate projects, but the project manager responsible for the initial system is often placed in charge of the new project.

Project Assessment

The goal of project assessment is to understand what was successful about the system and the project activities (and therefore should be continued in the next system or project) and what needs to be improved. Project assessment is not routine in most organizations, except for military organizations, which are accustomed to preparing after-action reports. Nonetheless, assessment can be an important component in organizational learning because it helps organizations and people understand how to improve their work. It is particularly important for junior staff members because it helps promote faster learning. There are two primary parts to project assessment— project team review and system review.

project Team Review Project team review focuses on the way the project team carried out its activities. Each project member prepares a short two-to three-page document that reports on and analyzes his or her performance. The focus is on performance improvement, not penalties for mistakes made. By explicitly identifying mistakes and understanding their causes, project team members will, it is hoped, be better prepared for the next time they encounter a similar situation—and less likely to repeat the same mistakes. Likewise, by identifying excellent performance, team members will be able to understand why their actions worked well and how to repeat them in future projects.

The documents prepared by each team member are assessed by the project manager, who meets with the team members to help them understand how to improve their performance. The project manager then prepares a summary document that outlines the key learnings from the project. This summary identifies what actions should be taken in future projects to improve performance, but is not intended to identify team members who made mistakes. The summary is widely circulated among all project managers to help them understand how to manage their projects better. Often, it is also circulated among regular staff members who did not work on the project so that they, too, can learn from projects outside their scope.

System Review The focus of the system review is understanding the extent to which the proposed costs and benefits from the new system that were identified during project initiation were actually recognized from the implemented system. Project team review is usually conducted immediately after the system is installed, while key events are still fresh in team members' minds, but system review is often undertaken several months after the system is installed, because it often takes a while before the system can be properly assessed.

PRACTICAL TIP: 13-1 BEATING BUGGY SOFTWARE

How do you avoid bugs in the commercial software you buy? Here are six tips:

1. Know your software: Find out if the few programs you use day in and day out have known bugs and patches, and track the Web sites that offer the latest information on them.

2. Back up your data: This dictum should be tattooed on every monitor. Stop reading right now and copy the data you can't afford to lose onto a CD, second hard disk, or Web server. We'll wait.

3. Don't upgrade—yet: It's tempting to upgrade to the latest and greatest version of your favorite software, but why chance it? Wait a few months, check out other users' experiences with the upgrade on Usenet newsgroups or the vendor's own discussion forum, and then go for it. But only if you must.

4. Upgrade slowly: If you decide to upgrade, allow yourself at least a month to test the upgrade on a separate system before you install it on all the computers in your home or office.

5. Forget the betas: Installing beta software on your primary computer is a game of Russian roulette. If you really have to play with beta software, get a second computer.

6. Complain: The more you complain about bugs and demand remedies, the more costly it is for vendors to ship buggy products. It's like voting—the more people participate, the better are the results.

Source: “Software Bugs Run Rampant,” PC World, January, 1999, 17(1): p. 46, Scott Spanbauer.

System review starts with the system request and feasibility analysis prepared at the start of the project. The detailed analyses prepared for the expected business value (both tangible and intangible), as well as the economic feasibility analysis, are reexamined, and a new analysis is prepared after the system has been installed. The objective is to compare the anticipated business value against the actual realized business value from the system. This helps the organization assess whether the system actually provided the value it was planned to provide. Whether or not the system provides the expected value, future projects can benefit from an improved understanding of the true costs and benefits.

A formal system review also has important behavioral implications for project initiation. Since everyone involved with the project knows that all statements about business value and the financial estimates prepared during project initiation will be evaluated at the end of the project, they have an incentive to be conservative in their assessments. No one wants to be the project sponsor or project manager for a project that goes radically over budget or fails to deliver promised benefits.

References

Chemuturi, M. (2011). Mastering Software Quality. J. Ross Publishing.

Dennis, Alan; Wixom, B.H., and Roth, R. Systems Analysis and Design, 5th Edition.

Information System Analyst

ASSIGNMENT.doc

An Example of Database Normalization.docx

ITEC-630.Data.Oriented.Analysis1 (Week 7).docx

ITEC-630.Data.Storage.Design1 (Week 8).docx

DATABASE DESIGN & RELATIONAL DATABASE MODEL

ITEC-630.Human.Computer.Interaction1 (Week 10).docx

ITEC-630.Quality.Assurance.and.Implementation1 (Week 11).docx

ITEC-630.User.Interface.Design1 (Week 10).docx

W10.Safari.References.docx

W10.Safari.References

Focus on the User Interface

15.2.1 Heuristic Evaluation

Heuristic Evaluation for Websites

Turning Design Guidelines into Heuristics

Doing Heuristic Evaluation

15.2.2 Walkthroughs

Cognitive Walkthroughs

Pluralistic Walkthroughs

6.2 Interface Types

6.2.1 Command-Based

6.2.2 WIMP and GUI

6.2.3 Multimedia

6.2.5 Information Visualization

6.2.6 Web

6.2.7 Consumer Electronics and Appliances

6.2.8 Mobile

6.2.9 Speech

6.2.10 Pen

6.2.11 Touch

6.2.12 Air-Based Gestures

6.2.13 Haptic

6.2.14 Multimodal

6.2.15 Shareable

6.2.16 Tangible

6.2.17 Augmented and Mixed Reality

6.2.18 Wearables

6.2.19 Robots

6.2.20 Brain–Computer

6.3 Natural User Interfaces

6.4 Which Interface?

Context

The Userview Process

User Culture

The Users' Task Representation Analysis

Metaphor Design

Layout

Content Awareness

Aesthetics

User Experience

Consistency

Minimize User Effort

Use Scenario Development

Interface Structure Design

Interface Standards Design

Interface Design Prototyping

Interface Evaluation

Basic Principles

Types of Navigation Controls

Messages

Basic Principles

Types of Inputs

Input Validation

Basic Principles

Types of Outputs

Media

W11.Safari.References.docx

W11.Safari.References

· Elements of an Architecture Design (Go to the section “Client–Server Architectures”)

· Elements of an Architecture Design (Go to the section “Cloud Computing”)

Syntax

Building the Structure Chart

Applying the Concepts at Tune Source

Design Guidelines

ELEMENTS OF AN ARCHITECTURE DESIGN

Architectural Components

Client–Server Architectures

Client–server Tiers

Less Common Architectures

Advances in Architecture Configurations