Introduction to Information Systems Analysis Input and User Interface Design

1
Introduction to InformationSystems
AnalysisInput and User Interface Design

• INFO 503
• Glenn Booker

2
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

3
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

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

5
Design 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

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

7
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

8
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

9
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

10
GUI 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)

11
Advanced 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)

12
Input 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)

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

14
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

15
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

16
3. 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

17
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

18
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

19
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

20
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

21
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

22
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!)

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

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

25
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

26
Human 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
27
Appropriate 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

28
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

29
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

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

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

32
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

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

34
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!)
• ccMail wisely put optional text below the icons

35
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

36
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

37
Instruction 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

38
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

39
Direct 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

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

41
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

42
Prototyping 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

43
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

44
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?)

45
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

46
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