About Face: the Essentials of Interaction Design

This whole book is about Software Interaction Design.
Lots of examples of Microsoft and Apple products.
I am not absolutely agree with all the concepts inside but worth reading.
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 informationAge 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
 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-dependentChapter 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.
Appendix A: Design Principles 573
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.

The Pragmatic Programmer, from Journeyman to Master

1. The greatest of all weaknesses is the fear of appearing weak.
2. Take responsibility and no lame excuses.
3. Talk to users.
4. An investment in knowledge always pays the best interest.
5. Portfolio Management
a. Invest regularly
b. Diversify
c. Manage risk
d. Buy low, sell high
e. Review and rebalance
6. Learn at least one new language every year.
Read a technical book each quarter.
Read nontechnical books, too.
Take classes.
Participate in local user groups.
Experiment with different environments.
Stay current.
Get wired.
7. Good communication with style and patience.
8. Don’t repeat yourself.
9. Decoupling codes, and do refactoring.
10. Tracer code.
11. The limits of language are the limits of one’s world.
12. Estimate to Avoid Surprises.
13. Use source control.
14. Debug in patience.
15. Finish what you start.
16. Fully understanding of codes.
17. Dig for requirements.
18. Ruthless test.

Facts and fallacies of Software Engineering

Reality is the murder of a beautiful theory by a gang of ugly facts.


Get the right people to do the right thing at the right process phase.

Software managers disconnect with technologists.


Complexity is inevitable; don’t fight it, learn how to work with it.

Poor estimation and the resulting schedule pressure are killing people in the software field.

Don’t aim for unrealistic targets.

Don’t go for Hype, and don’t look for silver bullet for project solutions. Grope for project-focused strong, sensible solutions.