Home Projects Publications
1. Action-oriented
2. Anchoring in domain
3. Support error handling
4. Support various uses
Minimalist principle 2: Anchor the tool in the task domain

For most users, an application is a tool they want to use to achieve objectives in their own task domain. The tool is merely a means; it is almost never an end in itself. The designer should therefore select or design instructional activities that are real tasks. To the greatest extent possible, these tasks should be selected from the core tasks of the application domain. These tasks provide a structural template for learning activities; they are a rubric and a meaningful context for the presentation of information. In addition, they provide concepts and terms with which to present and explain an application. The design strategies that belong to the principle to anchor the tool in the task domain are:
Heuristic 2.1: Select or design instructional activities that are real tasks
Heuristic 2.2: The components of the instruction should reflect the task structure
Heuristic 2.1: Select or design instructional activities that are real tasks
The user is preferably instructed to pursue goals and activities that can instantly be recognized as genuine. These tasks can be quite modest. For example, the documentation of Northern Telecom's Norstar system suggests the task of customizing the ring on one's own telephone. In word processing core tasks are typing, formatting, saving and printing and these should form the fundamental setup of the documentation. In domains in which the genuine tasks are not self-evident, designing instructional activities around real tasks is more difficult as well as more important.
Often there is a problem with prerequisites. The user’s prior knowledge in the task domain may be limited, or it may take (too) much time and effort to practice on something meaningful. In the programming domain one solution to this problem is to provided users with applications and suggest that they extend or debug these. For example, in a game called Gomoku users were asked to debug it from a special stealMove method that permitted the game to occasionally take two moves at once. Removing the bug created a realistic and meaningful programming task. In this way users were motivated to solve the problem and in doing so practiced important programming skills.
One can also consider providing users with sample files to relieve them from unnecessary chores. For example, users may be offered templates that help create a fully formatted text but that do not hinge on having to specify all the codes for headings, fonts or margins. Similarly, tutorials may include a training diskette with sample files. Users can then access a file with a focused exercise when this is indicated in the manual.
Heuristic 2.2: The components of the instruction should reflect the task structure
The structural organization of a manual is one of the most critical issues in designing for documentation that is anchored in the task domain. The headings should therefore be crafted to convey the major procedural elements in the instructional tasks. Headings should help the user keep in view the big picture of the skill being learned. For example, in presenting the basic createsave-andprint scenario in word processing subsections entitled “Starting a new memo”, “Working in the typing area”, “Saving your work” and “Requesting a print” are much more effective than “You can typeset your own letters”, “Switching to and from the DOS command line”, and “Tips for users of WordPerfect”. The latter headings do not suggest anything at all about the task organization; they do not give the user the big picture.
Figure 1 shows that the headings in the MiTTS manual give an overview of the main tasks in the domain. The manual introduces Smalltalk to users who must learn this programming language. Applications accompanied the manual and early on in the documentation (as signaled by the page locators) users were invited to engage in a programming task. The chapter subheadings in “Exploring the Blackjack Game” summarize what the user does here: open a browsing tool, use the tool to survey the code for a Blackjack game application, use the code to create an instance of the Blackjack class, further explore the code by sending some simple messages to the Blackjack instance, and then continue to explore some other objects used by Blackjack and some further message sending relations. Not by incidence, this is also the basic structure of the prototypical scenario for code exploration in Smalltalk programming.
The Smalltalk Mountain 1
Introducing the Blackjack Game 3
Topic 1: Exploring the Blackjack Game 5
Starting up the Bittitalk Browser 5
The Blackjack game 6
Creating an instance of Blackjack 6
Sending messages to the Blackjack instance 7
Exploring other objects and messages used in Blackjack 8
Topic 2: A User Interface for Blackjack 11
Starting up the View Matcher 11
Playing Blackjack interactively 11
How is a deal request made? 12
How is the result of dealing displayed? 15
How does the player take a hit? 17
How did Blackjack’s user interface get set up? 18
Topic 3: Enhancing the Blackjack Game 21
Starting up the Blackjack game 21
Parsing the Blackjack hitPlayer method 21
Changing the meaning of the stay message 26
Topic 4: Enhancing the Blackjack User Interface 29
Playing the enhanced Blackjack game 29
Re-visiting the Blackjack menus 29
Modifying the dealer menus 31
Feel like cheating? 33
A more challenging enhancement 35
Figure 1. The Table of Contents for the second Minimal Manual (MiTTS).
The headings focus the user’s attention on code exploration in a specific way. All headings refer to the Blackjack project. A disadvantage of specific headings is that the user must extract the general schema of Smalltalk programming activities. For this purpose, general headings can be more effective. Even when people find very concrete examples useful, they sometimes are hampered by examplespecific headings. In addition, when instructional materials are reused as reference material, general headings are better search keys.
Misconception: minimalism is just another word for job aids
It has been argued that the essence of minimalism is little other than a plea for job aids. This comment is understandable because minimalism aims to get users started quickly on real tasks. To a considerable extent this involves conveying basic procedural information in a very succinct form. In this sense minimalist instructions resemble job aids which are succinct procedures.
Typically however, job aids are used for reference by people who have already received instructions. In addition, most job aids are not designed to convey a model of the system or the task domain. They are often an arbitrary set of cards that belong together only because they are packaged together. Job aids are not designed to provoke task-oriented reasoning on the part of the user, but merely to support execution of a set of steps. They are intended merely to help people ‘play back’ a set of instructions.
One of the earliest projects developed and studied in the minimalist approach was the one most similar in design to job aids. Guided Exploration cards were an early exploration of optimizing the support for secretaries learning to use word-processing equipment. The cards were deliberately incomplete, often providing only hints, so that users would stay focused on the task. Each card also included specific checkpoint information and error-information.
Unlike job aids, the Guided Exploration cards only occasionally offered explicit prescriptions for procedures. Whenever possible, users were given instructions that were general enough to also support user actions for related procedures or tasks. Moreover, the Guided Exploration cards provided frequent feedback. Each card included at least one explicit coordinating anchor between the system state and the instructions.
The mere presence of error-information in the Guided Exploration cards does not distinguish them from job aids. What sets the two apart, however, is that in the Guided Exploration cards regular (‘constructive’) procedural instructions were accompanied by error-information. In short, the Guided Exploration cards differ in several important ways from job aids. Subsequent minimalist projects (e.g., the first Minimal Manual) emphasize this difference even more, thereby drawing the distinction even more sharply.
Carroll, J.M., & Van der Meij, H. (1998). Ten misconceptions about minimalism. In J.M. Carroll (Ed.), Minimalism beyond the Nurnberg funnel (pp. 55 - 90). Cambridge, Mass: MIT Press.
Van der Meij, H. & Carroll, J.M. (1998). Principles and heuristics for designing minimalist instruction. In J.M. Carroll (Ed.), Minimalism beyond the Nurnberg funnel (pp. 19 -53). Cambridge, Mass: MIT Press.