CS408 — Final Term Summary (Lectures 23–45)

📘 Lecture 23 — Requirements

📖 Overview: This lecture focuses on bridging the research-design gap in Human Computer Interaction by using narrative and persona-based techniques to define user requirements. It explains how personas serve as the main characters in scenarios that help translate qualitative user research into coherent design solutions, addressing both user needs and business constraints.

🗂️ Topics Covered

The lecture covers narrative as a design tool, including scenarios in design and their relationship with personas. It compares persona-based scenarios versus use cases, then details the envisioning of solutions through persona-based design. The Requirement Definition phase is explained through five steps: creating problem and vision statements, brainstorming, identifying persona expectations, constructing context scenarios, and identifying needs including data, functional, contextual, and other requirements.

📝 Lecture Summary

23.1 Narrative as a design tool

Narrative, or storytelling, is one of the oldest human activities and serves as a powerful tool for generating and validating design ideas. Because interaction design is the design of behavior over time, a narrative structure combined with minimal visualization tools like whiteboards is perfectly suited for envisioning and representing interaction concepts. Initial work of defining requirements and frameworks is best done fluidly and flexibly, without reliance on technologies that impede ideation.

🔑 Definition — Scenario: A method of design problem solving by concretization, making use of a specific story to both construct and illustrate design solutions. Scenarios are "paradoxically concrete but rough, tangible but flexible" and "implicitly encourage 'what-if' thinking among all parties" (Carroll).

Scenarios in design

Carroll's scenario-based design focuses on describing how users accomplish tasks, consisting of an environment setting and abstracted agents/actors with role-based names like "Accountant" or "Programmer." However, two problems exist with this approach:

• Scenarios are not concrete enough in representing the human actor — abstracted role-oriented models don't provide sufficient understanding or empathy with users
• Scenarios jump too quickly to task elaboration without considering user goals and motivations that drive these tasks

The missing ingredient is the use of personas. A persona provides a sufficiently tangible representation of the user to act as a believable agent in a scenario, enhancing the designer's ability to empathize with user mental models. Because personas model goals (not simply tasks), the scope of scenarios broadens to include product definition, helping answer "what should this product be?" and "how should it look and behave?"

Using personas in scenarios

Persona-based scenarios are concise narrative descriptions of one or more personas using a product to achieve specific goals. They capture the non-verbal dialogue between artifact and user over time. Goals serve as filters for tasks and guides for structuring information display and controls. Designers role-play personas similar to actors performing improvisation at a whiteboard, leading to real-time synthesis of structure and behavior. Three types of persona-based scenarios are employed at different points, each with successively narrower focus.

Persona-based scenarios versus use cases

Goal-directed scenarios are an iterative means of defining product behavior from the standpoint of specific users, including functionality, priority of functions, and how functions are expressed visually and interactively.

Use cases are an exhaustive description of functional requirements, often transactional, focusing on low-level user action and system response. They permit complete cataloguing of user tasks but say little about how tasks are presented or prioritized. Use cases may be useful for identifying edge cases and determining functional completeness but should be deployed only in later stages of design validation.

💡 Why this matters: The distinction is critical — personas add the human element that pure use cases miss, ensuring designs meet actual user goals rather than just system requirements.

23.2 Envisioning solutions with persona-based design

Translation from robust models to design solutions consists of two major phases:

• Requirements Definition: Answers what a product is and what it should do
• Framework Definition: Answers how a product behaves and is structured to meet user goals

Defining the requirements

The Requirement Definition phase determines the "what" of design — what functions personas need and what information they must access to accomplish goals. Five steps comprise this process:

1. Creating problem and vision statement
2. Brainstorming
3. Identifying persona expectations
4. Constructing the context scenario
5. Identifying needs

Steps proceed roughly chronologically but represent an iterative process; designers cycle through steps 3-5 several times until requirements are stable.

Step 1: Creating problem and vision statement

Before ideation, designers need a clear mandate. Problem and vision statements build consensus among stakeholders.

A problem statement defines the design objective, concisely reflecting a situation needing change for both personas and business. A cause-and-effect relationship exists between business concerns and persona concerns.

Example problem statement:

"Company X's customer satisfaction ratings are low and market share has diminished by 10% over the past year because users don't have adequate tools to perform X, Y and Z tasks that would help them meet their goal of G."

A vision statement is an inversion of the problem statement — a high-level design vision or mandate. It leads with user needs and transitions to how business goals are met:

"The new design of Product X will help users achieve G by giving them the ability to perform X, Y and Z with greater [accuracy, efficiency...], and without problems A, B, C that they currently experience. This will dramatically improve Company X's customer satisfaction ratings and lead to increased market share."

Content should come directly from research and user models, with user goals from primary/secondary personas and business goals from stakeholder interviews.

Step 2: Brainstorming

Brainstorming at this early stage serves an ironic purpose — getting design ideas out of designers' heads so they can "let them go." This eliminates designer bias before launching into scenarios, preparing designers to take on the roles of primary personas.

Brainstorming should be unconstrained and non-critical — put all ideas (including wacky ones) on the table, record them, and file them away for safekeeping until much later.

Step 3: Identifying persona expectations

The expectations a persona has for a product and its context of use collectively form that persona's mental model. The representation model of the interface should match the user's mental model as closely as possible, rather than reflecting the implementation model.

For each primary persona, identify:

• General expectations and desires about using the product
• Behaviors each will expect or desire from the product
• Attitude, past experience, aspirations, and other social/cultural/environmental/cognitive factors

Analyze research data for language patterns — what subjects mention first, which action words (verbs) they use, and which intermediate steps/tasks/objects aren't mentioned. Then repeat for secondary and customer personas, crosschecking similarities and differences.

Step 4: Constructing context scenarios

Context scenarios are the most story-like type of scenario, focusing on the persona's mental models, goals, and activities. They describe the broad context of usage patterns including environmental and organizational considerations, establishing primary touch-points for each persona over a meaningful time period. These are sometimes called day-in-the-life scenarios.

Context scenarios address questions like:

• What is the setting for product use?
• Will it be used for extended amounts of time?
• Is the persona frequently interrupted?
• Are there multiple users on a single workstation?
• What other products is it used with?
• How much complexity is permissible based on persona skill and frequency of use?
• What primary activities accomplish goals?
• What is the expected end result?

Keep scenarios broad and relatively shallow — resist diving into interaction detail. Map out the big picture first to prevent getting lost in design details that may not fit together coherently.

📌 Example context scenario — Salman, a real-estate agent in Lahore:

• Goal: Balance work and home life, cinch the deal, make each client feel like his only client
• Steps: (1) Checks e-mail on phone while making daughter's sandwich; (2) Sees client e-mail, calls with simple action; (3) Switches to speakerphone, creates appointment automatically linked to client; (4) Keys property address; (5) Phone updates Outlook so office knows schedule; (6) Phone alerts 15 minutes before appointment, shows all related documents; (7) Taps address for directions and map; (8) Phone recognizes daughter's special ring code; (9) Takes call — daughter missed bus, arranges pickup

Step 5: Identifying needs

After an initial draft of context scenarios, analyze them to extract the persona's needs. Needs consist of objects and actions in contexts. The term "needs" implies certain objects must exist and actions must happen in contexts — not identical to "tasks" (which implies manual user performance).

🔑 Definition — Data needs: Objects and information that must be represented in the system — charts, graphs, status markers, document types, attributes for sorting/filtering/manipulation, graphical object types for direct manipulation.

🔑 Definition — Functional needs: Operations performed on system objects, translated into interface controls. Also define places/containers where objects or information must be displayed.

🔑 Definition — Contextual needs: Relationships between sets of objects or controls, including which object types to display together for workflow or meeting persona goals, how objects interact, and skills/capabilities of personas.

Other requirements include:

• Business requirements: Development timelines, regulations, pricing structures, business models
• Technical requirements: Weight, size, form-factor, display, power constraints, software platform choices
• Customer and partner requirements: Ease of installation, maintenance, configuration, support costs, licensing agreements

The design team should now have a mandate (problem and vision statements), a creative overview (context scenarios), and a reductive list of needs and requirements.

⭐ Key Takeaways

Persona-based scenarios are superior to traditional use cases because they incorporate concrete human actors with goals rather than abstract role-based agents, enabling genuine empathy and understanding of user motivations. The Requirement Definition phase follows five iterative steps that move from high-level problem statements through brainstorming, persona expectation analysis, context scenario construction, and need extraction. Context scenarios should remain broad and focus on user goals rather than specific interface details, treating the system initially as a "magic black box." Needs are categorized into data needs (objects/information), functional needs (operations/controls), and contextual needs (relationships), plus business/technical/customer requirements. The entire process is held together by narrative — using personas to tell stories that point toward design solutions.

🧠 Quick Revision Questions

1. What are the two main problems with Carroll's scenario-based design approach that personas solve?
2. How does a vision statement differ from a problem statement, and what purpose does each serve?
3. What five questions should context scenarios address about the product's use environment?
4. What is the difference between "tasks" and "needs" in the context of identifying requirements from scenarios?
5. Why is brainstorming performed at the Requirements Definition stage, and what is its "ironic purpose"?

📘 Lecture 24 — Framework and Refinements

📖 Overview: This lecture details the process of building an interaction framework, which defines the skeleton, flow, and behavior of a digital product. It then explores the crucial role of prototyping—both low-fidelity and high-fidelity—in testing, refining, and communicating design ideas. Understanding these concepts is essential for moving from requirements to a concrete, testable design.

🗂️ Topics Covered

The lecture begins by outlining a six-step process for defining the interaction framework: form factor and input methods, defining views, defining functional and data elements, determining functional groups and hierarchy, sketching the framework, and constructing key path scenarios. It then discusses the use of scenarios and storyboarding, the principle of "pretending the system is human," and the application of design principles and patterns. The second half of the lecture covers the nature and purpose of prototypes, followed by a detailed comparison of low-fidelity and high-fidelity prototyping techniques, including storyboarding and sketching.

📝 Lecture Summary

24.1 Defining the interaction framework

The interaction framework is the core design output from the Requirements Definition phase. It defines not only the structure (the skeleton) of the interaction but also the flow and behavior of the product. The process involves six iterative steps that guide the designer from abstract concepts to concrete structural components.

Step 1: Defining form factor and input methods The first step is to define the form factor of the product—its basic posture (e.g., a web application, a phone, a kiosk) and the constraints it implies. You must then determine the valid input methods (e.g., keyboard, mouse, touch screen, voice) that are appropriate for your primary and secondary personas. This sets the stage for all subsequent design efforts.

Step 2: Defining views After defining the form factor, you must consider the primary screens or states the product can be in. These views are often hinted at by initial context scenarios. If a user's end goals are not closely related, separate views may be defined; if needs are related (e.g., seeing a calendar to make an appointment), they can be combined into a single view.

Step 3: Defining functional and data elements Functional and data elements are the visible representations of functions and data in the interface, described in the language of user interface representations (e.g., panes, containers, icons, buttons). In early framework iterations, specifying containers is most important. A single persona need may spawn multiple interface elements (e.g., for making a call: voice activation, quick-dial buttons, a list of contacts). This list is winnowed using persona goals, design principles, and constraints.

Step 4: Determining functional groups and hierarchy After establishing a list of top-level elements, you group them into functional units and determine their hierarchy to best facilitate tasks. Key considerations include which elements need more space, which are containers for others, how containers should be arranged for optimal flow, and which elements are used together. The most important step is determining top-level containers and arranging them according to the form factor and mental models of the personas.

Step 5: Sketching the interaction framework This step involves sketching different ways of fitting top-level containers together in the interface. This is an iterative process best performed in a small collaborative group. The visualization starts extremely simple, using boxes to represent functional groups and containers. It is critical to focus on the top-level framework first and avoid getting distracted by details at the widget level.

Step 6: Constructing key path scenarios Key path scenarios describe, at the task level, the primary actions and pathways that a persona takes with the greatest frequency (e.g., viewing and composing mail in an email app, not configuring a server). These scenarios are more task-oriented than goal-oriented context scenarios. They require the greatest interaction support for new users, but frequent use will lead users to demand shortcuts and customizations.

24.2 Prototyping

The main idea is that users often can't articulate what they want, but they know what they don't want when they see it. Therefore, we need to build prototypes and iterate through several versions. The more iterations, the better the final product will be.

What is a prototype? A prototype is a limited representation of a design that allows stakeholders to interact with it and explore its suitability. It can range from a paper-based storyboard to a complex piece of software. Examples include a carved piece of wood simulating the shape of a PalmPilot or a cardboard box labeled "Desktop Laser Printer." The key point is that users can envision using the real product.

Why prototype? Prototypes are a useful communication device among team members and with stakeholders. They support reflection in design and help answer questions or choose between alternatives. The purpose of a prototype (e.g., testing technical feasibility, clarifying requirements, user testing) will influence its type.

Low-fidelity prototyping A low-fidelity prototype does not look much like the final product (e.g., paper and cardboard mockups). It is simple, cheap, and quick to produce and modify, making it ideal for exploring alternative designs and ideas in early development stages. It is never intended for the final product.

• Storyboarding: A series of sketches showing how a user might progress through a task, bringing more detail to a written scenario.
• Sketching: Low-fidelity prototyping often relies on sketching. Designers are encouraged to devise their own simple symbols (e.g., boxes, stick figures) for elements like people, computers, and actions.

High-fidelity prototyping A high-fidelity prototype uses materials expected in the final product (e.g., a software prototype built in Visual Basic). It looks much more like the final product. However, it has inherent problems: it takes too long to build, reviewers focus on superficial aspects, developers are reluctant to change them, and one bug can halt testing.

📐 Table: Advantages and Disadvantages of Prototyping Types

⭐ Key Takeaways

The process of defining an interaction framework is a structured, six-step, and iterative effort that moves from defining the product's form and views to sketching its structure and validating it with detailed key path scenarios. Key path scenarios, which focus on frequent user tasks, are a critical tool for refining interactions and must be supported by built-in pedagogy and shortcuts. Prototyping is an essential design activity that allows for testing and iteration; low-fidelity prototypes (like storyboards and sketches) are ideal for early exploration due to their speed and low cost, while high-fidelity prototypes are better for detailed usability testing but carry risks of high cost and development reluctance. The core principle of "pretending the system is human" should guide the design of interactions to be polite, considerate, and helpful, just as a thoughtful human would be.

🧠 Quick Revision Questions

1. What are the six steps involved in defining an interaction framework?
2. What is the primary difference in focus between context scenarios and key path scenarios?
3. Give two specific examples of low-fidelity prototyping techniques mentioned in this lecture.
4. According to Marc Rettig, what are two key disadvantages of using high-fidelity prototypes?
5. What is the core principle behind "pretending the system is human" when constructing key path scenarios?

📘 Lecture 25 — Design Synthesis

📖 Overview: This lecture explores what makes a design superior by examining interaction design principles, patterns, and imperatives. It moves beyond process to define the specific attributes and features that enable designs to meet user goals while balancing business and technical constraints. Understanding these concepts is critical for creating usable, useful, and elegant products.

🗂️ Topics Covered

The lecture covers three main areas: Interaction Design Principles, which are generally applicable guidelines for behavior, form, and content; Interaction Design Patterns, which are exemplary solutions to recurring design problems; and Interaction Design Imperatives, which are fundamental principles guiding the entire design process. Several sets of design principles from different experts (Norman, Nielsen, Simpson, Shneiderman, Dumas) are reviewed and compared.

📝 Lecture Summary

25.1 Interaction Design Principles

Interaction design principles are generally applicable guidelines addressing issues of behavior, form, and content. They represent characteristics of product behavior that help users better accomplish their goals and feel competent and confident. Principles are applied throughout the design process, translating tasks from scenario iterations into formalized structures and behaviors.

Principles minimize work

The primary purpose of principles is to optimize user experience by minimizing work. For productivity tools, this means reducing several kinds of work:

• Logical work — comprehension of text and organizational structures
• Perceptual work — decoding visual layouts and semantics of shape, size, color, and representation
• Mnemonic work — recall of passwords, command vectors, names and locations of data objects and controls
• Physical/motor work — number of keystrokes, degree of mouse movement, use of gestures, switching between input modes, extent of navigation

Most principles attempt to minimize work while providing greater feedback and contextually useful information.

💡 Why this matters: Understanding the different types of user work helps designers systematically reduce cognitive and physical burden.

Principles operate at different levels of detail

Design principles operate at three levels:

• Conceptual-level principles — help define what a product is and how it fits into the broad context of use required by its primary personas
• Interaction-level principles — help define how a product should behave, in general and in specific situations
• Interface-level principles — help define the look and feel of interfaces

Most interaction design principles are cross-platform, though some platforms like the Web and embedded systems have special considerations.

Principles versus style guides

Style guides rigidly define the look and feel of an interface according to corporate branding and usability guidelines, typically focusing on detailed widget-level decisions. They answer questions like: How many tabs in a dialog? What should button highlight states look like? While important for fine-tuning, style guides don't address bigger issues of what a product should be or how it should behave. Experts recommend using style guides when available but recognize that larger behavioral issues rarely appear in them.

Design Principles (Norman)

These previously studied principles include:

• Visibility
• Affordance
• Constraints
• Mapping
• Consistency
• Feedback

Nielsen's design principles:

Visibility of system status: Always keep users informed about what is going on through appropriate feedback within reasonable time. For example, if an operation will take time, indicate how long and how much is complete.

Match between system and real world: The system should speak the user's language with familiar words, phrases, and concepts, following real-world conventions in natural and logical order.

User freedom and control: Users often choose functions by mistake and need a clearly marked 'emergency exit' to leave unwanted states without extended dialogs. Support undo and redo.

Consistency and standards: Users should not wonder whether words, situations, or actions mean the same thing in different contexts. Follow platform conventions.

Error prevention: Make it difficult to make errors. Better than good error messages is a careful design that prevents problems from occurring.

Recognition rather than recall: Make objects, actions, and options visible. Users should not have to remember information from one part of the dialog to another.

Flexibility and efficiency of use: Allow users to tailor frequent actions. Accelerators hidden from novice users can speed up interaction for expert users, catering to both inexperienced and experienced users.

Aesthetic and minimalist design: Dialogs should not contain irrelevant or rarely needed information. Every extra unit competes with relevant units and diminishes their relative visibility.

Help users recognize, diagnose, and recover from errors: Error messages should be in plain language (no codes), precisely indicate the problem, and constructively suggest a solution.

Help and documentation: Provide easy-to-search help focused on user tasks with concrete steps, not too large.

Design Principles (Simpson, 1985)

• Define the users
• Anticipate the environment
• Give operators control
• Minimize operators' work
• Keep the program simple
• Be consistent
• Give adequate feedback
• Do not overstress working memory
• Minimize dependence on recall memory
• Help operators remain oriented
• Code information properly (or not at all)
• Follow prevailing design conventions

Design Principles (Shneiderman, 1992)

1. Strive for consistency in action sequences, layout, terminology, command use
2. Enable frequent users to use shortcuts (abbreviations, special key sequences, macros)
3. Offer informative feedback for every user action
4. Design dialogs to yield closure so users know when tasks are complete
5. Offer error prevention and simple error handling
6. Permit easy reversal of actions to relieve anxiety and encourage exploration
7. Support internal locus of control — user controls the system
8. Reduce short-term memory load by keeping displays simple and consolidating displays

These rules provide useful shorthand for more detailed principles and are broadly applicable to most design projects.

Design Principles (Dumas, 1988)

• Put the user in control
• Address the user's level of skill and knowledge
• Be consistent in wording, formats, procedures
• Protect the user from inner workings of hardware and software
• Provide online documentation for operation and error recovery
• Minimize burden on user's memory
• Follow principles of good graphics design in screen layout

25.2 Interaction Design Patterns

Design patterns serve two important functions. First, they capture useful design decisions and generalize them for similar future problems, reducing design time and effort, educating designers, and formalizing design knowledge. Second, and more importantly, patterns can represent optimal or near-optimal interactions for users and the class of activity addressed.

Interaction and architectural patterns

Interaction design patterns are more akin to architectural design patterns from Christopher Alexander than to engineering patterns. Alexander sought to capture "the quality without a name"—the essence creating well-being in inhabitants. This human element differentiates interaction design patterns from engineering patterns concerned solely with code reuse.

A key difference: interaction design patterns concern not only structure and organization but also dynamic behaviors and changes in response to user activity. These responses to human activity differentiate them from preordained temporal transitions. Jan Borchers describes interaction design patterns as referring to relationships between physical elements and events, striving to create environments establishing positive behavioral patterns.

Types of interaction design patterns

Patterns can be hierarchically organized at different levels:

• Postural patterns — applied at the conceptual level, determining overall product stance in relation to the user
• Structural patterns — solve problems of information display, access, and how containers of data and functions are visually manipulated. They consist of views, panes, and element groupings
• Behavioral patterns — solve problems relating to specific interactions with individual functional or data objects

The most commonly used high-level structural pattern is the navigational pane on the left, overview pane on the upper right, and detail pane on the lower right (as in Microsoft Outlook). This pattern is optimal for full-screen applications requiring access to many objects, group manipulation, and detailed content display—all in a single screen.

Structural patterns, pattern nesting, and pre-fab design

Structural patterns often contain other structural patterns. While a comprehensive catalogue could permit rapid assembly of Goal-Directed designs, patterns cannot be mechanically assembled in cookie-cutter fashion. As Alexander notes, architectural patterns are the antithesis of pre-fab building because context is absolutely important. The environment, containing patterns, and adjacent patterns all matter. For interaction design patterns, the core lies in relationships between represented objects and between those objects and user goals. The precise form varies per instance, but relationships between objects remain essentially the same.

25.3 Interaction Design Imperatives

Beyond principles, experts identify fundamental guiding principles for the design process as a whole. Developed by Robert Reimann, Hugh Dubberly, Kim Goodwin, David Fore, and Jonathan Korman, these apply to interaction design and almost any design discipline. Design solutions should be:

• Ethical [considerate, helpful] — Do no harm; Improve human situations
• Purposeful [useful, usable] — Help users achieve goals and aspirations; Accommodate user contexts and capacities
• Pragmatic [viable, feasible] — Help commissioning organizations achieve goals; Accommodate business and technical requirements
• Elegant [efficient, artful, affective] — Represent simplest complete solution; Possess internal (self-revealing, understandable) coherence; Appropriately accommodate and stimulate cognition and emotion

Additional guidelines for documentation and help include:

• Ask relevant questions when planning manuals
• Learn about audiences
• Understand how people use manuals
• Organize for quick information finding
• Put users in control by showing structure
• Use typography to give structure clues
• Write so users can picture themselves in text
• Don't overtax working memory
• Use users' words
• Be consistent
• Test for usability
• Expect to revise
• Understand product users and why
• Adapt dialog to the user
• Make information accessible
• Apply consistent organizational strategy
• Make messages helpful
• Prompt for inputs
• Report status clearly
• Explain errors fully
• Fit help smoothly into users' workflow

⭐ Key Takeaways

Interaction design principles minimize four types of user work (logical, perceptual, mnemonic, and physical) and operate at conceptual, interaction, and interface levels. Multiple experts provide complementary sets of principles, with Nielsen's ten heuristics being particularly comprehensive and widely applicable. Design patterns capture optimal solutions for recurring problems and, unlike engineering patterns, focus on human experience and dynamic user-responsive behaviors. The four design imperatives (ethical, purposeful, pragmatic, elegant) provide overarching guidance for creating designs that are both human-centered and business-viable. Students must understand that while principles and patterns provide guidance, they cannot be mechanically applied—context and user goals always drive the specific implementation.

🧠 Quick Revision Questions

1. What are the four types of user work that interaction design principles aim to minimize?
2. How do interaction design patterns differ from engineering design patterns in their focus?
3. Name the three levels at which design principles operate and explain what each level addresses.
4. What is the key difference between a style guide and a design principle?
5. List the four top-level design imperatives and briefly describe what each means for a design solution.

📘 Lecture 26 — Behavior & Form Part I

📖 Overview: This lecture introduces the study of behavior and form in Human Computer Interaction, focusing on how software applications present themselves to users through different "postures." It explains how a program's behavioral stance affects usability and provides guidelines for designing interfaces that match the intended use of the application.

🗂️ Topics Covered

The lecture explores the concept of software posture as the behavioral stance of a program, examining four distinct categories for desktop applications: sovereign posture (full-screen, long-duration use), transient posture (temporary, single-function tools), daemonic posture (invisible background processes), and auxiliary posture (continuous but supporting roles). Each category is analyzed with specific design implications including screen usage, visual feedback, input methods, and state management.

📝 Lecture Summary

26.1 Software Posture

A program's posture is the way it presents itself to the user — its behavioral stance. Just as people have predominant behavioral stances at work, programs have a manner of presenting themselves. This should not result from personal preference of the designer but from the program's purpose and how it is used. The posture affects the user's relationship with the program and strongly influences usability. Programs whose appearance and behavior conflict with their purposes will seem jarring and inappropriate.

