CSE1IS Information Systems Week 8 Lecture 1 User Interface and Input Design

1. User Interface:

General aims of the user interface is to:

• get information (data) from the user into the information system.
• provide information for the user in an easily understandable format.

Whilst most input is via a screen/keyboard/mouse there are other input and/or data collection devices:

• 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:

2. Menu Hierarchy Design:

Menu screens are those which allow a user to navigate their through an application. Essentially a user is presented with a list of options and they select the one they wish to follow. The selection may be by:

• key press
• mouse click
• light bar (highlighted option)

When designing a menu structure you will be faced with several possibilities. As a general principle you should  group menu selections logically (from the user's  perspective). For example,  reports,  system utilities, database maintenance etc.

Menu systems can be designed using a menu hierarchy or dialogue chart. These simply show a hierarchy of menu screens and the relationships between them as in S.C.&R. Figure 6.24:

Menu options can be shown as:

• menu bar across top of window (most windows applications)
• popup context menu, shown by right mouse click - specialised for each data entry control
• series of buttons or hyperlinks (S.C.&R. Figure 6-26)
• drop down submenus (popular in web applications, eg. theage.com.au or Willowbank Raceway
• list of options down a left or right column (popular for web applications eg. ironbark)
• tabs (eg. theage.com.au/business)

Menu construction guidelines:

• Use a consistent heading structure
• Be consistent in general presentation
• Allow user to return to previous menu (or exit from top level menu)
• Restrict the number of selections to somewhere between five and nine options.
  This follows from the general rule of thumb that says that humans beings can only deal with somewhere between five and nine concepts at any given time.
• A user should never be confused about where they are within the system.
• provide navigation prompts. eg.: Ironbark Home → Subjects → SDE Home

Web-based Considerations:

• Across the top and down the left column is standard
• Use a template to keep menu options always on the browser screen, but loading the main area with selected page
  • Concept of Menu Hierachy is often lost, as the user can bookmark any page then reenter at that position next time
• May need to program to enforce starting at the top menu
• Provide navigation prompts. eg.: Ironbark Home → Subjects → SDE Home

3. Screen Design for Data Input:

3.1 Guidelines (S.C.&R. p.268):

• 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, ..

3.2 Controls used on a normal screen:

Screens are made up of individual controls that are fairly standard across all systems. The diagram shows the controls available in Java's Swing Class.

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

3.3 Example Screen:

S.C.&R. Fig 6-29

Controls are:

3.4 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:-).
• 
   

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

5. Guidelines for input screen design (see p. 279 )

• 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.

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

7. Guidelines for Drawing Screen Designs:

7.1 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

7.2 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,  Course Technology, 2006.

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