Mike McQuaid

Ajax is shorthand for "Asynchronous JavaScript and XML" and is a recent technique for developing more interactive Web applications, allowing faster input and better usability, striving for similar interfaces to those provided by GUI desktop applications.

Figure 1 shows the main differences between a classic Web application and an Ajax Web application.

A classic Web application sends a request to a server which generates the page, perhaps from a database, returning a page which is then displayed in the client’s browser. On each new page request or the retrieval or submission of new data, the whole page must be re-requested from the server.

An Ajax Web application follows the same pattern on the initial retrieval of a page, however, when new data needs to be sent or received from the server, instead of re-requesting the whole page, the browser can call a method written in JavaScript. JavaScript is a browser scripting language and in this case can be used to retrieve the data asynchronously. This data is normally returned as XML, which is then parsed by the JavaScript and used to modify the DOM and CSS of the page.

Figure 2 compares the typical interaction model between a classic Web application and an Ajax Web application.

The classic Web application requires user activity to take place then be submitted to the server and the data must be processed and returned successfully to the client before the user can commence any more interaction.

The Ajax Web application allows continuous user activity. On certain events JavaScript functions will be run by the browser, allowing client-side processing of data, such as input validation. If necessary, this data can then be sent to the server and/or the server return more data. This usage pattern is closely similar to that of a GUI desktop application where the user does not typically have to wait for the completion of tasks and can work without worrying about manually initiating interaction with the "server".

With increased bandwidth now available to large proportions of the first-world population, Web applications are becoming feasible replacements for GUI desktop applications. This movement is known by some as "Web 2.0". One of ideas behind "Web 2.0" is the Web as an application platform, replacing GUI desktop applications, allowing cross-platform applications and allowing data to be easily shared and manipulated between machines in different geographical localities. The only prerequisites for these applications are an Internet connection and a relatively modern browser.

The first wave of these applications to move online was email. There has been Web-based email for over 10 years and it is many users' sole way of accessing their email. Google’s email application, Gmail, was one of the first uses of Ajax technology on the Internet. For browsers that support Ajax, the user interface is similar to a GUI desktop application, with the ability to drag items and quickly open and close emails without the whole page reloading.

With Ajax the goal of moving GUI desktop applications online may finally be realised. As shown in Figure 2, Ajax finally allowed the user of an Ajax Web application to have an uninterrupted workflow. This can potentially greatly boost their productivity, bringing it more in-line with that from GUI desktop applications, whilst keeping the benefits of a Web application such as distributed processing, no need for local backups, high up-time and portability.

Now users and developers wishing to take advantage of Ajax have many options available to them. For developers, many Ajax libraries are now available, making Ajax user interface development as simple as importing any other library. Users can now find Ajax applications for word processing, spreadsheets, picture management, email, satellite mapping and more.

Ajax technologies, while being useful to both users and developers, are still in their infancy. Ajax applications frequently suffer from niggling bugs such as "breaking" the expected functionality of the "Back" button, causing other unexpected browser behaviour and may have security risks. It is also currently unclear whether the claimed benefits of Ajax actually result in better user interfaces. The role of this project is to try and discover any benefits and problems and see whether Ajax Web applications provide interface improvements over classic Web applications and existing GUI desktop applications, whilst having fewer disadvantages than either individual approach. A literature review was conducted in order to discover the need for this discussion. An existing classic Web application was modified into an Ajax application after critically evaluating the user interface failings of the existing classic Web application and GUI desktop application. Finally, the new Ajax Web application was evaluated and through this the strengths and weaknesses of Ajax were discussed.

The term "Ajax" was first used in "Ajax: A New Approach to Web Applications" <[2]>, an article about interaction design. The two examples referenced as examples of Ajax were Google’s Suggest and Maps services.

Figure 3 shows an example of Google Suggest in progress. As search queries are entered, suggestions for the search query are displayed, updating almost instantaneously with no other user interaction.

Figure 4 displays an example of Google Maps' usage. This figure does not convey the use of the interface as well as a demonstration, but the map can be manipulated by clicking and dragging around the map, and the map is dynamically loaded and updated, with no need to press reload. Also, take note of the shadow overlay from the Address "bubble", again, dynamically updated in real-time.

These applications are an example of what Adaptive Path called Ajax. Ajax makes use of the manipulation of XHTML and CSS, using the DOM, by JavaScript, and information retrieval and manipulation using XML, XSLT, XMLHttpRequest and JavaScript. The information retrieval is done by regular polling of XML data using JavaScript, providing the interactivity not existing in classic Web applications.