The look and feel of a program from the perspective of posture is not an aesthetic choice — it is a behavioral choice. The posture serves as the behavioral foundation, and aesthetic choices should be in harmony with this posture. As an interaction designer, one of the first design concerns should be ensuring that the interface presents the posture most appropriate for its behavior and that of the users.

🔑 Definition — Posture: The behavioral stance of a program — how it presents itself to the user, reflecting how it is used rather than an arbitrary standard.

26.2 Postures for the Desktop

Desktop applications fit into four categories of posture: sovereign, transient, daemonic, and auxiliary. Each describes a different set of behavioral attributes and a different type of user interaction. These categories give the designer a point of departure for designing an interface.

Sovereign posture

Sovereign posture applications are best used full-screen, monopolizing the user's attention for long periods of time. They offer a large set of related functions and features, and users tend to keep them running continuously. Good examples include word processors, spreadsheets, and email applications. Many vertical applications are also sovereign because they deploy on the screen for long periods.

Users of sovereign programs often find themselves in a state of flow. Sovereign programs are characteristically used for long, continuous stretches of time and dominate a user's workflow as the primary tool. For example, PowerPoint is open full screen while creating a presentation from start to finish.

💡 Why this matters: The most important implication of sovereign behavior is that users of sovereign programs are intermediate users. Each user spends time as a novice, but only a short period relative to the total time using the product. The program should be designed for optimal use by perpetual intermediates, not primarily for beginners or experts.

Take the pixels: Because the user's interaction dominates the session, sovereign programs shouldn't be afraid to take as much screen real estate as possible. In most instances, sovereign programs run maximized and should default to full-screen presentation. The interface must be optimized for full-screen rather than less likely cases.

Rich visual feedback: Sovereign applications are great platforms for creating an environment rich in visual feedback. Status bars, scroll bar areas, title bars, and other spaces can be filled with visual indications of program status, data status, and hints. However, care must be taken to avoid clutter. First-time users won't notice these artifacts, but after months of steady use, they will begin to explore them, becoming more powerful and satisfied users.

Rich input: Every frequently used aspect should be controllable in several ways — direct manipulation, dialog boxes, keyboard mnemonics, and keyboard accelerators. More aggressive demands can be made on fine motor skills. Corners and edges of the program's window can be used for controls. For example, Microsoft Word puts most frequently used functions on the two main toolbars, while visually dislocating functions (like view changes) are placed in less prominent positions near the bottom of the screen.

Users will not appreciate interactions that cause delay. A one- or two-second delay becomes painful after a few repetitions. Functions that take time should not be frequent or repeated procedures during normal use.

Document-centric applications: Many sovereign programs are document-centric (their primary functions involve creating and viewing documents containing rich data), but sovereign posture comes from the nature of the program's use, not from document-centricity or document size.

🔑 Definition — Sovereign posture: Programs best used full-screen that monopolize the user's attention for long periods, offering a large set of related functions, designed for perpetual intermediate users.

📌 Example: WordStar, an early word processing program, dominated the marketplace in the late 70s and early 80s because it served its intermediate users exceedingly well, even though it was extremely difficult for infrequent and first-time users. It failed when competition offered the same power while making it less painful for infrequent users.

Transient posture

Transient posture programs come and go, presenting a single, high-relief function with a tightly restricted set of accompanying controls. The program is called when needed, appears, performs its job, and quickly leaves. The salient characteristic is their temporary nature.

Because users don't stay on these programs for extended periods, they don't become very familiar with them. Consequently, the interface needs to be unsubtle — presenting controls clearly and boldly with no possibility of mistakes. This is not the place for artistic-but-ambiguous images or icons, but for big buttons with precise legends in easy-to-read typeface.

Although a transient program can operate alone, it usually acts in a supporting role to a sovereign application. For example, calling up Explorer to locate and open a file while editing in Word is a typical transient scenario. Because the transient program borrows space at the expense of the sovereign, it must respect the sovereign by not taking more space than absolutely necessary.

Bright and clear: Controls on a transient program's surface can be proportionally larger than those on a sovereign application. While heavy-handed visual design on a sovereign would pall within weeks, the transient program isn't on screen long enough for it to bother the user. Bolder graphics help the user orient more quickly when the program pops up. Transient programs should use brighter colors and bold graphics to clearly convey their purpose.

Transient programs should have instructions built into their surface. The user may only see the program once a month and will likely forget the meanings of choices presented. Instead of "Setup," use "Setup User Preferences." Nothing should be abbreviated — everything should be spelled out to avoid confusion.

Keep it simple: All information and facilities should be on the surface of the program's single window. Never force the user into supporting subwindows or dialog boxes for the main function. If you find yourself adding a dialog box or second view, that's a key sign that the design needs review.

Transient programs are not the place for tiny scroll bars and fussy point-click-and-drag interfaces. Simple push-buttons for simple functions are better. Anything directly manipulable must be at least twenty pixels square. Keep controls off borders and position them in the main part of the window. Keyboard interface should be simple — Enter, Escape, and Tab, possibly arrow keys.

If a transient program performs more than a single function, the interface should communicate this visually. For example, if importing and exporting graphics, the interface should be evenly and visually split into two halves.

🔑 Definition — Transient posture: Temporary programs that present a single, high-relief function with a restricted set of controls, appearing when needed and quickly leaving (e.g., dialog boxes, file open dialogs).

📌 Example: The calculator accessory in Windows and on the Mac is not resizable — it is always the correct size and shape.

Daemonic posture

Daemonic posture programs serve quietly and invisibly in the background, performing possibly vital tasks without human intervention. A printer driver is an excellent example. Any discussion of the user interface of daemonic programs is necessarily short.

Where a transient program controls the execution of a function, daemonic programs manage processes. Like the processes that regulate heartbeat, daemonic programs generally remain completely invisible, competently performing their process as long as the computer is turned on. However, they must occasionally be installed, removed, or adjusted. At these times, the interaction is transient in nature, and all imperatives of transient program design apply.

The principles of transient design concerning keeping the user informed of the program's purpose become even more critical with daemonic programs. Because users may not consciously be aware of the existence of the daemonic program, status reports can be dislocating if not presented in appropriate context.

One significant question: If the program is normally invisible, how should the interface be summoned? One method is to represent the daemon with an on-screen program icon in the status area (system tray) in Windows or Mac OS menu bar. However, putting the icon boldly in the user's face when almost never needed is an affront. Daemonic icons should only be employed permanently if they provide continuous, useful status information.

An effective approach for configuring daemonic programs is control panels — transient programs that run as launchable applications to configure daemons.

🔑 Definition — Daemonic posture: Programs that do not normally interact with the user, serving quietly in the background performing vital tasks without human intervention (e.g., printer drivers, communications concentrators).

📌 Example: Windows XP hides daemonic icons not actively being used, and Microsoft set the standard that only status icons appear in the status area.

Auxiliary posture

Auxiliary posture programs blend characteristics of sovereign and transient programs. The auxiliary program is continuously present like a sovereign, but performs only a supporting role. It is small and usually superimposed on another application like a transient program.

Examples include the Windows taskbar, clock programs, performance monitors on many Unix platforms, Stickies on Mac, and instant messaging applications used continuously. In Windows XP's Internet Explorer, Microsoft recognized the auxiliary role of streaming audio by integrating the audio player into a side pane.

Auxiliary programs are typically silent reporters of ongoing processes, although some display other data the user is interested in. A process-reporting auxiliary program must be simple and often bold in reporting its information. It must be very respectful of the pre-eminence of sovereign programs and should be quick to move out of the way when necessary.

Auxiliary programs are not the locus of the user's attention — that belongs to the host (sovereign) application. Controls on auxiliary applications can be designed to a sovereign's sensibilities because they are on screen for long periods, but they must be very conservative in pixel usage since they always obscure some of the underlying sovereign application.

🔑 Definition — Auxiliary posture: Programs that are continuously present like sovereign but perform only a supporting role, small and superimposed on another application (e.g., taskbar, clock programs, performance monitors).

📌 Example: In an automatic call distribution (ACD) program, the sales agent's order entry program is the sovereign, while the ACD program is the auxiliary application riding on top to feed incoming calls to the agent.

⭐ Key Takeaways

The posture of a program — its behavioral stance — is a fundamental design choice that must align with how the program is actually used, not designer preference. Sovereign posture programs (like word processors) require full-screen optimization, rich visual feedback, and design for perpetual intermediate users, with muted colors and compact controls for long-term comfort. Transient posture programs (like dialog boxes) need bold, clear controls with explicit instructions because users interact with them infrequently and briefly. Daemonic posture programs operate invisibly in the background and should only reveal themselves through icons when providing continuous useful status information. Auxiliary posture programs blend characteristics of both sovereign and transient, being continuously present but in a supporting role that must respect the pre-eminence of the host sovereign application.

🧠 Quick Revision Questions

1. What are the four categories of posture for desktop applications, and what distinguishes each one?
2. Why should sovereign programs be designed for perpetual intermediate users rather than beginners or experts?
3. What specific visual design guidelines apply to transient programs, and why are they different from sovereign program guidelines?
4. How should daemonic programs handle user interaction when configuration is needed, and where should their interface be located?
5. What is the key difference between auxiliary and transient posture programs in terms of their presence and attention demands on the user?

📘 Lecture 27 — Behavior & Form Part II

📖 Overview: This lecture continues the study of Human Computer Interaction by exploring how to apply behavioral and formal design principles to different platforms, including the web, mobile devices, and appliances. It emphasizes the importance of creating transparent, flow-inducing interfaces through careful orchestration of interaction elements.

🗂️ Topics Covered

This lecture covers postures for web design including information-oriented sites and transactional web applications, web portals, postures for other platforms such as kiosks, handheld devices, and appliances, flow and transparency in interaction design, and orchestration methods including finesse, distinguishing possibility from probability, providing comparisons, and avoiding unnecessary reporting.

📝 Lecture Summary

27.1 Postures for the Web

Designers may be tempted to think the web is different from desktop applications, but the basic four stances cover most needs. Information-oriented sites must balance sovereign attributes (detailed information display using full-screen space) with transient attributes (ease and clarity of navigation). The dominant stance depends on target personas and their behavior patterns — infrequent users need transient stances, while repeat users benefit from sovereign stances. Web designers must decide early what lowest common denominator screen resolution to support.

📐 Formula: Sovereign stance = full-screen detailed display → maximizes information density and navigational tools 📌 Example: E-commerce sites like Amazon.com balance sovereign and transient stances by providing one-click ordering, good search, browsing, reviews, recommendation lists, persistent shopping cart, and tracking of recently viewed items.

💡 Why this matters: The choice between sovereign and transient posture directly impacts user satisfaction and task completion rates.

Transactional sites and Web applications

Transactional Web sites must balance sovereign and transient stances similarly to informational sites. Consumer-oriented sites (e-commerce, online banking) have heavy informational aspects as users research and compare products. Navigational clarity, access to supporting information, and streamlining of transactions are critical.

📐 Formula: Consumer transactional sites = balance sovereign + transient + heavy informational aspects 📌 Example: Amazon.com addresses these issues via one-click ordering, persistent shopping cart, and tracking of recently viewed items.

27.2 Web portals

Early search engines served as navigational portals — ways to get somewhere else. Nothing really happens; you get in, go somewhere, get out. The appropriate posture is transient for infrequent access and auxiliary for frequent access (like the Windows taskbar).

Environmental portals provide unified access to content and functionality related to a specific topic; actual work is done here. Information is gathered from disparate sources and acted upon. The appropriate posture is sovereign — the portal becomes a destination in itself.

Within environmental portals, individual elements function as small applications with postures: • Auxiliary elements: aggregated information sets the user wants constant access to • Transient elements: minimal complexity, used briefly on demand

📌 Example: A portal composed of dynamic status monitors (auxiliary) plus temporary to-do lists (transient).

27.3 Postures for Other Platforms

Kiosks — Despite large full-screen nature, most kiosks should be transient because users are first-time (except ATMs), spend minimal time, use touch screens or bezel buttons, and stand in public places with bright light and distractions. Educational/entertainment kiosks can allow more data density and complex interactions.

🔑 Definition — Handheld devices: Often satellite systems of a desktop, used more for viewing than heavy input. The appropriate posture is auxiliary for frequently used applications (PIM, email, browsing) and transient for less frequent ones (alarms).

Cellular telephones are primary communication devices, not satellites. The best interface is transient — place a call as quickly as possible, then abandon the interface. Voice activation is perfect for placing calls.

🔑 Definition — Convergence devices (e.g., Handspring Treo): Combine handheld data and phone functions. Data functions should be auxiliary, phone functions transient.

Appliances — Most should be transient posture interfaces. Users want simple, straightforward interfaces to perform specific tasks. Status information (cycle status, VCR settings) should be provided as daemonic icons — minimal status quietly in a corner.

💡 Why this matters: Designers often mistakenly put dozens of unwanted features into digital appliances, making LCD touchscreens confusing arrays of unworkable controls.

27.4 Flow and Transparency

Flow is a state of deep, nearly meditative involvement where people concentrate wholeheartedly on an activity, losing awareness of distractions. The concept was first identified by Mihaly Csikszentmihalyi. Tom DeMarco and Timothy Lister describe flow as inducing a "gentle sense of euphoria" where users become unaware of time passage.

To create flow, interaction must become transparent — the interface must not call attention to itself but serve the user. Four methods to achieve this:

1. Follow mental models — Different users have different mental models of processes. The interface should match users' existing mental models rather than computer processes.
2. Direct, don't discuss — Users prefer interacting with software like using a tool (car, hammer) rather than having a dialog. Direct manipulation idioms are better.
3. Keep tools close at hand — Tools should be on palettes or toolbars for easy access with single clicks.
4. Provide modeless feedback — Information built into the main interface that doesn't stop normal flow.

🔑 Definition — Modeless feedback: Feedback that is built into the main interface and doesn't stop the normal flow of system activities and interaction.

📌 Example: Word shows page number, section, total pages, cursor position, and time modelessly via the status bar. Jet fighters use heads-up display (HUD) to superimpose critical instrument readings onto the forward view.

📌 Example: In a hospital system, physicians and nurses have mental models based on patient records — finding patients by name makes sense. Business clerks think about overdue bills — sorting by time overdue and amount due makes sense.

📐 Formula: Direct manipulation = point to what you want → click and drag → immediate visual feedback

27.5 Orchestration

Orchestration is "harmonious organization" — when all interface elements work coherently towards a single goal, the interaction becomes almost invisible. The interaction designer must train to hear "sour notes" in software interaction.

Adding finesse: Less is more — Constantly strive to reduce interface elements without reducing system power. Do more with less. Example: Instead of File Open dialog boxes in every application, replace with the shell program itself.

🔑 Definition — Finesse: Coordinating and controlling all product power without letting the interface become a jumble of windows and dialogs covered with unrelated controls.

Distinguishing possibility from probability — Programmers tend to treat possibilities as equal to probabilities. Example: A user has equal mathematical possibility of saving or discarding six hours of work, but the probability of discarding is thousands to one against. Yet typical programs always ask.

📐 Formula: Good design = segregate possible from probable → don't ask for unlikely scenarios

Providing comparisons — Quantitative information should answer the question "Compared to what?" Visual presentation should show data rather than just telling about it.

📌 Example: Windows File Manager showed exact bytes free (231,728 KB) — hard to interpret. A pie chart showing 22% free space with used space in blue and free space in magenta makes comprehension immediate.

Using graphical input — Software should let users enter graphs and convert them to numbers, not just enter numbers to make graphs. Example: Word processors let users set tabs by dragging markers on rulers.

Reflecting program status — Programs should visually show when asleep, awake, or busy. Status should be communicated using rich modeless feedback.

📐 Formula: Program state communication = asleep→looks asleep, awake→looks awake, busy→looks busy

Avoiding unnecessary reporting — Don't stop proceedings to report normalcy. Save dialogs for events outside normal course. Don't bother users with non-serious problems.

📌 Example: If program has trouble getting through a busy signal, build a status indicator rather than a dialog box.

Avoiding blank slates — Users prefer seeing what the program thinks is right and manipulating it, rather than explaining what they want from scratch.

📌 Example: Word creates a blank document with preset margins rather than asking for every detail. PowerPoint asks users to choose base style each time — less adequate.

📐 Formula: Blank slate → program makes statistically good assumption → user adjusts → better than asking for permission

Command invocation versus configuration — There's a big difference between invoking a function and configuring it. Invocation should be immediate without interrogation; configuration should be separate.

📌 Example: Word's print toolbar button prints immediately; Print dialog from File menu allows configuration. Users invoke commands ten times for every one configuration.

Asking questions versus providing choices — Asking questions makes users feel inferior; offering choices empowers them. Dialog boxes ask questions; toolbars offer choices.

🔑 Definition — Ejector seat levers: Controls for significant, irreversible actions (like ejecting from a jet fighter). These must be hidden from inexperienced users to prevent accidental deployment. They come in two varieties: those causing significant visual dislocation and those performing irreversible actions.

📌 Example: A function that changes layout of all tools or performs irreversible actions like deleting data should be hidden and require deliberate action to access.

⭐ Key Takeaways

The critical concept is that posture choice (sovereign, transient, auxiliary) depends on user personas and behavior patterns — infrequent users need transient stances, repeat users benefit from sovereign stances. Flow and transparency are essential for productivity, achieved through following mental models, direct manipulation, keeping tools close at hand, and providing modeless feedback. Orchestration requires finesse (less is more), distinguishing possibility from probability, providing comparisons rather than raw numbers, and avoiding unnecessary reporting. Programs should avoid blank slates by making good assumptions, separate command invocation from configuration, and hide ejector seat levers from casual users.

🧠 Quick Revision Questions

1. What are the four basic postures for user interfaces, and how do they apply to web design?
2. What is "flow" and what four methods help create it?
3. Why should designers distinguish between possibility and probability when designing dialogs?
4. What is the difference between command invocation and configuration, and how should each be handled?
5. Why should "ejector seat levers" be hidden from inexperienced users?

📘 Lecture 28 — Behavior & Form Part III

📖 Overview: This lecture continues the study of Human Computer Interaction by examining how to eliminate unnecessary user effort (excise) in software interfaces. It explores the nature of excise tasks versus goal-directed tasks, and provides strategies for reducing navigational complexity to improve usability and user satisfaction.

🗂️ Topics Covered

The lecture covers two main sections: first, an in-depth analysis of excise—the extra work users must perform that doesn't directly contribute to their goals—including GUI excise, visual excise, and training wheels. Second, navigation as a form of excise is examined, along with types of navigation (between windows, panes, tools, and information), and strategies for improving navigation through reducing places to go, providing signposts, overviews, proper mapping, and inflection.

📝 Lecture Summary

28.1 Eliminating Excise

Software often contains interactions that are top-heavy with extra work for the user. Excise is the extra work that satisfies either the needs of our tools or those of outside agents as we try to achieve our objectives. Programmers typically focus so intently on enabling technology that they don't carefully consider the human actions required from a goal-directed point-of-view. The result is software that charges users a cognitive and sometimes physical tax every time it is used. Where we can eliminate the need for excise tasks, we make the user more effective and productive and improve the usability of the software.

🔑 Definition — Excise: Extra work that satisfies the needs of tools or outside agents rather than directly contributing to achieving the user's goal.

What Is Excise?

Any large task involves many smaller tasks. Some work directly toward achieving the goal (goal-directed tasks), while excise tasks don't contribute directly to reaching the goal but are necessary to accomplish it just the same. For example, when driving to the office: opening the garage door, starting the engine, and stopping at traffic lights are excise tasks, while steering down the road toward your office is goal-directed. The distinction is sometimes hard to see because we get so used to excise being part of our tasks.

Software has a clear dividing line between goal-directed tasks and excise tasks. Some software excise tasks are trivial, while others are as obnoxious as fixing a flat tire—installation, configuring networks, making backups, and connecting to online services. As a software designer, you should become sensitive to the presence of excise and take steps to eradicate it with the same enthusiasm a doctor would apply to curing an infection.

Virtually all window management falls into this category. Dragging, reshaping, resizing, reordering, tiling, and cascading windows qualify as excise actions.

💡 Why this matters: Recognizing excise is the first step to eliminating it. Every excise task you remove makes your software more efficient and user-friendly.

GUI Excise

One main criticism of GUIs is that getting where you want is made slower by extra effort manipulating windows and icons. With command lines, users can just type commands and the computer executes them immediately. With windowing systems, they must open folders, find files, then stretch and drag windows into desired configurations. However, the command-line interface forces an even more expensive excise budget: the user must first memorize commands and cannot easily configure their screen. The excise of the command-line interface becomes smaller only after significant time and effort in learning it.

For casual or first-time users, the visual explicitness of the GUI helps them navigate and learn what tasks are appropriate. The step-by-step nature of the GUI helps users who aren't yet familiar with the task or system, and benefits those who must use more than one program at a time.

Excise and expert users

Any user willing to learn a command-line interface automatically qualifies as a power user. These users will easily learn each nuance of programs they use, starting each program with a clear idea of exactly what they want to do. To this user, the assistance offered to casual or first-time users is just in the way. We must be careful when eliminating excise: we must not remove it just to suit power users, but we also must not force power users to pay the full price of providing help to new or infrequent users.

Training wheels

Software designers can inadvertently introduce significant excise in support for first-time or casual users. Training wheels—facilities added to make it easy for newer users to learn—quickly become excise as users become perpetual intermediates (familiar with the program). Such facilities must be easily turned off. Training wheels are rarely needed for extended periods and, although a boon to beginners, are a hindrance to advanced learning and use when left on permanently.

"Pure" excise

There are actions that are excise of such purity that nobody needs them, from power users to first-timers. These include most hardware-management tasks the computer could handle itself, like telling a program which COM port to use. Any demands for such information should be struck from user interfaces and replaced with more intelligent program behavior behind the scenes.

Visual excise

Designers sometimes paint themselves into excise corners by relying too heavily on visual metaphors—desktops with telephones, copy machines, staplers, and fax machines, or file cabinets with folders in drawers. While these metaphors may make it easy to understand relationships between program elements, after these fundamentals are learned, management of the metaphor becomes pure excise. The screen space consumed by images becomes increasingly egregious, particularly in sovereign posture applications (programs used for extended periods). The little telephone that charmingly told us how to dial on that first day is now a barrier to quick communications.

Transient posture applications (programs used infrequently) can tolerate more training and explanation excise than sovereign applications because their users need more assistance. For sovereign applications, the slightest excise becomes agonizing over time.

The second type of visual excise became significant with the Web: overemphasis of visual design elements to the extent they interfere with user goals and comprehension. The late 90s attracted graphic designers to the Web who viewed it as a predominantly visual medium. This might be appropriate for brochure-ware Web sites (serving as marketing collateral) but is highly inappropriate for transactional Web sites and Web applications, which have far more in common with sovereign desktop applications.

A pre-eminent example was Boo.com, a fashion e-tailor that used hip visuals and flash-based interactive agents but didn't address user goals. The site was sluggish due to flash, visually distracting, confusingly laid out, and difficult to navigate. Users' goals were simply to buy products more quickly, cheaply, and easily online. By the time problems were remedied, customers had abandoned them.

Determining what is excise

The only way to determine whether a function or behavior is excise is by comparing it to the user's goals. If the user needs to see two programs at a time to compare or transfer information, the ability to configure windows to share screen space is not excise. If the user doesn't have this specific goal, a requirement to configure the main window is excise.

📌 Example — Determining Excise: A user needs to transfer data between two programs. Allowing them to arrange windows side-by-side is not excise—it directly supports their goal. However, if the user only works in one program at a time, forcing them to configure windows is pure excise.

28.2 Navigation and Inflection

Desktop applications, Web sites, and devices all share one attribute that, if improperly designed, becomes a critical obstacle to usability: navigation. The user must be able to navigate efficiently through features and facilities and stay oriented as they move from screen to screen. A user can navigate if they always understand what to do next, know what state the program is in, and know how to find the tools they need.

Navigation Is Excise

The most important thing to realize about navigation is that, in almost all cases, it represents pure excise or something close to it. Except in games where the goal is to navigate through a maze, navigating through software does not meet user goals, needs, or desires. Unnecessary or difficult navigation becomes a major frustration. Poorly designed navigation presents the number-one problem in the design of any software application or system—desktop, Web-based, or otherwise. It is also where the programmer's implementation model is made most apparent to the user.

Types of Navigation

Navigation through software occurs at multiple levels:

• Navigation between multiple windows or screens — most disorienting kind, involves gross shifting of attention disrupting user flow and forcing new context. The act of navigating to another window often obscures the original window's contents, requiring window management. If users must constantly shuttle back and forth between windows, productivity drops and disorientation rises. If the number of windows is large enough, users may experience navigational trauma—getting lost in the interface. Sovereign posture applications avoid this by placing all main interactions in a single primary window with multiple independent panes.

• Navigation between panes within a window — windows can contain multiple adjacent panes (separated by splitters) or tabbed panes (stacked on top of each other). Adjacent panes can solve many navigation problems by placing supporting functions directly adjacent to the primary work area. Problems arise when supporting panes become too numerous or don't match the user's workflow. Too many adjacent panes result in visual clutter and confusion. Tabbed panes bring navigational excise and potential disorientation because they obscure what was on screen before. However, tabbed panes are appropriate when multiple supporting panes aren't used simultaneously. Microsoft Internet Explorer for Macintosh uses a variant where tabs can deselect, shutting the adjacent pane like a drawer.

⚠️ Caution: Some programmers interpret tabs as permission to break complex facilities into smaller chunks. This actually increases excise while decreasing understanding and orientation. A dialog box is another room—have a good reason to go there.

• Navigation between tools or menus in a pane — spatial organization is critical to minimizing extraneous mouse movements. Tools used frequently and in conjunction should be grouped together spatially and immediately available. Menus require more navigational effort because contents aren't visible prior to clicking. Frequently used functions should be provided in toolbars or palettes; menu use should be reserved for infrequently accessed commands.

📌 Example — Poor Tool Navigation: Adobe Photoshop 6.0 forces users to navigate between the Paint Bucket tool and Gradient tool, which occupy the same location on the tool palette. Users must click and hold to select between them, even though both are fill tools used frequently. Better design would place each on the palette next to each other.

• Navigation within information displayed in a pane — accomplished by scrolling (panning), linking (jumping), and zooming. Scrolling is often a necessity but should be minimized. For 2D visualization and drawing applications, thumbnail maps ease navigation. Linking is the critical navigational paradigm of the Web—because it is visually dislocating, extra care must be taken to provide visual and textual cues. Zooming and panning are appropriate for 2D or 3D drawings but typically fall short for arbitrary or abstract data. Spatial zoom is difficult enough for users; logical zoom (displaying more attribute details about objects) is arcane to all but visualization researchers. Panning and zooming together create enormous navigation difficulties—humans are not used to moving in unconstrained 3D space.

Improving Navigation

The most effective methods for improving navigation:

1. Reduce the number of places to go

• Keep pages and windows to a minimum: one full-screen window with two or three views maximum
• Keep adjacent panes limited to the minimum needed for users to achieve their goals (three panes is a good maximum for sovereign applications)
• Keep controls limited to what users really need
• Minimize scrolling; default views should allow orientation without too much panning
• Zooming (especially continuous zooming) should be discretionary, not required

Many e-commerce sites present confusing navigation because designers try to serve everyone with one generic site. Personalization can help—if a user buys books but never CDs, access to the CD portion could be de-emphasized, simplifying navigation for that user.

2. Provide signposts Signposts are persistent objects placed in the user interface that serve as points of reference. In desktop applications, these include the program's window, menu bars, toolbars, palettes, status bars, and rulers. On the Web, Amazon.com makes careful use of persistent objects—the tab bar along the top and Search/Browse areas on the left. Their consistent presence and layout help orient customers.

Menus: The most prominent permanent object. Unexpected changes to menus can deeply reduce user trust. It's okay to add items to the bottom of a menu, but the standard suite of items should change only for clearly demonstrable need.

Toolbars: Should be considered recognizable signposts. Removing the toolbar is a dislocating change. Some programs put controls on the toolbar that made the toolbar disappear—this is a completely inappropriate "ejector seat lever."

Other interface signposts: Tool palettes and fixed data display areas should also be considered persistent objects. Judicious use of white space and legible fonts is important so signposts remain clearly evident.

📌 Example — Web Signposts: Amazon.com uses a tab bar that remains constant throughout shopping, with Search and Browse areas on the left. These don't just provide navigational options—their consistent presence and layout help orient customers.

3. Provide overviews Overviews help orient users within the content rather than within the application as a whole. The overview area should itself be persistent, though its content depends on the data being navigated. Overviews can be graphical (like the Navigator palette in Adobe Photoshop) or textual (like breadcrumb displays on the Web). Annotated scrollbars provide location information about selections, highlights, and other attributes of text—Microsoft Word uses a variant showing page number and nearest header in a ToolTip during scroll.

4. Provide appropriate mapping of controls to functions Mapping describes the relationship between a control, the thing it affects, and the intended result. Poor mapping occurs when a control does not relate visually or symbolically with the object it affects, requiring the user to stop and think about the relationship, breaking flow. Poor mapping increases cognitive load and can result in potentially serious user errors.

5. Inflect your interface to match user needs Inflecting an interface means organizing it to minimize typical navigation—placing the most frequently desired functions and controls in the most immediate and convenient locations, while pushing less frequently used functions deeper into the interface. Rarely used facilities shouldn't be removed from the program, but should be removed from the user's everyday workspace.

The most important principle in proper inflection is commensurate effort: people will willingly work harder for something more valuable to get. Value is in the eye of the beholder and has entirely to do with the user's goals. If the user really wants something, they will work harder to get it. A program's user interface can't be complex to achieve simple results, but it can be complex to achieve complex results (as long as such results aren't needed very often).

Controls and displays should be organized according to three attributes:

• Frequency of use: Most frequently used items (many times a day) should be immediately in reach. Less frequently used items (once or twice a day) should be no more than a click or two away. Other items can be two or three clicks away.
• Degree of dislocation: The amount of sudden change caused by invoking a function. Generally, put these functions deeper into the interface.
• Degree of exposure: Functions that are irreversible or have dangerous ramifications should be more difficult for users to stumble across.

As users get more experienced, they will search for shortcuts, and you must provide them. When software follows commensurate effort, the learning curve doesn't go away, but it disappears from the user's mind.

⭐ Key Takeaways

The central concept of this lecture is that excise—extra work required by tools rather than directly supporting user goals—must be identified and eliminated from software interfaces. Navigation is the most common form of excise, and poorly designed navigation presents the number-one problem in software design. To improve navigation, designers should reduce the number of places users must go, provide persistent signposts like menus and toolbars, offer overviews such as breadcrumbs, ensure proper mapping between controls and functions, and inflect the interface to organize controls by frequency of use, degree of dislocation, and degree of exposure. The principle of commensurate effort reminds us that users will tolerate complexity only when the rewards justify it, and that training wheels for beginners must be easily removable once users become perpetual intermediates.

🧠 Quick Revision Questions

1. What is excise in the context of user interface design, and how does it differ from goal-directed tasks?

2. Explain the difference between sovereign posture applications and transient posture applications in terms of how much visual excise they can tolerate.

3. What are the four main types of navigation described in the lecture, and which type is considered most disorienting for users?

4. List five strategies for improving navigation in applications, Web sites, and devices.

5. What is the principle of commensurate effort, and how should it guide the organization of controls in an interface?

📘 Lecture 29 — Evaluation – Part I

📖 Overview: This lecture introduces the fundamental concepts of evaluation in Human Computer Interaction. It explains what evaluation is, why it is necessary, and when it should be conducted during the development process. The lecture also introduces four core evaluation paradigms and various techniques used to assess interactive products.

🗂️ Topics Covered

The lecture covers the key concepts of evaluation, including what to evaluate, why evaluation is needed, and when to conduct it. It then introduces four core evaluation paradigms: "quick and dirty" evaluation, usability testing, field studies, and predictive evaluation. Finally, it describes the main evaluation techniques, including observing users, asking users, asking experts, user testing, and modeling users' task performance.

📝 Lecture Summary

What to evaluate?

There is a huge variety of interactive products with a vast array of features that need to be evaluated. Some features, such as the sequence of links to be followed to find an item on a website, are often best evaluated in a laboratory, since this setting allows evaluators to control what they want to investigate. Other aspects, such as whether a collaborative toy is robust and whether children enjoy interacting with it, are better evaluated in natural settings, so that evaluators can see what children do when left to their own devices.

John Gould and his colleagues recommended three principles for developing the 1984 Olympic Message System: focus on users and their tasks; observe, measure, and analyze their performance with the system; and design lucratively. Since that study, a number of new evaluation techniques have been developed, along with a growing trend towards observing how people interact with the system in their work, home, and other settings. The goal is to obtain a better understanding of how the product is (or will be) used in its intended setting, as real-world tasks are often interrupt-driven and very different from laboratory observations.

💡 Why this matters: The context of evaluation (laboratory vs. natural setting) significantly impacts the validity of the findings, as real-world usage is often messy and interrupt-driven.

Why you need to evaluate?

Just as designers shouldn't assume that everyone is like them, they also shouldn't presume that following design guidelines guarantees good usability. Evaluation is needed to check that users can use the product and like it. Nowadays, users look for much more than just a usable system, as the Nielsen Norman Group points out: the first requirement for an exemplary user experience is to meet the exact needs of the customer, without fuss or bother, followed by simplicity and elegance.

Bruce Tognazzini points out that there are five good reasons for investing in user testing:

1. Problems are fixed before the product is shipped, not after.
2. The team can concentrate on real problems, not imaginary ones.
3. Engineers code instead of debating.
4. Time to market is sharply reduced.
5. Upon first release, the sales department has a rock-solid design it can sell.

The diversity of interactive products, coupled with new user expectations, poses interesting challenges for evaluators, who must now adapt existing techniques and develop new ones. As well as usability, user experience goals can be extremely important for a product's success.

When to evaluate?

The product being developed may be a brand-new product or an upgrade of an existing product. For new products, considerable time is invested in market research, often using mockups to elicit reactions from potential users. For upgrades, attention is focused on improving the overall product, which is well suited to usability engineering where evaluations compare user performance and attitudes with those for previous versions.

Evaluations done during design to check that the product continues to meet users' needs are known as formative evaluations. Evaluations done to assess the success of a finished product, such as to satisfy a sponsoring agency or check a standard, are known as summative evaluations.

29.1 Evaluation paradigms and techniques

Any kind of evaluation is guided either explicitly or implicitly by a set of beliefs that may be underpinned by theory. These beliefs and the practices (methods or techniques) associated with them are known as an evaluation paradigm. In this lecture, we identify four core evaluation paradigms.

"Quick and dirty" evaluation

A "quick and dirty" evaluation is a common practice in which designers informally get feedback from users or consultants to confirm that their ideas are in line with users' needs and are liked. The emphasis is on fast input rather than carefully documented findings. This approach is often called "quick and dirty" because it is meant to be done in a short space of time. The data collected is usually descriptive and informal, and it is fed back into the design process as verbal or written notes, sketches, and anecdotes.

Usability testing

Usability testing involves measuring typical users' performance on carefully prepared tasks that are typical of those for which the system was designed. Users' performance is generally measured in terms of number of errors and time to complete the task. The defining characteristic of usability testing is that it is strongly controlled by the evaluator. Tests typically take place in laboratory-like conditions that are controlled. Quantifying users' performance is a dominant theme in usability testing. Some evaluators summarize this data in a usability specification so that developers can use it to test future prototypes or versions of the product against it.

🔑 Definition — Usability specification: A document that summarizes performance data so that developers can test future prototypes or versions of the product against it, often specifying optimal performance levels and minimal levels of acceptance.

Field studies

The distinguishing feature of field studies is that they are done in natural settings with the aim of increasing understanding about what users do naturally and how technology impacts them. In product design, field studies can be used to: (1) help identify opportunities for new technology; (2) determine requirements for design; (3) facilitate the introduction of technology; and (4) evaluate technology. The data takes the form of events and conversations that are recorded as notes, or by audio or video recording, and later analyzed using a variety of analysis techniques such as content analysis, discourse analysis, and conversational analysis.

🔑 Definition — Ethnography: A particular type of insider evaluation in which the aim is to explore the details of what happens in a particular social setting. In HCI, it is a means of studying work or other activities to inform the design of information systems and understand aspects of their use.

Predictive evaluation

In predictive evaluations, experts apply their knowledge of typical users, often guided by heuristics, to predict usability problems. The key feature of predictive evaluation is that users need not be present, which makes the process quick, relatively inexpensive, and thus attractive to companies. In recent years, heuristic evaluation in which experts review the software product guided by tried and tested heuristics has become popular. It is important to note that with the advent of new interactive products, original sets of heuristics have been found insufficient, and new sets of heuristics are needed that are tailored to evaluating different classes of interactive products.

The lecture provides a table summarizing key aspects of each evaluation paradigm, comparing them across the following issues: the role of users, who controls the process, the location of the evaluation, when the evaluation is most useful, the type of data collected and how it is analyzed, how findings are fed back into design, and the underlying philosophy.

Techniques

There are many evaluation techniques, and the lecture examines techniques for:

• Observing users: Observation techniques help to identify needs leading to new types of products and help to evaluate prototypes. Notes, audio, video, and interaction logs are well-known ways of recording observations.
• Asking users: Asking users what they think of a product is an obvious way of getting feedback. Interviews and questionnaires are the main techniques for doing this.
• Asking experts: Guided by heuristics, experts step through tasks role-playing typical users and identify problems. This approach is usually relatively inexpensive and quick to perform.
• User testing: Measuring user performance to compare two or more designs has been the bedrock of usability testing. Generally, the time taken to complete a task, the number of errors made, and the navigation path through the product are recorded.
• Modeling users' task performance: These techniques attempt to model human-computer interaction to predict the efficiency and problems associated with different designs at an early stage without building elaborate prototypes. GOMS and the keystroke model are the best-known techniques.

⭐ Key Takeaways

Evaluation is essential to verify that a product meets user needs and is enjoyable to use, as relying solely on design guidelines is insufficient. There are four core evaluation paradigms: quick and dirty evaluation for fast, informal feedback; usability testing for controlled, quantitative measurement of user performance; field studies for understanding natural user behavior in real-world settings; and predictive evaluation for expert-driven, inexpensive identification of usability problems. The context of evaluation—laboratory versus natural setting—significantly impacts the findings, and different paradigms are suited for different stages of development (formative vs. summative). Finally, various techniques exist to gather data, including observing users, asking users or experts, testing performance, and modeling tasks, each with its own strengths and limitations.

🧠 Quick Revision Questions

1. What are the three principles recommended by John Gould and his colleagues for developing the 1984 Olympic Message System?
2. Distinguish between formative evaluation and summative evaluation.
3. Name the four core evaluation paradigms discussed in this lecture and briefly describe the key characteristic of each.
4. What is the defining characteristic of usability testing, and where does it typically take place?
5. What is the key feature of predictive evaluation that makes it attractive to companies, and what is its main limitation?

📘 Lecture 30 — Evaluation – Part II

📖 Overview: This lecture introduces the DECIDE framework, a structured checklist for planning and conducting evaluations in Human-Computer Interaction. It is essential because it provides novice evaluators with a systematic approach to ensure evaluations are well-organized, ethical, and yield reliable, valid data that can be interpreted and presented effectively.

🗂️ Topics Covered

The lecture covers the DECIDE framework's six steps: determining the goals of an evaluation, exploring specific questions to be answered, choosing the evaluation paradigm and techniques, identifying practical issues such as users and equipment, deciding how to deal with ethical issues, and finally evaluating, interpreting, and presenting data, with a focus on reliability, validity, biases, scope, and ecological validity.

📝 Lecture Summary

DECIDE: A framework to guide evaluation

Well-planned evaluations are driven by clear goals and appropriate questions. To guide evaluations, we use the DECIDE framework, a checklist for novice evaluators. It consists of six steps: 1) Determine the overall goals, 2) Explore the specific questions, 3) Choose the evaluation paradigm and techniques, 4) Identify practical issues, 5) Decide how to deal with ethical issues, and 6) Evaluate, interpret, and present the data.

Determine the goals

The first step is to identify the high-level goals of the evaluation. For example, goals can be to clarify user needs, determine the best metaphor for a conceptual design, fine-tune an interface, or examine how technology changes working practices. These goals guide the evaluation approach, such as using usability testing for quantitative engineering or a field study for exploring innovative products.

Explore the questions

To make goals operational, specific questions must be identified. For instance, the goal of understanding why customers prefer paper tickets over e-tickets can be broken down into questions about trust, computer access, security, or poor interface design. Questions can be further decomposed into sub-questions, such as asking if the system is difficult to navigate or if the terminology is confusing.

Choose the evaluation paradigm and techniques

After identifying goals and questions, the next step is to choose the evaluation paradigm and techniques. The paradigm determines which techniques are used. Practical and ethical issues must be considered, and trade-offs are often necessary due to cost, time, or lack of expertise or equipment.

Identify the practical issues

Several practical issues must be considered before starting an evaluation, including users, facilities and equipment, schedules and budgets, and evaluators' expertise.

• Users: It is crucial to involve appropriate users. They must be screened to ensure they represent the target population, considering factors like experience, age, gender, and cultural diversity. Evaluators must put users at ease by treating them courteously and explaining that the system is being tested, not them.
• Facilities and equipment: Practical concerns include how to set up recording equipment like cameras without making users uncomfortable, and ensuring spare supplies like batteries are available.
• Schedule and budget: Time and budget constraints are important. Planning evaluations that can be completed on schedule and within budget is key, often requiring compromises.
• Expertise: The evaluation team must have the necessary expertise. For example, using models requires prior experience, and analyzing video requires appropriate skills and equipment.

Decide how to deal with the ethical issues

Ethical issues are paramount. Institutional review boards often require researchers to submit plans explaining how human participants will be treated. Key guidelines include:

• Tell participants the goals, process, time commitment, data collected, and any payment offered.
• Ensure confidentiality of demographic, financial, or health information, using a coding system to store data separately from identifiers.
• Make sure users know they can stop the evaluation at any time.
• Pay users when possible to create a formal relationship with mutual commitment.
• Avoid quotes or descriptions that could reveal a person's identity, and ask permission before quoting them.

The general rule is: "Do unto others only what you would not mind being done to you."

The lecture also notes ethical concerns with online research, where user interactions can be logged without their knowledge, raising issues of privacy, confidentiality, and informed consent.

Evaluate, interpret, and present the data

Key decisions involve what data to collect, how to analyze it, and how to present findings. General questions to ask include: Is the technique reliable? Is it valid? Are there biases? Are the results generalizable (scope)? Is the evaluation ecologically valid?

• Reliability: How consistently a technique produces the same results under the same circumstances. A controlled experiment has high reliability, while an unstructured interview has low reliability.
• Validity: Whether the technique measures what it is supposed to measure. For example, a lab experiment is not valid for studying product use in homes; an ethnographic study would be more valid.
• Biases: Distortions in results, such as expert evaluators being sensitive to certain flaws or interviewers unconsciously influencing responses.
• Scope: How much findings can be generalized. For example, a keystroke model predicts expert, error-free behavior, so results cannot describe novice learning.
• Ecological validity: How the evaluation environment influences results. Lab experiments have low ecological validity because they differ from real-world settings, whereas ethnographic studies have high validity. The Hawthorne effect describes how participants alter their behavior when they know they are being studied.

⭐ Key Takeaways

The DECIDE framework is a systematic, six-step guide for planning evaluations. A successful evaluation must start with clear goals, then be broken down into specific, operational questions. Practical issues like selecting the right users, managing budgets and schedules, and having the right expertise are critical and often require compromises. Ethical treatment of participants is non-negotiable, requiring informed consent, confidentiality, and respect for their rights. Finally, when interpreting data, evaluators must rigorously assess the reliability, validity, biases, scope, and ecological validity of their techniques to ensure the results are trustworthy and meaningful.

🧠 Quick Revision Questions

1. What are the six steps of the DECIDE framework for guiding evaluation?
2. Why is it important to break down general evaluation goals into specific questions and sub-questions?
3. What are three key practical issues an evaluator must consider, and what kind of trade-offs might be needed?
4. List four ethical guidelines that must be followed when conducting an evaluation with human participants.
5. Define reliability, validity, and ecological validity, and explain why they are important for interpreting evaluation data.

📘 Lecture 31 — Evaluation – Part VII

📖 Overview: This lecture provides a comprehensive definition and framework for conducting usability testing, distinguishing it from other evaluation methods like focus groups, surveys, and beta testing. It emphasizes that usability testing is an iterative process involving real users performing real tasks, with the primary goal of improving product usability rather than merely verifying functionality.

🗂️ Topics Covered

The lecture defines usability testing through five essential characteristics, explores what is and isn't required for testing, discusses when testing is appropriate throughout the design process. It covers testing applications across various product types, interfaces, and documentation aspects. The lecture also introduces special techniques like co-discovery and active intervention, and compares usability testing to beta testing, highlighting additional benefits for organizational change.

📝 Lecture Summary

What is Usability Testing?

Every usability test shares five fundamental characteristics. The primary goal is to improve the usability of a product, distinguishing it from research studies that investigate phenomena or quality assurance tests that check specifications. Within this general goal, specific concerns vary between tests—from novice versus experienced user performance to installation ease for technical staff.

The participants must represent real users who will actually use the product. Testing with programmers for a product intended for legal secretaries is not a usability test. If participants are more experienced than real users, marketplace problems may be missed; if less experienced, unnecessary changes may be made. Participants must perform real tasks that reflect actual job or home usage, which requires understanding users' work contexts.

🔑 Definition — Usability Test: An evaluation method where real users perform real tasks with a product while being observed and recorded, with the data analyzed to diagnose problems and recommend improvements.

You must observe and record what participants do and say, typically one participant at a time. This distinguishes usability testing from focus groups (opinions only), surveys (self-report only), and beta testing (unsystematic field observation). After data collection, you must analyze the data, diagnose real problems, and recommend changes to fix those problems.

📌 Example: A company testing a product for internal network deployment excluded the printed manual to simulate real conditions. Participants were told online help was available and given a help desk number. This focused the test on where people got stuck and how useful online help was, yielding actionable data for improving the interface and help system.

What Is Not Required for a Usability Test?

Features that are useful but not necessary include a laboratory with a one-way mirror, data-logging software, videotape, or a formal test report. A memorandum or meeting about results may be sufficient. Each of these has advantages, but none is an absolute requirement, allowing for low-budget testing with limited staff and equipment.

When is a Usability Test Appropriate?

Usability testing is not limited to a single summative test at project end. The five defining characteristics apply regardless of where you are in the design and development process. Testing is appropriate iteratively from predesign (testing similar products), through early design (testing prototypes), and throughout development (testing different aspects and retesting changes).

Questions that Remain in Defining Usability Testing

Some fuzzy edges remain. A test with only one participant probably would not be called a usability test—at least two or three people per subgroup are needed to avoid idiosyncratic behavior. A test without quantitative measures might also not qualify—at minimum, basic measures like number of participants with problems or task completion time are needed to substantiate reported issues.

💡 Why this matters: The evolving definition of usability testing means practitioners must make thoughtful decisions about participant numbers and measurement approaches based on their specific testing goals and constraints.

Testing Applies to All Types of Products

Usability testing works for all types of products—consumer electronics (TVs, VCRs, telephones), medical products (bedside terminals, patient monitors), engineering devices (oscilloscopes), application software, voice response systems, and automobile navigation systems. The procedures vary somewhat depending on the product but the approach remains largely consistent. Products need not involve hardware or software—forms, instructions, interviewing techniques, and questionnaires can also be tested.

Testing All Types of Interfaces

Any product people have to use has a user interface. Even an elevator's control panel can be tested by creating a simulation on a touch screen computer programmed to respond to button presses with sounds and visual feedback. Users can then be brought in one at a time with realistic scenarios.

📌 Example: An elevator interface prototype on a touch screen could simulate alarm sounds and door opening/closing. Users would interact as they would with a real elevator panel, allowing developers to identify problems before building the actual elevator—when changes would be prohibitively expensive.

Testing All Parts of the Product

Depending on development stage and concerns, usability tests can focus on specific parts including installing hardware, operating hardware, cleaning and maintaining hardware, understanding messages, installing software, navigating menus, filling out fields, recovering from errors, learning from tutorials, or finding instructions in user guides or online help.

Testing Different Aspects of the Documentation

When including documentation in a test, you must decide whether your concern is whether users go to the documentation or how well it works for them when they do. These questions are difficult to answer simultaneously. To test tutorial usability, ask participants to use it explicitly. To test whether anyone would actually open the tutorial, set up tasks with the tutorial available but not required.

📌 Example: In a test where the concern was minimizing help desk calls, the manual was excluded. Participants were told about online help and given a help desk number to call only if truly stuck. This test provided information on where people got stuck, how helpful online help was, and when people called the help desk—but gave no information to improve the printed manual.

Testing with Different Techniques

Most usability tests involve one participant at a time working alone while observed from a corner or behind a one-way mirror. Two useful alternative techniques are co-discovery and active intervention.

