Designing User Interfaces For A Database System

Lecture 1 of 1

MIS 3053

Database Design & Applications

The University of Tulsa

Professor: Akhilesh Bajaj

©Akhilesh Bajaj, 2001,2002. All rights reserved

Objectives

• Look at design rules for designing different aspects of a GUI for a database system:

- General design rules for user interfaces- Rules for designing menus- Rules for designing fill-in forms- Rules for designing error messages- Rules for designing user manuals

• Learn some methods to involve users in the testing of the GUI

• Learn a process we can follow when building real-world databaseapplications, that creates a good GUI for the end-users.

General Design Rules for User interfaces

5 measurable factors that are central to evaluation of a GUI: (From Schneiderman: Designing the User Interface)•Time to learn: How long does it take a typical user to learn to use the system effectively?

• Speed of performance: How long does it take to carry out benchmark tasks?

• Rate of errors by users: How many and what types of errors do typical users make when using the system?

Retention over time: How well does a typical user retain knowledge of how to use a system after an hour, a day or a week?

Subjective Satisfaction: How much do users like different aspects of the system?

General Design Rules for User interfaces

4 factors that are central to evaluation of end-user software: (Completed Research by Brinton, Bajaj and Gorr at CMU)

• Learnability: How long does it take a typical user to learn to use the system effectively?

• Reliability: How correct is the system, in terms of expected functionality?

• Response Time: How quickly does the system respond to end-users?

Feature Set: Does the system have sufficient features to performits basic functionality?

These factors have come from senior IS managers oflarge corporations in Pittsburgh. Reliability was most important.

General Design Rules for User interfaces

General Rules of Usable Interfaces:(From Nielsen: Usability Engineering)• Mapping between canvas views and user tasks: The mapping should be one-one.

• Grouping: Things of similar color, size and shape, and in closerspatial proximity are perceived as belonging to a group.

• Less is More: No extraneous information that distracts users, no extraneous colors, not too many choices on a canvas view.

• Speak the User’s Language: The GUI should use terms that the users use. E.g., refund v/s encashment v/s payout.

• Minimize User memory Load: Use a small number of rules that apply throughout system. E.g., use consistent units of measurement for quantities in system.

General Design Rules for User interfaces

General Rules of Usable Interfaces:(Continued)• Consistency: Use the same commands for the same thing each time. E.g., save v/s update v/s store.

• Feedback: Consistently give the user feedback that lets them know where they are and possible options. E.g., MS error messages have become better over the years.

• Response time: 1.0 seconds is the limit for the user’s flow of thought to be uninterrupted. 10 seconds is the limit for keeping the user focussed on the dialogue on the screen.

•Clearly marked Exits: Users should be able to exit the system easily from several points in the system.

• Use good error messages, prevent errors and provide on-line help.

General Design Rules for User interfaces

8 Golden Rules of Interface Design: (from Schneiderman: Designing the User Interface)1. Strive for Consistency: many forms of consistency: consistency of items on canvas views, consistency of color, consistency of language used, consistency of error handling, on-line help, etc.

2. Enable frequent users to use shortcuts: Give users the options to use shortcuts, hidden keys, macros, etc.

3. Offer informative feedback: Use alert boxes in database applications.

4. Design dialogs to yield closure: Every action should be part of a sequence that has a beginning, a middle and an end. E.g., save or go back to previous view in a database application. Feedbackonce rows are added, modified or deleted.

General Design Rules for User interfaces

8 Golden Rules of Interface Design: (Continued)5. Offer Error Prevention and Simple Error handling: Design the system so users cannot make a serious error, and if they do, the system should print an informative error message and exit gracefully. E.g., do not allow alphabetic characters in numeric fields. 6. Permit Easy Reversal of Actions: This feature relieves anxiety, since users know they can undo a bad action. E.g., undo a save to a database by providing an alert box before really committing.

7. Support Internal Locus of Control: Users should sense they are in charge of the system, and should be the initiators of actions, rather than responders to actions.

8. Reduce short term memory load: Users can only keep 7 ± 2chunks of information in Short Term Memory.

Rules for Designing Menus

• Note: When we talk about menus, we are talking about the canvas view buttons we shall create for navigation; not about the custom menus we can build using D2K. • Menus have to logically categorize activities or objects that the users believe fit into distinct categories.

• Use user terminology when creating menu choices.

• Don’t have more than 7-8 items on a menu.

• Keep all choices consistent on a menu.

• Menus could be single, trees, acyclic networks (more than one node points to another) and cyclic networks (a node points to another, which points back to it).

Rules for Designing Menus

• Tree Structured Menus: When objects or activities are can be categorized into mutually exclusive categories. E.g., male, female; animal, vegetable, mineral; spring, summer, fall, winter; fonts, size, style, spacing.

• Menu trees should not be over 3 levels deep, usually.

• Acyclic or Cyclic network menus: These are usually more appropriate in a real-world application. E.g., providing team information from both conference and school canvas views.

• Always give the user a choice of moving to another canvas view, or exiting the system. One option as we go down the menu network, is to give the users the choice of going back to either the main menu, or the earlier menu.

Rules for Designing Menus

Choice Presentation: • Present more frequently used choices first

• Use the keyword in each choice to the left (i.e., first). E.g., Save File is better than Press here to Save File.

