Standards v conventions

Try the following experiment. Send yourself an email message using "Test" as the subject line. Then send another.

Try the following experiment. Send yourself an email message using “Test” as the subject line. Then send another. Then reply to the first message, using the universal default for email 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 email 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 email 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 behaviour. Ximian’s Evolution gets it right, but most email programs flunk, as do nearly all web archives of email lists. This failure to render threads correctly is an information management catastrophe.

The RFC2822 (formerly RFC822) standard defines an email 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 email 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 email 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, analyse 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 visualising 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. Email 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.

Udell is lead analyst for the InfoWorld Test Center.

Join the newsletter!

Error: Please check your email address.

Tags Development ID

More about AppleXimian

Show Comments
[]