C SC 225 Lecture 14: User Interface Design : Goals

[ previous | schedule | next ]

Source: Designing from both sides of the screen, by Ellen Isaacs and Alan Walendowski, New Riders Publishing, 2002, www.uidesigns.com.

Overview

• User Interface Design is not covered in either of our course textbooks
• I will present highlights from Designing from both sides of the screen
  • Its subtitle : "How Designers and Engineers Can Collaborate to Build Cooperative Technology"
  • Ellen Isaacs is an Interaction Designer (in front of the screen)
  • Alan Walendowski is a Software Engineer (behind the screen)
  • Website is www.uidesigns.com

User Interface Design Goals

• Part 1 of the book is called The Goal. It comprises four chapters
  • On Being a Butler
  • Don't Impose: Respect Physical Effort
  • Don't Impose: Respect Mental Effort
  • Be Helpful
• Today's class features highlights from this part of the book
• The term Human Computer Interaction is a good one to describe what we're studying here

The Butler Metaphor

• Imagine the relationship between a butler and his employer
• Your application's user interface plays the role of the butler
• Your application's users play the role of the employer
• There are stereotypes of an effective relationship between them
• Characteristics of an effective butler:
  • Always available
  • Prepared to perform requested tasks with no complaints
  • Finds ways to deal with problems without bothering employer
  • Does not interrupt with suggestions
  • Pays attention to past behavior to anticipate (but not initiate) future behavior
  • Courteous and respectful at all times
  • Learns to collaborate with employer
• Characteristics of an effective employer:
  • Observes what butler does well
  • Learns through experience the best way to request things
  • Learns to collaborate with butler

Cooperative Principles

• Grice Cooperative Principle for Conversation
• Paul Grice, linguist and philosopher of language
• Four rules (Gricean Conversational Maxims)
• Quality (Truth) : Do not lie or say things for which you have little evidence
• Quantity (Information) : Offer neither too much nor too little information for the situation
• Relation (Relevance) : Be relevant
• Manner (Clarity) : Be clear and brief; avoid obscurity and ambiguity
• Isaacs Cooperative Principle for Technology
• Two rules (from Isaacs and Walendowski book) based on Grice maxims and butler metaphor
• Do not impose
  • Respect user's physical effort
  • Respect user's mental effort
• Be helpful
  • Offer relevant and sufficient information early
  • Solve problems without complaint
  • Be predictable
  • Request and offer only relevant information
  • Use plain language
• These will support user "flow"
• Allow users to focus on task at hand, not the communication tool and steps
• Example of flow: While typing a sentence in Word, you think of your sentence not the keystrokes
• Example of flow disruption: Again in Word, you unknowingly nudge the Insert key while pressing Backspace, then suddenly each character you type consumes one! The flow is gone.
• Relates to "readiness-to-hand" term coined by 20th century philosopher Martin Heidegger and applied to UI Design by Terry Winograd of Stanford

Respect Physical Effort

• Their base metric of physical effort is mouse clicks
• A wide range of user input actions can be expressed in terms of click-equivalents: menu item selection (2), scrolling (1.5), drag-and-drop (2), switching between input devices (0.5) and even rebooting (100!)
• Selected Isaacs/Walendowski Physical Effort Design Guidelines:
  1. Expend great effort to minimize clicks.
  2. Implement feature if customers will save lots of cumulative effort as a result.
  3. Do not ask for confirmation of an action if it can be easily undone or if loss is minimal.
  4. Make features that will be most frequently used the easiest to use, even if it makes infrequent features more difficult.
  5. Next time user comes back, reflect adjustments such as window movements or resizing that were made the last time.
  6. When designing a task, consider what it would be like to do it repeatedly over short period of time.
  7. Design a task so it can be performed using only one input device.
• How would you rank the top 5 in importance?
• Think of how each contributes to user flow
• Why might web developers want to ignore guideline #1? Because each click is an opportunity to present advertisements.
• You can check #5 in Windows by going to System control panel, clicking the Advanced tab, adjusting a setting, applying the setting, and leaving the control panel. Go to the System control panel again. Is it at the same tab where you left it?

