Dr Michael Rees [HREF1], Faculty of Information Technology [HREF2] , Bond University [HREF3], Qld 4229, Australia. mrees@bond.edu.au
A traditional method of implementing highly-interactive web applications employs Java applets or ActiveX controls which download executable components for a client-side run-time environment. This environment also may need to be downloaded, often to the annoyance of users. Another widely-used implementation method uses client-side JavaScript, the properties of dynamic HTML and minimal server-side scripting to implement the same type of highly-interactive web applications. This latter approach, now more usually referred to as the Ajax methodology, appears to be gaining ground in several commercial, high-profile web applications such as Google's Gmail.
The author has employed the Ajax approach extensively for constructing a number of shared in-page editing tools (collectively referred to as the DotSoft applications) reported in this conference series in the past. In contrast to Ajax server-side coding for web applications such as the ASP.NET environment is growing in popularity with commercial developers. It was decided to begin the re-implementation of some of the DotSoft tools using this apparently more productive server-side development environment. The tool chosen is a simple planning tool, originally called DotNotelets, which attempted to provide the simpler components of concept maps. The new tool is renamed DotPlan but provides essentially the same functionality with a few improvements to the user interface and extension of the plan/concept map structure to a true hierarchy.
This paper describes the development experience to date and compares the previous Ajax approach with an ASP.NET implementation. The experience highlights the strengths and weaknesses of the two approaches, and shows that at present the responsive user interface requirements still have to employ Ajax for acceptable performance. The discussion attempts to provide guidance for other developers by suggesting which parts of a highly-interactive web applications are best suited to the two technologies that can work together. Finally, some areas for further investigation are highlighted.
XHTML, JavaScript, web applications, server-side code, ASP.NET
Highly-interactive web applications (HIWA) allow web pages displayed in standard web browsers to present responsive user interfaces that approach the features expected in free-standing applications. Basic HTML provides simple elements like command, radio and checkbox buttons, selection lists and scrolling text areas. In contrast the user interface of free-standing applications can be composed of the basic HTML set together with menus, toolbars, exotic sliding controls and various drag-and-drop features. Such sophisticated and productive user interfaces are made possible by the extensive user interface control libraries available to free-standing application developers.
Traditionally developers of web applications have attempted to approach the sophistication of free-standing application user interfaces with the aid of Java applets, Flash movies and ActiveX controls. This sledgehammer approach requires the downloading of potentially large executable components to the machine running the web browser, sometimes requiring user intervention and causing annoyance. Depending on which of the sledgehammer technologies is used, an additional run-time execution environment needs to be downloaded or updated causing further delay and user annoyance. In some cases, even the security of the user's machine is compromised. Even after the successful downloading the eventual user interface, although perfectly responsive, often employs new interaction paradigms that differ markedly depending on the application.
Another widely-adopted approach to creating HIWA has been to exploit the responsive dynamic HTML Document Object Model (DOM) features built-in to most modern, conformant browsers and client-side JavaScript to drive the user interaction. Good approximations to the more exotic user interface controls can be implemented and even drag-and-drop features incorporated into the user interface designs. One major benefit of this approach is the avoidance of long download times and the need for user intervention. A downside for developers is, however, the exposure of their JavaScript code and loss of their IP.
This combination of HTML DOM manipulation by JavaScript used to implement responsive user interfaces has become known as Ajax. According to Garrett [HREF3] Ajax stands for 'Asynchronous JavaScript + XML' which mentions some of the key technologies of this development approach.
Several important commercial web applications are now using the Ajax approach although this name may not be used in the publicity. Notable examples of such applications are Google Gmail [HREF5] and Google Maps [HREF6]while competitors such as Yahoo are expected to follow suite. It is interesting to note that Google Gmail and Google Maps show an initial 'Loading...' message to indicate that some delays in reaching the first full display are expected. Both also mention a limited set of supported browsers. In the case of Google Gmail a 'Basic HTML' version is now available to support early and restricted browsers.
In contrast to the Ajax approach stand the server-side model development environments, one of the most notable being ASP.NET [HREF7]. Based on compiled, strongly-typed, object-oriented languages the server-side models are built to handle complex HTML forms and data manipulation in enterprise-scale third-tier database management servers. Concentrating most processing on the server does bring some advantages such as minimising XHTML delivery targeted to specific browsers. The developers also gain from the necessity for integrated development environments with powerful debugging and code management facilities.
This paper describes the translation of a useful interactive web application, DotNotelets (Rees, 2004) written with the Ajax approach, into an equivalent ASP.NET application called DotPlan. These applications can be used during a meeting, face-to-face or remote, to enter fragments of information (any HTML but usually text and images), order and structure this information in real-time, and then output the information in a variety of report formats for reuse in other applications. In essence, this is a typical brainstorm process for ideas generation and provides an electronic report of that process.
After introducing the Ajax and ASP.NET development approaches the features of the DotNotelets and DotPlan web applications are described. This is followed by a comparison of the implementation processes that results in the contrasting benefits of the two approaches. These contrasts are discussed and some general guidelines derived for the benefit of other developers. The paper concludes with suggestions for future work and new implementation possibilities to be attempted.
In his much-quoted web article Garrett [HREF3] lists the Ajax components as those shown in Figure 1.
Figure 1. Components of the Ajax Web Application Model
The main uses of the components are:
From a developer's point of the view the usual browser HTTP request-response cycle is used as normal but is augmented by the asynchronous (or synchronous) XMLHttpRequest background send and receive of data manipulated by the web application. This latter capability replaces the read file/save file mechanism enjoyed by free-standing applications. Figure 2 shows the Ajax web application architecture.
Figure 2. Ajax Architecture
Countless web applications have used the Ajax approach except that the developers may not have consciously collected their JavaScript functions into a distinct Ajax API as shown in Figure 2. Nevertheless, static web pages and their associated JavaScript files are loaded via the normal HTTP request-response cycle from a web server. As the user interacts with the XHTML elements in the displayed in the browser the JavaScript event handler scripts generate new XHTML perhaps reading and/or writing data in XML format to the same or other web servers. Asynchronous XMLHttpRequest calls are important to keep the user interface responsive while data manipulation using unreliable HTTP connections takes place in the background. Callback functions are used to provide user interface feedback to keep the user informed of progress.
The author chose the DotNotelets concept map web application as the Ajax example because it is implemented with a small amount of JavaScript yet still exhibits all the main Ajax features:
As briefly outlined in Rees (2004) DotNotelets supports just two levels of information, the concept map level which lists the set of concept maps, and the notelet level showing the information fragments of a single concept map.
On accessing the DotNotelets home page the user is presented with the list of maps displayed on the page. Each map is displayed at a 2-dimensional position, and the z-index setting, which dictates the front-to-back display order on the page, gives the impression of an additional dimension. Figure 3 shows an example of this display.
Figure 3. DotNotelets Map Display
Note that each notelet consists of three areas: the Concept Map label, a toolbar and a textual description of the map. The textual description is editable. Using the tools in the toolbar the user can perform the following actions:
In addition to the toolbar facilities, a context menu triggered with the right mouse button, displays additional menu items as shown in Figure 4. The context menu overrides the standard browser menu that can be annoying to users. Holding down the Ctrl key and right clicking shows the standard browser context menu instead.
Figure 4. DotNotelets Context Menu
The Save All and Help menu items mirror the equivalent toolbar icons. The New Concept Map menu item creates a new notelet near the mouse pointer. The remaining menu items are concerned with the output options of the DotNotelets tool. After a brainstorming session, how can the recorded notelet contents be captured? In this version of the simple DotNotelets tool only two outputs are provided:
Clicking on the Open icon in a Concept Map opens that map and shows the notelet contents as shown in Figure 5. It will be noted that the tool icons of very similar with the omission of the Open tool. In addition, the nearly identical context menu is also shown. The collection of Notelets shown make up a set of information fragments, in this case describing the features of the DotNotelets tool itself each with its own title. It can be imagined how the tool could be used to in this example to brainstorm the contents of an online manual for the web application.
Figure 5. Part of a Notelet Content Display in a single Concept Map.
A minimal set of editing functions, triggered by various key combinations, are available for the notelet contents as can be seen in the list in the central notelet of Figure 5. URLs and email addresses are automatically converted to links, and the Ctrl+K key combination prompts for a URL to turn the selected text into a link,
A much more powerful editor can be created as described in Rees (2004) when discussing the DotTegular tool. Even in DotNotelets the editable notelet field can be used to display relatively complex HTML content by copying and pasting from other web pages. An example is shown in Figure 6. The content was copied and pasted from the Bond University home page, and the images, links and text alignments are retained. [Text fonts and font sizes, probably driven by CSS on the source site, are not retained.] Once in the notelet the text can be edited in the normal way.
Figure 6. Rich HTML Content Copied into a Notelet
Here in the map contents view the output options become more useful. The 'Export all to text' menu item displays the whole map contents as a single web page. Printing this page, or copying the HTML to another application, provides a readable report version of the map, ie the output of the brainstorming process. A major question arises as to the order in which to output this serialised version of the map. Intuition, borne out by user testing, albeit limited, of the DotNotelets tool, directs the order to be top-to-bottom (vertical position on the page) then left-to-right (horizontal position) where the top of notelets coincide.
The XML output option allows a more structured capture of the brainstorming session that generates the map. Notelet title, size, colour, x-y position, z-index and XHTML contents of the notelet are available in the XML output document. Other applications can process any or all of these attributes as well as the more important XHTML contents.
DotNotelets fits the description of a HIWA using the Ajax Web Application Method because of the implementation choices used to provide the set of features described in the previous section. In use DotNotelets is highly-interactive because of the drag-and-drop features of notelets. Users can move and resize and adjust the z-index order with the very low response times typical of a free-standing application. Notelets are dragged to a new position using the top, positioning bar. For easy vertical and horizontal alignment the notelet is positioned to the nearest 10 pixels. Resizing a notelet is achieved by dragging the bottom resizing bar. Again the resizing is rounded to the nearest 10 pixels to aid alignment within the page. The usual four toolbar icons for Send to Back, Move Back, Move Forwards and Send to Front control the front-to-back display order.
Client-side JavaScript is used to control the user interaction and provide immediate feedback by manipulating the XHTML used to represent notelets (simple <div> tags) and their contents. Modern browsers provide a very quick and smooth update of the displayed page whenever the XHTML contents are changed. CSS style sheets are naturally used to bring display and layout consistency to all aspects of the web page contents.
The last major pillar of Ajax concerns the use of XML to store, transmit, manipulate and transform the data used by the web application. DotNotelets stores the list of maps and each map in an XML document stored on a web server. The client-side Ajax JavaScript routines instantiate in-memory XML Document Object Model (XML DOM) hierarchies for manipulating the data. Each map uses the simple format shown in Figure 7. The HTML contents of each notelet are stored in CDATA sections to prevent any spurious XHTML copied into the notelet from destroying the well-formed XML.
Figure 7. Example XML Fragment for an Individual Map.
Each map and each notelet is allocated a unique GUID which is stored in the XML and is used to name the XML document in which each map is stored. This design decision looks forward to future research in which notelets can be shared across maps and any other type of XML document. This aspect is mentioned again below in the DotPlan implementation.
The XML DOM load() method can be used to load XML documents directly from any web server. Of course, security boundaries prevent the client-side JavaScript from saving the XML back to a web server. It is here that the XMLHttpRequest component is employed to send XML back to server pages running script of some kind. In the case of DotNotelets server-side JavaScript is used to accept the XML and create, save and/or update the XML documents on an IIS server. These server pages could be written in many other scripting languages and use other web servers. In fact, other than loading the maps list XML document directly, DotNotelets also uses XMLHttpRequest to load the XML for individual maps. Although not fully exploited here this method allows the loading to happen asynchronously (the usual Ajax approach) in the background.
All web applications must generate XHTML dynamically to present their user interfaces so. XSLT style sheets are designed for this transformation amongst others and XMLHttpRequest is used again to acquire the XSLT style sheets with the transformations being performed as part of the Ajax rendering process. In DotNotelets the main use of XSLT is in producing the various output formats. In-line JavaScript is used to generate the XHTML for each map and notelet displayed on the page.
Concept map purists will immediately observe that DotNotelets does not produce complete concept maps. The accepted form of a concept map includes labelled arcs (arrows) drawn between the concept boxes. An example is reproduced by permission [HREF8] in Figure 8.
Figure 8. An Example Concept Map.
Concept mapping tools exist but have fairly complex user interfaces for drawing and labelling the relationships between concept boxes and the reordering and repositioning of concepts leads to substantial coding (Luchini et al, 2003). DotNotelets is the beginning of a more ambitious tool that deduces relationships automatically. Research is underway in this next stage in association with others and will hopefully be reported at this conference in future.
At its current state of development DotNotelets is a simple but effective brainstorming and planning tool. It is ideal for an individual assembling ideas and thoughts and for a team brainstorming session where the current page contents are displayed to the whole group and an individual secretary/recorder person updates the notelet contents as the meeting progresses. DotNotelets is also similar to another type of tool, mind maps, used for several decades and introduced and promoted by Tony Buzan (Buzan & Buzan, 1996). An example mind map is shown in Figure 9 generated by one of the many mind map applications, MindManager [HREF9]. Such a layout can be generated in DotNotelets using the notelet boxes for all text.
Figure 9. An Example Mind Map
Brainstorming tools like DotNotelets and MindManager find an important niche in the range of tools used for remote collaboration between teams and work groups of all kinds. A useful summary of the tool set including mind maps, and the strengths and weaknesses of each tool appears in a blog entry from Dave Pollard [HREF10]. His set of tools or communication media is:
| web log | wiki | whiteboard | document-sharing |
| IM, Skype, phone, e-mail, videoconferencing | mind maps | discussion forums | community of practice/ interest spaces |
| personal e-mail groups | social networking tools | in-person collaboration |
When implementing the ASP.NET version it was decided to call the tool DotPlan to more closely reflect the likely usage. The intention was to retain the same feature set present in DotNotelets. However, for DotPlan some changes were made to the basic user interface to accommodate feedback from early users. The major changes are:
notelet move and resize is possible on all sides/corners
notelet toolbars replaced by a single toolbar by introducing a current notelet selection
true hierarchical maps allowed with notelets and maps allowed at each level like a file/folder hierarchy
Apart from the last change, the user interface modifications are cosmetic.
The last major change is in nomenclature to reflect the new web application name. DotPlan now refers to plans rather than concept maps.
The intention was to rewrite DotPlan with the ASP.NET server-side architecture and Visual Basic .NET coding executed on the server. JavaScript was to be minimised and eliminated where possible. In principle this would leverage the advanced code development of Visual Studio .NET and improve developers productivity.
Visual Studio .NET 2003 (VS) works with the .NET Framework version 1.1 and develops web applications in ASP.NET for the IIS web server version 5 and above. To aid web application developers VS provides a number of web page user interface controls called web controls. These are based around the standard XHTML form elements, but also number several advanced controls like new button types, a powerful datagrid control for displaying database records, a visual calendar control and an extensive range of validation controls to check user input. The data contents of all web controls in the client browser are maintained by powerful state mechanisms accessible by simple coding on the server.
Nevertheless, ASP.NET is built on the premise that when a user interacts with a web control in the browser page round-trip to the server is made in order to handle the user interface event. Where the handler needs to access substantial business logic code and/or access other servers like databases this approach in sensible. ASP.NET goes to great lengths to make this server round-trip as efficient and as stateful as possible. However, some user interface activities simply cannot be handled this way. Drag and drop is a prime example but even the ASP.NET input validation controls have to resort to client-side JavaScript to maintain responsiveness.
It became clear from the start of the DotPlan implementation that the notelet moving and resizing support in JavaScript running in the client must be retained. The new notelet design in shown in Figure 10.
Figure 10. DotPlan Notelet Design
Notable notelet changes that improve the user interface are:
Such a design eliminates the annoying situation for both moving and resizing when the control bar is hidden by another notelet that has to be moved before working on the notelet beneath. Now if only a small part of a notelet is visible it can be moved or resized.
The next decision involved the method used to store and retrieve the plan list and the contents of the individual notelets. With the growing influence of server oriented architecture (Zhang et al, 2004) it seemed almost essential to convert the ad hoc ASP server-side scripting with equivalent web services. This is also very sensible since web service creation is so powerful and straightforward in VS (VanLengen & Haney, 2004) which almost invisibly handles the complexities of SOAP, WSDL and UDDI on the behalf of the developer. At the same time the opportunity was taken to move the XML storage requirements of DotPlan towards the concept of what the author refers to as 'universal memory' (mentioned briefly above), storing all data in XML fragments called I-grains (Rees, 2002), short for information grains, each directly and globally addressable via a GUID.
The I-grain web service itself is very simple and currently provides only the methods shown in Figure 11. Using the agile development maxim of implementing only what is needed for the next release, the I-grain web service simply stores each I-grain in a separate XML document. Eventually an XML or relational database solution will be needed. nevertheless, in its current implementation the I-grain web service is usable by many other web applications.
Figure 11. The Simple I-grain Web Service.
DotPlan stores each notelet content in a single I-grain. Each plan consists of a list of I-grain pointers. A item in this list may point to a notelet I-grain or a plan at the next level down in the hierarchy. Now each notelet on the page may represent either the notelet contents or a placeholder for a plan at the next level. This information must be reflected in the user interface and the simple expedient chosen was to mark a plan in a different boundary colour and add a link to take the display to the next level down. This is shown in Figure 12 with a preliminary version of the context menu displayed in the centre of the figure.
Figure 12. Part of a Page in DotPlan.
Notable features include the single editor toolbar at the top of the page rather than take up real-estate in each notelet. The navigation listbox at the top right of the page plays a very important role in showing the user which part of the plan hierarchy is currently being displayed. Figure 12 shows the top level plan. Also the two colours for the plan notelets (left side of page) and the content notelets (right side of page) can be seen. When the user clicks on one of the Show Plan links, the contents of that plan are shown. Figure 13 gives a brief example.
Figure 13. A Second Level Plan Page.
Note that the navigation listbox now shows a new plan is selected. Clicking on any other items in this listbox displays that level of plan. In addition, the notelet on the right is the selected notelet shown by the darker table cell outlines and by the fact it is displayed at the front and display above any other overlapping notelet.
Using server-side VB.NET code it is possible to implement all the calls to the I-grain web service and to handle all XML data manipulation including the fundamental XHTML generation to pass back to the browser for displaying the notelets. This is the coding in which VS and ASP.NET excels. The powerful class libraries of the .NET Framework (similar in scope with the Java class libraries) make this possible and the debugging support for this code is superb. Here then are distinct productivity gains for ASP.NET compared to Ajax.
One of the remaining facilities needed is for the browser client to ship back to the server the editing changes made by the user such a new plan/notelet and the changes in XHTML notelet content. Using standard ASP.NET button controls it is conceivable that during the relatively large user interface change that creating a new notelet entails the user might tolerate a server round-trip. This was the first implementation method and although the page clears and redisplays with the new notelet in place the expected response time is tolerable. However, shipping back the changed XHTML to the server ran into difficulties with the ASP.NET architecture.
ASP.NET is set up to transmit client state information back to the server in standard XHTML form elements including a number of hidden <input> fields. These fields do not normally contain XHTML. The __Viewstate field in particular plays a major role in the client state handling mechanism (ViewState) but cannot be used to convey XHTML. Also the way client events are converted to server-side events presents difficulties when additional client events are required.
The solution adopted to date is to avoid using any standard web controls and to implement additional client JavaScript routines that store the XHTML contents of the notelets in a set of hidden <input> fields in XML wrappers. The hidden field contents are then transmitted to the server where VB.NET code is used to store the XHTML in I-grains. Each time the response is returned to the client the XHTML is regenerated again. Although it sounds inefficient this is how ASP.NET works for all web controls. The benefit to DotPlan is that each server round trip automatically saves the latest XHTML contents reducing the number of times the user needs to remember to save. Nonetheless here we have an example of additional JavaScript being needed to populate the hidden fields.
The support of the context menu that appears on right-clicking the mouse must at first sight be another client-side implementation using JavaScript in the normal Ajax manner. This approach was adopted in DotPlan. However, VS developers are striving hard to reduce the lines of JavaScript to a minimum. A partial ASP.NET implementation of a context menu [HREF11] shows how menu item handlers can be programmed in server-side code. However, the display and behaviour of the context menu itself must be handled by JavaScript on the client. By making the context menu out of button elements, trapping the click events in client JavaScript and using hidden fields, the form submit event in the browser can be received on the server and converted into suitable server events for the context menu handlers on the server-side. Client-side JavaScript still plays a significant part. It must be added, however, that the custom context menu control code (written in C# in this case) is a true object class and can be reused and subclassed with inheritance to gain significant developer productivity for extended features and other ASP.NET web applications.
ASP.NET has several mechanisms for leveraging the built-in web controls. Web user controls allow developers to combine existing web controls into composite unit that can be treated like new web controls. Existing web control classes can be subclassed to add new functionality at the code level. Finally, developers may design totally new web control classes that provide the same programming interfaces as the built-in web controls. This is a very powerful arsenal for building and using specialist web controls.
It should be noted that the ASP.NET architects recognised that JavaScript on the client would continue to play a vital part in some aspects of ASP.NET web applications. There are a number of classes
It is interesting to note some of the expected and unexpected outcomes of the implementation comparison between the Ajax method and ASP.NET.
| Expected Development Features | ||
| Ajax | ASP.NET | |
| 1. | Limited development tools | Professional quality integrated development environment |
| 2. | Client-side and server-side development | Strongly biased to server-side development |
| 3. | Web service neutral | Comprehensive support for web service creation and use |
| 4. | Able to support server-side XML and database use | Very strong support for XML and databases |
| 5. | Scripting IP exposed | Compiled code less easy to reverse engineer |
| 6. | Highly-responsive client-side scripting | Some responsive client-side features supported by server-side code |
These features were on the whole borne out by experience. it must be remembered that the different components of the Ajax approach have been well known for almost a decade whereas ASP.NET and its competitors have existed for less than half this time. The main failing of ASP.NET was how much it still relies on JavaScript for client-side user interface responsiveness.
On the positive side, ASP.NET server-side data processing, in this case in XML, proved more than straightforward. Fewer lines of code were needed than originally envisaged and working code productivity was high. Against this were the design blind alleys which only became apparent when additional features were progressively added. The inability to transport the dynamically changed (by the user) XHTML content from client to server was an unexpected situation. The subsequent switch to client-side JavaScript invalidated much of the standard ASP.NET button handling. Client-side generation of XHTML wrapped in XML prior to submitting the XHTML form means that the standard ASP.NET button submit mechanism has to be subverted.
Another unexpected ASP.NET requirement was the need to regenerate from stored XML data the bulk of the XHTML displayed on the client browser on each server round trip. Even with a considerable number of web service calls this overhead proved not to affect response times noticeably which turned out to be a welcome surprise. Furthermore, by taking this approach further and saving the potentially updated XHTML each time it was sent to the server, again at apparent little cost, this relieves the user of the need to use the Save action so frequently. In fact apart from the act of editing the notelet contents, all other user interface actions result in the XHTML notelet being saved. Part of the observed low overhead for saving and regeneration is of course due to the fully compiled nature of the server-side script.
Re-implementing a web application using a very different development approach proved challenging with the expected steep learning curve. Despite being aware of likely benefits and limitations a number of expected and unexpected outcomes resulted. These outcomes can be used by developers planning new highly-interactive web applications using the ASP.NET platform.
It was valuable, too, to have the opportunity to redesign some features of the earlier tool and refocus the basic purpose of DotPlan towards brainstorming and planning applications. Its simplicity should encourage wider use, particularly for recording the collected thinking generated in group meetings. Being a combination of sticky notes, concept maps and mind maps, DotPlan can find a distinct niche use in collecting information fragments into a better structured form for input to more sophisticated knowledge management tools.
Future DotPlan extensions are planned in two main areas. Firstly, given the XHTML content, the chosen position including the z-index information and assigned colour information it should be possible to automatically cluster and categorise the notelet content of the maps/plans. This semantic information could potentially be transformed into formats being adopted for the semantic web such as RTF. A variety of approaches will be trialled to achieve this at some acceptable level. Secondly, the universal memory platform where the XML of the maps/plans is stored can be extended in a number of ways. In particular, it can lead to notelets (I-grains) being shared between maps/plans and made genuinely globally accessible. For this to happen a security and sharing mechanisms need to be added and their effectiveness checked for a wider variety of web applications.
I would like to thank my Honours student, Matthew Carter, for his appraisal of the DotNotelets web application. In a number of conversations he has contributed some original thinking on concept maps generation and planning tools generally. He has also provided some fruitful literature searches which resulted in useful references in this diverse area with many overlapping keywords.
Buzan, T. and B. Buzan (1996). The Mind Map Book: How to Use Radiant Thinking to Maximize Your Brain's Untapped Potential, Plume Books.
Luchini, K., C. Quintana, et al. (2003). Pocket PiCoMap: A Case Study in Designing and Assessing a Handheld Concept Mapping Tool for Learners. CHI 2003, Ft. Lauderdale, Florida, USA.
Rees, M. J. (2002). Evolving the Browser towards a Standard User Interface Architecture, Proceedings of User Interfaces 2002, Third Australasian User Interface Conference, Australian Computer Science Communications. 24(4): 1-8.
Rees, M. J. (2004). User Interfaces for Search Information Management Web Sites. AusWeb 2004, Gold Coast, Australia.
VanLengen, C. A. and J. D. Haney (2004). "Creating web services using ASP.NET." J. Comput. Small Coll. 20(1): 262--275.
Zhang, J., J.-Y. Chung, et al. (2004). Migration to web services oriented architecture: a case study. SAC '04: Proceedings of the 2004 ACM symposium on Applied computing, ACM Press: 1624--1628.