Office of Digital Humanities

DigHT 210/310
Principles of Interface Design

Human Interface refers to the "face" that your software presents to the user. Interface design is a complex topic that I can't hope to cover in a single lecture. I would recommend that if you are interested in the subject that you take a course and read in this area. However, I will try to present some principles that you may use as a guide when designing our own interface.

Know Your User

For any interface to be successful, you must try to predict as accurately as possible how your user thinks. For this reason, it is essential to have a clear idea of your audience, including age, education and computer experience.

One way of avoiding having to do a great deal of research into the way users think is to adopt an existing interface model, one that is proven through research, testing, and use. Whatever you choose to do, whether you use your own interface or adopt an existing one, there are guidelines you can use to make your design a successful one.

The Mental Model vs. the Functional Specification

The functional specification of your software is a checklist of all the features the software should have. But it says nothing about how the features should be organized or how the user will proceed through the program. (A. Marcus, New Media, Feb. 95, p. 100)

The mental (or cognitive) model represents the way the user will encounter your program's functions and data. Research has shown that for your interface to be successful, the user must be able to form a consistent mental model of how the software works and how it is organized. This requires you to plan carefully so that you can assist the user in forming this mental model.

The Interface Metaphor

A key in your effort in helping the user to form an effective mental model of your software is the selection of an appropriate metaphor.

[Look at the metaphor of the MacOS Finder or Windows desktop. This is a good point to discuss what class members found while doing their conventions assignments.]

Both of these interfaces use a desktop metaphor—elements are arranged much as your common workplace environment might be. It is a surface upon which users can place tools, documents and file folders. Menus allow you to give commands and instructions to objects on your desktop. The mouse lets you manipulate them in various ways.

Other commonly used metaphors are the book (cf. Toolbook) and the stack (cf. HyperCard, LiveCode).

The most important concerns in developing an effective metaphor are simplicity, consistency and clarity. Common elements should operate in the same way throughout the program.

Let's look at a few goals and principles to help you in designing an effective metaphor. [based in part on Computer Interface Design Guidelines, by Sallie Gordon. This presentation was excerpted from S. Gordon, Systematic Training Program Design: Maximizing Effectiveness and Minimizing Liability, Prentice Hall, 1994. Additional information drawn from Macintosh Human Interface Guidelines.]

• Create a system that is easy for the learner to use.
  
• At any given point, the user should understand...
  
  • what is being presented,
    
  • what they are required to do or have the option of doing,
    
  • how to accomplish their current goal.

At the same time, the system should display what the system is currently doing, if anything.

Static Screen Design (Screen Layout)
[For more information, see Deborah Mayhew, Principles and Guidelines in Software User Interface Design.]

• Don't try to place too much information on the screen. Tullis (1983) suggests that, based on research, alphanumeric characters should not take up more than 25-30% of the total screen space. This is equivalent to leaving plenty of white space in written documents. Include only information that is really necessary.
  
• Even when trying to keep the screens uncluttered, be sure to include all information that is necessary.
  
• Group characters so that they are moderately (but not extremely) packed.
  
• The items on a screen should be logically grouped so that people perceive the screen as consisting of blocks of related pieces of information. This may often include functional groupings. (eg., navigation elements vs. content elements.)
  
• Leave adequate space around each group of items.
  
• A smaller number of groups is better than a larger number of individual items or a large number of groups.
  
• Put the star on center stage. The most important information should occupy the largest, central area.
  [Show example from Ballet tutorial.]
• Minimize the complexity of the layout.
  [Show Vocabulary Editor: This is an example of a layout (which I created) that I happen to think is not very well designed. In trying to cram as much functionality into one screen as possible, I have made a very cluttered interface. This would require greater learning time on the part of the user.]
  
• Maximize visual predictibility. I.e., "based on a knowledge of the location of some items on the screen, one should be able to predict the locations of others."
  
  [Back to Vocab Tutor. If I wanted to look for a way to return to the starting menu, where would I look? If I wanted to add a "Return to Menu" button, where would I put it?]
  
• Use redundant coding. That is, have two or more different variables providing the same information. For example, active buttons could always be shown as "shadowed rectangles" and also always be colored turquoise blue.
  [I have done this in another way with my Show Example buttons--using both visibility and color.]
• Use symbols or icons for input buttons that are consistent with learners' previous knowledge. For example, a question mark is relatively well known as a symbol for requesting help or information. If possible, use both words and icons .
  The best icon is one that passes "predictive" user testing. That is, the function of an icon, when it first appears on a screen, whould be predictable by a novice user. If you ask them, "what happens when you click this icon?", they should be able to accurately tell you.
  
• Don't use hidden buttons (where parts of the screen are active hot spots, but you can't tell by visual inspection). Exceptions are when (a) all parts of the screen are hot, as in a map or picture with parts acting as hot buttons, and users know this; or (b) the cursor symbol changes when it is over buttons, giving visual feedback that the area is hot.
  
• In most circumstances, start in the upper left-hand corner of the screen, as this is where people habitually begin search and reading (at least in our culture.)
  
• Use upper and lower case for text. Use minimal or no text that is all upper case (Tullis, 1988).
      Read more on fonts and typography.
  
• Blinking is a very strong visual cue and can be distracting. Use only in emergencies or critical situations (or never).
  
• Use reverse video sparingly. Appropriate uses might include indications that an item has been selected, or to indicate an error field.
  
  [demo card shows Vocab Tutor with one item in list highlighted]
  
