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

[Philip Trauring]

Mimi,

Starting with your last item first, I certainly believe in the use of 
hue in addition to color. I don't think I mentioned that specifically 
but I had definitely been thinking about that when I was writing my 
e-mails. That said, hues can sometimes be confusing to use as the 
distinction between them can be too subtle for some people.

As far as the user seeing colors when they first open up Chandler and 
users not knowing what each color means, I think I was pretty clear 
that the user should be able to determine the colors used and whether 
they want to use them at all.

It's true that some programs (like SpamSieve) use color-coding to show 
information about e-mails, but this is optional and more importantly, 
does not effect the folder names at all. In addition, there's no reason 
for e-mails that the time information I am talking about couldn't be in 
a separate column altogether. I personally might want it to color code 
the whole row, but others might not. That's one of the reasons I showed 
several different color designs. Ideally, Chandler would allow one to 
choose how to display the information. It could be as simple as a 
colored dot next to the folder name.

As a side note, I had originally chosen red, orange and yellow as the 
colors to use to illustrate my point, which are certainly more easily 
recognizable as a pattern, but the yellow was hard to read on a white 
background, so I changed it.

That said, I do think your view of the dashboard may be the proverbial 
hammer seeing everything as a nail. You have an investment in seeing 
the dashboard work, so it seems like a nice general solution to a lot 
of problems. It may be a good solution to a lot of problems, but in 
this case I don't think this problem is a nail. Using the dashboard 
still requires one to tag e-mails appropriately or at the very least 
read or partially read an e-mail, while time-based tagging is automatic 
and gives me information on e-mails without me having to do anything. I 
don't want to change the status of these e-mails, the time-based 
tagging is not changing anything about the e-mail - it's just a visual 
cue to help me deal with so many e-mails. In fact, in my original 
proposal it didn't do anything to the e-mails (although I do like 
Selva's suggestion that all e-mail could be time-coded) but only to the 
folders themselves. I have more folders in my mail hierarchy than some 
people have e-mail...

Lastly, as far as the goals for Kibble my understanding from the 
roadmap was that it was intended to be "minimally usable, on a 
day-to-day  basis, for us within OSAF and for our info-intensive, 
techno-savvy early  adopters". The 'info-intensive' part would seem to 
suggest that the processing of 'public' information would be important.

Keep up the good work,

Philip

On Dec 28, 2004, at 12:13 AM, Mimi Yin wrote:
> 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