Tinderbox Way

3rd edition
Mark Bernstein
© Copyright 2006-2017 by Eastgate Systems, Inc. All Rights Reserved.
ISBN: 1-8845-1154-6
Tinderbox™ and Storyspace™ are trademarks of Eastgate
Systems, Inc., and CIVILIZED SOFTWARE is a service mark of Eastgate Systems, Inc. All other trademarks are the property of their respective owners, and are used for identification or illustration purposes only.
Eastgate Systems, Inc. 134 Main Street, Watertown MA 02472
The Tinderbox Way
1.The Tinderbox Way 1
2. Building Tinderbox 14
Design Note: Artisanal Software 24
3.Notes 30
Design Note: How Large Is A Note? 41
4.Lists And Containers 47
Design Note: The Hierarchical Backbone 60
5.Attributes And Values 70
Design Note: Another Level Of Indirection 83
6.Prototypes 88
Design Note: Inheritance 102
7. Tinderbox Maps 106
Design Note: Hiding And Revealing Detail In The Tinderbox Map 131
8. Emergent Structure 139
9.Shaping Space 156
Design Note: Kibbitzers vs. Parsers 159
10. Treemaps 165
11.Agents 171
Design Note: Aliases 193
12. Actions 200
13.Dashboards 229
Design Note: Tinderbox Designators 241
14.Links 247
Design Note: Internal and External Links 267
15.Planning Fiction 270
16.Promoting Consistency 289
17.Time 297
Design Note: Dates Are Complex 308
18.Planning with Tinderbox 311
19.Research Notes 318
20.Open Questions: Using The Attribute Browser 335
Design Note: The Attribute Browser 344
21.Making Tinderbox Your Own 345
Design Note: Gradual Customization 348
22.Sharing Lists and Outlines 349
23.Sharing Notes: Export Templates 366
24.Interlude: Living With Notes 380
25.Why Is Tinderbox Complicated? 414
Cooking The Software 420
27.Discovered Geometries 432
28. Project Management 440
29.The Information Farmer’s Almanac 465
30. Art And Engineering 476
1. The Tinderbox Way
Tinderbox is a software tool for making, visualizing, analyzing, and sharing notes. It’s an unusual piece of software: at a time when most new programs are revisions within a familiar genre, Tinderbox attempts something new.
This book explores ways you might use Tinderbox and explains why Tinderbox works as it does.
Tinderbox is a tool for making notes, a personal content assistant. Notes are intensely personal, but their impact on your effectiveness and accomplishment, public and private, can be tremendous. Writing things down in a place where we can find them again helps us make sure that we can consider every aspect of our decisions. The importance of making, analyzing, and sharing notes applies not merely to weighty decisions, like choosing what kind of car to buy or in which mutual fund to invest, but also to the hundreds of tiny decisions we make every day, selecting what we’ll do next and what we’ll postpone.
I often hear people talk about a book, a film, a party that changed their lives. But how many people have heard about a book that might have been, for them, that crucial book, only to forget all about it? How often do we fail to find the time to see a film or a play we ought to have seen? How many times have we been too busy or preoccupied to remember to drop by a party where we just might have met someone who would have changed… everything?
Our choices are important, and also personal. If we make them thoughtlessly, if we leave them to chance and memory, how can we be confident that we are doing all we can do? And doing what we ought?
We learn by remembering and by reviewing experiences. By preserving our notes, we create new opportunities for learning. What were you reading, this time last year? What do you think about it today? What do you think, now, about that movie that seemed so original, or so controversial, just a few months ago?
Will you even remember to reflect on it, a few months from now? Who will remind you?
An Energetic Assistant
Tinderbox is designed to help you write things down, find them, think about them, and share them. Tinderbox is an assistant. It’s meant to help, to facilitate. It’s a way to write things down and link them. It’s a tool to be guided by your hand and your intelligence, for projects that often last months or years.Tinderbox can sometimes be handy for short and small projects, but it is at its best with projects that last months or years, projects that are likely to grow or change over time. Whether you’re planning new products or plotting a complex novel, managing a campaign or designing an innovative curriculum, Tinderbox can adapt to your growing and changing understanding.
Software often uses computers to emulate passive media. Paint programs use the screen to imitate canvas or to recreate the photographic darkroom. Word processors emulate typewriters. Tinderbox can go further than this; you can build Tinderbox documents that automatically help organize your work, that notice mistakes and omissions, and that call attention to new and unexpected relationships.
Most Tinderbox documents express themselves with visual cues. Overdue tasks might be colored red, or a distinctive icon might be placed next to your most active customers. When necessary, though, Tinderbox can speak to you, send messages through Twitter, or launch other programs.
Tinderbox documents can take a variety of actions to help keep themselves consistently and well organized. Containers can sort their contents in lots of different ways, or can leave you to arrange things yourself. Containers can take actions when notes are added or removed from them. Tinderbox agents scan gather together notes that meet specific criteria, and they, too, can perform actions on those notes. Other notes may be associated with specified files, with records stored in other programs, or with information from the Internet.
A Personal Assistant
Tinderbox is personal. It’s designed to help you do your work better and to help you enjoy it more.
Tinderbox does not impose a way of working; it’s neither a workflow nor a methodology. Tinderbox doesn’t tell you how to take notes, but instead provides you with a number of different ways of making them. Tinderbox doesn’t provide a framework into which you fit your project, but instead provides a variety of tools to let your notes gradually play a role in keeping themselves neat and organized.
Tinderbox is personal in another sense, as well; unlike most corporate software today, Tinderbox was designed and implemented by a person—not by a committee, a corporation, or a focus group. That person is me: Mark Bernstein. I designed Tinderbox, and wrote just about every line of the tens of thousands of lines that make Tinderbox run. Tinderbox is the product of an individual vision. It wasn’t written to meet requirements or specs or to adhere to business rules.
Along the way, there have been thousands of decisions— engineering decisions, artistic decisions, operational decisions. In the end, I made the choices. I didn’t need to persuade the Development team to code Tinderbox the way I wanted: I was the development team. I didn’t have to fight Management and Marketing for features. But Tinderbox has always been short of resources. There is never enough time, never enough hands to do all the work. I have made plenty of mistakes, and when those mistakes became visible, I had to decide whether to live with them or to start over.
According to current wisdom, this is the wrong way to build software. We’re told that software specifications should be based on meticulous studies of user needs and corporate goals, that specialized interaction designers should plan the interactions and specialized graphic designers should plan the graphics, that the code should be specified by product specialists and then written and tested in software factories located in distant, low-wage countries. Documentation, packaging, and marketing specialists add their special skills.
Good software sometimes comes from organizations that operate like this, but it’s a process of consensus, of design by negotiation. At its worst extreme—an extreme we see more and more often in software today—it generates the blandness of design by committee.1
Tinderbox is an argument for artisanal, hand-crafted software. Artisanal software is opinionated. It may be unpolished. It may have fingerprints or rough edges. But it expresses the views of someone who thought about it and crafted it, not those an investment team has convinced itself to find in a focus group2.
The Productivity Puzzle
If Tinderbox is an assistant, it ought to help you. Do computers actually help? Or do they merely replace some old-fashioned clerical drudgery—ledger books and file cabinets—with new chores like reading spam and filling out Web forms? Economists, looking to measure the productivity gains realized by widespread adoption of personal computers in business, have found it surprisingly difficult to demonstrate that computers help at all.
I’d like to suggest that this isn’t the fault of the computers. It’s not a matter of bad design, of poor user interfaces or faulty error messages or cryptic documentation. Computers have given us enormous wealth and productivity, but we’ve chosen to spend that wealth in a way that makes it hard to see and to measure.
When we watch movies about 20th-century business life—Jack Lemmon’s office in The Apartment, saywe marvel at the clumsiness of business procedures that were, quite recently, state of the art. Banking transactions that once were manually recorded by tellers and checked by clerks are now handled by robotic ATMs or rendered unnecessary by credit cards. Mechanical phone indexes, rotary dialers, electric typewriters: all seem as arcane today as the crimson ribbons, known as “red tape”, that tied bundles of documents together in a time before manila folders and paper clips. Cutting and pasting were, only yesterday, performed with glue, and a misspelled word was best repaired by retyping the page on which it was found. Computers, obviously, save time. They make us greatly more productive (and far less bored) at work.
Yet, if you examine economic statistics, it’s remarkably hard to show that computers have improved everyday business productivity3. It takes about as much time, and about as much expense, to compose routine business correspondence today as it did a generation ago. The costs of making a sales call or closing a real-estate transaction, measured in real dollars, are roughly what they used to be. A new best-selling novel costs about as much as an entrée in a nice restaurant—just as it did in 1930, and in 1790. But that book in 1930 was composed on a manual typewriter and set in hot type; the 18th-century book was written in longhand with a quill pen and hand-set by compositors who picked tiny letters out of type trays. Today’s writer uses a word processor and delivers electronic files to the publisher, and the publisher in turn sends electronic files to a printer.
Yet, somehow, economists cannot detect an increase in productivity. Where did the money go? Computers do enhance our productivity; we simply have spent that productivity in ways that are not always, immediately, apparent.
Aesthetics. Business materials today are more attractive, more accurate, and better designed. I can remember, as late as 1980, receiving an annual report for a publicly traded corporation that had been prepared on a typewriter and reproduced by mimeograph. Today, the most routine business correspondence is typeset, and we think nothing of adding line drawings and illustrations to print collateral, even material designed for a very small audience. Though the audience may be a single manager, we often use graphic design tools that, in the past, would have been far out of reach
Presentation. The 1990s witnessed a presentation arms race in the lecture hall and in the conference room. People who once thought it sufficient to use chalk on slate now routinely create elaborate PowerPoint® presentations. Firms that once answered technical queries from other businesses with plain typed reports—the original “white papers”—now respond with print-on-demand books, custom-generated full-color reports, and elaborate Web sites.
Drudgery. Each elevator once required a full-time operator. This must have been a terribly dull job, moving up and down, day after day. Easily automated jobs are unsuitable for people; as a society, we’ve chosen to spend some of our productivity gains in order to avoid assigning people to
dull, dirty, and dangerous work. Computers replaced a legion of boring jobs with vastly more interesting, autonomous, and fulfilling positions. Big business in the early twentieth century required vast numbers of typists, file clerks, and bookkeepers simply to manage the flow of paperwork. Mail orders routinely took six to eight weeks for processing. As late as the second world war, the U. S. Army in Europe stockpiled more than 800,000 separate items, any one of which might be an immediate necessity somewhere—yet inventories and requisitions for every item had to be written with fountain pen or typewriter, copied, filed, and filled.
Yesterday’s secretaries and file clerks became today’s branch managers, software designers, and IT directors. They make a lot more money and consume a lot of expensive resources in their new roles—and thus seem less productive—but that’s just a statistical illusion. As late as 1990, a keynote speaker at an international computer conference might assert with confidence that personal computers would not be accepted in the executive suite until we could get rid of keyboards. Keyboards were for secretaries and file clerks.
When a business makes a profit, it may choose to spend some of that profit making the workplace more pleasant—painting the walls, buying more comfortable chairs, or throwing a spectacular holiday party. Some of these may be profit-earning investments, but others are simply profit sharing: a business rewards its workers through both monetary and non-monetary rewards. As a society, we’ve chosen to use the profits that computer productivity has generated on non-monetary rewards.
Some of those choices now seem wise, and we wonder why we waited so long. Others strike me as less convincing, especially the shift toward elaborate production in internal corporate communication and presentations. But, if our rival is submitting typeset and illustrated reports, dare we limit ourselves to the economical simplicity of plain white sheets and hand-lettered sketches?
In any case, that’s where the money went. Society made its collective choice. The computer did its share, and if we have spent the profits unwisely or imprudently, it’s wrong to blame the computer that generated the opportunity in the first place.
The Right Way To Do It
In over thirty years of designing and building hypertext tools at Eastgate, we’ve been very reluctant to tell people what to do, to presume to instruct the people who use our software. Our opinions are embodied in the design. But Tinderbox is a new kind of software, and even computer professionals have grown unaccustomed to meeting new software. People ask me, over and over, What should I do? I receive letters from all over the world, asking, Where do I start? And, What do I need to learn?
Software designers, like all artists, work to anticipate the needs of their audience, but one of the first lessons of software design is that real people use real software in really astonishing ways. “The street finds its use for things,” William Gibson wrote in Neuromancer.
This book contains my best advice. Throughout, I try to emphasize underlying concepts and ideas rather than mechanical details. Here, I want to recommend conceptual approaches to undertaking important work with Tinderbox, and to explain why Tinderbox works as it does.
Throughout this book, I affect more confidence in my opinions and in my conclusions than is actually warranted. Often, experience and evidence weigh on both sides of a question. If I properly qualified each bold assertion, this book would be tiresome, and tentative.
If you see a better way to do something about which this book is silent, you may well be right. If you envision a new application I don’t mention, it may well prove superior to the examples discussed here. If your experience does not agree with mine, your working environment may well be different. These are the notes of an early explorer; I hope you will find them a trustworthy guide but, if you find the map disagrees with the terrain before you, by all means trust the terrain.
Learning About Tinderbox
This book assumes that you are generally familiar with the elements of Tinderbox. If you’re new to Tinderbox, it may help if you explore the program a little, and spend some time with the manual, just to get your bearings.
In the Tinderbox Help menu, you’ll find Getting Started With Tinderbox, a detailed tour of some core Tinderbox features. This is probably the best introduction to the mechanics of using Tinderbox.
The Tinderbox User’s Manual will also be found in the program’s Help menu. It contains a wealth of information, not all of which may be evident at first glance.
Tinderbox is actively growing, and Eastgate is constantly adding improvements and new features. We recommend using the latest release of the program—even if it happens to be newer than the Tinderbox used in these pages. The confusion created by small discrepancies in the program’s appearance will be offset by better performance in the latest version. You can always find the latest release at
Since Tinderbox comes with a year of free upgrades, you’ll most likely be able to download the latest version and get down to work immediately.
In the Tinderbox User’s Manual found in Help Tinderbox Help, you’ll find Release Notes for each new version of Tinderbox. These notes can be a valuable guide to new features that you might overlook.
The Tinderbox forum
hosts an active and generous community of Tinderbox enthusiasts. There you will find a remarkable diversity of ideas and opinions about the best ways to use Tinderbox for all sorts of tasks, from course planning to plotting novels.
Mark Anderson has long maintained the wonderful Tinderbox resource, aTbRef (A Tinderbox Reference), a large Tinderbox document and Web site that contain a wealth of detailed information about Tinderbox.
The Tinderbox Cookbook is a Web site that provides examples of every Tinderbox action and expression in use. This can be an invaluable reference when writing complex actions.
Finally, when things are puzzling or when you’re stuck, never hesitate to email Tinderbox support.
Try things out. Tinderbox makes it so easy to build large and complicated projects that, at times, the project may outrun your understanding. If you aren’t quite sure how a feature works, try making a sample document just for practice. Many of the projects described in this book make excellent practice documents; most take only a few minutes to build once you’ve grasped the underlying concepts.
Things Change
This book was originally written during development of
Tinderbox versions 2 and 3. The second edition was written during development of Tinderbox 5.9-5.11 and the early stages of Tinderbox Six. This third edition is written for Tinderbox Tinderbox 7.
Over time, Tinderbox will grow and change. I will adapt this book as well, but some aspects of the program—especially cosmetic aspects—might not coincide exactly with the descriptions here. You’ll find complete, up-to-date information in the Tinderbox User’s Manual, in the Tinderbox Release Notes found at the end of the user manual, and in Mark Anderson’s online aTbRef.
About The scenarios
The scenarios and examples in this book are based on real projects, but the details are entirely imaginary. Any resemblance to actual persons living or dead, places, or organizations is entirely coincidental.
My colleagues at Eastgate, and in the hypertext research community, played large and crucial roles. At Eastgate, Eric Cohen, Diane Greco, and Stacey Mason supplied dozens of ideas and plenty of useful skepticism when things started to go astray. Meryl R. Cohen, Barbara Bean, Jen Muehlbauer, Elin Sjursen, and Estha Blachman lent willing hands to tackle what needed to be done. Robina Williams provided invaluable editorial advice for the first edition, Rosemary Simpson made many useful corrections for the second and third editions, and the advice of Dr. Eric P. James was invaluable to this revision. Tinderbox takes many fine ideas from Storyspace, the hypertext writing environment originally written by Jay David Bolter, Michael Joyce, and John B. Smith, and from VIKI, the pioneering spatial hypertext system created by Catherine C. Marshall and Frank Shipman. The good parts of Tinderbox are largely theirs.
Mark W. R. Anderson has provided countless fine ideas, superb
testing, and tireless support for Tinderbox and its community.

