Appendix A. Design Principles

Chapter 1

  • Interaction design is not guesswork.

Chapter 2

  • User interfaces should be based on user mental models rather than implementation models.

  • Goal-directed interactions reflect user mental models.

  • Users don’t understand Boolean logic.

  • Don’t replicate Mechanical-Age artifacts in user interfaces without Information-Age enhancements.

  • Significant change must be significantly better.

Chapter 3

  • Nobody wants to remain a beginner.

  • Optimize for intermediates.

  • Imagine users as very intelligent but very busy.

Chapter 5

  • Don’t make the user feel stupid.

  • Focus the design for each interface on a single primary persona.

Chapter 6

  • Define what the product will do before you design how the product will do it.

  • In early stages of design, pretend the interface is magic.

Chapter 7

  • Never show a design approach that you’re not happy with; stakeholders just might like it.

  • There is only one user experience — form and behavior must be designed in concert with each other.

Chapter 9

  • Decisions about technical platform are best made in concert with interaction design efforts.

  • Optimize sovereign applications for full-screen use.

  • Sovereign interfaces should feature a conservative visual style.

  • Sovereign applications should exploit rich input.

  • Maximize document views within sovereign applications.

  • Transient applications must be simple, clear, and to the point.

  • Transient applications should be limited to a single window and view.

  • A transient application should launch to its previous position and configuration.

  • Kiosks should be optimized for first-time use.

Chapter 10

  • No matter how cool your interface is, less of it would be better.

  • Well-orchestrated user interfaces are transparent.

  • Follow users’ mental models.

  • Less is more.

  • Enable users to direct, don’t force them to discuss.

  • Keep tools close at hand.

  • Provide modeless feedback.

  • Design for the probable; provide for the possible.

  • Contextualize information.

  • Provide direct manipulation and graphical input.

  • Reflect object and application status.

  • Avoid unnecessary reporting.

  • Don’t use dialogs to report normalcy.

  • Avoid blank slates.

  • Ask for forgiveness, not permission.

  • Differentiate between command and configuration.

  • Provide choices; don’t ask questions.

  • Hide the ejector seat levers.

  • Optimize for responsiveness; accommodate latency.

Chapter 11

  • Eliminate excise wherever possible.

  • Don’t weld on training wheels.

  • Don’t stop the proceedings with idiocy.

  • Don’t make users ask for permission.

  • Allow input wherever you have output.

  • Inflect the interface for typical navigation.

  • Users make commensurate effort if the rewards justify it.

Chapter 12

  • The computer does the work and the person does the thinking.

  • Software should behave like a considerate human being.

  • If it’s worth the user entering, it’s worth the application remembering.

Chapter 13

  • Most people would rather be successful than knowledgeable.

  • All idioms must be learned; good idioms need to be learned only once.

  • Never bend your interface to fit a metaphor.

Chapter 14

  • A visual interface is based on visual patterns.

  • Visually distinguish elements that behave differently.

  • Visually communicate function and behavior.

  • Take things away until the design breaks, then put that last thing back in.

  • Visually show what; textually tell which.

  • Obey standards unless there is a truly superior alternative.

  • Consistency doesn’t imply rigidity.

Chapter 17

  • Managing disks and files is not a user goal.

  • Save documents and settings automatically.

  • Put files where users can find them.

  • Disks are a hack, not a design feature.

Chapter 18

  • An error may not be your fault, but it’s your responsibility.

  • Audit, don’t edit.

Chapter 19

  • Rich visual feedback is the key to successful direct manipulation.

  • Support both mouse and keyboard use for navigation and selection tasks.

  • Use cursor hinting to show the meanings of meta-keys.

  • Single-click selects data or an object or changes the control state.

  • Mouse-down over an object or data should select the object or data.

  • Mouse-down over controls means propose action; mouse-up means commit to action.

  • Visually communicate pliancy.

  • Use cursor hinting to indicate pliancy.

  • The selection state should be visually evident and unambiguous.

  • Drop candidates must visually indicate their receptivity.

  • The drag cursor must visually identify the source object.

  • Any scrollable drag-and-drop target must auto-scroll.

  • Debounce all drags.

  • Any program that demands precise alignment must offer a vernier.

Chapter 20

  • A dialog box is another room; have a good reason to go there.

  • Provide functions in the window where they are used.

  • The utility of any interaction idiom is context-dependent.

Chapter 21

  • A multitude of control-laden dialog boxes doth not a good user interface make.

  • Use links for navigation, and buttons or butcons for action.

  • Distinguish important text items in lists with graphic icons.

  • Never scroll text horizontally.

  • Use bounded controls for bounded input.

  • Use noneditable (display) controls for output-only text.

Chapter 22

  • Use menus to provide a pedagogic vector.

  • Disable menu items when they are not applicable.

  • Use consistent visual symbols on parallel command vectors.

Chapter 23

  • Toolbars provide experienced users fast access to frequently used functions.

  • Use ToolTips with all toolbar and iconic controls.

Chapter 24

  • Put primary interactions in the primary window.

  • Dialogs are appropriate for functions that are out of the main interaction flow.

  • Dialogs are appropriate for organizing controls and information about a single domain object or application function.

  • Use verbs in function dialog title bars.

  • Use object names in property dialog title bars.

  • Visually differentiate modeless dialogs from modal dialogs.

  • Use consistent terminating commands for modeless dialog boxes.

  • Don’t dynamically change the labels of terminating buttons.

  • Inform the user when the application is unresponsive.

  • Never use transitory dialogs as error messages or confirmations.

  • All interaction idioms have practical limits.

  • Don’t stack tabs.

Chapter 25

  • Error message boxes stop the proceedings with idiocy and should be avoided.

  • Make errors impossible.

  • Users get humiliated when software tells them they failed.

  • Do, don’t ask.

  • Make all actions reversible.

  • Provide modeless feedback to help users avoid mistakes.

Chapter 26

  • Offer shortcuts from the Help menu.

  • Offer users a gallery of ready-to-use templates.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.191.94.249