YEdit IconDocument collaboration software > Archive > Web Collaboration Conclusion

This is an archived version, please use the menu on the left, or jump to the new version: 5.00 Conclusion

(4 Design > Test) Previous <=+=> Next (6 Glossary)

Co-operative authoring and collaboration over the World Wide Web using an engine called "YEdit", based at the web site http://www.YEdit.com/, demonstrates the co-operative authoring of individual documents, and collaboration in general.  The version that appears there is the latest version that has been tested successfully on the testbed servers.  The testbed servers are used to test the code before it is placed on the public server, they are also used to run tests that are better run on a standalone network, because they may interfere with other computers if run over the Internet.  Tests like load and stress testing are done in this manner.

YEdit demonstrates the ability for people to edit documents over the Web, from any location, at any time.  It stores documents in the local file system of the computer that is hosting the engine, and serves pages over the Web, with the ability for anyone to fully edit them while keeping full version information.  YEdit also allows for documents to be stored in the web server's document tree.  This means that the web server can serve the documents as if they were local static documents.  This allows the reading of the documents without regard to the status of the YEdit engine, this gives much better reliability than serving the pages dynamically every time.

The YEdit engine allows the free mixing of ideas by allowing anyone to edit any page.  People who would like to add their ideas only need to browse the web site, and start editing (whether creating new pages or editing current pages), to add their ideas, or to enhance ideas that are already present.  Of course should a Webmaster want to restrict a particular area to read only, or restrict access to only a select few, then the normal access provisions of the web server can be used.  This means that YEdit can be used for public editable content, public read-only content, and private content, with the use of the normal access controls that the web server provides.

All of this builds up to a vision of the future for the Web that allows the freedom for groups to work together to not only provide information over the Web, but to provide a means of creating new information at the same time.  That is, to allow the flow of information not only from the web server to the web surfer, but between groups of web surfers and web servers.  The ability for the information to flow in all directions is enabled by YEdit because it allows people to co-operatively author, and collaborate on, documents that they wish to share the creation of.  They can receive comments and additions, with the comments and additions made as part of the actual document, rather than making comments and additions using some other communication channel, like comment forms or email.

 

One of the early possibilities that was looked into for this thesis was to use web themes on the web server to allow a split between content and context information.  This split allows for there to be multiple ways of viewing information, all with one content base, that is, only one file to update that contains the content for the page.  The context information (images, buttons, other graphics, etc) could be linked to, and the appropriate version appears when someone views the web page.  For example, if the user is browsing in text only mode, all the graphics will be replaced with their text equivalent, or if it is near a particular time of year, the default images and graphics could be changed to match that time of year.  If the user prefers a particular theme or colour scheme, providing the web site supports that theme, the user can view the site using it.  Because this is all done on the server side, there are no requirements placed on the user, therefore anyone can use it.  Prototypes were created, first in 'C', and then in Java to test the idea and to see if it would work.  These themes allow the user to choose the method of display that is the most appropriate and convenient for them, with only one web page for the Webmaster to keep up to date.  Thus users can view the page as they wish, and the Webmaster only has to keep one set of information up to date.  These prototypes showed that it could work with fuller integration into the web server (rather than calling via SSI's (Server Side Includes; these let a user embed a number of special 'commands' into HTML.  When the server reads a SSI document, it looks for these commands and performs the necessary action.  For example, there is a SSI command that inserts the document's last modification time.  When the server reads a file with this command in, it replaces the command with the appropriate time.) or Servlets as was done in the prototypes).  This idea was considered for use in this thesis, but at the time (circa 1998) others were floating ideas of using templates and similar ideas for a similar job.  Since then other technologies, such as XSL/XML, JSP/XML, or JSP/HTML, for separating content from context, have maturated.  Unfortunately it is impossible to tell if these technologies are widely used (or used at all), because the entire interaction happens on the web server, before the user sees the page.

