[Design] Re: e-mail feature suggestion - msgs received recently
Mimi Yin
mimi at osafoundation.org
Mon Dec 27 14:13:13 PST 2004
Hi Philip,
I think the Dashboard view is meant to be a more general solution, not
just for mailing lists but for all kinds of information.
The Dashboard view addresses some of your issues because it allows
users to distinguish between partially read and completely read
messages without losing the distinction between unread and partially
read messages.
It also allows users to keep partially read and unread messages in one
central location (the Now section of the Dashboard view), which means
that they don't need to troll around looking for "the things they still
need to look at or follow up on." It's all in one place.
As for mailing lists specifically, if you are able to "Read" some of
your messages but still give them a "Now" or "Later" triage status (so
that they don't disappear into the morass of truly "Read and Done"
messages, you will be able to distinguish between truly "New and
Unread" messages and "Sort of New and I've Seen This Begore" messages.
Your "Unread" message count in the sidebar will now accurately reflect
the number of completely "New and Unseen" messages you've received in a
particular mailing list.
We're hoping that the Dashboard view will be a more general solution
that will be straightforward for beginner users as well as sufficient
for advanced users to help them get over some of the really basic
hurdles of processing large quantities of information.
In the future, we will want to address Mailing lists and RSS feeds
together with more sophisticated processing workflows for managing
large amounts of what we're calling "public" information. Currently for
Kibble however, we're focusing primarily on "private" information
(items created by me or sent to me), although we're hoping that some of
our "general" solutions for processing private information will also
improve management of public information.
=====
As for the flagging suggestion...it would need to be a 2-step rule that
automatically flags new messages and then automatically unflags read
messages...
This provides 2 benefits:
1. Users only need to flag emails that they want to keep around
2. Users can sort by Flag and all flagged messages are kept in the same
place as newly arrived messages...basically all "things I need to look
at" are together.
That way, as you're going through your mailing list messages, you can
scan through messages without really reading them...flag the ones that
you want to read in detail later and not muck up the # of unread
messages" indicator in the sidebar.
Now both of these solutions: Dashboard view and this hack with flagging
mean that you must actually click on each individual message in order
to "mark them as read". Furthermore, in the flagging solution, you must
then click to flag the ones that you want to read thoroughly later.
Certainly more work for the user. We could imagine setting it up so
that if the user visits the view and scrolls around, all messages that
come into view are "marked as read". But in the interest of sticking to
the basics, working in yet another layer of subtle distinction into the
"processing" workflow (ie. scan v. read partially v. read) will
probably be deferred until after Kibble.
===
A more general note on the use of color and number counts to provide
information.
Chandler as a platform carries with it the hope that a community of
interested developers and enthusiasts will customize and build in
sophisticated layers onto the basic application we create. However, out
of the box (OOTB), we're hoping to keep the use of colors, numbers and
symbols to a minimum.
In the context of this discussion, what the (bold, red #) symbolizes
(ie. # of new messages received in the last 10 minutes) and what the
color of a message (blue = more than 1 week old) means seems to be
clear. But especially wrt color, such things could mean a number of
different things to a number of different people. And in many existing
apps (most email clients), color means many different things
(categorization, junk mail status, errors, etc).
When we provide users with sophisticated affordances for assigning
meaning to colors and assigning color to items, it should probably in
most circumstances be something that is user-defined so that users are
never in a situation where they open up Chandler for the first time and
are confronted with a rainbow of colors which may or may not mean
anything to them.
Additionally, we will also want to provide guidance as to how the user
can best use colors. For example:
Blue = In
Red = Out
Purple = Trash
is a relatively meaningless mapping of color. Simply looking at items
that have been "colored" Blue, Red or Purple, it will be hard for most
users to remember which color means what.
However,
Light green to Dark green = New to Old "Actionable" items (ie. Green as
in Go)
Light yellow to Dark yellow = New to Old "Non-actionable but Undone"
items
Light red to Dark red = New to Old "Junked, Deleted, Cancelled" items
has clear semantics that are easy to remember and actually uses 2
dimensions of color (Hue and Lightness) to communicate 2 dimensions of
information (Status and Freshness).
=====
Apologies for the digression, hope that answers some of your questions.
Mimi
On Dec 27, 2004, at 1:03 PM, Philip Trauring wrote:
> 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
>>
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Design" mailing list
> http://lists.osafoundation.org/mailman/listinfo/design
More information about the Design
mailing list