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.

Seldom does a programmer have the privilege to use his own product in a real-life situation, but as an Australian living in Sweden I am often asked by friends and colleagues to proof read or even translate text. I was recently asked to proof read a short text for a friend who works at Myra Industriell Design, an early adopter of TextFlow.  I promptly fired up TextFlow and devoted half an hour to fine tuning and polishing the text. I was quite proud of the minor adjustments that, in my eye, really made a big difference to the text.  Imagine, then, how disappointed I was when WeaveSync just clobbered all my changes together into two big yellow blobs:

Which brings us to this weeks blog.  What is WeaveSync?  And, more importantly, why do we need your help beta testing WeaveSync?

WeaveSync is the heart of TextFlow. It is our patent-pending approach to comparing multiple versions of text, and much of WeaveSync is a direct beneficiary of the many, many years of research being done in the fields of bioinformatics and DNA analysis. Early on, when designing TextFlow, we realised that there isn’t such a big difference between text and DNA strings as one might first think - and careful adaptation of several bioinformatic algorithms got us quickly up and running with our first version of WeaveSync that could compare two documents and show differences, such as transposition, intelligently.

WeaveSync is constantly evolving and being improved as we discover types of text modifications that it doesn’t handle well.  We have always been careful to design it so that even the worst case scenario for any change is still usable, such as the above example where it presents my changes as a single rewrite of a paragraph - even in this situation I can still make use of TextFlow. However, in situations like this we humans can easily see how TextFlow could have given a more detailed presentation of the changes I actually made - that it can more accurately reflect the real-world situation.

This is why we need help from our beta testers not only to find bugs in TextFlow itself, but to also help us improve WeaveSync.  If you think that TextFlow could have done a better job when analysing a particular part of your text, please report this just as you would any other bug, along with a comment about how you think TextFlow could have presented the change.