[Design] Email in Chandler

Alec Flett alecf at osafoundation.org
Fri Jan 27 10:42:05 PST 2006


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



More information about the Design mailing list