Abelard: A Tool for Slow Discourse

Posted on Published by Eugene Eric Kim

I recently came across Jack Cheng’s essay, “The Slow Web” (via Alex Pang). Jack describes the Slow Web Movement as analogous to the Slow Food Movement. On the one hand, it’s a reaction to the “Fast Web,” this on-demand world of information overwhelm. The Slow Web, on the other hand, is about rhythm. It’s about doing things when they feel right to do, as opposed to whenever they come up.

I studied history of science in college, and I used to enjoy reading the correspondence between different scientists. It was this incredibly intimate experience to be listening in on these conversations, but what really struck me was the quality of discourse. They were respectful, thoughtful, and insightful. They were also slow. If you paid attention to the dates as you read, you’d start to feel a rhythm to the correspondence.

Respectful, thoughtful, insightful, slow. These are not words that describe most of the correspondence on the Internet today.

Ten years ago, I came up with an idea for a tool called Abelard. It was a tool for slow discourse, an attempt to integrate the best of the Web with the slow, wonderful art of letter-writing. The name of the tool was an homage to the medieval philosopher, Peter Abélard, who became famous for his romantic correspondence with his student, Héloïse d’Argenteuil.

I never had a chance to actually write the tool, but it seems fitting that — after 10 years, having had a chance to let the idea stew in the back of my mind for a very long time — I would share the idea for the tool in the hopes that somebody else might be inspired to build it.

The original concept had two key features. The first was a time limit. You would only be allowed to post once a day. The goal was to encourage rhythm and thoughtfulness.

  • Read people’s thoughts
  • Sleep
  • Write a response
  • Sleep
  • Read people’s responses
  • Sleep
  • Repeat

Simply slowing the conversation down would encourage higher levels of discourses (how many flame wars would be prevented if people were only allowed to post once a day?) and higher levels of participation.

Second, it would have tools to make it easy to respond to multiple ideas in a single post. Most of our current tools (especially email) encourage us to respond to individual ideas in separate posts, which leads to divergent conversations. The ability to combine multiple points (perhaps shared by different people) in a single post would encourage convergence.

My focus, at the time, was how to architecturally enable features like this. (This was building on the work that Chris Dent and I did around Purple Numbers and granular addressability and that Chris has continued developing with TiddlyWeb.) But the world of the web has evolved a lot since then. If I were to build something like this today, I would focus much more on the user experience. I’d also spend a lot of time on making it a delightful experience, in the same way writing on beautiful stationary with a great pen is delightful. Paperless Post is a great model for this.

I recently came across a group called the Letter Writers Alliance, which is trying to revive the art of letter writing. I would love to see a tool like Abelard that combined the same joy and benefits of letter writing with the magical world of the Web.

Kwiki::Purple, Wiki Deep Thoughts

Posted on Published by Eugene Eric Kim

My ex-partner-in-crime, Chris Dent, has been busy coding and expounding. Last month, he released Kwiki::Purple, a Purple Numbers plugin for Kwiki. You can play with it on his test site.    (IFZ)

This is fantastic news on a number of fronts. First, it’s further validation of our strategy to have the ideas take over the world, not the code. As I’ve said from the beginning, the purpose of PurpleWiki is to be a vehicle for ideas. Our goal was not for PurpleWiki to become the Wiki, but for other Wikis to steal our best ideas. There are now three Wikis with Purple Numbers — Kwiki, Zwiki, and PurpleWiki — with hopefully more to come.    (IG0)

Second, the fact that Chris was able to implement this as a Kwiki plugin makes Kwiki a more viable option for Blue Oxen Associates as its Wiki platform of the future. This is a good thing for many reasons.    (IG1)

Chris has also been doing some expounding on Wikis. His entry, “Why Wiki?”, is old hat for folks who know Chris, but it’s a nice, clean summary of his views for those who don’t. His framing of augmentation versus automation (discussed in much more detail in his paper, “The Computer As Tool: From Interaction to Augmentation”) is powerful, and I’ve borrowed it in my own thinking and writing. I also liked this line:    (IG2)

Architecting these sorts of tools may not solve poverty and hunger, or alleviate suffering in the aftermath of a disaster, but the tools can augment people actively doing that work. I happen to be good at making the tools go, so that’s where I look to fit myself into the puzzle.    (IG3)

