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
