Enhancing accessibility to web mapping systems with technology-aligned adaptive profiles

Abstract

Web-based geographic information systems have advanced rapidly on the back of web-based technologies, increased bandwidths and access to Digital Earth imagery and functionality. However, these advances are causing its capabilities to slowly overtake those of end-users. Additionally, the introduction of non-desktop devices such as smartphones, tablets and netbooks is starting to undo progress made towards standardisation of web-based technology. Large variations in screen sizes, computational power, bandwidth, and operating environments are once again introducing the need to ensure software remains functional across different platforms, standards-compliant or not. These two issues highlight the need for a mechanism to tune content and capability to end-users and their environment, to prevent information and complexity overload in a field already troubled by poor usability, while promoting cross-platform compatibility. This paper proposes the use of adaptivity to accommodate for users from different backgrounds accessing web mapping systems in different technical environments. It describes adaptive profiles aligned to the finite number of states a system can adopt, rather than the limitless range of user or environment characteristics that cannot be adapted to. Each profile consists of a combination of adaptive states comprising functionality, information detail, or technical demands to optimise for individual users or technical environments.

Keywords:

• web mapping
• digital earth
• adaptivity
• usability
• compatibility
• user modelling

1. Introduction

Web mapping technology has seen remarkable advances over the years, owing to the constant evolution of web-based technology and improvements to consumer bandwidth. The first instances of Internet-based maps were typically slow, form-submitted websites with a slow-to-load map picture and check-boxes along the side to control layer visibility. Common navigation operations could take many seconds to complete. Nowadays, AJAX-driven (Garrett 2005) highly-interactive web mapping systems (Google Inc 2005b; iDelve 1999) providing rich data in real-time are the norm, offering capability which approaches that of application-based Digital Earth geo-browsers such as Google Earth (Google Inc 2005a) and NASA World Wind (NASA Ames Research Center 2004). Apart from providing graphically rich spatial data across many layers, they frequently bombard users with contextually related information when they search, click, or hover on features, and offer a wide range of tools and options (see Figure 1). The information made available to users becomes ever more wide-ranging as more and more information is associated with location, from street view imagery to 3D buildings, photos, web links and more.

Figure 1. Example of an information-rich presentation in Google Maps (Google Inc 2005b).

Although the continual advances in web mapping capabilities are something to be excited about, a point is about to be reached where the capabilities of the technology may exceed those of the user. In addition, the plethora of information suddenly available to web mapping systems in real-time makes it necessary to improve on deciding what is relevant to the user, and what is not. Whereas web mapping was limited by technology at its onset, a point is now reached where the end-users are often the limiting factor, and one which differs on a user-by-user basis.

The recent growth in mobile devices has further added to the complexity. Until around 2008, most web mapping systems were targeted at only a handful of, usually Web standards-compliant (Berners-Lee 1994), ‘desktop-based’ browsers. The rise of smartphones, tablets and netbooks since this time means web-based geographic information systems (GIS) must take into account wide variations in screen sizes, aspect ratios, computational power, bandwidth and device-specific idiosyncrasies.

This paper discusses the role of adaptivity in ensuring that web mapping systems remain usable as well as operational in different technical environments. The issues of accessibility constraints of web-based GIS involving usability of interfaces and heterogeneity in operating environments are first discussed. The use of adaptivity approaches and user modelling are then outlined along with the proposed technology-aligned adaptivity model (TAAM). Aspects of the model were trialled and demonstrated through the implementation of a location based system (LBS) framework referred to as LOCUS which integrates positioning, social networking and user adaptivity components (Delfos, Tan, and Veenendaal 2010). The user modelling and adaptivity components of TAAM were investigated by capturing user profile data and constructing adaptive profiles through the use of decision trees. The results are discussed in terms of the benefits, drawbacks and future research directions of user adaptivity.

2. Accessibility constraints of web-based GIS

2.1. Usability in spatial information systems

Until recently, most spatial systems were targeted at professionals in the spatial industry and with an education in a spatial discipline. As such, the end-user was expected to understand concepts such as projections, coordinates, layers, overlays, scale, and other spatial terminologies. The complexity of GIS software has caused it to become accessible to only a handful of expert users (Angelaccio, Krek, and Ambrogio 2009) giving it the image of an ‘elitist’ technology (Meng and Malczewski 2009).

When developing systems for broader communities or the general public, it cannot be assumed that the target user has any familiarity with specialist concepts. Yet the user must be able to accomplish their goals successfully and effectively, with little to no training. If a user is introduced to a system which they are not able to operate, they are likely to leave it aside and not try it again (Junglas 2007). Users are easily intimidated by complexity, which means careful attention should be paid to interface design.

