An Indoor Navigation System for Reduced Mobility Users
Pedro Cardoso
1,2,3
, Ana Paula Cláudio
1,2 a
and Dulce Domingos
1,3 b
1
Faculdade de Ciências, Universidade de Lisboa, Portugal
2
BioISI - Biosystems & Integrative Sciences Institute, Lisboa, Portugal
3
LaSIGE - Large-Scale Informatic Systems Laboratory, Lisboa, Portugal
Keywords: Indoor Navigation, Reduced Mobility, Environment Barriers, Mobile Application.
Abstract: Indoor navigation systems help pedestrians to find the best paths inside buildings. Existing systems only re-
spond to the needs of reduced mobility users occasionally, by avoiding stairs. However, this is an obvious
requirement, unlike others that are almost invisible to people without restrictions. This paper presents the
results of the development steps of an indoor navigation system for reduced mobility users. In addition, we
systematize the relevant information about the indoor environment that must be gathered to instantiate the
requirements to a specific case. Finally, the paper overviews the developed prototype and describes its eval-
uation.
1 INTRODUCTION
Reduced mobility users demand additional require-
ments to indoor navigation systems, such as exclud-
ing stairs from calculated path (de Oliveira et al., 17).
However, problems reduced mobility users face go
beyond stairs and several barriers are almost invisible
to people without restrictions (Dzafic et al., 14).
In the last years, indoor navigation systems con-
tributions focus on solving two main problems: user
positioning and handling three dimensional (3D) en-
vironments. Global Positioning System (GPS) cannot
be used straightforward in indoor environments,
where its signal is generally not available (Gerstwei-
ler et al., 15). Due to this restriction, for indoor user
positioning, there are many proposals in the literature
that resort to smartphone functionalities, such as kin-
ematic techniques that use accelerometers and gyro-
scopes sensors (Pombinho et al., 11; Moder et al., 15),
visual techniques that use cameras (Koch et al., 14;
Carboni et al., 15; Deretey et al., 15; Gao et al., 16),
and wireless techniques (Fallah et al., 13; Jain et al.,
13; Koide and Kato, 05; Ozdenizci et al., 15; Matos
et al., 14; Faragher and Rice, 15).
Indoor navigation systems represent 3D environ-
ments, i.e., buildings with many floors with two di-
mensional or as 3D representations (Koide and Kato,
a
http://orcid.org/0000-0002-4594-8087
b
http://orcid.org/0000-0002-5829-2742
05; Thill et al., 11). Despite 3D representations can
provide more information, they need more storage
and processing.
In addition, performance problems are raised
when algorithms used to calculate best paths are ap-
plied in 3D environments. Bian et al. (2014) present
an approach that overcomes these performance issues
in 3D environments. These algorithms have also been
subject to adaptations to meet specific needs or pref-
erences of users (Fallah et al., 13; Koide and Kato, 05;
Akasaka and Onisawa, 08). In (Koide and Kato, 05)
and (Akasaka and Onisawa, 08), the authors already
address some specific needs of wheelchair users, cal-
culating paths that do not include stairs. However, as
stated before, avoiding stairs from calculated path is
just one (and an obvious one) requirement for reduced
mobility users. As far as we know, Dzafic et al.
(2014) present the widest work about wheelchair user
requirements for this kind of systems.
With the final goal of developing an indoor navi-
gation system for reduced mobility users, in this pa-
per, we start by focusing on the requirement analysis
phase of our work. Based mainly on the work of
Dazfic et al. and on the experience of one of the mem-
bers of our team who is a wheelchair user, we start by
eliciting customer oriented requirements (C-require-
ments) and then we detail developer requirements (D-
Cardoso, P., Cláudio, A. and Domingos, D.
An Indoor Navigation System for Reduced Mobility Users.
DOI: 10.5220/0008975302870298
In Proceedings of the 15th International Joint Conference on Computer Vision, Imaging and Computer Graphics Theory and Applications (VISIGRAPP 2020) - Volume 1: GRAPP, pages
287-298
ISBN: 978-989-758-402-2; ISSN: 2184-4321
Copyright
c
 2022 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved
287

requirements) associating them with each component
of the system: user positioning, path planning, repre-
sentation, and interaction. In addition, we systematize
the information about the indoor environment that
needs to be collected before developing its navigation
system. Finally, we also present the w4all, an indoor
navigation system for reduced mobility users, and its
evaluation phase that involved users with normal and
reduced mobility. A preliminary version of this work
can be found in (Cardoso et al., 16).
Next section presents related work, while Section
3 details the requirement analysis of indoor naviga-
tion systems for reduced mobility users. Section 4 de-
scribes the w4all prototype and Section 5 presents its
evaluation. Finally, last section ends with future re-
search directions and conclusions.
2 RELATED WORK
According to Fallah et al. (2013), an indoor naviga-
tion system can be organized in four components:
user localization (also named user positioning), path
planning, representation, and interaction. This section
presents the main challenges of each one of these
components and the corresponding contributions of
the state of the art.
2.1 User Positioning
The user positioning component is responsible for de-
termining user’s position. GPS, widely used to deter-
mine outdoor positions, is not adequate for indoor en-
vironments because its signal is generally not availa-
ble here (Gerstweiler et al., 15). Still being an open
research area, we can find many proposals in the lit-
erature for indoor positioning that take advantage of
smartphone functionalities, such as sensors (accel-
erometers and gyroscopes), cameras, and wireless
technologies (Koch et al., 14; Carboni et al., 15; Fal-
lah et al., 13; Jain et al., 13; Ozdenizci et al., 15). The
proposed positioning techniques can be grouped into
three different classes (Jain et al., 13): kinematic, vis-
ual, and wireless; which can be combined to enhance
position accuracy (Molina et al., 18; Torres-Sospedra
et al., 18).
Kinematic techniques estimate user positions
based on previously estimated or known positions by
using accelerometers and gyroscopes smartphone
sensors and dead reckoning algorithms (Pombinho et
al., 11; Moder et al., 15).
On the other hand, visual techniques determine
user position by comparing environment images cap-
tured with the smartphone camera with reference im-
ages stored in a database (Koch et al., 14; Deretey et
al., 15; Gao et al., 16). These reference images can be
encoded using, for instance, Barcodes or QR-Codes
(Carboni et al., 15).
Finally, wireless techniques calculate user posi-
tion resorting to light waves or radio waves. They can
be sub-grouped in direct sensing, triangulation, and
fingerprint techniques. The first ones (direct sensing)
use identifiers or tags previously installed in the envi-
ronment, supported by technologies such as RFID, In-
frared, Barcodes, or NFC (Fallah et al., 13; Jain et al.,
13; Koide and Kato, 05; Ozdenizci et al., 15). Indoor
triangulation techniques use Wi-Fi technology and
determine user position by triangulating the position
of access points (APs) through their signal strength,
as GPS does for outdoor positioning. Lastly, finger-
printing techniques calculates user position by com-
paring the signal strength that the user device receives
from APs with a pre-built fingerprint database (Matos
et al., 14; Faragher and Rice, 15).
Focusing on Wi-Fi based techniques, the ones we
use in the w4all system, they are convenient only if
there is a set of pre-installed dedicated APs, as they
are error prone and costly to maintain (Carboni et al.,
15). Comparing triangulation with fingerprint, the
first one has better results in open spaces, while fin-
gerprinting is better for environments with restricted
pathways (Carboni et al., 15). In addition, we point
out that the use of virtual APs, a technique where a
single AP is used to realize multiple APs, signifi-
cantly reduces position estimation errors, as stated in
(Fallah et al., 13).
2.2 Path Planning
The path planning component calculates routes or
paths. It determines the best path, normally the short-
est one. The best path can also take into consideration
user preferences or constraints, such as the require-
ments of users with reduced mobility (Fallah et al.,
13; Koide and Kato, 05; Akasaka and Onisawa, 08).
Additional functionalities that this component can
provide include calculating different paths to a desti-
nation, and dynamically re-calculating the path as
user position changes or when the system detects that
the user is not following the initial path.
Path planning components usually apply the
Dijkstra or the A* algorithms to calculate the best
path. These algorithms represent the environment by
using graphs or grids (Fallah et al., 13). Graph based
approaches divide the environment in a set of nodes
connected with edges. Nodes represent doors, hall in-
tersections, or elevators, for instance. Edge connects
GRAPP 2020 - 15th International Conference on Computer Graphics Theory and Applications
288

