Chapter 9: Orchestration and Flow

There is a condition defined as "flow", "a condition of deep, nearly meditative involvement". It is important to not disrupt the user and keep them from this flow.

They use the analogy of a car or hammering a nail. When you get into a car or hit a nail you expect something to happen. You don't expect a dialogue box to emerge saying, "You must put on your safety belt in order to drive the car". This is what aggrevates users, because it keeps them from enter a "flow" state.

Modeless feedback: Opposite of "modal feedback"- When the program has information or feedback for the user, it has several ways to present it. The most common method is to pop up a dialog box on the screen = model feedback. Modeless feedback does NOT stop the flow.

Orchestration: As a poor writer is a visible writer, a poor interaction designer looms with a clumsily visible presence in his software.

LESS IS MORE

Design for the probably case; provide for the possible case.

Not everything has to be reported with a dialogue box, especially if it doesn't require an action from the user = Don't use dialogs to report normalcy.

Ask forgiveness, not permission. It is easier to fine-tune an approximation, rather than start with a blank state.

"In general, any user invokes a command ten times for every one time he configures it."

Users don't like to be asked questions. It cues the user that the program is:
-Ignorant
-Forgetful
-Weak
-Lacking initiative
-Unable to fend for itself
-Fretful
-Overly demanding

In The Media Equation, Stanford sociologists make a compelling case that humans treat and respond to computers as if they were people.