CSE1IS Information Systems Week 8 Lecture 1 Input Design

The aim of input design is to capture and store the complete, valid data needed to produce the output which leads to effective decision making.

Where possible an input design should avoid involvement by people. Where people have to be involved, the input design:

• should require the mimimum number of keystrokes
• should look appealing to the user

Whilst most input is via a screen/keyboard/mouse there are other input and/or data collection devices which minimise user involvement and should be used where appropriate:

• BarCode reader: basically, just reads a number - but very fast and very accurately
• Data Collection Device: small hand-held devices that are used to help collect data remotely
• Microphone: sound is recorded and stored etc.
  - Voice Input: data entry can be entered via spoken word
• Video Input: video camera input
• Touch Screen: good for help systems.
• Scanner: reads a page as a picture
  - Optical Character Recognition: converts text embedded in a picture into text
• Graphic Input Devices: include light pens, graphics tablets that allow drawings to be easily entered.
• Input Devices for Physically Handicapped Users:
• Direct Entry: from another computer. Transmission could be via fixed network cables, wireless, bluetooth, etc.
• Mobile Phones and PDAs:

Screen Design for Data Input

Guidelines (S.C.&R. p.268, p.354):

• Should be easy to learn and use
  • clearly label all data entry areas
  • meanings of icon images should be clear
  • use yellowtips to provide extra information, especially on icons
• make navigation between screen easy and logical
• Provide features that promote efficiency
  • organise related tasks together
  • selection lists should be organised alphabetically
  • specify appropriate default values
  • specify ALT-Key shortcuts for each menu item and button.
    • i.e. View specifies ALT-V will show the View menu
• Make it easy to obtain help and correct errors
  • detailed User's Manual or Online Help
  • context-sensitive help for each control
  • balloon help
  • Undo button
  • confirmation before deletion
• Minimise data input problems
  • Each data item should never be entered more than once.
       - Once entered it should be selectable from a list.
       - Possible exception: codes - especially in long lists.
  • use controls that only allow valid values
    • eg. radio button for yes/no
  • input masks for typed data
  • validation checks are done immediately data is entered
    • may even be on character-by-character basis, eg. for dates
  • ensure the TAB button rotates through the data entry fields in a logical manner
• Provide feedback to users
  • often with popup message boxes
    • be consistent with their appearance and placement
  • let the user know when an operation is successful (sometimes assumed!)
  • avoid cryptic messages, such as "error 7: Overflow"
• Create attractive screens
  • graphics
  • colours of backgrounds and text
  • generally, keep background colours soft
  • place titles in the same place on each screen (design a template)
  • all screens should be based on the same template
• Use terms that relate to the activity
  • eg. student system would use course, subject, lecturer, student, ..

Controls used on a normal screen:

Screens are made up of individual controls that are fairly standard across all systems.

Data Entry controls:

• label
• text box and text area
  • rich text format
  • password field
• option group
  • radio buttons
• check box
• combo box
• list boxes
• tree view
• toggle button - works similar to a check box
• slider - eg. for volume control
• spinner (spin bar)

Command controls:

• command button
• drop-down menus
• popup menus

Information controls:

• dialogue boxes
  • messages
  • open file
  • print
  • colour/font chooser
• progress bar
• hypertext links

Layout Controls:

• Panel
• Splitter (Split Pane)
• Table

Example Screen:

What controls are used on this screen?

Example Screens showing navigation techniques:

• Using buttons to navigate through the records.
  • Very cumbersome if there are many records


• 
   
• Reducing selection list by some category
  • One-to-Many relationships usually specify such categories
  • eg. each author writes many books.
  • Author selected by comboBox
    Books by that author then displayed in listBox, and can be selected for editing
  • Note: order is important - author must be selected before the book

 

• 
   
• A TreeView Control can allow a more pictorial view of the data
• slow to load if many records
• but good programming will only load records as required:-).

 

• 
   

Web Considerations:

