Reflections on a night at BayCHI: BayCHITalk I had the opportunity at BayCHI to re-experience Merlin Mann's (of http://www.43folders.com fame) view of all things Productivity, in particular the problem that's become a cliche of modern life: Email Overload. His unapologetic characterization of the great majority of email we receive as the effluent of information work got me thinking about the converse of the problem: Why are we NOT more mindful about the email that we send? Well, for one thing, email is by it's nature ephemeral. Modeled on snail mail, email communication is structured as discrete messages that are composed, sent and for the most part discarded (by both senders and receivers) except for occasional dives into our email repositories for select pieces of information. (Although not typical of data-happy information geeks, there are a lot of people who literally DELETE, not archive, all their email...OR worse, email you again and again for the same information. In the last year, I have been asked for and provided my home mailing address to my parents at least 6 times.) Why are emails discarded? (Out of sight, out of mind) For most people on most email clients...email is not editable. As a result, any one email can't evolve with you as you make progress on a problem. It's a snapshot of a piece of information, at a given moment in time. Often times by the time an email is received and read by the intended recipient, that piece of information has already become obsolete. (Ever make the mistake of replying to email in a thread "in the order you received it"?) Email as it turns out is a great conveyance for dumping information straight into the archive. The email communication is given priority over the "information item" transported by the email. How so? Just look in your Inbox. Some emails are tasks. Some are reading material. Some are event invitations. Some are documents, drafts of proposals, questions, discussions. How do you know this? You look at each individual email and figure it out. But after you figure it out, you have no way of recording what you just figured out. As a result, there is nothing on the "outside" of the email that helps you figure that information out: e.g. A task icon. Reading glasses. Question mark. Talk bubble for discussions. Instead, we're provided with generic tools like Flags and Color codes to add Semantics to information. Was the Red flag for "Proposals I need to review" or was that Green? Which begs the question, am I using the right tool? Why is color appropriate for visually communicating something as complex as Proposals versus Tasks? Would we ever use that in our verbal communications with each other? "Well I've got 3 Reds and 1 Green to tackle this week." It sounds like Pentagon obfuscation. Even if you had the memory power and discipline to institute this system for yourself, how would you share it with others? In the end, your email client is dumb and makes you dumb along with it. All it knows is that you have emails with different colored flags. Anything beyond that and you're on your own. The Art of Addressing emails The lack of meaningful semantics is most egregious in the Addressing fields, which is where I think most of us go wrong when composing emails. The fields we're offered are for the most part, too generic: To, CC, BCC. What is TO? Isn't this email technically TO everyone? Out of all the mail you receive, how many people do you feel take great care in how they address their emails? However, if the "information item" emerges into the forefront of the communication workflow (aka Stamping in Chandler: This is Task, this is a Meeting invite, this is a Proposal), context-specific semantics can help ask the right questions. INVITE: Who are you Invite-ing to this meeting? ASSIGNED TO: Who are you asking to complete this task? I'm not proposing that we change the email protocol. What I'm describing is purely smoke and mirrors that information management clients need to pull off in order to help users be more mindful about how they utilize incredibly generic On the receiving end, the client needs to be able to parse these semantics and present them to the recipient in order to help them pick out signals from the sea of noise. "This is something that's Assigned to me." "Oh look, someone's asking me a question." "All this other stuff is just chatter and FYIs." Instead, all we have today in email clients is the "Danger, Will Robinson" flag called "High Priority." And there are only so many times Chicken Little can squawk about the sky falling before we become immune to such stuff. "High Priority" has no texture, no nuance. "High Priority" for whom? in what context? in what way? (There's also the little problem that just because something is High Priority for YOU...doesn't mean it's high priority for ME.) However, IF we could have texture, nuance and subtlety in our communications, courtesy of richer user semantics, then perhaps: The "information we email" would become more than just one-off blobs of text we lob into other people's Inboxes and the Inbox could stop being where people catch up with yesterday's news, which is a waste of effort for both the sender and the receiver. Instead, the "information we email" can become the "data representation" of the problems and issues that we're tracking in our heads. And like the stuff that floats around in our head, the tasks, drafts, discussions and issues in our information managers will evolve and change as "new information about our information" (meta-data) come to light. "This task needs to be due when? It's a good thing you told me." Practically speaking, it means that rather than having 8 separate emails, all of which are really just "Oh I forgots" and addendums to the original email, you have a single "information item" that everyone can edit and update, that is a LIVING record of the progress that you make on it. That's when "email" as a technology will become something helps you keep track of information, rather than something you lose track of. |
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list http://lists.osafoundation.org/mailman/listinfo/design