At the time of this article, the main users of Ajax were Google, making use of it on their Gmail, Groups, and the aforementioned Suggest and Maps services, but it also saw use in Flickr and Amazon’s A9 search engine. The article provided a clear explanation of both the technical usages of Ajax, its implementation and merits, and paved the ground for future studies in using Ajax for rich-client applications. Although this article was the first mention of Ajax, analysis of the usability of related technologies have been seen before, albeit with different terminology, such as DHTML.

Comparable issues to those spawned by Ajax have been analysed before, such as in "Navigating the Applet-Browser Divide" <[9]>. The feel of browser applets was very different to that of classic Web applications and raised similar usability problems to those encountered with Ajax applications. Users were found to instinctively press the browser’s "Back" button when intending to return to a previous stage in the applet process, which, if the applet had not taken this into consideration, wiped all progress they had undertaken so far in the applet, causing the user to have to start again. Again, applets brought claims of allowing the user to "dynamically interact with information", similar to those claims made today with the rise of "Web 2.0" and Ajax. This article contained the results from a usability study which found that users tended to depend on the browser navigation buttons to navigate through the applet. When navigation buttons were provided inside the applet the users were found to have fewer problems with integration and navigation. This article also highlighted the now so-relevant issue of ensuring compatibility between browsers.

The issue with the "Back" button was further explored in "Ajax: How to Handle Bookmarks and Back Button" <[8]> . The problem was raised by using Gmail as a case study. Once a user enters Gmail, at the time of publishing, the URL remained the same throughout the session, so if a user entered an email message, and then wished to leave the message and go back to the inbox by clicking the browser’s "Back" button, to their surprise they would find themselves out of Gmail.

Before the term "Ajax" became popular, some of the technologies used were referred to as DHTML. "DHTML accessibility: solving the JavaScript accessibility problem" <[3]> discussed some of the other issues arising from the usage of these technologies, focusing on the difficulty in providing content accessible to those with disabilities when the application relies on JavaScript. The main problems highlighted were dealing with focus on dynamic content and providing semantic data for GUIs, to allow the use of purely text-based input and display. It also called for a paradigm shift to ensure that interfaces are all usable through a keyboard interface and other assisting technologies, hopefully providing interfaces that can be better than the existing alternatives for disabled users.

"Beyond Ajax" <[4]> discussed both the potential of Ajax Web applications and their limits. The first limit shown is that Ajax applications cannot allow realtime event notification, instead requiring a polling loop; the more regular the poll, the more bandwidth and processing used, both on the client and server. The second limit raised is, that although most processing-intensive tasks can and have been made into Web applications, the GUI desktop equivalents provide certain advantages. An example of this is direct hardware access, which is not possible without browser plugins, such as Adobe’s Reader or Flash, the latter providing video and audio recording, with user-controllable security levels (see Figure 5). This paper showed some of the possible advantages of Ajax such as dramatic bandwidth savings in leveraging the transfer of XML using JavaScript rather than reloading whole pages. However, the benefits and costs of migrating GUI desktop applications online must be weighed up, with respect to security, bandwidth, response and interactivity issues.

The term "Web 2.0" was first used publicly by O’Reilly Media as a name for a conference in 2005. It has become rather popular in technology circles, describing the rise in the use of Ajax and other XML technologies and also the growth of Web-based communities around these technologies. "Web 2.0 Next Big Thing or Next Big Internet Bubble?" <[1]> emphasised the large number of technology start-ups based on these concepts and made comparisons made to the "Dot Com Bubble". This article highlighted the use of a "Rich User Experience", which refers to the use of Web applications attempting to behave more like their GUI desktop counterparts. Also, the importance of dynamic content, user participation, metadata and markup were raised, allowing a way for users to both create and find information more effectively. This article reiterated the previously mentioned issues accompanying Ajax technologies, such as lack of JavaScript availability and "breaking" the "Back" button, also the difficulty of bookmarking dynamically generated pages with varying states, meaning that storing the state of pages for a bookmark may be very difficult.

The issue of creating more rich-Web applications was discussed in "Beyond the Desktop Metaphor in Seven Dimensions" <[7]>. It mentioned the use of Ajax technologies to create far more GUI-like Web interfaces, allowing them to be more familiar to users and updated without user intervention. It also pointed to the recent growth of Ajax applications being used, forming the previously mentioned "Web 2.0", bringing a shift from applications (such as those on the desktop) to online services, frequently using Ajax, storing personal information and documents outside of an office machine.

"An Architectural Style for Ajax" <[6]> discussed the use of various frameworks for the creation of Ajax-enabled pages, allowing the Web developer to worry more about content than writing the JavaScript manually. The main focus of the paper was the styles for architecture of Ajax-based solutions. It introduced the idea that Ajax applications can be seen as a hybrid, combining features from GUI desktop and Web applications. This brought the conclusion that an architectural style must be created, rather than simply reusing existing desktop or Web styles. The style described in this paper is known as "SPIAR", and highlights the factors of intractability, latency, network performance, simplicity, scalability, portability and visibility in Ajax application design. The rest of the paper focused more on specific application development techniques.

"Usability in Web Design" <[5]> revealed Ajax as a technique for increasing the speed of page loading, especially when only a small change is made to the page content. It also emphasised the need for accessibility considerations when using client-side technologies, such as Ajax, to continue to ensure the separation of style and content, and ensuring the page falls back correctly to browsers without JavaScript.

The concept of Rich Internet Applications was discussed in "Emotionally centred design" <[10]>. Rich Internet Applications are Web applications that have similar functionality and features as a GUI desktop application, but run in a Web browser. Ajax technologies are normally used in the creation of RIA. The paper posed a question, examining a different dimension of Ajax technologies, "why are these [Ajax sites] so compelling?". The reasons returned were those of fluid movement and immediate responses to user input, which create "engaging interfaces". However, the issue of Ajax becoming a development trend was raised. A call is made for detailed studies into user interaction with RIA, rather than developers to creating RIA for the sake of personal exploration and jumping on the latest technological bandwagon, instead trying to use RIA interfaces to improve user effectiveness and engagement.

The previously analysed literature provides a detailed examination of both the advantages and drawbacks arising from using Ajax in Web application development. However, multiple articles call for a detailed usability study into the efficiency of user interaction with a Ajax application, and a direct study of this does not appear to have been done. This is a major problem as most of the articles are speculative on the benefits of using Ajax. This means that there is a real difficulty for developers currently debating whether to re-engineer a classic Web or GUI desktop application using Ajax or create a new Ajax application due to the lack of "hard" data to support the conclusions found in the current available literature.

Ajax applications allow the user to have an interface that is more predictable and allows greater response feedback than either of the alternative applications.

Ajax applications match the user’s interface expectations better than the alternative applications, allowing them to take better control of dialogue flow, and allowing support for more threads of simultaneous operation. Different forms of input are better facilitated and the interface can be more customisable.

Ajax applications allow for a more honest interface, better indicating the user’s action history and current state in the application. Errors are more rapidly repaired and prevented. The application is more responsive, providing better feedback to user input.

Ajax applications allow fewer or no more unpredictable delays than the alternative applications. The Ajax application allows for greater reassurance to unavoidable delay than alternative applications.

The following problems are those introduced only in Klingon, due to its online interface. These do not have comparable equivalent problems in Dizzy.

The aforementioned problems, while not the only problems in the application, are broadly summarised into six main areas with Dizzy and/or Klingon:

These areas are those that can be considered to affect the usability of these applications most severely. Simple aesthetic and organisational changes have been ignored, as the focus of this report is on using Ajax to improve applications, not classic Web design or usability techniques.

These will be approached in Shiny by using Klingon as a base, and using Ajax techniques, modifying both the front and backend code, but leaving the simulator logic itself intact. The difficulties in implementing these solutions and an evaluation of their effectiveness will then follow.

The first step in implementing this feature was adding the necessary hooks into the existing parts of the Web application used to run the chemical simulations. This was needed as the previous method of performing simulations was by a blocking method called from the JSP. This was made non-blocking, and the progress was made available to the JSP which allowed the implementation of a graceful fallback method for long-running simulations.

With all Ajax applications, as there is not currently universal browser support, it is essential to ensure that applications fallback gracefully if the XMLHttpRequest object cannot be created or if JavaScript is not running on the browser at all. With this in mind, the progress data now available to the JSP pages was used to create a static page that contained the progress-bar and time remaining. However, for the user to be able to see the current progress of the run, the page has to be regularly refreshed periodically. While this is possible using the Meta refresh tag, it is discouraged by the W3C’s Web Content Accessibility Guidelines <[12]> as if the user is in the middle of another task in the Web browser, such as entering a new URL, this could be interrupted or lost by a page refresh. Also, as the progress page is around 3KB, with 26KB of other data (that can be cached), this a large amount to be periodically refreshed without user intervention. It was decided to simply allow the user to manually refresh the page, and they would be automatically redirected and informed on run completion. This is an improvement on the complete lack of progress feedback in Klingon, but far from a desirable result, as it still requires user interaction, unlike Dizzy.

