Keywords

1 Introduction

The pervasiveness of mobile devices and the constant evolution of the sensors shipped within them has led to a constantly increasing number of mobile applications for navigation and positioning during the latest years. The Global Positioning System (GPS) technology is extensively used when it comes to outdoor environments. GPS-based navigation apps such as Google Maps [7] have become extremely popular and are now considered essential utilities on every smartphone, moreover, mapping and localization platforms such as those provided by Google offer services than can be easily integrated by developers in any mobile application. From food delivery to real estate services, many popular mobile apps include georeferenced maps as part of their functionalities or simply to provide better user experience.

Indoor localization systems cannot rely on GPS, and require ad hoc hardware infrastructures and positioning techniques tailored on the physical characteristics of the target environment (such as thickness and geometry of the walls). Thanks to the constant evolution of such technologies, mobile applications for indoor localization are growing more and more popular [19, 21]. Wi-Fi, Radio-frequency identification (RFID), Bluetooth Low Energy (BLE) and Ultra Wide Band (UWB) [3, 15, 24], possibly combined in hybrid systems [13], are among the most popular infrastructures adopted.

Context-aware mobile apps for indoor navigation have their main application fields in the Internet of Things (IoT) and Smart Cities projects, and have proven to be effective assistive solutions for persons with visual impairments [2, 8, 15, 20], as means of increasing social inclusion and autonomy. While visiting an indoor or outdoor environment, visually impaired users should be able to rely upon a navigation app in order to get information about their actual position, route planning, and accessibility warnings. This would enable them to get to a specific place in the safest and more effective way.

Navigation apps, anyway, are also an effective means to help visually impaired users build a mental representation (aka “cognitive map”) of a specific environment. This is particularly important in a training phase, i.e. before physically accessing an unknown or rarely visited place [12].

Many studies exist that describe indoor positioning and tracking solutions based on different technologies, mainly focused on how to develop effective wayfinding strategies and build robust infrastructures that minimize localization errors [14, 22, 26] scarce attention, anyway, is dedicated to issues related to the design of an effective user experience, and to the aspects of presentation and personalization of the information. Studies focused on technologies that support mobility for users with visual impairments outline the strategies adopted to improve user interactions without providing detailed description of the design [2, 20].

Guerreiro et Al. [8] conducted a survey with two focus groups of visually impaired users to assess common interaction issues encountered with an indoor navigation app; their findings show that, besides ad hoc strategies to convey information such as the haptic and audio channel, each user has their own peculiar needs (e.g., interaction ways vary whether they use a white-cane or a guide-dog). Finally, Wang et Al. [25] investigated the ways users cope with indoor wayfinding, and found out it is affected by their age and gender.

In this paper, we will focus our attention on the concept of personalization applied to the user experience as well as to the quality of the delivered information. We will describe a context-aware model for a mobile indoor positioning system, which leverages user’s needs and preferences to build a personalized conceptual view of the physical space, while at the same time providing information tailored upon the user’s interests and specific needs.

2 Two User Scenarios

In order to clarify the concept of personalization introduced in the previous section, we describe two user scenarios for an app to guide visitors through a museum.

2.1 User Scenario 1: Senior Experienced User

Anna, a 75-year-old retired teacher, loves art and regularly visits exhibitions and museums. Anna is used to deepen the knowledge of the works of art that most strike her, but she has some vision problems, and sometimes it is tiring for her to read captions and booklets provided by cultural institutions. She would be glad to have a mobile application to get the most from her visits; she would in particular appreciate an app that provided her with extra contents in a downloadable format, in order to learn more about the artworks when she gets home. Moreover, she would find it very handy if the app provided a functionality to render real-time captions in an accessible format for persons with vision problems. Such a functionality may show a caption as every piece of art is approached; captions should be rendered on the device’s screen in large, high contrast fonts.

2.2 User Scenario 2: Young Non-experienced User with Visual Impairment

Ben is a 20-year-old student. He is visually impaired and a white cane user. Ben rarely visits museums; he is not an art enthusiast, but he is a curious person and likes to explore new places. On such occasions, one of his main concerns is to find suitable routes for visually impaired visitors. He would appreciate a mobile application that helped him with this task by signaling areas that pose accessibility issues. He is not interested in having a deep insight of the pieces of art exposed, anyway, he would like if the app provided, for each artwork, an audio file containing its title and a short description.

These user scenarios highlight that the level of interest/experience of a user in a given environment (e.g. their attitude towards museum visits) shapes the amount and quality of information that the app provides them. On the other hand, possible special needs could hinder not only the physical exploration of the space (as in the case of mobility issues), but also the user experience with the app itself (as in the case of visual impairments). Disability issues must be hence kept into account by developers both when designing the user interfaces and when deciding which kind of information should be conveyed to users.

