[Design] Re: e-mail feature suggestion - msgs received recently

Chih-Chao Lam chao at osafoundation.org
Mon Dec 27 11:44:45 PST 2004


Hi Mimi,

Nice reply - I was hoping you'd jump into the fray :)

How would our triage workflow model deal explicitly with Philip's need  
to distinguish unread mailing list items vs. new incoming messages?  
Would you suggest that Philip mark unread mailing list items as "later"  
items?

chao

On Dec 27, 2004, at 10:14 AM, Mimi Yin wrote:

> Hi Philip,
>
> You'll be happy to know that your use case or rather workflow dilemma  
> is certainly one that we've paid a lot of attention to in designing  
> our central information triaging UI. However we've approached it from  
> a more general perspective and our proposed solution is perhaps less  
> direct, but perhaps larger in scope than the one you've described  
> below.
>
> Currently, as you've pointed out, email client Inboxes are overloaded  
> as both a place for new messages to arrive as well as a place to store  
> "glanced at, but not really read" messages and for a lot of people, a  
> place for ALL of my incoming email.
>
> As a result, the limited tools that are available to users (ie.  
> flagging, marking items as read / unread) make it difficult for users  
> to draw the few but fine distinctions they need to in order to make  
> sense of the giant pile of "stuff" in their Inbox.
>
> ** For example, one solution to your problem using existing clients  
> might be for you to flag items that are technically read, but not yet  
> ready to be lost to your email archive. However, because most clients  
> don't have very powerful sorting or ordering functionality...users are  
> left in a quandary as to whether they should:
>
> 1. Sort by date (in which case, flagged items are scrolled out of view  
> as new items come in) OR
> 2. Sort by flag (in which case, new items disappear because they  
> aren't flagged)
>
> Either way, the user is left with a half-solution that requires them  
> to constantly change their view. In other words, users must remind  
> themselves to look at their reminders (flagged items)...which defeats  
> the whole purpose of flagging in the first place.
>
> =====
>
> Our proposal is to provide a ground up change at the structural and  
> workflow level rather than to overlay the existing architecture with  
> more  color-coding and symbol reading in an attempt to guide users to  
> what we believe is a more "natural" way to process and manage their  
> information. (Our idea of "more natural" is based on David Allen's  
> ideas about Getting Things Done and studies on the many creative  
> solutions users have come up with to turbo-charge their current  
> Inboxes.)
>
> We've centralized all information in what we've been calling the  
> Dashboard view (see more at  
> http://wiki.osafoundation.org/bin/view/Chandler/TriageDesign) to  
> include items of all Kinds: Mail, Events, Tasks, Notes and items  
> irrespective of direction: Incoming and Outgoing.
>
> This central store of the user's data is divided into 3 sections: Now,  
> Later and Done.
>
> Our hope is that users will primarily live in the Now section where  
> they keep their "I'm not done with this" items (ie. email I haven't  
> read thoroughly yet, but isn't new) and where new "unread" items.
>
> Other "I'm not done with this" items can be shunted off to the Later  
> section if the user knows that they won't get to them until...well  
> Later. Later items can also be given an alarm or tickler date...at  
> which time they will reappear as "born-again" new items in the Now  
> section. (Users won't have to remember to go look at their reminders.)
>
> Done items go into the Done section, although users can always change  
> their minds and pull them out.
>
> Our goals for the Dashboard view are:
> 1. Provide a central place for ALL of the users items (has benefits  
> for search)
> 2. Provide intuitive affordances to help users process their  
> information that is easier and more useful than filing items into  
> topic categorizations.
> 3. Provide users with a realistic, coarse-grain, big picture view of  
> their life: What do I have to do Now? What do I have to Later?
>
> =====
>
> I hope this long-winded answer addresses some of the issues you  
> raised. It's a more roundabout way of solving your problem, but we're  
> hoping that it will fundamentally change the way people process their  
> information for the better.
>
> A lighter weight solution might be to simply have a rule that  
> automatically flags all new, unread items...that way you can keep your  
> Inbox sorted by "Flagged items" so that New and Flagged items stay  
> together, creating a pseudo-Now section in your Inbox.
>
> Mimi
>
> On Dec 25, 2004, at 12:00 PM, design-request at osafoundation.org wrote:
>
>> Send Design mailing list submissions to
>> 	design at osafoundation.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> 	http://lists.osafoundation.org/mailman/listinfo/design
>> or, via email, send a message with subject or body 'help' to
>> 	design-request at osafoundation.org
>>
>> You can reach the person managing the list at
>> 	design-owner at osafoundation.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of Design digest..."
>>
>>
>> Today's Topics:
>>
>>    1. Re: e-mail feature suggestion - msgs received recently
>>       indicator (Philip Trauring)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Sat, 25 Dec 2004 20:21:06 +0200
>> From: Philip Trauring <philip at trauring.com>
>> Subject: Re: [Design] e-mail feature suggestion - msgs received
>> 	recently	indicator
>> To: Chih-Chao Lam <chao at osafoundation.org>
>> Cc: design at osafoundation.org
>> Message-ID: <BE4A1F6E-56A1-11D9-8D89-000D932CB444 at trauring.com>
>> Content-Type: text/plain; charset="us-ascii"
>>
>> Hi Chao,
>>
>> On Dec 21, 2004, at 9:36 PM, Chih-Chao Lam wrote:
>>> Hi Philip,
>>>
>>> Thanks for an interesting use case. I'd like to understand and  
>>> clarify
>>> your scenario and issues before diving into whether OSAF's design  
>>> will
>>> solve your problems.
>>>
>>>> Current Situation:
>>>> Right now, in mail.app, the only indication I have is that unread
>>>> messages are in the mailbox, but they could be ancient. If I want to
>>>> see when new messages are received I'm forced to mark all messages  
>>>> in
>>>> the mailbox as unread, even if this isn't the case. This is a silly
>>>> thing to do, especially if one occasionally likes to go back in
>>>> mailing list discussions and read old discussions that one missed.
>>>>
>>> Do you mean forced to mark all messages as *read* rather than
>>> *unread*? I do agree that overlaying the read/unread status beyond
>>> it's original literal meaning can be problematic.
>>
>> Yes, I end up marking unread message as read, in order to be able to
>> tell from the folder (being bold or not) if I've received new messages
>> in that folder. This is because the only indication Mail.app makes on  
>> a
>> folder is if there are unread messages in the folder.
>>
>>> Is your main issue that you would like a distinction between new
>>> incoming messages versus unread messages? i.e. are there occasions
>>> where may have processed (e.g. moving it to a mailing list folder or
>>> collection in the Chandler model) a new message but still left it as
>>> unread?
>>
>> For sure it is important to make a distinction between unread messages
>> and recently received messages. Depending on the mailbox I may have
>> hundreds of unread messages that I may or may not go back to read at
>> some point. Some mailing lists I keep only to allow easy searching at  
>> a
>> later date.
>>
>> This is why different timeframes for different folders is important.
>> While I skim through the hundreds of mailing lists I get some I only
>> care to know if I've received new unread messages in the last month
>> (for a low-traffic list that I check only sporadically) while some I
>> check so often that I'd like to know if new messages have been  
>> received
>> in the last half hour, or even less.
>>
>> I see several ways to handle this type of functionality. Color-coding,
>> as some people have pointed out, is definitely an option. It might be
>> nice to be able to set up the colors to indicate something like:
>>
>> Red - new message in the last hour
>> Orange - new message in the last day
>> Green - new message in the last week
>> Blue - new message in the last month
>>
>> This could remove the requirement for different settings for different
>> folders, as I would know by the color if the folder had new enough
>> messages for me to check.
>>
>> Ideally I would like two options, which could be used together or
>> separately. First, the above color-coding system. I'd like a default
>> set of colors available, but the ability to set my own times and  
>> colors
>> if I choose. Second, I'd like the ability to show specifically next to
>> each folder how long it's been since a message was received. That info
>> itself could be what is color coded, although I would imagine some
>> would prefer to color-code the name of the folder, or both. It might
>> look like:
>>
>> Mailing Lists
>>     OSAF
>>        announce (2 mon)
>>        design (5 min)
>>        general (1 week)
>>
>> (where only mailboxes are colored)
>>
>> or:
>>
>> Mailing Lists
>>     OSAF
>>        announce (60 days)
>>        design (5 minutes)
>>        general (7 days)
>>
>> (where the times are colored)
>>
>> or
>>
>> Mailing Lists
>>     OSAF
>>        announce (2mo)
>>        design (5m)
>>        general (7d)
>> Personal Mail
>>     Family
>>        Mom (10m)
>>        Dad
>>     Friends
>>        Bob
>>        Mitch
>>        Jim
>>
>> (Where the mailboxes and times are colored, and those folders above a
>> colored folder are bold. Those folders without any unread messages or
>> beyond the coloring threshold (perhaps 6 months) are not colored.)
>>
>> or:
>>
>> Mailing Lists (5m)
>>     OSAF (5m)
>>        announce (2mo)
>>        design (5m)
>>        general (7d)
>> Personal Mail (10m)
>>     Family (10m)
>>        Mom (10m)
>>        Dad
>>     Friends
>>        Bob
>>        Mitch
>>        Jim
>>
>> (Where the mailboxes and times are colored, and those folders above a
>> colored folder are colored in the highest (shortest) color that  
>> matches
>> the sub-folders. Again, those folders without any unread messages or
>> beyond the coloring threshold (perhaps 6 months) are not colored.)
>>
>> Obviously there are all kinds of ways to tweak this. One could, for
>> example, only allow the parent-folder-coloring to go up one level - or
>> to go up to toplevel-1 or something like that. One could also only
>> color the actual folders instead of the parent folders - but in my
>> experience it's useful to indicate something in the parent folders
>> (which may or may not have any messages of their own) since I
>> frequently close the parent folders so I only see the folder name
>> instead of all the sub-folders. This allows me to, for example, take
>> all my mailing lists and reduce them to a single line in my folders
>> list when I don't want to deal with mailing lists.
>>
>> I hope this gives a clearer picture of what I was trying to describe.
>> This is slightly different that my original description, but is  
>> perhaps
>> an easier method to implement (and more useful if you don't remember
>> what time settings you set per folder).
>>
>> Philip
>>
>>> chao
>>>
>>>
>>> On Dec 20, 2004, at 6:35 AM, Philip Trauring wrote:
>>>
>>>> If there's a wiki page I'm supposed to add this to - please let me
>>>> know which one it is - the wiki has grown in complexity beyond my
>>>> meager navigation skills.
>>>>
>>>> Background:
>>>> I think I've posted similar ideas in the past, but not in this exact
>>>> method. One of my daily annoyances is managing the massive amount of
>>>> e-mail I receive. Beyond the spam issue (which I use SpamSieve to
>>>> mostly take care of) I receive a lot of mailing lists. I manage my
>>>> mailing lists by creating lots of subject-based folders and
>>>> sub-folders and filtering mailing lists into their own mailboxes
>>>> within these folders. Mailing lists come in heavy traffic and light
>>>> traffic, as well as important and non-so-important varieties. Of the
>>>> heavy-traffic variety I sometimes can't check them every day and
>>>> sometimes don't really need to - sometimes I just want to get a
>>>> snapshot of what the current discussion is. Of the not-so-important
>>>> variety I sometimes don't check the mailbox for weeks at a time (if
>>>> not months for light-traffic ones).
>>>>
>>>> Current Situation:
>>>> Right now, in mail.app, the only indication I have is that unread
>>>> messages are in the mailbox, but they could be ancient. If I want to
>>>> see when new messages are received I'm forced to mark all messages  
>>>> in
>>>> the mailbox as unread, even if this isn't the case. This is a silly
>>>> thing to do, especially if one occasionally likes to go back in
>>>> mailing list discussions and read old discussions that one missed.
>>>>
>>>> My Proposal:
>>>> All that said, the feature I'd like is a way to indicate for each
>>>> mailbox if new messages have been received in X amount of time
>>>> (minutes, hours, days, weeks, whatever). Ideally I'd be able to set
>>>> them all at once, or set up specific settings for each mailbox (an
>>>> override of the default I suppose). This way, each mailbox could
>>>> indicate on it's own time-scale if new un-read messages are present.
>>>> A heavy mailing list that I read constant might be set to 10  
>>>> minutes,
>>>> while a light not-so-important mailing list might be set to one  
>>>> week.
>>>>
>>>> In addition to an indication that new messages are present (mail.app
>>>> sets the mailbox name's font to bold) we could also offer to show  
>>>> how
>>>> recent a message was received (a column or mouse-over showing when
>>>> the most recent message was received).
>>>>
>>>> I hope I didn't ramble too much this time. What do people think? Is
>>>> this functionality already planned in Chandler?
>>>>
>>>> Philip Trauring
>> -------------- next part --------------
>> A non-text attachment was scrubbed...
>> Name: not available
>> Type: text/enriched
>> Size: 8755 bytes
>> Desc: not available
>> Url :  
>> http://lists.osafoundation.org/pipermail/design/attachments/20041225/ 
>> f951ec28/attachment-0001.bin
>>
>> ------------------------------
>>
>> _______________________________________________
>> Design mailing list
>> Design at osafoundation.org
>> http://lists.osafoundation.org/mailman/listinfo/design
>>
>>
>> End of Design Digest, Vol 14, Issue 8
>> *************************************
>



More information about the Design mailing list