Along with web themes, Multi-tier and multi-homed web sites were looked at early on.  The thinking behind multi-tiered and/or multi-homed web sites is that in case one part of the site fails or is lost in some manner, another part can take over at least some of the responsibilities of the failed part.  That is to display and/or store information so that it is both stored safely and accessible.  This had potential to be used by itself, or in combination with other ideas.  Using multi-tiered/multi-homed web sites in combination with other ideas such as the free flowing web of information allows for a more robust system.  This is because it tolerates any problems with the dynamic web site (that may be encountered in any newly designed system that are results of unexpected situations), as most people will be viewing the web pages from the static read-only web site, while editing is done on the dynamic site.  This allows both the read and edit parts of the dynamic web site to crash, while only inconveniencing a small proportion of users.  The level of service and information that is replicated over the different locations determines the level of redundancy offered by a multi-tier/multi-homed web site.  The ability to access the latest version of a web page is the most important one to have available, as most people are probably surfing the Web, not expecting to be able to edit it.  This is backed up by the access patterns on http://www.YEdit.com/.  In the past 2.5 months, people have viewed 2729 web pages on the web site, while only making 25 page edits during that time, which is approximately 1% of page views were to edit a web page.  This page view and edit information shows that if there are any problems, the way to minimise the impact is to make sure that the majority of people can continue to do what they were doing, and that is to surf the Web (in this case, view the read-only pages).  This means that the most used part of the YEdit engine, and therefore the part that is most important to replicate and keep redundantly available is the ability to view the latest version of the web pages.  This split between reading the latest version of a web page, and browsing all the versions and editing them, is used in the YEdit engine to allow a multi-tier, or multi-homed system to exist, and allows for the redundant storage and viewing of the latest versions.  Another reason for the split and redundant availability of the web pages is so that any problems in the more complicated subsystem detract as little as possible from the overall system.  There are other multi-tier/multi-homed systems that can be used (and could be used in conjunction with YEdit), such as load balancing between machines, mirror web sites, and lately Akamai Technologies (who have web servers located globally, and replicate web sites to the servers that are closest to users).

The YEdit engine was created in Java, using Java Servlets.  At the time, Java was a very new language, but it had good support and several advantages over other languages such as Perl or C/C++ for server side applications.  There are some very important considerations when writing applications that are to run on a web server.  Some of these are robustness, abilities of the language, portably, support, and general susceptibility to errors, especially buffer overruns, as they are one of the most common exploits.  One of the important things for YEdit is the dynamic object nature of Java.  C++ has similar abilities, but lacks the easy portability, and can have problems with security (especially buffer overruns).  Perl seemed to lack some of the abilities (such as reducing heavy load on the web server, unless the server supports persistence for Perl, like "mod_perl" in Apache, and less opportunity for dynamic object oriented code loaded on the fly), while Java Servlets stood out with a very good match for the needed abilities, with the advantage of a similar syntax to C/C++, which eased the initial learning of Java.  As Java was such a young language at the time, it was important that the reasons for choosing it were because it did what was needed, as has been the case.  Today it is a much more accepted language, and over the past years, the support for Java Servlets has increased in the commercial web server market.  There are now a reasonable number of web hosts to choose from, whereas when this was started, there were hardly even a handful to choose from, and if you wanted Java Servlet support, it was almost a case of setting it up yourself, which actually is not all that hard.