Respect Mental Effort

• The concept of user flow is closely related to mental effort
• Selected Isaacs/Walendowski Mental Effort Design Guidelines:
  1. Minimize number of visual elements on screen
  2. Most common tasks should be visible and lesser ones hidden.
  3. Acknowledge each user request and show progress of long operations
  4. Allow user to interrupt commands that might take a long time
  5. Use combined sound and visual clue to indicate event
  6. Provide user preferences to modify appearance, rather than to modify behavior.
  7. Follow interaction conventions for implementation platform.
  8. Include automatic, “widgetless” features within reason
• How would you rank the top 5 in importance?
• Airline websites are a particularly good study for #2
• Regarding implementation platforms, all of them provide design guidelines. Here are a few:
  • Windows Vista: msdn.microsoft.com/library/?url=/library/en-us/UxGuide/UXGuide/Home.asp
  • Macintosh OS X: developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/index.html
  • A collection of links to user interface style guides: www.experiencedynamics.com/science_of_usability/ui_style_guides/
• Handle widgetless features with care; it is better to do nothing than to do something inappropriate

Be Helpful

• Selected Isaacs/Walendowski "Be Helpful" Design Guidelines:
  1. Minimize use of unrequested informational pop-ups. Use persistent window with status message area instead.
  2. Do not interrupt user with problems you can address yourself.
  3. Develop and follow your own conventions, so user can predict how to use new features based on use of existing ones.
  4. Gray out unavailable options rather than allow user to select them then interrupt with message.
  5. Do not request info from user unless and until required.
  6. Avoid using technology-specific jargon in messages and widget wording.
  7. Take the attitude that your software is at fault when something goes wrong.
  8. Avoid "modal" dialog boxes that prevent user from using any other feature until responding.
  9. Label buttons with action term rather than generic Yes, OK, etc. The latter force user to read message carefully.
  10. Have someone outside the team proofread your language (messages, labels) for understandability, clarity, attitude.
• How would you rank the top 5 in importance?
• Relate these to the butler metaphor and cooperative principle for conversation.

Selected Additional Resources

• There are so many great resources it is difficult to highlight only a few.
• GUI Bloopers by Jeff Johnson, www.gui-bloopers.com
• Web Bloopers by Jeff Johnson, www.web-bloopers.com
• The latter has a nice checklist of 60 categorized bloopers.
• Don't Make Me Think! by Steve Krug, a book on Web usability. He has posted a sample chapter and a convenient link to buy it for $25.
• www.sensible.com Steve Krug's website on Web usability
• www.useit.com, Jakob Nielsen's website on usability
• Donald Norman has had a long and distinguished career in usability and is best known for his book The Design of Everyday Things. See his website www.jnd.org and the list of books he has writen and is writing at www.jnd.org/books.html.
• Nielsen and Norman are also partners in a usability consulting form, the Nielsen Norman Group.
• Jef Raskins' book The Humane Interface. Raskin is best known as as the creator (and namer) of the Macintosh project at Apple. He was Apple employee #31 but left before the Mac was completed. He died in 2005.
• Ben Shneiderman's Eight Golden Rules of User Interface Design from his landmark text Designing the User Interface. Here's the short version:
  1. strive for consistency (there are many types)
  2. enable frequent users to use shortcuts
  3. offer informative feedback (feedback for every user action)
  4. design dialogs to yield closure (organize actions into beginning, middle, end)
  5. offer error prevention and simple error handling
  6. permit easy reversal of actions (reduce anxiety, encourage experiment)
  7. support internal locus of control (user is in control, no surprises)
  8. reduce short-term memory load (7+-2 chunks)
• The persons listed above are highly reputable. Shneiderman is one of the most well known and respected persons in all of computer science. Nielsen somewhat less so but he is a giant in the user interface community.
• Beware though that Web design guidelines are a dime a dozen! Exhibit A is a set of guidelines developed by my Fall 1998 User Interface Design class at Southwest Missouri State University