[Design] SNARF and alternate models for scanning Email

[Mimi Yin]

This is interesting.

Excerpt from CNET article:
"The software maker [Microsoft]  this week released a free utility  
that aims to sort e-mail in a new way: It can organize messages not  
just by how recent they are, but also by whether the recipient knows  
the sender well."

I think SNARF, "in spirit" is very similar to Ducky's methodology for  
dealing with email. http://www.amazon.com/gp/product/ 
0970885172/102-6521947-3550501?v=glance&n=283155

===
I've actually played around with it a bit, but I will save my  
impressions of that for a separate email. Here, I'm going to stay  
somewhat high level and talk more about conceptual approaches to  
designing systems that help users deal efficiently and effectively  
with email overload.
===

I wonder though if sorting by "how well you know a person" is just  
adding yet another "imperfect" way to read your email. (I'm not  
saying that this isn't useful. In fact, it sounds to me like a step  
in the right direction. The kind of metadata SNARF is attempting to  
capture is an important step on the way to better user interactions  
with email . My discomfort is more with how the metadata is presented  
to the user and how the user is expected to act on it. (As in, the  
email is *sorted* by "how important the sender is to you" thereby  
implying that this is the order you should read your email in. Isn't  
this just as "wrong" as sorting it by Date?)

The idea is that *any single* "aspect" or "attribute" of an email is  
an over-simplistic way to decide "in what order" a user will want to  
read and deal with their email.

There are simply
1. too many factors to consider
2. those factors change over time (sometimes mid-stream as you go  
through your email) AND
3. many factors live in the murky realm of the user's subconscious or  
"gut" understanding of priorities.

In sum, there are too many variables to consider and many of them are  
beyond the access of both the software and the user.

Variables such as: How much time do I have right now. How fried is my  
brain right now? How do I feel about the sender right now? What are  
the high priority, high urgency issues at work right now?

What if instead of having the software proposing a particular "order"  
to the user, the UI simply did a better job at exposing important  
meta-data about the email so that users can exercise their "better"  
judgement on what "email to look at first" without having to first  
scan each individual email (which is what we do today).

What are some of the characteristics or metadata of email that in  
aggregate would help users do this?

- Is this email To: me, CC: me, BCC: me or To: some list I'm on?
- Is this the first email? or the 19th email in a thread that's been  
going on forever?
- Is this email part of a thread, which I have already marked as  
Status: Dealing with right NOW.

Armed with this metadata, metadata the client software has access to,  
the user can then mix in other information, as in information only  
the user has access to:

- How tired am I?
- How much time do I have right now?
- What fire alarms just went off in the last 15 minutes?

I think there is a subtle, but important difference in philosophy and  
approach here that's worth teasing out. I think of it as:

Software that helps people make decisions VERSUS software that makes  
decisions FOR people.

In more specific terms: How can we help people make smarter decisions  
about the order in which they tackle email, rather than finding yet  
another way to order their email FOR them?

Mimi

The original SNARF from Thundercats :o)

On Dec 2, 2005, at 2:49 PM, Ted Leung wrote:

> On the topic of people/contacts:
>
> Another example of uses of information attached to people and  
> filtering/sorting/triage:
>
> <http://news.com.com/SNARFing+your+way+through+e-mail/ 
> 2100-1032_3-5979217.html?part=rss&tag=5979217&subj=news>
>
> Ted
>
> On Dec 2, 2005, at 2:11 PM, Ted Leung wrote:
>
>>
>> On Dec 2, 2005, at 3:39 AM, Mimi Yin wrote:
>>
>>> So again, how can IM support what we already have? Better  
>>> scheduling? We've always thought it would be nice to have an IM- 
>>> style conversation at the bottom of events so that people could  
>>> just add their $0.02 about availability without having to clog up  
>>> Inboxes with lots of "Can make that. Can't make that" emails.  
>>> Maybe it would be useful for all items to have "conversations" at  
>>> the bottom.
>>>
>>> Any other ideas? They don't have to be fully-fleshed out down to  
>>> the workflow and implementation details. At a high level, where  
>>> do people feel like the easy-casual 1-on-1 conversation style of  
>>> IM would greatly enhance user experience (in the context of what  
>>> we plan to do in 0.7 and what we have already.)
>>>
>>> (This is not necessarily for 0.7)
>>
>> Generally speaking, I can imagine wanting to establish  
>> communications anytime another person is involved.  So items that  
>> involve people, events, tasks, so for are all natural candidates  
>> for wanting some kind of communication, whether that be  
>> asynchronous (today's e-mail) or synchronous (IM, Voice, Video,  
>> etc).   This is one of the reasons that I am so interested in  
>> getting contacts, "People" into the system because that's where I  
>> can put all the ways that I might communicate with  someone.    If  
>> you look at Mail.app, they do a nice job of adding an IM indicator  
>> for anybody that is online, so I could IM them instead of e- 
>> mailing them.  So integrating with events, tasks (delegatees), and  
>> e-mail would be a start.   You could imagine extending the samples  
>> parcel to allow you to IM the author of an RSS feed, flicker  
>> stream, or del.icio.us bookmark stream.
>>
>> Ted
>>
>>
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>
>> Open Source Applications Foundation "Design" mailing list
>> http://lists.osafoundation.org/mailman/listinfo/design
>
> ----
> Ted Leung                 Open Source Applications Foundation (OSAF)
> PGP Fingerprint: 1003 7870 251F FA71 A59A  CEE3 BEBA 2B87 F5FC 4B42
>
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Design" mailing list
> http://lists.osafoundation.org/mailman/listinfo/design

-------------- next part --------------
Skipped content of type multipart/related