Chris’s thoughts on Wikis as an external cache is another good piece. Two quick comments. First, viewing Wikis as an external cache reveals an important constraint. They are most valuable to folks who are already immersed in a conversation, because those folks already have some context that aids them in exploring the Wiki. For example, Wikis used for self-documenting events are not so good at involving those who did not participate, but they are extremely valuable for those who did. At the same time, they are better than nothing. If someone is motivated enough, they can use Wikis as a springboard for acquiring the context they need, and thus gain value that way. Think Out Loud is good.    (IG4)

Second, Chris writes:    (IG5)

I’ve found that in order for outboard processing to work there’s several design and process guidelines that have to be reached. Here are some: interaction must be highly responsive, noise in the interface must be minimized, structural mechanics and metaphors in content need to be consisent, names must have value, it must be there when you want it, when there is a shared brain its context is shared as well (e.g when some members of the company have a discussion about design it it is done in an archivable fashion).    (IG6)

(Emphasis is mine.) It’s ironic that Chris cites highly responsive interaction as a requirement for collaboration on an asynchronous medium to work. I agree that this is an important pattern of effective collaboration, but I wouldn’t go so far as to say it’s a requirement. There is an alternative mode, one that emphasizes deep thinking augmented by infrequent, but deep interactions. A big void in the collaborative space are tools that augment this mode of interaction. See my design notes on Abelard for an example of what such a tool might look like.    (IG7)

Transclusions, Path-Based Addressing, and Version Control

Posted on Published by Eugene Eric Kim

The PurpleWiki community has been rumbling recently, thanks largely to the contributions of two members of the Canonical Hackers, Jason Cook and Matthew O’Connor. Jason wrote perplog, an IRC logger that supports Purple Numbers and Transclusions. Matthew hacked a PurpleWiki node manager, then started adding and fixing other stuff, including an XML-RPC interface. Additionally, John Sechrest developed an experimental email interface to PurpleWiki. Lots of great stuff. It’s forcing us to get off our butts and make some long-promised changes and explain some long-undocumented things. Open Source is a wonderful thing.    (117)

A lot of the excitement is because of PurpleWiki‘s support for Transclusions. We had Transclusions in mind when we architected PurpleWiki, but we (or I, at least) didn’t think Transclusions would actually be implemented until much later. However, exactly one year ago today, Chris Dent got the itch and started playing. A few months later, Chris committed some code, and suddenly, we had Transclusions. It was a total hack, but it worked, and it was unexpectedly cool.    (118)

It’s still a hack, and it needs to be cleaned up, but it’s suddenly become a higher priority. First, we have a pretty good idea of how to support Transclusions “correctly.” Second, having had the chance to use Transclusions regularly, we are starting to recognize their utility and want to take greater advantage of that. (See, for example, my early specs for Abelard.) Third, people are starting to get excited about them.    (119)

Transcluding Multiple Chunks    (11A)

Currently, we support Transclusions of individual nodes (paragraphs, headers, list items, etc.) via the following syntax:    (11B)

  [t nid]    (11C)

where nid is the ID of the node you want to transclude. This works fine when you want to transclude small chunks, but at times, it’s useful to be able to transclude multiple chunks on a page. Rather than specify a transclusion for each individual node, it would be nice to have a syntax for specifying a collection of nodes in a single transclusion.    (11D)

Chris proposed the following syntax:    (11E)

  [t nid,nid,nid,...]    (11F)

This is problematic. The current implementation suggests that the transclusion command be replaced by the content identified by the specified NID. This proposal suggests that the command be replaced by both the content and the structure of the content. If you had a document like:    (11G)

  = Plan for World Domination {nid 1} =    (11H)
  # Finish PurpleWiki. {nid 2}    (11I)

and you tried to transclude this content with:    (11J)

  * [t 1, 2]    (11K)

what is the parser supposed to translate this to?    (11L)

A proper solution must be treated as its own structural element within a PurpleWiki document. More importantly, the syntax should capture document-specific context. This contrasts with the current syntax, which ignores document context entirely.    (11M)

Why is document context important? Suppose you have the following task list:    (11N)

  = To Do {nid 3} =    (11O)
  * Buy milk. {nid 4}   * Feed iguana. {nid 5}   * Implement distributed Transclusions. {nid 6}   * Vote in primaries. {nid 7}   * Expose API to Backlinks. {nid 8}    (11P)

Suppose you want to start a PurpleWiki-specific task list, transcluding all of the list items relevant to PurpleWiki (in this case, nodes 6 and 8). The resulting document might look like:    (11Q)

  {title PurpleWikiToDo}    (11R)
  = PurpleWiki To Do {nid 9} =    (11S)
  * [t 6] {nid A}   * [t 8] {nid B}    (11T)