two nodes that are accessible from one another. Edges
can have weights used to define preferences for the
path planning algorithms (Bian et al., 14). In grid-
based approaches the environment is divided into
small parts named cells. As edges, cells can also have
associated weights.
Comparing to outdoor systems, indoor systems
present an additional challenge when the building has
several floors. Bian et al. (2014) improve the A* al-
gorithm to solve performance problems when it is ap-
plied to a building with many floors, considering, as
well, user’s preferences.
2.3 Representation
Indoor navigation systems represent the environment
using maps, and, especially, floor plans, mostly
(Russo, 13). In addition to 2D maps, some proposals
use 3D maps (Koide and Kato, 05; Thill et al., 11).
Maps can also include information about the po-
sition and description of objects (such as room num-
bers), as well as points of interest (PoIs) that help to
identify the space, such as statues, bars, the reception,
or the information office.
2.4 Interaction
The interaction component includes user input and
system feedback functionalities. User input for indoor
navigation systems, mainly used in mobile devices, is
similar to other mobile applications. However, sys-
tem feedback presents more specificities related to
this kind of applications. To provide directions to the
user, audio, visual and haptic techniques are used.
Some proposals apply a combination of these tech-
niques to overcome particular limitations that each
one presents individually (Fallah et al., 13).
2.5 Conclusions
Reduced mobility users have specific restrictions that
current indoor navigation systems only meet occa-
sionally, mainly providing paths without steps.
Dzafic et al. (2014) identify the requirements of an
indoor navigation system for reduced mobility users.
Starting from this work, in this paper, we analyse re-
quirements of indoor navigation systems for reduced
mobility users. Besides that, as requirements depend
on the characteristics of a specific building, we also
systematize the information about this environment
that must be collected before starting the system de-
velopment.
3 REQUIREMENTS ANALYSIS
This section describes the requirements analysis of an
indoor navigation system for reduced mobility users.
We start by eliciting and analysing generic require-
ments for reduced mobility users and, after that, we
systematize the information we need to gather from
the environment to identify its barriers. We applied
these results in the deployment of the w4all system,
as detailed in the next section.
3.1 Elicitation and Analysis of Generic
Requirements
To elicit requirements for indoor navigation systems,
we surveyed related work and used the experience of
one of the elements of the team, a wheelchair user. As
far as we know, Dzafic et al. (2014) present the widest
work about wheelchair user requirements for this kind
of systems. These authors classify requirements as
permanent vs. transient and absolute vs. mitigable.
Permanent requirements are related to barriers that re-
main unchanged for a long time, while transient only
last for a short time. Absolute requirements are ap-
plied to barriers that cannot be bypassed, unlike miti-
gable that can be overcome with the help of another
person. In the following, we detail each requirement
(C-Requirements), identifying the system compo-
nents they influence.
Permanent and absolute requirements:
C1) Handling of steps includes two different re-
quirements, one for the representation component
(the “system should provide information about every
stair, its height and the number of steps” (Dzafic et
al., 14)) and one for the path planning component
(“avoiding steps should be a primary goal for an in-
door navigation system addressing handicapped”
(Dzafic et al., 14)). Notice that a high number of huge
steps is an insurmountable obstacle for a wheelchair
user. But, for instance, one sole step with a small
height can be a mitigable obstacle.
C2) Avoidance of steep incline also presents a re-
quirement for the path planning component: “steep
incline should be avoided according to the maximum
doable incline settled by the user” (Dzafic et al., 14).
The representation component should, as well, pro-
vide information about steep ramps.
C3) Recording of door widths implies that the path
planning component should present paths free of too
narrow doors, including elevator doors. This is also
information that the representation component should
provide.
An Indoor Navigation System for Reduced Mobility Users
289

Table 1: D-requirements for each component of an Indoor Navigation System.
user localization path planning representation interaction
P
ermanent and abso-lute
requirements:
C1) Handling steps D1.1) Calculate paths
without steps
D1.2) Show informa-tion
about stairs
C2) Avoidance of steep
incline
D2.1) Calculate paths
without steep incline
D2.2) Show informa-tion
about ramps
C3) Recording of door
widths
D3.1) Calculate paths
without narrow doors
D3.2) Show informa-tion
about door widths
P
ermanent and mit
i
-ga-
ble requirements:
C4) Handling of
automatic doors
D4.1) Calculate paths
excluding automatic do-
ors that have unreacha-
ble buttons or small
timers
D4.2) Show informa-tion
about automatic doors
that have unreachable
buttons or small timers
C5) Handling of non-
automatic doors
D5.1) Calculate paths
without non openable
manual doors
D5.2) Show informa-tion
about non openable
manual doors
C6) Avoidance of
revolving doors
D6.1) Calculate paths
without revolving doors
D6.2) Show informa-tion
about revolving doors
C7) Indication of stair
lifts
D7.1) Show informa-tion
about stair lifts
C8) Indication of toilets
for disabled persons
D8.1) Show information
about disabled toilets
C9) Indication of
emergency exits and
security zones
D9.1) Show informati-on
about emergency e-xits
and security zones
D9.2) Provide path to
security zone
Transient and abso-lute
requirements:
C10) Monitoring of
elevator status
D10.1) Determine
elevator status
D10.2) Calculate paths
without broken elevator
D10.3) Calculate
alternative paths
D10.4) Show information
about elevator status
D10.5) Provide
alternative paths
C11) Wheelchair
localization
D11.1) Monitor
wheelchair localization
Transient and mitiga-ble
requirements:
C12) Indication of POIs D12.1) Show informa-
tion about PoI
D12.2) Provide path to
PoI
C13) Recording of
opening hours
D13.1) Calculate paths
considering opening
hours of doors
Permanent and mitigable requirements:
C4) Handling of automatic doors involves the
identification of the opening mechanism (if the door
opens by pressing a button, it can be a problem de-
pending on the button position) and how long the door
is kept open. As this requirement is mitigable, the user
can use these doors if he has assistance, otherwise the
path planning component should avoid these doors
while calculating paths. Similar to previous require-
ments, this is another kind of information that the rep-
resentation component should also consider.
C5) Handling of non-automatic doors requires the
evaluation of the strength the user needs to open the
door as well as its opening direction. These doors lead
to the same requirements as automatic doors.
C6) Avoidance of revolving doors also constrains
the way path planning component calculates paths.
The representation component should also provide in-
formation about revolving doors.
C7) Indication of stair lifts should be included in
the representation component. As stair lifts usually
need an activation key or the assistance of a staff
member, this information should be provided in ad-
vance to avoid unnecessary delays.
C8) Indication of toilets for disabled persons is a
requirement for the representation component. It
could also include additional information, such as the
need for a key and its location.
GRAPP 2020 - 15th International Conference on Computer Graphics Theory and Applications
290

C9) Indication of emergency exits and security
zones presents a requirement for the representation
component as well as for the interaction component,
since the interface should include the functionality to
ask for the path to the security zones.
Transient and absolute requirements:
C10) Monitoring of elevator status defines re-
quirements for all the components. The user localiza-
tion component can monitor the status of elevators by
monitoring users’ movements. For instance, it is pos-
sible to determine that an elevator is working if users’
location change from one floor to another floor not
resorting to stairs. The representation component
should also provide information about elevator status,
while the interaction component should include an
additional functionality to calculate an alternative
path, if a user finds out that an elevator he was about
to use is after all out of order. Consequently, besides
calculating paths without broken elevators, the path
planning component should calculate alternative
paths, i.e., paths including another elevator.
C11) Wheelchair localization is a requirement
that the location component should accomplish.
Transient and mitigable requirements:
C12) Indication of PoIs is a requirement for the
representation component. In addition, the interaction
component should also provide the functionality to
ask for paths to specific PoIs.
C13) Recording of opening hours presents an ad-
ditional constraint for the path planning component as
path calculation should also consider which doors are
open in each period of the day.
Table 1 systematizes the developer requirements
(D-requirements) for each of these C-requirements,
considering the four main components of an indoor
navigation system.
3.2 Identifying Environment Barriers
After identifying C-requirements and D-requirements
for an indoor navigation system for reduced mobility
users, we need to analyse the specific environment
and its barriers. The following list enumerates the in-
formation about the building that we need to obtain:
1. Stairs: number of steps and their height, to dis-
tinguish absolute from mitigable situations.
2. Ramps: inclination of ramps to distinguish
steep ramps from the ones that are specially designed
for wheelchair users.
3. Doors: door widths, including elevators’ doors.
4. Automatic doors: button position and how long
the door is kept open.
5. Non-automatic doors: door strength and open-
ing direction.
6. Stair lifts: location of key and staff assistance.
7. Location of revolving doors, toilets for disabled
persons, emergency exits, security zones, and eleva-
tors.
8. Opening hour of doors.
This environment study should be done in loco
and preferably with the assistance of a wheelchair
user.
4 THE w4all SYSTEM
This section describes w4all, an indoor navigation
system for users with normal and reduced mobility,
whose development started with the requirement
analysis presented in the previous section.
The environment of the w4all is a four-floors
building with 23,992 m
2
of a university campus, iden-
tified by the name “C6”.
Figure 1 illustrates the interface of the w4all sys-
tem.
Figure 1: The interface of the w4all indoor navigation sys-
tem.
4.1 Identifying Barriers of the w4all
Environment
To identify the barriers of the building, we use the list
of section 3.2 and the experience of one of the au-
thors, who is a wheelchair user. The results of the en-
vironment study are listed in the following:
1. Stairs: all stairs are unusable for wheelchair us-
ers as they have too many steps. The building has in-
side stairs and some steps in the ground floor.
2. Ramps: the ramps are specially designed for
wheelchair users, as an alternative to the steps of the
ground floor.
3. Doors: door widths are adequate for wheelchair
users.
An Indoor Navigation System for Reduced Mobility Users
291

4. Automatic doors: elevators have automatic
doors whose button position and door open time are
also adequate.
5. Non-automatic doors: exterior doors are non-
automatic doors, whose strength make difficult their
opening. We also identified that one of the exterior
doors is nearby the security zone, where a staff mem-
ber can provide assistance.
6. Stair lifts: the building does not have stair lifts.
7. The building does not have revolving doors. We
identify the location of bathrooms for disabled peo-
ple, emergency exits, security zones, and elevators.
The emergency exits, in the ground floor, present a
problem because they include some steps.
8. Opening hours of exterior building doors: from
8 p.m. to 8 a.m. and during weekends only one build-
ing entrance is open.
4.2 The w4all Architecture
The w4all uses the client/server model, as illustrated
in Figure 2. The user interacts with the w4all client,
which communicates with the w4all server through
the HTTP protocol. The information the w4all needs
(for instance, fingerprints) is saved in a database. We
used the Where@UM application (Matos et al., 14) to
get the fingerprints from the environment.
Figure 2: The w4all architecture.
4.3 The w4all Prototype
This subsection presents details about the implemen-
tation of the w4all considering its four main compo-
nents. For each of them, when applied, we detail how
we handle specific requirements of reduced mobility
users.
4.3.1 User Localization
We use the Wi-Fi fingerprint technique for user local-
ization. This component takes advantage of the al-
ready installed eduroam Wi-Fi network, a world-wide
roaming access service developed for the interna-
tional research and education community. Despite ex-
isting many other APs in the building, the w4all ig-
nores them because they are not permanent. Each
eduroam AP is used to realize two APs (virtual APs),
which w4all uses in conjunction, a technique that re-
duces location estimation errors (Fallah et al., 13).
In some areas of the building, user location is not
accurate, due to the reduced number of APs in finger-
printings. To overcome this problem, we only use fin-
gerprints with at least five APs (including virtual
APs), assuring that each fingerprint includes at least
three different APs (physical APs). Without this re-
striction, the user localization is error prone, and con-
sequently, the information provided to the user may
be potentially misleading. This way, the system pre-
sents outdated information rather than an incorrect
one, an option that we conclude users prefer after per-
forming some tests. However, the navigation system
is not compromised, since interception areas have
enough Wi-Fi fingerprints and only some halls in the
building present insufficient Wi-Fi fingerprints.
To populate the fingerprint database, we collected
fingerprints near the door of each room, in halls inter-
ception points, stairs, near elevators, and PoIs. We
used the Where@UM application (Matos et al., 14) to
handle fingerprints, i.e., to collect, store and compare
fingerprints. Presently, the database includes 113
spaces with at least 10 fingerprints each.
User location is calculated by comparing current
fingerprints with the ones saved in the pre-built data-
base applying the Manhattan distance (Torres-So-
spedra et al., 15). When the system is not able to ob-
tain the current location, the interface provides the in-
formation about the last known location (while Figure
1 shows the information about the current position of
the user, Figure 3 illustrates the scenario where the
system could not determine the current position and
shows the information about the last known location
- see the information in the bottom left side of the Fig-
ure 3 and compare with Figure 1).
Figure 3: User Location Information.
GRAPP 2020 - 15th International Conference on Computer Graphics Theory and Applications
292

