Conceptual Models. Core to the Design of Interactive Applications

Preface
Contents
About the Authors
1 Introduction
	1.1 Where Does a Design Team Begin?
		1.1.1 Design (and Implement) the Functionality?
		1.1.2 Design (Sketch) the User Interface?
		1.1.3 Create a Conceptual Design
	1.2 Conceptual Models
		1.2.1 An Example: Calendar
		1.2.2 Contrasting Conceptual Models
	1.3 Important Decisions
	1.4 Conceptual Design’s Place in the Application Development Process
	1.5 The Benefits of Using Conceptual Models
	1.6 Organization of Book
2 Framework and Terminology
	2.1 Framework for Interactive Applications and Their Use
		2.1.1 People and Domains
		2.1.2 Tasks
		2.1.3 Plans and Activities
		2.1.4 Applications and Uses
		2.1.5 Conceptual Models
	2.2 Beyond Conceptual Models
		2.2.1 User Interfaces
		2.2.2 Implementation
	2.3 Thinking About Applications
		2.3.1 User’s Mental Model
		2.3.2 Designers’ Conceptual Model
		2.3.3 Terms for Conceptual Modeling
	2.4 Descriptions of Applications
	2.5 Designer Practice: Designing with Conceptual Models
3 What Conceptual Models Are and Are Not
	3.1 What are Models?
	3.2 What Are Conceptual Models?
		3.2.1 Unsatisfactory Descriptions of Applications
		3.2.2 Better: Task-Level Descriptions
		3.2.3 Best: Object-Operations Model Descriptions
		3.2.4 Our Approach to Conceptual Modeling
		3.2.5 High-Level Description of an Application
		3.2.6 Basis for Users’ Mental Model of the Application
		3.2.7 Design Goals for Conceptual Models
		3.2.8 Summary: What a Conceptual Model is
		3.2.9 Close Relative: Information Architecture
	3.3 What Conceptual Models Are Not
		3.3.1 Not Users’ Mental Model
		3.3.2 Not a Design Metaphor
		3.3.3 Not Just Task Models, Task-Level Scenarios, or Use Cases
		3.3.4 Not Based on the User Interface
		3.3.5 Not Formal Specifications to Automatically Generate or Simulate Applications
		3.3.6 Not the Implementation Architecture or an Implementation-Based Description
		3.3.7 Not Just the Information or Content Architecture
		3.3.8 Not Product Designer’s “Concept Design”
	3.4 Summary: Our View of Conceptual Models
		3.4.1 Conceptual Models Are
		3.4.2 Conceptual Models Are Not
4 Components of a Conceptual Model
	4.1 Domain, Purpose, and High-Level Functionality
	4.2 Concepts and Vocabulary
	4.3 Structure: Objects/Operations Analysis
		4.3.1 Declares Concepts that the Application Will Expose
		4.3.2 Introduces New Concepts, if Needed
		4.3.3 Shows Relationships Between Concepts
	4.4 Conceptual Scenarios
	4.5 Conceptual Model Issues
	4.6 Resolved Issues
	4.7 Open Issues
5 Representing Conceptual Models
	5.1 Introduction
	5.2 Outline
	5.3 Table or Spreadsheet
	5.4 Unified Modeling Language (UML) Diagram
	5.5 Entity-Relationship (ER) Diagram or Concept Map
	5.6 Conceptual Scenario
6 Two Complete Examples
	6.1 Example 1: Server Management Console
		6.1.1 Purpose
		6.1.2 High-Level Functionality
		6.1.3 Major Concepts and Vocabulary
		6.1.4 Conceptual-Level Scenarios
		6.1.5 Resolved Conceptual Design Issues
		6.1.6 Open Conceptual Design Issues
	6.2 Example 2: Web-Search Service for Professionals
		6.2.1 Domain and Purpose
		6.2.2 High-Level Functionality
		6.2.3 Major Concepts and Vocabulary
		6.2.4 Objects/Operations Structure
		6.2.5 Task Hierarchy Enumeration (from Task Analysis)
		6.2.6 Conceptual-Level Scenarios
		6.2.7 Resolved Conceptual Design Issues
		6.2.8 Open Conceptual Design Issues
