 |
[Design] Email (and other) ideas
Paul Saitta
Sun, 20 Oct 2002 20:21:26 -0400 (EDT)
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.
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.
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
/P.
--
Ideas are my favorite toys.
|