Transcript Introduction to Information Systems Analysis Input and User Interface Design INFO 503 Glenn Booker INFO 503 Lecture #7

Introduction to Information
Systems Analysis
Input and User Interface Design
INFO 503
Glenn Booker
INFO 503
Lecture #7
1
Input Design
• Data is captured on some device, then data
entry puts it in the information system
– Data may reside on source documents
and get entered via data entry
– Key is to determine when and how to capture
data for each type of transaction
• Batch and online data collection methods
were already discussed
INFO 503
Lecture #7
2
Automatic Data Collection
p. 619
(440)
• Many automation methods to choose from:
– The traditional keyboard & mouse
– Biometric data includes fingerprint readers
and retinal scanners; pricey but accurate
– Electromagnetic input includes EZ-Pass (RF)
– Magnetic ink readers include credit card
scanners and ATM/MAC card readers
– Sound and speech recognition can be used
INFO 503
Lecture #7
3
Automatic Data Collection
– Optical readers include bar codes and flatbed
scanners, some of which can be sent through
OCR for interpretation
– Smart cards are more expensive, but contain
more info than credit cards
– Touch screens and pen inputs have adapted
to many industries (mfg, food service, etc.)
– POS terminals (including ATMs)
– Optical mark recognition (Scantron tests)
INFO 503
Lecture #7
4
Design Issues
• Capture only variable data - don’t
bother inputting data which could be
obtained elsewhere
• Similarly, don’t capture data which
may be calculated or stored
• Use codes to describe attributes when
possible; translate later using tables
INFO 503
Lecture #7
5
Design Issues
• If source documents are used to capture data
– Include careful instructions for
completing form
– Minimize handwriting
– Make sure sequences of data entry are logical
– Isolate data which does not need to be entered
– Use a familiar metaphor (checkbook, folder)
– (see other GUI input considerations later)
INFO 503
Lecture #7
6
Controlling Inputs
• Monitor number of controls to help ensure
data elements are all present
– Know how many inputs should be present for
batch processing
– Or check each input document one at a time
– On-line, log inputs to an audit file
INFO 503
Lecture #7
7
Controlling Inputs
• Ensure data is valid
– Make sure all mandatory fields are present
– Check type and domain limits on input values
– Check combinations of inputs to ensure logical
relationships exist (no Kia Testarossa!)
– Validate primary keys with a check digit or sum
– Ensure data is in a correct format for each field
INFO 503
Lecture #7
8
GUI Input Controls
• GUI inputs choices are affected by
repository-based programming,
– Each element (widget) is drawn from a
shared system
– GUI controls are selected from the repository
• This helps encourage reuse, supports
configuration control, and allows automatic
generation of data dictionaries
INFO 503
Lecture #7
9
GUI Input Controls
•
p. 628
(446)
Familiar GUI controls include
1.
2.
3.
4.
5.
6.
7.
8.
INFO 503
Text box (field which isn’t limited in choices)
Radio button (set of exclusive options)
Check box (for individual Y/N)
List box (many fixed options)
Drop-down list (many fixed options)
Combo box (text and list; allows new entries)
Spin box (scrolling a few values up & down)
Button (which runs a script, module, or macro)
Lecture #7
10
Advanced Input Controls
p. 633
(none)
• Other GUI control options include:
–
–
–
–
–
–
–
INFO 503
Drop down calendar (for choosing dates)
Slider edit control (volume adjustment)
Masked edit control (fancy text box)
Ellipsis control (to bring up a window)
Alternate spinner (to select a number)
Hyperlink (ala WWW)
Check list or check tree box (related options)
Lecture #7
11
Input Prototyping
• Focus on content, appearance, and
functionality of inputs
• Four steps:
–
–
–
–
INFO 503
1. Identify Input Requirements (data and logic)
2. Select the GUI Controls
3. Design, validate and test the Input Screen
4. Design the Source Document (if needed)
Lecture #7
12
1. Identify Input Requirements
• Should have physical and/or logical data
flow diagrams for each design unit
• Review the attributes needed
• Make sure you know how each output is
traced to an input, looked up, or calculated
• Identify how each input will be entered
(batch, online, or automatic data collection)
INFO 503
Lecture #7
13
1. Identify Input Requirements
• Identify which attributes need to be input
• Determine if inputs can be merged to use
the same interface screen
• Define the label which will be used for
each attribute
• Determine possible values, field size and
format controls needed for each attribute
INFO 503
Lecture #7
14
2. Select the GUI Controls
• Now the scope of contents for each input
have been defined
• Identify how each input will be controlled,
based in large part on the number of values
each may have
• Choose from the earlier list of controls
how each field will be presented
INFO 503
Lecture #7
15
3. Design the Input Screen
• Keep in mind your organization’s standards
or policies for input screens (if any)
• Data issues for designing inputs
– Use color or shading to distinguish editable
from non-editable fields (no, I didn’t say “edible”)
– Input masks may help guide data entry
– Try to identify a logical order for data entry;
usually from general data to detailed data
INFO 503
Lecture #7
16
3. Design the Input Screen
– Consider security features to prevent data
corruption and incorrect entries
• Control issues for designing inputs
– Identify the controls needed for each screen
• New, Edit, Previous, Next, Delete, Exit
– Group and label related types of controls
– Consider how the user will be able to fix or
undo previous actions (clear fields, etc.)
– Use consistent size and spacing of controls
INFO 503
Lecture #7
17
3. Design the Input Screen
• Help issues for designing inputs
– Consider how the user will obtain help, or
receive instructions on using the form
– In addition to help screens, consider how the
user may find more detailed information
• Ask what the user will first need on a screen
• Whenever possible, develop a prototype of
the screen, and get user feedback to refine it
INFO 503
Lecture #7
18
4. Design the Source Document
• If source documents will be used to
capture data, need to design them too
• May start with a simple sketch
• Generally use zones to group
related information
• Data which appear only once are
separated from repeated data
INFO 503
Lecture #7
19
4. Design the Source Document
• Calculated fields, such as totals, are usually
put at the bottom of the document
• Plan where to put instructions
and signatures
• May develop prototype in a word processor,
or spreadsheet, or CASE tool
INFO 503
Lecture #7
20
Web Input Considerations
• Should be more visually appealing
• A navigation bar or shared border often
appears on the left of the screen
• Similar controls are available
– A clear control for proceeding to the next page
(Checkout, Continue, or Next) is needed
– Back and Forward buttons (Previous/Next)
may simplify some navigation
INFO 503
Lecture #7
21
User Interface Design
• Systems users may be either expert
(power or dedicated user) or novice
(casual or beginner user)
• More experienced users focus more on
minimal effort to get the job done
• Casual users need more Help, and may quit
if discouraged (especially on the Web!)
INFO 503
Lecture #7
22
Human Factors
• Frequent interface problems include:
–
–
–
–
–
INFO 503
Excessive jargon and acronyms
Counter-intuitive design (user hostile)
Unclear options (what do I do next?)
Inconsistent problem-solving approach
Inconsistent design
Lecture #7
23
Human Factors
• To avoid these problems, follow the Galitz
commandments of user interface design
–
–
–
–
INFO 503
Understand your users and their tasks
Involve the user in interface design
Test the system on actual users
Practice iterative design
Lecture #7
24
Human Engineering Guidelines
• Users should always be aware of what
to do next
–
–
–
–
What is the system expecting right now?
Was data accepted or rejected?
Is there a reason for delay?
Was the last task completed or not?
• Status information should consistently
appear in one part of the screen
INFO 503
Lecture #7
25
Human Engineering Guidelines
•
•
•
•
Display messages until the user clears them
Use obnoxious display tricks RARELY
Specify default values and answers clearly
Anticipate common errors
– Force a fix if an error occurs, or cancel function
• Lock out the user if something terrible
happens, and tell them to call support
INFO 503
Lecture #7
26
Appropriate Tone & Terms
• Dialogue tone should be helpful & friendly
– Use simple sentences with proper grammar;
conversational tone is fine
– Don’t be funny or cute (especially for
frequently repeated messages)
– Don’t be condescending or threatening
• Avoid jargon
• Avoid TLA’s
INFO 503
Lecture #7
27
Appropriate Tone & Terms
• Use simple terms
• Use terminology consistently
(edit vs. modify)
• Select clear action verbs for instructions
– Select, type, or press something instead of pick,
enter, or hit
– Position a cursor instead of pointing it
INFO 503
Lecture #7
28
User Interface Design
• User Interface Design is a conversation
between the system and the user
• Need to consider platforms used by
different users
– Windows vs. Macintosh vs. Unix/Linux
• Palm OS vs. WinCE for handhelds
– Internet Explorer vs. Netscape
• Often want platform independent interface
INFO 503
Lecture #7
29
Display Features
• The available display features will affect
your user interface
– Size of the display area (e.g. 600 x 800 pixels)
– Character sets and graphics availability
– Terminals are 25 lines by 80 or 132 columns
• Paging (to jump to a new screen of data)
• Scrolling (to move up & down slowly)
INFO 503
Lecture #7
30
Display Features
• Split screen (to show two separate areas in
one screen)
• Windowing (to create resizable windows)
• Programming function keys to have specific
purposes for your system (WordPerfect 5.1)
• Pointer options (mouse, trackball, pens)
INFO 503
Lecture #7
31
User Interface Design
• The text-based Menu selection strategy
offers the user a set of command options
to choose from
– DOS and Gopher systems used this
• GUI systems generally use windows for
display of information, with menu bars to
control user actions
– Frames define zones within a window
INFO 503
Lecture #7
32
Menu Structure
• Menu bars are often across the top of the
screen, like most Windows apps
• Each leads to a pull-down menu; a vertical
list of options
• Some menus are portable via tear-off menus
• More related details can be provided in
cascading menus (follow the side arrows)
INFO 503
Lecture #7
33
Menu Structure
• Pop-up menus appear anywhere,
e.g. by right clicking – this is to
provide object-specific options
• Iconic menus are better known as toolbars,
but the meaning of images may not be clear
to some of us (pet peeve!)
– cc:Mail wisely put optional text below the icons
INFO 503
Lecture #7
34
Consumer-style Interface
• A consumer-style interface refers to one
which is a collection of images, some of
which happen to be buttons or controls
– Many CD burning and media player
applications use this approach to look
less computer-like
– Is fast becoming common
INFO 503
Lecture #7
35
Hyperlink Menus
• Many web-based systems use hyperlinks
for the same navigation purpose
menus provided
– Some web sites are almost completely
hyperlinks (news sites like CNN or Google)
– Some Windows applications use what appear to
be hyperlinks for connecting to Help screens
INFO 503
Lecture #7
36
Instruction Set Interfaces
• Instruction set interfaces are also known as
command language interfaces
• Mostly designed for expert users
• Language-based syntax requires learning
each application’s command language
(e.g. AutoCAD, Mathematica, SQL)
• Some use natural language syntax
INFO 503
Lecture #7
37
Question and Answer Dialogue
• Used to supplement menu-driven or
instruction set languages
• Must define a default response for
each question
• Hard to trace all possible sets of responses
• Often used in installation routines,
or to help users select a product
INFO 503
Lecture #7
38
Direct Manipulation
• Drag-and-drop interfaces fall into this
category, starting with Apple’s Finder,
then the Windows Explorer
• All of the GUI interface controls also fit
this category
INFO 503
Lecture #7
39
User Authentication
• Most applications require the user to log in,
generally with a user name and password
• Authorizes different levels of functionality
depending on:
– The type of user (role or job title, RBAC)
– The organization (department or project) they
belong to (OBAC)
– User-specific functionality (Jane Smith)
INFO 503
Lecture #7
40
Help System
• Most users expect lots of help available
–
–
–
–
–
–
General help (F1 key or Help menu)
Tool tips to identify specific controls
Context-sensitive Help
Hyperlinks for additional information
Wizards may be elaborate Help functions
Help agents work across apps (the paperclip)
• RoboHelp is a typical help authoring tool
INFO 503
Lecture #7
41
Prototyping a User Interface
• Three steps to design a user interface:
–
–
–
–
INFO 503
1. Chart the user interface dialogue
2. Prototype the dialogue and user interface
3. Obtain user feedback
4. Go back to step 1 or 2 as needed until done
Lecture #7
42
1. Chart the Dialogue
• Use a state transition diagram (STD?) to
show how the user interacts with the system
– Looks like a flowchart
– Each box is a screen or report
– Lines between boxes indicate which
way users may navigate
– Can add text next to lines to describe
what the user did to use that function
INFO 503
Lecture #7
43
1. Chart the Dialogue
• Complex dialogues may be broken into
different diagrams by type of activity
• State transition diagrams may omit help
and error screens for an overview, or
show all details
• Can show what different kinds of users can
do (what screens can administrators see?)
INFO 503
Lecture #7
44
2. Prototype the Dialogue
and User Interface
• Walk through the screens in order they
would be seen by the user
• Keep in mind that screens or options visible
may change depending on the type of user
• Make sure each transition can be clearly
identified from each screen (navigation)
• Make sure look and feel are consistent
INFO 503
Lecture #7
45
3. Obtain User Feedback
• Let the user test the user interface; either
with real screens or sketches
– Note observations and complaints; review
them and revise designs as needed
– Repeat until users are happy with interface
• Revise design unit requirements to
match the new interfaces
INFO 503
Lecture #7
46