With Ajax this user interaction is not required. A few mechanisms on the client and server are combined to give a transparent update of data. The first step is creating an XML server. A JSP file makes use of a server-side session variable to locate which user and run are requested and then returns an XML file containing the progress and the time remaining. The next step is creating the necessary client-side JavaScript, which is run by the browser automatically on the page load. This JavaScript creates the XMLHttpRequest object and sets the URL to asynchronously get the XML file generated by the server. Rather than busy-waiting on a response from the server, a callback method is set which is run on a change of the ready state of the XMLHttpRequest. This state progresses from the initial value to open, sent, receiving and finally loaded. When it is loaded, the callback method checks the status of the HTTP response. The XML server makes use of the HTTP response’s status codes to provide information about the status of the run; a lower bandwidth method than using XML.

The following status codes are used:

The OK status code provides the progress data as XML, whereas the other two provide no XML content. This is slightly more complex than using a purely XML-based method but is more bandwidth-efficient as no XML data is transferred and the client does not need to respond to the server’s initial HTTP response.

On an OK status code the callback method parses the XML provided by the server to obtain the progress information. This information is used to then manipulate the DOM and CSS of the progress page in the browser, updating the colour and length of the progress-bar, the progress percentage and the estimated time remaining. This can be seen in Figure 18.

On a See Other status code the page is redirected to the runs page, as occurred in Klingon on completion of a run.

On a No Content status code the page is not updated, but in order to inform the user an update but no new progress data was available has occurred the status bar of the browser displays "No Update".

Regardless of the status code, on the evaluation of the code and associated response, the callback method is set to run again in a one second.

To further optimise the XML size, the XML tag names were shortened as this XML will not be read or downloaded other than by JavaScript.

For example, a typical XML response with non-optimised tags might be the following:

After optimisation:

The optimised XML file is, on average, around 82 bytes. Compared with the 3KB minimum from the meta refresh method, it is clear that for large amounts of clients, or low-bandwidth connections, the Ajax method is far more efficient.

Also added to Shiny was the ability for the run to complete in the background, allowing the user to accomplish other tasks while the run was completed on the server. This was facilitated by the method of handling runs, and also the new progress-bar. The progress-bar code was designed to be portable, so it was easily embedded into the navigation bar as a small reminder of the run progress; this can be seen in Figure 19.

Due to previous input validation in Klingon occurring on the server-side, there was no need to delve too deeply into the existing code in order to access the server-side parameter checking. The first step in this case was creating an XML server to serve the error information to the client. The previous method in Klingon sent the contents of the form to the server, which was validated and then accepted or returned with any errors. In Shiny this was handled by sending the output of a single input box from the form, and the unique identifier for the input box to the server. With Shiny this is not done on submission of the form but instead when the current input box loses focus, that is the user moves the text entry indicator to another input box.

The transmission of the value is done in much the same way as the progress indicator, except this time the XML server accepts the previously mentioned parameters and, in event of an error, produces a relevant error message. Also, as in the progress example, this is done by means of an XMLHttpRequest in JavaScript, not on direct user prompting, with HTTP status codes and XML optimisation again used to save bandwidth. This method, however, is not a regular poll, but only occurs when the user has changed the text entry indicator, indicating that they have finished with that field.

Figure 20 shows the results of an incorrect start time. This looks very similar to the results from Klingon, but there are two key differences. Firstly, the illegal value is still displayed. Secondly, the invalid value will be displayed instantly, with only 64 bytes used in the transmission of this error; Klingon’s method requires 6-11KB. The error messages provided are not any more helpful, but this was felt to be not an Ajax-related issue, and could have been fixed trivially. The main advantage the Shiny solution provides is the speed the use trial-and-error to find acceptable values, with near-instantaneous feedback without the removal of the invalid value.

A possible alternative to the Ajax method used in Shiny would simply be to use pure JavaScript to do input validation. This is discussed in Input validation based on client-side data but was not used in this case. An advantage of this method of server-side validation is that the input parameters are not made known to the user. This could be seen as a disadvantage, but it can help with two factors: security and flexibility.

The first benefit is that using server-side validation allows the criteria for input rejection to be kept secret from a client, requiring brute-force attacks in order to attempt to work out the acceptable range. If this were done using JavaScript client-side validation, the ranges could be easily determined and attacked more effectively. Also, if only client-side validation is used, a malicious client could simply disable JavaScript support in the browser and their input would not be subject to any validation.

The other benefit comes in the handling of change. In this example, if a server administrator wanted to immediately change the validation ranges, or remove them completely, any clients who had a Webpage with the existing JavaScript code downloaded or cached would check the old ranges rather than the new.