4.3.2 Path Planning
The path component has two modes: one for users
with normal mobility and one for users with reduced
mobility. Users can choose the mode they want to use
as explained in section 4.3.4.
In normal mobility mode, paths between floors
only include stairs, following the environment and
energy-saving policy of our university.
Considering the results of the environment study
that section 4.1 presents, the reduced mobility mode
uses elevators to avoid inside stairs and ramps to
avoid the steps of the ground floor. In addition, we
classify non-automatic exterior doors as a mitigable
requirement because an assistant can help the wheel-
chair user to bypass the door – this assistant can be
the security person of the building. Therefore, in this
mode, the path planning component only provides
paths whose entrance match the entry door near the
security workplace.
Finally, the restriction related to the opening hours
of the exterior doors is applied in both modes.
The maps of the building floors are built with
Blender (https://www.blender.org), which is fully
compatible with Unity3D (http://unity3d.com/pt), the
tool we chose for the development of the prototype.
These options were made due to the previous experi-
ence of the team on using these tools as well as to fa-
cilitate the future possibility of including 3D repre-
sentations in the interface. To calculate path, we used
the A* Pathfinding project plug-in for Unity3D with
a grid-based approach.
Our algorithm for path calculation is based on the
approach of Bian et al. (2014), who consider the
cross-storey problem of buildings. In normal mobility
mode, paths between floors only use stairs. When the
origin and the destination are not in the same floor,
our algorithm has the following phases:
1. for every stair repeat
1.1. use the A* to find the path between the
origin and this stair
1.2. use the A* to find the path between this
stair and the destination
1.3. the results of steps 1.1 and 1.2 give a fea-
sible path
2. choose the best feasible path (the shortest one)
In the reduced mobility mode, the algorithm re-
places inside stairs by elevators. In addition, by as-
signing high weights to the steps of the ground floor,
the calculated paths include ramps adequate for
wheelchair users.
4.3.3 Representation
The central element of the w4all interface is an ortho-
graphic top projection of a floor in the C6 building,
and, naturally, there is one map for each one of the 4
floors.
Matching the results of the work we perform dur-
ing the identification of the barriers of the buildings
with the D-requirements for the representation com-
ponent, the maps of each floor show stairs, elevators,
and bathrooms for disabled people. The ground floor
map also contains ramps and the location of the main
entrance where there is always an element from the
security staff that can open the door when required.
We do not represent emergency exits due to the
steps they have, as previously mentioned.
Maps also include some PoIs, such as “the globe”
(a big 3D model of the Earth that exists near one en-
trance of the building), the bar, the study room, librar-
ies, and department secretaries. To identify the most
popular PoIs we used questionnaires, whose respond-
ents were a set of regular users of the building. The
only reduced mobility user that contributed to this
phase was the one in our team because, presently, he
is the only wheelchair user that frequents the building
The colour we use to represent some kinds of in-
formation changes according to the type of mobility
the user chooses. For instance, stairs changes to grey
in reduced mobility mode, being orange in normal
mode (see the difference between Figure 3 and Figure
4).
Figure 4: The w4all interface.
4.3.4 Interaction
Based on the results of requirements analysis, the in-
teraction component provides some additional func-
tionalities. Reduced mobility users have the alterna-
tive path functionality to handle the scenario when
one elevator is not working (button in the right side
of Figure 4). In addition, the w4all system also has the
functionality to provide the path to the security staff
An Indoor Navigation System for Reduced Mobility Users
293

workplace which is near the main entrance (button
“Go to security” in the top of Figure 4). Finally, it also
provides the possibility to change the type of mobility
(see the button in the bottom of Figure 4).
The interaction component uses tactile techniques
for user input and visual techniques for system feed-
back. The central element of the interface is a map of
one floor. On the top of the interface there is a set of
buttons to define the destination, for instance Floor 3,
room 6.3.38, as depicted in Figure 4 (all the examples
we provide inside brackets in this paragraph refers to
this figure). On the right side, it has an ordered list of
floors with three symbols: an eye that identifies the
floor whose map is currently shown in the screen
(Floor 1) and a red racket pin and a flag pin, marking
the departure floor (Floor 1) and the destination floor
(Floor 3), respectively.
The pink line represents the calculated path. As
the user moves to the destination, his position is up-
dated. This movement is illustrated in Figure 4, where
the grey racket pin represents the departure position
and the red racket pin represents the current one. Fig-
ure 5 shows the help interface that summarizes the
w4all functionalities.
Figure 5: The w4all help interface.
5 EVALUATION
The application w4all was evaluated in two phases: a
preliminary one to test the first version of the proto-
type and to obtain feedback from a small set of users,
and a second phase, to test a more mature version that
corrected some details and included, among other fea-
tures, the ones that those users suggested. In both
phases, users: i) received a short explanation about
w4all and answered to a short list of questions that
allows us to trace their general profile; ii) tried the ap-
plication in loco using a tablet and following a guide
with tasks to fulfil; iii) afterwards, they answered to a
questionnaire.
5.1 Preliminary Tests
The first prototype of the application was tested by
three persons: two of them, women aged around 20,
that do not usually use the building and by one expert
in human-computer interfaces, women aged 50, a reg-
ular user of the building. None of them had reduced
mobility.
The overall feedback obtained was positive and
the opinions they expressed were used in the subse-
quent process of fine tuning the interface. The adjust-
ments that were made to the interface they tested con-
cern the graphical symbols (for instance, they sug-
gested to use a pin instead of a star, the symbol that
originally represented the current position of the user)
as well as the position of the buttons in the interface.
We also realized that an extra representation was
needed to enumerate the complete set of floors, high-
lighting the current floor of the user, the destination
floor, and the one that is on the screen (see right side
of w4all current interface, Figure 4).
5.2 User Tests
The second phase of the tests involved two groups of
participants that volunteered to participate in the
study: 47 users with normal mobility (group 1) and
three reduced mobility users (group 2), all distinct
from the co-author of this paper.
Before testing w4all, the participants received the
following explanation about it:
“w4all is a mobile application that calculates
paths in the interior of a building and is intended for
users with or without reduced mobility; the applica-
tion obtains automatically your current location in the
building, calculates the shortest path to reach the des-
tination you choose and displays it visually on a map
on the device screen. The interface allows you,
among other options, to choose the destination, the
type of mobility and an alternative path (for instance
if you verify that the elevator you were supposed to
use in your path is out of order).”
Then, participants answered to a set of questions
with the purpose of defining their profile. They were
asked about age, genre, type of mobility, and usage of
mobile equipment (GPS and Google Maps).
We also inquired users about their level of famil-
iarization with the interior space of the building.
Three classes were considered:
GRAPP 2020 - 15th International Conference on Computer Graphics Theory and Applications
294

 familiarised (F) - they have been inside several
rooms in distinct floors and they feel confident in
finding other rooms elsewhere in the building;
 not-familiarised (NF) - despite having been in-
side a small set of rooms in the building, they do not
feel confident in finding rooms elsewhere in the
building;
 never entered the building before the day they
