mail-handling system would look like. Here are some of the ideas we
came up with:
- * Program presents me with messages that need my attention, (a
- chronological sort of the archive with unread items in bold does
- not count).
-
- * When I decide a message does not need my attention I can make it
- "go away" into the archive, (and "mark as read" does not
- count---I want to file away messages but still track whether
- they are read or not in the archive).
-
- * Threads must be first-level objects, (in particular I want a
- kill-thread command that archives not only the current messages,
- but all future messages received in a given thread).
-
- * System should support arbitrary tags on messages. Tags can be
- applied automatically, (such as applying categories to mail
- received on lists), and applied ad-hoc by the user.
-
- * System should allow searching over the entire archive with most
- recent results appearing instantly. Search terms can include
- tags, message headers, or full-body search (including phrases).
-
- * In addition to full-archive search, incremental refinement
- should be possible, (a new search based on the results of a
- previous search).
-
- * There's no need for folders in this system. Tags and
- incrementally refined, tag-based searching provide all the
- benefits, (without the bug in folder-based systems where a user
- has to hunt among many folders to find one where a search
- returns non-empty results). In particular, the "inbox" view
- should just be a search for unread and non-archived messages.
+ * Program presents me with messages that need my attention, (a
+ chronological sort of the archive with unread items in bold does
+ not count).
+
+ * When I decide a message does not need my attention I can make it
+ "go away" into the archive, (and "mark as read" does not
+ count---I want to file away messages but still track whether
+ they are read or not in the archive).
+
+ * Threads must be first-level objects, (in particular I want a
+ kill-thread command that archives not only the current messages,
+ but all future messages received in a given thread).
+
+ * System should support arbitrary tags on messages. Tags can be
+ applied automatically, (such as applying categories to mail
+ received on lists), and applied ad-hoc by the user.
+
+ * System should allow searching over the entire archive with most
+ recent results appearing instantly. Search terms can include
+ tags, message headers, or full-body search (including phrases).
+
+ * In addition to full-archive search, incremental refinement
+ should be possible, (a new search based on the results of a
+ previous search).
+
+ * There's no need for folders in this system. Tags and
+ incrementally refined, tag-based searching provide all the
+ benefits, (without the bug in folder-based systems where a user
+ has to hunt among many folders to find one where a search
+ returns non-empty results). In particular, the "inbox" view
+ should just be a search for unread and non-archived messages.
That was basically our list of core features. Beyond that, we also
discussed some further ideas for improving the prioritization of email
It also does a few things I hadn't specified, such as displaying email
in a full-thread nested view, (rather than one message at a time),
with quoted elements and signatures folded out of view until the user
-asks to see them.
+asks to see them. Another nice touch is that the single-line
+presentation of a thread includes the first names of participants in
+the thread, (with bold names to indicate unread messages). This
+provides some of the essential information needed for applying Joey
+Hess's [thread
+patterns](http://joey.kitenet.net/blog/entry/thread_patterns/), but
+without the tree view at this point.
[Note: I have been told that several of the above features are also
implemented in gmail. I've never tried gmail myself, since it fails to