2. Building Tinderbox

The original vision for Tinderbox grew from exasperation with limitations of the first generation of writing tools for personal computers. Eastgate has long been deeply engaged with the development of hypertext—interlinked writing—and by the start of the 21st century it was clear that many important ideas about hypertext were not making their way from the laboratory to the personal computer. In particular, a focus on rich visual media— video, animation, digital photography, and personal music studios —had led to a general neglect of tools for working with ideas and an undue emphasis on tools for polishing presentations.
Since the early 1990s, Eastgate had been responsible for Storyspace, a tool for writing and publishing complex linked narratives. Tinderbox sought to take lessons learned in the research lab and to use them for working with the raw materials of thought, ideas, and texts, rather than for packaging presentations for managers.4
Later, the shift from the desktop to the Web led to further changes in personal computing that tended to diminish individual voice and individual ideas. The software industry had come to believe, or agreed to pretend, that work was fundamentally simple, a matter of filling out forms and filing reports. This was not the kind of software I wanted, because this is not the sort of work I most want to do.
What I Wanted To Do
Tinderbox offers many ways to look at a collection of notes. Projects frequently require hundreds or thousands of individual notes that may accumulate over months or years. These notes are too numerous to see at once or to arrange clearly in a single view. Instead, we offer lots of different views.
Crucially, these views are not simply visualizations or pictures of data stored elsewhere. Each view offers you opportunities not merely to see, but also to change, revise, and extend your notes.
Tinderbox has always sought to make things as simple as they can be, but no simpler: real ideas, and everyone’s everyday work, are much more complicated than marketing scenarios typically suggest. Tinderbox does not hide necessary complexity: some work is difficult, and Tinderbox does not pretend it’s not. Some ideas are hard to express, or are deeply entwined with other ideas; Tinderbox tries to find ways to reveal, not hide, that complexity.
Tinderbox documents are lively. Notes are not static lumps of text. Instead, they work together to help organize themselves, to correct errors, and to call attention to gaps. Bricklin and Frankston’s invention of the spreadsheet changed the way people look at numerical worksheets5; Tinderbox strives to bring the same power to working with facts and ideas.
Tinderbox documents are meant to be used for challenging projects that may last weeks or months. Tinderbox encourages you to adapt these documents to your own needs and preferences— not just through surface qualities of colors and fonts, but by letting the document help organize itself. Tinderbox documents can talk back to you, too, keeping tabs on your progress and deadlines, flagging inconsistencies, or automatically suggesting likely metadata for new notes.
Tinderbox agents scan your document continuously, searching for notes that satisfy their criterion. One agent might look for “Overdue tasks.” Another might identify “Scheduled site visits with incomplete contact information.” Agents can perform actions on the notes they identify.
Tinderbox uses the prodigious capacity of contemporary computers to automate tedious knowledge work, work too boring to do yourself.
At the outset of a project, we seldom know exactly how it should be organized. We may adopt a preliminary organization scheme, but of course growing experience and knowledge are bound to provide new insights. We cannot hope to classify everything immediately, and we cannot expect that our first classification will always be perfect. Keeping work organized is a continuing commitment.
Often, people are reluctant to organize notes. The preliminary organization may be wrong, after all; the work will need to be redone, so why do it at all? Despairing, some have argued against trying to organize at all, suggesting that searching an unorganized collection is all we can hope to do6.
Tinderbox tries to make it easy to classify notes and to move them when we discover that they belong elsewhere. Containers hold notes; any note can be made into a container by dragging another note inside it. Aliases let the same note appear in several different containers to reflect a multiple or uncertain classification. In map view, we can use adornments to gather together a cluster of notes in an informal group that is even less emphatic than a container, or composites to combine several notes into a larger object.
Knowledge representation is a branch of artificial intelligence research that focuses on efficient ways to record or represent concepts and ideas. For example, an alphabetical index lets you find a topic in a book more quickly than scanning each page in turn, and using a precise designator (“Look! There is a bald eagle on the belfry.”) is more efficient that a more generalized description of “an exceptionally large, dark brown raptor with a white head that is standing at the apex of the cupola of the village’s structure for non-secular ceremonies.” One of the principal challenges of knowledge representation is common sense —that vast body of knowledge that is perfectly obvious to any person but that requires fastidious and exacting programming if it is to be made available to a computer.
Though the AI efflorescence of the 1980s and early 1990s is now misremembered as a failure, the techniques of programming developed in this era gave us unprecedented ability to cleanly represent facts on a computer and to reason about those facts with the computer’s aid7. Tinderbox puts many of these tools at your disposal. They are not magic; computers are mere mechanisms. But rich representational facilities help people make collections of notes that evolve and grow.
Different Tinderbox tasks can benefit from common sense assumptions about completely different objects. A dermatologist’s Tinderbox might benefit from knowing that each office visit is made by a patient who has a name and an address. The Tinderbox notes kept by a student of indigenous folk music might benefit from knowing that each song collected in their field work has one or more performers, a duration, a recording call number and track number, and a musical key signature. A birdwatcher’s field notes have no particular use for either of these, but would benefit from knowing that a sighting reports the observation of one or more members of a species in a particular place, and that a second sighting reported a few minutes later is likely to be from roughly the same place as its predecessor.
Of course, these common-sense rules have exceptions, and our notes must be prepared for them. The dermatologist may treat a homeless person who has no address, or a sailor who is almost constantly as sea. A song in the collection might have no key signature, or the recording might have been lost but some information about the performance recalled from memory. These exceptions are unusual phenomena; our system can make assumptions provided that we can easily correct it when those assumptions are wrong.
Inheritance is an indispensable approach to reasoning about the properties of objects and concepts, originally growing out of AI research in the 1980s. No knowledge engineer or programmer today would think of working without inheritance, but the tools of object-oriented programming have long remained the province of computing professionals. Tinderbox was the first system to expose inheritance to people who simply needed it to do their work.
Tinderbox adopted an unusual form of inheritance—prototype inheritance8—to help users experiment with and understand inheritance. I expected that mastering inheritance would be a significant obstacle for many people, since the topic often requires weeks of attention in elite college courses. As it happens, relatively few people find inheritance difficult, not least because Tinderbox makes it easy to experiment with inheritance and to see at once the effect of changes.
Links connect notes to each other. Tinderbox links can be anchored in an entire note, or in a specific text span. Links have a type, sometimes called the path, and different paths may have distinct appearance.
Tinderbox can also connect notes to external resources. URL attributes associate a note with anything accessible by a URL— web pages, other internet data, and data stored in local repositories like DEVONthink Pro and Yojimbo. File attributes associate a note with an external file or folder, making it easy to write notes about that file and to open the file, if wanted, in its natural environment.
Actions and rules form implicit linkage that can connect notes in patterns dictated by underlying ideas.9 Tinderbox actions often refer to other notes with reference to their relationship to the note that performs the action; for example, the action
$Color(parent)="red" will set the color of this note’s parent note. In Tinderbox actions like this, the “$” symbol indicates that we are referring to the value of the attribute named “Color”. Other actions refer to notes by their name and the names of their ancestors, separated by the slash character; for example, the action
sets the color of this note to the color of the note named “Tolstoy” which can be found inside the the note named “configuration”.
Content management grew out of the needs of newspapers and magazines, organizations that need to coordinate the flow of work amongst numerous writers, editors, and compositors. These are the specialized needs of large organizations.
Individual writers and individual documents have a similar need, a need to assemble a complete work from its component parts. We cannot know in advance exactly how the reader will want to assemble these parts, and in fact users may want to assemble them in different ways to meet different needs. We might want to export a summary for a Web site and a more detailed discussion for print publication. We might want to export the text of selected notes for an email message, or we might need to build a file of extracted data—patient names and mailing addresses, or song titles and durations—to share with other computer programs. Some of those programs might be specialized, and some might not even have existed when we began our work.
Tinderbox lets you write export templates that describe what you want to export, and how you want it to appear. Export templates are notes that supply an example of what should be exported and how the information should be formatted. Different notes may use different templates; often, different kinds of notes will inherit their export templates from their prototypes.
What Tinderbox Isn’t (and Why)
Tinderbox is unusual software. There aren’t many programs like it. At times, people try to make Tinderbox attempt things at which it doesn’t excel.
Don’t try to fit a square peg in a round hole; use programs to do what they do best. The cost of an extra application or two is insignificant compared to the value of your time.
Tinderbox works best when you have hundreds or thousands of notes—especially when the notes are not all exactly alike. If you need to manage a million items, or if every note in a project contains the same sort of information as all the rest, consider using a database.
It’s easy to move from Tinderbox to a database, or from databases to Tinderbox. Tinderbox’s export tools make the transition between a large Tinderbox and a small database easy. Similarly, almost any database can summarize its data as a comma-separated file, which Tinderbox can readily import.
Repositories are programs that maintain collections of disparate media objects—photographs, scanned documents, receipts, plane tickets, pdfs—so that they may be stored, backed up, and searched in a single place. Many repositories let you add notes to the objects they hold, but repositories are primarily data warehouses and the notes serve to label your storage bins.
Repositories are often invaluable adjuncts to Tinderbox, but
Tinderbox is not a repository. You can store images either in Tinderbox or in a repository, but Tinderbox is not chiefly concerned with images. Tinderbox’s facilities for sorting, searching, and organizing work best with text. Tinderbox files aren’t very efficient for storing images; this presents no problem if you want to store a modest number of images but can be costly if you want to store thousands.
What is the natural size of a Tinderbox document? All writing systems envision some limited range of sizes for which they perform best. Scrolls are limited by wrist strength, codex books by the tendency of thick bindings to crack and wear out, and also by the sheer weight of the volume. What limits Tinderbox documents?
Many things we want to do with notes—search, for example— require time and space in proportion to the size of the document. If we want a list of all Urgent notes, for example, we must examine every note. As our list of notes grows, searches gradually become slower. Loading and saving a document also requires time in direct proportion to the number of notes in the document. Sorting is even more complex; if we have n notes in a container, sorting them takes n log n time.
In practice, this means that Tinderbox has plenty of speed for working with thousands of notes, but is probably too slow to work with hundreds of thousands.
Many of the techniques that give Tinderbox traction—textual search, links, spatial maps—work best with hundreds or thousands of notes. We can imagine arranging hundreds of sticky notes on a wall during a long brainstorming session, and Tinderbox can remove many of the inconveniences of working with actual paper notes on an actual wall. If the physical wall turned out to be too small, we'd be out of luck; the Tinderbox map can simply grow as needed. Still, if we had a million notes on that wall, we'd never be able to see all of them, much less express their relationships to each other.
A good deal of work in modern Tinderbox has been invested in making Tinderbox fast enough that you seldom need to worry about performance10 and can work with thousands of notes with comparative ease. Larger documents are slower and less nimble, so focusing documents on topics or projects can be effective. If it is unlikely that you'd link two groups of notes together, or if a search for one group of notes would be unlikely to find anything productive in another group, splitting the document in two may make your work more pleasant.
Various approaches to “mind mapping,” including Tony Buzan’s trademarked methodology, resemble the Tinderbox map view and the map view can indeed be used to build diagrams that resemble mind maps. Strictly speaking, mind mapping tools generally rely on automatic layout of a few dozen notes, where Tinderbox relies on manual layout but easily manages many more notes. Mind maps try to show you everything in one view, since there is less to show; Tinderbox uses containers to focus attention because, without them, you could be lost in a sea of hundreds or thousands of notes. The automated layout of mind maps means you don’t have to think about where to put notes, but also prevents you from putting notes where they belong—and, unless linkage is nearly hierarchical, often creates intractable tangles.
Tinderbox can be a valuable tool for planning lectures and presentations, and the Tinderbox map can be a terrific visual aid. Presentation tools like PowerPoint® and Keynote® work best when you are presenting a set piece to a large audience. Tinderbox works best when you may need to accommodate last-minute changes, as might be required by a business presentation11, or when you anticipate spontaneous interaction, as you would in a classroom.
Design Note: Artisanal Software
The core of this chapter is a section titled “What I Wanted To Do.” A central controversy in software development throughout the past generation has raged over the propriety of this question. Should it matter what a designer or developer wants to do, or is that merely self-indulgent arrogance? Should we instead find out what customers want, and build that? After all, before Steve Jobs became the business prophet of the 21st century, his early career was often cited as a cautionary tale, a warning of the inevitable consequences of indulging a childish visionary.
Software products are large, complex, and challenging to build. Software is also a very young field; people have built barns, houses, and bridges for centuries, but the design and implementation of large software systems begins in the second half of the twentieth century. We don’t have much collective experience with designing and delivering software—not when compared to designing and delivering big buildings, ships, or highways.
Three strands of thought ultimately convinced me that individual insight could make a real difference in designing innovative software tools. Each triggered a long and continuing argument. None of those arguments have been settled conclusively, but I believe the preponderance of the evidence in favor of the individual voice is increasingly clear.
Interestingly, the outstanding voices engaged in each of these separate strands all attended the very first Hypertext Conference, Hypertext ’87, in Chapel Hill.
An early lesson in management, one learned in the construction of the pyramids (if not before) is that vast projects can be undertaken by coordinating lots of people, each doing a modest amount of work.12 If some aspect of the work falls behind, adding more personnel or working longer hours in that area will bring the work back into balance. It is also easier to manage and coordinate workers if each performs a simple, predictable job: assembly lines produce products more cheaply than workshops.
Early software development experience, crystalized in the Frederick Brooks, Jr.’s 1975 classic The Mythical Man Month, contradicted this expectation. Brooks, who was managing the development of IBM’s OS/360 operating system, discovered that adding programmers to development teams failed to speed things up; in fact, teams receiving a big influx of help fell further and further behind. Each new worker could write some code, which moved the project forward, but each new piece of code would then have to be integrated into the entire system. Other parts of the system would need to use the new code, and that required meetings with the people responsible for those other parts in order to agree on how each part would interact. Disagreements inevitably arose, and these required even more managerial intervention. Finally, each part needed to be tested not only on its own, but also in conjunction with each other part of the software that depended on it, or on which it depended. Breaking the work into smaller and smaller chunks provided a way to coordinate more workers, but it could actually increase the system’s complexity while demanding more meetings and more management.
Some years later, Brooks observed that certain software tools inspired enthusiastic engagement with a community of users, and that these tools almost always arose from very small teams. Other products might earn equal or greater commercial success, yet tools from large organizations seldom inspired the prolonged enthusiasm observed in the communities that spontaneously grew up around such legendary systems as LISP, EMACS, and Unix. Committees can find consensus, but individual passion inspires commitment.
When I began to plan Tinderbox, I had The Mythical Man Month very much in mind.
Fred Brooks was the banquet speaker at Hypertext ’87; the keynote speaker on the following morning was Theodor Holm Nelson, the man who coined the term “hypertext” and whose 1974 book Computer Lib/Dream Machines had inspired most of the researchers in the audience13.
As Nelson’s recent autobiography, Possiplex, makes clear, he has, throughout his long career, pursued a distinctive model of software development that is based on film and television production. The director of a film is not expected to hook up the lights: the director is responsible for knowing what sort of lighting a scene will need and directs specialized craftspeople to see that the job is done. The director doesn’t cook lunch, but tells an assistant to make sure that lunch will arrive. This was the way Nelson expected that good software would be made: a team of specialists directed and controlled by a single, passionate visionary.
Managing software as if it were film has seldom worked well, though Nelson has been far from its only advocate. The movie industry has not always been adept at identifying artists who can consistently create wonderful films, and many of those it has blessed with the permission to make movies came to despise its obstacles and inhibitions, the many hoops through which the industry compelled them to jump. Successful directors have longed for a way to free themselves from reliance on an army of specialists.
Ultimately, film operates under very different economic constraints that involve vast investments in real-estate: movies require movie theaters, and television requires networks and satellites—all costly, and all of which must be dedicated to one project at any given time. Software isn’t like that.14
In the audience at that first hypertext conference was a young Danish professor, Jakob Nielsen, who was already establishing a formidable reputation as an expert in user interface design. Early software was sometimes daunting, requiring users to remember specialized key codes or arcane commands in order to coax the machine to perform even simple tasks. Nielsen soon became a stern critic of software that was difficult to use, a rigorous student of actual behavior of actual users.
A tension in early user interface design, one repeated in the early of the Web, was the conflict between innovation and consistency —between mimicking what was familiar or creating something new. Though Nielsen and Nelson alike scorned much contemporary software, they proposed very different solutions. Nielsen emphasized systematically measuring usability, which usually meant measuring the use of the system by novices and students; Nelson wanted to unleash the essence of the medium.
Nielsen wanted to rein in the creatives, taking the reins from software engineers and giving control to architects and designers. Nelson wanted to take the reins himself. Both believed that the software interfaces of the 1980s, often inconsistent and sometimes baroque, demonstrated that technical personnel could not be trusted to design user interfaces. A generation later, these ideas continue to dominate the field.
In truth, those early interfaces weren’t that bad. Tools are always designed for an ideal user, and the ideal user for many of those tools was an expert. That was not a foolish choice: computers were costly and specialized machines. They were slow, noisy, and inconvenient, and screens were tiny and crude. Software was, by definition, new. People didn’t use computers casually or for a whim, and if you had to use a computer at all, the odds were good that you’d be using it again. In that environment, it makes good sense to improve the experience of expert, even at the cost of making the first encounter with the software more difficult.
A personal knowledge tool like Tinderbox should also give great weight to the experience of people who will be working on projects for months or even years. The design of games and toys can privilege the importance of the encounter, but understanding — the true goal of Tinderbox—is seldom gained right away.
Brooks, who had managed large teams with unprecedented resources, discovered that ever-larger teams could bog themselves, and the project, down. Increasing the size of the team can sometimes set a project back. At the same time, achievements like UNIX (an operating system written by two researchers not long after Brooks’ vast team finished their own operating system) showed that, in software, small teams could be surprisingly powerful.
Nelson has never acquired the resources and authority to match his vision of software designer as auteur. When he managed to obtain resources, the craftspeople resisted direction; when he had built a like-minded team, the struggle for resources abraded it. Film requires teams: you cannot act every part yourself while managing the camera. Software isn’t like that—and Brooks’ observations about small teams suggests that doing things yourself is not a terrible solution.
Though I have long disagreed with the details of Nielsen’s “usability” and his implicit distrust of innovative exuberance, the over-arching message of the usability movement was, simply, to listen: to observe the system dispassionately, to observe the work to be done sympathetically, and to measure rigorously. Nielsen and his followers listened with special care to new and casual users, and their work created computers “for the rest of us,” computers we can use almost without thinking.
I wanted to listen to something else—to the information itself, to the way the pieces of everyone’s everyday knowledge work connect and reconnect. “Everything is intertwingled,” Nelson wrote in Computer Lib; I wanted to make those connections visible, not to untangle them but in the hope that seeing the tangles will lead to new understanding. I wanted to listen to the notes.
3. Notes
Taking Note
Notes are what we write when we are writing to ourselves. We might share some notes with others—most often with our assistants, colleagues, confidants, with people who help us get things done, but the primary audience of a note is almost always our future self.
Notes play three distinct roles in our daily work:
Notes are records, reminding us of ideas and observations that we might otherwise forget.
Shared notes are a medium, an efficient communication channel between colleagues and collaborators.
Notes are a process for clarifying thinking and for refining inchoate ideas. Understanding often emerges gradually from the accumulation of factual detail and from our growing comprehension of the relationships among isolated details. Only after examining the data, laying it out and handling it, can we feel comfortable in reaching complex decisions
We might intend to use some notes to advance a different kind of writing project: to write a book or an article, a policy proposal or a school paper. Notes may have unforeseen value; someday, our grandchildren might read our notes and learn something about us that they won’t find in family photographs. We treasure the notebooks and travel journals of our ancestors because they wrote them for themselves, not for us—because in their notes, we hear them speaking to themselves in their everyday voices.
Tip: Give thought to preserving notes long after their immediate purpose might be fulfilled. Storage is cheap, and will become less and less expensive every year. You never know what you might want someday, and you have no idea at all what your great-grandchildren might want.
For example, consider notes that you make in order to remind yourself to do something. You may be tempted, once you’ve finished the task, to delete the note. Don’t! Instead, keep a container that holds a list of tasks you’ve finished. If the container is someday filled with old tasks, just copy the container and paste it into an archive document.
In the same vein, it’s a great idea to make notes whenever you can about whatever you see. However good your memory, you won’t remember everything. Knowing you’ve written something down, you’ll have one less thing to worry about. And, once you trust yourself to make and keep notes, you’ll be able to rely more on your note-making system and will not need worry so much about what you might forget.
Hold Onto Your Notes
It might seem wasteful to store notes that you don’t expect to need again. Those old notes, after all, take up disk space. Disks fill up, and we’re accustomed to thinking of storage as expensive.
This is mistaken. Tinderbox notes are so compact that you can store them forever. If this seems hard to believe: let’s run the numbers.
As I write this, a hard disk will hold about 4 Tb of information and will cost about $100. It’s likely to last a long time, but let’s be conservative and expect to replace it after three years. A fairly long note from our ToDo list—a grocery list, perhaps—might run a few hundred words, and Tinderbox itself records metadata: the time the note was first made, the identity of its author. So this note might take about 1K of space on disk. Saving that 1K for three years will cost about one ten-millionth of a dollar.
Three years from now, we’ll replace the disk drive. Moore’s Law observes that the cost of computer memory is halved every eighteen months, so the new drive will most likely cost about ¼ of what we originally paid. But, even if the price of storage never decreases, we can continue buying new drives for millennia before the cost of storing this note will buy a cup of coffee.
The value of the time you spend deciding to delete a note will exceed by many orders of magnitude the cost of saving that note indefinitely.
Tip: From time to time, you will want to declutter your workspaces and notebooks. Old notes might be useful someday, but you don’t need to look at them all the time. So, periodically, plan to move obsolete notes and stale tasks to archival spaces. But don’t waste time wondering if things are worth keeping: in cyberspace, our attics have become so big that the cost of an extra note—or an extra million notes—is negligible.
Getting It Down
Two assurances are central to the Tinderbox approach. Writing a note must be fast, and the note, once written, must be stored reliably. Speed and safety are each essential.
Fast note-making depends on making the “new note” gesture simple. Some early programs, like the brilliant NoteCards15, began by asking users to classify and categorize each note before it was written. That turned out poorly; until you’ve written a note, it’s hard to know exactly what it will be and where it will fit. In practice, if you ask people to fill out a detailed form about each note, often their responses may be hurried and imprecise. Writers will know that their hastily-scrawled metadata is unreliable, and won’t use it. To avoid this, Tinderbox lets you annotate and classify notes as your requirement grow.
Tinderbox automatically records some helpful auxiliary information, such as the time when each note was created and the person who made it. You can often arrange for Tinderbox to automatically add additional metadata as well, allowing Tinderbox to make intelligent guesses and assumptions.
Tinderbox’s prototypes (Chapter 6) speed note-taking by instantly adapting new notes to follow the lead of an existing prototype. By selecting a prototype, you can save typing and set lots of properties of the note with a single gesture. Prototypes provide an immediate reward for taking a moment to think about the document structure.
Tinderbox agents (Chapter 11) speed note taking as well by relieving the writer of menial tasks. Agents scan your document continuously, seeking to find patterns, to discover structure, and to identify items (such as forgotten information) that require attention.
Because notes are so personal and so important—and because, even with Tinderbox, they represent so much time and work—it is vital to feel confident your work is safe. Everyone agrees that programs should never lose data or create unreadable files. That’s easy to say, but nobody can actually deliver on the promise16. Even spaceflight-qualified software, subjected to years of careful testing and planned to bear the load of billion-dollar missions, sometimes fails.
Tinderbox files are XML, a simple and standard interchange format for structured information. XML turned out to be a crucial element in being able to assure you that you will always have access to your information. Because XML is widely used, a host of software tools can work with it. XML files are repairable; isolated errors can be identified and fixed. Finally, XML files are designed so that people can read them. Drop a Tinderbox file into your favorite text editor, and you’ll see text you can read and tags that make sense. That in itself is a great comfort: your data remains yours.
A Dialogue With Your Data
We take notes not merely to record information that we might need again someday, but also to discover structures and relationships, to understand how things fit together. As we acquire new information, we may gradually learn how it relates to what we already know. Perceiving the structure of our problems and tasks more clearly, we may also come to see what information we are missing. Sometimes, we need to know quite a lot in order to understand what we don’t know.
Kumiyo Nakakoji (now at the Kyoto University Design School) calls this representational talkback.17 The writer seeks a way to represent the problem space, sketches notes that describe an initial approach, and then reviews the notes as if approaching the problem anew. If the representation is good, the problem now seems simpler. If the representation fails to make sense, that incoherence often suggests a new and better approach to the problem.
In this way note-taking can be like sketching, a private exercise to improve the acuity of our perception and to focus our understanding. Our sketches often focus on small detail: a study of a hand, say, or the weathered wood of porch behind a Gloucester drug store. We don’t draw these studies because we expect the image to matter, but because sketching these things with care and attention will improve our eye. By learning to draw the hand or the mountain, we polish our ability to draw anything. The process, not the picture, matters.
Working Things Out
Let’s examine a Tinderbox map scenario in more detail. At the outset of many projects, we need to understand what people and which organizations are involved in a problem and how they relate to one another. Such questions arise in a variety of contexts. For example:
An associate in a large law firm is assigned to join a team assigned to defend the firm’s client, a manufacturer of medical equipment, in a product liability matter. An alleged defect has led to litigation in four separate states. Each case involves a different judge and a presents a distinct slate of complainants and opposing attorneys. Depositions must be taken from patients, physicians, nurses, suppliers, product design engineers, and marketing executives, and each of these depositions is likely to mention other people involved in various capacities. Simply keeping track of the players will be a significant challenge for the attorneys handling each deposition.
A journalist or community organizer is looking into controversies surrounding the proposed construction of a new minor-league baseball stadium. On the surface, the questions appear to involve some minor adjustments to zoning regulations and traffic ordinances. Looking at the questions in more detail, we find complex relationships between the stadium developers, the owners of the land where the stadium is to be built (some of whom are relatives of city councilors), proprietors of neighboring businesses, the school board (which wants to use the new facility for sport events), the commissioner of the baseball league, and the heritage society (which wants to investigate archeological relics in the area). Only by identifying competing interests and conflicting priorities can we make sense 0f the negotiations.
A historian (or a fiction writer planning a historical novel) needs to introduce a group of characters in order to illuminate a series of events and explain why they happened. We want to introduce all the participants who are central to understanding what occurred, but also want to avoid overwhelming the reader with lists of unfamiliar names. We want readers to enjoy the interest and specificity of well-chosen anecdotes, but naturally we want to avoid a deluge of trivial names and dates. We may need to consider discussing any number of people, not all of whom will make it into the final draft. Only then can we be confident in judging which stories are indispensable and which are redundant or merely colorful. Often, one person’s actions are motivated by their relationships to others who might not figure in the story otherwise, but whose history and circumstances must be recounted if the subsequent actions are to be understood.
In all these scenarios, we begin by identifying people and organizations who are involved in the matter, and then work to capture a rough sense of how they relate to each other. Examining those relationships, in turn, suggests additional topics to investigate and more relationships to explore.
Imagine, for example, that we want to understand more about the circle of artists and writers centered in Paris in the early 1920s. We must begin somewhere; let’s begin with Hemingway (Figure 3-1) . We continue by adding notes to represent some of the people Hemingway knew in the early 1920s. We’ll add his wife Hadley, for example, and the American painter Henry Strater, with whom he boxed and who painted several portraits of the writer. Sylvia Beach, who owned the bookstore Shakespeare And Company, was an early champion of Hemingway’s work, and also supported D. H.
Figure 3-1. We start with a single note about a single person. This may not be the ideal place to start, but it is often better to start at once rather than to try to master the topic first.
Lawrence and James Joyce. This leads us toward Gertrude Stein’s circle, of course, which brings us to Picasso and Matisse, and also to Ezra Pound and the British visitors Wyndham Lewis and T. S. Eliot.
Even a few minutes’ work reveals intriguing complexity and can help remind us of people and issues we might later overlook. The map can be made clearer, too, if we bring related people together. We might use a distinct color to differentiate businesses from people, or distinctive shapes to distinguish visual artists, writers, musicians, and actors.
Figure 3-2. We proceed to add a few additional people to the map, trying to capture
the most obvious or interesting relationships. At this stage, completeness is impractical and often undesirable. For example, almost any English-speaker in Paris might have
patronized Sylvia Beach’s bookstore, Shakespeare And Company, but our preliminary interest lies in the most significant actors and most interesting relationships.
Experimental Organization
Our first notes about the 1920s Parisian scene placed writers to the left and visual artists to the right. This is arbitrary, of course, but even this simple distinction sometimes invites uncertainty: Gertrude Stein, for example, was a novelist, poet, playwright, collector, and an influential art critic. The painter John Singer Sargent is most closely identified with Paris, but in this period he maintained a studio in London and worked extensively in the United States; should his notes appear in Paris, London, or Boston?
Our organizing system need not be perfect: notes are primarily for our own convenience, and we can tolerate some ambiguity or uncertainty if the organization proves useful in general. Because Tinderbox makes it easy to search for notes, we are unlikely to
lose them entirely even if we forget the rationale for their placement.
Over time, however, we might want to consider other approaches to organizing our map. It might, for example, be interesting to group writers and artists by nationality rather than residence. Alternatively, we might examine the Parisian writers more closely and place their notes to reflect where in Paris they lived. On the upper part of the screen, we might place those who lived on the right bank: Picasso and Matisse, Braque and Modigliani in Montmatre, Zelda and Scott Fitzgerald in the tony 8th. On the lower part of the map, we place those who lived on the left bank: Brancusi on Montparnasse, Stein in St.Germain, Joyce on Rue de l'Universite and Rue Cardinal Lemoine, Beach near both on rue de L’Odeon, the Hemingways near Marché Mouffetard. This organization reveals some interesting patterns and can help explain some easily-forgotten details; Hemingway lived in what was then one of the less fashionable parts of Paris, the Fitzgeralds lived in one of the fanciest, and Stein’s salon (like Shakespeare & Co.) stood half-way between them.
Constructing hypertext maps based on geography is always tempting; when we are looking for a two-dimensional organizing principle, conventional mapping naturally suggests itself. Avoid falling back on geography by habit, but don’t overlook occasions where it may provide fresh insight18.
Figure 3-3: We might try to reorganize our notes to approximate the parts of Paris where people lived and worked. Hemingway had to travel to a far more prosperous neighborhood to drink with the Fitzgeralds; Gertrude Stein and Sylvia Beach lived in-between.
Design Note: How Large Is A Note?
How much text should we expect in a single Tinderbox note? How many of these notes should we expect in a typical Tinderbox document? Should Tinderbox users keep all their notes in one large document, or should we maintain separate, focused documents for each project?
Questions of scale and scope are critical for software and, indeed, for all information systems. In the past, the most crucial constraints were physical, though these always existed in tension with the information that the written media contained.
Our oldest writing systems used clay tablets incised with a stylus and then allowed to harden. The original application was almost certainly accounting, transmitting across space and time the resources (sheep, goats, workmen) a seller had dispatched to a distant buyer. Weight and convenience argued for smaller tablets, while considerations of marketing and contractual detail argued for fuller descriptions. The result, even in dimmest antiquity, was frequently a recourse to smaller and smaller glyphs.
The size of the “book” in antiquity was constrained by the amount of papyrus or parchment that could be conveniently wrapped around a spindle. Wrist strength and visual acuity constrained the length of the “book”—actually the scroll—in its original form. What we call a “book” of the Bible was once a scroll. By the fifth century BCE, writers generally understood that this was too small a chunk for planning a major work; Herodotus extends to nine books, Thucydides to eight. Livy’s monumental History, which ran from the mythical foundation of Rome through the current events of the author’s middle age, took up 142 books.
The familiar codex book, made by binding individual pages along one edge, can be larger than a scroll because it can lie on a table or lectern. The codex reader turns a page where, using a scroll, they once needed to be lift the whole book. A codex can hold more work than the scroll, allowing scholars and publishers to assemble anthologies like The Bible. Even here, ambition could sometimes exceed the bounds of the physical medium and required multiple volumes. At the same time, large volumes (and libraries of such volumes) could exceed the capacity of even the most dedicated student to recall what was written and where it was, leading late antiquity to commence a long exploration of metadata, indexing, cataloging, and other paratextual developments19.
The size of the pocket notebook (from ancient Rome to the modern Moleskine) is limited by the size of the shirt pocket and the purse. The same constraints fix the dimension of the dollar bill, the index card, and the punched Hollerith cards I used as a student to program the college computer.
Digital systems free us from the constraints of wrist strength and shirt-pocket width. We can fit hundreds of volumes in a chip, carry a library in a tablet, or gain instance access to millions of volumes through the internet.
Yet the digital does not render physics entirely superfluous. Our visual field is not unlimited, and the characters we read must be large enough for us to see. At a single glance, we can take in a few hundred words. After that, we must ask the machine to show us what comes next.
What comes next? “Print stays itself,” Michael Joyce reminds us.20 “Electronic text replaces itself.” But how are we to think about this necessary replacement? Reading, we have exhausted what we can see and we want to advance. What’s next?
If our notes are compact—if, say, each note is written on an index card—then what comes next is a new card, the next card (at least in this reading, at least for us). The card is a separate note, a thought, a chunk, an atom of argument. We move from one to the next, appreciating each in turn, and the writer constructs a larger argument from these atomic segments.
Alternatively, we might imagine our screen—our visual field—as a small window onto a larger, continuous text. What comes next, then, is simply more of what has come before, scrolling onto our screen but remaining part of the same.
Early workers in digital writing found themselves divided into separate camps along these battle lines. Jeff Raskin called one faction card sharks and their rivals holy scrollers21. It wasn’t an idle witticism: the proponents of smoothly scrolling documents often spoke of preserving the traditional continuity of the textual tradition while the advocates of screen-centered reading and writing called for an unabashed embrace of the affordances of the new medium, for new writing that would embrace the limits as well as the capabilities of the screen.
Literary machines of this early era explored some odd corners of this design space. Peter Brown’s GUIDE avoided navigational links; you click on a link and the link text would be replaced by something new. The document was continuous—and continuously changing; the edge of the screen was a meaningless and temporary accident. Bob Akscyn’s KMS (a Knowledge Management System) and Bill Atkinson’s HyperCard treated the screen edge as a true boundary, a signal that you had reached the end of one unit of meaning, and that, once you had finished here, you were ready to leap somewhere else. Brown University’s Intermedia envisioned a library of documents—small scrolls—interlinked in complex trails which would be augmented or replaced for different audiences, just as different university classes might have distinct reading lists while sharing the same library and using many of the same sources.
Three forces dominate the design question that separates the advocates of small, chunky digital writing from those who prefer scrolling, continuous text.
Scrolling has often been cast as the conservative, incremental choice, one more closely attuned to familiar habits of reading and familiar literary values. The treatment of the page boundary as meaningful is also part of a long tradition in research practice, in graphic design, and in narrative art, but card-centric navigation has always carried an air of transgressive modernism. This disparity was exacerbated in early research by the politics of the era, still dominated by protests against the Vietnam war and in favor of the rights of women; as luck would have it, the leading navigator was Ted Nelson, whose Computer Lib had a clenched fist on its cover, while those who preferred scrolling could look to the gentle and ever-respectable Doug Engelbart and the Brahmin, wartime imprimatur of Vannevar Bush. Nelson overflowed with ideas and visions; Engelbart built remarkable tools for military think tanks. It was an intensely political time, a time when a panel I moderated on Indexing Hypertext could inspire competitive cheering from left-leaning and right-leaning audience factions.
Typesetting requires a remarkable amount of computation. Each character must be placed in a line, and lines must be broken at the margin. We may accept a slightly worse break in one line to avoid a really bad break elsewhere in the paragraph. Some pairs of characters look better with more or less space between them, and each of these must be accommodated. Some pairs may be replaced by new characters—in German, ue may become ü and ss may be ß, while in English we often treat “fi” “fl”, sometimes other character pairs specially. All of this requires lots of computing power. Handling smaller chunks is easier than scrolling, and scrolling itself requires that we set the next line of type before our anxious reader can move it into view. The very slow retrieval speeds of the early era also made it helpful to write and read small chunks.
Small and focused atoms of information provide better link targets and more useful search results. It’s less useful to know, for example, that a quotation comes from Hamlet than to know that it comes from Hamlet Act IV Scene 2.
The last consideration is for Tinderbox the dominant force.
Shorter notes are more specific, and so they are easier to grasp when we refer to them later. Links—either explicit or implied— can provide context and detail when needed, but shorter and more focused notes are Tinderbox’s native idiom.
4. Lists And Containers
Bags, Bunches, And Sequences
Tinderbox containers can play three distinct roles in organizing your information.
First, a container may simply represent a collection of things, gathered together in one place.
People to whom you want to send holiday cards
The members of your local school committee
Web pages you’d like to read, when you find the time
Groceries you want to purchase after work
The members of the company’s graphic standards committee
These collections are bags or piles, a set of notes without any particular order22. Though the notes are part of a collection, they are individually significant; we might sometimes want to review the entire collection, but it’s just as likely that we’ll want to consult a specific note. The role of the container is simply that to collect some notes that will be useful in a particular context. When your work brings that context into focus, you can open the bag and see all the relevant notes. When the context is irrelevant, you simply file that bag away.
Second, we may have bunches—lists of notes that are interesting or useful to us primarily as composite collections rather than individual notes. For example, suppose you manage a work team that is responsible for announcing new products to the industry press. When a product launch approaches, you need to determine which staff members will brief various reporters, writers, and analysts. Hundreds of people need to be contacted and briefed; to facilitate this, you might break down “the press” into a collection of bunches:
Analysts, Wall Street
Analysts, regulators, lobbyists in the US
Analysts, International
Newspapers, Eastern US region
Newspapers, Western US region
Trade Journals
Strategic partner executives: US
Strategic partner executives: Asia
Instead of assigning personnel to handle a list of individuals, this lets you easily treat a bundle of people and publications as a unit. “Alice will handle Wall Street, and Bob will handle all the other analysts and the Asian partners.”
Finally, we often encounter lists where the individual items in the list are important and where the order in which they appear is significant. These ordered lists are sequences. Some common examples might include
Weblog articles, in reverse chronological order
Purchase requisitions, by date of request
A baseball team’s batting order
The students enrolled in Chemistry 242, listed in order of exam grades
A checklist for preparing to land an aircraft after engine failure
Here, not only are the individual items interesting, but their order is also significant, and we may frequently need to know which items precede or follow the item of interest.
Tinderbox provides useful facilities for bags, bunches, and sequences. Bags are often best viewed in a Tinderbox map tab; to open an extra map tab, select the container, make a new tab by clicking the button at the right edge of the tab bar, and choose Map from the View menu. If you prefer a more compact display, you can instead choose Outline from the View menu and then use View Focus View to open a new tab that lists only the contents of the bag.
In outline view, we can collapse a container to hide its contents, allowing the container to stand for the all the elements it contains. Expanding the container lets us see the bag, bunch, or sequence inside it, at the cost of pushing other items outside the field of view.
Actions and Rules can enforce constraints among all the notes in a bunch. For example, if your bundle of “Wall Street Analysts” has the OnAdd action:
then any note added to this bundle will be drawn in the same color as its new container.
Adornments, Composites, Containers, And Separators
Tinderbox maps provide three ways to group notes in collections: adornments, containers, and separators.
Adornments appear in the background layer of maps, and are hidden in other views. They help organize and annotate the space of the map, emphasizing and clarifying some spatial relationships.
Figure 4-1. Adornments express loose and experimental relationships, while containers express more concrete and lasting ideas of subordination or containment. Adornment boundaries are loose and permeable; an item is either inside a container or it is not.
It is easy to move items onto adornments, and just as easy to move them partly or completely away. Part of a note might lie on one adornment, and part on another. Tinderbox users sometimes regard adornments as signposts or landmarks, describing a note as “not far from the big red adornment.”
In map view, composites group several adjacent notes together, so you can move them as a unit and read their combined text.
Just as adornments appear only in map view, separators appear only in outline view and are ignored in maps. A separator is simply a line, potentially with a label, that divides a list into sections. Like adornments, the separator can serve as a lightweight, informal way to divide or group a part of a list.
While adornments and separators are best at representing tentative and contingent relationships, placing notes inside a container is more emphatic. Containers have more concrete semantics: a note is either inside a container, or it is not. Containers hide some of the details of their contents; they can be collapsed in charts and outlines, and links into containers are abbreviated in map view. By hiding their details, containers let you focus attention on their role as a bunch.
Containers In Tinderbox Maps
Containers simplify a Tinderbox map by sweeping details map out of the way and into their own map. The parts retain their individual identity but are replaced in the map by their container. Crucially, moving a note inside a container doesn’t break its links.
Containers can express a variety of relationships.
Small containers may represent a simple composite. In a list of sources, we might perhaps have several editions of the same book; placing all the editions inside a container that represents the book helps keep these bibliographic minutiae from adding complexity to our daily work. The children of a container are a part of a larger whole.
The container may represent a collection of notes with a common purpose. For example, a container might hold notes about Tasks that we plan to do.
The container may represent a specific context to which the notes it holds pertain. In a narrative, containers might represent events or episodes—the Armory Show or the US election of 1912. In the map, the container stands for the entire event; if more detail is wanted, we zoom into the container to explore the notes inside.
The container provides a viewport that gives us a partial glimpse into the notes it contains. These notes are drawn at smaller scale and with less detail than notes in the main map, but we can drag those notes into the main map if we desire, and we can just as easily drag additional notes from the map into the container.
We can supplement or replace the viewport with a summary table that lists pertinent attributes of the container’s children, or with a plot that graphs some particularly interesting attribute of the contents.
Containers And Links
Tinderbox maps only show links among notes inside the same container. If a link’s source or destination is a note in a different container, a link stub is drawn in place of the link.
Link stubs are sometimes frustrating; sometimes, we might prefer to have all links represented equally in the map. One answer to this frustration is simple: don’t use containers! Containers hide information: that is their purpose. Not every project will use every Tinderbox feature.
different containers.
At other times, though, we may want to hide links to obscure details while foregrounding more significant connections; this is precisely what link stubs do.
Arranging Lists
We can understand small lists readily enough, but a list with more then 5-9 items is too long to take in at a glance. If we use large lists frequently, we need a way to organize them.
For example, we may have a list of tasks we want to do—either a master list for all our activities, or a list of tasks for a specific project. This morning, the Tinderbox development list contains 266 items. That’s too many to remember, too many to see on the screen, and too many to print legibly on a page. Moreover, the first purpose of the task list is simply to tell me what I should do next. Some of these tasks are small and isolated, others require original research or new resources. Some tasks can be started right now, others must wait for other tasks to be completed. How can I choose which is the best task to undertake right now?
1. Finding the most important single task in a long list is daunting, but bringing some order to the list is not difficult.
2. Examine the first two items in the list. If one is clearly more important than the other, move it up on the list.
3. Examine the next pair of items. Swap them if the second is more important than the first. If either item is exceptionally important, give it a boost near the top of the list. If either item is exceptionally unimportant, move it down the list—or send it back to its project, removing it from the Current tasks entirely.
Continue to the end of the list. Repeat a few times.
After a few passes, the important tasks will be concentrated near the top of the list, and the less important tasks will be concentrated near the bottom.
You don’t have to examine the entire list at once. Each time you move a note, you improve the entire list. Scan down the list until you find a note that is clearly positioned too low. Select it. Press -up-arrow (Move Up in the Note menu) to move it higher in the list. Continue pressing -up-arrow until (a) you bump into a note that’s even more important, or (b) you reach the top of the list. Now, find a note that is clearly too high in the list. Press -downarrow repeatedly until the note you’re moving bumps into a note with even lower priority.
You may quickly identify some particularly urgent tasks. Drag them to the top of the list, where they will be easy to see, and add a separator that divides them from the rest. Now, as you work, when you encounter another urgent task, you can simply drag it up above the separator. Another separator, near the bottom of the list, might set off tasks that cannot be begun until other tasks are finished.
Once you’re confident that all the most crucial tasks are near the top, you can focus on sorting the top dozen tasks. Or, just take one of those tasks, do it, and move on.
Sorting Sequences Automatically
Containers also provide important tools for managing sequences. Most significantly, containers can sort their contents.
Don’t overlook opportunities to use container sorting to help organize your work. Note that the sort order is also significant for the map’s Arrange Clean Up commands; often, you may sort a container as a prelude to using the Clean Up submenu.
To change the sort criteria for a container, select the container and open the Inspector (-1). Switch to the Action Inspector () and select the Sort pane, then choose which sorting attributes you prefer.
Sorting is fast23, and changing sorting criteria is easy. Often, you may want to take a quick peek at a new sort criterion—for example, to see the delegated project that is most seriously overdue. Simply change the sort criteria temporarily, and then change them back.
If the new sorting criteria turn out to be especially useful, consider creating an agent.
Agents are specialized containers that constantly scan your document, looking for notes that match the agent’s query. When the agent finds a note that satisfies its criteria, it creates a new alias of that note inside the agent. Similarly, if changes to a note mean it no longer satisfies the agent’s criteria, its alias inside the agent will be deleted.
Like other containers, agents can sort their contents. Indeed, one common use for agents is to view the contents of a container sorted in a new way. For example, suppose you have a container of sources for your research, sorted by the date you first consulted that source. An agent could list the same sources alphabetically by author:
Query: inside(/Sources)
SortBy: $Author
A second agent might contain the same sources, arranging them alphabetically by title or sorting them by year of publication. You need not choose a single way to organize your list; agents let you use different perspectives on your data and help you learn, over time, which perspectives turn out to be most useful.
Container And Adornment Actions
Containers can perform actions on notes when they are added to or removed from the container. These actions are often quite simple —for example, the container “Completed Tasks” might mark each task as “complete” when the task is dragged into the container.
As noted above, in Tinderbox actions the attributes of a note are prefixed by the “$” sign. The action
$Color="red" turns a note red. Several simple actions may be chained together, separated by semicolons. For example, the action
$EndDate=date("today"); $Status="complete"; sets the note’s $EndDate attribute to the current date, and sets its $Status to the value “complete”.
Agents can also act on the notes they find. Indeed, one common role of agents is simply to gather notes in order to perform an action on them. For example, we might change the color of overdue notes.
Query: $DueDate<date("today")
Action: $Color="bright red"
Adornments can also perform actions. Containers act on a note when the note is created in or added to the container, while adornments perform actions when a note is moved onto the adornment.
Note: adornment actions are applied to all notes that touch some part of the adornment, and are reapplied when a note is dragged to a new location touching the adornment.
Container and adornment actions help automate routine tasks. For example, what happens to tasks on your ToDo list once you have completed them? You could delete those tasks, of course, but retaining them could have useful benefits:
You retain a record that the task has been finished, rather than forgotten or mislaid.
The time when when you marked the task as completed might be useful if, at some later time, you need to investigate or review the task or find information about it for colleagues, vendors, or managers.
1. Reviewing and analyzing old ToDo items may provide useful information for a project post-mortem or for future planning and budgeting decisions. We can help reduce or eliminate inconsistent metadata by using container actions to enforce constraints. Without such help, the workflow for marking a task as completed might be tedious:
2. Set $Completed to true and set the $Status to “complete”
3. Set $CompletionTime to the current date and time
4. Remove any special color coding we applied to this task
File the completed task under “FinishedTasks”
5. Each element of this workflow increases the likelihood that something will be forgotten, leaving the document in an inconsistent state. Instead, Tinderbox lets us reduce the complexity to a single step:
File under FinishedTasks
The container of FinishedTasks automatically performs the other steps when it receives a new task:
OnAdd: $Completed=true; 


