Problems More Easily
This chapter has looked at the different stages of the web engineering development process, ex- ploring possibilities for tool support to improve the usability of the website that is being created.
Initially, it may seem unlikely that significant usability improvements are possible with special tool support, as programs can only ever have a very limited view of how humans might react to a particular user interface. However, as the discussion of tool concepts above shows, there is a potential to assist the developer with many usability-related aspects during his work on the application. Once some more manual parts of his work have been automated, he is not distracted by details and has more time to consider the possible implications of his design decisions on usability. As a result, many of the discussed tool concepts only indirectly improve usability, by giving the developer the means to identify usability problems more easily.
The basic ideas behind the different tool concepts can be summarized in the following five principles for usability tool support in model-based web development:
1. Embed expert knowledge about usability in tools, i.e. let the tools follow established guidelines by default when creating new applications, or let them analyse the developer’s design with regard to these guidelines.
2. Use models as a source of meta informationabout the pages of the web application. This allows automated usability validators to achieve higher quality than without the presence of models.
3. Do not eliminate humans from the development process(e.g. for prototyping or user tests), but do automate preparation of the relevant steps in the process, as well as data gathering and analysis.
4. Educate the developerand increase his awareness that usability problems are important. It should not be assumed that he is an expert in usability, and not even that he attaches a lot of importance to usability issues.
5. Leave the developer in control – only assist him in coming to a conclusion about the impact of a design on usability, rather than making the decision for him.
Two of the most promising tool concepts are evaluated in chapters 6 and 7: Model-based usability validation (sections4.2.3,4.3.1,4.5.1) and web-based interaction logging for user tests (section4.4.1). Together, they incorporate all of the principles above. Many of the other concepts are less interesting for prototypical implementation, as they either employ already existing tools for new purpuses (such as requirements elicitation), or because it was felt that the functionality was similar to one of the two implemented concepts. For example, implicit modelling support for content management systems is conceptually similar to the “stand-alone” model-based usability validator that was implemented.
A Model for Usability and Accessibility
Information
As shown in the previous chapters, there is only limited support in existing web engineering models to record information which is needed by automated tools for usability and accessibility support. For example, none of the approaches from section 3.2 includes a user model which records the number of years of school education of the user – however, the “text complexity” usability check from section4.3.1needs this information to determine whether the page is likely to be understood by the users. In practice, many properties influence how users perceive and interact with the web application. A context model is required to specify this information, e.g. to assign different user groups to different parts of the application. The model must be integrated with the other web engineering models in order to allow an accurate mapping between parts of the application and the appropriate context.
After a look at related work, this chapter proposes extensions to existing web engineering models which allow the implementation of the tool concepts outlined in previous sections. This is achieved by introducing a new metamodel. The extensions represent a framework with defined semantics which can be used by different modelling solutions and tools. The meaning of its elements (such as string tags, see below) is described in a way which is sufficiently detailed to allow an implementation to be created. By providing a “standard” for the representation of usability-related information, it is hoped that future work on the integration of different tools will become easier.
The context model describes the user, platform and environment, and can be associated with existing classes which represent e.g. the pages of the application. The developer uses it to specify
expected static properties of users etc. – the model is not intended for the description of pa- rameters which change at runtime (although an extension to allow this would be feasible). In addition to the context model, a few properties are also directly added to existing presentation or navigation models, and yet others are attached to models by means of OCL constraints.
Finally, this chapter also discusses how to add the above model elements to the models of the different existing web engineering environments, and how to embed model information in the final HTML implementation.
1:N 1:N
Access
Basic user sub−schema
Location Longitude Latitude Height Activity Name Handycap Description 1:1 1:1 Device CPU InputDevice Display Memory Context Model sub−schema 1:1 1:N DefaultSV Group GroupName SiteView SiteViewID Review Title Body Belonging Personalization sub−schema Artwork Title Photo User UserName Password EMail 1:1 0:N 1:N 1:N 1:1 0:N DefaultGroup Membership 1:1 0:N 1:1 1:1 Preference 1:1 0:N
Figure 5.1: Example for a context model for WebML applications which adapt to changes
of context. [Ceri07MDDContext]
5.1
Modelling of User Properties and Context
Summary: User models and context models are of particular interest for the tool concepts introduced in this thesis. Some existing web engineering solutions provide support for these models, but related work outside the domain of web engineering is more advanced in this respect.
The analysis of web engineering models in section3.2shows that some existing web engineering approaches include the concept of user models or context models. However, for this aspect, the state of the art appears less advanced in web engineering than in other research fields, such as model-driven development of interactive, adaptive applications. The following is an overview of some efforts to model users and context of use, both in web engineering and other areas. Some of the ideas will be used in subsequent sections to propose models which are suitable for usability tool support in web engineering.
Context-Aware Applications With WebML
In [Ceri07MDDContext], the development of context-aware applications with WebML (see sec- tion 3.2.2) is described. The focus of the publication is the “context-triggered adaptation” of web applications, i.e. updating content, navigation or presentation when there are changes to the environment in which the web application is used, but not necessarily changes to the user or device. This focus is different from the aim of the tools from chapter4, which concentrate on aspects like the automated analysis of models. When developing context-aware applications with WebML, the context in which an application is accessed consists of properties and attributes for the following:
• The user of the application, and his current activities, • the location in which the application is used,
• the devices with which the user accesses the application, and • other aspects of the environment and of the application itself.
To represent the context information as part of the other WebML models, a data-centric ap- proach is chosen – this is an obvious choice given WebML’s background. The context model is attached as metadata to existing entities. Figure5.1shows an exemplary application data source together with a possible context model. Because the user is of particular interest, the correspond- ingUserentity is the central entity through which a user interface view of the site (SiteView) is connected with other concepts, such as the used device.
The exact properties e.g. of the Device entity are not specified in the paper. Instead, it is expected that the model will be adapted to the needs of a context-aware application. In contrast, the different sub-schemas shown in the figure are general enough to be applicable to most web applications: Users are represented as belonging to one or more groups, context information is stored for each user, and personalization information is also recorded individually for each user.
When trying to apply the concepts to the tool ideas presented in this thesis, one difference becomes obvious: The WebML work on context models assumes a setting where the web server will adapt the site to each individual user. In contrast to this, things like model-based usability validation work in a less detailed way, they have to generalize in the sense that they assume certain usergroupsto have properties like “uses a desktop browser” or “is aged 12 to 16”. Thus, when adapting the models, it may make sense to associate user groups rather than users with the remaining context information.
Cameleon Reference Framework
In [Calvary03MultiTarget], the authors present a framework which is intended as a reference for the description of user interfaces in the area of context-aware computing. The context of use of an application is described as consisting of three major components:
• The humanusersof the application, described as stereotypical users, for example in terms
of the things they are able to perceive or the actions they are able to perform,
• the hardware and softwareplatformon which the application runs, which is characterized
via the available resources (e.g. memory, screen resolution, bandwidth), and
• the physical environment in which it is used. This includes objects, persons and events
which may influence the interaction between the user and the application.
The aim of the framework is to allow a developer to create so-called multi-target user inter- faces which adapt to the context of use while remaining usable. The outlined process achieves this by first specifying the interaction with the application in an abstract way independent of con- text, and then successively refining the models until they correspond directly to a user interface for a specific user, device and environment. Due to its goal of providing a generic basis for exist- ing and future work, the paper does not include details on the contents of the models beyond the three parts mentioned above.
environment type : string id : string name : string isNoisy : boolean lightingLevel : string isStressing : boolean context id : string name : string uiModel creationDate : string schemaVersion : string contextModel plasticityDomainSet id : string hardwarePlatform category : string colorCapability : integer cpu : string isImageCapable : boolean inputCharSet : string keyboard : string maxScreenChar : integer model : string outputCharSet : string pointingDevice : string pointingResolution : string screenWidth : string screenHeight : integer screenSizeChar : integer isSoftKeyCapable : boolean storageCapacity : string isTestInputCapable : boolean hasTouchScreen : boolean platform id : string name : string userStereotype id : string stereotypeName : string taskExperience : string systemExperience : string deviceExperience : string taskMotivation : string browserUA browserName : Literal browserVersion : Literal isFramesCapable : Boolean HtmlVersion : Literal isJavaAppletEnabled : Boolean isJavaScriptEnabled : Boolean JavaScriptVersion : Literal isTablesCapable : Boolean XhtmlVersion : Literal XhtmlModules : Literal softwarePlatform audioInputEncoder : string downloadableSoftware : string jvmVersion : string osName : string osVendor : string osVersion : string videoInputEncoder : string networkCharacteristics capacity : Number costPerVolume : Literal costPerTime : Literal wapCharacteristics supportedPictogramSet : Literal[0..*] WapDeviceClass : Literal WmlDeckSize : Number WmlScriptLibraries : Literal[0..*] WmlScriptVersion : Literal[0..*] WmlVersion : Literal[0..*] plasticityDomain id : string contextId : string platformPlasticityDomain id : string platformId : string userPlasticityDomain id : string userStereotypeId : string environmentPlasticityDomain id : string environmentId : string platformPlasticityAspect id : string userPlasticityAspect id : string environmentPlasticityAspect id : string screenSizeAspect allowedOperations : string[0..*] corners : coordinate[0..*] shape : string 1..* 0..1 1..* 0..1 1..* 0..* 1..* 0..* 1..* 0..* 1..* 0..* 0..1 0..* 1..* 0..* 1..* 0..1 0..1 0..* 1..* 1..* 1 0..* 1 1..* 1 0..1 1 0..1 1 0..1 1 1..* 1 1..* 1 1..* Source:http://www.usixml.org/index.php5?mod=download&file=usixml-doc/UsiXML_v1.8.0-Documentation.pdf, p. 102, accessed 18 August 2007
Figure 5.2: The UsiXML context model can represent many facts about the users, platform and environment. They are used to adapt the user interface to different usage contexts.
UsiXML
Based on the Cameleon Reference Framework, [Limbourg04UsiXML] describes the USer Inter- face eXtensible Markup Language (UsiXML), a language for the specification of UIs at different levels of abstraction. Figure5.2shows the UsiXML context model. Because one of the declared goals of UsiXML is to ensure good usability of the user interface on different output devices, the model includes many aspects which may influence usability: The user’s experience with the system and device can be represented, peculiarities of the platform like network bandwidth and screen resolution receive attention, and a few properties like noise and light conditions in the environment are also part of the model.
While the given model does not include some details like the user’s age, extending it would be straightforward. Thus, the model is an adequate basis if context information needs to be represented in connection with the user interfaces of interactive applications, including web ap- plications.
SOUPA Ontology
Ontologies are comparable to models in that both describe a portion of the real world. Thus, it makes sense to have a look at ontologies which concern themselves with the description of user
interaction or usability. SOUPA (Standard Ontology for Ubiquitous and Pervasive Applications, [Chen04SOUPA]) is a detailed ontology which is defined using the Web Ontology Language (OWL). It covers a wide range of concepts, including that of a person (with attributes like name, address and contact information), device (type, bluetooth capability) and the environment of use (location of the user).
However, a closer look reveals that the ontology is designed for a field of study which pri- marily concerns itself with new types of interaction (including physical interaction) with mobile or embedded devices, and less with the usability of any user interface that is presented. For ex- ample, this includes the use of mobile phones which employ sensors to receive information about their environment, or location-aware services.
From those properties that are important in the context of this work, only a small fraction are already present in the ontology. For most other things, the ontology would have to be extended. On the other hand, such an extended version of SOUPA would include many aspects which would never be needed for web usability, so all in all, this ontology may not be the best choice for the specification of usability-related user and context information for web applications.