Now, suppose you want to replicate this task list on another page. You could transclude all of the items individually, just as you do on the PurpleWiki To Do page. In this case, a slight variation of Chris’s proposed syntax (a standalone structural element) would simplify that process. (It also raises an interesting question: Which NIDs do you use for the transclusions: 6 and 8, or A and B? Does it make a difference?)    (11U)

However, what I really want to do is say, “Transclude all of the list items on the ‘PurpleWiki To Do’ page.” For this, you want something like XPointer:    (11V)

  [transclude PurpleWikiToDo#xpointer(id("9")/li)]    (11W)

A few observations: First, the command should be on a line by itself, and it should be interpreted as an independent structural element that will be replaced by a set of structural elements and content. I used “transclude” instead of “t” to make the point that these are two different commands. Second, the Transclusion command specifies a range of nodes within a document, as opposed to a document-independent list of nodes. Third, this combines a path-based address with an ID-based address.    (11X)

Fourth (and this is an implementation detail), if we want to support such syntax, it would behoove us to use an XML data model rather than the home grown model we’re currently using. This way, we could easily plug in existing XPointer implementations to do the queries.    (11Y)

Version Control    (11Z)

The fact that Wiki pages are dynamic throws a kink into all of this. The syntax I propose above takes this into account for the most part. Barring major changes to the PurpleWiki To Do page, the transcluded content will include all of the PurpleWiki tasks, even if more items are added later. If you had to list a set of NIDs, then you would have to be diligent about updating that list manually every time the To Do page changed.    (120)

In addition to supporting path-based addressing, we also need to allow people to specify versions in the address. In other words, you may want to transclude a specific version of a node or a set of nodes from a specific version of a document.    (121)

This shouldn’t be too difficult, but there are some complications. The biggie is whether to transclude a node if the node no longer exists in any document. My instinct right now is telling me that yes, it should, but it should make it clear somehow that it’s an orphan node. (See my previous entry on link integrity for more on this.)    (122)

Tools As Place

Posted on Published by Eugene Eric Kim

When we first launched the Blue Oxen Collaboration Collaboratory, a few people expressed some confusion about the tools. Specifically, one person said, “I’m not sure whether I should post ideas to the mailing list or the Wiki.”    (UG)

Someone I’m working with recently asked a similar question. Our project has a group blog and a Wiki, and this person expressed confusion over where to post a story.    (UH)

In both cases, my answer was, “It doesn’t matter.” Or at least it shouldn’t. My philosophy about collaborative tools is that they shouldn’t lock you in. As long as I can do all of the things I want to do with the information once it’s in a tool, I’m happy. This is not the status quo with today’s collaborative tools, but it’s something we’re working very hard to make happen. You can see some of the fruits of that labor in the tools that we use at Blue Oxen, and the tools that our collaboratory participants have created.    (UI)

That said, certain tools facilitate certain patterns better than others. Blogs seem to facilitate Story Telling better than Wikis. I think the main reason for this is that blogs are designed to be personal spaces, whereas Wiki pages are implicitly deindividualized.    (UJ)

What patterns does email facilitate? Email serviceably facilitates many patterns. That’s a blessing and a curse. It means that email is an all-purpose collaborative tool. But, when groups are using email in conflicting ways, it becomes burdensome. (See Problems With Email for more thoughts on this.)    (UK)

The ideal solution is to use an integrated suite of tools, each of which are there to facilitate specific patterns. If these tools are appropriately interoperable, then there won’t be “wrong” ways to use the tools. But, there will still be optimal ways to use these tools. Discovering what’s optimal requires practice. Hand Holding also helps.    (UL)

Email (and archived mailing lists in particular) plays two important roles in this suite of tools. First, it’s excellent for notification. Second, it’s excellent for Chatter. It can be as real-time as instant messenging, but the end result is more structured.    (UM)

I think there’s a niche for a tool for discourse that is even more structured than email or threaded forums. I don’t think Wikis are the answer. I think group blogs and tightly bound blogs come close, but are not quite right either. I’ve been sketching out the design for a tool I believe will fill that niche, which I’m calling Abelard for now. The design is in its infancy, so I won’t say anything more about it now. However, you’re welcome to view (and contribute to) its Wiki page, which contains a brain dump of the ideas. Comments and questions (in any form — on my Wiki, on your blogs, or via email) are welcome.    (UN)