A number of people have been asking us lately about how TextFlow might be used in a Wiki environment. Wikipedia, the most successful example of a Wiki, is an online encyclopaedia that is built on the idea of user contributions - each entry in Wikipedia is built up collaboratively over time. At first glance, it seemed like TextFlow would be a perfect tool for comparing several versions of an entry in Wikipedia and resolving them into a single version, and here I thought I had the perfect topic for this weeks blog: how TextFlow could help editing Wikipedia.
Wrong. I quickly discovered that finding an interesting example to illustrate the value of TextFlow for Wikipedia was difficult to say the least. Every entry I looked at seemed inherently linear in the way that it was built up over time. 
Which lead me to a more fundamental topic for this blog: is something like Wikipedia inherently linear? Or is it linear simply because the tools for working with it enforce linearity? Are these tools limiting Wikipedia in some way?
Wikipedia works by having multiple versions of an entry, slowly built up over time, with each version adding new information or polishing the existing information. In order to avoid the conflicts that arise with branching versions, Wikipedia strictly enforces a linear editing and versioning system - each version builds strictly on the version before it, the current official version, and each new version becomes the new official version when it is saved, leading to a linear evolution shown in the image to the right.
TextFlow’s strength lies in supporting concurrent editing; the branching and merging of multiple concurrent versions, allowing editors to work in parallel and to reach a consensus over several iterations of branching and merging. This is possible because TextFlow does what other collaborative tools don’t - it gives you a way to handle the merging of many documents into a single result. Editing in TextFlow more typically looks like this:
With Wikipedia now looking to introducing flagged versioning to combat problems with vandalism, could a TextFlow-like tool that allows concurrent editing help? The current suggestion at Wikipedia of having flagged revisions is quite simple: someone who is trusted can flag a particular version of an entry as being OK for public viewing, a sort of “vouching” that the content in this entry is approved and thus accurate to some degree.
I think TextFlow should be able to help here - allowing anyone to make edits from the flagged version, thus creating many branches. These branches would then be merged into a single consensus version that is ready for flagging by an editor. TextFlow would streamline the process of merging and approving by clearly highlighting every change and making it trivial to accept or reject each individual change.
I’m still looking for a good example of where TextFlow could have helped in Wikipedia - either by allowing for faster development of an article, or avoiding any contributions from being missed. If anyone knows of a good entry that could be used to demonstrate the strength of TextFlow, please let me know and I will package up the Wikipedia entry as a TextFlow demo much like this one.
I’m definitely one who thinks TextFlow could be used in a wiki environment. I’ve been running wikis for many years and often encountered those situations when the linear diffing of todays wiki engines just doesn’t help that much.
One scenario is when a topic is “hot”. Could be because all of a sudden there’s is lots of new information to add. On Wikipedia, maybe that’s the case right now when the heir to the Swedish Royal Crown has announced her marriage. In those cases several people are spending some lengthy amount of time editing the article. If you spend an hour of time then you’re in for a tough time trying to merge your additions with that of maybe ten other people who’ve submitted while you were editing. Very often you end up just sighing “never mind”. It’s bad! And it gets worse if you think about how demoralizing it is. Next time you’ll think twice before spending an hour adding your knowledge. The community is the loser. TextFlow-style merging could solve this! (I think.)
Another scenario is when an editor decides to remake an entire article. Maybe the next editor disagrees with some or most of the new structure. But there’s only the “roll back” option available. Using that doesn’t feel quite right. You don’t want to discourage the initiative taken by the first editor. The option on today’s wiki engines is then something like starting a discussion about it. But chances are it stops there. The page ends subotimal and the community is at loss again. I think TextFlow-style would help here too. Especially if TextFlow would support annotated edits and merges (somehow, it’s not really clear to me, just “feels” possible).
Further, I think that the linearity you see when you try to follow the development of a wiki article today is more an effect of the lack of TextFlow than something inherent in the wiki technology/philosophy.
I think TextFlow would help also in the slower maintenance phase of a wiki article. What if you could edit the page much more WYSYWIG using TextFlow and interactively get help keeping track of what you’ve changed and how. Again it’s not really clear to me how, but my intuition says it’s good! =)
Thanks for bringing TextFlow to the world. It’s really inspiring when someone reinvents the wheel. Some wheels really need it!
To a man with a hammer, everything looks like a nail.
Mr Shaw: whilst I agree with that saying in general, in this situation I feel that it is a bit misplaced. Our tool allows for merging of multiple versions of text. Wikipedia is a text based versioning system that only allows for a linear version development. This blog is asking the question: what benefits might there be to Wikipedia if it could allow splitting and merging of versions? The answer “none!” would be perfectly acceptable, but the question is still worth thinking about.
Wikipedia might be a screw to our hammer - but surely you can’t argue that it is a banana?!