Museums and the Web 2005
Screen Shot: Detecting the user's room

Reports and analyses from around the world are presented at MW2005.

Let's Go Mobile! Design Issues In Multichannel "Accessible" Applications For Cultural Heritage

Sebastiano Colazzo, Franca Garzotto, and Paolo Paolini, Politecnico di Milano, Italy


A 'traditional' Web application for cultural heritage (CH) is intended for use in a stationary setting, far away (or at least separated) from the space where CH material resources are located and can be physically perceived by visitors. Mobile technology enables the creation of challenging CH applications that support new on-site experiences for the public and simultaneously expose users to both physical CH resources (e.g., paintings in a museum or ruins in an archaeological park) and digital virtual resources. When "porting" an existing Web site for culture heritage to mobile devices, a number of design issues arise, as we discuss in this paper. We give an overview of both the potential and the limits of mobile technology, and note the implications for application design. We introduce the concept of multi-channel Web applications and explore, from a design perspective, the concept of interoperability. We discuss the issue of location awareness and its design tradeoffs. Finally, we consider the requirements of disabled users, addressing the issues of design for accessibility in mobile applications.

Keywords: mobile devices, application design, user needs, multichannel application, interoperability, location awareness.


'Traditional' Web applications for Cultural Heritage (CH) are mainly intended for stationary use, on conventional desktop or laptop machines, in a physical setting (e.g., at home, in the office, in the museum library or reading room), that is different from the context where the material CH resources are actually located. The advent of mobile technology proposes a new challenge: creating enhanced reality (Spasojevic & Kindberg, 2001; Vlahakis et al. , 2004; Ryan, 2002) experiences in which physical cultural resources (e.g., paintings in a museums or ruins in an archaeological park) coexist with digital, virtual resources, and the user is exposed simultaneously to both of them. This paper explores some critical design issues that should be addressed when a CH institution decides to go mobile and to port a stationary Web application to devices enabling ubiquitous on-site fruition. We start our discussion by introducing a technical perspective of the field, discussing the potential of mobile devices and the limitations they impose on design solutions. We then introduce the concept of multi-channel Web applications (i.e., Web enabled applications that are delivered on multiple devices), and present some user scenarios. We also discuss, from a user perspective, the need for interoperability among different versions of a multichannel application, and its design implications. Then we address a specific capability of mobile devices – location awareness - and its design tradeoffs. Finally, we consider the requirements of disabled users, addressing the issues of design for accessibility in mobile applications. The paper exemplifies some of the above issues by discussing the experience of porting into a mobile version a museum Web site ( developed in cooperation with State Museums of Berlin for the Munch Prints exhibition held in April 2003.

Mobile Applications: Technological Perspective

The enormous potential of mobile applications is influenced by the constraints and drawbacks of today's mobile technology. In this section, we briefly overview these aspects which necessarily affect what a designer can or cannot conceive with a mobile application, and discuss them from three main viewpoints:

  • the hardware characteristics of mobile devices (e.g., display size, data input and pointing mechanisms, weight, expandability, processing power, memory space, battery capabilities, location-detection instruments);
  • the underlying communication infrastructure features (e.g, network connection modes, bandwidth, protocols);
  • the software capability (e.g., operating system, application development tools, data interchange formats).


Small display size and awkward methods of data input and pointing are among the major hardware constraints that impact mobile application design (Longoria, 2001).

For example, a Personal Digital Assistant (PDA, a typical mobile device) has a 3.5" TFT screen which operates at a resolution of 240 x 320 pixels in 16-bit color. If we compare this configuration with the resolution of a conventional desktop PC (1024 x 768 pixels with 24-bit colours and a 15" diagonal display), it is clear that PDAs impose significant limitations on the quality of media objects, and on the number and size of interaction elements that can be shown simultaneously on the screen. The size, spatial position, and cardinality of interaction objects are also affected by the mobile pointing mechanisms of mobile devices: they often have significantly lower resolution (e.g., touch-screens) or require the use of additional hand-held components (e.g. pens on PDAs - difficult to manage for a user in motion) or don't provide any 2D pointing mechanism at all except vertical and horizontal scrolling of a list of interaction items (e.g. mobile phones). Thus  user interaction should be simplified, minimizing the interaction elements displayed on the screen and avoiding visually demanding navigation.

For similar reasons, data input operations need to be minimized. Mobile devices can be equipped, in principle, with a fully alpha-numeric keyboard, but this creates usability problems while the user is moving around. Mobile applications can offer indirect means for data input - such as a visual keyboard on the screen or handwriting character recognition - which require pens or intense scrolling and has the same drawbacks mentioned above (Paelke et al., 2003).

Another constraint a designer needs to take into account is that mobile devices have rechargeable batteries whose charge-time varies, depending on utilization conditions, from 3.5 to 20 hours. This imposes some obvious constraints on the design of the duration of a user experience with a mobile device (and requires a careful organizational policy to manage the recharge process).

Finally, mobile platforms can be equipped with devices that can detect the user's position in the physical space, thus enabling location-aware behaviours of mobile applications. This capability allows the development of smart experiences in which information and services applicable to immediate local needs are emphasized (e.g., the Guide system (Davies et al., 1999), Cyberguide (Abowd et al., 1997), C-MAP (Sumi et al., 1998), MUSE (Salmon Cinotti et al., 2004), and Munch-Mobile (

The technologies used for location-awareness are mainly short-range infrared, ultrasonic or radio signals for indoor applications, and Global Positioning System (GPS) receivers outdoors. Indoor measuring methods use elapsed time of signals in combination with cell identification, time synchronisation or differences of elapsed time and allow obtaining position accuracy from 0.3 to 1 meter. By contrast, a GPS –based system provides accuracies on the 0.5 to 10 m level according to the number of available satellites.

Communication Infrastructure

Mobile devices can communicate with peers and stationary devices, both locally and remotely, at different degrees of performance and capacity depending on the different network connection modes (GPRS, UMTS, Wireless LAN, Bluetooth). The communication infrastructure introduces an additional technological variable that designer must take into account.

