1. 3461 Design Principles and Guidelines Hints for good design

2. 3461 Attributes of Good UIs  Invisible  They don’t get in your way  Minimal training  Easy to learn  Good manual (perhaps online) emphasizing how users can meet their goals  Training transfers easily to practice  Error savvy  Predictable: NO SURPRISES!  Prevent the user from making errors  Easy to recover from errors  Avoid information overload

3. 3461 Attributes of Good UIs (2)  Allow people to perform their tasks well  the good UI promotes efficiency!  Flexible  Seem “intelligent”  “do the right thing” without asking; remember user patterns  People have to like it!  “It is easy to make things hard. It is hard to make things easy.” -- A. Chapanis, ‘82

4. 3461 Design Guidelines  There are helpful UI design guidelines  Design guidelines are:  a set of design rules to follow  at multiple levels of design (e.g., early & late)  obvious to users of poorly designed interfaces  easy to ignore when deadlines approach  not complete  hopefully built on psychological underpinnings and an understanding of users

5. 3461 Guidelines for Building Good UIs  Follow graphic design principles  Use standard language conventions  Minimize load on short-term memory  Design for consistency  Provide clear feedback  Prevent errors & provide error correction  Use sensible conceptual models  Let’s discuss some of these…

6. 3461 From IBM’s RealCD application Graphic Design & Color Choice  A good UI will appropriately direct the user’s attention. How?  One way: use color and layout - black button on black background is bad colour choice - shouldn’t need label to tell you this is a button

7. 3461 Graphic Design & Color Choice (2)  Keep related objects together  Appropriate alignment & spacing (readability)  Decorations can provide extra information.  Use white space (vital in WWW design)  Use only a few fonts & colors (5-7 colors max)  Remember colour deficiency (5% of males are colour blind) A Toolbar from MS Word

8. 3461 Bad? Speak the User’s Language  Use common words, not “techno-jargon”  Use the vocabulary of the user  Refer to the user’s objects when giving feedback, e.g., “your document…”, “your graph…”  Allow full-length names in forms  Avoid spatial-linguistic conversions, which can be extremely confusing for users  pick one or the other; examples…

9. 3461 Spatial - Linguistic Examples  Placing objects on a canvas  by specifying (X, Y) coordinates  linguistic, use keyboard to enter X, Y  by relative positions to other items  spatial, use cursor/mouse  Selecting a quantity  specify a known value  linguistic, use keyboard to enter value  relative (more, less)  spatial, use dial

10. 3461 Problem? Less is More  The KISS Principle: “Keep it simple, stupid!”  Use concise language; avoid verbiage  Avoid extraneous pictures & information  fewer options and menu choices  reduce planning time  reduce manual size, etc.  avoid information overload!

11. 3461 Minimize User Memory Load  Short-term memory of people.  capacity of 7 +/- 2 items, with decay of 30 seconds to 2 minutes  Recognition is easier for us than recollection!  Use menus rather than keyed input  Prompts should provide formats for required data  Don’t require retyping of remembered info  Use pervasive, generic rules for common interactions, e.g., cut, copy, paste

12. 3461 Memory Examples  CAD example  poor: delete template 5  better: delete resistor template.  best: delete  Error recovery message example  poor: message telling user what to type in vanishes when typing starts  better: message maintained on display.  best: automatic error recovery

13. 3461 Be Consistent  Size, color, wording, location, ordering of objects  Same command should always have same effect in different contexts.  Following convention helps  e.g., Cut/Copy/Paste  Seems easy but it’s often not followed  Useful since it allows user to generalize from their own experience

14. 3461 Inconsistency  CMS - XEDIT Editor  in one context, D10 means “down 10 lines”  in another context it means “delete 10 lines”  Current selection (CS) in graphics editor  create a new object, it becomes CS  duplicate an object, the original remains CS  Macintosh dragging file operations?  folder on same disk vs. folder on different disk  file to trashcan vs. disk to trashcan

15. 3461 Inconsistency - Example  Moving icon to file cabinet, mailbox, or trash causes icon to disappear (Xerox Star)  What to do when dragging a file icon to the printer icon?  delete the file icon (and thus the file)  the file icon disappears “into” the printer icon, from where it can be retrieved (printer icon is also a folder?)  return icon to original location