In our architecture, the problem of tailoring the information content is delegated to a backend service, that is responsible for recognizing the proper piece of information, associating it to the correct format, and returning it to the app for presentation. The mobile app will hence be responsible for issuing notifications related to the presence of POIs and rendering the information obtained by the backend service; potential users’ disabilities, such as visual impairments, must be taken into account in the design of the user interfaces and, more broadly, of the user experience.

3 Architecture Overview

The first requirement for an indoor positioning system is to make users aware of relevant places or objects in the surrounding space, known as Points of Interest (POIs). Our architecture is meant to be generalizable with respect to the hardware adopted for the positioning, anyway, in order to develop our model, we assumed to rely on an infrastructure based on BLE transmitters (AKA beacons), in which each POI is signaled by a beacon via its unique identifier (UID), that is broadcast to every Bluetooth-enabled device. BLE beacons benefit of ease of installation, low power consumption and fair localization accuracy [8, 9]. This has led to a wide diffusion of such transmitters in public urban areas and buildings, which makes it also possible to rely on pre-existing BLE infrastructures to develop positioning applications for different purposes.

Figure 1 shows an overview of our architecture, which is based on a service-oriented approach [11]. The navigation system’s front-end for the user is provided by a mobile application; as soon as the app receives the UID from a beacon, it will issue a request to a RESTful web service, notify the user and present the retrieved information. Data exposed by the REST are created and modified via a web application which enables operators to translate the physical environment into logical entities; it in fact enables operators, among other functionalities, to search through the installed beacons, associate a beacon to a POI and define its information content. A dedicated server is also present, which will be queried by the app to fetch maps of the surrounding environment, or of parts of it.

Fig. 1.
figure 1

An overview of the architecture.

Full size image

4 Mapping Physical Entities to a Logical Model

Indoor localization systems are typically adopted to guide users through complex indoor environments (such as hospitals or airports, museums), as well as restricted outdoor areas such as university campuses; parks or cultural sites. Information related to POIs may be of varying degrees of complexity, depending on the context and the purpose for which the system is conceived. For instance, a mobile app that guides visitors through museums and exhibitions will not only provide navigation hints, but also detailed information about specific objects in the environment recognized as artworks. A POI must be hence associated to a type, which identifies its function; a typical POI may be an ATM, an artwork or a physical barrier which is relevant from an accessibility point of view [6]. Figure 2 shows the class diagram of our model, which is directly related to the well-known concept of Building Information Management (BIM) modelling [16]. A BIM model provides a thorough description of a building in terms of its structural elements (via CAD mappings) and allows to describe functional properties and relationships between those elements, as if they were database records. An example of an open-source BIM modelling tool is the indoor map editor provided by the OpenStreetMap (OSM) project, in which basic entities that may be given a meaning by means of attributes named “tags” [17, 18]. The figure shows how the objects in our model are related each other and categorized.

Fig. 2.
figure 2

A class diagram that describes the key entities of our model and how they are related.

Full size image

The Beacon class contains the coordinates of the transmitting device and its unique identifier; a POI is related to just one beacon via the UID, while a Type object describes the purpose of the POI itself. Furthermore, a POI is related to the surrounding environment via the Context class, which assigns a specific purpose to a portion of environment (a shop, a ticket office, a museum’s room, etc.). Finally, the Environment class describes the highest hierarchical entity in the model; it semantically identifies the indoor environment according to its wider function, which may be a railway station, a museum, a shopping mall, etc.

Figure 3 shows how POIs are related to other entities in our model according to our database schema. It highlights the relationship between a particular spatial context and the types of POIs it can contain. It also shows that additional complex information can be associated with a POI via an XML document, namely the info_content field.

Fig. 3.
figure 3

The DB schema for the tables related to POIs in our model.

Full size image

4.1 Accessibility and Personalization

Every user has their own preferences, related to factors such as age, gender, and personal experiences and needs; moreover, possible impairments may hinder the accessibility of the mobile app for navigation and compromise the whole user experience [4]. Figure 4 shows how the User class translates into the Preferences section of an Android application developed as a front-end prototype for two different environments: a museum and a railway station. User interfaces (UIs) in the figure were designed in order to avoid accessibility issues (e.g. default Android preferences widgets were avoided since they were based on pop-ups). In order to guarantee a thorough accessible user experience, anyway, not only the mobile app must be properly designed, but also the backing services must assure to deliver the proper content [11].

