DATA CAPTURE AND USER INPUT DESIGN

16-2

Data Capture

16-3

Taxonomy for Computer Inputs (continued)Process Method

Data Capture Data Entry Data Processing

Point of Sale Data captured as close to the point of sale as humanly possible. No source documents.

Data is often entered directly by the customer or by an employee directly interacting with the customer.

Data is almost always processed immediately as a transaction or inquiry.

Sound Data is captured as close to the source as possible, even when the customer is remotely located.

Data is entered using touch-tones (typically from a telephone). Usually requires rigid command menu structure and limited input options.

Data is almost always processed immediately as a transaction or inquiry.

Speech Same as sound. Data (and commands) is spoken. This technology is not as mature and is much less reliable and common than other techniques.

Data is almost always processed immediately as a transaction or inquiry.

Optical Mark Data is recorded on optical scan sheets as marks or precisely formed letter, numbers, and punctuation.

Eliminates the need for data entry.

Data is almost always processed as a batch.

16-4

Taxonomy for Computer Inputs (concluded)Process Method Data Capture Data Entry Data Processing

Magnetic Ink Data usually prerecorded on forms that are completed by the customer. The customer records additional information on the form.

A magnetic ink reader reads the magnetized data. The customer-added data must be entered using another input method.

Data is almost always processed as a batch.

Electromagnetic Data is recorded directly on the object to be described by data.

Data is transmitted by radio frequency.

Data is almost always processed immediately.

Smart Card Data is recorded directly on a device to be carried by the customer, employee, or other individual that is described by that data.

Data is read by smart card readers.

Data is almost always processed immediately.

Biometric Unique human characteristics become data

Data read by biometric sensors. Primary applications are security and medical monitoring

Data is processed immediately.

16-5

Input Design Guidelines• Capture data as close to its source as possible

• Capture only variable data.• Not data that can be looked up.

• Do not capture data that can calculated or stored in computer programs as constants.• Extended Price, Federal Withholding, etc.

• Use codes for appropriate attributes.

16-6

Source Document / Form Design Guidelines

• Include instructions for completing the form.

• Minimize the amount of handwriting.• Data to be entered (keyed) should be sequenced top-to-bottom and left-to-right.

• When possible use designs based on known metaphors.

16-7

Bad Flow in a Form

16-8

Good Flow in a Form

16-9

Metaphoric Screen Design

16-10

Internal Controls for Inputs• The number of inputs should be monitored (to minimize risk of lost transactions).• For batch processing

• Use batch control slips• Use one-for-one checks against post-processing detail reports

• For on-line systems• Log each transaction as it occurs to a separate audit file

• Validate all data• Existence checks• Data-type checks• Domain checks• Combination checks• Self-checking digits• Format checks

User Input Design

The user interface• System users often judge a system by its

interface rather than its functionality• A poorly designed interface can cause a user to

make catastrophic errors• Poor user interface design is the reason why so

many software systems are never used• Software engineers generally must do interface design

Importance of User Interface• “Most important part of any computer system”

• “Interface is the system for most users”

• Increasingly important• GUIs a big improvement over previous approaches• Platforms (e.g. Mac/ Microsoft) have style guides• 50% of code devoted to interface

• Interface should “disappear” – users can focus on their task, not the interface

• Biggest enemy of good interface design is time

Galitz

Benefits of Good Design• Small improvements can be worth big $$$

• If users work 1 sec slower on each of 4.8 million screens per year, need almost an extra person

• Redesigns have improved productivity 20%, 25%, 40%, 50% …• IBM - $1 invested in usability returns $10-$100

• Interface problems are treated as bugs• Pressman - $1 fix during design, $10 fix during development, $100 fix after

release

• Big Improvements can establish new products, companies, markets …

• the browser was a UI idea – before it, search using gopher etc was tedious. • AOL was successful because it was more user friendly than early leader

CompuServe.

Galitz

17-15

System User Classifications

Expert User – an experienced computer user• Spends considerable time using specific application

programs. • Use of a computer is usually considered non-

discretionary. • In the mainframe computing era, this was called a

dedicated user.

Novice User – a less experienced computer user • Uses computer on a less frequent, or even occasional,

basis. • Use of a computer may be viewed as discretionary

(although this is becoming less and less true). • Sometimes called a casual user.

Distinguish between different types of computer users and design considerations for each.

Galitz’s WWW Heuristics1. Speak the user’s language2. Be consistent3. Minimize the user’s memory load4. Build flexible and efficient systems5. Design aesthetic and minimalist systems6. Use chunking7. Provide progressive levels of detail8. Give navigational feedback9. Eliminate erroneous or misleading links. Do not refer to

missing information

Galitz

17-19

Interface ProblemsAccording to Galitz, the following problems result in confusion, panic, frustration, boredom, misuse, abandonment, and other undesirable consequences.