Co-discovery involves two participants working together to perform tasks. They are encouraged to talk to each other, which is more natural than thinking out loud alone. This yields more information about thinking processes and problem-solving strategies. Research by Hackman and Biers (1992) confirmed that co-discovery participants make useful comments without distorting other results. Co-discovery is more expensive (paying two people per session) and may be harder to observe, but is especially useful early in design.

Active intervention involves a test team member sitting with the participant and actively probing their understanding during tasks (e.g., asking them to explain what they would do next and why). This provides insights into participants' evolving mental model of the product. Active intervention is particularly useful early in design with prototypes, but should not be used when the primary concern is measuring task completion time or help desk calls.

🔑 Definition — Co-discovery: A usability testing technique where two participants work together to perform tasks, talking naturally to each other as they solve problems.

🔑 Definition — Active intervention: A usability testing technique where a team member sits with the participant and asks probing questions throughout the session to understand the participant's mental model.

Additional Benefits of Usability Testing

Usability testing has two specific benefits beyond improving the product. It helps change people's attitudes about users—watching users struggle has much greater impact than discussions about usability importance. Designers, developers, and managers often become "instant converts" after witnessing testing. It also helps change the design and development process by revealing deeper global problems with both the product and the organizational process.

Comparing Usability Testing to Beta Testing

Beta testing (field testing, clinical trials, user acceptance testing) involves giving an early-release product to customers and waiting for feedback. While real users do real tasks in real environments, beta testing seldom yields useful usability information for several specific reasons:

1. The beta test site doesn't have to use the product
2. Feedback is unsystematic—users report what they remember
3. No one observes and records user behavior
4. Tasks are not chosen by testers—critical situations may not arise
5. Beta testing comes too late in development to fix usability problems

💡 Why this matters: Beta testing's major disadvantage is its timing—it occurs very close to release, when only critical functional bugs can be addressed. Usability testing can be done throughout the design process, allowing problems to be fixed and retested early when changes are less expensive.

📌 Example: Companies that include observations and interviews with beta testing, or give tape recorders to selected users to record problems as they occur, may get more useful information. However, these techniques still cannot overcome beta testing's fundamental timing disadvantage.

⭐ Key Takeaways

The five essential characteristics of usability testing—improving product usability, using real users, having them do real tasks, observing and recording behavior, and analyzing data to diagnose problems—distinguish it from research studies, quality assurance tests, focus groups, surveys, and beta testing. Usability testing can be conducted iteratively throughout the design process using prototypes, not just at the end of development. Special techniques like co-discovery and active intervention are particularly valuable early in design for gaining insights into user thinking and mental models. While tools like laboratories and videotape are useful, they are not required—effective testing can be done on a shoestring budget. Beta testing is not a substitute for usability testing because it is too late, too unsystematic, and provides no observation of actual user behavior.

🧠 Quick Revision Questions

1. What are the five essential characteristics that define every usability test?
2. How does a usability test differ from both a research study and a quality assurance function test?
3. What is co-discovery testing, and when is it particularly useful?
4. Why is beta testing generally inadequate as a primary usability evaluation method?
5. What factors determine whether a test qualifies as a usability test (e.g., number of participants, use of quantitative measures)?

📘 Lecture 32 — Evaluation IV

📖 Overview: This lecture explores the critical importance of navigation in both physical spaces and Web sites. It compares the process of finding a product in a department store to navigating a Web site, emphasizing that clear, consistent navigation is essential for user satisfaction and retention.

🗂️ Topics Covered

The lecture begins by comparing navigation in physical spaces (a mall) and Web sites, highlighting similarities and differences. It then discusses the "unbearable lightness of browsing" and the unique challenges of Web space, including lack of scale, direction, and location. The overlooked purposes of navigation are examined, followed by Web navigation conventions and the concept of persistent navigation. Finally, it covers specific navigation elements including Site ID, Sections, Utilities, Low Level Navigation, Page names, "You are here" indicators, and Breadcrumbs.

📝 Lecture Summary

Scene from a mall

The lecture opens with a scenario of searching for a chainsaw in a Sears department store. You use the store's navigation systems—department names on walls and signs at the end of aisles—along with your ability to scan shelves to find what you're looking for. The process involves deciding whether to search on your own or ask for help, a decision based on familiarity with the store, trust in their organization, time pressure, and sociability.

🔑 Definition — Navigation systems: The signs and organizing hierarchy that help users find what they are looking for in a physical or digital space.

📐 Formula: Process of finding items = Look at department signs → Navigate to section → Scan aisle signs → Examine individual products → If wrong, try another aisle or start over

Web Navigation

The process of entering a Web site mirrors the physical mall experience in several ways:

• You're usually trying to find something
• You decide whether to ask first (search) or browse first
• If you choose to browse, you make your way through a hierarchy using signs
• Eventually, if you can't find what you're looking for, you'll leave

The Web equivalent of asking directions is searching—typing a description into a search box. Some people are "search-dominant" users who almost always look for a search box, while "link-dominant" users browse first and search only when necessary.

💡 Why this matters: Understanding user preferences (search vs. browse) helps designers create navigation that supports both types of users.

The unbearable lightness of browsing

While Web browsing feels similar to navigating physical spaces, the Web experience is missing many cues we rely on:

• No sense of scale: Users have little idea how large a site is
• No sense of direction: No left and right, no up and down in physical terms
• No sense of location: No physical traversal of space; you're teleported via links

The Back button accounts for 30-40 percent of all Web clicks because users lack physical sense of location. Home pages serve as fixed reference points, like the North Star.

💡 Why this matters: The lack of physicality in Web navigation makes it essential to design explicit navigation systems that compensate for this missing sense of place.

The overlooked purposes of navigation

Navigation serves several important functions beyond helping users find things and telling them where they are:

1. It gives us something to hold on to — Done right, navigation makes users feel grounded
2. It tells us what's here — Navigation reveals content by making the hierarchy visible
3. It tells us how to use the site — Good navigation implicitly tells users where to begin and what options are available
4. It gives us confidence in the people who built it — Clear navigation creates a good impression and influences whether users return

Web navigation conventions

Physical spaces have navigation conventions that have evolved over time (street signs, page numbers, chapter titles). Web navigation conventions have emerged quickly, mostly adapted from print conventions. The basic elements include Site ID, Sections, Utilities, and Pages.

Persistent navigation (or global navigation) describes the set of navigation elements that appear on every page of a site. It should include five elements users most need at all times.

Exceptions to the persistent navigation rule:

• The Home page — has different burdens and sometimes shouldn't use persistent navigation
• Forms — on payment or registration pages, persistent navigation can be a distraction; use a minimal version with Site ID, Home link, and helpful Utilities

Site ID

The Site ID or logo is like the building name for a Web site. Users expect to see it at the top of the page, usually in or near the upper left corner. The Site ID represents the whole site and should:

• Be at the top to frame the entire page
• Look like a Site ID with a distinctive typeface and recognizable graphic

The Sections

The Sections (primary navigation) are links to the main sections of the site—the top level of the site's hierarchy. The persistent navigation should also display secondary navigation: the list of subsections in the current section.

The Utilities

Utilities are links to important elements that aren't part of the content hierarchy. These include Help, Site Map, Shopping Cart, About Us, and Contact Us. The Utilities list should be slightly less prominent than Sections. Only four or five Utilities should be in the persistent navigation.

🔑 Definition — Utilities: Links to important elements of the site that help users use the site or provide information about its publisher.

Low Level Navigation

A common problem in Web design is failing to give lower-level navigation the same attention as the top. This happens because:

• Good multi-level navigation is hard with limited space
• Designers often don't have time to figure out beyond two levels
• Designers assume users will understand by the time they get deeper

The reality is that users spend as much time on lower-level pages as at the top. It's vital to have sample pages showing navigation for all potential levels before arguing about the Home page color scheme.

Page names

Page names are the street signs of the Web. Four things to know:

1. Every page needs a name — Don't rely solely on navigation highlighting
2. The name needs to be in the right place — Should frame the unique content
3. The name needs to be prominent — Usually the largest text on the page
4. The name needs to match what I clicked — Sites make an implicit social contract: if you click "Hot mashed potatoes," you should get a page named "Hot mashed potatoes"

"You are here"

A "You are here" indicator shows users where they are in the scheme of things. On the Web, this is accomplished by highlighting the current location in navigational bars, lists, or menus. The most common failing is that indicators are too subtle; they need to stand out, ideally using more than one visual distinction (e.g., different color and bold text).

Breadcrumbs

Breadcrumbs show users where they are by displaying the path from the Home page to the current location. Unlike "You are here" indicators that show position in context of the hierarchy, Breadcrumbs only show the path taken. They're reminiscent of the trail of crumbs Hansel dropped in the woods.

🔑 Definition — Breadcrumbs: Navigation elements that show the path from the Home page to the current page, helping users understand where they are and how they got there.

⭐ Key Takeaways

Navigation is critical for Web sites because users lack the physical cues they rely on in real-world spaces (sense of scale, direction, and location). Persistent navigation should include Site ID, Sections, and Utilities, appearing consistently on every page except Home pages and forms. Every page needs a clear, prominent name that matches what users clicked, and "You are here" indicators must be sufficiently obvious to be useful. Lower-level navigation deserves as much attention as top-level navigation since users spend significant time there.

🧠 Quick Revision Questions

1. What are the three "senses" that Web users lack compared to navigating physical spaces?
2. What are the five elements that persistent navigation should include?
3. What are the two exceptions to using persistent navigation on every page?
4. Why is it important that page names match what users click on?
5. What is the difference between a "You are here" indicator and Breadcrumbs?

📘 Lecture 33 — Evaluation V

📖 Overview: This lecture focuses on evaluating web navigation through two specific lenses: the effective use of tabs as a navigation device and the "trunk test" for assessing how well a page communicates its context. It explains why tabs work so well, using Amazon as a case study, and provides a practical, quick method for evaluating whether a web page answers the essential questions a lost user would have.

🗂️ Topics Covered

The lecture begins by outlining four key reasons to use tabs for site navigation, highlighting their self-evident nature and visual distinctiveness. It then provides a detailed analysis of Amazon's implementation of tabs, focusing on four critical attributes: correct drawing, fast loading, color coding, and having a tab selected on entry. Finally, it introduces the "trunk test," a quick method where a user is dropped onto a random page and must be able to instantly identify the site, page name, sections, local navigation, location, and search function.

📝 Lecture Summary

Four reasons to use tabs

Tabs are a rare example of a physical metaphor that works well in a user interface. They divide content into sections and make it easy to navigate by clicking on the tab. The lecture gives four reasons why tabs are an excellent navigation choice for large sites. First, they are self-evident; even the most "computer illiterate" user understands their function. Second, they are hard to miss, as they are visually distinctive and unlikely to be overlooked like a button bar. Third, they are slick, adding polish and visual interest without significantly increasing page load times if implemented correctly. Fourth, they suggest a physical space, creating the illusion that the active tab is in front of the others, which provides a strong visual cue about the current section.

💡 Why this matters: Effective navigation is critical for user experience. Tabs leverage a familiar real-world metaphor to make large, complex websites feel more manageable and intuitive.

Why Amazon is good?

Amazon is presented as the gold standard for tab implementation. The lecture identifies four key attributes of Amazon's tabs to imitate. First, they’re drawn correctly, meaning the active tab must visually appear "in front of" the others by using a different color or contrasting shade and physically connecting with the content below. Second, they load fast, using only two graphics per page, totaling less than 6k, which avoids the longer initial load times and "crazy-quilt" effect caused by using separate graphics for each tab. Third, they’re color coded, where each section uses a distinct color that is also used in other navigational elements, although the lecture warns that color should never be the only cue due to color-blindness and a general lack of awareness of color coding in a significant percentage of users. Fourth, there's a tab selected when you enter the site, which ensures the impact of the tabs is felt from the very first second, though this can create a dilemma when a site's identity evolves (e.g., Amazon creating a "Welcome" tab to move beyond being just a bookstore).

🔑 Definition — Color Coding: The use of different colors for different sections of a website to help users visually distinguish between them. It is an additional cue and should not be the only differentiator.

📐 Formula: Effective Tabs = Correct Drawing (active tab in front) + Fast Loading (minimal graphics) + Color Coding (as a secondary cue) + Active Tab on Entry

📌 Example: Amazon uses a single row of tabs. Each tab (e.g., Books, Electronics) has a distinct color. The active tab is drawn in a contrasting shade and connects to the content below. When a user lands on the Amazon home page, the "Welcome" tab is selected.

Here's how you perform the trunk test:

The trunk test is a quick acid test for good web navigation. The scenario is that you are blindfolded, locked in a trunk, driven around, and dumped on a random page deep in a website. The test is whether you can instantly answer six questions: (1) What site is this? (Site ID), (2) What page am I on? (Page name), (3) What are the major sections? (Sections), (4) What are my options at this level? (Local navigation), (5) Where am I? ("You are here" indicators), and (6) How can I search? The procedure is to print a random page, squint to see only the overall appearance, and quickly try to find and circle each of these six items. The test emphasizes that users often enter a site from a search engine link, not the home page, so the page must be self-explanatory at a glance.

🔑 Definition — Trunk Test: A usability evaluation method where you test if a web page instantly and clearly communicates the site identity, the user's current page, the major sections, local navigation options, the user's location within the site, and search functionality.

💡 Why this matters: The trunk test addresses the reality of web use, where users are often "dumped" onto a page without context. A well-designed page should not require close scrutiny to be understood.

33.1 Try the trunk test

The lecture provides a visual example of the trunk test using a sample website. It demonstrates how to circle each element on the page. The Site ID is typically a logo or brand name at the top-left. The Page Name is usually the title of the current page. Sections and subsections are the main navigation categories, such as tabs. Local Navigation refers to links that are specific to the current section. A "You are here" indicator shows the user's current location, often by highlighting the active tab or using a breadcrumb trail. Finally, the Search function is a utility that should be easy to find.

📌 Example: In the sample website provided, the Site ID is the company logo. The Page Name is "Home". The Sections are represented by tabs (e.g., Home, About, Services). The Local Navigation would be links within the "Home" section. The "You are here" indicator is shown by the "Home" tab having the same background color as the page content. The Search utility is a text box located at the top right of the page.

⭐ Key Takeaways

Tabs are an exceptionally effective navigation tool because they are self-evident, visually distinctive, and create a strong sense of physical space. A successful tab implementation, as exemplified by Amazon, requires the active tab to visually appear in front, fast loading via minimal graphics, and the use of a tab selected upon entering the site. Color coding of tabs is helpful but must be supplemented with other cues to account for color-blindness and users who do not notice color differences. The trunk test is a crucial evaluation method that simulates the common user experience of arriving on a deep page from a search engine, demanding that a page's core navigation elements be instantly identifiable at a glance without close scrutiny.

🧠 Quick Revision Questions

1. What are the four specific reasons given in the lecture for why tabs are an excellent navigation choice for large websites?
2. Describe the visual illusion that must be created for tabs to work effectively. What are the two key graphic requirements for the active tab to create this illusion?
3. According to the lecture, what is the main problem with using a separate graphic for each tab or button on a navigation bar?
4. What is the "trunk test" and what are the six questions it is designed to answer about any given web page?
5. Why does the lecture recommend squinting or holding a printed page at arm's length when performing the trunk test?

📘 Lecture 34 — Evaluation – Part VI

📖 Overview: This lecture focuses on performing heuristic evaluations to identify usability issues in a web interface. Through a practical example, it demonstrates how to systematically detect common design problems by applying usability heuristics, covering issues related to readability, navigation, content clarity, and user expectations.

🗂️ Topics Covered

The lecture walks through a heuristic evaluation of a website, identifying specific usability problems such as unclear fonts, dim colors, misleading browser titles, excessive banner ads, improper use of highlighted tabs, confusing breadcrumbs, deceptive “sign up” links, and horizontal scrolling. Each issue is tied to a usability heuristic and explained with visual annotations from the site.

📝 Lecture Summary

Identifying Usability Issues Using Heuristics

The lecture presents a practical heuristic evaluation case study. A website is examined for common usability violations. Each issue is identified with a screenshot annotation, linking the visual problem to a specific heuristic principle. The examples cover readability, navigation, content labeling, and page layout.

Clear and readable fonts not being used

The site uses fonts that are not clear or readable. This violates the heuristic of consistency and standards or aesthetic and minimalist design. Dim color further reduces readability, making text hard to see.

🔑 Definition — Heuristic Evaluation: A usability inspection method where experts review an interface against a set of usability principles (heuristics) to identify potential problems.

Browser Title always contains the word ‘Home’

Every browser title on the site includes the word “Home,” which is misleading. Different pages should have unique, descriptive titles. This confuses users and violates the heuristic of user control and freedom or match between system and the real world.

Banner ads take up too much space

Large banner ads dominate the page layout, pushing content aside. This violates aesthetic and minimalist design by cluttering the interface and distracting users from primary tasks.

Invalid browser title characters

The browser title contains invalid or special characters that may not display correctly in all browsers, reducing usability and accessibility.

Use of highlighted tabs in global navigation bar shows this is the ‘Home’ page

In one screenshot, a highlighted tab correctly indicates the current section (Home). However, absence of a highlighted tab in another view confuses the user about which section is being viewed. This violates the heuristic visibility of system status, as users need constant feedback about their location.

📌 Example: On one page, the “Home” tab is visually highlighted, clearly showing the user’s location. On another page, no tab is highlighted, leaving the user uncertain which section they are in.

Version numbers should not be given on the main page

Displaying version numbers (e.g., “v2.1”) on the main page is irrelevant to most users and adds unnecessary clutter. This violates aesthetic and minimalist design — only information relevant to the user’s task should be visible.

Breadcrumbs format do not follow standard conventions

The site’s breadcrumb trail uses an unusual format, confusing users who expect standard separators (e.g., “>” or “/”). This violates consistency and standards, as users rely on learned conventions to navigate.

‘Sign up now’ link appears to refer to free report...

The text “Sign up now” suggests a free offer (e.g., a free report), but the link actually takes the user to the online store. This violates consistency and standards and user control and freedom — the link label does not match its destination, misleading the user.

💡 Why this matters: Misleading links break the trust between the user and the system. If a user expects one action and gets another, they may feel tricked, increasing frustration and abandonment rates.

The page has horizontal scrolling

The page requires horizontal scrolling to view all content. This is a severe usability issue because it breaks the standard vertical scrolling pattern, forcing users to scroll in two dimensions. It violates flexibility and efficiency of use and aesthetic and minimalist design — users expect content to fit within the viewport width.

⭐ Key Takeaways

This lecture demonstrates that heuristic evaluation is a powerful, low-cost method for catching usability problems before user testing. Key violations to remember include: misleading or absent navigation cues (like highlighted tabs and breadcrumbs), deceptive link labels that mismatch destinations, irrelevant content (like version numbers), and layout problems (like horizontal scrolling). Every evaluation should check for consistency, clarity, feedback, and user expectations. These heuristics apply broadly across all digital interfaces.

🧠 Quick Revision Questions

1. What is the purpose of a highlighted tab in a global navigation bar, and what problem arises when it is missing?
2. Why is displaying a version number on a website’s main page considered a usability issue?
3. How does a misleading link label (e.g., “Sign up now” leading to an online store) violate usability heuristics?
4. What two specific heuristics are violated when a page requires horizontal scrolling?
5. List three examples of heuristic violations identified in this lecture that relate to the principle of consistency and standards.

📘 Lecture 35 — Evaluation – Part VII

📖 Overview: This lecture explores the strategic nature of usability by examining key questions about users, technology, medium, and commitment. It then delves deeply into the unique nature of the Web as a super-medium, introducing a five-plane conceptual framework (Strategy, Scope, Structure, Skeleton, Surface) for understanding user experience and the tools used to solve design problems.

🗂️ Topics Covered

The lecture begins by establishing the relationship between evaluation and usability, posing critical questions about understanding users, technology, the medium, and organizational commitment. It then defines the Web as a super-medium combining print, video, audio, and software. The core of the lecture introduces a five-plane model (Surface, Skeleton, Structure, Scope, Strategy) built from bottom to top, and explores the historical duality of the Web as both an application and a hypertext information space. Finally, it maps the elements of user experience onto each plane, detailing functional specifications, content requirements, interaction design, information architecture, interface design, navigation design, and visual design.

📝 Lecture Summary

35.1 The relationship between evaluation and usability?

Evaluation helps uncover problems in the interface that improve the usability of the product. To achieve this, several fundamental questions must be asked: Do you understand the users? Do you understand the medium? Do you understand the technologies? Do you have commitment?

Regarding Technologies, you must understand the constraints of technology, what can be implemented using current technologies, and that building a good system requires a good understanding of technology constraints and potentials. For Users, you must know your users, their goals and behaviors, how they can be satisfied, and use goals and personas. Commitment involves ensuring that building usable systems has commitment at every level in your organization. Finally, for the Medium, you must understand the medium you are working in to build a good usable system.

Nature of the Web Medium

The World Wide Web is a combination of many different mediums of communication. It is a super medium which incorporates all of the following media: Print (newspapers, magazines, books), Video (TV, movies), Audio (radio, CDs, etc.), and Traditional software applications. Because of its very diverse nature, the Web is a unique medium and presents many challenges for its designers.

We can more clearly understand the nature of the Web by looking at a conceptual framework consisting of five planes.

The Surface Plane On the surface you see a series of Web pages, made up of images and text. Some of these images are things you can click on, performing some sort of function such as taking you to a shopping cart. Some of these images are just illustrations, such as a photograph of a book cover or the logo of the site itself.

The Skeleton Plane Beneath that surface is the skeleton of the site: the placement of buttons, tabs, photos, and blocks of text. The skeleton is designed to optimize the arrangement of these elements for maximum effect and efficiency—so that you remember the logo and can find that shopping cart button when you need it.

The Structure Plane The skeleton is a concrete expression of the more abstract structure of the site. The skeleton might define the placement of the interface elements on our checkout page; the structure would define how users got to that page and where they could go when they were finished there. The skeleton might define the arrangement of navigational items allowing the users to browse categories of books; the structure would define what those categories actually were.

The Scope Plane The structure defines the way in which the various features and functions of the site fit together. Just what those features and functions are constitutes the scope of the site. Some sites that sell books offer a feature that enables users to save previously used addresses. The question of whether that feature—or any feature—is included on a site is a question of scope.

The Strategy Plane The scope is fundamentally determined by the strategy of the site. This strategy incorporates not only what the people running the site want to get out of it but what the users want to get out of the site as well. In the case of our bookstore example, users want to buy books, and we want to sell them.

Building from Bottom to Top These five planes—strategy, scope, structure, skeleton, and surface—provide a conceptual framework for talking about user experience problems and the tools we use to solve them. When the Web started, it was just about hypertext. Tim Berners-Lee created it as a way for researchers to share and refer to each other's findings. People originally seized on the Web as a new publishing medium, but as technology advanced, the Web took on new capabilities, becoming more interactive and responding to user input like traditional desktop applications.

When the Web user experience community started to form, its members spoke two different languages. One group saw every problem as an application design problem. The other group saw the Web in terms of information distribution and retrieval. To address this basic duality, let's split our five planes down the middle. On the left, we'll put those elements specific to using the Web as a software interface, mainly concerned with tasks. On the right, we'll put the elements specific to hypertext information spaces, where our concern is information.

The Elements of User Experience Now we can map the whole confusing array of terms into the model.

The Strategy Plane: The same strategic concerns come into play for both software products and information spaces. User needs are the goals for the site from outside our organization. Balanced against user needs are our own site objectives (e.g., business goals like "Make $1 million in sales").

The Scope Plane: On the software side, strategy is translated into scope through functional specifications (a description of the "feature set"). On the information space side, scope takes the form of content requirements (a description of various content elements).

The Structure Plane: Scope is given structure on the software side through interaction design (defining how the system behaves in response to the user). For information spaces, the structure is information architecture (the arrangement of content elements).

The Skeleton Plane: The skeleton plane breaks down into three components. On both sides, we must address information design (presenting information to facilitate understanding). For software products, the skeleton includes interface design (arranging elements to interact with functionality). The interface for an information space is its navigation design (screen elements allowing users to move through the information architecture).

The Surface Plane: Regardless of whether we are dealing with a software product or an information space, our concern is the same: visual design, or the look of the finished product.

Using the Elements: Few sites fall exclusively on one side of this model. Within each plane, the elements must work together. For example, information design, navigation design, and interface design jointly define the skeleton of a site. In reality, the lines between these areas are not clearly drawn. A couple of additional factors go into shaping the final user experience, most importantly content—the single most important thing most Web sites can offer.

⭐ Key Takeaways

The lecture establishes that strategic usability requires a deep understanding of users, technologies, the medium, and organizational commitment. The Web is a unique super-medium that combines print, video, audio, and software applications, presenting distinct design challenges. The five-plane model (strategy, scope, structure, skeleton, surface) provides a comprehensive framework for analyzing user experience from abstract goals down to concrete visual design. A critical duality exists in Web design between the software/application perspective (focused on tasks) and the hypertext/information perspective (focused on information), which maps to different elements on each plane like functional specifications vs. content requirements and interaction design vs. information architecture. Ultimately, all elements on all planes must work together cohesively, with content being the most crucial factor for most Web sites.