Users frequently make mistakes. They are required in Dizzy and Klingon to make decisions on output, with no idea of what the output will look like. This problem was amplified in Dizzy, as to change the output it was necessary to redo a lengthy simulation. With Klingon, it was still necessary to for the user to navigate back and forth, losing the previous output in order to modify its appearance.

Figure 21 shows the new selectbox available in Shiny to modify the chart on the fly. In this example, the chart is not very useful if evaluation of the differences between G80_RNA and G80_protein was needed, as these two values are far too small to be useful. The selectbox allows the user to select the desired axis and have the chart updated. The "Update Axis" button calls a JavaScript function that forms a new image source URL for the desired new image, downloading it in the background and updating the source for the image when the download has completed. This means that the user can now observe the graph as they decide on the new datasets and also not lose this chart while the new one is updating.

Figure 22 displays the result of the update. The comparison of the two datasets is far easier now, as the Y-Axis scale has been adjusted dynamically.

Also added was the ability to export charts as SVGs, allowing the chart to be dynamically resized after generation and therefore viewed or printed at high quality at any resolution, due to the nature of vector graphics, something lacking in the previous PNG format. The text in an SVG file, such as chart axes in this case, can be searched through and copied. Using an SVG editor such as Inkscape, these charts can be easily modified, annotated or edited; difficult with a PNG file. The SVG output library used generated large SVGs (in the above example 44KB compared with a 12KB PNG), Thankfully this was not an issue as it can be compressed automatically by the Web server and client’s Web browser, as most modern browsers support gzip compression, after which the PNG is 11KB but the SVG only 3.8KB (with default compression). The added SVG functionality also has many possible extensions that could not be currently implemented. These are explained further in SVG and SVG.

Web browsers, like any applications, are not without bugs. They are complex applications required to do increasing numbers of differing tasks, and increasing numbers concurrently. This is one of the reasons some Web browsers become unstable. A common problem with long-running user tasks using the Web browser is, on event of a crash, everything is lost.

The previous method used in Klingon of creating and editing simulator files was shown to be problematic. It was necessary for a user to navigate away from the current page, losing focus in the file, every time they wanted to make a save. This naturally encourages users to not navigate away, and therefore, not to save. More technical users may type the file up in an application that allows saving first, before entering it into the browser, but this is not an ideal solution.

The previous sections have already shown that browsers with Ajax support can easily send and receive information from a server asynchronously, without breaking the user’s workflow. For editing simulator files Shiny uses JavaScript to submit the contents of the editor, using a form, in the background, using the XMLHttpRequest object. This form data is sent to the server in exactly the same format as in Klingon, but this way was done behind the scenes and did not require page navigation to return to work.

Figure 23 shows the result of a successful save. The file has been updated and stored on the server, with no need to break the user’s workflow. If the users were trusted even less, these updates could be made after a certain number of keypresses or fixed time periods.

The other way of adding files to the server is by traditional HTTP uploading. The previous Klingon method works satisfactorily for small uploads, but for larger uploads or slow Internet connections, the page will appear to hang until the file has finished uploading, and, as with the Klingon’s simulation runs, there is no indication as to how long this will take.

The Klingon backend code made use of an external module to handle file uploads. The latest beta of this module added the ability to associate a given upload with a progress listener. This was used to create an XML server for the upload progress. When a file is sent to the server the browser informs the server of the number of files being sent and the size of each file. The progress listener can then use this information, combined with the size of file already uploaded, to calculate the percentage through the upload. An XMLHttpRequest object is used with callback objects to asynchronously poll the XML server for the file upload status, and display a progress-bar on the page while the file is uploaded. A example of an upload in progress can be seen in Figure 24.

This method is less successful than the simulation run progress-bar, as uploading the file will make maximum use of either client or server bandwidth, so polling the progress from the server is far slower than with the simulation progress-bar, as the connection is being saturated. However, this method still allows a user to more easily estimate how long an upload will take and can be useful for large uploads.

Sometimes input validation on the client-side is actually more secure and sensible than using a server-side method. For example, when checking password data over a non-secure link, it is sensible to not send the password in plain-text over an untrusted network. Also, for basic checks it may be a waste of resources relying on the server to validate data, for example checking the similarity of two strings.

An example of this is the password update page. The user should be warned if the old and new passwords match or if the new password and the confirmation do not match. This was handled easily and efficiently using JavaScript. On every change of a relevant input box a JavaScript function is called to check the validity of the input and, if necessary, modify the DOM to insert warning text. An example of this can be seen in Figure 25.