• Use same size buttons, same color, same font, same font size, similar number of words per choice, no conflicting terms in a menu (e.g., imagine a menu with choices: save, update, cancel: this causes confusion between save and update).

• Make sure choices are aligned the same way on the canvas view.

• The title can be centered or left justified.

Rules for Designing Fill-in Forms

• Use a meaningful title, that describes the data being filled in, or the activity being performed.

• Logically group and sequence fields, using same colors or spatial proximity for each group. . E.g., on a page that captures customer information, name information is one group, street address is another group, city, state and zip is another group, telephone, fax e-mail, web page is another group.

• Use a uniform distribution throughout the canvas view. So, we shouldn’t clump everything on one side, and leave large parts of the canvas view blank.

• Use visible space and boundaries for data entry fields.

• Generate error messages for incorrect data at the field itself.

• Optional fields should be clearly marked.

Rules for Designing Fill-in Forms

• Create an auto-hint for each field, that describes the information in the field.

• Use list boxes (LOVs) when selecting an existing record.

• Try to create patterns for fields (Format Masks). E.g., telephone numbers: (XXX) YYY - ZZZZ, SSN: XXX-XX-XXXX, etc. Use format masks for this.

• Provide an alert before fill-in form is ready to be saved.

• Use consistent font, font size across the fields

• Put optional fields in each group last.

• Label of field should begin with the keyword on the left (i.e., first word). E.g., Name is better than Customer Name

Rules for Designing Error Messages

• The phrasing of error messages is critical

• Avoid ambiguous, generic messages that are imperious or signify some sort of catastrophic failure. E.g.,Message Better MessageSYNTAX ERROR Unmatched left parenthesisILLEGAL ENTRY Select from one of the given choicesDISASTROUS String space consumed. ReviseSTRING OVERFLOW string to fit in space.

• Words like ILLEGAL, INVALID, BAD, DISASTER should be eliminated from error messages.

• Focus on user. E.g., instead of saying: ENTER DATA (makes the user feel not in control), we can say: READY FOR ENTRY.

Rules for Designing Error Messages

• The message should be upper and lower case. Reserve ALL UPPER CASE lettering for more serious error messages.

• Use same font for all error messages.

• Offer the user a choice at the error message (possible using an alert box in D2K).

• Prevent users from making errors as far as possible. E.g., changing the primary key can be prevented by making the field non-updateable.

Rules for Designing User Manuals

• All terms used in our system should be properly defined

• The hierarchy of menus should be well explained

• Each potential business activity should b explained, with a listing of all steps to be taken on the system to perform the activity.

• Use examples when describing the functionality of the system.

• Use hypertext in on-line help.

• Provide a quick-start section, that allows the users to get started quickly.

• Provide auto hints on line.

Rules for Designing User Manuals

• Some systems come with a series of manuals: getting started, basic reference, advanced reference, etc. Oracle manuals are a case in point!

• Discussion point: Is it a mistake to offer several different manuals??

•Proposal: Offer 2 types of manuals. First, the business process manual, that describes the different business processes that can be accomplished by the system, and the steps taken on the system for each process. Second, offer the reference manual that defines every term used in the system, every part of the system, and defines all the (company-specific) terminology used in the system. Manuals offer a chance to capture organizational knowledge, an opportunity that is often not taken.

Methods for User Testing

• Expert Reviews: Experts are experienced programmers (who have worked on systems before, for the same end users preferably). Even if they are not involved in the current system, getting them to review the screens of the system can prevent embarrassing errors.

• User Surveys: The basic idea is: get a group of end-users to use the system, and have them fill out a survey. Some ways to make this meaningful:

- Select users carefully. Either a random sample, or potentially influential users who will encourage others to use the system later. - Pilot test the questionnaire you come up with, with 3-4 users, making sure the questions are non-ambiguous and asking what e think they are asking. - Use a similar grading scale for all questions, e.g., 3 point likert scale: Bad Average Good.

Methods for User Testing

• Acceptance testing: A set of test cases is drawn up (usually, these are the typical business processes the system will support). Users simulate performing these tasks on the system. If the system passes these test cases, it is deemed “acceptable”.

• Prototyping: Very important in databases. Make the prototype early. The initial prototype is simply the canvas views of the system. Then slowly add functionality, and incrementally test the system with end-users. Tools like D2K make prototyping easy.

• Interviews and focus group discussions: Open-ended interviews are great for getting feedback. E.g., “how did you feel about the system?” Focus groups are a group of users who use the system and then sit together and discuss the pros and cons of the system, while the programmers listen (with no comments).

Methods for User Testing

• On-line bulletin board or newsgroup: Depending on the technical sophistication of the end-users, a newsgroup or bulletin board can be set up. These are often valuable tools, especially the FAQ. The same problems happen to multiple users, and these boards or newsgroups allow users to learn from each other.

• Help desk: Most large systems have a help desk set up (usually one of the programmers occupies the desk) at the time of launch. It’s a good idea to solicit comments from users at the help desk, and use these in the next version of the system.

Pointers to Further Literature on GUI Design

Books:• Ben Schnederman. “Designing the User Interface”, third

edition, Adddison Wesley, 1998.

• Jakob Nielsen. “Usability Engineering”, AP Professional, 1993.

• Thomas K. Landauer. ‘The Trouble with Computers: Usefulness, Usability and Productivity”, MIT Press, Cambridge, 1995

Web: • http://usableweb.com/

• http://is.twi.tudelft.nl/hci