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

Philip Trauring philip at trauring.com
Mon Dec 27 13:03:17 PST 2004


I certainly see how the dashboard idea is useful, but I can't see how  
it's useful for viewing hundreds of mailing lists and seeing which ones  
have messages I want to look at right now.

As far as automatically flagging new unread items, I don't understand  
the usefulness of this - it seems to add the extra step of having to  
unflag every e-mail I read which is a lot more work. The reason my  
scheme works is that the status of messages automatically change over  
time periods that I define.

Philip

On Dec 27, 2004, at 8:14 PM, 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
>> *************************************
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Design" mailing list
> http://lists.osafoundation.org/mailman/listinfo/design
>



More information about the Design mailing list