With aid of a BSD-licensed password library, JavaScript was also used to perform slightly more advanced client-side tasks. A simple password strength meter was added, with a graphical progress-bar, to allow the user to see how strong the new password is, before they decide to update the details on the server. The password strength bar and form can be seen in Figure 26.

As with any program, some problems were encountered in the creation of Shiny. However, some of these problems are not specific to Shiny itself, and may be prevalent with the development of Ajax applications.

For an application to be easily learnable it should seem to be deterministic, so that every user action has an obvious, expected and consistent response. For Shiny, as the application is being run in a Web browser, the expected response is for the application to behave in similar manner as other Web applications.

The newly introduced feedback for long-running tasks would not be familiar to a user who has never used an Ajax application, but as this merely presents information on progress rather than information that the user needs to process this does not detract from the learnability of the application. Classic Web applications don’t make use of extensive long-running server-side processing, so the progress indication could provide indication that the application hasn’t crashed or "broken". The presentation of the progress-bars naturally leads to comparison between those of GUI desktop applications performing long-running operations, and a user who had downloaded files from the Internet or copied files to removable media would be familiar with the concept of progress-bars.

The input validation may be slightly confusing to a new user as the error messages may seem to appear and disappear without the user noticing, causing confusion when they later encounter them. Classic Web and GUI desktop applications tend to respond to errors in forms when the form is completed rather than while the form is in progress. This may make an Ajax application slightly harder to learn, however, these provide far great response feedback than the previous methods used, and the error generation is predictable and deterministic, so after a few errors the user will quickly realise the difference with this type of application.

The modification of on-screen datasets (in this case, charts) without page reloading is also a novel concept to users experienced only with classic Web applications. However, this is used constantly in GUI desktop applications, so it may be slightly unexpected at first but should not break the flow of the application or the work. This applies equally with the saving of status without navigation (in this case the contents of a file). Were there no feedback on the operation the user may become confused as to why the action they took has not caused the traditional click-load-newpage cycle expected in a browser, but a status message is updated, informing the user of their last action’s result and success.

Ajax applications are becoming more commonplace, with sites like YouTube, Flickr, Facebook and Google Maps used regularly by average Web users. To a user unfamiliar with these applications the instant response and animated feedback may be initially confusing, but as the method of input is still the same as classic Web applications this confusion will rapidly pass, and the new Ajax applications provide more rapid feedback on user input and therefore a faster interface.

A flexible application should allow the automation of routine tasks, support for simultaneous tasks and give the user control of the task execution.

The progress-bar introduced in Shiny allows the user to perform other tasks, such as editing files, whilst keeping up to date with the progress of the current simulation. It also allows a user to stop a current run. In addition, throughout the application there is automation of tasks such as repetitive form submission or moving back and forward to perform input validation, change a dataset or submit some data to the server. This allows the user’s actions to be preempted, providing information in less time than it would take them to request it traditionally. However, a problem with this method is that the user is not in complete control of task execution, as many of the input validation operations occur without any direct request from the user, merely on input.

Most Ajax applications are similar in this regard, second-guessing the users current task to provide shortcuts to its completion. In Shiny, due to the simplistic and short nature of tasks, this works well as there is only usually one path the user can take to complete an action but other applications may result in a user having to fight with the interface in order to perform a task in a way that was not expected by the designers of the application. In Shiny the interface is not made customisable to the user, but applications such as the Google Customised Home and Google Maps use Ajax technologies to provide interface customisation, as can be seen in Figure 27.

An application’s robustness can be shown through its indication of its past, present and possible future states, the ability to undo errors, responsiveness and providing sufficient functionality to conform to user tasks.

Moving a GUI desktop application to a Web browser automatically gives it a state-based architecture, allowing navigation between these states and a history indicating the user’s movement through these states. Also, with classic Web applications, this allows simple errors such as a misdirected click to be easily remedied: simply click the "Back" button. However, with Ajax applications this becomes more difficult. This was highlighted earlier, instead referring to applets, in "Navigating the Applet-Browser divide" <[9]> and "Ajax: How to Handle Bookmarks and Back Buttons" <[8]>. Users of Web applications instinctively press the "Back" button to try and undo an action or return backwards in a process. Ajax applications rely heavily on JavaScript running on each page, manually updating the DOM, and this information is not stored in the browsers history stack, meaning that moving backwards through the history a user of a Web application may not see what they were expecting. In Shiny this is relatively minor, and only clicking back to progress-bar pages may present some confusion, as the progress-bars simply do not appear, or appear to be not progressing, the latter should not be confusing to the user as the run has already been visibly completed.

