[Home]ThreadingForWiki

MeatballWiki | RecentChanges | Random Page | Indices | Categories
This page is about adding threading to wikis.

See WikiLog for general discussion about combining wikis and web logs.

Working definition (please refine)
a time ordered list of entries similar to that provided by WikiLog's but extended to support threads of discussion through the facility to reply to individual entries.

Eventually I would like to add a feature like this to UseModWiki. I would like for each page and comment to have a "reply" link, and for each comment to be individually editable. One feature I would like to add is to allow threaded discussions to be split and mingled with page text. A page might start with a summary followed by the main discussion thread. Significant subthreads could be separated from the main thread and given their own summaries. Eventually, if a subthread becomes large enough, it might be moved to a separate page.

This isn't likely to happen "soon", as other features (like categories and translations) have priority. It might wait until the eventual DB-oriented rewrite of UseModWiki (version 2.0). --CliffordAdams

Pros and cons

Care to elaborate? Why do you want it? EasySubmission seems to indicate that there is no benefit in such an approach. Somehow it doesn't feel like the AppropriateMedia. --AlexSchroeder

I don't think this feature would help "wiki" communities. I'm interested in other things besides wikis, however. There are a large number of sites which have trained users how to use comment/reply systems, while few users have experience with wikis. Newcomers may feel more comfortable writing a separated reply/comment than editing the full text of a page. (Heck I've felt inhibited on Meatball sometimes, especially given the strong DocumentMode bias of some authors. :-)

Some site owners may want to limit full page-editing to a small (or large) editor group, while still allowing public comment. For high-volume systems (like KuroShin or SlashDot), the collaborative page editing model would likely deteriorate into a mess of edit-conflicts as many people edit pages simultaneously. With separate comments, many people can reply (near-) simultaneously.

Another reason for such features is to allow a better interface for threaded discussion than the erratic "ThreadMode" conventions. For example, some people might want all comments expanded in the text in a nested/indented list, while others might want to see only the subjects of each comment. Another improvement is that RecentChanges could display the number of new comments in addition to the number of edits. If a user has a username, one could search for pages that they recently commented on. Etc... You can't do much automatically with free-form text.

For me, one of the biggest benefits of UseModWiki as a separate project is that I get to set the development priorities. (User requests are welcome, but I say "no" a lot.) Anyone who wants to change that will have to get out their checkbook... --CliffordAdams (I'm cheap, but not that cheap. :-)

Implementation Ideas

Some bloggers find discussions on wikis painful. One reason, probably, is the added complexity in editing a large page in order to reply to one comment. The solution really means reworking the page so that is smaller, but this takes time and patience. For those used to a quicker pace of existence, a more direct method may be required.

The basic blog method of ThreadMode is to create a tree of comments and replies. This is not hard to reproduce as it stands on a wiki, especially one like UseModWiki that has the colon (:) syntax for indenting a block of text. However, one still needs to edit the entire page in order to post a comment. With the edit-box method of EasySubmission, it's easy to append to a page, but that method of commenting is seen as primitive by blog standards.

Now, when you use EasySubmission to append to a page, you submit a block of text that the script has to place on the page for you. The script could easily format this text in some reasonable way, such as appending your signature and possibly a timestamp. Indeed, some implementations already do this. Suppose the script also appended some special WikiSyntax as a marker to indicate the end of a comment as well as some unique identifier for the comment, say ~~~42 for argument's sake. When rendering the page, whenever it encounters ~~~, the script could then emit a link to a reply form with the number 42, and the current indent level of the last paragraph (as indicated by the number of colons preceding that paragraph). When submitted, the script merely searches for ~~~42 in its internal WikiSyntax of the page and inserts the replied text. This fits the current blog idiom of pasting replies newest to oldest as well. And if the tag ~~~42 is missing, meaning it's been edited away in the meantime by a good wiki editor, an EditConflict dialog could occur.

This not only allows for the ThreadMode so longed after, but it places all the comments on a wiki page that is also editable by all, allowing people to rework the page in place. Think about the benefits of being able to edit the threaded comment section of a weblog story. You could remove trolls, reduce noise, unify redundancies, delete mistakes, and otherwise do all the things we do already on a wiki. Think about the benefits of having an easy threaded submission mechanism on a wiki. If participation and action is important to you, this will increase the pace of writing. If you want a WikiLog, this will be a further bridging of the two worlds.

Among the discussions of this kind of thing with respect to MediaWiki, an interesting proposal is at MetaWikiPedia:LiquidThreads

An implementation should support the upcoming [threadsML] thread metadata standard.

Similar Implementations

TWiki:Codev/EvEm has proper threading on a TWiki site - not yet part of the core TWiki code. Also, TWiki:Plugins/CommentPlugin is an addon to allow 'quick comments' a la WebLogs without having to edit the whole page. There's also the weblog-inspired TWiki:Codev/WikiRssExtension (aka ModWiki) for generating RssFeeds from TWiki. -- RichardDonkin

TWiki:Codev/EvEm ceased using TWiki when (summarising the reasons) they realised they were trying to use a wiki to do things "badly" that a weblog does well. The comment plugin noted above helps more lots of sequential posts style discussions rather than threaded discussions. Which it doesn't really help with. Sectional edits combined with a comment plugin helps more there, but still aren't threaded [example].- MichaelSamuels

Other ideas

See TouchGraphWikiBrowser for the interesting related idea of aiding refactoring by allowing one to easily move parts of pages around. i.e. in a truly threaded wiki, individual comments could be one of these "parts". This would make it very easy to move a subthread or a few comments from a thread to another page. (see WikiRefactoringBrowser) -- BayleShanks

I posted [a similar idea on WikiFeatures: BuiltinThreading.] One of the options is to make "talk rooms" anywhere on a wiki page. You'd write "discussion:blahblah" and that would create a threaded discussion. If you wanted to, you could link to it from three wiki pages, or start it from one wiki page, and then easily move it to another wiki page, just by moving the "discussion:blahblah" title. No reason it couldn't be email tied as well. You could get updates by RSS or Email or a recent changes for the discussion or a super-recent changes for everything. -- LionKimbro.

CategoryWikiTechnology CategoryUncommonWikiTechnology

Discussion

MeatballWiki | RecentChanges | Random Page | Indices | Categories
Edit text of this page | View other revisions
Search: