Mocked up screen shot of DiffDeck

DiffDeck is an idea for a piece of software which I (Yaris678) presented at WikiConference UK 2012. The main idea is inspired by TweetDeck. The proposed software displays multiple diffs next to each other in columns so that a user can scan across and quickly get an idea of the history of an article.

The requirement for the software comes from the fact that the standard article history tab is reliant on edit summaries provided by editors. These can be missing, cryptic or misleading. The history tab enables the generation of a comparison between different versions of an article, also known as a diff. A user can end up generating multiple diffs, flicking between tabs and generally going backwards and forward. DiffDeck aims to make this a lot easier for the user.

The screen contains a number of columns. As with TweetDeck, the user can scroll left and right over a wide range of columns. Each column contains a diff for an edit. In the example screen shot given, the diffs have been generated using Schnark's method (based on Cacycle's, based on Heckel's). As well as other advantages, Schnark's method gives a diff in a single column, which suits DiffDeck.

Near the top of each column is the date of the edit, the name of the editor and the edit summary given, as per the article history tab. Above this is some slightly less familiar information:

  • The number of characters added to and removed from the article is given as two separate numbers, unlike the net size change given on the history tab. These two numbers can easily be derived from Schnark's diff.
  • The number of characters moved can also be shown, since this info also comes from Schnark's diff (it is not shown in the screen shot given because there is no moved text).
  • The proportion of the edit that remains in the article is shown. I think this could be calculated using algorithms similar to (but simpler than) those used in WikiTrust. Perhaps this feature will have to wait until the details are worked out.
  • If the edit is undoable then rather than show this number as 100% (which must be the case) a symbol is shown. The ⎌ symbol used in the screenshot is character 9100 from the Miscellaneous Technical Unicode block.

The small square icons along the bottom summarise a larger number of edits than can be shown as diffs on a single screen. The icons shown in the screenshot come from Huggle and are described on a page of Huggle's manual.

Other useful features:

  • Hide reverts. Addition and removal of vandalism can clog up the article history for of some articles. Perhaps an option should be included to hide the revert unless the reverted editor has more than say 100 edits, that way DiffDeck will show almost all genuine disagreements over content while hiding most vandalism.
  • Combine edits of a user. Especially useful when an editor makes a change and then corrects their own typos.
  • Combine a larger number of edits. This can give a more general overview of the article history, but would include the ability for the user to select a combined set of edits and expand them into individual edits (or maybe even expand a large set into several smaller sets).
  • Select a bit of text and then find the diff where it was added or removed. This could use WikiBlame, or perhaps an algorithm related to WikiTrust. A variant of this feature would relate to the case where you have a combined set of edits and you want to find the edit within that which relates to a selected change. DiffDeck could show all diffs which contain the change, and leave the other aspects of the combined set in smaller combined sets.

If we are getting really advanced, DiffDeck could act as a client for STiki. That would enable it to show an editor a questionable edit (as STiki does) but also show previous edits so that any earlier vandalism can be spotted. If such a system were successful, it may even prompt a change in the STiki server to allow edits that are not at the top of the edit history (although that would require some clever changes to the stiki server, not just the client).

What next? edit

DiffDeck needs a developer, or maybe several developers. I have some knowledge of software development but no knowledge of developing anything for MediaWiki.

At some point a decision will also have to be made about the platform that DiffDeck uses. Some ideas are:

  • Adobe Air, used for TweetDeck
  • Java the language on which STiki is based.
  • Huggle. Would is make sense to make DiffDeck a feature of Huggle? It already has the icons and must have routines for extracting information from a wiki. A version 3 is apparently in the works.
  • A MediaWiki gadget based on JavaScript. This would make it easy to use Schnark's diff and easy for a user to install.

Multidiff edit

A relatively simple piece of code could provide some of the functionality of DiffDeck. The code would create a button and two tick boxes next to the Compare selected revisions" button". These would be as follows:

  • A button labelled Multidiff - opens up multiple tabs in the browser, each of which is a diff in the range selected by the user with the radio buttons. By default, this would give one new tab and diff per edit in the selected range.
  • A tick box labelled Merge by author - if selected, the multidiff button will merge adjacent edits into a single tab and diff, if they are by the same author.
  • A tick box labelled Ignore reverts - if selected, the multidiff button will detect if an edit is a revert of the preceding edit. If this is the case, neither the revert nor the reverted edit will be displayed in a new tab.

This does not display the diffs side-by-side. It does not have some of the information described above or make it so easy to navigate through the history of an article. However, the user can get an overview of some of the articles history quite quickly by flicking between the tabs generated.