The message-reply paradigm of e-mail creates huge chains of messages, in ThreadMode, that are difficult to reconcile or organize--particularly after a decision has been reached. While during a conversation, this may seem natural, after the conversation one only wants a summary of the decision and the relevant inputs. Think of group e-mail discussions as calling a meeting--because e-mail is the new meeting hell--and then consider meeting etiquette: have an agenda, take minutes, summarize the decision.
Essentially, natural conversations are not understandable once atomized into chunks that are interleaved into a chaotic soup. To OrderChaos, creating OneTexts for each conversation would be a boon, just as on a wiki we can convert ThreadMode into DocumentMode. Indeed, the standard option is to use a wiki, but WikiAdoption is hampered by the SwitchingCost of people moving away from their necessary e-mail to a new untested medium, or the more likely scenario of splitting their time between two CommunicationChannels. Ask a busy person to add something new to their schedule every day, and you will find this is nigh an impossible sell.
Another ideal would be to change e-mail to be more wiki-like. E-mail UserInterfaces are hampered by legacy, but the NetworkStandards are powerful because they are built of such basic actions and data structures that they afford many complex behavioural patterns. The e-mail clients really only act as an interface to the e-mail server, and that means they can be changed. Indeed, if you view the client as only a view on the e-mail database, perhaps it is possible to make it a view on a PageDatabase?
Therefore, create an e-mail interface to the page database. One can do this with one of two protocols. The PostOfficeProtocol (POP) handles basic e-mail functionality, such as spooling e-mail on a server, listing it, reading it, and deleting it from the server. It's chiefly used for 'offline' reading, which means you have a mail client that downloads the e-mail to your computer, where you then can manipulate it even while disconnected from the Internet. IMAP is another e-mail protocol, but it allows clients like Outlook and Evolution to read e-mail 'online'--that is while connected to the server. Mail can remain on the server while the client accesses and manipulates it. While POP also allows you to read e-mail without downloading it, IMAP allows you to manipulate the e-mail on the server such as flagging it, searching it, or even saving drafts.
An EmailWiki would roughly work at its very core as so:
- Pages appear as "e-mails".
- Replies to "e-mails" replaces the original e-mail on the server. (Replaces the page.)
- Replies don't show up as new e-mails, but merely remove the answered flag from the original e-mail.
- Timestamps on e-mails reflect last-edited time.
- RecentChanges becomes merely 'unanswered' e-mail.
As mentioned, IMAP is actually more powerful, with features like server-side searches, flags, draft composition. The advanced features might lead to interesting feature possibilities and workflow changes, such as 'bookmarking' interesting 'pages' by flagging the 'e-mails'.
Another advantage of using these protocols is that they are automatically WysiwygWikis as they will use Outlook and Evolution's built-in editors for manipulating the e-mail.
Also, this process will force e-mail subjects to be as precise as FreeLinks (notwithstanding their lameness), since subjects will be what distinguish e-mails from each other, not their intrinsic identity as is the case now.
But, new-fangled interface features that do not have an analog in the e-mail world will go missing. Most distressingly, links will no longer work.
No matter. Do as much as you can in the e-mail client, and then provide a web interface for those who prefer that. The EmailWiki is only one view. VersionHistory, for instance, might only be available from the web interface. One can provide a link at the bottom of each e-mail to its corresponding web page.
Contributors: SunirShah (originator)
I hate e-mail. -- SunirShah
This doesn't so much require a new technology so much as a shift in usage patterns. Instead of appending or prepending a reply, one can simply edit the text in the response -- most email clients have a way of keeping the original text unquoted somehow. This allows for revision history to be kept with the threading mechanism in the email. In fact, Outlook has this sort of thing built in, in which it attaches revision marks to everything you edit (though it's not made for inline edits). Really though, even Wikis operate the same way as email -- notice my reply posted below your text that I won't presume to edit, since they're your words. Says right here in my employee "net usage manual" that if you have an email thread that goes on and on, you should probably pick up the phone. I don't see a wiki changing this dynamic, wikis aren't the golden hammer that can fix any and every communication problem. --ChuckAdams
JotSpot crosses my mind when I read this. You can send email to every page existing in their WikiEngine, and so you can archive that emails. See further info at http://www.jot.com/icon_sendemail --BerndSchiffer
SocialText also allows you to e-mail directly to the wiki, except e-mails become page text. In fact, you can edit pages round-trip using e-mail, by sending the page as an e-mail to you, editing it, and then e-mailing it back (with the "attach: replace" command). The JotSpot usage pattern is not streamlined as all it does is store the e-mails as attachments to the pages, like a DiscussionBoard, but not as pages themselves (as SocialText does). I'm not aware of any other WikiEngine with similar functionality (maybe TWiki?), but that's not surprising as it requires having a dedicated SMTP server or e-mail account accessible by the WikiEngine. -- SunirShah
Interesting. The subtlety in the use case is the behavior when replying to an email. The conventions in ordinary email are mixed and inconsistently followed. The internet mailing list convention is to strip out everything but the most recent comment. However, that assumes that the reader remembers the context, or has a reader client where the context is easily visible and easily associated with the prior post. When that convention is not followed, people use a windows convention of putting responses at the top, or a unix convention of putting responses at the bottom. -- AdinaLevin
The subtlety of maladaptive user behaviour when crossing media is likely self-rectifying as there is immediate feedback that email conventions are wrong. The page no longer looks readable, and therefore becomes unusable. The best way to find out is to try. It's on my list. -- SunirShah
Also see John Udell talking about querying for email threads - http://weblog.infoworld.com/udell/2006/02/07.html#a1383 - he doesn't talk about the seekrit wiki refactoring concept -- AdinaLevin