A Solution? One possible answer
The YEdit content/document management software (which a prototype had been created for, and was available for public use) for co-operative authoring, collaboration and content management was based on the free flowing web of information that includes some of the original intentions for the Web; that is to use the Web for both reading and writing. This system could provide a possible answer to the problem of many people working on documents together that do not support easy collaboration, without extra work, such as remembering to email the latest version on to others.
In searching for the very information that I needed to work on this problem, I came up against one of the problems that I am trying to solve. That is, the problem that as information is revised, it is very easy to unintentionally lose important information. This problem is not so evident in print mediums, because once information is printed, it can be stored that way, and is very seldom rewritten and replaced. Unfortunately, on the Web, things are changing so quickly that information that is present one day may not be present the next. To keep pages updated authors often add, replace or remove information. Sometimes this is deliberate changing of information, but more often it is just that the information that was present, seems to the author to have less relevance now. The problem with this is that the very piece of information that one person may think is no longer relevant, and years out of date, may be the very information that someone is looking for, as I found in my search. Luckily W3C (The World Wide Web Consortium, http://www.w3.org/) did keep the old outdated pages, and some digging around their site revealed them, even if it took a little work.
While looking through these documents I realised that one of Berners-Lee's original visions for the web was along similar lines to what I was thinking would be a good direction for the Web to go. My idea was for an engine that could be used by almost any front end (be it web browser, word processor, web site, etc) that would allow interaction with full version tracking information. This would allow web sites (or any server or application) to keep the full revision history for documents (any kind of document, text, pictures, sound, etc). It will also allow any groups that have permission, to edit, update and change any available document.
The engine that I created worked as an extension of the web server. It could also work standalone for applications that require collaboration, utilising interfaces other than the Web. The engine abstracts both the user interface and the file system interface, allowing other methods of interaction to be plugged in and work seamlessly. This allows for the engine to be used through a normal web browser and via other connection methods at the same time, using the same base of files. It also works the same the other way around, (refer to Figure 4: Interaction of the main components of YEdit for a graphical overview) allowing any base of files that it has an interface for, to be used by any of the access methods. This flexibility means that the engine has a much wider range of abilities to support collaboration than just the Web, or any particular file system. For example it could be used via a command line interface, direct into word processors, and store information in databases, version controlled repositories, etc. This would also have allowed it to be used where legacy systems exist, either as the front end, or back end, or both, allowing disparate legacy systems to interact, when under normal circumstances they would not be able to.
The content/document management software engine promotes co-operative authoring and collaboration by providing an interface that is built specifically for this, with full version histories of all documents, by default.
The Web interface to the YEdit engine could be used to read different versions of documents in the same way as you normally read documents over the Web. This meant that anyone could access the documents without needing to learn how to run a new application. The Web interface also supported modes for browsing the documents with collaboration in mind (that is, displaying information that is appropriate to the user about the document, for example the version number, last author, last date of change, and previous versions). This part of the interface also allowed you to edit the document, and at that time had a simple locking scheme to prevent changes being overwritten. Because all of the changes were kept in different versions, it was possible to keep track of each change, who changed it and when. This allowed certainty about the history of the document. The process of either reading the documents in the system, or browsing them with a view to editing them, or looking for information about changes, has been implemented so that as many of the abilities as possible are implicit in the display. Therefore anyone who knows how to surf the Web should be able to surf though the documents stored in this system, and need not know the inner workings to retrieve the information that they are looking for. The reading part of the interface is simply presenting the documents as they would appear on a normal web server, and may in fact be served as normal static documents, under a multi-tier web site design. Even the browsing part of the interface is designed so that the user is as unaware of the complexities of the system as is possible. This is achieved by providing a simple menu above the document, which provides information about the document, such as the last author, version number (and view versions), and the option to edit the document. Only if the user decides to edit the document does any of the complexity of the system show itself, and that will decrease as user suggestions (such as a simpler form for editing a page) are incorporated into the design.
This engine would allow web sites to be fully interactive, while keeping the version information that is important to ensure that the information is correct, and will even allow the whole site to be rolled back to a previous known working configuration, should disaster strike.
Because the full version history is included, and the ability to go back and check the previous versions, it will be easier to trust the information that you receive. If you have a query, you can easily check who changed what and when, especially if the site uses some form of write once media to either store the information, or to back up the new information.
| Previous: | 3.15 The future 2 |
| Next: | 4.00 Design through to testing |