Stamping [a feature in Chandler that would allow users to transform one kind of data into another, like making an e-mail message into a calendar event] aimed to introduce a kind of productive ambiguity to the computer desktop that more closely mirrored the way people think. It was not a simple concept, even for the designers who'd invented it; for the developers who had to make it work, it was even trickier. Computer programs used silos and trees and similar unambiguous structures because they helped keep data organized and limited confusion. If an item belonged to one group, it did not belong to another; if it lived on one branch of a tree, it did not live on another.
Human language is more forgiving: one word can mean more than one thing. This flexibility provides a deep well of nuance and beauty; it is a foundation of poetry. But it only leads to trouble when you're trying to build software. As OSAF's developers struggled to transform the innovations in Chandler, like stamping, from sketch to functioning code, they repeatedly found themselves tripped up by ambiguity. Over and over, they'd end up using the same words to describe different things.
Take item. To the designers, an item in Chandler was anything a user would think of as a basic piece of data: A single e-mail; an event on a calendar; a task or a note. But the back-end world of the Chandler repository [the custom-made database the program used to store information] also had items, and its items were subtly but substantially different from the front-end's items. A repository item was a single piece of information stored in Chandler's database, and in fact you needed many of these repository items to present a user of Chandler with a single user item like an e-mail: Each attribute of the user item -- the subject line, the date sent, the sender's address, and so on -- was a separate repository item. At different times in Chandler's evolution, proposals arose to resolve this problem -- to "disambiguate" the word item. Maybe the term "user item" could always be capitalized. (This helped in written material, when people remembered to do it, but not in conversation.) Maybe another term for one or the other type of item could be adopted. (But some of those proposed, like thing, were even more ambiguous, and none of the proposals stuck.)
The Chandler universe was rife with this sort of word overlap. The design team kept using the term data model to refer to the list of definitions of data types the user would encounter along with all the attributes associated with that data type. For example, the data model would specify that every note would have a "date created," an "author," and a "body text." But to the developers, data model referred to a different, more technical set of definitions that they were using to store and retrieve data at the level of their code. What the design team called the data model was really, in the developers' vocabulary, the content model.
Then there was the problem with the term scheduled task. In the design world, a scheduled task meant an item on a user's to-do list that had a date and time assigned to it. But for the developers, a scheduled task was something that Chandler itself had been told to perform at a particular time, like download e-mail or check for changes in shared information. Or take the term event notification. For the designers, this meant things like telling the user that new mail had arrived; for the developers, an event was some change in the status of a code object, like a window closing or a click on a menu item -- and notification meant sending news of that change to other code objects.
Kapor would observe these little linguistic train wrecks and shudder. "We need to speak one language," he'd say. "We should all speak Chandlerese. We have to fix the vocabulary."
Finally, Brian Skinner stepped forward to try to do just that. Skinner had joined OSAF as a volunteer and helped Andi Vajda and Katie Parlante sort out the subtleties of the data model back when Vajda was just trying to get the repository started. Now a full-time OSAF programmer, Skinner had a knack for explaining developer-speak to the designers and design-talk to the developers. When the groups talked past each other, he was often the one to sort out the language. Why not, he proposed, set up a Chandler Glossary on the wiki? It would provide a single, authoritative, but easily amended reference point for all the terminology floating around the project. It could get everyone, literally, on the same page.
Skinner took arms against the sea of ambiguity. He produced dozens of glossary pages. He built a system for linking to them from the rest of the wiki.
It was a heroic effort, but it didn't seem to make much difference. For one thing, usage of the terms continued to change faster than his wiki-editing could keep up. More important, the developers, who were already drowning in e-mails and bug reports and wiki pages, didn't seem to pay much attention to the glossary, and the pages languished, mostly unread.
The glossary's futility might have been foreshadowed by the outcome of another naming effort in which Skinner participated. OSAF's Howard Street headquarters had a half-dozen conference rooms, and Kapor decided that it would be useful for them to have names, so that instead of saying "Let's meet in the little conference room around the corner from Donn's desk," you could just say the room's name. OSAF held a contest and solicited proposals from the staff. Skinner suggested using names from imaginary places; he won the contest and ponied up his $150 prize to fund a happy hour for his colleagues at Kate O'Brien's, the Irish bar down the street.
The fanciful names -- the two main conference rooms were Avalon and Arcadia -- captured the spirit at OSAF, where imagining new worlds was on the collective to-do list. It was only later that everyone realized what a bad idea it was to have the names of the most frequently used rooms start with the same letter: No one could ever remember which was which.
Reprinted from "Dreaming in Code" by Scott Rosenberg. Copyright (c) 2007. Published by Crown Publishers, a division of Random House, Inc.
Shares