In our model, we designed the AccessiblePOI class, a specialization of the POI class whose purpose is to identify a POI as accessible to a particular category of users with special needs and define special audio and haptic feedbacks to be issued by the mobile app contextually with the POI notification. AccessiblePOIs are the key entities upon which an accessible user experience of navigation can be built, since they make it possible to define routes in the surrounding space in which every accessible object or place is properly highlighted and notified. A flight of stairs or an elevator, for instance, should be considered as AccessiblePOIs, and consequently the mobile app should signal them much more clearly to visually impaired users than to others. Moreover, contents associated to these POIs may be adapted according to specific rendering needs, e.g. if a screen reader or a magnifier is used.

Fig. 4.
figure 4

The Preferences section of the mobile app as it appears in different environments: a museum and a railway station.

Full size image

Figure 5 shows the layout of a form to create a new POI via the back-end application; one of the beacons installed in the environment can be associated to the POI via a drop-down menu or by choosing one item on a map that shows also its coordinates. A section of the form is related to accessibility; it provides functionalities by which operators can define haptic or audio feedbacks associated to the POI and choose the categories of users with special needs which can benefit from this POI. For every POI object, structured content may be associated, that accounts for detailed information and additional content to be provided to users; this information is modelled via the structuredContent field of the POI class, associated to an XML document.

4.2 Structuring the Information Content

One of our main concerns was to provide each user with information tailored on their profile. In order to do so, each POI object was associated to an XML document containing exhaustive information about the point of interest, structured upon users’ features, such as language, age, expertise and special needs. A detailed description of the XML Schema designed for our model is beyond the scope of this paper and will be omitted for simplicity’s sake.

Fig. 5.
figure 5

Editing GUI for a new POI.

Full size image

Figure 6 shows a portion of an XML document associated to a POI; the root, i.e. the structuredContent element, is related to the POI type via an attribute (e.g. “artwork”) and contains a variable number of complexDescription children elements, each characterized by attributes related to customization, namely “language”, “age”, “expertise” and “accessibility”. Each complexDescription node contains a short descriptive text element (which will be used as. a caption for notifications issued by the navigation app), HTML content to be shown as a detailed description within the app, and a variable number of file elements, which refer to additional multimedia contents such as mp3 tracks of an audio-guide or pictures of a building’s entrances, and the relative descriptive metadata. XML is the data format of choice when it comes to working with structured data that can be presented differently. Depending on the request issued by the mobile app to the web service, it will respond with the proper information content extracted (and possibly transformed) from the whole document.

Back-end operators can add a new piece of structured content directly when creating a new POI (see Fig. 5). A wireframe of the user interface for creating and editing this kind of complex, structured information is shown in Fig. 7.

Fig. 6.
figure 6

Part of an XML file containing the structured description of a POI.

Full size image

Sample notifications issued by the mobile app are shown in Fig. 8; samples refer to different users for the same POI. The POI object of the model is responsible for the title of the notification and the vibration or audio hints (if any), via the description, sound (audio-hint) and vibration-pattern fields (see Fig. 2). The first refers to a young visually impaired user with a “beginner” level of expertise; the notification contains a short and clear text message (that will be read by the smartphone’s screen reader) and contains a play button that fires the playback of a descriptive audio file meant for a compatible target audience. The second notification, on the other hand, is addressed to a young experienced user with no disabilities; the caption shown in the system’s window is a long text. Tapping on the window will open a section of the app where detailed html formatted information will be displayed, together with additional multimedia contents, if any.

Fig. 7.
figure 7

The GUI for creating and updating structured content associated to a POI.

Full size image
Fig. 8.
figure 8

Notifications issued by the app depending on the user’s preferences.

Full size image

5 Conclusions and Future Work

We have presented the software architecture of a versatile system for indoor positioning and navigation, with samples of implementation. Our aim was to provide a software back-end which was reusable and highly configurable according to the physical structure of the environment, the context of use and the users’ needs and preferences, with particular attention to special features related to accessibility.

The data model and UIs designed for the system operators were conceived to make its configuration as intuitive as possible. Our architecture is generalizable, provided that each electronic device associated to a POI broadcasts a unique identifier; anyway, depending on the associated transmitter, a POI may broadcast richer information, such as data collected by sensors, or even a URL [23, 24] We are planning to provide the POI object with more optional fields as a consequence. We will also investigate more aspects related to accessibility for users with visual impairments; to this extent, we are planning to expand our architecture to include wearable technologies, such as haptic bracelets [5]. This would imply to enhance our backend model with more accessibility options, as such devices allow for more complex and semantically significant haptic hints.