🧠 Quick Revision Questions

1. What are the four key areas of understanding required for strategic usability?
2. What four media does the Web incorporate as a "super medium"?
3. List the five planes of the conceptual framework for user experience, from top to bottom.
4. What is the difference between the software side (tasks) and the hypertext side (information) of the Web duality?
5. On the skeleton plane, what are the three components that must work together, and how do interface design and navigation design differ?

📘 Lecture 36 — Behavior & Form – Part IV

📖 Overview: This lecture explores the complexities of the undo function in user interfaces, moving beyond a simple "mistake reversal" tool to consider it as a primary support for user exploration and confidence. It also critically examines the file and save paradigm, arguing that the implementation model of file systems creates significant confusion for users and proposes a unified file model aligned with the user's mental model.

🗂️ Topics Covered

The lecture begins by redefining the purpose of undo from a user-centered perspective, emphasizing its role in exploration. It then categorizes different types of undo, including incremental vs. procedural, blind vs. explanatory, and single vs. multiple undo, detailing their respective advantages and limitations. The discussion extends to other undo-like behaviors such as group multiple undo, comparison tools, category-specific undo, and milestoning. The second half of the lecture shifts focus to the file system, identifying problems with the implementation model, including the "Save Changes?" dialog and the "Save As" function, before outlining a design for a unified file presentation model.

📝 Lecture Summary

36.1 Understanding undo

Undo is a remarkable facility that lets users reverse a previous action. From a computational standpoint, undo has no merit as computers make no mistakes. However, humans make mistakes as a part of everyday behavior, making undo a facility for their exclusive use. The design of undo should be modeled most like the user's mental model, not the computer's implementation model. Users don't typically include error in their mental model, so software should absolve the user of blame and treat all user actions as valid.

Undo is critically important for supporting exploration. When users experiment with a tool, they inevitably probe into dead ends. Undo acts as a "rope ladder," providing psychological reassurance that they can always return to a safe state. This encourages further exploration, as users are more willing to try new things if they know they can easily reverse their actions. Undo is primarily a tool for supporting exploration, not just for reversing errors.

🔑 Definition — Undo: A facility that allows a user to reverse a previous action, supporting exploration and recovery from mistakes. 💡 Why this matters: Viewing undo as an exploration tool rather than an error-recovery tool fundamentally changes its design, making it more forgiving and encouraging user experimentation.

36.2 Types and Variants of Undo

The software industry lacks adequate terminology for the different types of undo, which contributes to a lack of innovation. This section defines several distinct undo variants to clarify their behaviors.

36.3 Incremental and procedural actions

All user actions have a procedure component (what the user did) and an optional data component (what information was affected). Actions with a data component—such as cutting, pasting, typing, and deleting—are called incremental actions. Undoing them involves removing or replacing the affected data. Actions that are data-free transformations—such as paragraph reformatting or rotation—are called procedural actions. Most existing undo functions do not discriminate between these two types.

Blind undo is invoked by a menu or toolbar control with an unchanging label or icon. The user knows it undoes the last operation but has no indication of what that operation was. Explanatory undo, by contrast, includes a textual or visual description of the particular operation that will be undone. For example, if the user last typed "design," the menu says "Undo Typing design." Explanatory undo is generally a much more pleasant feature.

🔑 Definition — Incremental Actions: User actions that include a data component (e.g., typing, deleting, cutting). 🔑 Definition — Procedural Actions: User actions that are data-free transformations with only a procedure component (e.g., reformatting a paragraph, rotating an image). 🔑 Definition — Blind Undo: An undo function that reverses the last operation without indicating what that operation was. 🔑 Definition — Explanatory Undo: An undo function that includes a textual or visual description of the operation to be undone.

36.4 Single and multiple undo

Single undo is the most basic variant, reversing the effects of the most recent user action. Performing a single undo twice usually undoes the undo, bringing the system back to its previous state. This is very effective because it is simple to operate. The biggest limitation is when the user accidentally short-circuits the capability. For example, if a user deletes six paragraphs, then deletes one word, performing undo only brings back the one word, and the six paragraphs are lost forever. The program acted literally, not practically.

Multiple undo can be performed repeatedly in succession to revert more than one previous operation in reverse temporal order. The program maintains a stack of operations. In the scenario above, the user can restore the deleted word with the first undo and the six paragraphs with a second invocation. However, multiple undo also has limitations. It operates in a strict LIFO (Last In, First Out) order. If a user performs several interlaced functions, only some of which are undesirable, they must undo all intervening actions, even valid ones, to reach the desired point. The model models code and data structures instead of user goals.

🔑 Definition — Single Undo: An undo that reverses only the most recent user action. Performing it twice typically toggles the action. 🔑 Definition — Multiple Undo: An undo that can reverse a sequence of actions in reverse chronological order, typically using a LIFO stack. 📐 Formula: LIFO (Last In, First Out) → The last action performed is the first to be undone. Redo is a function that resulted from the implementation model of undo, allowing the user to "undo the undo." It avoids the problem of clicking Undo one time too many. Group multiple undo, as seen in Microsoft Word, is a variation where the user can see a list of past operations and select one to undo. However, this undoes all operations back to that point, not just the selected one.

36.5 Other Models for Undo-Like Behavior

The simple single undo conforms to the user's mental model, but it diverges as complexity grows. This section discusses alternatives.

Comparison: What would this look like? The paired undo-redo function can serve as a convenient comparison tool, allowing the user to toggle back and forth between two states to see the visual effect of a change. This is akin to a "Jump" button on a TV remote, which switches between the current and previous channel.

Category-specific Undo targets a specific class of operation. The Backspace key is a prime example, acting as an incremental undo that only reverses the last characters typed, ignoring other, intervening functions. Using this model, one could create format-undo, pigment-undo, or transformation-undo functions that only undo actions within their specific category.

Deleted data buffers provide a repository of all deleted text or data, independent of the procedural stack. The user can open this buffer as a document and browse it to recover desired data, rather than having to reverse complex sequences of commands.

Milestoning involves making a copy or "snapshot" of the entire document at a specific point in time. The user can then make experimental changes and later revert to any saved milestone. A reversion facility would allow the user to load any saved version.

Freezing is the opposite of milestoning. It locks specific data in a document so it cannot be changed, while allowing new data to be added.

Undo Proof Operations are actions that cannot be undone because they trigger a device not under the program's control (e.g., sending an email, turning off the computer). However, many operations masquerade as undo-proof, like saving a file under a new name. A filename undo is rarely provided, even though it is technically feasible.

🔑 Definition — Milestoning: A function that saves a copy of the entire document, like a snapshot, that the user can later revert to. 🔑 Definition — Freezing: Locking specific data in a document so it cannot be changed, while allowing new data to be added.

36.6 Rethinking Files and Save

The file system is the most difficult part of modern computers for users to understand. The "Do you want to save changes?" dialog box is a primary source of confusion.

What's Wrong with Saving Changes to Files? Every program exists in two places: in memory and on disk. The "Save Changes?" dialog appears when closing a document because the program must reconcile the difference between the two copies. From the user's mental model, they are simply putting their document away, and the question is absurd. The program asks about saving changes at the end of the work, not when the changes were made, which is disconnected from the user's workflow.

Problems with the Implementation Model The file system is an internal facility that shouldn't affect the user, but its influence pervades the interface, affecting menus, dialogs, and program structure. Most software treats the file system as the operating system shell does, forcing users to think like mechanics.

Closing and unwanted changes Experienced users use the "Save Changes?" dialog to abandon unwanted changes by choosing "No." However, the proper time to reject changes is when they are made, using the Undo function.

Save As This dialog forces users to understand the file system intimately, including file names and directory navigation. Many users give up on directories. The dialog also has inconsistencies; it allows renaming other files but not the one being worked on, and trying to rename an open file in Explorer results in a confusing "sharing violation" error message.

36.7 Archiving

There is no explicit function for making a copy of a document. Users must use "Save As," which leads to dangerous traps. If a user edits a document "Alpha" and uses "Save As" to make an archival copy as "New Alpha," the program saves the old version of "Alpha" (without recent edits) to disk and leaves the user editing "New Alpha" with all the recent changes. The user mistakenly believes their work is backed up, but it is not.

📌 Example: A user edits "Alpha" for 20 minutes, then uses "Save As" to create "New Alpha." The program saves the original "Alpha" (without the 20 minutes of changes) to disk. All the recent changes are in "New Alpha," the only copy in memory. The user has no backup.

36.8 Implementation Model versus Mental Model

The file system's implementation model violates the user's mental model in two key ways: First, users imagine there is only one document, but there are always two (on disk and in memory). Second, users feel the document belongs to them, but the program treats it as its own. The user's mental model is like a journal that comes off the shelf, gets edited, and then is put back. The computer makes a copy of the journal, edits the copy, and then asks if the original should be replaced.

36.9 Dispensing with the Implementation Model of the File System

The solution is not to get rid of the file system, but to hide its existence from the user. The user interface should present a unified model of a single document. This would remove confusing dialogs and allow interface designers to structure commands according to user goals, not the needs of the operating system. This would significantly lower the barrier for new users.

36.10 Designing a Unified File Presentation Model

Properly designed software should treat documents as single instances, not as a copy on disk and a copy in memory: a unified file model. It is the file system's job to manage the second copy on disk, but the application software should conspire to hide this from the user. If a file is in use, the file system could indicate this visually (e.g., with a red filename or a special symbol) rather than causing a confusing error message. The software should also help the user understand non-intuitive actions, like how a program can still appear in the Start menu even after it has been launched.

⭐ Key Takeaways

1. Undo is an exploration tool, not just an error recovery tool. Design it to reassure users and encourage experimentation, making them feel safe to probe the unknown.
2. Single undo is simple but limited; it fails when users don't notice a mistake until after several subsequent actions. Multiple undo (LIFO) solves this but forces users to reverse all intervening actions, even valid ones, which can be painful.
3. The file system is the greatest source of user confusion. The implementation model (two copies of every file) violates the user's mental model (one single document). This leads to perplexing dialogs like "Do you want to save changes?" and dangerous traps.
4. The "Save As" dialog is a poor tool for archiving. It should not be the primary way to make a copy of a document. A dedicated "Milestone" or "Archive" function would be far more intuitive and safe.
5. The goal is a unified file model where the software hides the duality of disk/memory storage from the user, treating the document as a single instance. This makes software far more accessible to non-technical users.

🧠 Quick Revision Questions

1. Why is it important to design undo from the user's mental model rather than the implementation model?
2. Explain the primary limitation of single undo. Give a specific example of when it would fail a user.
3. What is a "deleted data buffer," and how does it solve a problem that multiple undo (LIFO) cannot?
4. According to the lecture, what is the fundamental problem with the "Do you want to save changes?" dialog box from a user's perspective?
5. What is the key design principle for a "unified file presentation model"?

📘 Lecture 37 — Behavior & Form - Part V

📖 Overview: This lecture explores how to redesign software interfaces to be more considerate and intelligent, moving beyond traditional file management paradigms. It introduces unified document management, considerate software design principles, and smart software that uses memory to anticipate user needs, fundamentally shifting how we think about human-computer interaction.

🗂️ Topics Covered

The lecture covers unified document management as an alternative to traditional file dialogs, including automatic saving, snapshot copies, milestoning, renaming, and format specification. It then explores the concept of considerate software with twelve key characteristics, followed by smart software techniques that leverage idle processor cycles and task coherence through memory systems that remember user patterns, choices, and behaviors across sessions.

📝 Lecture Summary

37.1 Unified Document Management

The established standard suite of file management consisting of the Save As dialog, Save Changes dialog, and Open File dialog is confusing for some tasks and incapable for others. A different approach manages documents according to the user's mental model, rendering the document as a single entity with goal-directed functions.

Automatically saving the document abolishes all user interface recognition of the two copies (memory and disk), so the Save function disappears completely from the mainstream interface. The program should automatically save when the user closes, writing changes to disk without asking for confirmation. To prevent data loss from crashes, the program should save during the session — ideally after each keystroke, though word processors may save when the user pauses typing rather than using a countdown clock that interrupts work. Manual save controls (like Ctrl+S) should remain for paranoid users, but not be prominently forced on all users.

Creating a copy should be an explicit function called Snapshot Copy, making it clear the copy is identical to and not tied to the original. The new copy should automatically be named "Copy of Alpha" (or "Second Copy of Alpha" if that name exists) and placed in the same directory without any dialog box interruption.

Naming and renaming should be simple: the document name appears on the application's title bar, and users can click and edit it in place.

Placing and moving documents: Most edited documents already exist and have established positions. New files should be put somewhere reasonable automatically. If users want to explicitly place a document, they can request a function from the menu — a relative of the Save As dialog appears with the current document highlighted for moving.

Specifying stored format should not be tied to the Save function, as this adds unnecessary complexity to a common operation. Physical format (rich text, ASCII, Word format) is a characteristic of the document, not the disk file. It belongs in a Document Properties dialog, with significant cautions built in. For drawing programs, an Export dialog is appropriate.

Reversing changes should use the undo tool, not the file system as a surrogate for undo. The concept of going directly to the file system to undo changes undermines the undo function.

Abandoning all changes should be explicitly supported via an Abandon Changes function on the main menu, with clear warning signs since it involves significant data loss. Making this function undoable is highly desirable.

💡 Why this matters: These redesigns eliminate confusion by matching the user's mental model rather than the implementation model of separate disk and memory copies.

37.2 Creating a Milestone Copy of the Document

Milestoning is similar to the Copy command, but the copy is managed by the application after it is made. A Milestone dialog box lists each milestone with statistics like time recorded and length. With a click, the user can select a milestone as the active document; the current document becomes milestoned itself (e.g., "Milestone of Alpha 12/17/03, 1:53 PM"). Milestoning is a lightweight form of versioning.

A new File menu would include: New and Open as before; Close closes without dialog after automatic save; Rename/Move lets users rename or move files; Make Snapshot Copy creates a copy; Print collects all printer controls; Make Milestone creates managed copies via a dialog summoned by Revert to Milestone; Abandon Changes discards all changes; Document Properties lets users change physical format; Exit closes document and application.

A new name for the File menu is needed since we present a unified storage model. Two alternatives: label the menu after the document type (e.g., "Sheet" for spreadsheets, "Invoice" for invoicing programs) or use a generic label like "Document." Programs that represent disk contents as files (operating system shells and utilities) should keep "File" since they address files as files.

37.3 Are Disks and Files Systems a Feature?

From the user's point of view, there is no reason for disks to exist. From the hardware engineer's perspective, three reasons exist: disks are cheaper than solid-state memory, they retain data when power is off, and they provide physical means of moving information. However, non-volatile RAM and networks can serve the latter two purposes. Cost is the real reason disks exist.

Disk drives have many drawbacks: much slower than RAM, less reliable due to moving parts, consume more power, take up more space, and the CPU cannot directly read/write to them — data must first be brought into solid-state memory. This makes processing with disks orders of magnitude slower and more complex than working with RAM. Disks make computers weaker, slower, and more complex — a compromise dilution of solid-state architecture. Wherever disk technology has left its mark on software design, it has done so for implementation purposes only, not in service of users.

37.4 Time for Change

Two arguments favor the file system model: "our software is already designed that way" and "users are used to it." Neither is valid. New programs with a unified file model can coexist with older implementation model applications, much like toolbars invaded interfaces. The second argument is more insidious — users may reject new solutions because they abhor change, but users are not always the best predictors of design successes. The Chrysler minivan example shows that the public initially rejected a superior design that later became hugely successful. Users cannot be expected to visualize interaction paradigm shifts, but the market shows people will gladly give up painful software for better alternatives.

37.5 Making Software Considerate

Research by sociologists Clifford Nass and Byron Reeves discovered that humans instinctively treat interactive artifacts as sentient beings — our reaction to software as sentient is both unconscious and unavoidable. The implication: if we want users to like our software, we should design it to behave like a likeable person; if we want productivity, design it to behave like a supportive human colleague.

Designing Considerate Software: Nass and Reeves suggest politeness, but considerate is preferred — putting the needs of others first. Considerate software has users' goals and needs as its primary concern beyond basic functions. If software is stingy with information, obscures its process, forces hunting for common functions, and blames users for its own failings, users will dislike it regardless of visual appeal.

What Makes Software Considerate? Twelve characteristics:

Considerate software takes an interest: It remembers likes and dislikes to please users in the future. Most software doesn't know or care who is using it, remembering nothing about us despite constant use. Software should remember work habits and everything users tell it.

Considerate software is deferential: It defers to the client — the user is the boss. Software can suggest an action and explain consequences, but if users wish to proceed, software should do as told. (The word "Submit" is a reversal of this deferential role.)

Considerate software is forthcoming: It volunteers useful collateral information beyond answering precise questions. When we tell a word processor to print, it should tell us when paper is low or other documents are queued.

Considerate software uses common sense: It doesn't place controls for constantly used functions adjacent to never-used or dangerous functions.

Considerate software anticipates needs: Like a human assistant who reserves a hotel room without being asked, software should anticipate needs. A web browser could preload visible links while users read.

Considerate software is conscientious: It has a larger perspective on task performance — like washing dishes and also wiping counters and emptying trash, a conscientious program does related tasks.

Considerate software doesn't burden you with its personal problems: Software should keep quiet about its problems and show interest in ours. It whines with error messages, interrupts with confirmation dialogs, and brags with unnecessary notifiers. Software should have the intelligence to fix its problems on its own.

Considerate software keeps us informed: While not pestering, it provides modeless feedback about what matters to us.

Considerate software is perceptive: It observes user patterns and offers relevant information. If a user asks about widgets once, it's a clue they want to know again. Software should watch preferences and remember them without being asked.

Considerate software is self-confident: It stands by its convictions — if told to discard a file, it shouldn't ask "Are you sure?" Instead, it should anticipate changes of mind by being prepared to undelete.

Considerate software doesn't ask a lot of questions: Excessive choices become an ordeal. Choices should be offered like window shopping (peering at leisure) rather than interrogation.

Considerate software fails gracefully: When discovering a fatal problem, it should prepare for failure without hurting the user — tidying up affairs, preserving data in recoverable format — rather than crashing and taking work with it.

Considerate software knows when to bend the rules: Fudgeability is the characteristic of manual systems that lets humans perform actions out of sequence or before prerequisites are satisfied. It's one of the first casualties when systems are computerized. By allowing small temporary mistakes and trusting humans to correct them, we avoid bigger permanent mistakes. Inflexible rules cast human and software as adversaries.

Considerate software takes responsibility: Too much software takes the attitude "It isn't my responsibility," passing jobs along without follow-through. In a typical print operation, when the user cancels but the printer continues printing buffered pages, the software lies by saying the function was canceled while pages still print.

37.6 Considerate Software Is Possible

Software irritates us because it isn't considerate, not because it lacks features. Considerate software is usually no harder to build than rude software — it simply requires envisioning interaction that emulates sensitive and caring friendship. None of these characteristics conflict with pragmatic business computing goals; behaving more humanely can be the most pragmatic goal of all.

37.7 Making Software Smarts

Programmers optimize code for the CPU's single-file instruction processing, keeping instructions minimal for snappy performance. However, once the CPU finishes work, it waits idle until the user issues another command. We invest enormous efforts in reducing reaction time but little in putting the computer to work proactively when not busy. The division of labor is clear: the computer does the work, the user does the thinking. Users don't need help thinking — they need help with information management work. Smart software means programs capable of working hard even under difficult conditions and when the user isn't busy.

37.8 Putting the Idle Cycles to Work

Users must remember too many things (file names, locations) while the processor wastes billions of cycles waiting. Most software takes no notice of context — offering the same help whether the user is struggling on a tight deadline or noodling casually. Most users can't do anything in less than a few seconds — enough time for a desktop computer to execute at least a billion instructions. With pre-emptive threaded multitasking, programs can perform extra work in the background without affecting performance. Every time a program puts up a modal dialog box, it goes into an idle waiting state — this should never happen. We need a more proactive way of thinking about how software can help with goals and tasks.

37.9 Giving Software a Memory

Memory here means a program facility for tracking and responding to user actions over multiple sessions — not RAM. If a program remembers what the user did last time and how, it can use that remembered behavior as a guide. This is one of the most effective tools for designing software behavior. Continually interrogating users is not only excise but subtly expresses doubt about their authority. Most software is forgetful, remembering little from execution to execution, and when it retains information, it's usually for the programmer's convenience, not the user's.

37.10 Task Coherence

Task coherence is the principle that our goals and how we achieve them through tasks is generally the same from day to day. When a consumer uses a product, the functions they use and how they use them will be very similar to what they did last time — working on the same or similar documents in similar places. With significant reliability, you can predict user behavior by remembering what they did the last several times they used the program.

Remembering choices and defaults: If it's worth the user entering, it's worth the program remembering. Instead of hard-wired defaults, the program should use the previous setting as the default. Options should remain in effect until manually changed. If users ignored facilities or turned them off, they should not be offered again.

Remembering file locations: Programs must remember more than just the last place files were accessed — they must remember the last place files of each type were accessed. Window positions should also be remembered.

Remembering patterns: Memory reduces excise — useless effort devoted to managing the tool rather than doing work. A significant portion of excise involves explaining things to the program it should already know. If the program noticed patterns (like repeated two-step formatting operations), it could automatically create new format styles or toolbar controls.

🔑 Definition — Task Coherence: The principle that user goals and task achievement methods are generally the same from day to day, allowing prediction of future behavior by remembering past actions.

37.11 Actions to Remember

Everything users do should be remembered — there's plenty of storage, and memory is a good investment. If a word processor saved 1 KB of execution notes per run, 10 times daily for 200 workdays per year, the annual consumption is only 2 MB.

File locations: All file-open facilities should remember source directories and offer them on a combo box — users should never have to step through the tree to a directory more than once.

Deduced information: Software should also remember useful information deduced from facts. For example, tracking changed-byte-count per session: if the count suddenly jumps from ~100 to 5000, the program might keep a milestone copy before changes were made, just in case.

Multi-session undo: Programs should write the undo stack to a file, reloading it when the user reopens the document — even if it was a week ago.

Past data entries: Memory reduces errors by reducing manual entry. If the program remembers zip codes and city names, it can indicate uncertainty (yellow field) or ambiguity (pink field) when mismatches occur.

Foreign application activities on program files: Applications might leave a small thread running between invocations to track where files go and who reads/writes them, helping users find moved files and informing about other functions performed.

37.12 Applying Memory to Your Applications

When developers accept task coherence's power, their thinking takes on new quality. Instead of popping up dialog boxes, designers ask questions: How much should the program remember? Which aspects? Should it remember more than the last setting? What constitutes a pattern change?

Decision-set reduction: People tend to reduce infinite choices to a small, finite set. Even when not doing the exact same thing, users choose from a small repetitive set of options. Simply remembering the last action can fail if the decision set has two elements (user alternates between two directories). The solution: remember more than one previous choice. The program should look for subtle clues to differentiate from the small set — like remembering payees and amounts on an account-by-account basis for check writing.

Preference thresholds: Decisions fall into two categories: important and unimportant. Most decisions are insignificant. Software can use this to simplify tasks — after a user asks to print, we don't need to ask how many copies or orientation. Make assumptions the first time, remember them, and let users access options if they want changes.

Mostly right, most of the time: Task coherence predicts with reasonable (not absolute) certainty. If we can predict correctly 80% of the time, offering a choice would bother users with an unnecessary dialog 80% of the time. Instead, the program should do what it thinks appropriate and allow override or undo. If undo is sufficiently easy, users handle it only 2 times out of 10 instead of dealing with redundant dialogs 8 times out of 10.

🔑 Definition — Decision-Set Reduction: The human tendency to reduce an infinite set of choices to a small, finite set of regularly used options.

📐 Formula: Memory-based prediction = Task Coherence + Decision-Set Reduction + Preference Thresholds → "Mostly right, most of the time" without asking unnecessary questions

37.13 Memory Makes a Difference

One main reason software is difficult to use is that designers make rational, logical assumptions that are very wrong — assuming user behavior is random and unpredictable, requiring interrogation to determine the proper course. While human behavior isn't deterministic like digital computers, it's rarely random. Applying memory via task coherence yields great advantages in user efficiency and satisfaction. A program that makes effective use of memory becomes like a self-motivated assistant — remembering helpful information and personal preferences without needing to ask. Simple things make the difference between a tolerated product and one users love. The next time a program asks users a question, it should ask itself one instead.

⭐ Key Takeaways

