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

INFO 503Lecture #72 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 503Lecture #73 Automatic Data Collection 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 p. 619 (440)

INFO 503Lecture #74 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 503Lecture #75 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 503Lecture #76 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 503Lecture #77 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 503Lecture #78 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 503Lecture #79 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 503Lecture #710 GUI Input Controls Familiar GUI controls include 1.Text box (field which isn’t limited in choices) 2.Radio button (set of exclusive options) 3.Check box (for individual Y/N) 4.List box (many fixed options) 5.Drop-down list (many fixed options) 6.Combo box (text and list; allows new entries) 7.Spin box (scrolling a few values up & down) 8.Button (which runs a script, module, or macro) p. 628 (446)

INFO 503Lecture #711 Advanced Input Controls 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) p. 633 (none)

INFO 503Lecture #712 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)

INFO 503Lecture # 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 503Lecture # 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 503Lecture # 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 503Lecture # 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 503Lecture # 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 503Lecture # 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 503Lecture # 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 503Lecture # 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 503Lecture #721 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 503Lecture #722 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 503Lecture #723 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

INFO 503Lecture #724 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

INFO 503Lecture #725 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 503Lecture #726 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

INFO 503Lecture #727 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 503Lecture #728 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 503Lecture #729 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 503Lecture #730 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 503Lecture #731 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 503Lecture #732 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 503Lecture #733 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 503Lecture #734 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 503Lecture #735 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 503Lecture #736 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)CNN Google –Some Windows applications use what appear to be hyperlinks for connecting to Help screens

INFO 503Lecture #737 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)AutoCADMathematicaSQL Some use natural language syntax

INFO 503Lecture #738 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 503Lecture #739 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 503Lecture #740 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)RBAC –The organization (department or project) they belong to (OBAC) –User-specific functionality (Jane Smith)

INFO 503Lecture #741 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 toolRoboHelp

INFO 503Lecture #742 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

INFO 503Lecture # 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 503Lecture # 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 503Lecture # 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 503Lecture # 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