The YEdit engine is flexible enough to be used for a wide range of different document types, from web pages, to word processor documents, to any kind of document that one wishes to edit co-operatively.  It also has the capability to store the documents in any kind of repository that an interface can be created for.  This potentially allows it to access and store information in any current document storage system, and to serve the stored documents from this system to any document editing facilities that are available.  This allows any group or business to have the full advantages of co-operative authoring, while keeping prior investments in legacy technology intact.  It enhances their ability to advance the technology they use to the latest that is available, without many of the normal side effects of changing the software that people are used to using.  The side effects are mitigated because most users can continue to use the software that they are familiar with, while allowing the software that is working in the background to be advanced and upgraded.  Because the user interface and server interfaces of the YEdit engine are independent, there is no reason that a particular storage system should be used for any particular software that a user is using, this allows for the storage system to be completely upgraded with little impact on the users.  This de-coupling of the storage system from the user-editing program also has the side effect of allowing an user interface for the YEdit engine to be created that can automatically convert documents to a standard format for storage.  This can have the benefit of allowing user-editing programs that store files in different formats to be used, accessing the documents transparently to the user.  The document may have been edited in a completely different editing program, as YEdit could provide the document in a particular programs native format, without the need for the user to intervene.

YEdit is flexible enough to support future expansion and development in methods for storing and serving documents.  It was designed to work over the Web to begin with, to test and evaluate possibilities for use and to allow people to become familiar with this type of system.  The Web is also expected to be the most used interface, therefore it should be the first one created.  Included in the future developments for storing documents is using databases to store the documents, and the possibility of storing documents into source code revision storage facilities, such as CVS for advanced version control.  Included in future developments for serving documents are a simplified web edit ability (for those that would rather have a simpler way to edit documents), serving and editing documents using WebDAV (an open distributed authoring and versioning protocol), WAP (browsing simplified web pages on mobile devices), and directly into your favourite document editing program, using their native formats.

 

The major goal of this research was to see if it was possible, and if possible to create, an system that would handle co-operative authoring over the Web.  As a secondary goal the system should be flexible enough to potentially handle any kind of document, any kind of storage system, and any kind of user application to access it.  Successful implementation of the YEdit engine has demonstrated the viability of those ideas.  The secondary goal was also achieved, allowing the flexibility of any kind of document to be stored in any kind of storage system that has an interface created for it, and accessed by any kind of user program that an interface is created for.  Now that YEdit has been created, and has interfaces for editing the Web, it will be appropriate to create interfaces to other applications.  This is so that YEdit can be used by a variety of different applications, and interfaces to a variety of different storage systems so that when people first hear about YEdit, they know that it can interface with their current set up seamlessly.  This will allow them to use the software that they want to, rather than being locked into any legacy system.

Further research could be possible into how a system such as YEdit will affect the use of authoring software in groups, especially from the point of view of businesses, as YEdit has implications on the use of both legacy and current software.  Other research areas could include how people use the YEdit interfaces (where they are visible to the end user), and whether the interfaces should be completely transparent, or should give some sign to the user that they are being used.  Also there could be research into the refinement of the Web interface, and web page editing interfaces in general for editing documents live on the Web.  This would have implications not only for YEdit, but also for web editing in general, and may have a flow on effect to other editing interfaces.

There are other things that have been created in the process of conducting this research that are not directly related to its aim, such as the design and construction of the web pages to support the YEdit engine.  These web pages inform people about the uses and abilities of YEdit and these web pages can be enhanced in the future.  Along with enhancing the web pages, further promotion of http://www.YEdit.com/ can proceed especially with regard to users who may wish to use the abilities of the YEdit engine to enhance their co-operative authoring and collaboration.

The YEdit engine has succeeded in demonstrating that co-operative authoring of individual documents over the Web and collaboration in general is possible, and that it is possible to create an engine that is general enough that it can support a wide variety of document types.  The front end can interface with many different applications, allowing people to work in the manner that best suits them, and the storage interface can store documents in any locations that are appropriate for the documents concerned.  The current main user interface is through the Web.  This means that it can be widely used and tested without the need to install specific software on users' computers, allowing a broad range of people to try it out and decide if it will be useful for them.  The YEdit engine also allows a wide range of document storage systems to be used.  The combined abilities to handle any type of document interface with any kind of document storage system, and interface with the users most used applications will allow the YEdit engine to enhance even legacy systems with the maximum of ease and usefulness.

(4 Design > Test) Previous Next (6 Glossary)