[Design] Email in Chandler

[Oren Sreebny]

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