• Excessive use of computer jargon and acronyms • Nonobvious or less-than-intuitive design • Inability to distinguish between alternative actions

(“what do I do next?”) • Inconsistent problem-solving approaches • Design inconsistency

17-20

Commandments of User Interface Design

• Understand your users and their tasks. • Involve the user in interface design. • Test the system on actual users. • Practice iterative design.

17-21

Human Engineering Guidelines• The user should always be aware of what to do next

• Tell user what the system expects right now. • Tell user that data has been entered correctly.• Tell user that data has not been entered correctly. • Explain reason for a delay in processing. • Tell user a task was completed or not completed.

• Format screen so instructions and messages always appear in same general display area.

• Display messages and instructions long enough so user can read them.

17-22

Human Engineering Guidelines (continued)

• Use display attributes sparingly. • Default values should be specified.• Anticipate errors users might make. • Users should not be allowed to proceed without correcting an error.

• If user does something that could be catastrophic, the keyboard should be locked to prevent any further input, and an instruction to call the analyst or technical support should be displayed.

17-23

Guidelines for dialogue Tone and Terminology

Dialogue – the overall flow of screens and messages for an application

• Don’t use computer jargon.• Avoid most abbreviations.• Use simple terms.• Be consistent in your use of terminology.• Carefully phrase instructions—use appropriate action

verbs.

17-24

Graphical User Interfaces Styles and Considerations• Windows and frames • Menu-driven interfaces

• Pull-down and cascading menus• Tear-off and pop-up menus• Toolbar and iconic menus• Hypertext and hyperlink menus

• Instruction-driven interfaces• Language-based syntax• Mnemonic syntax• Natural language syntax

• Question-answer dialogue

17-25

Pull-Down and Cascading Menus

menu bar

Pull-down menu

Cascading menu

Ellipses indicates dialogue box

For frequently used application actions that take place in a wide variety of different windows

To simplify a higher-level menu

17-26

Dialogue Box

17-27

Pop-Up Menus

For frequent users and frequently used contextual commands

Tear-Off menu: For items sometimes frequently or infrequently selected

17-28

Tool Bars

To identify and provide access to common and frequently used actions

17-29

Iconic MenusTo designate applications available and special functions within an application

17-30

Consumer-Style Interface

17-31

Hybrid Windows/Web Interface

17-32

Special Considerations for User Interface Design

• Internal Controls – Authentication and Authorization• User ID and Password• Privileges assigned to roles• Web certificates

• Online Help• Growing use of HTML for help systems• Help authoring packages• Tool tips• Help wizards• Agents – reusable software object that can operate

across different applications and networks.

Error messages• Error message design is critically important.

Poor error messages can mean that a user rejects rather than accepts a system

• Messages should be polite, concise, consistent and constructive

• The background and experience of users should be the determining factor in message design

System and user-oriented error messages

Error #27

Invalid patient id entered?OK Cancel

System-oriented error message

user-oriented error messages

Patient J . Bates is not registered

Click on Patients for a list of registered patientsClick on Retry to re-input a patient nameClick on Help for more inf ormation

Patients Help Retry Cancel

User-oriented error message

Help system design• Help? means ‘help I want information”• Help! means “HELP. I'm in trouble”• Both of these requirements have to be taken

into account in help system design• Different facilities in the help system may be

required

Help information • Should not simply be an on-line manual• Screens or windows don't map well onto paper

pages.• People are not as good at reading screen as

they are paper text.• Content should be prepared with help of application

specialists• Content should not be too large – don’t overwhelm user

Help system use• Multiple entry points should be provided so that

the user can get into the help system from different places.

• Some indication of where the user is positioned in the help system is valuable.

• Facilities should be provided to allow the user to navigate and traverse the help system.

• Index, TOC, and Search should be provided

Entry points to a help system

Help frame network

Top-levelentry

Entry from errormessage system

Entry fromapplication

Help system windowsMail redirection

Mail may be redirected to anothernetwork user by pressing theredirect button in the controlpanel. The system asks for thename of the user or users towhom the mail has been sent

next topicsmore

Mail redirection

Mail may be redirected to anothernetwork user by pressing theredirect button in the controlpanel. The system asks for thename of the user or users towhom the mail has been sent

Help frame map

You are here

Help history

1. Mail2. Send mail3. Read mail4. Redirection

Help on WWW

•Easy to implement•Easy for users to use•Difficult to link to applications themselves

• users may need to make extra effort to get to help• Help doesn’t know context where you needed help – cannot provide context sensitive help

17-43

Help Tool Tip, Help Agent, and Natural Language Processing

17-44

Help Wizard

45

Modeling System Behavior

17-46

The User Interface Design Process1. Chart the user interface dialogue.

State Transition Diagram– a tool used to depict the sequence and variation of screens that can occur during a user session.