With larger, more dynamic Ajax applications such as GMail, this presents more of a problem. For example, once logged in to a GMail account, a user would find themselves at the "Inbox". If they decide to navigate to the "All Mail" folder they simply click on the link on the navigation bar. However, as this is an Ajax application this new folder is loaded dynamically using Ajax, so the address bar does not change. If the user then decides to navigate backwards to the "Inbox", they may instinctively press the "Back" button. With limited testing it was seen that this did not always return to the "Inbox" sometimes returning to the login screen and sometimes even "breaking" the application, returning the confusing error seen in Figure 28. In this strange situation, clicking the "Forward" button again results in the same error, with the only way to return to the "Inbox" again being to keep pressing the "Back" button until the login screen is seen and logging in once more.

As mentioned in the last chapter, Ajax solutions tend to use lots of small requests for data, rather than re-requesting the page. This allows Ajax applications to provide more responsive interfaces, both to user input and when changing datasets is required, as only the new data need be transferred. A possible criticism is that this requires bandwidth, but the total bandwidth used is far less when using an Ajax method than a classic Web application.

Providing the needed functionality in an Ajax application is simply a matter of implementation. It may require more to implement, but ultimately the sky is the limit as far as Ajax is concerned, as interfaces can be created that are far more dynamic than a classic Web application and may equal the usability of a GUI desktop application.

Evaluating Time Affordances in an application requires examining possible and forced delays and reassurance on long running operations completion. The reassurance on long task completion have already been covered in Learnability, and delays and application speed in Robustness.

Essentially, Ajax Web applications allow the creator to provide to the user a method of input equally as quick as a GUI desktop application and provide faster data transfer, due to the lighter overhead of using XML to transfer data than an HTML page with all the other content that is needed. This essentially allows the browser to not only cache the images and stylesheets for a page but actually some of the other content (such as navigation bars) by simply modifying the current page rather than reloading it in its entirety. Also provided is the ability for some processing of data and input validation to be performed on the client rather than server-side, further reducing the latency in making requests and bringing the speed of the application closer still to that of a GUI desktop application, whilst still providing the benefits of a Web application. With an application such as Shiny, with a powerful server performing the simulations, this may be far faster than using Dizzy on the local machine.

As previously mentioned, SVG is a vector graphic format that can be embedded in Webpages. SVGs can potentially be used to create event-driven graphics and animations, allow dynamic retrieval, scripting and animation. It is an open standard, and the tools to create, view and edit SVGs are freely available, with both open-source and proprietary solutions.

The current problem with SVG is the lack of browser support. No browser fully meets the latest specification and the most commonly used browser (Microsoft Internet Explorer) has no native SVG support. As a result, this technology does not have much usage on the Web, with most SVGs used for vector art offline, such as icons or diagrams.

With increased support and compatibility between browsers, SVG could potentially allow for even more rich interfaces than Ajax alone allows, and Ajax can be used within SVGs for dynamic content retrieval. Furthermore, SVG, with its ability to be scripted and animated, could feasibly topple Adobe Flash as a tool for creating dynamic, animated Websites while allowing pages to be individually bookmarked and give a more browser-native feel to dynamic applications, common criticisms of Websites using Adobe Flash.

This project did not make use of user-based usability validation, instead relying on guideline and task based evaluation methods. A more in depth user-focused usability study could make aware of some of the more subtle effects of Ajax on usability, such as how likely users are to attempt to use the "Back" and "Forward" buttons. With Shiny the changes made and added functionality was sufficiently small to allow guideline based evaluation to be sufficient, but a comparative evaluation of GMail or another Ajax version of a common, complicated GUI desktop application, such as a word processor or spreadsheet, could be beneficial, allowing developers to ensure their focus is directed to any common stumbling-blocks users encounter when trying to use Ajax applications in a working environment.

An examination of the negative implications for Ajax of a low-bandwidth connection was discussed in this report, but not that of other conditions such as packet loss or high latency. High latency in particular is an area in which Ajax applications could potentially suffer greatly compared with classic Web applications. Due to insufficient infrastructure available to test this further, this report does examine the effects under these conditions, however the frequent small update structure usually used in Ajax applications will result in a sluggish or "broken" application with poor network conditions, so a formal quantitative analysis of this could be beneficial for evaluating the potential for Ajax replacements for GUI desktop applications.

A common criticism of the wave of Ajax applications and the increased use of these to replace GUI desktop applications is the perceived lack of attention to security. Previously mentioned are the possibilities of cross-site scripting vulnerabilities in JavaScript but also the weakly-typed nature of JavaScript, the dependence on client checking the client data, the inability to prevent modification of the local copy of JavaScript and poor error handling all create potential security flaws, bringing security risks to the server and/or the client. A recent virus named "Yamanner" spread through the Yahoo! Mail service, sending the contents of a targeted user’s address book to a remote server.

