Introduction to Information Systems Analysis Input and User Interface Design

1. Introduction to InformationSystems AnalysisInput and User Interface Design INFO 503 Glenn Booker Lecture #7

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

3. p. 619 (440) 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 Lecture #7

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) Lecture #7

5. 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 Lecture #7

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) Lecture #7

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

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

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

10. p. 628 (446) GUI Input Controls • Familiar GUI controls include • 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

11. p. 633 (none) 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) Lecture #7

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) Lecture #7

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) Lecture #7

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

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

16. 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 Lecture #7

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

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

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

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

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

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!) Lecture #7

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

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

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

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

27. 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 Lecture #7

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

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

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) Lecture #7

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) Lecture #7

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

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) Lecture #7

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!) • cc:Mail wisely put optional text below the icons Lecture #7

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

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

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 application’s command language (e.g. AutoCAD, Mathematica, SQL) • Some use natural language syntax Lecture #7

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

39. 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 Lecture #7

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) Lecture #7

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

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

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

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?) Lecture #7

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

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