Standards vs. conventions

Try the following experiment. Send yourself an e-mail message using “Test” as the subject line. Then send another. Then reply to the first message, using the universal default for e-mail conversations: “Re: Test.” Then reply to the second message using a different subject line, for example, “I disagree.” Now turn on the threaded view in your e-mail program and observe the results.

Here’s what you should see:

Test

            re: Test

Test

            I disagree

In other words, there should be two distinct e-mail threads, each with an original message and one reply. But here’s what I see in Outlook:

Conversation: I disagree (1 item, 1 unread)

Conversation: Test (8 items, 3 unread)

This also looks like two threads. But here the first is a lone response, distinguished by its title, disagreeing with nothing. Meanwhile, the second message refers to all messages in the current folder that happen to have the subject line “Test.”

Apple’s Mail exhibits a different incorrect behavior. Ximian’s Evolution gets it right, but  most e-mail programs flunk, as do nearly all Web archives of e-mail lists. This failure to render threads correctly is an information management catastrophe.

The RFC2822 (formerly RFC822) standard defines an e-mail thread as a set of messages that share common IDs in one or another (or both) of two header fields: References and In-Reply-To. But most people think that an e-mail thread is really a set of messages that share a common subject line.

If we all understood and applied the RFC2822 notion of threading, we could spare one another untold hours of wasted effort. For example, we could write descriptive subject lines for every e-mail message, thus enabling our correspondents to scan inboxes and archives without having to open each message to figure out what it adds to the conversation. But we’ve learned not to rewrite subject lines because we’ve discovered that it breaks threading in many (if not most) viewers.

Although I’d love to be proven wrong, I have a feeling we won’t resolve this dilemma in my lifetime. But maybe we can avoid creating similar dilemmas for our grandchildren. To do that, I think we have to admit that standards alone, no matter how carefully written, aren’t enough. We also need to look at implementations, analyze the conventions they embody, and spell out guidelines and best practices — both for developers and for users.

Apple, of course, wrote the book on human interface guidelines by visualizing and documenting a range of interaction scenarios in meticulous detail. Today we have a variety of platform-specific guidelines — for Windows, for Gnome, for Flash MX. But we lack general guidelines for how Internet applications should behave on all platforms. E-mail programs don’t agree on how threading, foldering, and filtering should work. Web browsers don’t agree on how drop-down search boxes should work. RSS readers don’t agree on how the orange XML icon should work. Media players don’t agree on how playlists should work.

We need HCI (human/computer interface) guidelines more than ever. And we need them not only for Windows, OS X, GNOME, and Flash, but for the uber-platform that subsumes them all. We need human interface guidelines for the Internet. i