• Data Entry is contained within a Form
• Standard data entry controls are:
  • text box and textarea
  • radio buttons
  • check boxes
  • drop-down lists (comboBox)
  • list boxes (multi-select list)
  • buttons (can have a value associated with it)
• Advanced controls include:
  • Server Side Includes (SSIs)
  • PHP - Hypertext Preprocessor
  • iFrame - a web page inserted within another web page
• Other controls may be displayed via an "Object" tag
  • eg. TreeView, movie, sound
  • however, different agents (browsers) may display them differently
• Page formatting controls:
  • ordered and unordered lists
  • tables
  • pictures

More specific guidelines for input screen design (see p.279, p.363)

• Restrict access to data entry areas only. This is achieved by the positioning of the cursor
• Use meaningful captions or labels  for fields e.g. Customer surname rather than cust-sur
• Show the required entry format. For a date ,    --/---/--, suggests that the date should be entered dd/mmm/yy
• Use the <enter key> or <return key >  to confirm entry
• Provide special characters such as $, /, decimal point so that  the user should not have to enter them. For example $____.__ for a currency field (rather than _______)
• Do not require leading zeroes for numeric fields. For example ___6.87 rather than forcing the user to enter 0006.87
• Use default values where applicable  and think carefully what they may be. Today's date as a default for a date entry field?
• When a code is required either display valid codes or provide a help screen that can be activated
• Allow the user to quit (exit without saving) or to exit and save. For example use the ESC key to quit,  CRTL-END to quit and save. Ensure that you provide the necessary feedback so that the user knows what has happened. Have I saved my work? Confirm such actions i.e. add this record (y/n)?, delete this record (y/n).
• Allow full screen editing, allow navigation from one field to another with re-entering data
• Input screen design should match source document design. This can minimize input errors.

More specific guidelines for screen appearance

• A system will contain many screens and many reports.
• Be consistent in  presentation across your screens. Ensure that they follow a similar layout. For example, put headings in the same place, display navigation buttons in the same place, consistent use of icons etc.
• Use explicit, understandable and polite error messages.
• Provide positive feedback. For example, display anticipated length of processing , use the 'hour glass' or the 'watch', display messages indicating that processing is occurring..
• Allow the user to clear messages at their convenience.
• Use video effects sparingly, particularly `blinking text'. This can be very distracting.
• Pay close attention to colour combinations. Use complementary colours (e.g. yellow and blue, yellow and black, blue and white etc.) and avoid combinations such as red and green or blue and red .

Guidelines for Drawing Screen Designs:

Graphical Screens:

1. Design a detailed template:
• may have sections for:
  - logo
  - headings
  - global menu and/or links
  - local menu/links that change for each page
• Provide specific details:
  - images
  - main headings
  - global menu content and actions
  - font sizes
  - etc.
• leave an area for page content
• provide a print screen showing global template controls
• for web pages, provide related html etc.
2. Sketch other screens:
• outlines for global template
• outline boxes (rectangles) for data entry areas
• specify prompts, labels and images specific to the page
• specify local menu items and links
• specify data source that the page is based on
3. For controls that display data, usually from a database table, eg. a text box displaying a surname, specify the data source
   eg. customer.surname
4. For controls that contain a list of data, eg. comboBox, specify the data source for the list
   - eg. names from customers table
   - may contain multiple columns
   - one column may be 'bound' to a data source that the form is based on
5. For controls that trigger an event, eg. button, specify any processing or logic involved
6. May require multiple sketches for screens that hide/unhide controls, eg. Tab control
7. Screens should follow the Menu Hierarchy

Traditional Text Screens:

• based on 80 columns x 25 lines:
• grid pattern
• every cell represents position of a character
• tables are made up of line characters, which include horizontal and vertical lines, corners and every possible t-junction
• the screen design is drawn up on a 80 x 25 screen layout grid

References:

• Shelly, Cashman & Rosenblatt, Systems Analysis and Design, 6th Edition,  8th Edition, Course Technology, 2006, 2008.

NOTE: this webpage has not been brought up to WCAG 1.0 standard nor does it contain validated HTML