[Design] Stamping from the perspective of Dealing with Email Overload

[Mimi Yin]

Hi Dennis,

I've been struggling for some time to figure out a good way to  
respond to your mail. It touches on a broad range of design issues in  
Chandler and I haven't had a good way to distill them down into a  
digestible nugget.

I think the design challenge is as usual, one of Deciphering User  
Intent from User Behavior. Your suggestion to allow users to embed a  
Tag in the Subject line of emails is perhaps rooted in the desire to  
be able to see this Tag in the Summary list? rather than any  
particular need to associate the Tag with the Subject field?

I think there are a number of similar use cases like the ones you've  
described:

1. People often put who they're having a meeting with in the Title  
field of an Event. e.g. 1-on-1 with Jane

2. Katie did research a long time ago on Calendar usage and people  
would stuff all kinds of things in there: Locations, Phone numbers, etc.

3. I just sent out a notice from the shared OSAF Office calendar that  
I was going to be working from New York from April 17-21...and I felt  
the need to put April 17-21. However, if you're viewing the event in  
the calendar, having April 17-21 in the Event title is totally  
unnecessary.

The problem is two-fold:
1. Depending on the Context in which you see Data, you will want to  
see different facets of the Data.

2. When you enter Data, you're really entering information that spans  
many different attributes (e.g. This is about Sharing formats AND  
it's  a Proposal message). However, the user doesn't want to be/isn't  
prepared to parse all that information into different fields. (e.g. 1- 
on-1 with Jane.)

We think in sentences, not in individual form fields.

What's the solution?
1. Can we divorce the act of entering data from entering data into a  
specific field? (aka Natural language parsing). We don't need to  
parse everything, but parsing a few simple things might be 80% of the  
battle. (e.g. with = people fields. on + date/time = date/time  
fields. at + time = time fields. in/at + text = location fields.)  
Everything else gets dumped into the Title field?

2. Can we divorce what gets displayed in the Summary pane from any  
individual field?
e.g.
+ Event lozenges only display Start time and Title right now
+ Files in your OS file browser display the Filename + Last modified  
date.

Instead, can we allow the user to decide what attributes show up in  
the Summary...with some smart Out of the Box defaults of course.

3. Can we divorce what gets displayed in the Summary pane from the  
data itself? Instead, can we provide a layer in between the Data and  
the User that allows the User to view different facets of their Data  
depending on Context?
e.g.
+ When I view this Event from the perspective of the PPD team, I see  
1-on-1 w. Sheila and Mimi.
+ When I view this Event from the perspective of my personal Work  
calendar, I see 1-on-1 w. Sheila.

For mock-ups, please see:
http://wiki.osafoundation.org/bin/view/Journal/ 
SharingScenarios#WhatYouEnterHowYouEnter

Apologies if I've taken this topic and run away with it. But I think  
Dennis' scenarios touch on some deep-rooted usability issues that are  
worth exploring.

Mimi

On Mar 15, 2006, at 10:44 AM, Dennis Lynch wrote:

> I appreciate the thoughtful essay attached.  Many (or dare I say
> "most") of us suffer from "Email Overload", and each of us has our own
> way of dealing with it.
>
> I would love for Chandler to help us to make email more useful.  One
> of the things I do is to use the Subject line to put in a abbreviated
> label preceding the subject.  People tell me they appreciate that
> label- it helps them triage the emails they receive.
>
> This is very similar to a suggestion in the attached essay.
>
> BUT- I wonder.. could Chandler make this process more formalized, so
> that every email sent from Chandler would have some kind of Label in
> the Subject line.  As a minimum, Chandler could have 1) a
> configuration switch "Include Subject Line Tag when sending emails",
> AND 2) the email creation form would have a drop-down selection list
> of tags (including "New Tag...")
>
> One of the things I have learned in life is to always try to avoid or
> to fix problems at the start (when sending an email) rather than
> leaving them for someone else to have to deal with later (when
> receiving an email).
>
> --
> Dennis Lynch
> dmlynch [at] whatever [dot] whatever
>> Make email more useful by using Labels in your subject line:
> IMPT- important message
> INFO - general information
> JOKE- self-explanatory
> QRY- an unsolicited query/question
> REPL- reply to your message (The CAPS stand out more than the usual  
> "Re:"
> RQST- a request for information or assistance
> URGT- urgent message requiring immediate attention
>
>
> On 3/15/06, Mimi Yin <mimi at osafoundation.org> wrote:
>>
>>
>> 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?
>>  FYI: Who just needs to know about it?
>>
>> ASSIGNED TO: Who are you asking to complete this task?
>>  QUESTION FOR: Who are asking for input from?
>>  FYI: Who just needs to know about it?
>>
>> 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