One of the features in the Confluence 1.3 release that I still look back on and say "Hey, that's neat", is the representation of threads in the email archives. (For those not following at home, Confluence can now suck in and archive email, which is pretty useful if you're running a mailing-list and a wiki on related topics).
The idea for displaying threads this way isn't one I can really take much personal credit for. In a comment elsewhere on this blog, the author of Zoë (apparently the best mail app I've never quite got around to using) generously pointed me to this article by Jon Udell, which inter alia points out a massive flaw in most web-based mail archives.
In most mailing-list archives that I (and Udell, it seems) encounter, threads generally look like this:
Worse still, the view you get of the thread at the bottom of each mail tends to resemble this:
These views impart (at best) the shape of a thread, its duration, and who contributed. They give no indication of the gist of the conversation, or which messages are worth reading.
Where Udell was wrong, was saying that this was a problem inherent in email itself, and practically unsolveable. There's a pretty simple workaround, and it worked far better than I even hoped when I was implementing it. It turns out that if you grab the first substantial chunk of non-quoted text in an email, then nine times out of ten you'll get a good idea what that mail is about:
(The page that screenshot was taken from can be found here...)
On a related note, here's an annoying User Interface misfeature from Livejournal. When you get sufficient comments on a page to overload the threaded comment view into summary mode, here's what it looks like:
Whenever I want to take the most obvious action for a comment (viewing it), I inevitably click on the most prominent link... which in this case is the username of the person who made the comment. This link takes me to that user's livejournal homepage. Try as I might, I've never got used to this, and I keep ending up exactly where I don't want to go.
For the sake of completeness, here's how we handle threaded comment overflow in Confluence. Since comment threads are revealed in chunks, and there should already be sufficient information leading up to the overflow to let the reader decide if they want to see the next chunk, all the overflow does is give the reader some idea of how much they're missing:
Very nifty. I like it!
One thing you may want to consider is to limit the extract to the first sentence of unquoted text. This should be enough in most case. Also, I'm not quite sure why you display the thread subject over and over again? Is that solely to provide a link to the message? Perhaps there is a more succinct way to achieve this...
All things considered, very nice!
The excerpt is about the right length if you look at it in situ, it just looks weird squashed to fit the width of my blog.
The subject also has to be there - subjects can mutate in the middle of threads, and also since the content excerpter is fallible, the subject has to be around as a fallback.
I can't resist pointing out that MH-E (the emacs front end for mh) has done something like this for a long time. If there's room on the line after the subject, it fills in the start of the message. Skipping the quoted text is a good idea, I think I'll pass that on to the MH-E team...
I'll try and include an example, though it's formatting must be left to the blog gods, who fear the tag... eh, I give up on the formatting, here's one long line broken up by manually inserted returns:
429 12/09 "Mark D. Baushke"
Re: MH-E 7.82<<Hi Kevin, The mh-invisible-header-fields may
contain the initial substring of
I love live journal. It's so easy. Maybe you should just get over the fact that you are too stupid to use it?
Maybe that is a good thing. Maybe they should make the internet harder to use, so that retards don't use it.