Unified document management eliminates the confusing separation between memory and disk copies, replacing Save/Save As with automatic saving and explicit functions like Snapshot Copy, Milestone, and Abandon Changes that match the user's mental model. Considerate software should behave like a supportive human colleague — taking interest, being deferential, forthcoming, perceptive, self-confident, and knowing when to bend rules rather than interrogating users with questions. Smart software uses memory through task coherence to predict user behavior by remembering past actions, reducing excise and eliminating unnecessary dialog boxes. The principle of "mostly right, most of the time" means programs should act on predictions and allow easy undo rather than asking for confirmation. Applying memory to applications through decision-set reduction and preference thresholds transforms software from a tolerated tool into a beloved assistant.

🧠 Quick Revision Questions

1. What are the seven goal-directed functions in unified document management, and how does automatic saving differ from traditional Save functionality?
2. List and explain five characteristics of considerate software that directly reduce user frustration.
3. How does task coherence enable prediction of user behavior, and why is "mostly right, most of the time" better than asking questions?
4. What is fudgeability, and why is its absence in computerized systems a key contributor to inhumanity in digital systems?
5. How can a program apply decision-set reduction and preference thresholds to remember user patterns without needing to interrogate the user?

📘 Lecture 38 — Behavior & Form – Part VI

📖 Overview: This lecture explores the critical role of visual design in Human Computer Interaction, distinguishing it from visual art and explaining why many graphical user interfaces still fail despite their graphical nature. It introduces key principles of visual interface design to help create interfaces that are both aesthetically pleasing and functionally clear, emphasizing how to leverage human visual processing capabilities for better communication of software behavior.

🗂️ Topics Covered

The lecture begins by examining the difference between visual art and visual design, clarifying that designers create artifacts to meet others' goals rather than for self-expression. It then contrasts graphic design, visual interface design, and visual information design, each with distinct focuses. The core of the lecture details five principles of visual interface design: avoiding visual noise and clutter, using contrast and layering to organize elements, providing visual structure and flow, using cohesive imagery, and integrating style and function. Specific techniques like dimensional/tonal/spatial contrast, layering, figure-ground perception, and the squint test are explained in depth.

📝 Lecture Summary

38.1 Designing Look and Feel

Graphical User Interfaces (GUIs) are often considered superior to character-based interfaces, yet many GUIs remain difficult to use. This is because creating an effective GUI requires more than just graphics; it requires a deep understanding of visual design in the context of interaction. Visual design in interfaces is about finding the representation best suited to communicate specific information and the behavior of the software, not just about making things look pretty.

Visual Art versus Visual Design Practitioners of visual art produce artifacts to provoke an aesthetic response, serving as a means of self-expression on emotional or intellectual topics. Few constraints are imposed, and uniqueness is highly valued. In contrast, visual designers create artifacts to meet the goals of people other than themselves. They are "concerned with finding the representation best suited to the communication of some specific information." Visual interface designers specifically focus on communicating the behavior of the software they are designing.

💡 Why this matters: Understanding this core difference is foundational—a beautiful interface that is confusing to use is a failure of visual design, not a success of visual art.

Graphic Design and Visual Interface Design Graphic design historically focused on print media (packaging, advertising, documents). Digitally-fluent graphic designers excel at creating rich, clean, visually consistent, and aesthetically pleasing "surfaces" of an interface, including corporate branding. Their design priorities are first legibility and readability of information, then tone and style, and finally communicating behavior through affordances.

Visual interface designers share graphic design skills but focus more on the organizational aspects of the design and how affordances communicate behavior. They are more knowledgeable about principles of interaction, matching the visual structure of the interface to the logical structure of both the user's and the program's behavior. They are also concerned with communicating program states and cognitive issues like layout, grids, and figure-ground.

Visual information designers perform a similar role but for content and navigation, especially in Web design where content often outweighs function. Their primary focus is on controlling information hierarchy through visual language.

Industrial design plays a growing role in interactive products (handheld devices, appliances). Some industrial designers focus on the shape and "skins" of objects, while others focus on the logical and ergonomic mapping of physical controls to match user behaviors. As more physical artifacts become software-enabled, close collaboration between interaction, industrial, and visual designers is crucial.

38.2 Principles of Visual Interface Design

The human brain is a superb pattern-processing computer that makes sense of visual information by discerning visual patterns and establishing a system of priorities. Visual interface design must take advantage of our innate visual processing capabilities to help programs communicate their behavior and function. The key principles, based on the work of Kevin Mullet and Darrell Sano, are that visual interfaces should:

• Avoid visual noise and clutter
• Use contrast, similarity, and layering
• Provide visual structure and flow
• Use cohesive, consistent, and contextually appropriate imagery
• Integrate style and function comprehensively and purposefully

Avoid visual noise and clutter Visual noise is the result of superfluous visual elements (e.g., over-embellished 3D, overuse of rules, insufficient white space, overuse of color). This is like trying to hold a conversation in a loud restaurant—it makes communication impossible. Cluttered interfaces provide excess functionality in a constrained space, resulting in controls that visually interfere with each other and raise the cognitive load for the user.

To counter this, interfaces should use simple geometric forms, minimal contours, and less-saturated colors. Typography should be limited to one or two typefaces. Elements with a similar logical purpose should share visual attributes (shape, size, color, alignment). Elements intended to stand out should be visually contrasted. A popular technique is to remove individual elements to test their contribution to clarity.

🔑 Definition — Leverage: Using an element in an interface for multiple, related purposes. For example, a visual symbol that communicates the type of an object in a list, which when clicked also opens a properties dialog for that object type.

📌 Example: Instead of having a small icon for "File Type" and a separate button to "Open Properties", a single icon (e.g., a PDF symbol) in a list next to a filename serves both purposes—it identifies the file type and, when clicked, opens the file's properties dialog. This combines two functions into one visual element.

Use contrast and layering to distinguish and organize elements Contrast serves two needs: 1) To provide visual contrast between active (manipulable) and passive (non-manipulable) elements, and 2) To contrast different logical sets of active elements. Unintentional contrast causes confusion. Proper use of contrast creates visual patterns that users can remember, allowing faster orientation and communication of function.

DIMENSIONAL, TONAL, AND SPATIAL CONTRAST

• Dimensional contrast: Using pseudo-3D to give the feel of a manual affordance. Buttons are given a raised look, while text fields are given an indented look.
• Tonal contrast: Varying hue, saturation, or value to distinguish controls from the background or to group them logically. It is best to vary along a single "axis" (hue or saturation or value). Using hue can exclude users with color perception problems; saturation or brightness is a safer alternative.
• Spatial contrast: Positioning related elements together to show task relationships. This includes grouping by position (considering eye-scanning patterns like left-to-right, top-to-bottom), shape (square checkboxes vs. round radio buttons), orientation (vertical document icons vs. horizontal folder icons), and size (for indicating importance or scope).

LAYERING Interfaces can be organized by layering visual cues. Color affects this: dark, cool, de-saturated colors recede, while light, warm, saturated colors advance. Size also affects layering: large elements advance, small ones recede. To layer effectively, use minimal contrast between items you wish to associate in a layer. Maximize differences between layers, but minimize differences within a layer.

FIGURE AND GROUND Figure refers to the visual elements that should be the focus of the user's attention, and ground is the background context. People tend to perceive light objects as figure and dark objects as ground. A successful design integrates both, with figure and ground having an equal visual weight and with the figure centered on the ground.

THE SQUINT TEST A technique to evaluate contrast, layering, and figure-ground is the squint test: Close one eye and squint at the screen to see which elements pop out, which group together, and whether figure or ground seems dominant. Other tests include viewing the design through a mirror (mirror test) or looking at it upside down to uncover imbalances in composition.

⭐ Key Takeaways

• The primary goal of visual design in HCI is to communicate software behavior and function to the user, not just to create an aesthetically pleasing artifact. This distinguishes it from visual art.
• An effective visual interface relies on a team of designers (graphic, visual interface, visual information, industrial) each bringing specialized skills like typography, interaction principles, information hierarchy, and ergonomics.
• The five core principles for a good visual interface are: avoid noise/clutter, use contrast/layering, provide visual structure, use consistent imagery, and integrate style and function.
• Key techniques include using dimensional, tonal, and spatial contrast to distinguish active from passive elements; layering to organize information by importance; and using the squint test for self-evaluation. The concept of leverage (using one element for multiple purposes) is crucial for simplicity.

🧠 Quick Revision Questions

1. What is the fundamental difference between the goal of a visual artist and the goal of a visual interface designer?
2. Explain the concept of "leverage" in visual interface design and give a practical example.
3. List three types of contrast (dimensional, tonal, spatial) and give a concrete example of how each is used in a typical GUI to communicate function.
4. How does the visual phenomenon of figure-ground affect interface design, and how can the squint test be used to evaluate it?
5. According to the principles for a good visual interface, what is the problem with "visual noise" and what are three common ways it manifests in an interface?

📘 Lecture 39 — Behavior & Form – Part VII

📖 Overview: This lecture focuses on the principles of visual interface and information design, providing a comprehensive guide on how to create clear, functional, and aesthetically pleasing user interfaces. It covers topics from visual structure and alignment to the use of imagery, color, text, and the critical role of consistency and standards, aiming to equip designers with the knowledge to create effective and user-friendly digital products.

🗂️ Topics Covered

This lecture explores the principles of visual interface design, including how to provide visual structure and flow through alignment, grids, symmetry, and spatial harmony; how to use cohesive and contextually appropriate imagery, such as function-oriented icons and visualizations of behavior; the importance of integrating style and function for branding; the seven grand principles of visual information design according to Edward Tufte; best practices for the use of text and color; and finally, the benefits, risks, and proper application of interface consistency and standards.

📝 Lecture Summary

39.1 Provide visual structure and flow at each level of organization

Interfaces are composed of visual and behavioral elements grouped into panes and screens. It is critical to maintain a clear visual structure to help users navigate. Grouping can be achieved by position, alignment, color, texture, size, or shape. Several important attributes help define a crisp visual structure.

🔑 Definition — Alignment: The arrangement of visual elements so they line up with each other, creating a sense of order and organization for the user.

📐 Formula: Grouped elements should be aligned both horizontally and vertically, following a regular grid structure to combat ambiguity.

📌 Example: For controls stacked vertically, labels should be left-justified for easier scanning. A related group of checkboxes, radio buttons, or text fields should all be aligned according to the same regular grid to maintain a clean layout.

Symmetry and Balance: Symmetry is a useful tool for providing visual balance, while asymmetrical balance is harder to achieve in user interfaces due to screen real-estate constraints. Two common types are vertical axial symmetry and diagonal axial symmetry, the latter being the most frequent in dialog boxes. Sovereign applications typically achieve balance through a grid at the top level but use symmetry for internal elements.

Spatial Harmony and White Space: This considers the interface as a whole. Certain proportions, like the Golden Section ratio, are more pleasing to the eye. Proper dimensioning of functional regions and a proper amount of white space between elements is critical. Avoid indecisive proportions (e.g., "almost a square"); make them bold, crisp, and exact.

💡 Why this matters: A well-structured interface reduces user cognitive load, making the application feel organized and easy to navigate.

Use cohesive, consistent, and contextually appropriate imagery: Icons and other illustrative elements must be carefully designed, with a good understanding of personas, their mental models, and cultural issues (e.g., red is not a warning color in China). Visual elements should be part of a cohesive visual language, where similar elements share attributes like position, size, and style to form a cohesive whole.

Function-oriented Icon: Designing icons for abstract functions is challenging. Guidelines include representing both the action and an object acted upon (e.g., a document with an X for Cut), keeping icons simple, reusing elements, and using ToolTips or text labels for clarity.

Associating Visual Symbols to Objects: Creating unique symbols for object types aids user recognition, and these symbols should be used wherever the object is represented.

Rendering Icons and Visual Symbols: Icons should be simple and schematic, not photo-realistic. Photo-realistic icons draw undue attention, render poorly at small sizes, and lack visual cohesion. They are like all-capitalized text; the differences are not sharp.

Visualizing Behaviors: Use visual elements (e.g., diagrams, thumbnails) to show users the results of interface functions, rather than just describing them with words. For example, the Word Page Setup dialog shows a Preview of the page layout. Text is still important for precise values.

Integrate style and function comprehensively and purposefully: Stylistic elements must be applied from a global perspective, ensuring functional aspects are in harmony with the visual brand.

Form versus Function: Stylized visual elements should not affect the basic shape, visual behavior, or visual affordance of controls. Educational and entertainment applications allow for more stylistic experimentation, but basic affordances must be preserved.

Branding and the user interface: Brand value is the sum of all user interactions with a company. A positive first impression in the first five minutes is critical, built on visual design. Long-term relationships are built by delivering on that promise through consistent behavior (interaction design).

39.2 Principles of Visual Information Design

Information design guru Edward Tufte asserts that good visual design is "clear thinking made visible." He identifies two key problems: displaying multidimensional information on a 2D surface and the low resolution of computer displays. He proposes seven "Grand Principles" to maximize the effectiveness of information display.

1. Enforce visual comparisons: Provide a way for users to compare related variables or "before and after" scenarios to make information more valuable (e.g., previews in Photoshop).
2. Show causality: Clarify cause and effect in information graphics and use modeless visual feedback to inform users of consequences.
3. Show multiple variables: Display multiple related variables simultaneously without sacrificing clarity, allowing users to turn them on/off.
4. Integrate text, graphics, and data in one display: Avoid separate keys or legends, as they add cognitive load.
5. Ensure the quality, relevance, and integrity of the content: Only display information that helps users achieve goals relevant to their context.
6. Show things adjacently in space, not stacked in time: For changes over time, show them adjacently (like a cartoon strip) rather than superimposed, unless animation is available.
7. Don't de-quantify quantifiable data: While using graphs, also display the raw numbers (e.g., a pie chart for disk space with the exact number of kilobytes).

📌 Example: The Challenger disaster is cited as a classic example where data was not organized to clearly show the causality between air temperature and O-ring failure.

39.3 Use of Text and Color in Visual Interfaces

Text and color are indispensable elements of the visual language of user interfaces.

Use of text: For navigation, text words are best considered as visual elements and should be short and easily recognized. Avoid ALL CAPS as they are harder to read because familiar pattern-matching hints are absent. Minimize text reading for navigation; use visual symbols for context and text for differentiation. When text must be read, ensure high contrast, choose an appropriate typeface (sans-serif like Arial for brief text, serif like Times for paragraphs), and phrase clearly with the fewest words necessary.

📌 Example: "WORDS TYPED IN ALL CAPITAL LETTERS ARE HARDER TO READ than upper/lowercase — the familiar pattern-matching hints are absent in capitalized words."

Use of color: Color is a powerful design tool. It draws attention, improves navigation speed, and shows relationships.

🔑 Definition — Chromostereopsis: A visual effect where colors from extreme ends of the spectrum (like red and blue) appear to "vibrate" when placed adjacently, making them difficult to read.

Common misuses of color include:

• Using too many colors (more than seven degrades performance).
• Using complementary colors adjacently, causing chromostereopsis.
• Excessive saturation, which looks garish.
• Inadequate contrast (difference only in hue, not saturation or brightness).
• Inadequate attention to color impairment (color blindness in ~10% of males). Important information should not rely solely on red and green hues.

📌 Example: Red text on a blue background (complementary colors) is extremely difficult to read due to chromostereopsis.

39.4 Consistency and Standards

Consistency in look, feel, and behavior across modules and products is a key goal for usability organizations.

Benefits of interface standards (according to Jakob Nielsen):

• For users: Improved ability to learn interfaces, higher productivity, and fewer errors.
• For vendors: Reduced customer training and support costs, reduced development time, and improved code reuse.

Risks of interface standards:

• The product is only as good as the standard itself.
• Standards primarily emphasize the syntax (visual look and feel) but not the deeper behaviors or logical structure, as they lack context-specific knowledge.

Standards, guidelines, and rules of thumb: Standards should evolve with technology and understanding. They are best treated as detailed guidelines or rules of thumb. Following them too rigidly can result in a poor fit for a specific application.

When to violate guidelines: Standards should be violated when there is a very good reason—specifically, when a new idiom is clearly seen to be significantly better by most people in the target user audience. This is how toolbars, tabs, and other innovations came into existence.

Consistency and standards across applications: For companies with multiple software titles, consistency is important for visual branding. However, consistency does not imply rigidity. If different products serve distinct personas with different goals, a single standard may be inappropriate. The "spirit of the law" should guide design, not the "letter of the law."

📌 Example: Microsoft’s attempt to enforce a similar menu structure in Word, Excel, and PowerPoint was arguably too rigid, as PowerPoint’s user model is different.

⭐ Key Takeaways

This lecture is critical for understanding how to design professional, usable interfaces. The key takeaways are: 1) Visual structure, achieved through alignment, grids, symmetry, and white space, is fundamental for user navigation and comfort. 2) Imagery, including icons, must be part of a cohesive visual language that is culturally appropriate, contextually relevant, and simple; visualizing behaviors is often more effective than text alone. 3) Tufte's seven principles for information design provide a powerful framework for presenting data clearly, emphasizing comparisons, causality, and integration. 4) The use of text and color is a core design tool; avoid all-caps, ensure high contrast, and be aware of color blindness and perceptual artifacts like chromostereopsis. 5) Consistency and standards are valuable but should be treated as guidelines to be thoughtfully violated when a new, measurably better idiom emerges that serves user goals.

🧠 Quick Revision Questions

1. What are the key attributes that help define a crisp visual structure in an interface?
2. Explain the "squint test" in the context of visual balance and symmetry.
3. List the seven "Grand Principles" of visual information design as defined by Edward Tufte.
4. What are the primary risks and limitations of relying too heavily on interface standards?
5. Describe the “chromostereopsis” effect and give an example of a color combination that causes it.

📘 Lecture 40 — Observing User

📖 Overview: This lecture focuses on observation as a key evaluation method in Human-Computer Interaction. It covers how to watch and listen to users in both controlled and natural environments, explores different observation frameworks, and explains how to collect, analyze, and present observational data to inform design decisions.

🗂️ Topics Covered

The lecture covers when and what to observe during product development, how to observe in controlled environments versus the field, data collection techniques including notes, audio, video, diaries, and interaction logging, participant observation and ethnography, and finally how to analyze, interpret, and present both qualitative and quantitative observational data to feed findings back into design.

📝 Lecture Summary

40.1 What and when to observe

Observing is useful at any time during product development. Early in design, observation helps understand users' needs. Later, observation examines whether the developing prototype meets users' needs. Depending on the type of study, evaluators may be onlookers, participant observers, or ethnographers. The degree of immersion varies across a broad outsider-insider spectrum, determined by the study's goals and practical/ethical issues.

40.2 How to observe

The same basic data-collection tools are used for laboratory and field studies (direct observation, notes, video), but used differently. In the laboratory, emphasis is on details of what individuals do, while in the field, context is important with focus on how people interact with each other, technology, and their environment.

In controlled environments: Key practical issues include deciding where users will be located (e.g., usability labs with wall-mounted cameras), testing equipment beforehand, and having informed consent forms and scripts ready to make users comfortable.

In the field: Events can be complex and rapidly changing. Experts use frameworks to structure observation. One simple practitioner's framework focuses on three items:

• The Person — Who is using the technology?
• The Place — Where are they using it?
• The Thing — What are they doing with it?

A more detailed framework by Goetz and LeCompte (1984) encourages attention to context, people, and technology: Who is present? What is happening? When does the activity occur? Where is it happening? How is the activity organized?

Colin Robson (1993) suggests another framework: Space, Actors, Activities, Objects, Acts, Events, Goals, Feelings.

A comprehensive checklist for field observation includes: stating study goals clearly, selecting a framework, deciding how to record events, reviewing notes within 24 hours, separating opinion from fact, being prepared to refocus the study, gaining acceptance and trust, handling sensitive issues, working as a team, checking notes with informants, and looking at situations from different perspectives.

Participant observation and ethnography: Being a participant observer or ethnographer requires acceptance into the group. An example is Nancy Baym's (1997) work where she joined an online soap opera community for over a year. She told the community what she was doing and offered to share findings, gaining trust and support. She kept all messages as data and adapted interviewing and questionnaires.

The distinction between ethnography and participant observation is blurred. Some believe ethnography is an open interpretive approach; others like David Fetterman (1998) see a stronger role for theoretical underpinning: "before asking the first question... the ethnographer begins with a problem, a theory or model, a research design, specific data collection techniques, tools for analysis, and a specific writing style." Ethnographic study allows multiple interpretations of reality—it is interpretive. Data collection and analysis often occur simultaneously.

Fetterman's checklist for ethnography includes: identify a problem or goal and ask good questions; be there to observe; collect a variety of data (notes, pictures, audio, video, artifacts); move between broad picture and specific questions; analyze data using a holistic approach where observations are understood within broad context.

40.3 Data Collection

Data collection techniques (notes, audio recording, video recording) are used individually or in combination, often supplemented with photos.

Notes plus still camera: Taking notes is the least technical but can be difficult and tiring. Handwritten notes are flexible but must be transcribed; this transcription can be the first step in data analysis. A laptop is an alternative but more obtrusive.

Audio recording plus still camera: Less intrusive than video, allows mobility. Two main problems: lack of visual record (handled with a small camera) and transcribing data. Many studies use the recording to remind evaluators of important details and as a source of anecdotes.

Video: Captures both visual and audio data but can be intrusive. Small handheld digital cameras are mobile and inexpensive. Problems: attention becomes focused through the lens, missing other things; sound may get muffled in noisy conditions. Analysis can be very time-consuming—over 100 hours of analysis for one hour of video is common for detailed analyses.

40.4 Indirect observation: tracking users' activities

Sometimes direct observation is not possible. Diaries and interaction logs are used to track users' activities indirectly.

Diaries: Provide a record of what users did, when, and what they thought. Useful when users are scattered and unreachable. Diaries are inexpensive, require no special equipment, and are suitable for long-term studies. Templates can be created online to standardize entry format. Robinson and Godbey (1997) used diaries to record how Americans spent time on various activities. Barry Brown and colleagues (2000) collected diaries from 22 people with handheld cameras to examine information capture—381 activities were recorded, providing contextual information for designing new digital cameras and handheld scanners.

Interaction logging: Records key presses, mouse movements, etc. Often synchronized with video and audio logs to help evaluators analyze behavior. Logs are time-stamped, allowing calculation of time spent on tasks. Explicit counters record visits to websites and can justify maintenance and upgrades. For example, McLaughlin et al. (1999) analyzed server logs of an interactive art museum over seven months, discovering the site was busiest on weekday evenings. Nonnecke and Preece (2000) compared messages posted with list membership to investigate lurking behavior. An advantage of logging is unobtrusiveness, but ethical concerns must be considered. Large volumes of data can be logged automatically, requiring powerful analysis tools like WebLog (Hochheiser and Shneiderman, 2000).

40.5 Analyzing, interpreting, and presenting the data

Most observational data is qualitative, involving interpreting what users did or said by looking for patterns. The DECIDE framework suggests identifying goals and questions first before selecting techniques, as goals determine which data is collected and how it will be analyzed.

First step: "eyeball" the data to see what stands out. Then proceed to analyze according to goals and questions. Three types of data are discussed:

Qualitative analysis to tell a story: The power lies in telling a convincing story illustrated with powerful examples. Main activities: review data after each session, record themes coherently with examples, record date and time of each analysis session, check understanding with participants, iterate until the story faithfully represents observations, and report findings in oral and written form.

Quantitative data analysis: Video data from usability laboratories is annotated as observed. Evaluators mark the video and record remarks when errors or unusual behavior occur. Performance times are calculated and compared across prototypes. Interaction log data is used similarly. Simple statistics (means, standard deviations, T-tests) are applied. Categorized data may also be quantified and analyzed statistically.

Feeding the findings back into design: Results can be reported through clearly written reports with overviews, detailed content lists, anecdotes, quotations, pictures, and video clips. Both qualitative and quantitative data analysis are useful because they provide alternative perspectives.

⭐ Key Takeaways

Observation is a versatile evaluation method useful throughout product development, from understanding needs early to testing prototypes later. The choice between controlled laboratory observation and field observation depends on whether the focus is on individual task details or contextual social interactions. Frameworks like the Person-Place-Thing model and Goetz and LeCompte's checklist help structure field observations systematically. Data collection methods range from simple note-taking to video recording and interaction logging, each with trade-offs between intrusiveness, richness, and analysis time. The most critical skill is analyzing qualitative data to tell compelling, evidence-based stories that feed directly into design improvements.

🧠 Quick Revision Questions

1. What are the three main items in the simple practitioner's observation framework for field studies?
2. Why is it recommended to review observation notes within 24 hours?
3. What is the key difference between laboratory observation and field observation in terms of focus?
4. What are two main advantages and two main disadvantages of using video recording for observation?
5. How does interaction logging help evaluators understand user behavior, and what ethical concern does it raise?

📘 Lecture 41 — Asking Users