2. Prototype the dialogue and user interface.

3. Often STD is precursor to a use case

4. Obtain user feedback. • Exercising (or testing) the user interface

5. If necessary return to step 1 or 2

17-47

Partial State Transition Diagram

48

State Transition Diagrams• A state transition diagram is a model that depicts a

system’s states and the events that cause the system to change states.

• A state is any observable mode of behavior for the system.

• The state transition diagram also shows what actions are taken as a consequence of an event

• Such models are often called finite state machine models

49

State Transition Diagrams – An ExampleFollowing is a very simple state transition diagram for software controlling a printer. In this simplified model, we’ve identified five distinct states: idle, ready, printing, jammed, out_of_paper. The arrows represent transitions from one state to another. Along each arrow we note the event triggering the state change (above the horizontal rule) and the action taken in response to the event (below the horizontal rule).

50

State Transition Example (cont’d)

printing

ready

out_of_paper

jammed

jammeddisplay jam msg

jam correctedready resume job

new jobinitiate print

resume jobinitiate print

job completestop printing

idleprint requestready new job

no paperdisplay paper msg

paper loadedready resume job

trigger

action

51

ActivityConsider the software that controls the functions of a cruise control device on an automobile. Work with your team to create a state transition diagram for this system.

The particular device we’re working has the usual cruise control functions, plus the following enhanced ones: 1) if your vehicle pulls within 50 feet of a vehicle in front of you, an active cruise control device will turn itself off if it is set for more than 45 mph; 2) when you tap the brake once, the cruise control speed is suspended, but may be reinstated by pressing the resume button; 3) if you tap the brake more than once or if you hold the brake down for more than 2 seconds, the cruise control device will turn itself off in which case the speed setting is cancelled and will have to be reset when you re-engage the device.

52

Dialog Maps• User interfaces can often be regarded as a finite

state machine model• Thus, state transition diagrams can be used to

model these• Such state transition diagrams are referred to as

dialog maps (also sometimes called site maps when used with Web development)

53

Dialog Maps as Finite State Machines• Each dialog element (menu, screen, dialog box,

etc.) can be viewed as a state• The user can then navigate to another dialog

element (i.e. change states)• The possible elements and the navigation paths

between them can be modeled as a state transition diagram

54

Dialog Maps – An Example

cancellationrequest

RouteRequest

update submitted update notallowed

try againcancellationdata

invalid

Modeling User Interaction to Cancel a Seminar Registration in the Seminar Registration System we worked on earlier.

RegistrationInformation

Accessed

CancellationPerformed

cancellationconfirmed

CancellationDenied

request to cancel registration cancellation

not allowed

ErrorMessage Displayed

transaction terminated

accessdenied

1 start

55

Dialog Maps – An Example

cancellationrequest

RouteRequest

cancellationconfirmed

request to cancel registration cancellation

not allowed

update submitted update notallowed

try againcancellationdata

invalid

transaction terminated

accessdenied

1 start

Possible Application for a Decision Tree/Table

Modeling User Interaction to Cancel a Seminar Registration in the Seminar Registration System we worked on earlier.

RegistrationInformation

Accessed

CancellationPerformed

CancellationDenied

ErrorMessage Displayed

56

ActivityConsider the Seminar Management System we’ve been working on. Work with your team to create a dialog map that models the seminar administrator’s interactions with the system in obtaining an instructor for a seminar.

Refer to the Context for this system on the next slide to refresh your memory about it if needed.

ProposedSeminar

ManagementSystem

SMS

SeminarAdministrator

venue_request

venue_options

venue_choice

instructor_request

no_instructor_available

instructor_reserved

request_for_eval

Email Sys

Selected Venue

booking_requestbooking_confirmation

eval_request

class_roster

Accounts Payable

venue_pmt_info

instructor_pmt_info

Instructor Info

* Transfer/Maintenance TBD

Attendeecompleted_eval

seminar_completed

Attendee Info*

available_instrs

inst_scheduled

roster_sign-in

Instructor

dates_availscheduled

final_roster

email_address

SeminarRegistration

System

Venues Info*

inst_dates

venue_reserved

no_venue_avail

venues_available

Print Vendor

seminar_notification

booking_denied

final_roster

58

Dialog Maps as Abstraction of User Interface

• Dialog maps can be viewed as high-level abstractions of user interfaces

• Show the dialog elements and navigational links among them

• They do not reveal, or even take into account, detailed screen designs or data field definitions

59

Dialog Maps and Prototypes• A dialog map makes a good preliminary model to

use before beginning the construction of a prototype

• Provides vehicle for a high-level discussion with users about the interface functionality -- without getting bogged down in screen appearance and data definition details

• Excellent model for discovering missing requirements and misunderstood requirements relative to user interactions

17-60

Sample Dialogue Chart