Clearly there are potential and real security problems with Ajax, but a formal evaluation of these problems and how they can be prevented by server administrators, clients and Web application developers is beyond the scope of this report, but could be useful as a tool for those developing Ajax applications.

Comet is a further evolution of Ajax. Where Ajax relies on a polling loop to check for changes on a server and to mimic event-driven behaviour. This model is flawed when the client must wait for an event to occur on the server, as it relies on the client checking for the event before it can be handled or detected. A better solution to this problem would be allowing the server to notify the client on the event, but this is not possible with Ajax. Comet is a technique that, rather than using a polling loop keeps a consistent HTTP connection between client and server, allowing the server to send data to the client on an event without the client requesting it.

Comet was, at the planning stages of this project, very much a bleeding-edge technology. During this project more frameworks have become available and Comet is becoming a viable option for event-based user interfaces. Some of the concerns still remaining with Comet are on its scalability, with each client requiring a long HTTP connection to the server, and existing Web servers are not designed for such a large number of connections.

Shiny’s progress feedback relied on the client checking for new data from the server, and sometimes it would not be available. With Comet this could have occurred whenever the server had new data, rather than the client unnecessarily polling, resulting in lower bandwidth usage and also a more smooth progress indication mechanism.

To restate the hypothesis of this project:

"Ajax applications can provide a more effective interface user interface than those of GUI desktop or classic Web applications with fewer drawbacks than either individual approach."

The conclusion of this project, as expected, is not a clear agreement or contradiction of the hypothesis, but more complex. The key outcomes of this report and the project are split into the benefits and drawbacks of using an Ajax application.

Ajax applications, due to the nature of their interaction with the server, can provide a far more responsive and rich user interface. Users can now drag and drop items, be notified on server events without requesting, and transform datasets on the fly without the need to reload the page. Their input can be quickly regulated and automatically corrected, minimising the use of bandwidth. Lengthy interactions with the server can have their progress indicated, whilst allowing other tasks to continue, allowing better multitasking.

The application developer can benefit through the ability to offload some of the application logic and processing to the client and needing to send only required data, rather than repeatedly send the same stylistic information. Also, the creation of these applications becomes increasingly less complex with the addition of new Ajax libraries to aid the developer.

One of the biggest struggles with Ajax development are the difficulties arising from the use of JavaScript. JavaScript suffers from its weak-typing, security risks and different implementations across browsers and also that some users may have disabled JavaScript within their browsers. In addition, debugging can be very difficult and time consuming as Ajax applications frequently make use of multithreaded JavaScript, resulting in race conditions and obscure bugs. For logic implementation, JavaScript, as an interpreted language, is frequently slow and can use a lot of memory, leaving client machines somewhat unresponsive. In addition, the nature of an application in a browser means that other potentially "buggy" sites may crash the browser and cause loss of work by the user. A minor issue is that of retaining backwards compatibility. An Ajax application must be accessible to clients without JavaScript, those with text-based browsers or search engines.

Ajax’s lack of browser compatibility is evident from the need for "hacks" to make the same code work in different browsers and how easily Ajax applications "break" common functionality such as the "Back" button. This leads onto an argument growing somewhat less valid now; Ajax applications are unfamiliar to a user of classic Web applications and can cause confusion.

The largest development pitfall encountered in the development of Shiny was the difference in architecture between Ajax and classic Web applications. With Ajax applications, the logic needs to be easily manipulated and accessed by the Ajax code, and long running tasks buried deep within an application need to be made accessible to a user interface, necessitating large amounts of re-engineering in order to access this.

This report has provided a glimpse into some of the usability benefits and drawbacks of Ajax Web applications. The usability study provided between Dizzy, Klingon and Shiny could be used to evaluate moving a classic Web application or GUI desktop application onto the Web. For creating new Web applications, Ajax can be a powerful tool in providing more usable, intuitive and responsive user interfaces. However, porting existing Web applications to Ajax could prove to be very time consuming and difficult and therefore must be analysed carefully before implementation. There are no clear benefits of Ajax application interfaces over those GUI desktop applications, but the benefits of distributed storage, computing and portability can be counted in the favour of Ajax. Technologies such as SVG and Comet are likely to push the boundaries for these applications even further.

Ajax is a new technology that has captured the imagination of many application developers. The dream of the Internet as an application platform may be realised and as browser support and libraries make development easier and users become more familiar with the new interfaces, Ajax Web applications will provide more services to users in an easy-to-use manner from anywhere with an Internet connection, without the requirement of a plug-in.