performed the tests (NEB).
This classification was used to discriminate some
of the answers in the questionnaire, as we explain fur-
ther on.
Next step in the evaluation process was to use
w4all inside the building. Users in group 2 had to use
always the option “reduced mobility”, obtaining a
path involving the use of an elevator whenever they
had to go to a different floor. Users in group 1 were
asked to begin using “normal mobility” (the default
mode of the application) but, at a certain point, they
changed to the “reduced mobility” mode. All the us-
ers tried the option “alternative path”.
After trying w4all, participants answered to a
questionnaire with three parts.
Part 1 is a System Usability Scale (SUS) question-
naire to conclude about the usability aspects of the
application (Brooke, 96).
In part 2, participants had to give a score to each
symbol in the interface concerning how easily they
understand its meaning (from 1- very difficult to 5 -
very easy). With the same scale, they were asked to
classify the usage of the “I'm here” button. This but-
ton was conceived to deal with sporadic failures in the
Wi-Fi signal and permits the user to introduce in the
application its current position that he can obtain just
by consulting the label in a nearby door. This way, it
is possible to go on using w4all to obtain asking for a
path inside C6.
Besides, we asked if they considered necessary to
have a 3D representation of the interior space of the
building (a yes or no question) and the following set
of open questions:
 what aspects did you find difficult to use or to
understand?
 what aspects did you find easy to use or to un-
derstand?
 what did you like the most?
 what did you dislike the most?
 which additional functionalities do you suggest?
The main objective of part 3 is to obtain the opin-
ion of the users about w4all. We asked them to give a
score in a 5 points Lickert scale (from 1- strongly dis-
agree to 5- strongly agree) to express their level of
agreement with the following statements:
 the application fulfils my anticipated objectives;
 the application is useful.
Finally, we collected general observations and, on
a scale of 1 (bad) to 5 (excellent), users’ overall as-
sessment (global appreciation) of the application.
Following subsections detail the results obtained
in each one of the two groups: users with normal mo-
bility and users with reduced mobility.
5.2.1 Users with Normal Mobility
Among the 47 participants in group 1, there are 36
(77%) with ages between 20 and 35 (10 women and
26 men); and 11 users (23%) aged above 35 years old
(9 women and 2 men). They all feel comfortable us-
ing mobile equipment (tablets, smartphones or both)
and use on a regular basis GPS services and Google
Maps.
Considering the level of familiarization with the
building, 7 users (15%) classified themselves as “fa-
miliarised” (F), 26 users (55%) as “not-familiarised”
(NF) and 14 users (30%) had “never entered before”
(NEB) in the building.
The value obtained in the SUS questionnaire, part
1 in the questionnaire, was 75, a value over 68, the
value that represents the average of this questionnaire
(Sauro, 09). According to Bangor et al. (2009), this
result can be objectified as “Good”.
Analysing the results of part 2, we start by identi-
fying the symbols of the interface that received lower
scores: the stairs, the ramps and the security person
(average score around 3,6). All the other symbols re-
ceived average scores above 4.
The “I’m here” button raised several questions.
Despite being explained in the help area of the app,
several users did not process this information and got
confused with it, thinking that they should use the
button to obtain the current location. As a matter of
fact, 12 users (26%) mention negatively this button:
10 considered it difficult to use or confusing and 2
included it in the items they dislike the most.
Relatively to the 3D representation of the space, 6
users (13%) considered it would be important to help
the orientation process of people that do not know the
space. Among these 6 users, 4 were NF users, 1 was
F and another NEB.
The aspects found more difficult to use or to un-
derstand were the button “I’m here” (discussed
ahead), and 2 users mentioned the fact that the map
does not rotate according to the current position of the
user, making difficult to know, in some points of the
path, if the user should turn right or left.
The aspects more appreciated were, for the large
majority of the users, the simplicity of the interface
An Indoor Navigation System for Reduced Mobility Users
295

and the possibility of obtaining paths for people with
reduced mobility.
The aspects that the users dislike the most were
related to the design of the interface; 8 users (17%)
referred this, saying for instance, that it should be
more appealing and colorful.
The suggestions for additional functionalities
were the following:
 support the possibility of choosing a destination
room by the name of a professor that occupies it; this
was the most frequent suggestion, 5 users (11%) men-
tioned it.
 adjust the orientation of the map according to
the relative position of the user while navigates in the
building; 4 users (9%) mentioned this functionality.
 support input by voice command (for instance,
some users with reduced mobility have also some
limitations interacting with the touch screen); 4 users
(9%) mentioned this feature.
 show the length of the path; this was referred by
2 participants (4%), one of them a NEB user.
 produce an alert to the user when he just arrived
at his destination, for instance by vibration or drawing
a specific symbol or text in the interface; this was
mentioned by 1 participant (2%).
Figure 6, Figure 7, and Fig. 8 summarize the re-
sults obtained in part 3. The strong majority of users
in class F, 57%, scored with 4 and 14% with 5 the
statement “the application fulfils my anticipated ob-
jectives”; scores 2 and 3 received the remaining per-
centage, 14% equally divided; nobody used score 1.
Considering the statement “the application is useful”,
71% used the value 5 and the remaining 29% the
value 4; nobody used score 3 or 2.
In class NF, 42% scored with 4 and 35% scored
with 5 the statement “the application fulfils my antic-
ipated objectives”; scores 3, 2 received the remaining
percentage, 19% and 4% respectively; nobody used
score 1. Considering the statement “the application is
useful”, 35% used the value 5, 62% the value 4; 1 user
out of 26 (4%) gave score 3 and nobody used score 1
and 2.
In class NEB, 36% scored with 5 and the same
percentage with 3, while 21% scored with 4 the state-
ment “the application fulfils my anticipated objec-
tives”; score 2 received 7% (1 out of 14). Considering
the statement “the application is useful”, 43% used
the value 5, 50% the value 4; and 7% (the same user
out of 14) gave score 2. Nobody used scores 1 or 3.
Concerning the global appreciation (see Fig. 8),
and like in the previous statements, score 1 never oc-
curred. In class F, 14%, scored with 5, 43% with 4,
29% with 3 and, 14% with score 2. In class NF, the
majority, 73%, gave score 4 while the remaining per-
centages are 12% to score 5 and also to score 3 and
only 4% to score 2. In class NEB, the large majority,
79%, gave score 4 being the remaining percentages
7% to score 5 and 14% to score 3.
The final observations made by participants rein-
force the opinions given in the open questions. How-
ever, we obtained a curious one, by a NF user: “the
application is really important because people get fre-
quently lost in this building. While I was testing the
application, I helped a person who was lost. This app
is useful.”
Figure 6: Percentage of score values (between 1- strongly
disagree and 5- strongly agree) given by users with normal
mobility concerning the statement: the application fulfils
my anticipated objectives.
Figure 7: Percentage of score values (between 1- strongly
disagree and 5- strongly agree) given by users with normal
mobility concerning the statement: the application is useful.
Fig. 8. Percentage of score values (between 1- bad and 5-
excellent) given by users with normal mobility concerning
their global appreciation about w4all.
GRAPP 2020 - 15th International Conference on Computer Graphics Theory and Applications
296