7 Essential Conceptual Modeling
	7.1 Basic Objects/Operations Analysis
		7.1.1 First Step: Identify the Objects, Attributes, Attribute Values, and Operations
		7.1.2 Objects Are UI-Independent User-Manipulable Content
		7.1.3 Assign Operations and Attributes to Objects
		7.1.4 Assign Operations to the Appropriate Object(S)
		7.1.5 Decide How to Model Similar Objects
		7.1.6 Decide Whether to Include and Expose a Parent Object as Well as Its Subtypes
		7.1.7 Identify the Attributes of Each Object-Type
		7.1.8 Decide What Type of Values an Attribute Has
		7.1.9 Watch Out for Hidden Objects
		7.1.10 Decide How Detailed to Be in Modeling Common Operations
		7.1.11 Include All Task-Relevant Operations
		7.1.12 Remove Obsolete Concepts
		7.1.13 Part-of and Containment Relationships Need Not Always Be Distinguished
		7.1.14 Include Software Developers Who Have Experience with Object-Oriented Programming
	7.2 Supporting Learning
		7.2.1 Metaphors
		7.2.2 Consistent Terminology
	7.3 Conceptual Model Versus User Interface
		7.3.1 UI Terms Versus Conceptual Terms
		7.3.2 Interactive Concepts
	7.4 Object Identity
		7.4.1 Containment
		7.4.2 Synchronizing Objects
		7.4.3 Inheriting Attributes
		7.4.4 What Work is Saved, When? And Can I Reverse It?
8 Enhanced Conceptual Modeling
	8.1 Using Companion Models
		8.1.1 Progressive Disclosure
		8.1.2 Component Models
		8.1.3 Surrounding Models
	8.2 Modeling Interactions
		8.2.1 Managing Errors
		8.2.2 Anticipating Trouble
		8.2.3 Macros: Capturing Activity
	8.3 Evolving the Application
		8.3.1 Managed Growth
		8.3.2 Anticipated Growth
		8.3.3 Unanticipated Growth
		8.3.4 Embedding in Social Domains
9 Process of Designing with Conceptual Models
	9.1 Overview of the Process
	9.2 Start with User Research to Understand Users and Tasks
		9.2.1 User Profiles
		9.2.2 Task Analysis
	9.3 Based on User Research, Start Designing a Conceptual Model
		9.3.1 The Conceptual Model is Central to the Design Process
		9.3.2 Coordination is Required
		9.3.3 One Team Member Should Drive the Conceptual Design
		9.3.4 Include Developers, but Keep the Conceptual Model Focused on User-Facing Objects and Tasks
	9.4 Use the Conceptual Model to Coordinate Development
	9.5 Iterate, Iterate, Iterate
		9.5.1 Including Conceptual Models in Agile Development
		9.5.2 Testing Conceptual Models
	9.6 Getting from CM to UI
		9.6.1 Object-Based Versus Task-Based UIs
10 Benefits of Designing with Conceptual Models
	10.1 Produces a Vocabulary
	10.2 Facilitates Creation of Conceptual Scenarios
	10.3 Facilitates Creation of User Documentation, Training, and Support
	10.4 Focuses User Interface Design: Gives Designers a Clear Target
	10.5 Jump-Starts and Focuses the Implementation
	10.6 Supports Further Task Analysis
	10.7 Supports Controlled Iteration of a Design
	10.8 Facilitates Communication Between Team Members
	10.9 Saves Time and Money
	10.10 Conclusion
Glossary of Terms Used in This Book
Appendix: Origins, History, and Contributing Fields
	Database Design and Development, Software Engineering, and Simulation
	User Interface Design
	User Interface Engineering and User Interface Management Systems
	Task Analysis and Task Models
	Information Architecture
Bibliography