Options and Futures    Mail reader

Mail reader

If I ever find the time to write a mail reader, here are the things I'll want:

[What about ML? It sounds as if it had many of these things.]

Everything is parallel.  If something happens, a new task is spawned off that doesn't have anything to do with the rest.  Right now, I can't read my email while answering my email.  That's ridiculous.

Suspend and Resume
Replies can be stored and resumed at a later date.  (That is, the tasks are persistent.)  The files that replies are composed in are not stored on /tmp, and are not lost when the machine crashes.

Direct manipulation.  Pointers/markers and texts, lines, attributes, but no cute drawn folders or desks.  The operative term is scale; explore the space between visualization (``there's a flutter of mails on the subject of ...'') and interaction (``read this mail'').  (Cf. the Pad++ work at U New Mexico).  There must be a Unix command line interface, but there must be a direct manipulation interface as well; when organizing mails, I do not want to type more than a single character - and it had better be lower case.

No own text editors.  Not necessarily its own flow control, either.  (Compare: mh.)


If something moves asynchronously, it must be a non­interactive display.  Sometimes, such displays are a natural part of the environment; e.g., my elm icon could grow apples[%], or sway in the breeze.  Something should move.
[%] I've been since informed that apples grow on apple trees, not on elms. Erm. Well, you get the idea.

Asynchroneous Deletion
There's a certain log of sent replies; the text isn't gone just after I pressed "send".

Folder management
Hypertext.  Folders can contain links to other emails.  One email can be stored in multiple folders.  (The physical folders contain links to the actual location in another folder.)  Task-based management of emails.  The first thing you do after an email comes in is not reply to it, but to tag it with a task.

By default, a task can have new, pending, archive sections; it is possible to define new substructures for the task.  Tasks can have their own aliases.  If tasks know about people and threads, incoming emails can be assigned automatically.

Emails touch on many things; people chat in between technical calls, or handle two technical calls at once; threads join and split again.

Virtual folders
An email appears in a virtual folder based on some property or tag, not based on a physical location in a file.  That is, I can edit all ``unanswered'' email, even if no such folder exists.

A folder can inherit attributes from its contents in various ways.  E.g., if an incoming email is automatically sorted into a task, the task itself is incoming.

Jutta Degener, jutta@cs.tu-berlin.de, last changed April 16 1995