Human Factors

Todd Bacastow

Geography 583

Geospatial Systems Analysis & Design

15-2

Spatial Systems

• Key human factors in spatial systems– Gender (the court is still out)– Spatial cognition

• Declarative• Procedural• Configurational

– Spatial visualization• Manipulation• Rotate• Move• Transform

– Spatial orientation (imagination)

Spatial Systems

– Spatial relations • Patterns• Shape• Layout• Hierarchy• Linkage

– Map reading aptitude– Human spatial information processing

• Perception• Integration• Utilization

– Mental models & problem solving– Computer aptitude– Need/Motivation

15-5

Output Design Guidelines

1. Outputs should be simple to read and interpret.– Include a title.

– Date and time stamp.

– Include sections and headings to segment information.

– Clearly label all fields and columns.

– Include legends for all abbreviations.

– Include only required information. Online provide methods to expand and contract information.

– Report information in format that does not have to be manually edited.

– Information should be balanced across the page or screen.

– Provide for easy navigation.

– Avoid computer jargon and error messages.

15-6

Output Design Guidelines (cont.)

2. The timing of outputs is important.– This can affect how the output is designed an

implemented3. The distribution of (or access to) outputs must be

sufficient to assist all relevant users.– The choice of implementation method affects

distribution4. Outputs must be acceptable to the system users who

will receive them.– Systems analyst must understand how the recipient

plans to use the output

15-7

Output Design Process

1. Identify system outputs and review logical requirements.

2. Specify physical output requirements.

3. As necessary, design any preprinted forms.

4. Design, validate and test outputs using some combination of:1. Layout tools (e.g., hand sketches, spacing charts,

or CASE tools.

2. Prototyping tools (e.g., spreadsheet, PC DBMS, 4GL)

3. Code generating tools (e.g., report writer)

15-8

Screen Output Design Principles

Screen Design Consideration

Design Guidelines

Size The designer should consider the “lowest common denominator.” The default window size should be less than or equal to the worst resolution display in the user community.

Scrolling On-line outputs have the advantage of not being limited by the physical page. This can also be a disadvantage if important information such as column headings scrolls off the screen. If possible, freeze important headings at the top of a screen.

Navigation Users should always have a sense of where they are in a network of on-line screens. Users also require the ability to navigate between screens.

Partitioning In Windows, zones are forms within forms. On the Internet, frames are pages within pages.

Information Hiding

On-line applications offer capabilities to hide information until it is either needed or becomes important. Techniques include drill-down and pop-up dialogue boxes.

Highlighting Highlighting can call users’ attention to erroneous data, exception data, or specific problems. Highlighting can also be a distraction if misused.

Printing Always provide users the option to print a permanent copy of the report.

16-9

Data Capture and Data Entry

Data capture – the identification and acquisition of new data (at its source).

– Source documents – forms used to record business transactions in terms of data that describe those transactions.

Data entry – the process of translating the source data or document (above) into a computer readable format.

16-10

Data Processing

Data processing is all processing that occurs on the data after it is input from a machine readable form.

– In batch processing, the entered data is collected into files called batches and processed as a complete batch.

– In on-line processing, the captured data is processed immediately

– In remote batch processing, data is entered and edited on-line, but collected into batches for subsequent processing.

16-11

Input Implementation Methods

• Keyboard• Mouse• Touch Screen• Point-of-event terminals• Sound and speech• Automatic data capture

– Optical mark recognition (OMR)• Bar codes

– Optical character recognition (OCR)– Magnetic Ink– Electromagnetic transmission– Smart cards– Biometric

16-12

Input Design Guidelines

• 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.– Distance, etc.

• Use codes for appropriate attributes.

16-13

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-14

Bad Flow in a Form

16-15

Good Flow in a Form

16-16

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

16-17

Common GUI Controls

• Text boxes• Radio buttons• Check boxes• List boxes• Drop down lists• Combination

boxes• Spin boxes• Buttons

16-18

Common GUI Controls Uses

• Text boxes– When the input data values are unlimited in

scope• Radio buttons

– When data has limited predefined set of mutually exclusive values

• Check boxes– When value set consists of a simple yes or no

value• List boxes

– When data has a large number of possible values

• Drop down lists– When data has large number of possible values

and screen space is too limited for a list box• Combination boxes

– To provide user with option of selecting value from a list or typing a value that may or may not appear in the list

• Spin boxes– When need to navigate through a small set of

choices or directly typing a data value

16-19

Advanced Controls

• Drop down calendars

• Slider edit controls

• Masked edit controls

• Ellipsis controls• Alternate

numerical spinners

• Check list boxes• Check tree boxes

16-20

Input Design Process

1. Identify system inputs and review logical requirements.

2. Select appropriate GUI controls.

3. Design, validate and test inputs using some combination of:

a) Layout tools (e.g., hand sketches, spacing charts, or CASE tools.

b) Prototyping tools (e.g., spreadsheet, PC DBMS, 4GL)

4. As necessary design source documents.

17-21

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.

17-22

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-23

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-24

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-25

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-26

Guidelines for dialogue Tone and Terminology

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

• Tone:– Use simple, grammatically correct sentences. – Don’t be funny or cute! – Don’t be condescending.

• Terminology– 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-27

User Interface Technology

• Operating Systems and Web Browsers– GUI– Windows, Macintosh, etc– Growing importance of platform independence

• Display Monitor– PC monitors – Non-GUI terminals– Growing importance of devices such as handhelds

Paging – Display complete screen of characters at a time.

Scrolling – Display information up or down a screen one line at a time.

• Keyboards and Pointers– Mouse

– Pens

– Touch

17-28

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-29

A Classical Hierarchical Menu Dialogue

17-30

Sample Dialogue Chart

17-31

Pull-Down and Cascading Menus

menu bar

Pull-down menu

Cascading menu

Ellipses indicates dialogue box

17-32

Dialogue Box

17-33

Pop-Up Menus

17-34

Tool Bars

17-35

Iconic Menus

17-36

Consumer-Style Interface

17-37

Hybrid Windows/Web Interface

17-38

Instruction-Driven Interfaces

• Language-based syntax is built around a widely accepted command language that can be used to invoke actions– SQL

• Mnemonic syntax is built around commands defined for custom information systems.– Commands unique to that system and meaningful

to user

• Natural language syntax allows users to enter questions and command in their native language

17-39

Instruction-Driven Interface

17-40

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.

17-41

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. Obtain user feedback. – Exercising (or testing) the user interface

4. If necessary return to step 1 or 2