16. 3461 Lexical Consistency  Make use of “words” consistent with common (real-world) usage  Examples:  red = bad/stop, green = good/go  left arrow = less, right arrow = more  Use consistent abbreviation/capitalization rules  CONTROL, CTRL, Ctrl, Control  which is it?  Use mnemonic names rather than codes  Use devices in the same way in all states  e.g., character delete key is always the same

17. 3461 Syntactic Consistency  Error messages at same (logical) location in all situations  Give command first -- or last (e.g., after arguments to the command)  Don’t change ordering based on context!  The user will have more to remember  Menu items at same location in menu  Muscle memory helps the user here

18. 3461 Semantic Consistency  Global commands should always be available:  Help  Cancel  Undo  Operations should always be valid on all reasonable objects  if object of class “X” can be deleted, so can object of class “Y”  if it can’t be deleted, the user will want to know why.

19. 3461 Providing Feedback  Lexical  feedback on ‘words’ that are used, (the definition of a word)  Syntactic  feedback on grammar, i.e., the order in which ‘words’ are used (subject, action and object of a sentence are determined)  Semantic  feedback on the meaning of operations (the meaning of a sentence)  It is vital to provide clear, consistent, meaningful feedback to users based on their inputs  More…

20. 3461 Lexical Feedback  Legal input in the input “language”  may be keyboard-based, mouse-based, voice-based, etc.  Using the right tokens, gestures, clicks, etc.  Feedback given using  Cursor movement (e.g., valid keypresses only generate cursor movement)  Cursor image (example… )  Keyboard echo (e.g., don’t echo illegal words)  Selection highlighting, e.g., for cut & paste or changing text style

21. 3461 Syntactic Feedback  Ensure that the sequence of “words” entered is grammatically valid  Feedback provided when the sequence is illegal  Examples…  Wrong number of arguments provided  Menu item under cursor in reverse video indicates it will execute if you release mouse button (absence of this means it will not execute)

22. 3461 Semantic Feedback  Command is understood:  it may be helpful to restate the command, e.g., by echo or by highlighting the icon in some way  Command is underway:  provide a count-down or progress bar  makes the processing appear faster (placebo)

23. 3461 Semantic Feedback (2)  Command is completed:  provide its results  prompt for next command  All three forms of semantic feedback are not always necessary  select one or more depending on the task of interest  Examples:  Progress bars not needed for short computations  Incomplete data might not be displayed

24. 3461 Feedback Placement  Put feedback where the eyes are!  Examples…  Insertion point for text  Where the screen cursor is located.  Audio output can also provide useful feedback.  sounds on error, failure, success  voice, for more detailed responses  environmental conditions may not permit audio feedback

25. 3461 Error Prevention  Preventing errors should take priority over correcting for them. Why?  Avoids “fear of failure” on the part of the user  Allows the user to work faster  Things to consider  Key placement (e.g., Apple Reset key vs Microsoft Windows key)  “distance” between commands  menu items or typed names  Suppress unavailable commands where appropriate  Confirm dangerous actions, e.g., delete files

26. 3461 Error Correction  Lexical  typing mistakes (automatic in MS Word)  Syntactic  re-specify just the parameter in error, or  restart at beginning of command (may be necessary if dependent words are used)  Semantic  cancel the operation underway  undo previous command(s)

27. 3461 Mismatch Between Designer & User Conceptual Models  Result in errors on the part of the user  Slow the user down  Result in a great deal of frustration on the part of the user  Coming up with good design models that mesh well with commonly held conceptual models is very difficult  Have to know a lot about the users requirements and typical characteristics

28. 3461 Conceptual Models DO NOT ENTER Which way would you drive?

29. 3461 Why are Design Guidelines Insufficient?  Too specific and/or too general  there may be a huge number of guidelines that are not specifically focused enough to provide useful help  A standard design might not address all the issues  Macintosh standard UI could be all dialog boxes and menus. Who is to say that this will be sufficient for the users?

30. 3461 Usability Slogans  Beware of Slogans  Always catchy, rarely useful!  Examples…  Your best guess is not good enough!  The user is always right!  The user is not always right!  Users are not designers!  Designers are not users!  Less is more!  Details matter!

31. 3461 Summary  UIs are hard to design - obviously!  Slogans do not really help  Guidelines can give us general principles to follow  Guidelines fail in that they can be hard to apply  too specific or too general  especially true for style guides

32. 3461 Thank you!