GPRS (General Packet Radio Service) ( is a packet switching technology for GSM (Global System for Mobile Communications) mobile phone networks. A GPRS connection is 'always on' and a single user connection allows 21.4Kbps, but combining multiple connections (time slots) can reach a theoretical speed of 171.2Kbps. GPRS fully enables Mobile Internet functionality since it enables the interplay between the existing Internet infrastructure and the new GPRS network. Still, the limited bandwidth available to a GPRS connection makes extremely important to have selective downloading of data - high resolution images, for example, should be avoided.

UMTS (Universal Mobile Telecommunications System) ( is envisioned as the successor to GSM. UMTS addresses the growing demand of Internet-based mobile applications for new capacity in the overcrowded mobile communications sphere, since it increases transmission speed to 2 Mbps per mobile user and establishes a global roaming standard.

WLAN (Wireless LAN - Local Area Network) technology allows a mobile device to transmit and receive data over radio airwaves. A WLAN usually consist of a wireless antenna (access point) which allows a number of mobile devices (provided with a WLAN card) to access the Internet. The technical standard developed by the IEEE, on which most of today's WLANs run, is the 802.11g (or Wi-Fi) which allows communication speed of 54 Mbps. ( - thus relatively limited with regard to UMTS.

Bluetooth ( is a standard for data communication that uses short-range radio links in place of cables to establish the interconnection between mobile devices. Bluetooth allows transmitting and receiving data at 721 kbps. As such, it is not designed to carry heavy traffic loads, and it would not be a suitable technology for replacing LAN, WLAN, and Backbone cables in applications require heavy data transmission and exchange. Nor is Bluetooth, by its very nature, suitable for server-based applications. The emphasis in Bluetooth is on mobile, re-configurable computerized units that need sporadic contact with each other, and can autonomously provide their own computational and data power.

Finally, designers of mobile applications must also take into account that these systems typically operate in a highly dynamic network environment (Peddemors et al., 2004). A mobile device may connect and disconnect dynamically to (mostly) wireless networks, which in general expose a more unstable behaviour in terms of variation of available bandwidth and delay than their fixed counterparts. In addition, wireless networks occasionally may not even be available at all for short periods of time (when the device's owner is driving through a tunnel, for example).

Therefore, not only the system software but also the user experience side of the application should be conceived to face the dynamicity of the infrastructure (deciding, for example, what happens to the user when (s)he gets disconnected).


The limited processing power (usually 400 MHz), memory space (usually 64 Mb), and bandwidth constraints discussed above impose on developers of mobile applications the need for a strong separation of concerns, and in particular a clear distinction between the presentation logic - managing user interaction and the data (dis)play - and the "business logic – interpreting the request of data and services from the presentation level, executing the data retrieval operations, sending the required elements to the presentation level. The computational load of a mobile device can be strongly reduced if it is responsible for the presentation logic only, and business logic processes are instead delegated to a server. Moreover, this separation allows sharing and reusing of both data and business components.

The two core approaches to mobile applications development are the Thin Client and the Thick Client Application Development (

The first approach, also known as browser-based, uses mark-up languages such as WML or HTML for content and interactions (uses HTTP to communicate with a server). Main pros of this approach are independence from the devices' capabilities (it only requires a mobile browser), ease of creating and updating thin-client applications (with centralized code, everyone gets the latest release and accesses the same database of content) and the speed of development time. Its main cons are an inability to handle rich graphics and an increase in maintenance costs (due to the difficulty of separating presentation logic from business logic).

The Thick Client approach is broadly structured into three sub-approaches: i) Native application development, ii) Smart Client application development, iii) Mobile Application Framework.

Native applications are developed to address specific operating systems (OS) such as Palm OS or Windows CE. The native solutions tightly integrate with proprietary systems, either directly from a native application or indirectly tthrough an application server. The main disadvantage of this approach is that each application depends on the operating system of the device. Still, it is a powerful approach to develop high performance applications (e.g. games) and applications that need sophisticated control of the hardware of the mobile device (e.g. drivers).

Smart Client Application development utilizes a single application suite (e.g. Java 2 Mobile Edition) to control business and presentation logic, and delivers content specific to each mobile device. This approach enables the development of applications that provide rich user interfaces - since they are not limited by the capabilities of mobile browsers, they utilize local processing power, and they support both on-line and offline scenarios. In this respect, Smart Client Application development overcomes the resource constraints of devices, thereby, allowing the best of both thin and native clients.

Mobile Application Framework, also known as Wireless Middleware (built on open standards like Java), provides a development platform explicitly devoted to propagating the organization's mission critical applications on to multiple devices and channels. The platform tightly integrates with an enterprise application server, and exploits smart client devices so that any change in the enterprise application is directly updated on the client device. The main con of this approach is the extensive technical and management support needed to adopt it. Its claimed pros are the possibility to extend existing applications for multiple devices, the ability to work offline or execute the application logic on the mobile, and the possibility of developing highly customizable and scalable applications (reducing development time and costs for large scale applications).

User Scenarios

In origin, the notion of channel was related to a mere technological consideration: a channel was regarded as the device being used for an application (e.g., a PC, a palm-held device, a 3rd generation phone …) plus the overall infrastructure behind it (i.e. the connection network and the services supported). The difference between a standard TV set or satellite TV or interactive TV does not lie with the device (always a TV set), but with the services (due to the infrastructure) that can be accessed.

Recently, the notion of channel has taken a different, wider and more conceptual meaning. A channel is better understood (and defined) in terms of the context rather in its strictly technological definition:

Context is any information that can be used to characterize the situation of an entity. An entity is a person, place, or object that is considered relevant to the interaction between a user and an application, including the user and applications themselves

(Dey, 2001).

Thus the context is anything related to the who, when, why, how characteristics of a computer mediated experience, and includes a wide spectrum of elements to be considered (Dey, 2001; Dey & Abowd, 2000; Brown et al., 1997; Abowd et al., 1998). In this wider view of channel, the technological characteristics of a device and its underlying infrastructure are still important, since they define constraints and limitations on several factors (as discussed in the previous section) but they do not necessarily represent the main driving force for setting the requirements that ultimately influence the design of a multichannel experience.

To be concrete, here is a realistic example. Let us assume that a city (say, in Southern Italy) has created the content for a cultural (tourist-oriented) guide to its territory, including an overall introduction to the area, minor cultural elements, two important museums and one archaeological park. The content could be delivered via Web, or via a palmtop (possibly equipped with GPS, in order to locate its position).

Let us examine the stationary (Web application) application first.

  • Assume that, as with many applications of this kind, the goal is to provide cultural tips and 'stories', in order to attract visitors, or, at least, to make the territory known to a wider audience.
  • The application is expected to be "consumed", in front of a PC or a laptop. During the use of the application, no other stimulus is reaching the user, in the sense that no other information is provided beside what the computer delivers.
  • The screen is reasonably large and the multimedia can be of excellent quality (according to current standards, at least); a large keyboard and a pointing device can be used.
  • We can presume that the user will "use" the application either before going for a visit (in Southern Italy) or after having been there. It is very unlikely that the application would be used during the trip, and certainly not while in a museum or an archaeological park.
  • The goals for the user could be to decide whether to go for a visit; to decide what to focus on in the case of an actual visit; to organize the visit from a practical point of view, etc.

Let us examine, now, a possible palmtop application, useful for guiding the user within a museum (or the archaeological park):

  • The user is not sitting, looking at the device, but walking around.
  • The main concern of the user is looking at the objects in the museum, not at the device; the device is supporting the visit, it is not the essence of the visit. We are in a situation of real-virtual contiguity - the real experience and the digital experience are interplayed - and of enhanced reality - the device is strengthening the quality of the visit (while on the Web, the application IS the –virtual- visit).
  • The screen is small; the keystrokes are clumsy; multimedia features are poor; audio is probably the most important medium.
  • The user activates the device during the visit (not before or afterward).
  • The main goal, for the user, is probably to better understand what (s)he is looking at; an additional goal could be also to look for practical directions for (short-term) planning of the remaining of the visit.

Let us examine, now, an additional possible palmtop (with GPS) application, useful for guiding users while driving the car in the territory:

  • The drivers (hopefully) do not look at the screen, or if so, only occasionally.
  • The users may get hints about what to look at; suggestions about where to stop, information or stories about the areas they are passing by, suggestions about nearby interesting spots, etc.
  • We are in a situation of "enhanced" reality, since the users (besides possibly driving) manage two inputs: i.e. the real world they are looking at and the interactive application.

The above scenarios show what multichannel applications are about: reusing the same content, for different purposes and for different contexts of use. Therefore designers must take into account, above all, what the different contexts imply for the users (in terms of user motivations and goals) and only later take into considerations the technical limitations. If a palmtop application, for example, is designed by "shrinking" down a Web application, something will be wrong: the user does not want to look at the (small) screen of the device while moving in the museum! The enhanced reality aspect would be missing.

We wonder now if we should consider the three above applications, as being three distinct ones, or we should rather consider them as interoperable components of a common integrated service. In this paper we argue for the second approach: we consider the three applications as a single multichannel application, made available to the user in different versions according to the different situations of use. In the following section, we discuss the implications, for the user, of this approach, analysing more precisely the concept of interoperability, i.e., an operational interconnection among the different applications.


If we examine the interrelationships among the different device specific versions of a multichannel application, regarded as declinations of the same service, we can identify a set of possible requirements, at different degrees of complexity. They are discussed from the simplest to the most difficult.

Content Sharing And Repurposing

Something useful both for users and developers is to maximize the reuse of content. From the developer's point of view, the goal is to reduce costs and time by exploiting the same digital resources (which may have required a significant authoring effort) in multiple ways. From the users' point of view, there is the need of continuity: if they have seen a picture on the Web, and read a comment about it on the Web, they reasonably expect a similar picture and a similar comment on the palmtop. They would be rather confused otherwise.

The key point (and the difficult part) is that "similar" means "in essence" the same but not exactly the same, because of both technical limitations of the device and the different requirements of the context of use. In general, contents must be modified (technically and conceptually) in order to make them suitable for the different channels. We refer to this process as to repurposing. Let us discuss this concept for the different types of media.


It is obvious that a long text is not appropriate for a mobile device screen, since it would require too much scrolling to be read. Thus, long text should be shortened or split in parts (see also "Navigation sharing and repurposing"). But it would be probably more appropriate to substitute an audio file for a long text: we would like the user to look at objects while on-site, rather than at screens. If in principle the audio file can be automatically generated from the text, the results may be of poor quality – a text conceived for being read is different from text conceived for being heard. The best solution, in the end, probably will be to write a small audio script from scratch.


For technical limitations - screen size, infrastructure performance – the role of "large image" pictures should be re-thought on mobile devices. While looking at a big picture (e.g., of a painting) on the Web can enhance users' emotions, during a museum visit the true emotion should be provided by the real painting. If details (of the painting) are really important for the users both on stationary mode and during the on site visit, zoomed pictures may be effective on the Web, while something else should be tried with mobile devices, as we will discuss in  "Content Complement".

Time-based media

Time-based resources such as video, animation, and interactive 3D, which may represent appealing features in a stationary application, are technically demanding (in terms of bandwidth and processing power) and should be carefully reconsidered in a mobile device. As we discussed for big pictures, the matter is all about utility for the actual situation of use. For example, 3D interactive representations of museum building(s), of the rooms and the ways works are exhibited on the walls, can be engaging for the stationary Web user in a context far apart from the physical museum, but are probably of no interest for a visitor who is in the museum and can look at the arrangement of works. On site, the same representations simply do not provide any added value to the real experience. In contrast, 3D virtual reconstructions of an archaeological site can be engaging both on a stationary and a mobile version. On the mobile, in particular, they can amplify the users' emotion of being on-site and improve their understanding of the place. Similarly, a video presenting an interview with the creator of a painting (Samis, 2001) might be more catching for mobile users in front of a painting than during a remote, stationary session of use, and would justify a temporary distraction from viewing the painting.

Audio can be offered relatively easily in both stationary and mobile devices; thus here the design trade-offs are essentially user-needs driven. Statistically, audio has limited use in stationary applications (unless there are explicit requirements related to a specific application domain, or to accessibility needs, as discussed in the last section of this paper) – perhaps simply because it is noisy and may prevent the use of the application in multi-user physical contexts. In contrast, speech should have a stronger role in the mobile version, as we discuss below.

Content Complementing

If some pieces of existing content developed for stationary applications must be modified or omitted from the mobile versions, others typically need to be created ad hoc: again because of the specificity of the situation of use, each different context may need specific pieces of content only relevant to it.

Consider, for example, a palmtop version within a museum. Orientation content must probably be added, in order to help the user to move within each room and across the rooms. In addition, information about the number of pieces in the different rooms, the estimated time of visit for each room, or the duration of a guided tour (see figure 1 in Munch-Mobile) etc. are useful pieces of information. This content, completely useless for the Web, will enhance the quality of the application for the palmtop.

Screen Shot: Content complementing

Fig 1: Content complementing from Munch-Mobile

Similarly, audio should be introduced in the mobile version, even if missing in the stationary one (Wilson, 2004). This medium has limited performance requirements; it is non intrusive with regard to the physical experience, and is something the user is very familiar with. Audio guides have been around in CH institutions for a long time, and, when well designed, have proven their effectiveness for conveying cultural information to visitors and for improving their learning experience. Audio is also an ideal way to convey information about the use of the application (e.g., to explain to the user the meaning of the various interaction elements, or to give help if needed) without requiring any lay-out space.

Navigation Sharing And Repurposing

The navigation structures should be partially re-designed for the mobile version, and not only because of the limitations imposed by the screen and of the pointing devices on the number and position of the navigation elements (as discussed in section "Technological Perspective"). As a result of content repurposing and complementing, content structures may change, and navigation paths must change accordingly. For example, a content piece that fits in a single page on a stationary device and needs to be split in several components on the mobile, must be connected by proper ad hoc navigation links (see figure 2, which highlights that a single screen presentation of an artwork - Munch's print The Sick Child - on a stationary Web application has been split in two screens on the mobile version).

Screen Shot: An Artwork object

Fig 2: An Artwork object displayed on the stationary application (a) and on the mobile version (b and c).

In addition, the grouping criteria can be different in the mobile and stationary versions. In a mobile application for a large fine arts museum, for example, "visit duration" and "physical vicinity" can be meaningful criteria to collect groups of paining for an on site guided tours, while they do not make much sense for a virtual guided tour on the stationary Web version. The collection of highlights should collect the "best" paintings that are physically exhibited on site at the time of the visit, not the best of those  belonging to the museum.

In some cases, the navigation patterns (Garzotto et al., 1999) adopted for the stationary version should be modified when going mobile. Due to the characteristics of the pointing devices, which support traversal and horizontal scrolling more efficiently than random selection, index navigation (i.e., direct pick-up of an item in a list) should be replaced by (or at least integrated with) guided tour navigation (back-and-forth sequential scanning). Finally, the state of a composite multimedia object is accessed during navigation - i.e., the component that is first (dis)played when the object is retrieved, may differ in the stationary and mobile versions. On a stationary application, when users have access to, say, a painting, they are typically presented with a combination of text and image; audio, video, or 3D elements are retrieved by effect of further explicit user demand. In contrast, when a painting must be shown to the user on the mobile version, we can assume that the user is in front of the real object. Thus the audio is the first piece of content to deliver information about the specific painting. Who, standing in front of a painting, would prefer to look at an explanatory side panel rather than admire that artwork face-to-face while listening to an audio explanation in the meantime?

Supporting Cross-Channel "Workflows"

Let us imagine users with the Web application at home. They may decide where to go in the territory, and "mark" specific points of interest, e.g., selecting the museums to visit and the more interesting works within each museum. Or they may specify a personal cultural profile and ask the system to propose the most appropriate items to explore.

While using the palmtop version in the car or inside a museum, the same users would like to exploit the "customization" carried on at home: they expect to easily access (or to be prompted with) the pre-packaged list of topics (s) selected, or with the system-defined proposals more suitable to their profiles.

Things may go also the other way around: uses with the palmtop can select the works that were more impressive for them during the visit (eventually adding short comments and annotations). Later, at home, they may look at the Web application, and may re-view these selected works in detail, for in-depth understanding.

Location Awareness

Location awareness (i.e. the "knowledge" about where the device is currently located) introduces a new variable to be considered in a multichannel application, and raises a number of new design issues.

Location Accuracy

As discussed in the section "Technological Perspective", today's technology can detect the user' physical "location" at many different degrees of "accuracy" (Moran & Dourish, 2001; Schilit et al., 1994; Sumi et al., 1998), ranging from 100 to 0.3 meters (up to the level of detecting also the device orientation).

The question "What is the most appropriate accuracy for my application?" does not have a general answer. It depends on the nature of the specific application and on the situation of use. If, for example, the user is in a museum, the application should probably know the room where the user is located (as in Munch Mobile, see figure 3), and perhaps even the corner of the room. The "best" location precision is determined by the capability of the application to make use of  position data in order to provide the user with the "best" information needed.

Screen Shot: Detecting the user's room

Fig 3: Detecting the user's room in Munch-Mobile

During car-based exploration of a large region, for example, users are probably interested to know where they are located on a map and where they can find other interesting areas in the range of 1-10 kilometres. In an urban zone, driving users probably need to know, beside their current position on a map, the position of the major nearby "places" to visits (museums, big monuments, churches, etc.) - those ones that can be reached in 1-2 minutes of driving. In these situations, a mobile device needs to know only "approximately" where the user is located, and the positioning accuracy ranges between a kilometre (large region exploration) to 50-100 meters (urban area).

In the context of pedestrian navigation, users focus on close, finer grained "objects" (buildings, squares, monuments, but also wall inscriptions, statues, building glasses, etc.…). Here the accuracy demand increases to values of at least 25 meters. Finally, indoor use of a context-aware device may require (less than) 2 meter of accuracy, since the user focus is the "room" where (s)he is located, the artwork (s)he exhibited that, or even the object (s)he is looking at. Thus the accuracy must be less than 1 meter, in some cases taking into account also the orientation of the device (as in Salmon et al., 2004).

Localization And User Control

In a non-location-aware application, the user is in control of what is presented on the device: the content is (dis)played in response to the user's explicit requests for information, or of the user's interactions with interface elements (e.g., navigation buttons).

In contrast, in a location-aware device, the application can take control and push information to the screen in response to changes in the user's current position. The user is offered the possibility of indirectly controlling the application's behaviour through movements in the physical space.

Different degrees of interplay can be conceived between these two control paradigms - direct user control vs. location-mediated control - and their emphasis on one and other is, once again, a matter of interpreting user needs in the specific situations of use:

  • Location-mediated control is offered (and, consequently direct user control is excluded). This means that if the context-aware mechanism is "enabled", the user has no direct control of the information provided by the application, which is automatically delivered on the mobile device according to the user's current position. For example, the museum visitor can "consume" (see, hear, virtually manipulate) only the objects in the current room proposed by the device, or the objects being looked at (if the device is orientation sensitive). There is no way to get any information that is not associated, at design time, to the current context but is still related, (and might be of interest for the user: e.g., about the painters). This solution has advantages for technologically timid users, or "couch potatoes", who can stay totally passive and relaxed. It has disadvantages for bright users, whose curiosity may be unsatisfied. Both types of users may be seriously frustrated if for any reason the location-detection control does not work: they will feel trapped, getting no information at all.
  • Both mechanisms (i.e. direct user control and. location-mediated control) are offered, but they are mutually exclusive. This means that the user interested in something related to the resources being receiving on the device can take  control and navigate to (or query for) the needed information, and the location-awareness turns off until it is explicitly re-set by the user. This approach has the advantage that the user feels more in control, but the disadvantage that the user must also understand who is in control at any time (user or the device) and know how to switch location-awareness off and on. Switching mechanisms can be explicit (e.g., "off/on" buttons on the screen) or implicit (e.g., location awareness turns off when the user selects any link to an object outside the current location) and must be carefully designed to avoid usability problems.
  • The two mechanisms coexist. This means that users interested in some content information corresponding to their position in the physical space can navigate in the virtual space and access the wanted information without closing the location-awareness. This is conceptually "suspended", and takes control back as it detects a change in the users' position. This approach requires careful design of the location model and of the granularity of the content structures associated to the different positions. It can be implemented if the location model is not excessively fine-grained, so that users can perform small movements while navigating in the virtual space without updating  their positions in the representation of the world maintained by the system. Any physical movement which is interpreted as a "position change" would abruptly cause a replacement of the "current object" a user is consuming with new location-aware information – introducing obvious disorientation effects.

Localization And Time-Based Media

In a location-aware application providing time-based media (e.g., speech, music, animation, video), we can associate a concept of "state" to three types of "entities":

  • the moving user:  state, for the purposes of our discourse, is the system representation of his(her) position in the physical space;
  • the application: state is determined by the information currently (dis)played on the device;
  • the time-based information elements:  state of an element of this type, when "active", is the amount of time being played.

Clearly, the minimum prerequisite for a sound location-aware behaviour is that any information item (dis)played at any point of time on the device is semantically coherent with the user state, unless the location-aware mechanism is temporary suspended (as discussed above in section "Location and user control".) For example, a map "always" shows the user's current position, and possibly orientation or direction of movement.

While for static media the concept of semantic coherence is straightforward, the same is less obvious for time-based, dynamic media. What should happen when the user changes position while seeing or listening to a video or audio stream? In principle, both synchronous and asynchronous behaviours may be appropriate. A synchronous solution means that the information presented to the user is "immediately" (up to minimum performance delays) updated according to the user's current state, and the video or audio is replaced by  information corresponding to the new position, no matter if these are still running. An asynchronous solution means that the time-based medium keeps playing till its end (unless the user explicitly stops it) before being replaced by information corresponding to the user's new position. Selecting between these two approaches depends on several aspects, e.g., the position model adopted by the system, the duration of time-based media and their semantic relevance for the on-site user experience. From a usability perspective, what is important is that the chosen strategy is applied consistently in the whole mobile application, and that system behaviour is evident to the user. Skilled users may also like to be in control of switching among synchronous and asynchronous behaviours depending on their needs.


Accessibility means allowing users with disabilities to access interactive applications. The issues at stake (Di Blas et al., 2003; Di Blas et al., 2004; Hofstader, 2004) concern content in the strict sense (since difficulty in using one or more senses determines which media can be used), design (overall organization of the application), interface and interaction design. If the accessibility issues for Web applications are basically understood (although viable and final solutions are yet to come), new issues arise when we consider mobile applications: the new feature is related to the notion of "enhanced reality" as discussed in previous sections. We must consider, in fact, what the overall situation of users with disabilities is, and their motivations.

Let us consider, for example blind users: if using a Web application, motivation is similar to the motivation of regular users. The goal for both is to understand what the territory can offer: what is available in the museum, what is important about the archaeological park, etc. If using mobile applications, the two types of users have quite different motivations: regular users, in fact, are in a situation of enhanced reality, and they combine the effect of "looking around" with the input of the application (that must reinforce the "real" input, rather than replace it). The interactive application is expected to provide a "commentary" to the application, rather than an alternative to it. For blind users, the interactive application must play a double role: to "describe" the reality, and then to convey the commentary. If, for example, the mobile application has an historical introduction to object #56, the same application for a blind user must describe the object first, and only afterward can it provide the historical introduction.

The crucial point is that since mobile applications work in a situation of enhanced reality and since disabled users have a different perception of reality, mobile applications need to be adjusted in their very requirements, not just in the technical details.

In addition, even more than for Web applications, different disabilities need different sets of requirements, since the relationship between the users and the reality is different.

Conclusions and Future Work

We think that multichannel applications represent a new challenge with respect to traditional Web applications, and that more research and experimental work is need.

We are facing a number of new challenges:

  • Enhanced reality: the user must coordinate perception of the real world with the input from the interactive application. Both inputs must be effective (with the one from the "real world" probably prevailing over the one from the application). We still need to better understand requirements, and then design principles.
  • Interactive audio: as we have argued in this paper, when mobile devices are used, audio becomes the most important medium. We still do not have good design practices for developing sophisticated interactive "audio-based" applications: audio guides have simplistic structures, while Web applications are too visual.
  • Groups of applications: we think that, from the user point of view, different applications concerning the same content must be perceived as ONE SERVICE delivered over several channels, rather than as a bunch of loosely coupled services. Again we need to better understand requirements and design principles.
  • Interoperability: we must provide users with ways to perform operations (e.g. the creation of "shopping bags" of interesting items) across the different channels. Requirements, design and technology are at stake.

Our research effort is basically pragmatic: working on real applications while trying to build an overall conceptual framework where different options can be accommodated.

After a number of lab experiments have been completed (e.g. moving the Munch application to a palmtop), two specific test beds are being launched: each of them concerns cultural support for a visit in two regions in southern Italy (Campania and Puglia), combining Web applications with mobile ones.


Abowd, G. D., A.K. Dey, R.J. Orr  & J. Brotherton (1998). Context-awareness in Wearable and Ubiquitous Computing. Virtual Reality Society International Journal, 3, 200-211.

Abowd, G. D., C.G. Atkeson, J. Hong, S. Long, R. Kooper. & M. Pinkerton (1997). Cyberguide: A Mobile Context-Aware Tour Guide. Wireless Networks, 3(5), 421-433, 1997.

Brown, P.J., J.D. Bovey & C. Xian (1997). Context-Aware Applications: from the Laboratory to the Marketplace. IEEE Personal Communication, 4(5), 58 -64, October 1997.

Davies, N., K. Mitchell, K. Cheverst  & A. Friaday (1999). Caches in the Air: Disseminating Tourist Information in the Guide System. In Proceedings of the 2nd IEEE Workshop on Mobile Computing Systems and Applications, New Orleans, USA, 11-19.

Dey, A. K. (2001). Understanding and Using Context. Personal Ubiquitous Computing, Vol. 5, No. 1. (February 2001), pp. 4-7.

Dey, A.K. & G. D. Abowd (2000). Towards a Better Understanding of Context and Context-Awareness. CHI 2000 Workshop on the What, Who, Where, When, and How of Context-Awareness, 2000.

Di Blas, N., A. Capodieci, P. Paolini  & M. Speroni (2004). Enhancing accessibility for visually impaired users: the Munch exhibition. In David Bearman and Jennifer Trant (eds.). Museums and the Web 2004: Proceedings. Toronto: Archives & Museum Informatics, 2004. Available:

Di Blas, N., P. Paolini  & M. Speroni (2003). Listen to a Web site: accessibility (beyond current standards) and a market opportunity. In Proceedings of the Conference ICHIM03, Paris, 2003.

Garzotto, F., P. Paolini, D. Bolchini  & S. Valenti (1999). "Modeling by patterns" of Web Applications, In Proceedings of the International workshop on the World-Wide Web and Conceptual Modelling , WWWCM'99, Paris, 293-306.

Hofstader, C. (2004). Internet accessibility: beyond disability. IEEE Computer, 37(9), 103 – 105.

Longoria, R. (2001). Designing mobile applications: challenges, methodologies, and lessons learned. In Proceedings of HCI- 2001, New Orleans, Louisiana, August 2001, 5-10.

Moran, T. P. & P. Dourish (2001). Introduction to Special Issue on Context-Aware Computing. Human-Computer Interaction, 16 (2-4): 87-94, 2001.

Paelke, V., C. Reimann  & W. Rosenbach (2003). A visualization design repository for mobile devices. AFRIGRAPH '03: Proceedings of the 2nd international conference on Computer graphics, virtual Reality, visualisation and interaction in Africa, 57—62.

Peddemors, A., H. Zandbelt  & M. Bargh (2004). A mechanism for host mobility management supporting application awareness. MobiSYS '04: Proceedings of the 2nd international conference on Mobile systems, applications, and services. Boston, MA, USA, 231—244.

Ryan, N. S., (2002). Back to Reality: Augmented Reality from Field Survey to Tourist Guide. In F. Niccolucci (ed.), Virtual Archaeology, proceedings of the VAST EuroConference, Arezzo, Italy, November 24–25, 2000, 45-52, Archaeopress, Oxford, 2002

Salmon, Cinotti T., G. Raffa, L. Roffia, F. Garzotto , R. Muzii, V. Varlese, M. Malavasi & S. Galasso (2004). Evaluating Context-aware Mobile Applications in Museums: Experiences from the MUSE project. In David Bearman and Jennifer Trant (eds.). Museums and the Web 2004: Proceedings. Archives & Museum Informatics, 2004. Available:

Samis, P. (2001). Points of Departure: Integrating Technology into the Galleries of Tomorrow. In D. Bearman and F. Garzotto (Eds.) International Cultural Heritage Informatics Meeting, Full Papers ICHIM01. Milano: Politecnico di Milano and Archives & Museum Informatics. 623-637

Schilit, B. N., N.I. Adams  & R. Want (1994). Context-Aware Computing Applications. In IEEE Workshop on Mobile Computing Systems and Applications, Santa Cruz, CA, December 1994, 85-90.

Spasojevic, M. & T. Kindberg (2001). A study of an Augmented Museum Experience, HP Laboratories, Palo Alto, July 2001. Availa ble:

Sumi, Y., T. Etani, S. Fels, N. Simone, K. Kobayashi, & K. Mase (1998). C-MAP: Building a Context-Aware Mobile Assistant for Exhibition Tours. Social Interaction and Communityware, Kyoto, Japan, LNCS 1519, 137-154.

Vlahakis, V., A. Demiris, E. Bounos & N. Ioannidis (2004). A novel Approach to Context-Sensitive Guided e-Tours in Cultural Sites: "Light" Augmented Reality on PDAs. In Chrysanthou, Y., Cain, K., Silberman, N. and Niccolucci, F. (eds), VAST 2004, 5th International Symposium on Virtual Reality, Archaeology and Intelligent Cultural Heritage, December 2004.

Wilson, G. (2004). Multimedia Tour Program at Tate Modern. In  David Bearman and Jennifer Trant (eds.). Museums and the Web 2004: Proceedings. Archives & Museum Informatics, 2004. 99-109. also available:

Cite as:

Colazzo, S., F. Garzotto and P. Paolini, Let's Go Mobile! Design Issues In Multichannel "Accessible" Applications For Cultural Heritage, in J. Trant and D. Bearman (eds.). Museums and the Web 2005: Proceedings, Toronto: Archives & Museum Informatics, published March 31, 2005 at