The email problem
September 28th, 2003
For everyone that says, “I get too much email, dammit, let’s work together on a wiki,” there will be two others that say, “I hate having to go off to some web site to see what’s going on. Can’t we do this on a list?” You don’t notice this now, but I guarantee you will as Wiki usage spreads outward from the alpha geeks to the rest of the world. Businesses are trying to reduce email, sure. (They’re also trying to reduce churn, and wikis can create plenty of churn when used to tackle technical issues collaboratively. That’s only one way to use them, however.) But individuals often stumble, still, whenever they stray from it. Admit it - you know somebody who’s intelligent and gives a lot to the world, but doesn’t really understand the Bookmarks menu.
You can fight over whether the wiki should come to the people or vice versa, or you can just build nice email features into your wiki for those who want them. I plan (eventually) to do the latter. But what will they look like?
Subscription is the most obvious. Just as you can, in many message boards and weblog comment engines, check a checkbox to receive email notice when someone follows up on a comment, you ought to be able to look after a wiki page you create or edit. (Or just want to keep tabs on.) Enough people subscribe to the same page, you’re halfway to a mailing list right there.
The weirder problem is editing the wiki from outside, via email. You don’t want this to be a kludge or insecure, like many email-to-weblog gateways I’ve seen that have you put usernames and passwords in the subject line or first line of your email. You can’t use HTML email with fancy stuff done in JavaScript either, because, well, people hate that shit. What you can do, though, is create mailboxes for each page on the wiki and have them behave basically like mailing lists.
…But that would make people treat it like a mailing list. What kinds of afforrdances could we give a wiki email interface that would help keep the discourse wiki-ish? Or, if you’re feeling saucy, what other forms are possible when you combine email with a web collaboration space? And we haven’t even touched on how to bring multiple wiki pages into this. I have a feeling, though, that RSS is going to be more relevant there.
(Afterthought: hmm… automatically determining which wiki pages are closely related, by number of links? Vulnerable to attack. And it doesn’t really have anything to do with email. But people are going to need more efficient ways to slice this hunka meatloaf I’m putting together… grr.)
Entry Filed under: Vision
4 Comments
1. Bryan Alexander | October 1st, 2003 at 6:56 am
Questions about differences:
So do updates come by email every time someone edits the page, or daily/weekly? Different impulses, schedules, senses of the conversation.
The archive issue: I love my email archives. Wikis block some of that. Will I select wikimail for the topics I don’t archive?
2. misuba | October 2nd, 2003 at 1:13 am
Interesting thoughts: I’m embarrassed to say I hadn’t even gotten as far as thinking of digests. I guess I’ve gotten so used to RSS, and thinking of email lists as increasingly equivalent to XML feeds, that I blanked. (Although there’s no reason RSS feeds couldn’t be published on a regular schedule, I haven’t ever seen that happen yet. Aggregators kind of make it pointless.)
But the immediate vs. digest question could be driven deeper: how do you decide when a change to a page is newsworthy? You can’t just do it by the size of the change… some kind of user rating system? Then you could aggregate others’ opinions on how big the change is, and let people know based on their preferences: “only email me when the change is of severity 5.” Or whatever.
That’s obviously only a point for when we have time to make this system as complex as possible. :-) As for your other question, I’m not sure what the distinction is. Wikimail being what I talk about in the body of this post, and archives being… what?
3. Bryan Alexander | January 21st, 2004 at 4:14 am
The ranking brings to my mind something like karma points or a rep system… but those are based on discrete posts, nailed down precisely by time. How do you freeze a wiki - perhaps the users can do this, time-stamping a wiki with a command, and lodging the text either locally or on server.
4. misuba | January 21st, 2004 at 5:22 am
Thing about this is, the change of wikis only looks smooth. It’s actually as discrete as an HTTP POST request. If you look at history pages on well-designed wikis (or even the ones on Wicker! hah!), you’ll see every change ever made to them, right down to the smallest.
The challenge there is that not every change is large/interesting enough to vote on, or even to comment on when you make it. Who decides?