• Messages should be brief, concise, specific, helpful, and comprehensible. Here are some examples of poor and improved messages from Mayhew (1992).
  
• Use instructional prompts to cue users when they must type or perform other necessary input activity.
  [May be something as simple as a label for a field where data is to be entered.]
  

Designing Interactions

Instructional computer systems should be transparent, that is, at least two things should be readily apparent to the user:

• The overall purpose of the program--what it is used for;
  
• How to interact with the program.

User should know how to accomplish goals, whether they are vague (I'm lost--what do I do next?) or specific (How do I quit?)

Here are some basic guidelines for developing interaction in instructional programs:

• At the beginning, present an overview of how the system works, and how the learner interacts with the system. This may be explicit information or implicit in the screen design.
  
• Provide an advance organizer. This can be something as simple as a list of topics, or a map of the program that clearly conveys the contents.
  
  [Humanities 101 Architecture Tutorial provides good example of this.]
  
• Make use of previously existing knowledge. This can range from using icons such as a "?" to using an entire metaphor. (Desktop, schoolhouse, city metaphors). Most users are now familiar with touching a place on the screen or clicking on buttons with a mouse, so these are good input mechanisms. A variety of symbols may be familiar, depending on the target population.
  
  [VCR or cassette recorder controls]
  
• In general, a graphical interface will be better than command line input for training programs. As always, a designer must match the complexity, input mechanisms, and symbology of a system to the target user population and to the nature of the task.
  
• Use consistent design elements from one screen to the next. This includes color coding for functions, placement of control buttons, use of symbols for icons, etc.
  
• Old Humanities 101 Architecture--Gothic. Example of inconsistent placement of elements.
  
  [example of inconsistent interface from booklet, p. 14]
  
• For most hypertext or hypermedia systems, make the underlying organizational structure hierarchical rather than an unstructured networks of nodes. (See Gordon & Lewis, 1992.)
  
• Avoid the overuse of modal alerts (messages that float atop all other windows and must be dealt with immediately). "A modal alert is like yelling 'Fire!' " (Clifford Nass, quoted in "Six Tips for Better Interfaces", Byte, July 1996, p. 86.)

In summary, a design team must create a simple and obvious system for the user interface, and stick to that system consistently thoughout the instructional program.

Most design teams do this by creating a style sheet, which specifies the characteristics of interface elements in careful detail. Along with this it may also be useful to create a template card, so that for each new card added to your stack, you can simply paste a copy of the template, then change the elements or information unique to that card. HyperCard's card-background structure is very conducive to this approach, allowing you to put common elements on the background so that the design remains consistent.

References

Web:

http://www.baddesigns.com - Examples of poor industrial design.

http://www.webpagesthatsuck.com/ - Often hilarious, always insightful site that gives "awards" for the ugliest or worst web sites. (PG-13 language warning.)

http://homepage.mac.com/bradster/iarchitect/ - Aging but still insightful commentary on computer human interface design, good and bad. Mostly Windows examples.

http://www.d.umn.edu/itss/support/Training/Online/webdesign/usability.html - Many links to usability guidelines for web page design, but also generally applicable to designing interface layout.

http://www.mackido.com - Human interface commentary. Heavily pro-Mac.

http://www.usabilityfirst.com - Even more user interface design commentary.

http://www.xvsxp.com/interface/index.php - A comparison of interface features of Mac OS X and Windows XP from a usability perspective.

Macintosh Human Interface Guidelines, Apple Computer, Inc. Internet document: http://developer.apple.com/techpubs/mac/HIGuidelines/HIGuidelines 2.html

Windows Usability Guidelines, Microsoft Corp. Internet document: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwui/html/uidesign.asp

Nielsen, Jakob, “Ten Usability Heuristics”, http://www.useit.com/papers/heuristic/heuristic_list.html

Print:

Burger, Jeff, "An Elegant Interface Design," New Media. September 1995, p. 77.

Corry, Michael D., "Mental Models and HyperMedia User Interface Design," Educational Technology Review. Spring/Summer 1998, pp. 20-24.

Gordon, Sallie, Systematic Training Program Design: Maximizing Effectiveness and Minimizing Liability. Englewood Cliffs, NJ: Prentice Hall, 1994.

Heckel, P., Elements of Friendly Software Design. San Fransisco, CA: Sybex Books, 1991.

Helander, M., Handbook of Human-Computer Interaction. Amsterdam: North Holland, 1988.

Marcus, A., Graphic Design for Electronic Documents and User Interfaces. New York: ACM Press/Addison-Wesley, 1991.

Mayhew, D., Principles and Guidelines in Software User Interface Design. Englewood Cliffs, NJ: Prentice Hall, 1992.

McFarland, Ronald D., "Ten Points for the Human Interface to Instructional Media", T.H.E. Journal. February 1995, pp. 67-69.

Salvendy, G. (Ed.), Handbook of Human Factors. New York: John Wiley & Sons, 1987.

Salvendy, G. and Smith, M. J., Human-Computer Interaction: Software and Hardware Interfaces. Amsterdam: Elsevier, 1993.

Schneiderman, B., Designing the User Interface. Reading, MA: Addison-Wesley Publishing Co., 1987.

"Six Tips for Better Interfaces," Byte. July 1996, p. 86. (10/1/09 - article seems to be unavailable. Hoping it will reappear soon.—DNA)

 

---