[PRL] Morning blog clip: getting the names straight

[Mitchell Wand]

An excerpt from "Dreaming in Code", by Scott Rosenberg:


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" <http://www.dreamingincode.com/> by Scott
Rosenberg. Copyright (c) 2007. Published by Crown Publishers, a division of
Random House, Inc.*

*http://www.salon.com/books/feature/2007/02/03/rosenberg/
*
-------------- next part --------------
HTML attachment scrubbed and removed