Mind in Mind Chapter 3

We seek structure

Don’t bury information

Remove repetition & noise

Use contrast

Structures is Easier to Scan

Dates and

Create a Visual Hierarchy

Hierarchy in Controls

POSTURE About Face 3, The Essentials of Interaction Design

Posture Programs have a dominant way of presenting themselves. May be bold or timid, colorful or drab, but it should be so for a specific, goal-directed reason. Two of interest: sovereign and transient

Sovereign Posture Monopolize the user’s attention for long periods of time and are best used full-screen. Offer a large set of related functions and features. Examples are word processors, spreadsheets, and many vertical applications. These programs are often the user’s primary tool. Most users are perpetual intermediates, but first-time and infrequent users cannot be ignored. Example: WordStar was great for intermediates, but difficult for infrequent users. Final lost market (mostly to Word). These applications should take as much screen real estate as needed. Windows should default to maximized. Should use a conservative visual style. Colors and texture should be muted. Toolbars and controls can be smaller, because users spend many hours getting familiar with them. Extra information can be added to the interface, such as in the status and title bars, as long as the effect is not too cluttered. Beginners won’t notice, but intermediates will make use of this info. Every frequently used aspect of the program should be controllable in several ways. Direct manipulation, dialog boxes, keyboard mnemonics and keyboard accelerators are all good. Beginners should be protected from visually dislocating functions (e.g., page layout and outline views in Word)

Transient Posture Program comes and goes, presenting a single function with a tightly restricted set of accompanying controls. Because it is temporary, user doesn’t become very familiar with controls. User interface needs to be unsubtle, presenting its controls clearly and boldly with no possibility of mistakes. Big buttons with precise legends spelled out in slightly oversized, easy-to-read typeface are recommended. Should conserve total amount of screen real estate consumed. Should be painted in brighter colors to help differentiate it from the hosting sovereign. Should have instructions built into their surface. Nothing should be abbreviated. Keep to a single window and view. Don’t force the user into subwindows or dialog boxes to take care of main function of program. Keep demands on user’s fine motor skills to a minimum. Don’t use the window bottoms, status bar or sides.

Transient Continued Provide a keyboard interface, but keep it simple. Enter, Escape and Tab should suffice (possibly include arrow keys). If program have several functions (e.g., import and export), evenly and visually split the main screen into two halves. Program must be movable, so it must have a title bar. Should remember size and placement from one invocation to the next. Also remember any logical settings. May not need to be resizable (e.g., calculator)

FLOW AND EXCISE About Face 3, The Essentials of Interaction Design

Flow: What is it? Flow (Csikszentmihalyi): when people concentrate wholeheartedly on an activity, they lose awareness of peripheral problems and distractions. Gentle sense of euphoria Can be extremely productive, especially when engaged in process-oriented tasks such as engineering, design, development and writing.

Flow: How? No matter how cool your interface is, less of it would be better. Follow mental models. People form mental images about how software should function. Example: it makes most sense to find patient information using names. For business office, support finding bills that are overdue. Direct, don’t discuss. Ideal interaction is not a dialog, it’s more like using a tool. Compare to driving a car. Keep tools close at hand. Must ensure that tool information is plentiful and easy to see (on palettes or toolbars) and attempt to make transitions between tools quick and simple. Modeless feedback. Jet fighters have a heads-up display (HUD) that superimposes the readings of critical instruction onto the forward view of the cockpit’s windshield. Constantly strive to reduce the number of elements in the interface without reducing the power. This means reducing the user actions required to achieve a task, NOT reducing available options.

More HOW Design the interface to assume the probable, but allow for the possible. E.g., assume spreadsheet will delete formula, allow to delete notes or formats. Raw numbers (such as number of free bytes and total size) are precise, but don’t help users with questions such as whether the disk is getting full as much as percentages. Make good use of charts. Graphical input is rare, but could be helpful. Setting tabs by dragging a marker on a ruler is an example. When a program is asleep, it should look asleep. When it is awake, it should look awake. When it is busy, it should look busy. For users, it can be disconcerting to know all the details of what is happening. Don’t use dialogs to report normalcy. Differentiate between command and configuration. If you ask a program to perform a function, it should simply perform that function. To modify behavior, user should request a configuration dialog. Ex: print icon vs print function on menu.