5.2.2 Users with Reduced Mobility
The users in group 2 were 1 man and 2 women, all
aged between 20 and 35 years old. They had never
been inside the building before (NEB users) and are
wheelchair users. They all feel comfortable using mo-
bile equipment (tablets, smartphones or both) and use
on a regular basis GPS services and Google Maps.
The answers that these users gave in the SUS
questionnaire are similar to the ones of group 1.
Considering the symbols in the interface they also
mentioned the ramp and the stairs; the “I'm here” but-
ton was not problematic. Table 2 summarizes the an-
swers given by these users and their suggestions for
new functionalities.
Table 2: Open answers by users with reduced mobility.
User 1 User 2 User 3
Genre m f f
Age 20-35 20-35 20-35
3D repre-
sentation?
no no no
Most diffi-
cult to use
choose the des-
tination
nothing nothing
Easier to
use
know location
in the building
know location
in the building
all
Like the
most
the map of the
building
know the way
without losing
myself
find the shor-
test path; alter-
native paths
Dislike the
most
the design nothing wc positions are
not highly-
ghted enough
Additional
Features?
navigation by
voice
bilingue version more places
ready to choo-
se as a desti-na-
tion; path to the
nearest wc
Table 3 shows the scores concerning the items in
part 3. The general opinion obtained two 5-scores and
one 3-score; usefulness has a slightly better result,
two 5-scores and one 4-score. While the sentence “the
app fulfils my anticipated objectives” obtained two 5-
scores and one negative 2-score. Curiously, this neg-
ative score was given by user 2 who scored with 5 the
other two items.
Table 3: Scores by users with reduced mobility.
User 1 User 2 User 3
Fulfils my anticipated
objectives
5 2 5
Usefulness 4 5 5
General opinion 3 5 5
Considering the observations, one of these users
said: “It's good to have something that reassures when
I need to find a path in a building that I do not know;
besides it gives me the shortest path. It is a good feel-
ing to know the way without losing myself”.
5.2.3 Discussion
As explained before, two groups of users tested the
w4all application in loco: a group of 47 normal mo-
bility users and a small group of three users with re-
duced mobility.
The first group comprised persons that covered
the three levels of familiarization with the building.
Therefore, we tried to discriminate all the answers ac-
cording to this characteristic. As we can observe in
Fig. 6, Fig. 7, and Fig. 8, results are quite positive:
users in classes F, NF and NEB considered it, respec-
tively, 100%, 97% and 93% useful (scores 4 and 5);
respectively 71%, 77% and 57% considered that
w4all fulfils their anticipated objectives (scores 4 and
5). In the overall appreciation, and using the same or-
der, the application received 57%, 85% and 86% of
scores 4 and 5. Score 1 never occurred and score 2 is
rare.
Nevertheless, we are aware that improvements
have to be made in the interface, namely in the sym-
bols related to ramps and stair, extremely important
because they are used in the paths. Also
, the function-
ality of the button “I’m here” must be clarified.
6 CONCLUSION AND FUTURE
WORK
This paper presents the results of each step of the de-
velopment process of an indoor navigation system for
reduced mobility users. It describes the requirement
analysis focusing on each component of the system:
user localization, path planning, representation and
interaction. After eliciting C-requirements, we detail
D-requirements for each component. We also enu-
merate the relevant information to gather from the in-
door environment to instantiate the requirements to a
particular building space. Finally, we overview the
w4all prototype and its evaluation with users with
normal and reduced mobility.
Beyond the interface aspects referred previously,
usability tests involving more participants, mainly
wheelchair users, are also planned. Future work also
includes fine-tuning the user localization component
and the implementation of some D-requirements,
namely, monitoring and showing information about
the elevator status and tracking wheelchair users.
An Indoor Navigation System for Reduced Mobility Users
297

