Monday, May 19, 2008

Editable Versions and Groups

At last I can edit groups and versions, delete them, move them between groups or rename them. The Version Edit screen looks a bit crowded (see below) but I reduced the clutter somewhat by using links instead of buttons. Some people think this is poor style. It is far worse to have buttons disguised as links to achieve a similar effect. It is true that the wiki won't function without JavaScript, but it is simply impossible to build this level of functionality without it.

I have also added a Revert button, which restores the text or the versions to the state they were in after the last click on the Save button. The "Edit..." links take you to separate pages which allow you to edit the characteristics of the group or version:

What remains now are a few important features that I hope to set right before we go to Oulu:

  1. Find – I need to reimplement the same search facility we had in the desktop version of the tool. It should be easy because the highlighting of search hits is similar to the highlighting of differences between two versions, which we already have. No other application can search multiple versions simultaneously and in linear time – this is one of the great strengths of the MVD format.
  2. Beautify the buttons – these could be reduced to standard icons, and arranged over the top of each text column, instead of at the side. Rather than ugly strings the labels could vanish into 'tool tip text' that only appears when you mouse over them.
  3. Allow the user to author an MVD from scratch. This is meant to be the centrepiece of the demo at Oulo. It is fairly easy, but I will need to automatically markup plain text using TEI encoding and also check the syntax before committing it. That may have to be done in JavaScript again, otherwise we won't be able to alert the user to syntax errors.
  4. Image view and edit image view – this is really cosmetic but could be quite impressive. The only way I can think of getting the correct image to display in HTML as you scroll down is to use hyperlinks in the right hand window that call JavaScript to set the image of the left hand side. At the moment I don't know how to achieve the same effect in edit view.
  5. Synchronise the left and right hand text in Twin View. This can also be done by hyperlinks, as it was in the multilingual example metioned earlier. What it means is that the text on the right corresponds to the text immediately on the left. The user should never have to scroll and read to align the texts manually. This is really important.
  6. Transpositions – I think these can be done as an optimising step after alignment has been completed. Then any significant pairs of deletions/insertions can be tested to see if they qualify as transpositions. I think if we recalculate them after every update there won't be any problems as to which bits are transposed and which bits are insertions/deletions etc. It all boils down to the status of individual fragments: a bit of text is either inserted, deleted, transposed, a match or a variant. When those characteristics change we start a new fragment.
  7. Edit Twin View – I want to use AJAX to automatically update the left hand HTML version of the XML the user is editing on the right.

That's quite a lot of work before I can call Phaidros version 1 complete, but it shouldn't take more than a couple of months at most. Then we will have a completely new tool to play with. It will be exciting to see where we can take multi-version text then.


Unknown said...

The Find function is great, I wait for it ! The process for transpositions is very interesting also.

desmond said...

There are some things called "multi-version documents" already implemented but they use version control to record revised versions of entire elements. That's not the same thing as our problem and it is very clumsy to search through all versions. I would like to add your transposition method to the program if we can manage it. I think it will work.