📖 Overview: This lecture introduces techniques for gathering user feedback by directly asking users, including interviews and questionnaires. It covers the basics of questionnaire design, how to conduct interviews, heuristic evaluations, and walkthroughs, and explains how to collect, analyze, and present data. Understanding these methods is crucial for evaluating usability and gathering user requirements in human-computer interaction.

🗂️ Topics Covered

The lecture covers four main methods for asking users and experts about system usability: interviews (unstructured, structured, semi-structured, and group interviews), questionnaires (design, administration, and online versions), heuristic evaluation using usability principles, and walkthroughs (cognitive and pluralistic). Each method is presented with its appropriate use cases, strengths, limitations, and practical guidelines for implementation.

📝 Lecture Summary

41.1 Introduction

Interviews and questionnaires are well-established techniques in social science research, market research, and human-computer interaction. They are used in "quick and dirty" evaluation, usability testing, and field studies to ask about facts, behavior, beliefs, and attitudes. These techniques can be structured or flexible, and they are often combined with observation in field studies. This lecture focuses specifically on interviewing techniques and also covers expert-based evaluation methods like heuristic evaluation and cognitive walkthroughs, which predict how usable interfaces are.

41.2 Asking users: interviews

Interviews can be thought of as a "conversation with a purpose" (Kahn and Cannell, 1957). There are four main types: open-ended or unstructured, structured, semi-structured, and group interviews. The first three types are named according to how much control the interviewer imposes by following a predetermined set of questions. The fourth involves a small group guided by an interviewer who facilitates discussion of specified topics.

The most appropriate approach depends on the evaluation goals, the questions to be addressed, and the paradigm adopted. For gaining first impressions about a new design idea, an informal, open-ended interview is often best. For feedback about a particular design feature, a structured interview or questionnaire is often better because the goals and questions are more specific.

Developing questions and planning an interview When developing interview questions, plan to keep them short, straightforward, and avoid asking too many. Key guidelines include:

• Avoid long questions because they are difficult to remember
• Avoid compound sentences by splitting them into two separate questions. For example, instead of "How do you like this cell phone compared with previous ones that you have owned?" say "How do you like this cell phone? Have you owned other cell phones?"
• Avoid using jargon that the interviewee may not understand
• Avoid leading questions such as "Why do you like this style of interaction?" which assumes the person did like it
• Be alert to unconscious biases and strive for neutrality in your questions

Asking colleagues to review questions and running a pilot study helps identify problems in advance.

When planning an interview, think about interviewees who may be reticent or in a hurry. Include these steps:

1. An Introduction — interviewer introduces themselves, explains purpose, reassures about ethics, asks about recording
2. A warm-up session — easy, non-threatening questions first
3. A main session — questions presented in logical sequence, with difficult ones at the end
4. A cool-off period — few easy questions to defuse tension
5. A closing session — interviewer thanks interviewee

Further advice for conducting interviews includes: dress similarly to interviewees, prepare an informed consent form, make sure recording equipment works, and record answers exactly without making cosmetic adjustments.

🔑 Definition — Unstructured (Open-ended) Interviews: Interviews more like conversations focusing on a particular topic, where the format and content of answers are not predetermined. The interviewee is free to answer as fully or briefly as they wish.

Unstructured interviews are at one end of the spectrum of interviewer control. They generate rich data and allow exploration of things the interviewer may not have considered. However, they produce a lot of data that is time-consuming and difficult to analyze, and the process is impossible to replicate. Typically, the evaluator makes notes or records the session and later notes main issues of interest.

Key points for unstructured interviews: have an interview agenda, be prepared to follow new lines of enquiry, pay attention to ethical issues, work on gaining acceptance, respond with sympathy but avoid putting ideas into respondents' heads, indicate the beginning and end of the session, and start to analyze data as soon as possible after the interview.

🔑 Definition — Structured Interviews: Interviews that pose predetermined questions similar to those in a questionnaire. Responses may involve selecting from a set of options. The questions are closed, requiring a precise answer, and the same questions are used with each participant for standardization.

Structured interviews are useful when the study's goals are clearly understood and specific questions can be identified. Questions need to be short and clearly worded. Responses may involve selecting from a set of options read aloud or presented on paper. Questions should be refined by review and pilot study.

🔑 Definition — Semi-structured Interviews: Interviews that combine features of structured and unstructured interviews, using both closed and open questions. The interviewer has a basic script for guidance but probes the interviewee for more information.

Semi-structured interviews use both closed and open questions. For consistency, the interviewer has a basic script so the same topics are covered with each interviewee. The interviewer starts with preplanned questions and then probes the interviewee to say more until no new relevant information is forthcoming. For example: "Which websites do you visit most frequently? Why? Tell me more about x? Anything else?"

It is important not to preempt an answer by phrasing a question to suggest a particular answer is expected. The body language of the interviewer can have a strong influence. The interviewer needs to accommodate silence and not move on too quickly. Probes are devices for getting more information, especially neutral probes such as "Do you want to tell me anything else?"

🔑 Definition — Focus Group: A form of group interview frequently used in marketing, political campaigning, and social sciences research, normally involving three to 10 people who share certain characteristics.

Group interviews or focus groups allow diverse or sensitive issues to be raised that would otherwise be missed. The method assumes individuals develop opinions within a social context. A preset agenda guides discussion but allows flexibility for a facilitator to follow unanticipated issues. The facilitator encourages quiet people to participate and stops verbose ones from dominating.

Focus groups appear to have high validity because the method is readily understood. They are low-cost, provide quick results, and can be easily scaled. Disadvantages include the need for a skillful facilitator, difficulty getting people together, and problems scheduling participants.

Other sources of interview-like feedback include: telephone interviews (good for people you cannot meet but you cannot see body language), online interviews via email or chat (good for sensitive issues), video-conferencing systems, customer help lines, consumer groups, and online customer communities. Retrospective interviews can be done during field studies to check understanding.

Data analysis and interpretation Analysis of unstructured interviews can be time-consuming. A coding form may be developed, either predetermined or developed during data collection. Comments may be clustered around themes with anonymous quotes used to illustrate points. Tools like NUDIST and Ethnography can be useful for qualitative analyses. Data from structured interviews is usually analyzed quantitatively as in questionnaires.

41.3 Asking users: questionnaires

🔑 Definition — Questionnaire: A well-established technique for collecting demographic data and users' opinions, similar to interviews, that can have closed or open questions.

Questionnaires are similar to interviews and can have closed or open questions. Effort and skill are needed to ensure questions are clearly worded and data can be analyzed efficiently. One advantage of questionnaires is they can be distributed to a large number of people. Structured interviews are easier and quicker in situations where people will not stop to complete a questionnaire.

Designing questionnaires Many questionnaires start by asking for basic demographic information (e.g., gender, age) and details of user experience (time or years using computers, level of expertise). This background information helps find out the range within the sample group. Following general questions, specific questions that contribute to the evaluation goal are asked. If the questionnaire is long, questions may be subdivided into related topics.

Checklist for designing a questionnaire:

• Make questions clear and specific
• When possible, ask closed questions and offer a range of answers
• Consider including a "no-opinion" option for opinion questions
• Think about ordering — general questions should precede specific ones
• Avoid complex multiple questions
• When using scales, make sure the range is appropriate and does not overlap
• Make ordering of scales intuitive and consistent, and be careful with using negatives
• Avoid jargon and consider different versions for different populations
• Provide clear instructions on how to complete the questionnaire
• Balance white space with compactness to avoid deterring participation

Question and response format Different types of questions require different types of responses, including discrete responses (e.g., "Yes" or "No"), ranges, or single preferred opinions.

Check boxes and ranges: The range of answers to demographic questions is predictable. A common design error occurs when ranges overlap. For example, specifying ranges as 15-20, 20-25 will cause confusion for people who are 20 years old. Making ranges 14-19, 20-24 avoids this problem.

Whether the interval must be equal depends on what you want to know. For example, for an e-commerce site selling life insurance, target population might be 21-65 years, so ranges could be: under 21, 21-65, and over 65. For ten-year cohort groups, ranges would be: under 21, 22-31, 32-41, etc.

Administering questionnaires Two important issues are reaching a representative sample and ensuring a reasonable response rate. For large surveys, potential respondents need to be selected using a sampling technique. Interaction designers tend to use small numbers (often fewer than 20 users). 100% completion rates are often achieved with small samples, but with larger populations, 40% return is generally acceptable.

Ways to encourage a good response include: ensuring good design, providing a short overview section, including a stamped self-addressed envelope, explaining why the questionnaire needs to be completed, contacting respondents through follow-up letters/phone calls/emails, and offering incentives.

Online questionnaires Online questionnaires are effective for reaching large numbers quickly. There are two types: email and web-based. Email allows targeting specific users but is usually limited to text. Web-based questionnaires are more flexible, allowing check boxes, pull-down menus, help screens, graphics, immediate data validation, and enforcement of rules.

Advantages of online questionnaires:

• Responses are usually received quickly
• Copying and postage costs are lower or nonexistent
• Data can be transferred immediately into a database for analysis
• Time required for data analysis is reduced
• Errors in questionnaire design can be corrected easily

A big problem with web-based questionnaires is obtaining a random sample of respondents. There is some evidence suggesting response rates may be lower online than with paper questionnaires.

41.4 Asking experts: heuristic evaluation

🔑 Definition — Heuristic Evaluation: An informal usability inspection technique developed by Jakob Nielsen in which experts, guided by a set of usability principles known as heuristics, evaluate whether user-interface elements conform to the principles.

Heuristic evaluation involves experts guided by a set of usability principles called heuristics. The original set was derived empirically from an analysis of 249 usability problems. The latest set of heuristics includes:

1. Visibility of system status — Are users kept informed about what is going on? Is appropriate feedback provided within reasonable time?
2. Match between system and the real world — Is the language simple? Are words, phrases and concepts familiar to the user?
3. User control and freedom — Are there ways of allowing users to easily escape from places they unexpectedly find themselves in?
4. Consistency and standards — Are ways of performing similar actions consistent?
5. Help users recognize, diagnose, and recover from errors — Are error messages helpful? Do they use plain language and suggest a way of solving the problem?
6. Error prevention — Is it easy to make errors? If so, where and why?
7. Recognition rather than recall — Are objects, actions and options always visible?
8. Flexibility and efficiency of use — Have accelerators (shortcuts) been provided for experienced users?
9. Aesthetic and minimalist design — Is any unnecessary or irrelevant information provided?
10. Help and documentation — Is help information provided that can be easily searched and followed?

For evaluating commercial websites, Nielsen suggests the HOME RUN heuristics: High-quality content, Often updated, Minimal download time, Ease of use, Relevant to users' needs, Unique to the online medium, Net-centric corporate culture.

Different sets of heuristics are needed for different products (toys, WAP devices, online communities, wearable computers). Using a set of heuristics, expert evaluators role-play typical users and note problems. Empirical evidence suggests that five evaluators usually identify around 75% of total usability problems.

💡 Why this matters: Heuristic evaluation is a quick and cost-effective method for identifying usability problems without involving users directly, making it ideal for early design evaluation when prototypes may not be ready for user testing.

41.5 Asking experts: walkthroughs

🔑 Definition — Walkthroughs: An alternative approach to heuristic evaluation for predicting users' problems without doing user testing, involving walking through a task with the system and noting problematic usability features.

Walkthroughs involve walking through a task with the system and noting problematic usability features. Most walkthrough techniques do not involve users. Others, such as pluralistic walkthroughs, involve a team including users, developers, and usability specialists.

Cognitive walkthroughs 🔑 Definition — Cognitive Walkthrough: A method involving simulating a user's problem-solving process at each step in the human-computer dialog, checking to see if the user's goals and memory for actions can be assumed to lead to the next correct action.

Cognitive walkthroughs focus on evaluating designs for ease of learning. The steps involved are:

1. Identify characteristics of typical users, develop sample tasks focusing on aspects of the design to be evaluated, and produce a description or prototype of the interface along with a clear sequence of actions needed for the task.
2. A designer and one or more expert evaluators come together to do the analysis.
3. Evaluators walk through action sequences for each task, trying to answer these questions:
   • Will the correct action be sufficiently evident to the user? (Will the user know what to do?)
   • Will the user notice that the correct action is available? (Can users see the button or menu item?)
   • Will the user associate and interpret the response from the action correctly? (Will users know from feedback whether the action was correct or not?)
4. As the walkthrough is done, a record is compiled including assumptions about problems, notes about side issues, and a summary of results.
5. The design is then revised to fix the problems.

It is important to document the cognitive walkthrough, using a standardized feedback form and documenting the severity of problems.

Strengths: Focuses on users' problems in detail, users do not need to be present, and a working prototype is not necessary. Limitations: Very time-consuming and laborious, and has a narrow focus that is useful for certain types of systems but not others.

Pluralistic walkthroughs 🔑 Definition — Pluralistic Walkthrough: A type of walkthrough in which users, developers, and usability experts work together to step through a task scenario, discussing usability issues associated with dialog elements.

Pluralistic walkthroughs involve a team that includes users, developers, and usability experts. Each group is asked to assume the role of typical users. The steps are:

1. Scenarios are developed as a series of hard-copy screens representing a single path through the interface.
2. Scenarios are presented to the panel of evaluators, and panelists individually write down the sequence of actions they would take to move from one screen to another.
3. When everyone has written down their actions, the panelists discuss the actions they suggested. Typically, representative users go first, then usability experts, and finally developers.
4. The panel moves on to the next round of screens until all scenarios have been evaluated.

Benefits: Strong focus on users' tasks, performance data is produced, and the approach lends itself well to participatory design practices by involving a multidisciplinary team where users play a key role. Limitations: Requires getting all experts together at once, proceeds at the rate of the slowest, and only a limited number of scenarios can be explored due to time constraints.

⭐ Key Takeaways

