data capture and user input design
DESCRIPTION
data Capture and user Input Design. Data Capture. Taxonomy for Computer Inputs (continued). Taxonomy for Computer Inputs (concluded). Input Design Guidelines. Capture data as close to its source as possible Capture only variable data. Not data that can be looked up. - PowerPoint PPT PresentationTRANSCRIPT
![Page 1: data Capture and user Input Design](https://reader036.vdocument.in/reader036/viewer/2022062315/56815e8e550346895dcd1e0f/html5/thumbnails/1.jpg)
DATA CAPTURE AND USER INPUT DESIGN
![Page 2: data Capture and user Input Design](https://reader036.vdocument.in/reader036/viewer/2022062315/56815e8e550346895dcd1e0f/html5/thumbnails/2.jpg)
16-2
Data Capture
![Page 3: data Capture and user Input Design](https://reader036.vdocument.in/reader036/viewer/2022062315/56815e8e550346895dcd1e0f/html5/thumbnails/3.jpg)
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.
![Page 4: data Capture and user Input Design](https://reader036.vdocument.in/reader036/viewer/2022062315/56815e8e550346895dcd1e0f/html5/thumbnails/4.jpg)
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.
![Page 5: data Capture and user Input Design](https://reader036.vdocument.in/reader036/viewer/2022062315/56815e8e550346895dcd1e0f/html5/thumbnails/5.jpg)
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.
![Page 6: data Capture and user Input Design](https://reader036.vdocument.in/reader036/viewer/2022062315/56815e8e550346895dcd1e0f/html5/thumbnails/6.jpg)
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.
![Page 7: data Capture and user Input Design](https://reader036.vdocument.in/reader036/viewer/2022062315/56815e8e550346895dcd1e0f/html5/thumbnails/7.jpg)
16-7
Bad Flow in a Form
![Page 8: data Capture and user Input Design](https://reader036.vdocument.in/reader036/viewer/2022062315/56815e8e550346895dcd1e0f/html5/thumbnails/8.jpg)
16-8
Good Flow in a Form
![Page 9: data Capture and user Input Design](https://reader036.vdocument.in/reader036/viewer/2022062315/56815e8e550346895dcd1e0f/html5/thumbnails/9.jpg)
16-9
Metaphoric Screen Design
![Page 10: data Capture and user Input Design](https://reader036.vdocument.in/reader036/viewer/2022062315/56815e8e550346895dcd1e0f/html5/thumbnails/10.jpg)
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
![Page 11: data Capture and user Input Design](https://reader036.vdocument.in/reader036/viewer/2022062315/56815e8e550346895dcd1e0f/html5/thumbnails/11.jpg)
User Input Design
![Page 12: data Capture and user Input Design](https://reader036.vdocument.in/reader036/viewer/2022062315/56815e8e550346895dcd1e0f/html5/thumbnails/12.jpg)
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
![Page 13: data Capture and user Input Design](https://reader036.vdocument.in/reader036/viewer/2022062315/56815e8e550346895dcd1e0f/html5/thumbnails/13.jpg)
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
![Page 14: data Capture and user Input Design](https://reader036.vdocument.in/reader036/viewer/2022062315/56815e8e550346895dcd1e0f/html5/thumbnails/14.jpg)
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
![Page 15: data Capture and user Input Design](https://reader036.vdocument.in/reader036/viewer/2022062315/56815e8e550346895dcd1e0f/html5/thumbnails/15.jpg)
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.
![Page 16: data Capture and user Input Design](https://reader036.vdocument.in/reader036/viewer/2022062315/56815e8e550346895dcd1e0f/html5/thumbnails/16.jpg)
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
![Page 17: data Capture and user Input Design](https://reader036.vdocument.in/reader036/viewer/2022062315/56815e8e550346895dcd1e0f/html5/thumbnails/17.jpg)
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
![Page 18: data Capture and user Input Design](https://reader036.vdocument.in/reader036/viewer/2022062315/56815e8e550346895dcd1e0f/html5/thumbnails/18.jpg)
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.
![Page 19: data Capture and user Input Design](https://reader036.vdocument.in/reader036/viewer/2022062315/56815e8e550346895dcd1e0f/html5/thumbnails/19.jpg)
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.
![Page 20: data Capture and user Input Design](https://reader036.vdocument.in/reader036/viewer/2022062315/56815e8e550346895dcd1e0f/html5/thumbnails/20.jpg)
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.
![Page 21: data Capture and user Input Design](https://reader036.vdocument.in/reader036/viewer/2022062315/56815e8e550346895dcd1e0f/html5/thumbnails/21.jpg)
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.
![Page 22: data Capture and user Input Design](https://reader036.vdocument.in/reader036/viewer/2022062315/56815e8e550346895dcd1e0f/html5/thumbnails/22.jpg)
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
![Page 23: data Capture and user Input Design](https://reader036.vdocument.in/reader036/viewer/2022062315/56815e8e550346895dcd1e0f/html5/thumbnails/23.jpg)
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
![Page 24: data Capture and user Input Design](https://reader036.vdocument.in/reader036/viewer/2022062315/56815e8e550346895dcd1e0f/html5/thumbnails/24.jpg)
17-26
Dialogue Box
![Page 25: data Capture and user Input Design](https://reader036.vdocument.in/reader036/viewer/2022062315/56815e8e550346895dcd1e0f/html5/thumbnails/25.jpg)
17-27
Pop-Up Menus
For frequent users and frequently used contextual commands
Tear-Off menu: For items sometimes frequently or infrequently selected
![Page 26: data Capture and user Input Design](https://reader036.vdocument.in/reader036/viewer/2022062315/56815e8e550346895dcd1e0f/html5/thumbnails/26.jpg)
17-28
Tool Bars
To identify and provide access to common and frequently used actions
![Page 27: data Capture and user Input Design](https://reader036.vdocument.in/reader036/viewer/2022062315/56815e8e550346895dcd1e0f/html5/thumbnails/27.jpg)
17-29
Iconic MenusTo designate applications available and special functions within an application
![Page 28: data Capture and user Input Design](https://reader036.vdocument.in/reader036/viewer/2022062315/56815e8e550346895dcd1e0f/html5/thumbnails/28.jpg)
17-30
Consumer-Style Interface
![Page 29: data Capture and user Input Design](https://reader036.vdocument.in/reader036/viewer/2022062315/56815e8e550346895dcd1e0f/html5/thumbnails/29.jpg)
17-31
Hybrid Windows/Web Interface
![Page 30: data Capture and user Input Design](https://reader036.vdocument.in/reader036/viewer/2022062315/56815e8e550346895dcd1e0f/html5/thumbnails/30.jpg)
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.
![Page 31: data Capture and user Input Design](https://reader036.vdocument.in/reader036/viewer/2022062315/56815e8e550346895dcd1e0f/html5/thumbnails/31.jpg)
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
![Page 32: data Capture and user Input Design](https://reader036.vdocument.in/reader036/viewer/2022062315/56815e8e550346895dcd1e0f/html5/thumbnails/32.jpg)
System and user-oriented error messages
Error #27
Invalid patient id entered?OK Cancel
System-oriented error message
![Page 33: data Capture and user Input Design](https://reader036.vdocument.in/reader036/viewer/2022062315/56815e8e550346895dcd1e0f/html5/thumbnails/33.jpg)
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
![Page 34: data Capture and user Input Design](https://reader036.vdocument.in/reader036/viewer/2022062315/56815e8e550346895dcd1e0f/html5/thumbnails/34.jpg)
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
![Page 35: data Capture and user Input Design](https://reader036.vdocument.in/reader036/viewer/2022062315/56815e8e550346895dcd1e0f/html5/thumbnails/35.jpg)
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
![Page 36: data Capture and user Input Design](https://reader036.vdocument.in/reader036/viewer/2022062315/56815e8e550346895dcd1e0f/html5/thumbnails/36.jpg)
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
![Page 37: data Capture and user Input Design](https://reader036.vdocument.in/reader036/viewer/2022062315/56815e8e550346895dcd1e0f/html5/thumbnails/37.jpg)
Entry points to a help system
Help frame network
Top-levelentry
Entry from errormessage system
Entry fromapplication
![Page 38: data Capture and user Input Design](https://reader036.vdocument.in/reader036/viewer/2022062315/56815e8e550346895dcd1e0f/html5/thumbnails/38.jpg)
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
![Page 39: data Capture and user Input Design](https://reader036.vdocument.in/reader036/viewer/2022062315/56815e8e550346895dcd1e0f/html5/thumbnails/39.jpg)
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
![Page 40: data Capture and user Input Design](https://reader036.vdocument.in/reader036/viewer/2022062315/56815e8e550346895dcd1e0f/html5/thumbnails/40.jpg)
17-43
Help Tool Tip, Help Agent, and Natural Language Processing
![Page 41: data Capture and user Input Design](https://reader036.vdocument.in/reader036/viewer/2022062315/56815e8e550346895dcd1e0f/html5/thumbnails/41.jpg)
17-44
Help Wizard
![Page 42: data Capture and user Input Design](https://reader036.vdocument.in/reader036/viewer/2022062315/56815e8e550346895dcd1e0f/html5/thumbnails/42.jpg)
45
Modeling System Behavior
![Page 43: data Capture and user Input Design](https://reader036.vdocument.in/reader036/viewer/2022062315/56815e8e550346895dcd1e0f/html5/thumbnails/43.jpg)
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
![Page 44: data Capture and user Input Design](https://reader036.vdocument.in/reader036/viewer/2022062315/56815e8e550346895dcd1e0f/html5/thumbnails/44.jpg)
17-47
Partial State Transition Diagram
![Page 45: data Capture and user Input Design](https://reader036.vdocument.in/reader036/viewer/2022062315/56815e8e550346895dcd1e0f/html5/thumbnails/45.jpg)
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
![Page 46: data Capture and user Input Design](https://reader036.vdocument.in/reader036/viewer/2022062315/56815e8e550346895dcd1e0f/html5/thumbnails/46.jpg)
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).
![Page 47: data Capture and user Input Design](https://reader036.vdocument.in/reader036/viewer/2022062315/56815e8e550346895dcd1e0f/html5/thumbnails/47.jpg)
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
![Page 48: data Capture and user Input Design](https://reader036.vdocument.in/reader036/viewer/2022062315/56815e8e550346895dcd1e0f/html5/thumbnails/48.jpg)
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.
![Page 49: data Capture and user Input Design](https://reader036.vdocument.in/reader036/viewer/2022062315/56815e8e550346895dcd1e0f/html5/thumbnails/49.jpg)
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)
![Page 50: data Capture and user Input Design](https://reader036.vdocument.in/reader036/viewer/2022062315/56815e8e550346895dcd1e0f/html5/thumbnails/50.jpg)
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
![Page 51: data Capture and user Input Design](https://reader036.vdocument.in/reader036/viewer/2022062315/56815e8e550346895dcd1e0f/html5/thumbnails/51.jpg)
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
![Page 52: data Capture and user Input Design](https://reader036.vdocument.in/reader036/viewer/2022062315/56815e8e550346895dcd1e0f/html5/thumbnails/52.jpg)
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
![Page 53: data Capture and user Input Design](https://reader036.vdocument.in/reader036/viewer/2022062315/56815e8e550346895dcd1e0f/html5/thumbnails/53.jpg)
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.
![Page 54: data Capture and user Input Design](https://reader036.vdocument.in/reader036/viewer/2022062315/56815e8e550346895dcd1e0f/html5/thumbnails/54.jpg)
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
![Page 55: data Capture and user Input Design](https://reader036.vdocument.in/reader036/viewer/2022062315/56815e8e550346895dcd1e0f/html5/thumbnails/55.jpg)
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
![Page 56: data Capture and user Input Design](https://reader036.vdocument.in/reader036/viewer/2022062315/56815e8e550346895dcd1e0f/html5/thumbnails/56.jpg)
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
![Page 57: data Capture and user Input Design](https://reader036.vdocument.in/reader036/viewer/2022062315/56815e8e550346895dcd1e0f/html5/thumbnails/57.jpg)
17-60
Sample Dialogue Chart