DATA CAPTURE AND USER INPUT DESIGN 16 2

DATA CAPTURE AND USER INPUT DESIGN

16 -2 Data Capture

16 -3 Taxonomy for Computer Inputs Process Data Capture Data Entry (continued) Method Point of Sale Sound Speech Optical Data captured as close to the point of sale as humanly possible. No source documents. Data is captured as close to the source as possible, even when the customer is remotely located. Data is often entered directly by the customer or by an employee directly interacting with the customer. Data is entered using touch-tones (typically from a telephone). Usually requires rigid command menu structure and limited input options. 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 recorded on Eliminates the need for Data Processing Data is almost always processed immediately as a transaction or inquiry. Data is almost

16 -4 Taxonomy for Computer Inputs (concluded) Process Method Magnetic Ink Electromagn etic Smart Card Data Capture Data Entry Data Processing Data usually prerecorded on forms that are completed by the customer. The customer records additional information on the form. Data is recorded directly on the object to be described by data. Data is recorded directly on a device to be carried by the customer, employee, or other individual that is A magnetic ink reader reads the magnetized data. The customeradded data must be entered using another input method. Data is almost always processed as a batch. Data is transmitted by radio frequency. Data is almost always processed immediately. Data is read by smart card readers. Data is almost always 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” is the system for most users” • Increasingly important • “Interface • 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 Compu. Serve. • Galitz

17 -15 System User Classifications Distinguish between different types of computer users and design considerations for each. Expert User – an experienced computer user • Spends considerable time using specific application programs. • Use of a computer is usually considered nondiscretionary. • 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.

Galitz’s WWW Heuristics 1. 2. 3. 4. 5. 6. 7. 8. 9. Speak the user’s language Be consistent Minimize the user’s memory load Build flexible and efficient systems Design aesthetic and minimalist systems Use chunking Provide progressive levels of detail Give navigational feedback Eliminate erroneous or misleading links. Do not refer to missing information Galitz

17 -19 Interface Problems According 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 For frequently used application actions that take place in a wide variety of different windows menu bar Cascading menu Ellipses indicates dialogue box Pull-down menu To simplify a higherlevel 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 Menus To 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 System-oriented error message ? Error #27 Invalid patient id entered OK Cancel

user-oriented error messages User-oriented error message Patient J. Bates is not registered Click on Patients for a list of registered patients Click on Retry to re-input a patient name Click on Help for more information Patients Help Retry Cancel

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 system windows

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

Modeling System Behavior 45

17 -46 The User Interface Design Process 1. 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

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 48

State Transition Diagrams – An Example Following 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). 49

State Transition Example (cont’d) trigger action new job initiate print request ready new job idle job complete stop printing ready resume job initiate printing jammed display jam msg paper loaded ready resume job no paper display paper msg out_of_paper jam corrected ready resume job jammed 50

Activity Consider 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 reengage the device. 51

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

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 53

Dialog Maps – An Example 1 start transaction terminated request to access cancel registration denied Error Message Displayed cancellation data invalid try again Registration Information Accessed cancellation request cancellation confirmed cancellation not allowed Cancellation Performed Cancellation Denied update submitted update not allowed Route Request Modeling User Interaction to Cancel a Seminar Registration in the Seminar Registration System we worked on earlier. 54

Dialog Maps – An Example 1 start transaction terminated request to access cancel registration denied Error Message Displayed cancellation data invalid try again Registration Information Accessed cancellation request cancellation confirmed cancellation not allowed Cancellation Performed Cancellation Denied update submitted update not allowed Route Request Possible Application for a Decision Tree/Table Modeling User Interaction to Cancel a Seminar Registration in the Seminar Registration System we worked on earlier. 55

Activity Consider 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. 56

eval_request Email Sys Attendee com plet ed_ Print Vendor seminar_notification eva l leted p r_com a n i m se request_for_eval no_instructor_available b instructor_request venue_reserved venue_options Seminar Administrator venue_choice no_venue_avail strs available_in Instructor Info Proposed Seminar Management System SMS eduled dates_avail t ues q e r ing_ venue_pmt_info instructor_pmt_info booking_denied Accounts Payable class_ roster led edu h c s final_roster Selected Venue k venues_available roster_sign-in Instructor boo _co final_roster inst_sch inst_dates ing ook n tio ma nfir instructor_reserved email_address Attendee Info* Seminar Registration System Venues Info* * Transfer/Maintenance TBD

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 58

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 59

17 -60 Sample Dialogue Chart