Tangled in the Threads
Jon Udell, April 19, 2000Hybrid Web/Email Applications
In a previous column, I talked about three groupware services that fall into the category I call "web/email hybrids":
- eGroups, which supports public or private discussions in both email and web modes, plus other web-based services such as calendaring and polling.
- TakeItOffline, for lightweight single-topic discussions, again in both email and web modes.
- TimeDance, for scheduling events, and collecting and monitoring RSVPs.
This week I've been using TimeDance to organize an event, and I've also tried out a new web/email hybrid at Zaplets.com. Both experiences have made me realize, again, that email and the web really do need to converge. The web serves up programmable documents, or -- what comes to the same thing -- document-style interfaces to software. Email transports messages which increasingly refer to, or contain, web documents. Groupware seeking to merge web software with email messaging faces tough challenges, and the results are never seamless, but I'm pleased to see services such as TimeDance and Zaplets pushing the envelope.
To schedule an event with TimeDance, you register with the site, create an invitation, attach some email addresses to it, and send it off. What recipients get is a message from the service containing an URL. For most recipients, the URL will have been auto-activated (made clickable) by the mailreader. Some, however, will need to cut the URL from email and paste it into a browser. This is one of the unfortunate wrinkles of any web/email hybrid: the behavior of an URL in a mail context is nowhere near as universally standard as the behavior of an URL in a web context.
Even mailreaders that can auto-activate URL don't always do so properly. When operating in plain-text mode (as opposed to HTML mode), very long URLs often break onto several lines and fail to activate. To prevent this, TimeDance keeps its URLs very short.
TimeDance URLs aren't just short, they're unique. If I invite 20 people to an event, each invitee gets his or her own URL. That way, when you click through to the RSVP page on the site, it knows who you are. You'll see the location of the event, and can view a map of the location (if TimeDance was able to look up the address). To RSVP, you announce your plans ("Attending", "Not Attending", "Not Sure") and, optionally, post a message to the group.
One of the things affecting your decision to attend (or not) is the list of invitees, and their intentions. If the event originator told TimeDance to make this information available, then it does so. You'll see a summary of the number of people in each of four categories: "Attending", "Not Attending", "Not Sure", and "Not Responded Yet". And you'll see the lists of names and address associated with each of these groups. This is a really powerful feature, which enables the event coordinator (or anyone else) to communicate with each of these automatically-maintained lists.
TimeDance also enables the coordinator to delegate the task of inviting others. If an invitation is configured this way, anyone can add names to the invitation -- very helpful when the coordinator wants to invite people, doesn't know their email addresses, but suspects that others do.
Like TakeItOffline, TimeDance creates a single-topic discussion. This message board, focused on the planned event, helps invitees decide how to respond. Crucially, it does this without generating any email messages. I've come to dread the kinds of events that are scheduled using conventional email, because the ensuing message flurry is more than my overloaded email inbox can stand. What's most valuable about TimeDance is the way it consolidates all that messaging. It follows a rigorous "need to know" policy. If you change the date or time, it sends everyone email, because everyone needs to know. But if someone adds an invitee, only that person gets a message. The system can send nag messages to nonresponders, and reminders to responders, but doesn't have to. The proof is in the pudding. I've coordinated a get-together for tomorrow night, to which I've invited over 20 people. Ten say they're coming, two can't, three aren't sure, and eight haven't responded. Amazingly, I have neither sent nor received a single email message during this process.
Mail filtering and threading
There are, admittedly, less high-tech ways to consolidate message traffic. In the applications newsgroup, Alan Shutko reminds us that good old-fashioned filtering can go a long way toward solving the problem:
I really wouldn't mind [a flurry of follow-on messages]. Of course, I'd have them all filtered automatically into a separate folder, and the increasing number in my group list would keep me posted that it's seeing activity.
I guess that's where I differ from most people, because most get all their email in one big unthreaded mess. I don't know how anyone can manage that way.
Neither do I. The mail filtering in Netscape's mailreader, which I mainly use, isn't world-class, but it's useful and I depend on it. Given the tremendous overload of email that many people struggle with, I'm always amazed to see how few use filtering.
Of course, it does require some effort to set up a new filter. And filtering can never be completely reliable. How do you control the filtering? By a matchstring in Subject: or perhaps (in a more advanced mailreader) by means of the References: or In-Reply-To: header? Neither approach is guaranteed to work. Indeed, this lack of a reliable way to thread mail messages is one of the fatal flaws of email-as-groupware, and one of the driving motivations for hybrid web/email solutions.
Recently I examined the messages that comprise a popular mailing list. The threading was a disaster! Why, I asked myself again, do people use mailing lists when the objective is threaded group messaging?
Alan Shutko:
Because real mail readers are quite capable of threading, and it doesn't require a) a news server, b) a constant connection to the net, or c) a disconnectable news reader.
When it works, it works well. The Gnus list, for instance, offers perfect threading. Most Linux lists thread pretty well. People who use Eudora thread incorrectly, but overall threading is useful.
Of course, when threading mail you need to look at both the References and In-Reply-To header and do a little fudging to put things together, which most software probably doesn't do.
Dave Caplinger:
I know what you are saying, of course, and you are unfortunately correct, but it just seems like the clients have to do a lot of work to undo the mess that other clients make because they don't all just follow a standard.
Proper threading creates, within a larger discussion, a discrete "discussion object" tied to an issue. Although newsgroups can do this pretty well, because newsreaders use the References: header more rigorously than mailreaders do, the whole idea of message threading has been poisoned by people's experiences with mailing lists. On lists, nobody can assume that a reply will attach to its antecedent. To ensure that it will, everybody feels obliged to quote the prior message's Subject: line:
Subject: Group scheduling Subject: re: Group scheduling Subject: re: re: Group scheduling
There are some terrible problems with this mechanism:
- Meaningful message titles are sacrificed. When you scan a newsgroup or a mailing list, titles (that is, Subject: headers) are your only clue as to the contents of messages. Because people feel that descriptive titles will destroy threading, they seldom write them. Occasionally, when it's absolutely vital, somebody will do something like this: Subject: VCAL standards (was Group scheduling). This is such a waste! The Subject: header shouldn't need to be a threading token. Correspondents should feel free to use it to describe each message richly and uniquely.
- Subject:-based threading is unreliable. If a thread is a discrete discussion object then its parts should all hang together. A Message-ID: header (or an equivalant hypermail URL) referring to any message in the object should be sufficient to recapture the full context of the object, with all its related parts. But inboxes (and web archives built from mailing lists) don't work this way. They try to behave like collections of topic-focused discussion objects, but they never succeed completely.
Zaplets push the boundary of HTML email
At Zaplets.com you can find a TimeDance-like service that pushes the web component of the web/email hybrid all the way into the mailer. HTML email is the preferred platform for a Zaplet, which is an active, self-updating document that lives in your email inbox.
Here's a picture of a Zaplet in my inbox:
In this example, an HTML email message is used as a discussion object. Recipients with HTML-aware mailreaders use the interface included within the message to have the topical discussion initiated by the message. Those without HTML-aware mailreaders can click through to web-hosted version of the discussion.
What I like very much about both TimeDance and Zaplets is the way they implement network-based discussion objects that are tightly bound to sets of messages. I hope these services will spur basic email to live up to more of its groupware potential. Messaging is too important an activity not to be fully customizable and programmable. Today, mail-oriented groupware applications have to rely on web backends, or bleeding-edge client capabilities like HTML email. 1
1Should HTML email, now over four years old, still be considered bleeding-edge? Sigh. Internet time isn't what it used to be.
But email really deserves to be a platform in its own right. Topic-specific messaging -- an invitation, a poll, a document approval process -- is something that we ought to be able to do right in the email user interfaces where we spend so much of our time.
Jon Udell (http://udell.roninhouse.com/) was BYTE Magazine's executive editor for new media, the architect of the original www.byte.com, and author of BYTE's Web Project column. He's now an independent Web/Internet consultant, and is the author of Practical Internet Groupware, from O'Reilly and Associates. His recent BYTE.com columns are archived at http://www.byte.com/index/threads
