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 <[EMAIL PROTECTED]> 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

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design

Reply via email to