The most critical things to remember from this lecture are the four main methods for gathering user feedback: interviews (unstructured for rich exploratory data, structured for specific questions, semi-structured for a balance, and focus groups for group dynamics), questionnaires (carefully designed with clear questions, appropriate scales, and no overlapping ranges), heuristic evaluation (using Nielsen's 10 heuristics to identify usability problems without users, with five evaluators finding about 75% of problems), and walkthroughs (cognitive for learning-focused analysis and pluralistic for collaborative evaluation with users). Each method has specific strengths—interviews provide depth, questionnaires provide breadth, heuristic evaluation is quick and expert-driven, and walkthroughs focus on task-based analysis. The golden rules include avoiding leading questions, piloting before full use, ensuring representative sampling, designing for good response rates, and documenting problems with severity ratings for effective design revision.

🧠 Quick Revision Questions

1. What are the four main types of interviews described in this lecture, and what distinguishes each type in terms of interviewer control and question format?
2. How can you avoid a common design error when creating age range options in a questionnaire, and what is the problem with overlapping ranges?
3. What are Nielsen's 10 heuristics for heuristic evaluation, and approximately what percentage of usability problems can five evaluators typically identify using this method?
4. What are the three key questions evaluators must answer during a cognitive walkthrough, and how do these questions relate to the user's learning process?
5. What are the advantages and limitations of using online questionnaires compared to paper-based questionnaires, particularly regarding response rates and sampling?

📘 Lecture 42 — Communicating Users

📖 Overview: This lecture explores how to design interfaces that eliminate or minimize error messages, notifiers, and confirmatory dialog boxes. It argues that these elements are often abused and can be replaced with smarter, more flexible software that prevents errors from occurring in the first place, fostering a more positive and efficient user experience.

🗂️ Topics Covered

This lecture begins by examining why error messages are so prevalent and problematic, arguing they are a sign of inflexible software design. It then proposes methods for eliminating errors, such as making errors impossible through bounded inputs and making programs smarter. Next, it discusses the importance of positive feedback and provides guidelines for improving unavoidable error messages as a last resort. The lecture also covers notifiers and confirmations, explaining why they often stop proceedings unnecessarily and how alerts announce the obvious while confirmations pass the buck. Finally, it introduces rich modeless feedback as the superior alternative to dialog boxes.

📝 Lecture Summary

42.1 Eliminating Errors

Bulletin dialog boxes are frequently used for error messages, notifiers, and confirmations, but they are often overused and represent poor design. The lecture posits that with proper design, these dialogs can be largely eliminated. Users do not want error messages; they want to avoid the consequences of errors. The tradition of error messages stems from early computing where machines were expensive and operators were scientists tolerant of machine-centric communication.

Error messages are problematic because they stop the proceedings with a modal dialog, often informing the user of the program's inflexibility rather than a user error. Users hate error messages because being told they are wrong by a machine is humiliating. The assumption that users need to be told when they are wrong is false, as programs can often make reasonable substitutions for invalid input. Most "errors" occur when the program gets confused by input that is in an unfamiliar sequence, not when the user makes a substantive mistake.

🔑 Definition — Blocking modal bulletins: Error messages that must stop the proceedings with a modal dialog box.

📌 Example: When a user enters an invoice with an invalid customer number, most programs stop and demand a valid number. A better approach would be for the program to accept the transaction and remind the user to fix it before the end of the session. This mirrors how human assistants work; they don't stop everything for missing information.

💡 Why this matters: Error messages are often a failure of program design. The program should be flexible enough to handle user input in various sequences, rather than forcing the user to adhere to the program's strict rules. The program should assume the user is correct because the human is more important than the code.

The best way to eliminate error messages is to make errors impossible by using bounded gizmos like lists and drop-down menus instead of free-form text entry. Another way is to make the program smart enough to deduce information without asking, such as getting the date from the internal clock or remembering recently used files. These solutions require more work from programmers, but the programmer's job is to satisfy the user, not the other way around.

📌 Example: Instead of having a user type a state code, present them with a list of valid state codes. Instead of asking for a file name, have the program remember which files were accessed in the past and allow selection from that list.

42.2 Positive feedback

Software is often hard to learn because it rarely gives positive feedback. People learn better from and are motivated by positive feedback. They need to be rewarded or acknowledged for success, not just slapped on the wrist for failure. While negative feedback is effective for preventing people from doing things they shouldn't (like speeding), positive feedback is best for helping them do what they want to do.

To be given negative feedback by software is an insult, as the computer has no genuine experience or merit. The lecture concludes that there is nothing inside a computer that justifies humiliating or degrading a user. Negative feedback is used only out of habit.

Improving Error Messages: The Last Resort

If an error message is truly unavoidable, it should be used as a last resort and must conform to these requirements:

• Be polite: It must never even hint that the user caused the problem. The customer is always right. The program should protect the user even when they take inappropriate action.
• Be illuminating: It must explain the scope of the problem, alternatives, the program's default action, and what information was lost.
• Be helpful: It should offer to implement at least one solution directly on the dialog box, such as offering to defer a print job if a printer is missing.

📌 Example: A well-formed error message for a missing printer should be polite, explain that no printer was found, and offer buttons for "Try Again," "Select Another Printer," or "Defer Printing." It should not imply the user made a mistake.

42.3 Notifying and Confirming

This section discusses alerts (notifiers) and confirmations. Like error dialogs, they stop the proceedings with idiocy but do not report malfunctions. An alert notifies the user of a program's action, while a confirmation gives the user the authority to override an action. Both should be eliminated in favor of more useful idioms.

42.4 Alerts and Confirmations

Alerts occur when a program feels uncomfortable with an action it has taken, so it informs the user. This violates the axiom: "A dialog box is another room; you should have a good reason to go." A program should either have the confidence of its convictions or should not take action without user guidance. An alert is unnecessary when the user has explicitly requested the action.

Confirmations are dialog boxes that ask the user for approval when the program feels unsure about its actions. They pass the buck from the program to the user. The proper solution is to make the action easily reversible with a robust Undo facility.

🔑 Definition — Alert: A dialog that notifies the user of the program's action. 🔑 Definition — Confirmation: A dialog that gives the user the authority to override an action, reflecting the program's lack of confidence.

📌 Example: A dialog that appears after adding an entry to a phone book, saying "The entry was added," is a bad alert. The user just told the program to do it, so the announcement is obvious and annoying.

📌 Example: A confirmation dialog asking "Are you sure you want to delete this style?" passes the responsibility for a potentially risky action back to the user. A better solution is to provide clear visual feedback about which styles are in use and a powerful Undo feature.

💡 Why this matters: Confirmations suffer from the "boy who cried wolf" effect. When they appear routinely, users dismiss them without reading, rendering them useless when a truly dangerous situation arises. For confirmations to work, they should only appear when the user is almost certain to click "No" or "Cancel," which makes them pointless.

42.5 ELIMINATING CONFIRMATIONS

The best way to eliminate confirmation dialog boxes is to Do, don't ask. The program should act with confidence. To compensate for potential mistakes, every action must be reversible. Instead of asking in advance with a confirmation, let the user issue a Stop-and-Undo command on those rare occasions when the program acted out of turn.

📌 Example: The Recycle Bin in Windows is a good implementation of an undo facility for deleted files. Files are moved to a suspense directory instead of being immediately deleted, so there's no reason for a confirmation box for every deletion.

For truly irreversible actions, provide modeless warnings built into the interface. For example, instead of a dialog box saying a document is larger than the printable area, show permanent visual guides on the page indicating the printable region.

42.6 Replacing Dialogs: Rich Modeless Feedback

Modern computers have high-resolution displays and high-quality audio, but most programs still use the blunt instrument of dialogs to communicate. What users need is constant feedback through a different channel. Rich modeless feedback is information provided in the main displays that doesn't stop the flow of the program, effectively eliminating pesky dialogs.

42.7 Rich visual modeless feedback

Rich visual modeless feedback (RVMF) is a key type of modeless feedback. It is:

• Rich: Giving in-depth information about the status or attributes of a process or object.
• Visual: Using pixels on the screen, often dynamically.
• Modeless: Always displayed, requiring no special action from the user to see it.

📌 Example: In Windows 2000 or XP, clicking an object in a file manager window automatically displays details (title, size, author, modification date) and a thumbnail. If the object is a disk, it shows a pie chart of used space. This eliminates the need for a separate properties dialog to display this information.

📘 Lecture 43 — Information Retrieval

📖 Overview: This lecture explores how to communicate effectively with users through audible feedback, identity systems, and help mechanisms. It also examines the critical distinction between storage and retrieval systems in digital interfaces. Understanding these concepts is essential for designing interfaces that provide clear, modeless feedback and enable users to find information efficiently without relying solely on memory.

🗂️ Topics Covered

The lecture begins by examining positive vs. negative audible feedback and how silence can be a powerful indicator of success or failure. It then explores various channels for communicating with users, including program identity through names, icons, about boxes, splash screens, online help, wizards, and intelligent agents. Finally, it analyzes storage and retrieval systems in both physical and digital worlds, introducing positional, identity, and attribute-based retrieval methods.

📝 Lecture Summary

43.1 Audible feedback

In data-entry environments, clerks need both auditory and visual feedback when entering data, as they often examine source documents and type by touch rather than looking at the screen. The proposed auditory indicator for a problem is silence, not a beep.

Negative audible feedback announces user failure. Users are offended by computer sounds because computers have always accompanied error messages with alarming noises, and those noises have been loud, monotonous, and unpleasant. Error message boxes with beeps are a public announcement of the user's failure. It is the negative aspect of the feedback that presents problems, not the audible aspect. Negative feedback is issued at a time when a problem is discovered, naturally taking on alarm characteristics — alarm sounds are designed to be loud, discordant, and disturbing. People choose no noise versus noise for negative feedback, and no noise versus soft, pleasant noises for positive feedback.

💡 Why this matters: The negative feedback paradigm teaches users that success is greeted with silence, but humans like to know when they are doing well — which is what positive audible feedback provides.

Positive audible feedback occurs when success with tools yields a sound. Almost every object outside software offers sound to indicate success: closing a door produces a click when latched, silence tells us it's not secure; conversation partners say "Yes" or "Uh-huh" to register what was said. Our keyboards provide positive audible feedback through clicks when keys are pressed. The true value of positive audible feedback is that its absence becomes an extremely effective problem indicator — the software doesn't have to insult the user. Software should give constant, small, audible cues like keyboards, issuing sounds when user actions are correct, and remaining silent when input is not understood.

🔑 Definition — Negative audible feedback: Emitting noise when something bad happens, usually through loud, shrill, unpleasant beeps accompanying error messages. 🔑 Definition — Positive audible feedback: Sound produced when success with tools occurs, indicating correct action has been taken. 📐 Principle: Success = sound, Failure = silence → more effective and user-friendly than the opposite model 📌 Example: When a user drags an icon, the computer issues a low-volume sliding sound; when dropped on a meaningful target, a cheerful "plonk" is heard; if the drop was not meaningful, there is silence — immediately informing the user without embarrassment.

43.2 Other Communication with Users

This section discusses communicating with users in ways that are helpful to them while also asserting brand and identity. The modern desktop screen is crowded with many programs running, and each must assert its identity through several conventions.

Your program's name is displayed in the title bar of the main window. The title string is a single text value usually owned by the main window. Since Windows 95, the title string plays a greater role — it is displayed on the program's launch button on the taskbar. As more buttons are added, they shrink and title strings are truncated. Adding company names to program names can cause truncation to the company name only, making adjacent buttons identical. Many programs also use the title string to display the active document name. A better approach would be adding a separate title string for launch buttons, allowing tailored shorter strings.

Your program's icon is the second biggest component of identity. Windows uses standard 32x32 pixel icons and miniature 16x16 pixel icons. Mac OS X icons can be up to 128x128 pixels. The 32x32 size is used on the desktop, while 16x16 is used on title bars, taskbars, and Explorer. Icons must be readily identifiable from a distance, especially the miniature version. Icon design is a specialized craft — Susan Kare's original Macintosh icons set the industry standard.

Ancillary application windows are windows not part of core functionality but provided by convention. They are available on request or offered once, forming channels of communication that help users and communicate brand.

About boxes identify the program to the user and serve as credit screens. On Macintosh, they're summoned from the Apple pop-up menu; on Windows, from the bottom of the Help menu. Microsoft's approach treats the About box as an Identity box — displaying name, version number, copyrights, user identification — useful for customer support but not for users. A true About box should tell the user the program's scope, what it can and cannot do, and provide a one-lesson introduction for new users. It should also list the product team's names, as credits are important motivation for programmers.

🔑 Definition — Identity box: A dialog that identifies the program by name, version number, copyrights, and user information, used mainly for customer support purposes rather than helping users understand the program.

Splash screens are displayed when a program loads, giving users something to view while the program prepares. They should disappear automatically after a few seconds, and immediately if the user presses any key or clicks. Splash screens create a good first impression, establish visual brand, and can direct first-time users to training resources. For shareware, splash screens can inform users of terms of use — but should not guilt-trip customers.

Online help is a reference tool for perpetual intermediates — users already successfully using the product who want to expand horizons. A complex program needs a reference document, either printed or online. The key to effective help is the quality of the index, which must have as many synonyms as possible. The list of index entries is more important than the entry text itself. Missing entries are worse than poorly written entries. Help systems should also offer a shortcuts option showing all tools and keyboard commands, and overviews explaining scope, effect, power, upside, and downside of features.

🔑 Definition — Perpetual intermediates: Users who are no longer beginners but not experts, wanting to expand their horizons with a product's features.

Modeless and interactive help like ToolTips are incredibly effective. Standard help systems in separate programs cover up the main program and cannot point to objects on screen. Apple's innovative help system directs users step-by-step by highlighting menus and buttons in sequence.

Wizards are an idiom that attempts to guarantee success by stepping users through a series of dialog boxes. Programmers like them because they treat users like peripheral devices. Wizards use interrogation tactics rather than informed conversations. Users learn to just click "Next" without critically analyzing. Wizards are appropriate only for very rarely used actions like installation. A better approach is a simple automatic function that asks no questions and lets users modify results using standard tools later. Wizards give programmers license to put raw implementation model interfaces on complex features.

🔑 Definition — Wizard: A step-by-step dialog system that guides users through complex procedures, often using interrogation tactics rather than providing true choices.

"Intelligent" agents like Clippy are problematic because animated anthropomorphism raises user expectations of the agent's intelligence. If the agent cannot deliver, users become furious. These constructs become cloying and distracting, interfering with users trying to accomplish tasks.

43.3 Improving Data Retrieval

In the physical world, storing and retrieving are linked — putting an item on a shelf gives us the means to find it. In the digital world, only faulty thinking links these concepts. Computers enable sophisticated retrieval techniques if we break traditional thinking patterns.

Storage and Retrieval Systems A storage system is a method for safekeeping goods in a repository — a physical system of container and tools. A retrieval system is a method for finding goods in a repository — a logical system allowing location according to abstract values like name, position, or contents.

Storage and Retrieval in the Physical World The "everything in its place" model works by location — knowing where something is and going to fetch it. This is a coupled storage and retrieval system, where the storage system equals the retrieval system. This works at home but is limited by human memory at larger scales.

For large collections like the Library of Congress, we use indexed retrieval with the Dewey Decimal system — giving each book a unique number based on subject and title, shelving in numerical order. Three index cards (author, subject, title) are created and filed alphabetically. The serial number bridges storage and retrieval systems.

Storage and Retrieval in the Digital World Ironically, where easily implementing dynamic retrieval mechanisms is possible, we often don't implement any retrieval system. Most computer systems have no retrieval system other than the storage system — users must know a file's name and place to find it. This puts 100% of the retrieval burden on user memory while the CPU idles.

🔑 Definition — Coupled storage and retrieval system: A system where the storage method (location) is identical to the retrieval method — you find something by remembering where it is stored.

Retrieval Methods There are three fundamental ways to find a document on a computer:

1. Positional retrieval — remembering where you left the file in the file structure
2. Identity retrieval — remembering its identifying name
3. Associative or attribute-based retrieval — searching based on inherent qualities of the document itself (e.g., red cover, discussing light rail, containing photographs)

Positional and identity retrieval also function as storage systems. Associative retrieval is the only method that is not also a storage system. When retrieval is based solely on storage methods, users must know what information they want and where it is stored.

🔑 Definition — Attribute-based retrieval: A method of finding documents based on inherent qualities of the document itself, such as content, type, creation program, or usage patterns.

An attribute-based retrieval system would enable finding documents by their contents or attributes. The system would automatically know where all documents are, allowing searches without specifying directories. It would enable browsing by synonyms or related topics and assigning multiple attributes to documents. The system could automatically learn attributes like:

• The program that created or last opened the document
• Document type
• File size
• Time since last use
• Duration of last edit session
• Amount of information added/deleted
• Whether the document has been edited by multiple programs
• Whether it contains embedded objects
• Printing and faxing history
• E-mail recipients

The Enfish Corporation product provides this functionality — dynamically and invisibly creating an index of information across the computer system, LAN, and Web.

📌 Example: A user has proposal letters for different clients. The storage system requires each letter to be in one folder. An attribute-based system would allow finding all proposal letters (by type/function) while each letter retains its association with its particular client — impossible in a purely location-based file system.

⭐ Key Takeaways

Positive audible feedback (sound for success, silence for failure) is dramatically more user-friendly than negative audible feedback (beeps for errors), which publicly announces user failure. The About box should be redesigned as a true About box that tells users what the program does, rather than just an Identity box with legal information. Wizards should be reserved for very rare tasks and replaced with automatic functions that let users modify results later. The most critical insight for data retrieval is that current computer systems have no retrieval system separate from storage — users must remember file names and locations. Attribute-based retrieval systems that automatically learn document characteristics and allow searching by content and usage patterns are essential for modern computing.

🧠 Quick Revision Questions

1. What are the key differences between negative and positive audible feedback, and why is silence more effective for indicating errors?
2. What is the difference between an Identity box and a true About box?
3. What are the three fundamental methods for finding documents on a computer?
4. Why are wizards problematic for user interfaces, and when are they appropriate?
5. What attributes could an automatic attribute-based retrieval system learn without user setup?

📘 Lecture 44 — Emerging Paradigms

📖 Overview: This lecture explores two critical paradigms in modern web design: information architecture through metadata and controlled vocabularies, and web accessibility for people with disabilities. It explains how metadata systems and thesauri create more navigable websites while examining the ethical, legal, and practical imperatives for making web content accessible to all users regardless of ability.

🗂️ Topics Covered

The lecture first addresses metadata and controlled vocabularies as fundamental components of information architecture, exploring how thesauri model semantic relationships between terms. It then examines web accessibility in depth, covering the opportunities the web offers people with disabilities, current shortcomings, legal requirements, and comprehensive solutions including organizational commitment and technical training.

📝 Lecture Summary

Metadata

A web site is a collection of interconnected systems with complex dependencies. A single link on a page can simultaneously be part of the site's structure, organization, labeling, navigation, and searching systems. Metadata and controlled vocabularies present a fascinating lens through which to view the network of relationships between systems. In many large metadata-driven web sites, controlled vocabularies have become the glue that holds the systems together. A thesaurus on the back end can enable a more seamless and satisfying user experience on the front end.

When it comes to definitions, metadata is a slippery fish. Metadata is definitional data that provides information about or documentation of other data managed within an application or environment. For example, metadata would document data about data elements or attributes (name, size, data type, etc) and data about records or data structures (length, fields, columns, etc) and data about data (where it is located, how it is associated, ownership, etc.). Metadata may include descriptive information about the context, quality and condition, or characteristics of the data.

Metadata tags are used to describe documents, pages, images, software, video and audio files, and other content objects for the purposes of improved navigation and retrieval. The HTML keyword meta tag provides a simple example: <meta name="keywords" content="information architecture, content management, knowledge management, user experience">

Many companies today are using metadata in more sophisticated ways. Leveraging content management software and controlled vocabularies, they create dynamic metadata-driven web sites that support distributed authoring and powerful navigation. This metadata-driven model represents a profound change in how web sites are created and managed. Instead of asking, "Where do I place this document in the taxonomy?" we can now ask, "How do I describe this document?"

🔑 Definition — Metadata: Definitional data that provides information about or documentation of other data managed within an application or environment. 📐 Formula: N/A 📌 Example: HTML meta tags like <meta name="keywords" content="information architecture, user experience"> allow authors to enter words and phrases that describe content, not displayed in the interface but available for search engines.

Controlled Vocabularies

Vocabulary control comes in many shapes and sizes. At its most vague, a controlled vocabulary is any defined subset of natural language. At its simplest, a controlled vocabulary is a list of equivalent terms in the form of a synonym ring, or a list of preferred terms in the form of an authority file. Define hierarchical relationships between terms (e.g., broader, narrower) and you've got a classification scheme. Model associative relationships between concepts (e.g., see also, see related) and you get a full-blown thesaurus.

Classification schemes can be used in the context of searching. Yahoo! does this very effectively by presenting "Category Matches" in search results, which reinforces users' familiarity with Yahoo!'s classification scheme.

The important point is that classification schemes are not tied to a single view or instance. They can be used on both the back end and the front end in all sorts of ways.

🔑 Definition — Controlled Vocabulary: Any defined subset of natural language used to improve information retrieval, ranging from simple synonym rings to complex thesauri. 📐 Formula: Types: Synonym ring → Authority file → Classification scheme → Thesaurus (increasing complexity) 📌 Example: Yahoo! search results show "Category Matches" like "Bizarre Humor > Hamster Dance" or "Rodents > Hamsters" for a search on "hamsters"

Thesauri

A thesaurus is a semantic network of concepts, connecting words to their synonyms, homonyms, antonyms, broader and narrower terms, and related terms. For web purposes, the thesaurus takes the form of an online database, tightly integrated with the user interface of a web site or intranet. While the traditional thesaurus helps people go from one word to many words, our thesaurus does the opposite. Its most important goal is synonym management — the mapping of many synonyms or word variants onto one preferred term or concept, so the ambiguities of language don't prevent people from finding what they need.

For the purposes of this book, a thesaurus is: "A controlled vocabulary in which equivalence, hierarchical, and associative relationships are identified for purposes of improved retrieval." — ANSI/NISO Z39.19-1993

A thesaurus builds upon the constructs of the simpler controlled vocabularies, modeling three fundamental types of semantic relationships. Each preferred term becomes the center of its own semantic network. The equivalence relationship is focused on synonym management. The hierarchical relationship enables the classification of preferred terms into categories and subcategories. The associative relationship provides for meaningful connections that are not handled by the hierarchical or equivalence relationships.

🔑 Definition — Thesaurus (web): A controlled vocabulary in which equivalence, hierarchical, and associative relationships are identified for purposes of improved retrieval. 📐 Formula: Semantic relationships: Equivalence (synonyms) + Hierarchical (broader/narrower) + Associative (related terms) 📌 Example: A search for "automobile" might map to preferred term "car," with broader term "vehicle," narrower term "sedan," and related term "gasoline"

💡 Why this matters: Thesauri convert the inherent ambiguity of natural language into precise, machine-manageable relationships, dramatically improving search accuracy and navigation.

44.1 Accessibility

Accessibility is a general term used to describe the degree to which a system is usable by as many people as possible without modification. It is not to be confused with usability, which is used to describe how easily a thing can be used by any type of user. One meaning of accessibility specifically focuses on people with disabilities and their use of assistive devices such as screen-reading web browsers or wheelchairs.

Accessibility is strongly related to universal design in that it is about making things as accessible as possible to as wide a group of people as possible. The disability rights movement advocates equal access to social, political and economic life which includes not only physical access but access to the same tools, organisations and facilities which we all pay for.

Various countries have legislation requiring physical accessibility:

• In the UK, the Disability Discrimination Act 1995 has numerous provisions for accessibility
• In the US, under the Americans with Disabilities Act of 1990, new public and private business construction generally must be accessible
• In Ontario, Canada, the Ontarians with Disabilities Act of 2001

🔑 Definition — Accessibility: The degree to which a system is usable by as many people as possible without modification, particularly focusing on people with disabilities.

Introduction to Web Accessibility

The Internet provides access to information, news, email, shopping, and entertainment. Some have argued that no other single invention has been more revolutionary since Gutenberg's printing press. Now, at the click of a mouse, the world can be "at your fingertips"—that is, if you can use a mouse, see the screen, and hear the audio.

The Web Offers Unprecedented Opportunities — The Internet is one of the best things that ever happened to people with disabilities. For example, without the Internet, blind people mostly couldn't read newspapers independently. With the advent of the World Wide Web, many newspapers now publish their content electronically in a format that can be read by text-to-speech synthesizer software programs (often called "screen readers") used by the blind. Suddenly, blind people don't have to rely on others to read to them.

Similarly, people with motor disabilities who cannot pick up a newspaper can access online newspapers using assistive technologies that adapt the computer interface. Adaptations range from crude (using a stick in the mouth to type) to sophisticated (eye-tracking software). People with tremors may use special keyboards with raised ridges between keys. Most of these adaptations make use of the keyboard or emulate keyboard use rather than mouse use.

People who are deaf can read online transcripts of important speeches or view multimedia content that has been fully captioned.

Falling Short of the Web's Potential — Despite the Web's great potential for people with disabilities, this potential is still largely unrealized. Where can you find web-based video or multimedia content that has been fully captioned for the deaf? What if content is only accessible by using a mouse? What if developers use all graphics instead of text, preventing screen readers from reading to blind people?

People with Disabilities on the Web — Though estimates vary, most studies find that about one fifth (20%) of the population has some kind of disability. Businesses would be unwise to purposely exclude 20, 10 or even 5 percent of their potential customers. Schools, universities, and government entities would be not only unwise, but in many countries, also breaking the law.

Each major category of disability requires certain types of adaptations in web content design. Most of the time, these adaptations benefit nearly everyone. People with cognitive disabilities benefit from illustrations, graphics, properly-organized content with headings, lists, and visual cues in navigation. Though captioned video is meant for deaf people, it also benefits those without sound on their computers or those in public places.

Occasionally developers must implement more specific accommodations, such as links allowing blind users or those with motor disabilities to skip past navigational links. In almost every case, these adaptations can be integrated with little or no impact to visual "look and feel."

From the perspective of people with disabilities, inaccessible web content prevents them from participating fully in the information revolution. It is a matter of basic human rights.

Comprehensive Solutions — There are two key components to any effort to achieve web accessibility:

• Commitment and accountability
• Training and technical support

Either of these by itself is insufficient.

Commitment and accountability requires: (1) Awareness — Most accessibility errors result from ignorance, not malice; developers who understand the issues are usually willing to help. (2) Leadership — If organizational leadership doesn't express commitment, chances are low that content will be accessible. (3) Policies and Procedures — The best approach is to create internal policy outlining specific standards, procedures, and monitoring methods, such as requiring compliance with W3C Web Content Accessibility Guidelines.

Training and technical support addresses the fear that accessible sites are more expensive. On a page-by-page basis, the extra time required by a knowledgeable developer is almost negligible. A developer can learn basics in a few days but may need months to internalize the mindset. Organizations should ensure access to training materials, workshops, books, or courses. Resources like WebAIM are available for free.

Ongoing technical support can be offered through outside consultants, discussion groups, internal workshops, or classes. Some organizations set up internal discussion groups for accessibility issues.

🔑 Definition — Screen Reader: Text-to-speech synthesizer software programs that read text out loud so that blind people can use computers and access text content. 🔑 Definition — Universal Design: Making things as accessible as possible to as wide a group of people as possible.

⭐ Key Takeaways

Metadata and controlled vocabularies form the invisible infrastructure of modern websites, with thesauri modeling three critical semantic relationships — equivalence, hierarchical, and associative — to enable powerful navigation and retrieval. Web accessibility is both a legal requirement under acts like the Americans with Disabilities Act and a moral imperative, given that approximately 20% of the population has some disability. The web offers unprecedented independence to people with disabilities through screen readers, keyboard-based navigation, and captioning, yet most sites fail to realize this potential. Achieving accessibility requires both organizational commitment with clear policies and accountability, plus ongoing training and technical support for developers. Importantly, most accessibility adaptations benefit all users, not just those with disabilities, making it a universal design principle rather than a niche concern.

🧠 Quick Revision Questions

1. What are the three fundamental types of semantic relationships modeled in a thesaurus, and how does each improve information retrieval?
2. How does the metadata-driven model change the fundamental question web developers ask when adding content to a site?
3. What percentage of the population has some kind of disability, and why is this significant for web design decisions?
4. What are the two essential components of a comprehensive web accessibility solution, and why is each component alone insufficient?
5. How do screen readers change the newspaper-reading experience for blind people compared to pre-Internet methods like Braille or audiotapes?

📘 Lecture 45 — Conclusion

📖 Overview: This concluding lecture explores emerging interaction paradigms beyond traditional desktop computing. It introduces students to ubiquitous computing, wearable technology, tangible user interfaces, and attentive environments—all representing the future direction of Human-Computer Interaction. Understanding these paradigms is essential for anticipating how computing will integrate seamlessly into everyday life.

🗂️ Topics Covered

The lecture presents four major emerging interaction paradigms: ubiquitous computing (integrating computation into the environment), wearable computing (computers worn on the body), tangible bits (physical objects as interfaces), and attentive environments (user and context-aware spaces). It traces the historical development and philosophical underpinnings of each paradigm, from Mark Weiser's foundational work at Xerox PARC to modern applications in military, medical, and consumer contexts.

📝 Lecture Summary

Ubiquitous computing

Ubiquitous computing (ubicomp, pervasive computing, calm technology, things that think) integrates computation into the environment rather than having computers as distinct objects. The goal is enabling people to move around and interact with information and computing more naturally and casually. Devices should sense changes in their environment and automatically adapt based on user needs and preferences.

The late Mark Weiser wrote seminal papers beginning in 1988 at the Xerox Palo Alto Research Center (PARC). The MIT Media Lab carries on research under the name "Things That Think." Writer Adam Greenfield coined the term Everyware to describe technologies of ubiquitous computing, pervasive computing, ambient informatics, and tangible media.

🔑 Definition — Ubiquitous Computing: Computing that is invisible, everywhere, and does not live on a personal device but is integrated into the environment.

💡 Why this matters: This paradigm represents a fundamental shift from "dramatic" machines we consciously use to "invisible" computing that blends naturally into our surroundings.

Early work in Ubiquitous Computing

The initial incarnation was "tabs", "pads", and "boards" built at Xerox PARC (1988-1994). Ubicomp helped kick off mobile computing research, though it is neither the same nor a superset/subset.

📌 Example — Weiser's vision: "Activate the world. Provide hundreds of wireless computing devices per person per office, of all scales (from 1" displays to wall sized)."

Weiser distinguished two paths: the "dramatic" machine (making computers so exciting we never want to be without them) and the "invisible" path (making computers so imbedded, fitting, and natural that we use them without thinking).

45.1 Wearable Computing

Wearable computers break the limitation of traditional personal computers by being worn on the body like clothing. They have been applied to behavioral modeling, health monitoring, information technologies, and media development. Government organizations, military, and health professionals use them daily. They are especially useful when hands, voice, eyes, or attention are actively engaged with the physical environment.

🔑 Definition — Wearable Computer: A computer worn on the body that provides constant interaction, multi-tasking capability, and can act as an extension of the user's mind or body.

Main features: constancy (no need to turn on/off) and ability to multi-task (augmented into all other actions). These devices can be incorporated as a prosthetic extension.

📌 Example — Military application: The US Army's Land Warrior system (eventually merged into Future Force Warrior) is the most extensive military program in wearables.

Issues

Wearable computers have led to an increase in micro-management—a society characterized by total surveillance and greater influence of media and technologies. There is concern about cameras affecting personal and private moments as a form of social control.

History

📌 Example — First wearable computer (1961): Mathematician Edward O. Thorp and Claude E. Shannon constructed a concealed cigarette-pack sized analog computer to predict roulette wheels. It used microswitches in shoes to indicate wheel speed, sending musical tones via radio to a collaborator's ear canal.

📌 Example — 1967: Hubert Upton developed an analogue wearable with eyeglass-mounted display to aid lip reading using high and low-pass filters.

📌 Example — 1981: Steve Mann built a backpack-mounted 6502-based computer to control photographic systems. He later created the Wearable Wireless Webcam (1994).

📌 Example — 1989: Reflection Technology marketed the Private Eye head-mounted display.

📌 Example — 1993: Columbia University's KARMA (Knowledge-based Augmented Reality for Maintenance Assistance) overlaid wireframe schematics on real objects being repaired, such as explaining how to change a paper tray in a laser printer.

Commercialization attempts by Xybernaut, CDI, ViA Inc, Seiko (Ruputer wristwatch), IBM (Linux wristwatch prototypes), and Fossil (WristPDA running Palm OS) met with limited success.

45.2 Tangible Bits

The development from desktop to physical environment has two phases:

1. Xerox Star workstation (1981) — First generation graphical user interface establishing the "desktop metaphor" with "seeing and pointing" design principles.
2. Marc Weiser (1991) — "Ubiquitous computing" paradigm displacing computers into the background.

Tangible User Interfaces (TUIs) make computing truly ubiquitous and invisible by changing the world itself to an interface—all surfaces (walls, ceilings, doors) and objects become interfaces.

🔑 Definition — Tangible Bits: Coupling digital information to everyday physical objects, making digital information tangible and graspable.

📌 Examples:

• ClearBoard (1990-95): Changing a passive wall to an active dynamic collaboration medium
• Bricks (1990-95): Graphical interface allowing direct control of virtual objects through physical handles called "Bricks"
• Marble Answering Machine (Durell Bishop): Incoming messages represented by marbles—user grasps and drops to play message or dial caller automatically

Goals and Concepts of "tangible bits"

Goals: Augment the real physical world by coupling digital information to everyday things, bringing cyberspace and real world together. All states of physical matter (solids, liquids, gases) become interfaces. Users should "grasp and manipulate" foreground bits and be aware of background bits. No distinction between input and output devices.

Three key concepts:

1. Interactive surfaces — Transformation of each surface into an active interface
2. Coupling bits and atoms — Seamless coupling of everyday objects with digital information
3. Ambient media — Use of sound, light, air flow, water movement for background interfaces at periphery of human perception

45.3 Attentive Environments

Attentive environments are user and context-aware. IBM's BlueEyes research project explores and defines these environments. The goal is creating computational devices with perceptual abilities that people take for granted.

🔑 Definition — Attentive Environment: An environment that senses user actions, extracts key information, and determines user's physical, emotional, or informational state to perform expected actions or provide expected information.

📌 Example — BlueEyes-enabled television: Could become active when user makes eye contact; user could then tell television to "turn on."

💡 Why this matters: Adding perceptual abilities to computers enables humans and computers to work together more as partners, rather than tools requiring explicit commands.

⭐ Key Takeaways

The most critical takeaway is that HCI is evolving from explicit, desktop-based interaction toward invisible, context-aware computing embedded in our environment. Ubiquitous computing aims to make computers "invisible in use" by integrating them into everyday objects and spaces. Wearable computing extends this by making computers part of our clothing and bodies, offering constant interaction and multi-tasking capabilities. Tangible Bits demonstrate a fundamental shift from graphical interfaces to physical objects as interfaces, coupling digital information with physical matter. Finally, attentive environments add perceptual intelligence, allowing computers to sense user states and respond proactively rather than requiring explicit commands—truly transforming computers from tools to partners.

🧠 Quick Revision Questions

1. What distinguishes Mark Weiser's "invisible" path of computing from the "dramatic" machine path?
2. What are the two main features of wearable computers, and how do they differ from traditional personal computers?
3. What were the three key concepts behind Tangible User Interfaces (TUIs)?
4. How does the Marble Answering Machine exemplify the concept of "tangible bits"?
5. What is the primary goal of IBM's BlueEyes project in creating attentive environments?