Recent studies have shown that authors spend more time reading and annotating documents written collectively than creating original documents. Even when writing formal documents from scratch, the text is often a composite of fragments from other, existing documents. Web-based tools to support these reading and editing processes are presented in this paper. Particular emphasis is placed on reusing document fragments.
The author has been developing collaborative, document editing tools for some time using the web browser as the thin client but rich feature application. A new collaborative tool, DotNotelets, that leverages the rich dynamic HTML editing component built in to the most popular modern web browser is described. This DotNotelets tool allows documents to be constructed from reusable text fragments, referred to as fraglets. A simple but effective distributed architecture is discussed to support the tool built around the new technology of XML web services. The paper concludes by considering the mechanisms of such a document construction process for formal documents in business and the professions.
Reusable document fragments, browser user interface, XML, web services, dynamic HTML editing component, distributed documents, document fraglet architecture.
Reading the very early history of the World Wide Web (Berners-Lee, 1999) (Gillies & Cailliau, 2000) reveals that the first web browser allowed users to edit a web page as well as reading it. When the web browser had to be implemented across several hardware/operating system platforms it was more straightforward to make browsers display-only. HTML forms were introduced to add a simple data entry facility to make up for the loss of full editing capability.
In the area of word processing, Brush and his colleagues (Brush et al, 2001) have studied the patterns of use of Microsoft Word users. They discovered that the most common action with Word was reading existing documents, either their own or produced by other authors. The next most common action was annotating existing documents to add comments of changes to the document content. Thus shared authoring of documents in now becoming very common. This finding gives added impetus to the development of shared editing tools in the context of the web browser, as documents trend to web pages rather than free-standing word-processed documents.
Since the mid-1990s much effort has been expended to bring in-page editing back to the web browser. The primary aim is to allow collaborative editing of web pages, but a beneficial by-product of editing pages within the browser is the ease of keeping page content up to date. The working group on Collaboration, Knowledge Representation and Automatability [HREF4] held their first landmark meeting in 1995 [HREF5] and many large software organizations were represented. Several sophisticated, but incompatible, browser extensions have been produced since then. These extensions implement collaborative editing of web pages and other tools. The browser acts as the front-end client for these facilities.
This author has built a number of lightweight, in-page editing tools over the last years as part of the Pardalote project reported at the Australian Document Computing Symposium 2000 (Rees, 2000). This tool is now renamed DotEdit and forms part of the range of lightweight tools offered by the author’s On-The-Dot Software [HREF6] web site. Amongst a number of other excellent solutions, DotEdit is mentioned by Jon Udell in his Byte Magazine article [HREF7]. More details of the DotEdit user interface design within the browser can be found in a discussion by the author for evolving the web browser user interface towards a standard user interface architecture (Rees, 2002).
DotEdit allows simple text editing of nominated sections of web pages. This is achieved by manipulating the DHTML Document Object Model (DOM) [HREF8] to present readers with text boxes to allow them to edit page contents. Clicking the appropriate DotEdit-generated command button causes the updated web page to be written back to the web server. Other users in the collaboration team can then access the updated page.
While useful and efficient, DotEdit is limited to text-only editing, even though that text may be styled using CSS style sheets. To be true to the very first web browser, tools are needed that allow more powerful editing features such as font face, size, weight and colour changes, and the ability to create and edit structures such as indented paragraphs, lists, links and tables. In addition, users require the ability to create and manage connected pages of information in a reusable manner.
This paper first describes the DHTML Editing Component available in the Microsoft Internet Explorer that makes the latest shared editing tools from the On-The-Dot software suite possible. A simple slide show tool, DotXShow, is used demonstrate several important features of the component. The work described here specifically excludes consideration of other browsers and platforms except for Windows. Neither does the design address the important considerations of the W3C Web Accessibility Initiative (WAI) [HREF9]. Thus the editing features of the On-The-Dot tools are limited to using Internet Explorer on the Windows platform, although the static information after editing can be viewed on a wider variety of browsers and platforms. As they stand, the full features of the On-The-Dot tools are only available to about 75% of Web users.
Most of the paper builds on the use of the DHTML Editing Component to produce a web page user interface for assembling documents out of information fragments or fraglets. A simple tool for constructing concept maps acts as a demonstration of the user interface for such fraglets. The paper concludes by discussing a shared storage and retrieval fraglet architecture that is accessible to all web users. A very preliminary implementation of this architecture is presented, and suggestions for extensions into a more powerful architecture are given.
Microsoft has steadily been componentizing many of its consumer products like Office and Internet Explorer using the COM and COM+ technology. This makes available subcomponents of the main Microsoft products to other applications as well as the capability of add-ons to the products themselves. One such example is the DHTML editing (DE) component in the Internet Explorer (IE) browser.
The DHTML editing component has been available for some time with later versions of IE4 and early versions of IE5. However, in the latest IE versions the DE component is highly accessible from page scripts and appears as an attribute on element (tag) nodes in the DOM. A correspondent Jon Udell's article [HREF7] gives some excellent examples of deploying the DE component in script. Several commercial products are also exploiting this component.
This author has deployed the DE component in two lightweight tools:
Currently in development, DotEdit version 2 uses the DE component as well.
Figure 1. DHTML Editing Component in DotXShow.
The screen dump in Figure 1 shows the editing user interface for DotXShow. The DE component edits the text in the lower half of the figure. Across the centre of Figure 1 will be seen the editing toolbar. This is generated by scripts within the web page and gives the user access to some of the features of the DE editing component. The features encompass many capabilities expected of a word processor for web pages and include:
The scripting mechanism to make the DE component available to the user is a very simple process:
So simple is this process that it is strange that more authors and developers do not exploit this feature in their web pages.
DotXShow stores the HTML from each slide in the slide contents element in an XML document representing a whole slide show. In Figure 1 the handling of individual slide creation, deletion and ordering within the slide show appears in the upper part of the user interface. Note that the title of each slide can be specified. A number of typical slide layouts are available in the list at the top right to be used when a new slide is created.
Figure 2. Slide Show Management in DotXShow.
DotXShow has been developed from an earlier tool called DotShow written as a Perl CGI script. Both tools share the feature of a common repository of slide shows (DotShow generates linked web pages, one per slide, and stores each show in a separate folder). Using one repository per organization, department or work group, provides a number of benefits:
For DotXShow, Figure 2 shows the simple user interface for managing the slide show level. Users can create, duplicate, delete, rename and edit slides shows. A number of templates that are slide shows themselves are available for users to use. It is the author’s experience that making duplication easy and straightforward is a more powerful way to achieve consistency between slide shows that using templates. Both are provided in DotXShow.
DotNotelets is a lightweight tool using the browser user interface to investigate a combination of features for shared documents:
An overarching aim of all tools in the On-The-Dot software stable is that each be a useful tool in its own right.
The design of DotNotelets is driven by a simple user need to be able to record small pieces of information or notelets, and then to assemble them into a larger document. In the current early version of DotNotelets, each notelet can contain richly formatted text and hyperlinks. However, it is envisaged that the next versions of the tool will extend the content types of notelets to images, lists, tables and forms, indeed anything that can be contained in a web page.
The process of entering or copying fraglets is not new. Various software packages such as outliners, ideas organizers and brainstormers exist to allow text to be entered randomly then reorganised into a meaningful structure. Many remote meeting tools incorporate such software as this is often central to planning and workshop style meetings.
A specific form of idea organization is the mind map [HREF10] evolved by Tony Buzan. Mind maps have grown into an industry of their own with many software packages to support them and instructor-led courses available for training purposes.
In the case of DotNotelets, the design was more heavily influenced by the broader concept map [HREF11] that offers a connected two-dimensional layout. DotNotelets at present has just concentrated on the absolute position of notelets rather than attempting to cluster the information based on specified connections entered by users.
Each notelet is represented by a colored rectangle containing text and control bars as shown in Figure 3.
Figure 3. An Example Notelet.
The top Notelet control bar allows the whole notelet to be repositioned by dragging and dropping with the mouse. Under the Notelet bar is the main toolbar that gives the user access to the main editing features of an individual notelet:
A Resize control bar at the bottom of the notelet allows the width and height of the notelet to be adjusted. Position, width and height are constrained to be multiples of 10 pixels so that simple alignment of notelets is possible within a web page.
The main body of each notelet contains the editable DHTML text supported by the DE component. In the current experimental version of DotNotelets no additional editing icons that are used in DotXShow have been added yet. This means the user is limited to keyboard editing, but his yields a number of useful editing capabilities such as bold, italic, underlining and the ability to insert hyperlinks. Even searching the text of the notelet can be undertaken with the Ctrl/F key combination. Of course, the usual cut, copy and paste options from the keyboard are also available. Copy is vital for the usability of DotNotelets so that it can accept text via the clipboard from other applications.
The background colours of the notelets can be used to allocate the notelets to categories. Just a fixed set of about 8 colours are provided at present.
Figure 4. A Concept Map.
Users can create new notelets by right clicking on the page background. After editing the contents of the notelet it can be dragged into the required position that denotes its relationship with other notelets. Figure 4 shows a simple concept map in its entirety. The user controls the overlap order by using the arrow keys on the toolbar.
Note that the size of a notelet is independent of the size of the text content. Scroll bars appear when required. Being able to see the first few words of text is often sufficient when structuring the concept map.
While a printed version of Figure 4 can be useful for visualization purposes, users will most often require the text to be consolidated for reporting purposes and to import into other applications like word processors. Right clicking on the page background and selecting ‘Export all to text’ will consolidate all the text in all notelets into a single web page.
A very simple, and apparently effective, algorithm is used for the consolidation. The vertical stacking order of the notelets is the overriding factor. If vertical positions match then a left to right order is assumed. Figure 5 shows the concept map from Figure 4 consolidated into a single page.
Figure 5. Notelets Consolidated into a Single Page.
The consolidated page can be printed as a report, saved as an HTML file or the text copied and pasted into another application for further processing.
Like DotXShow, DotNotelets uses a shared repository of concept maps. In this case the top level is more visually appealing and reuses the same type of user interface as the concept maps themselves. In the repository view as shown in Figure each map is represented by an object just like a notelet. The only addition is an extra Open button in the toolbar that opens the specified concept map. To reflect the fact that each object represents a complete concept map, the main title bar is changed to ‘Concept Map’. The text contained in the body becomes the title of the map and can be edited to any string.
The DotNotelets user interface aims to have visual appeal and simple functionality. This is achieved with very little scripting in client-side JScript. The power of the DE component, mouse events in JScript and the absolute positioning features of the DOM come to the fore here. In particular, the DE component fits seamlessly into the user interface with minimal scripting required. The first objective of DotNotelets is thus achieved.
Figure 6. Concept Map Repository.
All users sharing a concept map and the repository share the same web page, so the web application is fully collaborative. Although not yet incorporated, DotNotelets will use the same mechanism employed by DotEdit to guard against simultaneous updates to the same notelet, map or repository. This involves a check when changes are written back to the web server and is fully described by Rees (Rees, 2000).
The decision to represent concept maps in XML was straightforward. The DE component works with DHTML and this can be incorporated within a suitable XML element. The exact format of the concept map XML is still being evolved, but in essence each map needs only store position, width, height, overlap order and DHTML text contents.
Figure 7 shows an example of the XML document representing the concept map repository. The format is that generated by Internet Explorer when displaying an XML file. The ‘+’ and ‘-’ characters are not present in the document but are inserted on the page to allow the user to expand and contract parts of the XML.
The XML elements are self-explanatory. The <guid> element is the novel feature. The text associated with this element is a global unique identifier (GUID) for the concept map, so each concept map generated will be unique and potentially shareable and reusable.
When the DotNotelets home page is first accessed, the concept map repository document is read and objects generated on the page representing the concept maps. To access and individual concept map the user clicks on the Open button. At this point DotNotelets seeks a file named <guid>.xml, where the concept map GUID is used for the base file name. Thus each concept map is stored in a uniquely named file.
Figure 7. Concept Map Repository XML.
Once again, a single concept map file is represented in XML. Figure 8 shows relevant parts of an example file. Each notelet is wrapped in a <dotlet> element and, as can be seen, also possesses a GUID. Thus each notelet is uniquely identified and again has the potential to be reused and shared. In principle, this means that every small piece of information in a concept map is made unique at the point of creation. Thereafter such a fraglet has the potential to be reused in other concept maps or, indeed, any other kind of document.
Figure 8. Part of Concept Map XML Document.
In summary, the implementation of the notelet document architecture is kept as simple as possible. There are just two levels:
One of the first DotNotelets prototypes stored each notelet in an XML file, but this quickly leads to a plethora of files, making management more difficult.
Early test users of DotNotelets expected to find another obvious extension to the concept map document architecture: allowing any notelet to be a concept map container itself. This recursive architecture is perfectly possible, but would bring major new requirements to the user interface in order to make the users aware of the level of recursion, and to allow notelets to be moved between levels. Solutions to this problem are needed on most large-scale web sites where users need to be informed as to how to navigate between levels and be aware of the level at which they are currently positioned. Hyperlinks showing all levels and allowing a return to any level are quite common, as is the use of site maps both textual and graphic.
In its current version, a concept map repository consists simply of:
DotNotelets therefore fulfils the second objective, but the simple XML file-based implementation currently used has basic limitations.
Further refinement of the current DotNotelets architecture is needed to allow individual notelets to be shared and reused. In a direct analogy of graphical image files in HTML, each notelet itself must be stored in a directly accessible fraglet. Currently, if a notelet is to be moved from one concept map to another the notelet XML must be deleted from one concept map file and inserted into another. Worse, if the same notelet is required in two or more concept maps duplication of the XML is necessary. Further degradation to reusability occurs since the user is allowed to edit notelets in different concept maps potentially violating the exclusivity of the notelet content.
At the concept map level the structure needed is:
<concept-map><guid id=”notelet1”/><guid id=”notelet2”/>…<guid id=”noteletn”/></concept-map>
In other words a concept map should consist of a sequence of GUIDs each uniquely identifying a notelet. Sharing notelets between concept maps then is a simple matter of using the same GUID in two or more maps. Moving and reordering a notelet becomes the movement of a <guid> element.
This approach can be generalised to a fraglet architecture for any type of document as in:
<document><guid id=”fraglet1”/><guid id=”fraglet2”/>…<guid id=”fragletn”/></document>
This is the generic document fraglet architecture. Here, fraglet is used to represent any document component. A fraglet is deemed to be a single XML element with similar syntax and semantics as the document element in a valid XML document. One can go further and postulate a range of fraglet types to suit particular types of document. Recursive architecture is achieved by allowing fraglets to nest within fraglets to any depth.
Such a fraglet approach is envisaged for a range of business oriented documents. A good example of this is electronic contracts in a B2B context. Contract documents consist of a number of contract clause groups containing contract clauses. Such an approach is suggested by Herring and Milosevic (Herring & Milosevic, 2000). In terms of the document fraglet architecture there would be two types of fraglet: contract clause groups and contract clauses. This suggests that nested and linked fraglet architectures will be needed.
It is clear that a file-based implementation as currently adopted in DotNotelets is totally inadequate for a globally shareable document fraglet architecture. At the most basic level a fraglet consists of:
This would seem to lend itself to a very straightforward database solution. While appropriate for a central repository of fraglets a database does not lend itself to a fully distributed solution envisaged for true reusability in a global, distributed address space.
Fortunately, two technologies are with us to allow a solution to the document fragment architecture storage problem. These are XML web services teamed with the Universal Description, Discovery, and Integration (UDDI) mechanism [HREF12]. Web services are at the heart of the Microsoft .NET initiative and Kirtland gives a good overview (Kirtland, 2000). Web services address the major issues of application integration. The goal is to produce applications running on different operating systems, built with different object models, using different programming languages and turning them into easy-to-use Web applications.
Web services run on any web server and can be called using the standard simple object access protocol (SOAP) from anywhere on the Internet. Instantly this will meet the distributed repository requirement of the document fraglet architecture. A fraglet repository web service can be defined and placed on multiple web servers. Indeed, taken to the extreme, this will allow a true peer-to-peer (P2P) implementation of the document fraglet architecture. Here individuals or organisations can publish their own fraglets by putting up their own fraglet web service.
The beginning of such a solution is being trialed with a version of DotNotelets as this paper is being written. One of the primary services needed by DotNotelets is the generation of a GUID to assign to new concept maps and notelets. In addition, the XML associated with each GUID needs to be stored in an easily accessible form as described above. A research colleague has implemented a GUIDDictionary web service [HREF13]. This offers the following methods:
The description string described in these methods currently limited to 2048 characters, adequate for the vast majority of notelet XML content which tends to be very short. For longer notelet content a simple chain of these GUID description strings can be used. Such a hard upper limit of 2048 characters per notelet is a by-product of the first working prototype built in limited time and will be eliminated in future versions of the web service.
Thus without a change to the user interface described in previous pages the new version of DotNotelets now has truly independent notelets. Each notelet can be accessed by simply sending the GUID in a SOAP message to the GUIDDictionary service. The solution can immediately be scaled to very large numbers of notelets, and opens up the ability to provide recursive notelets and other notelet structures. Recall this latter feature will require a significant redesign and extension of the exisiting very simple user interface. DotNotelets can now fulfill the third objective of a scalable and practicable document architecture.
Furthermore, the GUIDDictionary web service with GUID description chaining is capable of supporting the full document fraglet architecture as regards the storage and retrieval requirements. An arbitrarily large set of fraglet web service repositories can be deployed and utilised.
However, to use the GUIDDictionary web service the URL of the web server must be known. This is where UDDI plays its most important role. Using UDDI it is possible to search and discover document fraglet repositories built on web services. Now the full document fraglet architecture can be implemented in a straightforward manner.
Looking further forward one can envisage the need for additional attributes to be associated with each fraglet. Examples are date/time of modification and last access and versioning. These will be useful search parameters for the UDDI mechanism when the user comes to construct documents from the reusable fraglets.
This paper has presented some simple collaborative tools accessible within web pages using the web browser as the client application. DotXShow allows users to collaborate in building and editing slide shows for presentation within the web browser. DotXShow exploits the DHTML editing component to allow users to add rich content in their individual slides. A major feature of DotXShow which helps a group or organisation achieve consistency and commons style is the shared slide show repository.
The more ambitious DotNotelets tool is a vehicle for testing a web-based distributed document architecture where documents are built from fraglets, reusable pieces of documents that can nest within each other and be chained together. A credible and practical architecture for distributed fraglet storage has been presented based on XML web services. DotNotelets forms the prototype for demonstrating the document fraglet architecture. Immediate applications of this architecture allow complex business documents such as contracts to be supported.
Berners-Lee, T., Weaving the Web, Orion Business Books, 1999, ISBN: 0-75282-090-7.
Brush, A. J., Bargeron, D, Gupta, A. & Cadiz J J, “Robust Annotation Positioning in Digital Documents”, Proceedings of SIGCHI’01, Seattle, 2001, pp 285-292.
Gillies, J. & Cailliau, R., How the Web was Born, Oxford University Press, 2000, ISBN: 0-19-286207-3.
Herring, C. & Milosevic, Z. “Implementing B2B Contracts Using BizTalk”, Thirty-Fourth Hawaii International Conference on System Sciences (HICSS-34). 2000. Maui, Hawaii.
Kirtland, Mary , “The Programmable Web: Web Services Provides Building Blocks for the Microsoft .NET Framework”, MSDN Magazine, September 2000. [Online] Available http://msdn.microsoft.com/msdnmag/issues/0900/WebPlatform/WebPlatform.asp.
Rees, M. J., “Implementing Shared Document Preparation with Lightweight Editing”, Proceedings Fifth Australasian Document Computing Symposium (ADCS), December 2000, Twin Waters Resort, Sunshine Coast, pp 25-33.
Rees, M. J., “Evolving the Browser Towards a Standard User Interface Architecture”, Proceedings of the Third Australasian User Interface Conference, February 2002, pp 1-8.