ACKNOWLEDGMENTS
This work was supported by FCT through the
LASIGE Research Unit (U.408) and the UID/MULTI
/04046/2019 Research Unit grant (to BioISI).
REFERENCES
Akasaka Y, Onisawa T. Personalized pedestrian navigation
system with subjective preference based route selec-
tion. In: Da Ruan, Hardeman F, van der Meer K, edi-
tors. Intelligent Decision and Policy Making Support
Systems. Studies in Computational Intelligence, vol
117. Springer, Berlin, Heidelberg. p. 73-91, 2008.
Anagnostopoulos GG, Deriaz M, Gaspoz JM, Konstantas
D, Guessous I. Navigational needs and requirements of
hospital staff: Geneva University hospitals case study.
Proc. Int. Conference on Indoor Positioning and In-
door Navigation (IPIN), IEEE. 2017. p. 1-8.
Bangor A, Kortum P, Miller J. Determining what individual
SUS scores mean: Adding an adjective rating scale.
Journal of Usability Studies. 2009; 4(3): 114-123..
Bian W, Guo Y, Qiu Q. Research on Personalized Indoor
Routing Algorithm. Proc13th Int. Symposium on Dis-
tributed Computing and Applications to Business, En-
gineering and Science, IEEE. 2014. p. 275-277.
Brooke J. SUS-A ‘Quick and Dirty’ Usability Scale, In: Jor-
dan P, Thomas B, Weerdmeester BA, McClelland IL,
editors. Usability Evaluation in Industry, Taylor &
Francis 1996. p. 189-194.
Carboni D, Manchinu A, Marotto V, Piras A, Serra A. In-
frastructure-free indoor navigation: a case study. Jour-
nal of Location Based Services. 2015; 9: 33-54.
Cardoso P, Domingos D, Cláudio AP. Indoor navigation
systems for reduced mobility users: the w4all case
study. Procedia Computer Science 100 (2016): 1200-
1207.
de Oliveira LC, Andrade AO, de Oliveira EC, Soares A,
Cardoso A, Lamounier E. Indoor navigation with mo-
bile augmented reality and beacon technology for
wheelchair users. Proc. Int. Conference in Biomedical
& Health Informatics (BHI), IEEE. 2017. p. 37-40.
Deretey E, Ahmed MT, Marshall JA, Greenspan M. Visual
indoor positioning with a single camera using PnP”.
Proc. Int. Conference on Indoor Positioning and In-
door Navigation (IPIN), IEEE. 2015. p. 1-9.
Dzafic D , Link JAB, Baumeister D, Kowalewski S, Wehrle
K. Requirements for Dynamic Route Planning for
Wheelchair Users. Proc. Int. Conference on Indoor Po-
sitioning and Indoor Navigation, IEEE. 2014. p.27-30.
Fallah N, Apostolopoulos I, Bekris K, Folmer E. Indoor hu-
man navigation systems: A survey. Interacting with
Computers. 2013; 25(1): 21-33.
Faragher R, Rice A. SwiftScan: Efficient Wi-Fi scanning
for background location-based services. Proc. Int. Con-
ference on Indoor Positioning and Indoor Navigation
(IPIN), IEEE, 2015. p. 1-6.
Gao R, Tian Y, Ye F, Luo G , Bian K, Wang Y, Wang T,
Li X. Sextant: Towards Ubiquitous Indoor Localization
Service by Photo-Taking of the Environment. IEEE
Transactions on Mobile Computing. 2016; 15(2): 460-
474.
Gerstweiler G, Vonach E, Kaufmann H. HyMoTrack: A
Mobile AR Navigation System for Complex Indoor En-
vironments. Sensors. 2015; 16(1): 17.
Jain M, Rahul RC, Tolety S. A study on Indoor navigation
techniques using smartphones. Proc. Int.Conference on
Advances in Computing, Communications and Infor-
matics (ICACCI), IEEE. 2013. p. 1113-1118.
Koch C, Neges M, König M, Abramovici M. Natural mark-
ers for augmented reality-based indoor navigation and
facility maintenance. Automation in Construction.
2014; 48: 18-30.
Koide S, Kato M. 3-D human navigation system consider-
ing various transition preferences. Proc. Int. Confer-
ence on Systems, Man and Cybernetics, IEEE. 2005. p.
859-864.
Matos D, Moreira A, Meneses F. Wi-Fi fingerprint similar-
ity in collaborative radio maps for indoor positioning.
Proc. 6° Simpósio de Informática (INForum), 2014. p.
184-194.
Moder T, Wisiol K, Hafner P, Wieser M. Smartphone-
based indoor positioning utilizing motion recognition,
Proc. Int. Conference on Indoor Positioning and In-
door Navigation (IPIN), IEEE. 2015. p. 1-8.
Molina B, Olivares, Palau CE, Esteve M. A Multimodal
Fingerprint-Based Indoor Positioning System for Air-
ports. IEEE Access. 2018; 6: 10092-10106.
Ozdenizci B, Coskun V, Ok K. NFC internal: An indoor
navigation system. Sensors. 2015; 15(4): 7571-7595.
Pombinho P, Afonso AP, Carmo MB. Point of interest
awareness using indoor positioning with a mobile
phone. Proc. 1st Int. Conference on Pervasive and Em-
bedded Computing and Communication Systems. 2011.
p. 5-14.
Russo D. Route Directions using Visible Landmarks for an
Indoor Navigation System based on Android device: In-
doorNav (dissertation). Aquila (IT): University; 2013.
Sauro J. Measuring Usability with the System Usability
Scale (SUS); 2011 Feb
Thill JC, Dao TH, Zhou Y. Traveling in the three-dimen-
sional city: applications in route planning, accessibility
assessment, location analysis and beyond. Journal of
Transport Geography. 2011; 19(3): 405-21.
Torres-Sospedra J, Montoliu R, Trilles S, Belmonte O,
Huerta J. Comprehensive analysis of distance and sim-
ilarity measures for Wi-Fi fingerprinting indoor posi-
tioning systems. Expert Systems with Applications.
2015; 42(23): 9263-9278.
Torres-Sospedra J, Jiménez AR, Moreira A, Lungenstrass
T, Lu WC, Knauth S, Mendoza-Silva GM, Seco F,
Pérez-Navarro A, Nicolau MJ, et al. Off-line evaluation
of mobile-centric indoor positioning systems: The ex-
periences from the 2017 IPIN competition. Sensors.
2018;18(2): 487.
GRAPP 2020 - 15th International Conference on Computer Graphics Theory and Applications
298