ESTANDARIZACIÓN

Summary: Experience with the prototype suggests that validation quality can be improved if models are taken into account. However, an objective, fair comparison of the concept of model-based usability validation is hard: The scope of existent validators differs, and no models are available for existing websites.

This chapter has described the prototype of a model-based validator for web pages. It supports the validation of a number of example accessibility and usability guidelines based on model information which is embedded in the HTML code. The program is implemented as a server- side application.

It is evident from the descriptions in the previous section that many of the implemented tests only use heuristics rather than being able to give a 100% correct result. For example, it would be trivial to construct a page which has an excellent low readability grade, but which contains complete nonsense nevertheless. Still, considering the hard-to-automate nature of the problem, the results produced by the implementation are encouraging – tests of the prototype with existing websites suggest that the output of a model-based validator can indeed be more detailed and accurate than that of a validator which only processes the HTML data.

However, it is difficult to objectively compare the validation quality of the model-based Wusab prototype to that of the the existent non-model-based tools. Section 6.2.2 has already discussed the benefits of model-based validation at a conceptual level. A simple approach to a more practically oriented evaluation would be to evaluate several existing sites and to count the correctly identified issues and the false positives/negatives. Unfortunately, in the author’s opinion, this would not result in a fair comparison.

On one hand, this is due to the fact that Wusab only supports a basic, limited set of model- based usability tests. The number of guidelines and the exact selection varies a lot for other existing validators. Rather than comparing the concepts, it would only be evaluated how complete the implementations are.

On the other hand, existing websites do not provide models which describe their presentation, navigation, their expected audience etc. For a comparison test, this information can be created and it can be assumed that it would be present in practice, but this involves a subjective inter- pretation of the implementation to create the model, so the result might not reflect the original developer’s intentions. In particular, the platform model (user, device, environment) could only be guessed.

Finally, another aspect which makes comparison difficult is that the expressed aim of most existent validators is to evaluate the accessibility of websites only, and not the usability. It was already pointed out in section 2.1 that these two concepts do not exist independently of each other; bad accessibility usually affects usability. Consequently, even accessibility-only validators inherently also check for certain usability problems. However, it might not be entirely fair to conduct a test where the set of issues that should be recognized by the validator is extended to include usability problems, when the existent validators were never meant to recognize such problems.

UsaProxy, a Tool for Website Usage

Analysis and Testing

This chapter presents a tool called UsaProxy that is designed to support usability improvements during model-based web development. The central idea of the tool concept is to make user testing easier, by creating an accurate and detailed log of each test participant’s actions on the website during the test, and by making the logging system straightforward to setup.

UsaProxy can be viewed as a complementary tool to the model-based automated page val- idator Wusab from the previous chapter: Whereas Wusab assists the web developer during the time of a development cycle when he is working on the design or implementation, UsaProxy helps during the user tests that follow. It improves the usability of the web application indirectly by making it less work-intensive for the developer to conduct user tests and to analyse their re- sults. These user tests can also be remote tests (i.e. tests for which the test subjects do not come to a usability lab), which can further reduce the effort and costs of testing. The tool does not directly access the web engineering models itself, but its output can be used by a validator like Wusab to compare actual observed characteristics of the web application with the expected ones as specified in the model.

Web applications increasingly include pages which no longer employ the standard request/ response paradigm to update the user interface when the user performs an action, but instead use JavaScript code to contact the server and then change page content without reloading it. In general, it is harder for the developer to obtain feedback about the usage of these AJAX applications than with conventional web applications: Since the server is only contacted to store or retrieve data and not for all user interface updates, data from logfiles becomes less useful for analysing the users’ actions. Even for web applications which do not use JavaScript this way, the information in the server logs is often not detailed enough. For instance, it does not include the order in which the fields of a form were filled.

UsaProxy solves this problem with its detailed tracking of all user interaction with the web page. Implemented as an HTTP proxy, it uses AJAX technology itself to record all mouse move- ment and clicks, key presses and other activity on the page. Furthermore, every entry in Usa- Proxy’s log file identifies the URL and the exact HTML element that was interacted with on the

respective page. This makes it easy to extract facts like the exact time when a particular button was clicked. Finally, one interesting feature of the tracking solution is that no installation of software is necessary on the client machine. Instead, either the user’s browser needs to be recon- figured (if interaction on third-party sites needs to be observed) or no changes at all are necessary (if the site visited by test users is under the web developer’s control).

This chapter is based on several publications about UsaProxy [Atterer06UsaProxy] [Atterer07TrackingAJAX] [Atterer06LoggingAJAX].