$CompletionTime= date("today");

These steps are applied when a note is added, and so they can be overridden later when exceptions arise. For example, on Tuesday a customer reports a missing order.
Current Tasks
Trace Johnson order TX-183
We look into the matter, find the parcel is scheduled for delivery later that afternoon, and pass the information to the customer. The task is completed, and we place it in FinishedItems.
Several days later, an anxious customer again to ask, “where is our package?” The original task is still readily available in your Tinderbox task list, even though it’s now filed among the Completed tasks, and so finding the pertinent details is straightforward. You investigate and discover that the delivery truck went to the wrong location, and that the parcel is waiting at the customer’s factory when it ought to have been delivered to their downtown offices. You call the customer to explain, confirm that the problem is now resolved. To conclude the inquiry, you can manually update the task’s $CompletionTime, which had been set automatically when you marked the task as completed, to reflect the delay that this shipping problem created.
Automate To Reduce Tedium
You should consider adding actions to containers and adornments whenever you notice that moving a note to a new place suggests or requires other actions, such as updating time stamps or changing colors.
Repetitive chores are tedious and prone to error. You have important things to do; let your Tinderbox document assist you by taking on repetitive work. Experience shows repeatedly that, when people are expected or required to add metadata to documents, they will find interesting ways to avoid performing this dull, unrewarding chore. Once they discover that some of their metadata are incomplete or incorrect, it becomes difficult to rely on any of the metadata—and still more difficult to expend extra time and energy on adding and maintaining the metadata.
Conversely, don’t spend much time automating exceptional cases. Exceptions are rare; it’s harder to regain the time you spend on automation if the case is unusual. Also, exceptions are interesting; you’re more likely to notice exceptions and won’t mind occasional manual work. Remember that OnAdd actions are performed only when a note is first moved into a container or onto an adornment; you are always free to override the automatically-assigned values.
Tinderbox containers may also have an OnRemove action, which is performed on notes that are moved out of the container and placed elsewhere.
Smart Adornments
We move notes onto an adornment in order to organize them and to help us to find them later. Sometimes, we want the adornment to gather notes automatically. These are smart adornments.
Smart adornments gather notes on the same map level that satisfy a query. For example, the query
$Text.contains("Aluminum") is satisfied for any note where the text mentions Aluminum. A smart adornment with this query would examine each note in its map view and would move notes that satisfy the query onto the smart adornment. Any notes already on the adornment that no longer match the expression will in turn be moved outside the adornment. Notes inside containers, or in other parts of the document, are not affected by smart adornments.
For example, a judge might use Tinderbox to take notes during a long and complex trial. Most notes will concern the facts of the case and the issues of law that arise; recording these is paramount. Nonetheless, occasional notes will concern questions regarding courthouse staff, schedules, and logistics that might arise. A special cue, perhaps adding the string “@review” to the note’s $Tags, identifies these notes. Such notes can be created anywhere in the map, and the smart adornment will gather them up for you to review later.
Tip: When starting a new project, should you try to put everything in one large map view? Or should you begin by creating bins and categories or even a taxonomy of notes?
Many opinions on this question have been expressed in Tinderbox Weekend presentations and on the Tinderbox Forum. The current consensus suggests that you create a few containers to hold categories of notes you are certain to need, and to keep everything else in one map view, or in one heterogenous outline view until the natural structure of the project is clear
Design Note: The Hierarchical Backbone
Every note in a Tinderbox document occupies a place in an outline or hierarchy that spans the document. This “hierarchical backbone,” which Tinderbox inherits from Storyspace, was once one of the most controversial features of personal information tools.
Outlines help people compose and understand large, linear texts. Everyone learns this in school. To some, the utility of outlines is self-evident. To others, outlining is a pointless and tedious chore, one which piles up barriers of unhelpful structure in order to write
Figure 4-3: Mary-Kim Arnold’s “Lust”, a small hypertext fiction. A mere 37 nodes create a map of formidable complexity.
down what has always been entirely clear. Some writers use outlines, others despise them.
Digital tools encourage writers to craft detailed and complex outlines. If an outline is to fit on the back of an envelope, it must be small, and outlines written out in longhand tend to resist efforts to expand and reorganize them. Working on paper, if section III.A has five items, you might leave space for one or two items that you forgot, but if you want to add seventeen items (one of which has thirty-seven descendants), you'll need to write very small. With digital tools, though, your outline can easily expand to whatever level of detail your work demands.
As outlines become more complex, though, it becomes increasingly difficult to visualize exactly where a specific item ought to fall. Adding a new item to a list on the back of an envelope, we can readily assess exactly where the addition belongs. When we’re dealing with a seven-level outline with hundreds of sublists, that initial choice is much harder. More difficult still is the challenge of reclassifying notes in a complex outline as the notes change, or as your understanding changes: because the outline fixes your attention in one section of the work, notes tend to stay in their original section indefinitely. Over time, individual notes become misclassified and the outline can lose coherence.
One of the original goals of Storyspace was exploring nonsequential writing, writing with links24. The presence of a hierarchical backbone might easily detract from that goal, tempting lazy or hurried writers to rely too heavily on the privileged, linear path.
An alternative to hierarchical outlines was seen in visualization like the Tinderbox map, views that could make complex and nonhierarchical relationships clear. Indeed, some researchers briefly held that the map defined hypertext, that true hypertext required a visual map.
Maps of a handful of boxes and arrows are often easy to understand. As maps grow, though, it often becomes difficult to perceive relationships at a glance.
Map views like Figure 4-3 (and many were far more tangled) once terrified hypertext researchers; if maps were the essence of hypertext, clearly, something would have to be done. One answer was to restrict the link network. For example, we could link only within a small neighborhood of pages, and rely on simple, hierarchical navigation to lead people to the neighborhoods they wished to visit. This approach persists in the Web in news sites that only permit links to articles on the same site, or that highlight internal links while relegating external links to secondary status.
The Web provided a second answer to the quandary as well: we could simplify the map, or forgo it entirely. Many early researchers were deeply worried that people would get lost in hypertexts, that they would lose their place and find themselves wandering aimlessly. In the event, this seldom turned out to be a problem. Web readers did not get lost: they always knew where they were because their browser always showed them the Web address they were reading. They might not know just why they were reading that particular page, but this was not an unusual situation; newspaper and magazine readers feel the same way25.
Storyspace hit on a third path, and Tinderbox follows its example.
Its maps show links among sibling notes, the notes inside a single container. You’re free to make links anywhere within the document, but those long-distance links are elided: only their starting point or terminus is shown (Figure 4-2). This compromise lets map views show considerable detail without being entirely swamped, and when the structure of one section of a map becomes well understood, we can use a container to tuck those notes away in a separate place, leaving the container as a placeholder in the original map.
5. Attributes And Values
Regular Information
A regular polygon is a symmetrical shape with sides of equal length, such as a square or a hexagon. By analogy, we say that regular information occurs in fixed and predictable patterns, where each item contains the same components.
Databases handle regular information. A register of personal checks, for example, has a regular structure: each check necessarily contains the same, specific fields of information:
Bank name
Account number
All checks have this information; if they don’t, they aren’t checks. Every check we write is drawn on exactly one bank, for precisely one amount, and each has exactly one payee. We never need to worry about checks that are not drawn on a bank, or where “account number” is not a number, or where “Amount” is a poem or a drawing.
Regular information possesses qualities that help us store it compactly and process it efficiently. Because each item is regular, we can predict its size in advance; if we want to reserve space for storing 1000 checks, we can do this without knowing anything about the individual checks.
The strength of the database is speed and efficiency, but databases are inflexible. Databases reward advance planning: when we create a database application to manage personal checks, we begin by listing the fields that describe a check, and because checks are well understood we can reasonably expect to anticipate what fields we will need. Databases work best when our initial analysis is complete and correct; if our understanding of the data changes radically in the course of development, we usually need to start over.
Because checks are regular, it’s also easy for the computer to sort them and to search efficiently. By keeping checks sorted, we can answer some queries (“What is the date of check #7231?”) without having to examine every check. Because we understand check semantics, we can track our expenditures to identify exceptionally large or small transactions that might deserve special attention, and we can easily compute our bank balance or report total expenditures for last month. It is easy to anticipate the sort of questions we might have about our checks.
Much of the information we encounter, in business and elsewhere, is regular, but much of it is not. Some irregularities begin as exceptions, situations that standard forms nearly accommodate but don’t quite capture. We may need to keep track of things that are nearly checks, but not quite—post-dated checks that represent casual loans, payment vouchers, IOUs, accounts receivable, gambling markers, and certificates promising breakfast in bed to The Birthday Girl. We may need to catalog things we never anticipated, as when an accountant discovered that her client—a famous artist, recently deceased—was in the habit of sketching witty portraits on the face of cancelled checks and had bequeathed this collection to a university art museum. We might need to augment the routinely-anticipated information with an entirely new galaxy of data if, for example, we need to pore through a murder victim’s checkbook for information that might suggest a motive.
All these examples begin with the same, regular data, but each develops unique needs and extensions. Databases place great weight on getting the structure exactly right from the beginning, so that the database can be fast and efficient. Sometimes, we cannot know in advance what we need. If speed and efficiency require extensive re-engineering whenever we discover new requirements, then speed and efficiency cannot be our chief care. Often, we’d greatly prefer to make it easier for our systems to adapt, even if our software will be a little less efficient.
Irregular Information
The notes and data we accumulate in our inbox, or in the course of our research, are irregular and unstructured. They store information that is meaningful to us, but nearly opaque to the computer.
Figure 5-1. Notes without any metadata are nearly opaque to the computer. They may, however, mean something to us: our habits in coloring and arranging notes might tell us a lot about these objects.
Consider a collection of notes I make in the course of a workday. Some represent ideas I have jotted down during meetings. Of these, some relate to the subject matter of the meeting and reflect ideas discussed in the meeting or resolutions adopted by the participants. Other notes describe ideas that occurred to me while I happened to be in the meeting. Some notes might be email and phone messages awaiting my attention. Others are photographs I captured earlier this morning, poems my niece wrote last week, and reminders for my next expense report.
Because this data is irregular, the computer has to work harder to store it. We can’t predict how much space an item will require, and the required space might change. A small note may later become very large:
Reminder: have Bruce paste video from annual meeting here
Usually, there’s not much benefit to sorting irregular information. Sorting implies that we compare two things and decide which comes first. But how do we compare a picture of the conference center to last night’s dinner receipt, or to the seventh voicemail message waiting for my attention? If the information is opaque, we can’t do much automatic processing or error checking.
Indeed, it might seem that there’s not much point in using a computer to work with irregular data at all. But, despite the obstacles, even highly irregular information does offer us some benefits when stored in an environment like Tinderbox:
Once saved in a computer document, we can make archival copies of the data as often as we like, protecting it from loss or damage.
Notes can be shared by email, or copied to media that will be delivered to colleagues and collaborators.
Since Tinderbox files are stored as XML, we can be confident that we’ll be able to read them in the future.
If some of the information is text, we can search the text for patterns and keywords. This search will not be as efficient as it would be if we were searching a rigidly organized database, since the database can focus its search more tightly. Clever programming (and fast computers) can compensate for the inefficiency, while the flexibility of irregular information remains a lasting advantage.
We can provide links (Chapter 14) between related items.
We can put related notes in containers (Chapter 4) to bring related notes together and to facilitate review and retrieval, and to represent deep structure.
We can build spatial hypertext maps to group related items and to help us locate notes later (Chapter 7).
Though the predictable structure and semantics of regular information make it easier for computers to get leverage, even opaque and irregular information provides plenty of scope for computational assistants.
Everything Is An Attribute
When you write a note in Tinderbox, the program builds data structures to store your information and to facilitate its future use. Some parts of these structures are essentially infrastructure, the plumbing and foundations the software requires for its own use. Others are metadata—information the program records because it might prove useful later. Some of the metadata Tinderbox automatically records for each note includes:
The time and date a note was originally created
The time and date of the most recent change to the note
The position of the note in the document outline
The number of child notes inside the note
The length of the text in the note, in characters and in words
Tinderbox also stores a long list of properties associated with the note, aspects of the note that affect its appearance or behavior. These include its color, its map position, the background colors to be used for the text and for maps of the note’s interior, and many other things.
Tinderbox stores the note’s properties and metadata in a long list of attribute-value pairs.
Color: red
Name: Planck’s constant
Created: 1 April 2014
URL: http://www….
Almost every aspect of a Tinderbox note is ultimately stored as an attribute-value pair.
This simple (and highly regular) structure means that Tinderbox can use a single mechanism for examining any aspect of a note. Whenever Tinderbox needs information about an object in a Tinderbox document, it looks at the object’s attribute list and follows a set of simple rules for finding the value. Whatever happens, Tinderbox will always find some value for any attribute about which it inquires.
Because everything is an attribute, reading and writing Tinderbox notes is largely a matter of reading and writing a list of attributes. Because everything is an attribute, it’s easy for Tinderbox to grow; Tinderbox developers can add new behavior and new attributes to support it, but existing files continue to work just as they always have.
Attributes aren’t simply names; each attribute is an object that knows how to read and to write its values. Different kinds of attributes have different rules for finding and recording their values. Some attributes, such as WordCount, are read-only; you can’t set them directly. Others have special inheritance rules—for example, while the values of most attributes can be inherited from a prototype, some intrinsic values (like the name of a note and its map position) are never inherited.
1. Whenever Tinderbox needs to find a value, it follows a simple procedure:
2. Locate the Attribute object for the desired attribute.
The Attribute object provides methods for finding the corresponding value for the note
The price of this flexible approach is speed; Tinderbox needs to do extra work whenever it requires information about a note.
Tinderbox does a lot of work behind the scenes. For example, simply exporting a weblog may easily involve several million distinct attributes and values, and finding those values may require additional computation to locate inherited values, computed values, and defaults. It turns out that this is precisely the sort of work at which modern processors excel.
You can add new attributes to a Tinderbox document whenever you like; your attributes are just as powerful (and just as fast) as Tinderbox’s built-in attributes. When you define a new attribute, that attribute is immediately a property of every note in the document—new notes and existing notes alike.
Note: Although attributes are always defined for every note in the document, they don’t require additional memory for notes that don’t use them. Adding a new field to a database often makes the entire database larger and slower, but the impact of adding a Tinderbox attribute is negligible.
Don’t hesitate to make new attributes if you need them.
Semi-Structured Information
Often, though we may not be able to anticipate the entire structure that defines an information space, we can easily identify some relevant properties. For example, suppose we are on an airplane, traveling to a conference or trade show. Whatever the conference turns out to offer, we know we’ll want to take some notes, even though we don’t yet know precisely what those notes will be or how we might eventually want to use them. We might write a separate text for each notable event, perhaps in a single long text file.
Jefferson Abelson (Univ. New Denmark)
Perspectives In Planning (Ontario Room)
A fascinating exposition. Invite him for a site visit before the annual retreat?
Text notes are very flexible, but they can be difficult to search and sort. Solely by searching the text of a note, it could be difficult, for example, to distinguish papers about Denmark from papers presented by people who teach in Denmark, or to separate presentation on the Ontario Room from lectures about policy challenges in Ontario.
We may add some structure to our notes by defining a few user attributes.
As a first step, I defined some useful attributes—$Speaker, $Affiliation,
$SessionTitle, and so forth. This provides a dedicated place in which
Figure 5-2. Defining key attributes helps you record information you'll likely want later
to store specific kinds of information. By choosing these “key attributes” for the note, I remind myself that I want to capture these mundane details in addition to the interesting ideas Professor Abelson presents.
By adding explicit structure, you make it easier for Tinderbox to work for you. For example, a Tinderbox agent could watch for notes from any session where Prof. Abelson was a speaker:
Query: $Speaker.contains("Abelson")
This will automatically catalog notes from Abelson’s talk; when we attend the second part of his presentation tomorrow, the agent will automatically catalog those notes as well. But the agent won’t be confused by other notes that merely mention “Abelson” in the text, and this helps us keep different kinds of notes separate. We don’t want the expense report from lunch with Professor Abelson to be mixed in with discussions of his research; attributes help us assign just enough semantic background to let agents distinguish effectively.
Figure 5-3. This agent searches for all notes in which the Speaker attribute contains
“Abelson”. We can more compactly talk about this agent by simply specifying its
query: AgentQuery: $Speaker.contains("Abelson")
Automatic Metadata
Attributes also let us collect some kinds of metadata automatically. For example, we might keep all the notes from one conference session inside a container:
Perspectives on Planning
Perspective On Planning (Abelson)
The Importance of Flexible Plans (Brekke)
Panel: Tools for Better Plan Management (Cruft, Dotson, Nakamura)
If we organize our notes this way, we can easily set some of the metadata automatically. As soon as a note is created or added to the session container, it performs an action on the new note:
OnAdd: $SessionTitle="Perspectives on Planning"; $Room="Ontario"
This kind of ad hoc automation requires hardly more work than simply entering the information once. Automation saves keystrokes, but even more importantly it encourages consistency, making notes easier to find later.
Note: Prototypes (chapter 6) offer another way to automatically assign consistent values. Prototypes are ideal where a single note can serve as an exemplar for an entire class of notes; a prototypical Student, for example, might set a host of attributes that would serve as default values for all individual students. Actions (and stamps) are ideal when you want to set some initial values without establishing a permanent connection.
Key Attributes
Every attribute is defined for every note in a Tinderbox document, but some attributes are especially pertinent to specific kinds of notes. For example, if some notes represent telephone messages, such attributes as $PhoneNumber will be especially important. The entire roster of attributes is very long, but it’s often handy to display a few, selected attributes at the top of a note’s text window. We call these key attributes.
You can add key attributes individually to a note by clicking the “+” button in the upper right-hand corner of the text pane. You can also add a group of key attributes at once, by setting the value of the attribute $KeyAttributes. This attribute is simply a list of attribute names, separated by semicolons:
KeyAttributes: Caller;Phone;Created;PleaseReturn;WillCallBack
Key attributes can be instrumental for gradually adding structure and metadata. Placed at the top of each note, they make it easy to paste information scattered within the text or implicit in the note’s context. In addition, they help communicate what sort of information a note ought to contain, and highlight gaps in your information.
Figure 5-4. Key attributes appear at the top of a note’s text window. Often, groups of similar notes will share the same key attributes.
Related kinds of notes often share the same key attributes. Some attributes are pertinent to phone messages, others to library references, and still others to interview notes; an investigative journalist might well keep all three in the same document, with different key attributes for each kind. Key attributes can thus establish a sense of common type or class among a group of notes.
Tip: When a group of notes share the same key attributes, consider giving them all a common prototype and inheriting the $KeyAttribute from that prototype. The prototype can also provide other cues—such as the text background color and typeface in the phone message of Figure 5-4 to reflect the specific role of the note.
Default Values
How does Tinderbox find the value of a note’s attribute?
First, Tinderbox checks to see whether a specific value has been assigned for that note. A value can be set in several different ways:
set explicitly in the key attributes table
set explicitly in the attributes pane of Get Info window
set explicitly using Window Inspector. For example, the Appearance Inspector tab offers ways to set the note’s $Color.
set by applying a stamp or a Quickstamp to the note
set implicitly by a user interface action. For example, resizing a note in a map view implicitly changes its values of $Width and $Height.
set automatically by an agent or container action, or by a rule.
set inherently by Tinderbox. For example, Tinderbox always sets the Created timestamp when a new note is added to a document
computed from the note’s properties. For example, the value of $WordCount depends on the note’s text, and its $OutlinePosition depends on its place in the document.
If no specific value has been assigned, Tinderbox checks to see if the note has a prototype. Prototypes are discussed in Chapter 6.
Finally, if Tinderbox is still unable to find the value, Tinderbox uses the attribute’s default value. The default value is, simply, the value Tinderbox will use if no other value has been assigned.
Figure 5-5. If no value has been assigned to an attribute, Tinderbox instead uses that attribute's default value.
Figure 5-6. Most default values can be changed in the Document Inspector. For
example, the default color for notes can be changed from “warm gray dark” to any other color.
The default values of many System attributes, and of all User attributes, can be changed in the Document Inspector.
Changing a default value might affect many notes. If you haven’t explicitly set a color for the notes in your document, then changing the default value of $Color from black to red will instantly make every note red.
Choosing appropriate default values can save time and improve your experience. The default size of a newly created note in a map is 1 × 3, but you can use wider, thinner notes instead by changing the default $Height and $Width to 0.5 × 6. If you want new notes named “titteløs” instead of “untitled”, just change the default value of $Name.
Design Note: Another Level Of Indirection
The concept of indirection is as central to computing as the concept of argumentation is central to the practice of law, or the practices of observation and measurement are central to medicine.
The idea of indirection is simple enough. Imagine a business office in the middle of the 20th century. A new employee is filling out a form, and has forgotten the date. “Mr. Newman,” she asks her colleague at the next desk, “What’s today’s date?”
“June 17th,” is a possible answer. That provides the requested information.
A better answer might add an explanation to help the new employee when next they need to check the date. “There’s a wall calendar by the door, right behind the front desk. You can see it from here.” This provides the same information. We have to do a small amount of extra work—we need to look across the room to see the date—but we now know how to find the date whenever we need it. Indirection replaces a chunk of information with a pointer to a place where the information may be found. More generally, indirection replaces a value (1955 Day 169) with instructions for efficiently finding that value.
Later that day, our new employee is working through a pile of invoices, paying contractors and suppliers with checks drawn on the office’s Operations Account. “Shouldn’t I check that there’s enough money in the account before writing all these checks?
How do I find the current balance?” she asks her colleague?
“If you’re ever uncertain, Ms. Perkins in 603 is in charge of that account. Check with her when the day’s expenditures are going to exceed $5,000, or if there’s anything that looks questionable. She always makes sure we start the day with at least five thousand. She takes Thursdays off, so plan ahead on Wednesday or you'll need to wait a day. In an emergency or on weekends, you can call Central Accounting in New York, but they can be a bit tetchy. I never had a problem with the account balance, though, and I had your job for 18 months.”
Here again, rather than supply the requested data, we supply a method for finding the answer. For the first five thousand dollars, we don’t even need to ask. After that, we query Ms. Perkins, who works in room 603. That query might fail; it won’t work on
Thursdays or weekends, and of course it’s always possible that Ms. Perkins might be ill, on vacation, at lunch, in a meeting, or otherwise unable to give us an answer. In that case, we can try again later. If we cannot wait, we have a different way to obtain an answer: New York can tell us, though contacting them might be slower or more costly. Finally, if for some reason even that fallback procedure fails, it’s suggested that we proceed on the assumption that there will be sufficient funds in the account. The new employee thanks her colleague, the helpful Mr. Newman, for his comprehensive if indirect information.
In fact, asking Mr. Newman is quickly becoming a habit, for he is a font of information and experience. This is a second layer of indirection! When a problem arises:
We ask Mr. Newman, “Who knows how to solve this problem?”
Mr. Newman tells us who to consult.
That person tells us where to find the answer.
This additional level of indirection is even more work; we need to ask Mr. Newman, and then we need to ask someone else, and only then will we learn how to find the answer. Yet, relying on Mr. Newman can be far more efficient than the alternative; we don’t need to memorize a thick book of procedures and personnel before we can begin to work. If this system fails—for example, if Mr. Newman becomes so busy with other responsibilities that he can no longer assist us—we may replace Mr. Newman and proceed just as before.
An old computer science witticism holds that “another layer of indirection” is the answer to any design problem. That extra layer of indirection is the heart of Tinderbox’s approach to attributes. Rather than work directly with the many properties that each note requires, we use two layers of indirection:
A dictionary of attributes catalogs a computational object for each attribute.
That object, in turn, knows how to get the value of one particular attribute.
Tinderbox has always featured a long list of built-in attributes, and this list continues to grow (Table 5-1).
Tinderb ox Version Built-in Attributes
2.1.1 86
2.5.0 111
Tinderb ox Version Built-in Attributes
3.0.7 136
4.0.2 150
5.0.2 200
5.9.0 225
5.10.4 250
5.12.0 287
6.0.0 310
6.2.0 337
5.3.2 350
6.6.4 360
7.0.0 367
How does Tinderbox find the value of an attribute? If we are drawing a map, Tinderbox needs to know each note’s $Height and $Width; how, exactly, does it find them?
First, as described above Tinderbox takes the name of the attribute (“Width”, say) and looks it up in a dictionary that Tinderbox builds when the document is loaded. The definition of “Width” is an Attribute object—an object that knows how to find out things about that particular attribute. In the current
Tinderbox implementation, the attribute object for Width is a
BasicAttribute, meaning that there’s not much that’s special about Width. Other attributes are implemented as ReadOnlyAttributes of various kinds, or through a handful of other specialized attribute objects. The Attribute object knows how that particular attribute works, what sort of thing the attribute holds, and also keeps track of what sorts of things need to be updated when the attribute’s value changes. For example, the Attribute object for Width knows that the changing its value may require the map to be updated, but won’t require changes to the text pane. Looking things up in a dictionary is fast, and the dictionary is organized so it doesn’t get much slower as we add more attributes.
The list of attributes is saved with each document; after loading a document, each version of Tinderbox adds any built-in attributes that are missing, thus ensuring that older documents will work with new versions of Tinderbox. Conversely, if we open a new document in a previous version of Tinderbox, the old Tinderbox merely sees some extra attributes that have no particular meaning to that version; it still knows how to fetch and save values, and how to read and write them in Tinderbox documents. This mechanism has proven surprisingly resilient as Tinderbox changes.
6. Prototypes
Copying And Pasting
Related notes often share common elements. Instead of describing each new note from scratch, we can sometimes describe the difference between the new note and another note that resembles it. Taking another note as a point of departure, we make it easier to set up the new note and may avoid accidental oversights. If we record phone messages on a special-purpose form, the form can remind us to get the phone number of the caller every time.
A simple way to take advantage of common elements among notes is just to duplicate an existing note, and then to modify the copy. Instead of starting with an empty note, we make a duplicate and then describe the differences between the old note and the new one. If the changes are few, we can save time and typing. This strategy of copy-and-modify is familiar from stationery and business forms, and from programs that mimic these paper-based techniques.
Prototype Inheritance
Once we’ve made the duplicate note, we have two copies of the common information. If that information were to be superseded someday, we would need to correct it twice: in the original and in the copy.
Instead of duplicating a note and then editing the copy, we can tell Tinderbox to make a new note “just like” another note, with the exception of those attributes we want to change. The existing note serves as a model or prototype.
Notes inherit values from their prototype. If a note has a prototype, Tinderbox looks first at the note itself for any attribute values Tinderbox needs. If that information isn’t explicitly specified for that note, Tinderbox examines the note’s prototype. If Tinderbox doesn’t find the information in the prototype, then it continues to look for the prototype’s own prototype. In the end, if a value still isn’t specified, Tinderbox will use the attribute’s default value.
Figure 6-1. If a note has a prototype, it inherits values from the prototype. If no value is specified in either the note or its prototype(s), Tinderbox uses the default value.
Inheritance creates a dependence between two notes. Changing the value of a prototype’s attribute changes the value of all of its instances, unless those instances have already established their own, independent value.
Suppose a prototype Groceries is green, and a newly created note, Today’s Grocery List, uses Groceries as its prototype. The note Today’s Grocery List will be green. If we change Groceries’ color to blue, Today’s Grocery List will turn blue as well; it inherits the color. But if we change Today’s Grocery List to red, further changes to the color of Groceries won’t change Today’s Grocery List’s color.
Any note can serve as a prototype for other notes. A special attribute, $IsPrototype, tells Tinderbox that a note expects to serve as a prototype; notes marked $IsPrototype appear in the popup Prototype menu.
Detail: Prototypes are implemented as a special link that connects the prototype to its instances. Prototype links are usually invisible, but you may make them visible in the Link Types pane of the Attributes palette. A note can have only one prototype, but prototypes can inherit from their own prototypes to create inheritance chains.
Detail: $IsPrototype is among the select list of intrinsic attributes that are not inherited. If $IsPrototype were inherited normally, then all notes that used a prototype would themselves be marked as potential prototypes.
Built-In Prototypes
Tinderbox provides a selection of built-in prototypes that you can add to your document by selecting them from the File menu. These prototypes address some simple facets of common note types such as Events or References. For example, the built-in prototype Person has key attributes that include FullName, Address, Email, and Telephone. The prototype Person also assigns a distinctive shape, color, and badge, and sets an informative HoverExpression to reveal additional information about the note when the mouse hovers above it.
Built-in prototypes are created in a top-level container named Prototypes, and are intended as a starting point. You are free to modify these prototypes, perhaps adding additional key attributes or adapting the suggested appearance to your liking. You may also add your own prototypes to the container.
Tip: The built-in Prototypes container is created with the $OnAdd action, $IsPrototype=true, so any new notes you create inside the Prototype container will also be prototypes.
Inheritance And Dependence
Inheritance from prototypes helps organize your work and avoids unwanted duplication. Duplicate information is inconvenient because you have to type the same information repeatedly: prototypes save typing. More important, though, duplicate information is difficult to revise and update. If a phone number is recorded separately in several different notes, changing that phone number requires us to change every note. If the phone number is inherited from a single prototype, then updating the prototype automatically updates all the other notes. Prototypes let you enter and revise information in one place—in the prototype—and share that information among many notes.
This sharing, incidentally, has almost no cost, because Tinderbox implements inheritance very efficiently.
Occasionally, propagation of changes is neither intended or desired. At times, you may want to create completely independent notes, perhaps duplicating a note and then editing it without creating any inheritance relationship. If you want two notes, for example, to have similar appearance but the notes are not otherwise related, copying and pasting makes more sense than using prototypes.
Using Inheritance
One common Tinderbox task is the daybook—a collection of notes about things that happen during the day, a sort of laboratory notebook for everyday business life. My daybook records things I might want to remember later—decisions I made, where I put things, when I mailed a check or placed an order.
Let us suppose that I often want to jot down records of phone conversations connected with my research project, not as a formal phone log but simply as an aide-mémoire. I could simply make plain old notes after each call, but instead I define a prototype note, Call, which I’ve made to look a little like the old-fashioned pink phone message notes (Figure 6-2).
The prototype is set up with relevant key attributes. This saves time and focuses attention after a phone call on the message, rather than on Tinderbox mechanics. The note is pink in the map, and when its text window is open its distinctive background color and typeface remind me instantly that telephone notes are not purchase orders or memoranda. Months or years from now, when a telephone note appears in a search result, I’ll be able to see what it is at a glance.
Figure 6-2: a prototype telephone note is like a pad of message forms, a template waiting to be filled out. Cf. Figure 5-4. The pink background color is controlled through the attribute $TextBackgroundColor.
Over time, I might add more prototypes to my daybook. One represents purchases, another product ideas or new software concepts. Each prototype can have its own key attributes and its own distinctive appearance.
Prototypes gain additional power because they are easy to extend. Suppose, for example, that I notice myself making essentially the same note, time and again:
Figure 6-3. If Perkins calls almost every month to arrange lunch, this message may itself be a useful prototype.
Perkins and I have lunch frequently, roughly once a month. It’s usually on Tuesday. But I can’t simply schedule a monthly lunch on my calendar; sometimes he’s out of town, sometimes I’m away, and sometimes we’ll decide to have dinner instead.
I can easily select one of these messages and click its prototype checkbox. Now, “Perkins Lunch” appears on the prototype menu. When Perkins calls, I can instantly create a new note modeled after Perkins Lunch. The phone number and caller will be automatically filled in because it is inherited from the prototype, but of course I can change these if, for example, Perkins is working this week from his London office. The “usual” text is entered automatically, but I can extend or change it as needed.
Tip: Many Tinderbox users keep their prototypes in a separate top-level container. This is often convenient, since it gathers all prototypes in one place. If you use any of the built-in prototypes, they are created in a toplevel container named Prototypes; you can use this for your own prototypes, too.
Tip: When starting a new project, don’t try to define all the prototypes you might eventually need before getting down to work. Good prototypes can save you time, but it’s sometimes tempting to spend hours defining complex prototypes that, in the end, you’ll seldom use.
You don’t need to get everything right before you start to gather notes. If you need to add prototypes later, Tinderbox makes it easy to integrate them with your existing notes.
Refactoring Key Attributes
When several different notes share a common set of key attributes, this suggests that the notes possess a common structure and purpose. A shared set of key attributes often suggests that all the notes are members of a single class or type of note. Lists of key attributes can be tedious to set up, and inheriting key attributes can save a substantial amount of time while explicitly indicating that each note is also a member of a common class of notes.
When you recognize that several notes are all members of a class, it is often useful to create a new prototype, set the prototype’s key attributes appropriately, and then make it the prototype for each instance. Existing notes may already have their own set of key attributes, and you’ll want to remove those key attributes so the notes all inherit their key attributes from the prototype.
To reset the value of an attribute to the default:
1. Select the note(s) of interest in any view window.
2. Open the Quickstamp pane of the Properties Inspector (-2)
3. Select the attribute you want to reset from the attributes popup menus, or use the search field to locate it.
4. Press the default button to used the default value.
Actions can also restore a default value:
$Color=; $Price=; $Quantity=; restores the default values of Color, Price, and Quantity.
When To Make Prototypes
Any note can serve as a prototype.
People familiar with object-oriented computer programming are accustomed to defining classes before using them, and so it seems natural to define prototypes before making any notes. Those who have taught object-oriented programming, however, consistently find that students are confused by the distinction between classes and instances. People who aren’t expert programmers often prefer to get on with the work rather than creating lots of abstract classes.
Prototype inheritance blurs the distinction between class and instance, because any instance can define a new class. Every note can be a prototype, every note can use a prototype, and you can change prototypes whenever you like.
Refactoring Information To Prototypes
As your project proceeds, you may notice new patterns and regularities in your notes. Often, the first sign of these patterns is redundancy or repetition; you find yourself typing the same information several times. We’ve just addressed one example of this phenomenon with respect to Key Attributes, but whenever we find a cluster of similar notes, we’re likely to discover opportunities to move shared information to a prototype. Software developers call this refactoring.
Consider a Tinderbox project in which we are evaluating digital cameras in order to review current technologies. Ultimately, our firm plans to select a specific camera to be issued to every member of our sales and service team; our task is to select a specific model of camera. To begin, we gather some recent product reviews from industry journals, both to learn about specific offerings and to get a better picture of the product space. In the process, we create a number of notes about specific products:
Figure 6-4. In our preliminary foraging for information, we collect many unstructured notes. Later, refactoring from text to attributes, and then moving common attributes to prototypes, can save typing while improving accuracy and consistency.
Our early research is chiefly concerned not with specific cameras, but rather with learning what factors to take into account and what information sources we can use to gather reliable facts and opinion. We don’t, at this point, know how we’ll organize and classify the cameras, and a premature attempt to determine this classification (e.g. by assembling a preliminary outline) might prejudge our decision.
In time, regularities will emerge, and we will eventually choose a list of basic information we want to know about every camera. Perhaps these include its manufacturer, model number, resolution, and price. We can refactor this information into attributes, creating a prototype note, Camera, that automatically sets the key attributes most cameras will share.
Figure 6-5. As we learn more about the problem space, we extract common elements shared by all cameras (like their key attributes) to a shared prototype.
If we require a very detailed and thorough survey, gathering information about hundreds of cameras, we might create several prototypes to describe categories of cameras. These additional prototypes inherit most of their properties from the core Camera prototype, but add additional information. The more specific prototypes can automatically fill in some attributes by supplying default values we typically expect. Of course, some models might differ from our expectations, and individual cameras simply override the prototype’s default value.
Keep in mind that any note can serve as a prototype. Many new products are best described as updates to a familiar product; we say, “this camera has all the features of last year’s model, but includes a higher-resolution sensor and new software at a lower price.” We can easily express this relationship by making the old model serve as a prototype for the new model.
Figure 6-6. Additional prototypes can add information about new cameras while setting default values.
Inheritance And Linking
Inheritance competes with links; we can inherit information from a prototype or link to information in a separate note. We’ll doubtless record the manufacturer of each camera; in time, we may record of great deal of information about specific manufacturers. One company might offer special discounts, another has an extensive support program, a third is challenged by chronic supply-chain problems. Sherry Perkins is our contact at one of the manufacturers; we might note her phone number, email address, and the name of her daughter who is in fifth grade and plays the violin. Extending the previous example of information about camera manufacturers, we might envision several notemaking strategies:
Manufacturer information could be recorded with each camera
Manufacturer information could be recorded in prototypes for each manufacturer, and inherited by individual cameras
Manufacturer information could be recorded in separate notes, and those notes could be linked to notes about individual cameras.
Each approach has distinct advantages and weaknesses. Recording vendor information with each camera is convenient and flexible, but can entail redundant data that might prove hard to maintain. Inheritance cleanly isolates shared data, but is potentially complex and can be excessively rigid.
Observe again that a note can have no more than one prototype; if we have already adopted the prototype categories of Figure 6-6 and add a layer of vendor prototypes, we will have a very long prototype list indeed, with names like Sony—
ProfessionalCamera. As the prototype tree becomes bushier, adding new classes—especially new classes near the root of the tree—requires new set of subclasses. If our needs change, reorganizing a complex prototype hierarchy can be arduous.
Linking cameras to vendors provides less formal leverage—we can’t automatically fill out forms by making a link—but is in other ways more flexible than inheritance. We can add manufacturer links to some cameras where this information is pertinent, but not to others where its utility is unclear. Notes can have only one prototype but can have as many links as we like; if one camera is available from two vendors, we can express this with two links but not with two prototypes. It’s easy to add more links, or to define new kinds of links, or to delete links you no longer need—much easier than revising a tangled inheritance tree.
Prototypes And Classes
In practice, Tinderbox prototypes define ad hoc classes of notes. The prototype Camera and the prototypes that inherit from it define a group of notes about specific cameras. We might well have other kinds of notes, some of which will have their own prototypes.
Sources of information
Field Test Reports
User Requirements
Each kind of note may have different key attributes, and you might employ different views for each. Notes about information sources—web sites, product reviews, industry newsletter—will form a list of references to give your recommendations weight, and also provide a vital resource if you need to defend your report from rivals and critics. You’ll want to record them and manage them differently, for example, than you’ll manage the survey results and memos that generate your notes about user requirements.
It is often useful to use distinctive color schemes, borders or badges to distinguish different classes of note. By making the different kinds of notes more visually apparent, you can quickly notice anomalies and mistakes.
Automatically Assigning Prototypes
Often, you'll create some notes and discover later that they should share the same prototype. Still later, you might find that a few of these notes should share a more specific prototype: one note might start as a Reference and then become into a JournalReference or an AssignedReading. The process of discovering and refining prototypes is part of incremental formalization: we begin with unstructured information and gradually add formal categories and structure.
If it were hard to assign or change prototypes, people might tend to avoid prototype information entirely. What if something is miscategorized? Fear of premature commitment can overwhelm other considerations, leading people to call everything “a note” and leave it at that.
To avoid this, Tinderbox makes it very easy to change the prototype of a note. Because the note’s current values override inheritance, changing the prototype won’t erase information that’s already part of the note.
If you need to change the prototype of a lot of notes, consider using a power tool.
You can make a stamp that sets the prototype of selected notes; this is handy for prototypes you need frequently
A quickstamp for setting the prototype gives you the power of a stamp without the overhead. It’s ideal when you need to set a big batch of prototypes today, but don’t expect to need the stamp again.
You might consider creating an agent that looks for notes that fit your search criteria and sets the Prototype automatically.
One common and powerful way to automate prototypes is to use the context of a note to deduce what sort of note it is. For example:
If our document contains some Projects, each of which holds one or more Tasks, then the Project’s OnAdd action can set the prototype. Whenever a note is added to a Project, it becomes a Task.
If our document has an Adornment named “Things To Finish Today Without Fail,” we might use the adornment’s OnAdd action to assign the prototype UrgentTask.
We might use a Tinderbox rule to set the prototype. For example, if a Task mentions “filing” in the text, you might automatically change the prototype from Task to the more specific OfficeTask.
Design Note: Inheritance
Prototype inheritance is one of Tinderbox’s most distinctive features. The importance of inheritance for representing relationships between classes of things became clear during the burst of artificial intelligence research in the 1970s and 1980s, but inheritance was long assumed to be a concept reserved for professional programmers26.
At first, we worried that explaining inheritance would pose a serious obstacle to Tinderbox adoption. In this era, ambitious undergraduate computer science curricula spent weeks on the study of inheritance in their Introduction To Programming, while less ambitious programs deferred the topic to the third semester or to specialist courses in computer languages.
As things turned out, though, inheritance proved fairly easy for most newcomers to Tinderbox, even for people with no formal computer science training.
Tinderbox adopts a form of inheritance that was, at the time of Tinderbox’s original design, considered unusual27. In most languages that use inheritance, separate kinds of objects called classes describe the kinds of objects with which the system deals and the way in which data and behavior are shared, while actual objects are instances derived from a class. The class is an abstraction like “Rectangle” or “Bank Deposit”, while an instance might be a specific rectangle near the bottom of page 107, or a deposit of €1,037 credited to the operating account. In this scheme, a class must be defined before you can make an instance.
Prototype inheritance was proposed in reaction to the conceptual complication that classes represent. Instead of building separate class objects, we allow any object to inherit from any other object. In the 1990s, a number of projects began to explore varieties of prototype inheritance; I had (fairly ineptly) reinvented this wheel on my own, and was delighted to stumble upon an actual research literature dedicated to the topic28.
Though prototype inheritance lets notes inherit from any note, most Tinderbox users reinvent dedicated class objects themselves, defining prototype notes that represent generic objects rather than inheriting from a specific instance: we typically see documents in which George Washington and Abraham Lincoln both use “US President” as a prototype, even though it would be just as correct to let all the other presidents use (say) George Washington for their prototype.
Dedicated prototype notes can help us by omitting information that where inheritance is unlikely to help. Every president has a unique term of office, and that term must be entered for each new president. “US President” can use the default value of “never” for the start and end of term, and new instances would then inherit these values. If a new note for George W. Bush used George Washington as a prototype, it would inherit 1789 as the start of his term.
Tinderbox notes inherit properties from their prototypes; the prototype defines what sort of thing a note represents.
Some new Tinderbox users expect that notes will inherit the properties of their container. This might make sense for containers in which the children represent parts or components of a larger item that the container represents. For example, a Task might be a container that represents a thing that needs to be done, and its children might also be Tasks that represents the steps required to accomplish the goal. Mitch Kapor’s Agenda, a pioneering personal information tool that influenced Tinderbox, used this sort of inheritance through the hierarchy to excellent effect.
Two problems arise with inheritance through the hierarchy. First, in which direction does information flow? For example, we might expect that, if a task is Important, all of its subtasks should be important as well: importance flows from parent to child. On the other hand, if each subtask has a CompletionDate, we’d expect the parent’s completion date should not precede the latest completion date of its subtasks: CompletionDate flows from the children to the parent. Different properties might require different directions of inheritance. An early Tinderbox prototype attempted this, but the additional complexity was often confusing.
Second, containers are frequently an entirely different kind of thing from their contents. For example, in my weblog the container March 2015 represents a month, but its children include notes about books that I read, concerts I wrote about, conferences I attended, and interesting dishes I tried to cook. It doesn’t make much sense for fettuccine Carbonara to inherit from March 2015, or for March 2015 to inherit from fettuccini. Also, if containers create inheritance relationships, the role of agents become problematic: an agent that searches for notes that mention pancetta might find fettuccine Carbonara, but fettuccine is not an agent and the agent is not a dish of noodles.
Still, early Tinderbox users longed for some sort of inheritance along the hierarchy. In the end, the Tinderbox action syntax was made sufficiently expressive to allow specific attributes to pass either upward or down through the hierarchy. For example, the rule
$Important = any(children,$Important)
marks a container as Important if any of its children are
Important, and the rule
$Color=$Color(parent) tells a note to adopt the color of its parent.
Using rules (or agents) to move information through the hierarchy is flexible, but the cost of that flexibility is performance. In early Tinderbox releases, complicated rules could create perceptible interruptions. Later, Tinderbox watched what you were doing and tried to update rules when you weren’t actively editing. Now that computers have multiple processors, Tinderbox updates rules in the background while dedicating one processor to the user.
7. Tinderbox Maps
Conceptual Clustering
When the relationships among notes are unclear, or when competing abstractions threatens to overwhelm us, Tinderbox maps can help us move ahead with confidence while also helping us uncover hidden relationships among notes.
Consider, for example, the problems inherent in planning a critical meeting that brings together important people for a very limited time. The participants might be the corporate sales force at their annual meeting, or an international panel of researchers gathered to discuss the policy implications of recent discoveries, a policy summit of a political party, or a program committee of an academic conference. In planning, we’re faced with a host of things we might want to address, and it is easy to become paralyzed by the number of possibilities. Where to begin? When all topics are vitally important, how can we start at the beginning or decide which comes first?
One useful remedy for analysis paralysis is to temporarily abandon analysis. Instead, we simply gather concepts, topics, ideas, and proposals. At first, we make no attempt at all to organize these suggestions: the first goal is to capture all the ideas, to ensure that everything we might want to consider is represented in the map.
The time for pruning back and straightening up will come, but you cannot successfully edit what you have not yet written.