A Task Assistant

“…the primary source for serious hypertext” – Robert Coover, The New York Times Book Review

Tinderbox is a personal content assistant that helps you visualize, analyze, and share your notes. Download and try it today.


A Task Assistant

Tinderbox is a fine tool for making notes, for visualizing your ideas and for outlining your plan. But Tinderbox can also create active documents, electronic notebooks that respond to what you write and actively help you organize and analyze your notes.

This case study looks at some of the ways that lively and active Tinderbox documents can serve as an active assistant, helping you organize, visualize, and understand the complex information that we all work with every day.

You won't need these techniques for every Tinderbox project. You may not need them at all! It's nice to know that they're available, in case you need them.

Typically, you'll start small and simple and let the document's abilities emerge gradually over time. Conventional databases work best when you get the design right before you start to work; Tinderbox, on the other hand, encourages you to plunge right in and gradually organize and automate your work.

Some of the techniques in this note require Tinderbox 4 or later. This note assumes that you're already fairly familiar with Tinderbox or that you wont mind looking things up in the manual. If anything puzzles you, you're sure to find help on the Tinderbox wiki and forum, or by contacting Eastgate.

Making A List

While knowledge management is usually treated as a task for business analysts and scholars (or dismissed as a meaningless buzzword), most people need to keep track of an immense number of projects and tasks. Some are small and urgent, others are large and complex. Some may not be tentative, or ill-defined. Some may be delegated to others. The list is constantly changing.

Let's use Tinderbox to make a big ToDo list, a comprehensive list of everything we want to do. The recent popularity of comprehensive ToDo lists was inspired by David Allen's book, Getting Things Done; we wont adhere to every detail of Allens system here, but GTD fans will find this approach familiar.

To begin, we'll open a fresh Tinderbox outline and start making lists of some things we want to do. We can do this very quickly: hit to make a new note, enter its title, hit Return to finish the note and we're ready for the next task.

We're done

We're done. You could use Tinderbox effectively in exactly this way, with no further elaboration. You can add notes for new tasks. If you need to explain the task, you can write as much as you like inside the note. If a project needs to be elaborated if it turns out to contain lots of subtasks you can easily put the subtasks inside the project to keep everything organized.

You can organize tasks in the outline, or use the Map view to cluster related tasks together. You can use Tinderbox's exceptionally-fast Find window to locate any tasks you've misplaced.

True, there are lots of Tinderbox features we aren't using. It's OK to ignore affordances you don't need. Tinderbox is a personal content assistant, and its meant to assist you. If you dont need more assistance than this, thats fine.

But, as we add every task and project we can envision to our Tinderbox ToDo list, we find ourselves face to face with hundreds indeed thousands of tasks. We can handle them ourselves. But, if we like, Tinderbox can automate some of the work, helping to keep things organized and to help us understand the changing, emergent structure hidden in all this detail.


We can already see that our inbox will contain quite a variety of things small tasks, big projects, errands, inchoate desires. One important and useful distinction we might make right away, distinguishing a task a thing we can do from a project that is made up of several tasks.

We'll begin by defining two prototypes, Task and Project. We'll set the Color of the Project prototype to red, so we can quickly distinguish a simple task from a more complex project.

We've already made a bunch of notes in the inbox. We can select them all, open the Quickstamp window (cmd-1), and set their prototype to Task. Then, we can select the projects tasks in the inbox that have subtasks and change their prototype to Project.

In Tinderbox, any note can be a prototype, and you can always change a note’s prototype whenever you wish. You don't have to plan all your prototypes in advance.

Setting Prototypes Automatically

It's easy to set a notes prototype:

In fact, when you first create a note, you'll find that Tinderbox does its best to guess what Prototype you might want to use. But Tinderbox is an assistant; we can arrange for Tinderbox to do this automatically.

Whenever we add a note to a container, we apply that container's OnAdd action to the note. So, we'll add an OnAdd action to the prototype Project:

OnAdd: $Prototype="Task"

Now, whenever we add a note to any project, its prototype will automatically be set to make it as Task.

Notice that you can always change the prototype from Task to something else. The OnAdd action simply instructs your assistant to assume that things added to a project are tasks, until you say otherwise.

Sometimes, what seemed to be a single task turns out to be a project. This, too, is easy to handle automatically. We'll add a rule to convert a Task to a Project if it acquires subtasks:

Rule: if($ChildCount>0){$Prototype="Project"}

Tasks With Style

It might be nice to make Projects stand out a little more clearly amid this sea of individual tasks. To do this, we can change the visual style of the prototype Project. We might, for example:

Its important to notice how much richer Tinderbox's styling can be than the familiar approach in presentation programs like Keynote or PowerPoint, where style simply depends on the position of the note in the outline. You can, to be sure, do that in Tinderbox, but inheritance lets you do much more. As soon as a task becomes a real project (by acquiring subtasks), it acquires the style of a Project.

Use The Map

Though weve focused on using the outline view, dont overlook other Tinderbox views as well. The map view, for example, gives you interesting opportunities to brainstorm. In the map, its also easy to move things around to informally cluster related items.


Maps can be especially valuable for reviewing tasks, deciding which task is most important, and (with the aid of a projector) for facilitating discussion with your assistants and colleagues.

