Title: Introduction to Information Systems Analysis Input and User Interface Design
1Introduction to InformationSystems
AnalysisInput and User Interface Design
2Input 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
3Automatic 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
4Automatic 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)
5Design Issues
- Capture only variable data - dont bother
inputting data which could be obtained elsewhere - Similarly, dont capture data which may be
calculated or stored - Use codes to describe attributes when possible
translate later using tables
6Design 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)
7Controlling 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
8Controlling 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
9GUI 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
10GUI Input Controls
p. 628 (446)
- Familiar GUI controls include
- Text box (field which isnt 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)
11Advanced Input Controls
p. 633 (none)
- Other GUI control options include
- 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)
12Input Prototyping
- Focus on content, appearance, and functionality
of inputs - Four steps
- 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)
131. 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)
141. 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
152. 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
163. Design the Input Screen
- Keep in mind your organizations 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 didnt 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
173. 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
183. 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
194. 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
204. 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
21Web 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
22User 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!)
23Human Factors
- Frequent interface problems include
- Excessive jargon and acronyms
- Counter-intuitive design (user hostile)
- Unclear options (what do I do next?)
- Inconsistent problem-solving approach
- Inconsistent design
24Human Factors
- To avoid these problems, follow the Galitz
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
25Human 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
26Human Engineering Guidelines
- Display messages until the user clears them
- Use obnoxious display tricks
- 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
RARELY
27Appropriate Tone Terms
- Dialogue tone should be helpful friendly
- Use simple sentences with proper grammar
conversational tone is fine - Dont be funny or cute (especially for frequently
repeated messages) - Dont be condescending or threatening
- Avoid jargon
- Avoid TLAs
28Appropriate 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
29User 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
30Display 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)
31Display 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)
32User 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
33Menu 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)
34Menu 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!) - ccMail wisely put optional text below the icons
35Consumer-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
36Hyperlink 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
37Instruction Set Interfaces
- Instruction set interfaces are also known as
command language interfaces - Mostly designed for expert users
- Language-based syntax requires learning each
applications command language (e.g. AutoCAD,
Mathematica, SQL) - Some use natural language syntax
38Question 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
39Direct Manipulation
- Drag-and-drop interfaces fall into this category,
starting with Apples Finder, then the Windows
Explorer - All of the GUI interface controls also fit this
category
40User 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)
41Help 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
42Prototyping a User Interface
- Three steps to design a user interface
- 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
431. 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
441. 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?)
452. 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
463. 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