[Design] Email in Chandler

[Sheila Mooney]

For anyone that hasn't been able to follow this discussion closely on  
the list, I just wanted to set reiterate the context here. We will be  
doing *some email* work in 0.7 that supports the dashboard tenet (we  
are in the process of drilling down on this) but what's being  
discussed here relates to a discussion of email support for 1.0.  
There are still many unanswered questions at this point, particularly  
around support for imap folders.

We will be spending more time on this discussion but not until post  
0.7 planning when we have dealt with most of the outstanding 0.7  
design issues.

Sheila

On Jan 27, 2006, at 11:30 AM, Oren Sreebny wrote:

> Hi, Alec -
>
> We don't do the big public shared IMAP folders service like CMU  
> does, but I know some other institutions do.
>
> I agree that it's important in the era of too much information to  
> be able to segregate incoming streams (whether email, nntp, rss,  
> whatever) into collections. Pine has a useful feature for  
> specifically designating which folders are contained in a  
> collection called "Incoming-Folders" which are the folders Pine  
> checks for new messages, and allows you to easily cycle between them.
>
> - Oren
>
> On Jan 27, 2006, at 10:42 AM, Alec Flett wrote:
>
>> Oren Sreebny wrote:
>>>
>>> One thing that is really important in our environment is support  
>>> for LOTS of imap folders - it's not uncommon for folks to have  
>>> collections with hundreds of folders. That implies not doing  
>>> things like scanning all of the folders for new messages, but  
>>> allowing the user to specify which folders she wants scanned.
>>>
>> I've also used IMAP as a replacement for NNTP - where all  
>> newsgroups (and other forum-like discussions) happen in IMAP  
>> folders that are shared, that you can subscribe to. I'm assuming  
>> UW does this too? I know this isn't a very common occurrence in  
>> the commercial/enterprise world, but I believe its popular in some  
>> academic environments (CMU is another example)
>>
>> Pre-IMAP, at CMU they had a mail system (the "Andrew Mail System")  
>> where when you logged in, the mail client would only show you the  
>> newsgroups/folders that had new messages, and you had to  
>> explicitly say "view all folders" to see everything you had  
>> subscribed to. I found it a very attractive model because I could  
>> log in and instantly get a visual feel for how much I had "to  
>> read" - i.e. if there were only 4 visible folders then I only saw  
>> 4 lines of text, and I didn't have much to read. If there was a  
>> page of 20 folders, then I had a lot to read.
>>
>> Mail clients have clearly moved away from this model and instead  
>> show all folders and mark the ones with new messages with a bold  
>> font. This has its benefits for managing your existing mail  
>> (because you always have access to all your folders) but I still  
>> miss the other behavior for reading mail quickly (i.e. triaging!)  
>> I could subscribe to literally hundreds of mail "folders" (i.e.  
>> newsgroups) but I would only ever see the 10-20 that had new  
>> messages. Instead of scanning a big list of folders to see which  
>> ones are bold (i.e. relying on my brain to make the conceptual  
>> distinction between the bold/not-bold folders) I only saw the ones  
>> that were relevant to me, right now.
>>
>> RSS has become another way to subscribe to many external feeds of  
>> information. At the moment we create a new RSS collection (in the  
>> sidebar) for each RSS feed. The common way that RSS readers  
>> "solve" this problem is to just show an aggregated view of all the  
>> RSS articles, and we accomplish this pretty easily with the "All"  
>> collection. Personally, I'd be interested in exploring the idea  
>> that there are distinct collections but you're not always  
>> interested in seeing the ones that don't have new items.
>>
>> Alec
>>
>>> I'm not sure I understand what  "Chandler does NOT replace your  
>>> existing email client for reading and writing emails" means - is  
>>> that merely a "what can we realistically get done in a 1.0  
>>> release", or a statement of long-term direction? I believe that  
>>> our constituencies are looking to specifically replace their  
>>> existing email client with an integrated client that does all the  
>>> good things mentioned in the first bullet point along with email.
>>>
>>> Cheers -
>>>
>>> - Oren
>>>
>>> On Jan 23, 2006, at 4:47 PM, Mimi Yin wrote:
>>>
>>>> http://wiki.osafoundation.org/bin/view/Journal/ 
>>>> EmailDiscussion20060120
>>>>
>>>> Here are notes from an ad-hoc design meeting last week on  
>>>> *options* for our high-level strategy for email in Chandler 1.0.
>>>>
>>>> + How will people use email in Chandler?
>>>> + What scenarios will it be useful for?
>>>> + What workflows will we support?
>>>>
>>>> Mimi
>>>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>>>
>>>> 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
>>
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>
>> 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