Usability, as defined by the ISO (ISO 1998), is largely determined by a user's ability to successfully interact with an interface, in order to accomplish their goal. Usability of web mapping systems has been found to be particularly poor when assessed against ISO standards (Schimiguel, Baranauskas, and Medeiros 2004). GIS in general are found to exhibit poor usability (Haklay and Jones 2008), although the uptake of Digital Earth systems by the general public in recent years demonstrates that at least some progress has been made. The absence of standards that specifically address GIS user interfaces was observed by the BEST-GIS project (Geographical Information System International Group 2004) and remains a problem today. Web-based GIS initiatives, particularly Digital Earth applications, are often designed with the general public in mind as a target audience, which means they must accommodate for people of various backgrounds and education levels.

Meng and Malczewski (2009) found significant differences in usability metrics between users with different levels of GIS experience of a web-based participatory GIS. In this study, it was found that GIS-experienced users perceived the system as having better usability, and required less time and instruction to successfully complete tasks. This raises the concern that people from the general public may not possess the spatial literacy required to efficiently operate a spatial application, unless particular attention is paid to making the operation of the system intuitive. Ideally, an interface should be able to accommodate for novice users, without sacrificing functionality for more advanced users (Wu 2000). With the increasing desire from expert users in the general community for greater interoperability in both data and functionality, trying to accommodate both novice and advanced users within a simple, useable and contextual interface is a challenge. An intuitive approach to achieving this, however, can be to show only the information and tools, which are relevant to the user's objectives and context, and which are suitable to the user's background and competence (Angelaccio, Krek, and D'Ambrogio 2009; Delfos, Tan, and Veenendaal 2010).

2.2. Technical heterogeneity of operating environments

Most existing web-based GIS are targeted at browsers which comply with W3C web standards (Berners-Lee 1994). Standardisation is essential in ensuring that developed software works reliably across multiple platforms, helping to ensure reliability and significantly decreasing development effort. In recent years, web mapping has been pushing the boundaries of web-based technology, by making use of increasingly advanced capabilities, such as vector-rendering and hardware-based positioning (Google Inc 2005b; iDelve 1999). Some of these advanced capabilities must rely on technology which is not (yet) standardised or universally supported, such as Google's implementation of vector-based rendering using WebGL (Google Inc 2005b). iDelve technology (iDelve 1999) has solely relied on Java applets for vector-rendering from 1999 until 2011, as W3C-compliant plugin-less vector-rendering has only recently become possible through HTML5 (Hickson 2011).

The widespread compliance to web standards has done much for reliability and interoperability, but the increasing use of smartphones, netbooks and tablets is at least partially compensating for the relative uniformity otherwise achieved.

The increasing presence of new devices, operating systems and browsers means developers of web mapping technology are under pressure to provide support for a wider range of operating environments. Standards-compliant or not, wide variations in screen sizes, the adoption of touch-based controls, variations in computational power and hardware-specific idiosyncrasies make it increasingly more difficult to develop a one-size-fits-all web mapping solution.

If the heterogeneity of operating environments succeeds in undoing the progress made by the adoption of web-standards, the end-users are most likely to suffer the consequences. They may be forced to select one device over another in order to be able to access spatial functionality, which is incompatible with their device of preference. Organisations which publish web mapping services will suffer from reduced uptake if only select devices are able to access them, unless they make the costly investment of duplicating development efforts to target individual device types.

3. Adaptivity and user modelling

3.1. Use of adaptivity

Adaptivity is a mechanism that can be used to dynamically adapt a system's properties or behaviour to an end-user's characteristics or requirements (Kobsa 2006). Adaptivity has been suggested as a way to prevent information overload in increasingly complex hypermedia systems (Billsus et al. 2002; Conlan et al. 2003; Fink, Kobsa, and Nill 1996; Flesca 2005; Johnson and Taatgen 2005; Koch 1998; Kost 2004; Kules 2000; Zhang and Ghorbani 2007).

Digital Earth-based systems and general web-based GIS could be considered ultimate hypermedia systems, as they arguably involve more diverse and larger quantities of data than almost any other type of system. Spatial data is literally multidimensional and spread across many domains and data types. The representational and graphical complexity of spatial data and the different ways in which users can interact with it, suggests that traditional human-computer interface (HCI) based research on adaptivity may need to be expanded to accommodate for spatial systems. Despite some efforts of applying adaptivity to improve mapping interfaces (Bereuter, Venkateswaran, and Weibel 2009; Chalmers, Sloman, and Dulay 2001; Reichenbacher 2003), adaptivity efforts targeted specifically at spatial systems are comparatively limited.

With spatial systems being increasingly targeted at the general public, there is an increasing need to incorporate adaptivity to address issues of usability and technical heterogeneity in web mapping. Interfaces would need to be dynamically customised to accommodate particular types of users or the devices they use.

3.2. User modelling

To be able to adapt a system to an end-user and their technical environment, it is necessary to collect and interpret information about the user (Hintz and Fiala 2004) in order to build a user profile (Kobsa 2006; Yu et al. 2003; Zhang and Ghorbani 2007). This profile must be interpreted in the context of the system and user preferences before it can be applied to adapt behaviour. The resulting abstracted representation of the user is referred to as a user model (Kobsa 2006).

The most unobtrusive manner to populate a user profile is to collect whatever information is made available by observing the user's behaviour (Flesca 2005; Herder and Dijk 2003; Hintz and Fiala 2004; Johnson and Taatgen 2005; Kellar and Watters 2005) and their environment (context sensitivity). From these two sources, a user model can be developed (Figure 2).

Figure 2. High-level representation of inputs to a user model.

User models assist in making predictions and generalisations about users to help drive adaptive behaviour (Johnson and Taatgen 2005). According to Kass and Finin (1988), user models can be beneficial under the following circumstances:

• The system seeks to adapt itself to individual users,

• The system assumes full or shared responsibility for successful Human Computer Interaction, and

• The user base, or potential system uses, is diverse.

Kass and Finin (1988) suggest that any system that seeks to be cooperative can benefit from a user model, regardless of the type of interaction that takes place with the system.

3.2.1. User monitoring

The purpose of user monitoring is to obtain knowledge about the user and the goals of the user. Information collected through user monitoring typically needs to be interpreted, for example, by a user model for it to be useful for the purpose of adaptivity or decision making. Existing web-based user monitoring methods rely largely on investigating the links that the user has followed, for example, by examining web-server logs (Flesca 2005; Zhang and Ghorbani 2007). However, web-server logs give only a limited picture of, often historic, user activity. True user interaction happens within the browser and never reaches the server logs, particularly for modern interactive web applications, where much of the processing occurs in the browser. Alternative monitoring methods are often obtrusive or impractical, such as camera observation to observe user response (Abigail et al. 2007; Liffick and Yohe 2001) and location (Anne et al. 2005; Martin, Ionut, and Romit Roy 2009), eye gaze detection to observe user interest (Johnson and Taatgen 2005), and integrated application monitoring (Fenstermacher and Ginsburg 2003). However, keystroke logging (Campbell 2005; Thomas, Karahasanovic, and Kennedy 2005) and mouse click logging (Flesca 2005) can be performed in unobtrusive ways so as not to change user behaviour (Kellar and Watters 2005) resulting in biased results (Fenstermacher and Ginsburg 2003).

3.2.2. Context detection

A user's environment, activities, preferences and their goals are collectively referred to as user context (Mohamed and Justin 2009; Spaccapietra, Al-Jadir, and Yu 2005; Teng, Chu, and Hsu 2004). Context can also include information on user location and the platform they use to access a system, both of which are important to adaptive changes in a web mapping system (Hintz and Fiala 2004).

Surroundings can be derived from relative or absolute locations, but could also be sensed using devices available to a web mapping client. Location is becoming increasingly readily available and accessible via static and mobile devices including GPS, WiFi, RFID, sensors and IP geocoding (Veenendaal, Delfos, and Tan 2011). The SurroundSense can determine relative locations at 87% accuracy using ambience footprints determined using sensors on a mobile device (Martin, Ionut, and Romit Roy 2009).

Information on the system environment of a user can reveal characteristics about personal preferences of a user, their platform capabilities or even their location. End-user IP addresses can readily be geocoded to country and city (Delfos, Tan, and Veenendaal 2008; Gornall 2005; MaxMind 2002). In addition, detailed information on operating system, browser version, locale, language and screen size can easily be obtained using server-side and client-side scripts part of ordinary websites.

3.2.3. User modelling methodologies

User modelling deals with the interpretation of information about a user, in order to make predictions and generalisations that help a system make user-customised decisions. How users are represented and how decisions are formulated depends on the type of user model, and how it is implemented. In general, two types of user models are identified:

• Stereotype models – users are placed into pre-defined classes, within which users are assumed to exhibit the same particular characteristics. Users in the same classes are treated the same by the user model (Kobsa 1993; Yang, Aufaure, and Claramunt 2007; Zhang and Ghorbani 2007).

• Overlay models – for each individual user, a profile is maintained containing values that are collected and updated for specific parameters of interest, such as user characteristics or assumptions on a user's knowledge (Chepegin et al. 2004; Johnson and Taatgen 2005; Zhang and Ghorbani 2007). Overlay models are more fine-grained than stereotype models, allowing more precise adaptation (Zhang and Ghorbani 2007).

Although overlay models are more fine-grained, they suffer from what is described as the ‘cold-start’ problem; a substantial amount of information is required on users or on newly added components to initialise an overlay model, which is not available until the user has interacted with the system for a minimum amount of time (Flesca 2005; Zhang and Ghorbani 2007). For this reason, stereotype models are often combined with overlay models to support adaptive behaviour, until sufficient information is collected for the overlay model (Flesca 2005; Zhang and Ghorbani 2007). This approach was used for the AVANTI project, which combined stereotypes, user profiles, and specific user preferences (Stephanidis et al. 1998).

Because of the effort that goes into building up the user model, including the amount of interaction time required on the user's part, there is a move towards centralised user-modelling servers that serve more than one application (Kobsa 2006; Zhang and Ghorbani 2007). An example of this is the GUMSAWS framework, which provides user modelling capabilities for adaptive web systems (Zhang and Ghorbani 2007). It can infer user properties such as gender, marital status and purchase frequency with an accuracy of close to 70% based on clickstream and purchase information from an online store.

4. Adaptivity in web mapping

Adaptivity provides a means to ensure that web mapping systems operate within the capabilities of both the user and their platform. There are a number of aspects about a user and their technical environment that a web mapping system could adapt to, including:

• Personal characteristics: professional background, level of competence, interests and preferences, and so on.

• User context: user location, region of interest, environment, current activity

• System context: screen size and resolution, type of interface (mouse, touch screen, keyboard only, etc.), connection bandwidth (4G, 3G, 2G, DSL, Fibre, etc.), hardware capabilities (graphics, processing power, memory), browser capabilities (support for HTML5, Flash, WebGL, Java, etc.)

If a system were to take aspects of users and their environment into account, it could prevent overloading a device with content it cannot process or download fast enough, limit its content to what is relevant to the user, and adjust the complexity of the information and presentation to what the user is able to interpret comfortably.

4.1. Adaptable aspects of web mapping systems

There are a number of aspects about web mapping systems that can be adapted to the user. Not all adaptable properties outlined here may be applicable to each type of web mapping system. Also, there can be overlap and interdependence between the adaptable properties, such that changes to one aspect of the system may require changes to another aspect. For example, a change to information presentation may require a change to information content, and adapting to a smaller screen may require changes to both presentation and content.

4.1.1. Information content

Possibly the most important aspect of web mapping is the information content (Angelaccio, Krek, and D'Ambrogio 2009; Bereuter, Venkateswaran, and Weibel 2009; Chalmers, Sloman, and Dulay 2001; Peng and Silver 2007; Zipf and Meng 2005). Particularly for map contents, too much clutter makes it difficult for a user to interpret the information. Content also includes search results, textual information, and other non-graphical elements. Changes to information content can help prevent some users feeling overloaded, while providing optimal levels of information to others (Angelaccio, Krek, and D'Ambrogio 2009). Adapting content can also make it more specific and useful through selectively hiding or showing layers, descriptions or search results on the basis of a user's location, background or interests.

4.1.2. Functionality

Functionality can also be adapted, as not all users are likely to make use of all available functionality (Angelaccio, Krek, and D'Ambrogio 2009; Benyon and Murray 1993; Klaus-Dieter, Bernhard, and Qing 2009; Peng and Silver 2007). By removing tools and functionality that a user is not likely to make use of, the simplicity of an interface can be greatly increased, preventing users from feeling that they are using ‘elitist’ software intended for more highly skilled people (Meng and Malczewski 2009). Adapting functionality helps prevent unnecessary complexity for some, while permitting rich capabilities for others. Adaptive behaviour can adjust the assistance offered for operations, hide advanced tools not frequently used, or make frequently used tools more prominent. On mobile platforms, it is often necessary to remove capability, because the limited screen size does not permit tools to be displayed or used properly. Gang and Daimeng (2011) found that 60% of rich clients could be well adapted to the small screen sizes of mobile devices, but that success rates dropped when interfaces were too large to be able to be condensed. For spatial systems, which often include large mapping components and many tools, the level of functionality may not always be appropriate for smaller screen sizes.

4.1.3. Presentation

Presentation can be as important as the information itself, and is often discussed separately in the context of adaptivity (Adipat, Zhang, and Zhou 2011; Ardissono and Torasso 2000; Chalmers, Sloman, and Dulay 2001; Johnson and Taatgen 2005; Kost 2004; Li, Li, and Bian 2007; Peng and Silver 2007; Reichenbacher 2003; Trewin 2000; Zipf and Meng 2005). Adjusting the presentation can help reduce complexity without having to reduce the amount of information. Adaptive changes can include the use of prominent colours for frequently accessed functionality or information, the use of symbols or pictures instead of complex textual descriptions, and adjustments to font and graphic styles. Adipat, Zhang, and Zhou (2011) observed how applying adaptive presentation on devices with screen constraints significantly improved user performance and perception.

4.1.4. Technical demand and compatibility

Adaptive changes can also be made to suit the capabilities of the platform, such as processing power and available memory (Hintz and Fiala 2004; Peng and Silver 2007; Reichenbacher 2003). The demands imposed by the data or functionality on the client platform must be adjusted to the platform's capabilities, which may involve taking into account device-specific compatibility. Particularly for mobile devices, a web mapping system must be able to accommodate for reduced capacity in terms of screen size, available bandwidth, memory and processing power. On the other hand, mobile devices often support capabilities not offered by desktop platforms, such as a three-dimensional compass, an accelerometer, and GPS. Apart from providing rich positioning and navigation capabilities to mobile applications such as Google Earth (Google Inc 2005a), these devices can also enable enhanced capabilities in mobile-friendly web mapping technology such as Google Maps (Google Inc 2005b) and iDelve Mobile (iDelve 1999) through HTML5 (Hickson 2011). To ensure compatibility while taking advantage of all supported capabilities, on-the-fly adjustments would be needed to accommodate for device-specific characteristics.

4.2. Technology-aligned adaptivity using adaptive profiles

Most adaptive changes that can be made to a web mapping system are discrete in nature. For example, to accommodate for reduced memory capabilities on a mobile device, a simplified data-set with a smaller size may be used, instead of a complete but large data-set. However, when it comes to adaptivity, there will usually be no gradual ‘intermediate’ options. Likewise, there is a finite number of ways in which tools can be hidden, or information can be presented, and not all possible combinations may be used. As such, it makes sense to define commonly-used profiles for each aspect of the system that is adapted.

Application of a particular profile should result in a fixed set of adaptive changes to a particular aspect of the system. Each adaptive profile is based on certain assumptions about the user, their context, and the platform they use. Whether a particular profile is applied would depend on how the user scores for the criteria associated with that profile, as well as what information is available. Each adaptive aspect may have a different number of profiles that can be applied to it, each comprising a specific combination of configurations to be applied to that aspect. For example, an adaptive aspect of ‘performance’ may have a profile which limits memory and computational demands, and another profile which assumes no device limitations. However, only one adaptive profile is selected for each adaptive aspect at a time, as otherwise the configurations within each profile would conflict.

The approach to adaptivity proposed here differs from most adaptive methods described in the literature, where adaptive behaviour is very much dictated by a profile describing the user, without detailed explanation on how this would translate to discrete system changes (Bereuter, Venkateswaran, and Weibel 2009; Kobsa 2006; Kost 2004; Yang, Aufaure, and Claramunt 2007). The traditional user-centric approach is based on an ideal system, able to adapt to every aspect of every user based on the model for that user. However, this is often not realistic from a technical point of view, particularly for web-based GIS systems which are inherently difficult to engineer (Angelaccio, Krek, and D'Ambrogio 2009). Given the finite number of states a system is able to adopt, compared to the potentially unlimited number of states an unclassified (overlay) user model could take on, it is unlikely that a system is able to adapt to the output of a traditional user modelling component. Even if a stereotype user model is employed where users are grouped into a finite number of classes according to personal characteristics, the resulting classes may not align at all with feasible adaptive changes. For this reason, it is more logical to approach adaptivity from a system point of view. This prevents a scenario where the output of the user model does not align with those adaptive changes that can technically be implemented within the system. It may seem counter-intuitive to have the system dictate the user criteria, rather than to have technology adapt to the end-user. However, this technology-aligned approach results in a more feasible implementation with a focus on adapting to relevant, domain-related characteristics of a user and the technical environment.

4.3. Proposed adaptive profiles

Adaptive profiles can be applied to qualitative, as well as quantitative aspects of both users and systems. Table 1 shows an example of three profiles which were developed and applied to the quantitative adaptive aspects discussed in Section 4.1: a Basic, Intermediate, and Advanced profile. For each profile, the adaptive changes associated with the profile are described.

Table 1. Example of profiles for the quantitative adaptive aspects of a web mapping system.

	Profiles
	Basic	Intermediate	Advanced
Information Content	Only the most relevant information is presented, pertaining to major features in high-relevance spatial layers, with little to no contextual information.	Multiple high-relevance spatial layers are presented in the map along with basic contextual information and descriptions.	Graphically rich maps are presented with a great degree of detail across multiple spatial layers. Detailed information and descriptions are presented along with the map itself. Information related to position, motion or orientation is presented if available.
Functionality	Only the most commonly used tools are made available, to accomplish basic operations such as navigation and enquiry.	Commonly used tools are available, as well as a small range of more advanced functionalities, such as measuring or advanced search, allowing users to dig deeper into the information presented.	The full range of capabilities is exposed, allowing the user to take maximum advantage of the information and analysis capabilities of the system. Capabilities requiring position, orientation or motion input are activated if support is available.
Presentation	A small palette of contrasting colours is used to separate key information from background information. Large text and intuitive pictures are used where possible.	Pictures are used in combination with text and descriptive icons to help convey more information. Colours are used to categorise similar information and capabilities, allowing more content to be presented in an organised fashion.	Rich styles are used to achieve a visually pleasing presentation, and to allow users to interpret the information according to multiple criteria simultaneously through a combination of fonts, colours, and graphic styles. Device orientation is reflected if compass information is available.
Technical demands	Only minimal code is executed on the client platform to maintain performance; minimal information is sent to reduce bandwidth requirements, and only key components may be shown to accommodate for smaller screen sizes. Example: smartphone	Some components may be hidden to accommodate for a slightly smaller than usual screen size. Information is limited to exclude less relevant details, and detail may be decreased to accommodate for reduced bandwidth. Computationally demanding capabilities are omitted. Example: tablet/netbook	All information is sent at full fidelity, as no bandwidth or memory constraints are assumed to be present. No functionality is omitted, and computationally intensive features are made available if required.

The adaptive aspects in Table 1 are not an exhaustive description of user profiles. In fact, they can be extended or further detailed depending on the data about users, technology and applications that is captured or available, and to the level of detail that is required for profiling users and systems. For example, technical demands could be broken down further to have separate profiles for bandwidth, processing power, and memory capacity. Likewise, functionality could separate out those capabilities that are usually only supported on mobile devices and tablets, such as position, orientation and motion. The quantitative profiles are ordinal in nature, and can be considered incremental, with each more advanced profile adding to the previous one.

Qualitative adaptive changes relate to the nature of information presented, or to device-specific idiosyncrasies that require technical adjustments on-the-fly to ensure compatibility or optimise performance for a particular device or browser. Qualitative adaptive changes are relatively domain and implementation specific, such that profiles would have to be defined specifically for each application instance. Table 2 identifies two such qualitative profiles that were developed, namely, for technical browser compatibility and domain-specific content.

Table 2. Example of profiles for the qualitative adaptive aspects of a web mapping system.

	Profiles
	Apple iOS 5.1 Browser	Android 4.1 Browser	Internet Explorer 9	Mozilla Firefox 14
Technical Compatibility	Components requiring support for Java, Flash or WebGL are omitted. File uploads are disabled. Challenge user for authentication. Position, orientation and motion input is used if the device supports it.	Components requiring support for Java are disabled. Flash support must be detected before used. Challenge user for authentication. Position, orientation and motion input is used if the device supports it.	Enable support for Flash and Java if support detected. Components requiring support for WebGL are disabled. Rely on single sign-on for authentication. Position input is used if the device supports it.	Enable support for Flash, Java and WebGL if support detected. Challenge user for authentication. Position input is used if the device supports it.
	Surveying	Planning	Environmental
Domain-specific Content	Enable surveying related layers and tools as well as base data.	Enable planning related layers and tools as well as base data.	Enable environmental related layers and tools as well as base data.

The qualitative aspects of each profile can be further detailed or broadened to accommodate diversity in users, technology and applications. For example, a separate profile could be created for each type of device, where compatibility is considered important, such as support for Java or WebGL, or single sign-on authentication. Likewise, separate profiles can be created to deal with support for positioning, orientation or motion detection through an accelerometer.

4.4. Technology-aligned adaptivity model

To drive adaptive changes, a model is needed, which will describe users in a quantitative and qualitative manner for properties that can be related back to adaptive profiles. The Technology-Aligned Adaptivity Model (TAAM) was developed as part of this research to model user and context sensitive data from adaptive user profiles.

Figure 3 shows an end-to-end walkthrough of the TAAM, illustrating how data is collected, interpreted, and used to drive adaptive changes.

Figure 3. Selection and application of adaptive profiles on the basis of interpreted user criteria from user profiles.

Input is received through user monitoring and context detection. This collective input constitutes the user profiles. These profiles are processed and abstracted by a user model, to present values for criteria used by the adaptivity component for selecting adaptive profiles. This process may involve transforming the captured raw data, or modelling it using predictive techniques based on inductive decision trees, deductive multiple regression or other methods (Delfos, Tan, and Veenendaal 2010). The adaptivity component applies profiles for the various adaptive aspects on the basis of the criteria presented by the user model.

The user model creates and maintains profiles that include values for the criteria used by the adaptivity component to base its decisions on. Such values include location, region of interest, user background, or technical skill-level. Each user only has one user profile, which is not to be confused with the adaptivity profiles, which are pre-defined collections of adaptive changes applied to one aspect of the system.

The adaptivity component uses classification to determine the adaptive profile that should be applied to an aspect of the system based on user criteria. It is therefore not necessary to also classify users within the user model; the adaptivity component needs access to the interpreted criteria values determined for the user, which the user model bases on collected monitoring data and contextual information. Contrary to conventional approaches, TAAM makes no attempt to group users into pre-defined classes, within which all users are assumed to have the same characteristics. The approach used here for the user model therefore, more closely resembles an overlay model, which maintains values for specific parameters of interest. However, the cold-start problem associated with overlay models (Flesca 2005; Zhang and Ghorbani 2007) described in Section 3.2.3 does not apply here, as classification still occurs, albeit in the adaptivity component.

An example of how TAAM can assist is where two users come from a similar background, with similar skills and experience, accessing a web mapping system using a similar device, but one user has access to a broadband connection, while another user is accessing the system using a low-bandwidth connection. The first user may be assigned an advanced profile for the aspects (or sub-aspects) of technical demands and information content, whereas the second may receive an intermediate or basic profile, to prevent the user receiving more information than his or her bandwidth can cope with. A traditional stereotyping approach may not have permitted this approach, as the classes would be based on general user-characteristics, without making allowance for differences in specific characteristics of their technical environment. The TAAM model does not try to classify users according to criteria that do not relate to adaptable aspects of a system.

5. Application of adaptive profiles

5.1. Monitoring and modelling for user profiles

To demonstrate the feasibility and benefit of the LOCUS framework, Delfos, Tan, and Veenendaal (2010) developed the Positioning, Mapping, Information and Communication System (POMICOS) prototype to support basic LBS functionality, WiFi- and IP-positioning, and social networking. This prototype incorporates the User Monitoring and User Modelling components of the TAAM illustrated in Figure 3. The system was tested by exposing volunteers in a controlled university campus environment to the social networking component of POMICOS in order to collect contextual and user monitoring data. Collected data were then modelled against user characteristics as determined from a questionnaire to assess whether such data could support a user model to drive adaptive changes. The POMICOS prototype demonstrated the feasibility of user monitoring and context detection in a web-based environment, and showed that monitoring data describing mouse movement, hand movement and keyboard events could be correlated back to user characteristics (Delfos, Tan, and Veenendaal 2010). A user's computer proficiency, rated on a scale from 1–10, was able to be predicted within a margin of 1 class-width in 76.7% of the cases by a C4.5 decision tree classifier using user interaction data as input.

5.2. User context monitoring application

The User Context Monitoring Application (UCMA) is a prototype that was developed and deployed as part of the LOCUS framework research project, to demonstrate how information about website visitors and their platforms can be collected to support adaptivity. Data captured included many device and user parameters such as screen size, user location, device type, operating system and browser. The UCMA demonstrated the feasibility, and the benefit web-based context detection and components of the UCMA were later integrated into POMICOS.

Figure 4 shows the distribution of platform/browser combinations for visitors of a website under the domain of Curtin University over four consecutive periods of one year. Visitor numbers were comparatively constant over these four years, having an average of 270 records per year (σ = 26).

Figure 4. Variability in platforms and browsers from July 2008 to July 2012.

Figure 4 clearly demonstrates a strong increase in the variability of platforms and browsers in recent years, particularly portable devices such as iPads and iPhones. Also, more browser types are being used for the same platform. The collected data also shows a strong increase in screen size variations, with 18 different screen sizes recorded during 2008–2009, versus 40 during 2010–2011 and 34 during 2011/2012 (the year 2011–2012 had 23% fewer visitors compared to 2008–2009, which may explain the slight drop in screen size variation in this last period).

Based on platform information as collected by this research, it is straightforward to determine device capabilities and limitations, which can help prevent information being provided that is incompatible, or too large to process. In addition, user preferences in terms of hardware or software choices can give an indication of the background of a user (Delfos, Tan, and Veenendaal 2010). Locale and language information can be helpful to customise content or presentation, or to fine-tune search results by disambiguating non-unique place names such as ‘Perth’ or ‘2nd Street’.

Data collected by this application came from a public website, and exhibited much higher variability than data collected by POMICOS, which was trialled in a controlled campus environment over a shorter period of time with computers, which were set up in very similar ways by the centralised IT support department. The examples provided in the following sections use this higher-variability context data collected by the UCMA over a 4-year period.

5.3. Decision trees for selection of adaptive profiles

Adaptive profiles are selected from the collective user profile information using decision trees. The decision trees incorporate the logic which an application could apply to select an adaptive profile by using the criteria of the user model. As examples, two decision tree processes were undertaken, one based on the technical requirements of the end-user platform, and the other based on user proficiency in combination with screen size.

Based on parameters from the UCMA, the decision tree in Figure 5 shows how a Basic, Intermediate, or Advanced profile is selected for the technical demands placed on the end-user platform. Examples of high-level adaptive changes that could be associated with Basic, Intermediate or Advanced profiles are shown in Table 1.

Figure 5. Decision-tree for selecting a profile for the adaptive aspect of computation demand using platform parameters.

The decision tree in Figure 5 shows how the device type is deduced on the basis of screen size and platform. Larger screen sizes usually imply more powerful platforms. The decision tree shown here is indicative only because of space restrictions, and can be expanded to incorporate more platforms and technical specifications as they become available. For example, first and second generation iPads can be detected by looking for platforms running iOS with a resolution of 1024 × 768 pixels, while more powerful 3rd and 4th generation iPads are recognised by their resolution of 2048 × 1536 pixels. Basic netbooks often have a screen height of 600 pixels, while screens of 1200 × 800 pixels are often dual-core Android tablets. In a real-world implementation, it is important to be as specific as possible in detecting devices. Poorly implemented adaptivity can cause end-user frustration if functionality/content is needlessly omitted, or if a device is provided with content it cannot process.

To address the issue of usability, it is necessary to also model against parameters collected from user monitoring and interpreted by a user model. By combining inferred computer proficiency from a C4.5 classifier with detected screen size, it becomes possible to compensate for perceived complexity associated with smaller, more crowded screens (Adipat, Zhang, and Zhou 2011). Figure 6 shows an example decision tree which selects Basic, Intermediate, or Advanced profiles for the adaptive aspects of information content and functionality using inferred computer proficiency in combination with the size of the end-user's screen.

Figure 6. Decision-tree for selecting a profile for the adaptive aspects of information content and functionality using screen size and inferred computer proficiency.

Examples of high-level adaptive changes that could be associated with Basic, Intermediate, or Advanced profiles for information content and functionality are shown in Table 1.

The decision trees shown in this chapter are examples of how adaptive changes could be triggered. Examples of adaptive changes given here are high-level only, because adaptivity is very implementation-specific. Rules to drive adaptive changes should be customised from application to application, but also as technology progresses. Poorly implemented adaptivity can detract from the HCI experience rather than improve it. A common example is the experience of receiving the mobile version of a website, with significantly reduced content, when the device being used was perfectly capable of processing the standard, more complete, version. Likewise, if an iPad 3 on a low-bandwidth connection is incorrectly classified as a desktop platform based on its high resolution, its user will not be pleased if it is presented with ‘heavy’ unsupported Flash content. When adaptive changes needlessly withhold content or capability from end-users it is likely to result in frustration. Unless the rules driving adaptivity are very finely tuned and validated, users should have the option to influence or override adaptive changes.

6. Discussion and conclusions

This paper discusses the evolution of web mapping on the back of advancing web-based technologies including GIS and digital earth systems, and how web mapping systems are at risk of becoming more complex than their target audiences can handle. This issue is particularly applicable to information-rich digital earth systems, which have begun to be used by a more diverse range of users, devices and applications. The introduction of new end-user devices is increasing the number of ways in which more users access web mapping systems. Access to web mapping systems can be enhanced with the adaptivity solution proposed in this paper.

Whereas usability has been considered a problem in geospatial systems for some time already (Haklay and Jones 2008; Meng and Malczewski 2009; Schimiguel, Baranauskas, and Medeiros 2004), the technical heterogeneity of environments is a more recent but possibly more urgent problem. Many currently available web mapping applications are not able to operate in anything but a desktop browser in a ‘standard’ environment, or will work with reduced capability or information access on tablets, smartphones, or netbooks with small screen sizes. Although there have been efforts to introduce adaptivity in general information systems to address usability (Klaus-Dieter, Bernhard, and Qing 2009; Peng and Silver 2007), device capability (Hintz and Fiala 2004) and screen size related issues (Adipat, Zhang, and Zhou 2011; Gang and Daimeng 2011), there are few specific applications of adaptivity to spatial systems, despite these systems being highly complex in terms of information dimensionality and functionality.

The inherent complexity of implementing web-based GIS (Angelaccio, Krek, and D'Ambrogio 2009) means that, any proposed solution based on adaptivity should aim to be technically feasible and integrate well with existing technology. Much of the existing work in user modelling and adaptivity (Chepegin et al. 2004; Kobsa 2006; Yu et al. 2003) aims to model users with academic perfection, without necessarily considering the value of the resulting user model in driving adaptive changes, or the technical feasibility. This paper has put forward an end-to-end design for applying adaptivity in a technology-aligned way, which approaches adaptivity from an implementation perspective. Given the comparatively few adaptive states a system can adopt, compared to the limitless properties that users and their environments can exhibit, this approach is more likely to lead to a model for adaptivity, which is technically feasible. Examples have been given of aspects of a system which can be adapted, and decision trees provide the means to select adaptive profiles based on monitored and acquired user and context data. The POMICOS prototype of the LOCUS LBS framework has demonstrated that meaningful criteria part of an overlay user model can be modelled from monitoring data within a web-based environment (Delfos, Tan, and Veenendaal 2010). Context data collected by POMICOS was gathered just prior to the main rise of tablets and smartphones, such that modelling against questionnaire ground truth only proved useful for monitored user interaction data. Future efforts therefore leave opportunity for the joint collection of context and interaction data from modern devices, which can be modelled using decision trees as shown here in order to trigger adaptive changes based on a user's platform and their inferred proficiency.

Adaptivity can be applied to any Digital Earth or GIS system which suffers from the usability or technical heterogeneity issues discussed here. However, it is only likely to improve the HCI experience, if the adaptive behaviour is finely tuned to the specific implementation, and to current-day technology. The TAAM approach provides the processes to accommodate the range of user, technology and application data needed, and the flexibility to adapt to diverse users and technologies. Further research will need to investigate the selection and adaptive profile development for a wider range of user and contextual data including location, historical traces, dynamic applications and participative environments envisaged for web-based mapping and digital earth systems (Craglia et al. 2012).