Unformatted text preview:

1Fall 2005 6.831 UI Design and Implementation 1  Fall 2005 6.831 UI Design and Implementation 2  Plenty to choose from Nielsen s 10 principles One version in his book A more recent version on his website Tognazzini s 16 principles Norman s rules from Design of Everyday Things Mac, Windows, Gnome, KDE guidelines Help designers choose design alternatives Help evaluators find problems in interfaces (heuristic evaluation)Fall 2005 6.831 UI Design and Implementation 3    User-centered design Know your users Understand their tasks Fitts s Law Size and proximity of controls should relate to their importance Tiny controls are hard to hit Screen edges are precious Memory Use chunking to simplify information presentation Minimize working memory Color guidelines Don t depend solely on color distinctions (color blindness) Avoid red on blue text (chromatic aberration) Avoid small blue details Norman s principles of direct manipulation Affordances Natural mapping Visibility FeedbackFall 2005 6.831 UI Design and Implementation 4!"#  $$%&  Use common words, not techie jargon But use domain-specific terms where appropriate Don t put limits on user-defined names Allow aliases/synonyms in command languages Metaphors are useful but may misleadSource: Interface Hall of Shame2Fall 2005 6.831 UI Design and Implementation 5'"( ) Principle of Least Surprise Similar things should look and act similar Different things should look different Other properties Size, location, color, wording, ordering,  Command/argument order Prefix vs. postfix Follow platform standardsSource: Interface Hall of ShameFall 2005 6.831 UI Design and Implementation 6*+(  Internal External MetaphoricalFall 2005 6.831 UI Design and Implementation 7(,(  Inconsistency is appropriate when context and task demand it Arrow keys But if all else is (almost) equal, consistency wins QWERTY vs. Dvorak OK/Cancel button orderFall 2005 6.831 UI Design and Implementation 8-"   Users don t read manuals Prefer to spend time working toward their task goals, not learning about your system But manuals and online help are vital Usually when user is frustrated or in crisis Help should be: Searchable Context-sensitive Task-oriented Concrete Short3Fall 2005 6.831 UI Design and Implementation 9."( Provide undo Long operations should be cancelable All dialogs should have a cancel button User-provided data should be editableSource: Interface Hall of ShameFall 2005 6.831 UI Design and Implementation 10/"0+) ) 1 Keep user informed of system state Cursor change Selection highlight Status bar Don t overdo it Response time < 0.1 s: seems instantaneous 0.1-1 s: user notices, but no feedback needed 1-5 s: display busy cursor  > 1-5 s: display progress barSource: Interface Hall of ShameFall 2005 6.831 UI Design and Implementation 11/"0+) ) 1Fall 2005 6.831 UI Design and Implementation 122"3 ++  )$  Provide easily-learned shortcuts for frequent operations Keyboard accelerators Command abbreviations Styles Bookmarks HistorySource: Interface Hall of Shame4Fall 2005 6.831 UI Design and Implementation 134" 5 Selection is less error-prone than typing But don t go overboard Disable illegal commands Keep dangerous commands away from common onesSource: Interface Hall of ShameFall 2005 6.831 UI Design and Implementation 14   Intended action is replaced by another action with many features in common Pouring orange juice into your cereal Putting the wrong lid on a bowl Throwing shirt into toilet instead of hamper Going to Kendall Square instead of Kenmore Square Avoid actions with very similar descriptions Long rows of identical switches Adjacent menu items that look similarFall 2005 6.831 UI Design and Implementation 15(  A sequence of actions is replaced by another sequence that starts the same way Leave your house and find yourself walking to school instead of where you meant to go Vi :wq command Avoid habitual action sequences with common prefixesFall 2005 6.831 UI Design and Implementation 16#   Modes: states in which actions have different meanings Vi s insert mode vs. command mode Caps Lock Drawing palette Avoiding mode errors Eliminate modes Visibility of mode Spring-loaded or temporary modes Disjoint action sets in different modes5Fall 2005 6.831 UI Design and Implementation 17# #  Fall 2005 6.831 UI Design and Implementation 18"% 67% #   Use menus, not command languages Use combo boxes, not textboxes Use generic commands where possible (Open, Save, Copy Paste) All needed information should be visibleSource: Interface Hall of ShameFall 2005 6.831 UI Design and Implementation 198" %66% 5 Be precise; restate user s input Not Cannot open file, but Cannot open file named paper.doc Give constructive help why error occurred and how to fix it Be polite and nonblaming Not fatal error, not illegal Hide


View Full Document

MIT 6 831 - Desing Principles

Documents in this Course
Output

Output

15 pages

Quiz 2

Quiz 2

10 pages

Quiz 2

Quiz 2

8 pages

Input

Input

9 pages

Load more
Download Desing Principles
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Desing Principles and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Desing Principles 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?