Making notes in a map is just as easy as making them in an outline: just double-click where you want to note to go. Need to make several notes in the same locale? Just press . (Consider setting notes to expand automatically in the map if you need to brainstorm quickly in map view and prefer lengthy note titles.)

Remember, too, that Tinderbox lets you keep many windows open at the same time. Keeping a map and outline open simultaneously lets you switch back and forth whenever you like.

What's New?

Agents continuously search your document for notes that match the agent's criteria. For example, we could have an agent find all the Tasks in the document that we've created today:

AgentQuery: $Prototype="Task:" & $Created>date("yesterday")
SortBy: Name

Tinderbox agents never move or delete your notes. Instead, they make aliases of your notes and collect those aliases. If a note no longer qualifies for the agent, the agent's alias will be deleted.

Agents are persistent searches, and can examine the note’s text, title, or any of its attributes, and agents can take actions on notes they find. A fast and efficient regular expression engine is built into Tinderbox, so agents can search for complex strings with wildcards.


ToDo lists should not be confused with calendars. Calendars are for appointments, for things that must happen at a specific time. Calendars are designed to manage times, and computerized calendars are designed to remind you of upcoming appointments. Well assume you also use a calendar or PDA to manage appointments.

Many tasks, though, have a deadline either a fixed time when the task must be performed, or a time frame in which youd prefer to see the task finished. To keep track of this information, well create a new Date attribute called DueDate in the User Attributes panel.

Now that we have an attribute for DueDate, we can add DueDate as a key attribute of the prototype Task. Since tasks inherit key attributes, a DueDate will now appear in the top of each tasks text window. The default due date is "never", but we can easily enter a specific date or an expression such as "today+3 weeks".

Another useful attribute might be a simple checkbox that indicates when a task has been finished. Well call this attribute Completed, and we'll make it a key attribute for Task as well.

The new attributes gives us new opportunities for helpful agents. One agent might search for overdue tasks:

AgentQuery: $Prototype="Task" & $Completed=false & $DueDate
SortBy: DueDate

Would you like a badge?

Tinderbox 4 introduced badges small, graphical indicators associated with each note. We might want, for example, to add a badge to mark completed tasks. It's easy enough to add badges yourself just right-click in the upper-right-hand corner of the note for a badge menu, or select the note and choose a badge from the Note menu.

But we could also let an agent handle the badge for us. This is convenient: it saves us a task. But perhaps we don’t want to delegate all authority over badges to Tinderbox. Instead, we might prefer to tell our assistant, When a task is marked as Completed, give it a the badge. But if I've already given the note a badge, leave it alone."

Our rule, then, is quite simple:

Rule: if($Completed) {$Badge|="OK";}

The special assignment |= sets the value of Badge only if Badge does not already have a value.


Assistants can be especially useful for repetitive tasks. For example, every Thursday a local farm drops off a carton of fresh vegetables for me at a nearby artisan bakery. I dont have to pick it up at a specific time; any time Thursday or even Friday will do, so this is not really an appointment and doesnt belong on my calendar. But the task does need to be rescheduled each week (until Winter, anyway). How can we handle repetitive tasks?

Its OK to do this manually. Instead of ticking off "Completed" for this task, just replace the current date with "Thursday" and Tinderbox will automatically fill in the next Thursdays date. You dont need to automate everything.

But it's also easy for an agent or a rule to reschedule this task. Let's do it with an agent:

AgentQuery: $Name(pick up farm vegetables)
AgentAction: if($Completed){$Completed=false;$DueDate=date("Thursday");}

Passing Information Down The Chain

Tinderbox notes inherit from their prototypes. Sometimes, though, you'd like a specific property to be inherited in some different, special way. Tinderbox let's you do that by letting you explain the special inheritance in a Tinderbox rule.

Let's add another new user attribute, a string called Goal and the represents the overall aim of which each task is a part. A task might remind us to set up a lunch with a promising graphic designer; the corresponding Goal might be Improve sales by next annual meeting.

We could enter the goals by hand; indeed, if we make Goal a key attribute and use the pull-down menu, well seldom need to type anything. But if we already have a thousand tasks in our list, adding all this metadata could be boring. Fortunately, we can have our assistant fill in the goals based on some simple principles.

  1. If I've set a goal, that's it. I know what I'm doing.
  2. The goal of a task is the goal of the project of which it's a part.
  3. If a project is a part of a bigger project, then its goal is the goal of the bigger project.
  4. If the project isnt part of a bigger project, its goal is the same as its name.

Writing rules for these constraints is quite simple. For tasks, principles #1 and #2 are simply:

Rule: $Goal |= $Goal(parent);

For projects, our rule slightly more complicated but still remarkably simple.

Rule: if($Goal(parent)) { $Goal |= $Goal(parent); } else {$Goal |= $Name

This lets us pass information down the hierarchy, from the big project to the smallest task. Sometimes, we may want information to travel in the opposite direction. If we have a boolean attribute Urgent that flags top-priority tasks, we might want our assistant to propagate that information upward:

  1. If a project has an urgent task, then that project is urgent

The new rule for Projects becomes

Rule: $Urgent = any(child,$Urgent);

If you found these notes intriguing, you might enjoy The Tinderbox Way, a 240-page book that explores these ideas in depth. The Tinderbox Way is less concerned with mechanics than this tutorial and more interested in why Tinderbox is designed as it is, but there's plenty of hands-on advice for interested readers.