Transcript No Slide Title

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 database
applications, 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 perform
its basic functionality?
These factors have come from senior IS managers of
large 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 closer
spatial 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, online 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. Feedback
once 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 ± 2
chunks 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-XXXXXX, 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 Message
SYNTAX ERROR
Unmatched left parenthesis
ILLEGAL ENTRY
Select from one of the given choices
DISASTROUS
String space consumed. Revise
STRING 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