[Design] Email (and other) ideas

[Warner Onstine]

On Sunday, October 20, 2002, at 05:24 PM, Paul Saitta wrote:

> Hi,
>   A few ideas, mostly related to email handling:
>
>   Recursive folders are taken as the de facto concept for email
> organization, but they're really rather limiting -- messages have to be
> manually moved from folder to folder, and a message appears in only one
> folder.  Instead, the concept of database style views on the message 
> store
> seems much more useful.

Zoe (http://guests.evectors.it/zoe/) dumps this whole concept of 
folders and allows you to search google-style through your e-mail.

>
>   At the simplest level, a view can act like a folder -- you manually 
> drop
> messages into it, and putting a view inside another view implies 
> nothing
> more than a user decision.  At the other end, you can have 
> automatically
> generated logically nested views -- the system notices that this set of
> emails come from the same mailing list and creates a view (say, under a
> top level 'lists' view) with all the messages from that list.  This 
> view
> gets updated whenever new mail from that list comes in -- it may still 
> be
> sitting unread in the inbox, but it's also here.  Thread level views,
> single participant views, search-on-keyword views, etc can be nested
> inside any given view.
>
>   In effect, views are just saved searches given the same (or greater)
> priority than folders in the interface.
>
>   Filtering has always been a bolt-on feature in many MUAs, and the
> feature set has tended to be fairly impoverished.  Being able to use 
> basic
> boolean logic and regexps in filtering would be a big win, provided 
> that
> it's done carefully so that a new user isn't overwhelmed.  As 
> mentioned,
> mailing list detection would be useful, as would being able to filter
> based on addressbook entries, with the understanding that one person 
> may
> have many email addresses.  For that matter, usenet style killfiles and
> (more importantly) scorefiles would be handy -- if I'm on a really high
> traffic list, having those people whose posts I want to read picked out
> would be quite useful.
>
>   Depending on the model taken for mail delivery, automating the
> generation of throwaway identities for spam filtering purposes would
> potentially useful, but requires cooperation at the mail server end.
>
>   Being able to easily share mailboxes between users would also be 
> handy,
> as would some sort of mailing list feature, even if it's only 
> implemented
> as shared aliases.  NNTP support, which I haven't seen on the feature
> list, seems like it would also be a logical extension.

In Zoe we are looking at a long-term server where you can do some of 
that.

>
>   Scheduling negotiation would be a useful feature -- given a set of
> restrictions, find a free and optimal time block.
>
>   Another, larger feature that might be interesting later on would be
> either an internal or an integrated revision control and workflow 
> system.
> This could be as simple as hooks for revision control and support for
> scripting workflow by the end user.
>
>   In short:
>
>    Views:
>     Recursive database style views on message store
>     Easy semi-automatic subviews
>
>    Filtering:
>     Searching on boolean and regular expressions
>     Automatic mailing list detection for filtering
>     Filter by identity or user-supplied metadata
>     Killfiles and scorefiles
>     Automatic generation/handling of throwaway identities
>
>    Collaboration:
>     Multiple users per mailbox/identity
>     Mailing list management
>     News Support
>     Scheduling negotiation
>     Revision Control and Document Control/Workflow

Very interesting ideas.

-warner

>
> /P.
>
> -- 
> Ideas are my favorite toys.
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Design" mailing list
> http://lists.osafoundation.org/mailman/listinfo/design
>