More HOW Provide choices, don't ask questions. Asking questions is not the same as providing choices. Dialog boxes ask questions, toolbars offer choices. Questions and choices don’t necessarily make the user feel empowered. More commonly, they make the user feel badgered and harassed. It’s worse when questions are asked repeatedly and unnecessarily (do you really want to save your work?) Hide the ejector seat levers. One thing that must never happen is accidental deployment of the “ejector seat.” Two basic varieties: those that cause a significant visual dislocation and those that perform some irreversible action. Avoid blank slates. People may be uncomfortable explaining to program what they want (e.g., having to answer a bunch of questions, before program begins). May be better for program to do what it thinks is right, and allow users to manipulate.

Excise Excise: a tax, or excise, of cognitive and sometimes even physical effort to use software. Excise tasks: Don’t contribute directly to reaching the goal, but are necessary for users to do. Are extra work that satisfies the needs of the tools or outside agents. May be hard to recognize, because we’re so used to excise. Examples: installation, configuring networks, making backups, connecting to online services, and virtually all window manipulation. In command-line interface, excise is requirement for user to memorize commands. Excise becomes less after user has learned interface. In GUI, extra effort and time required (excise) to get where you want to go due to manipulating windows and icons. Any power user of a command-line interface will quickly become a power user of any other type of interface. Must be careful when removing excise not to design to just to suit experts. Facilities added to software for purpose of training beginners ("training wheels") must be easily turned off.

Excise Tasks Most hardware-management tasks are excise (even for power users). Visual metaphors that make it easy to understand program elements can become excise, due to management of the metaphor (chapter 13). Transient posture applications can tolerate more training and explanation excise than sovereign applications. Overemphasis of visual design elements to the extent that they interfere with user goals and comprehension is excise Tasks are only excise if they are forced on the user, rather than being made available. Example: window management is good when it allows users to configure work area to meet their needs/preferences. Interrupting a user’s flow for no good reason is "stopping the proceedings with idiocy." Example: automatic windows update that halts program

Excise Tasks Error messages and confirmation dialogs may be excise. Example: tell program to print, should expect that it will print… not that a warning message will hold up the process. Should allow input wherever you have output. Useful idiom: tell dialog to close and not display in the future. Be careful about the use of passwords. Users should be able to cancel time-consuming tasks.

Common Excise Traps Don’t force the user to go to another window to perform a function that affects this window. Don’t force the user to remember where he put things. Don’t force the user to resize windows unnecessarily. Program should size child windows appropriately. Don’t force user to move windows. If there’s open space on the desktop, put the program there. Don’t force the user to reenter her personal settings. Don’t force the user to fill fields to satisfy some arbitrary measure of completeness. Don’t force the user to ask permission. Don’t ask the user to confirm his actions (requires robust undo) Don’t let the user’s actions result in an error.

Navigation is Excise Navigation represents pure excise. Unnecessary or difficult navigation thus becomes a major frustration. In authors’ opinion, is the number-one problem in any software application or system. Is also the place where implementation model is made most apparent. Navigation is any action that takes the user to a new part of the interface or which requires him to otherwise locate objects, tools or data.

Common Types of Navigation Between multiple windows or screens. Probably most disorienting. Take care to avoid making users shuttle back and forth between windows. Between panes within a window. Panes should match user’s workflow. Tabbed panes are appropriate for the main work area when multiple documents or independent views of a document are required. Between tools or menus in a pane. Tools that are used frequently and in conjunction with each other should be grouped together spatially and be immediately available. Adobe Photoshop exhibits annoying behavior because different tools share the same location on the tool palette.

Improving Navigation Reduce the number of places to go. This includes modes, forms, dialogs, pages, windows and screens. Provide signposts. Users navigate by reference to persistent objects placed in the user interface. Provide overviews. Overviews help to orient the users within the content. Breadcrumb displays and annotated scrollbars are examples. Organize your interface to minimize typical navigation (must really understand your users) Avoid hierarchies. Abstract hierarchies are difficult for users (but comfortable for programmers).