D4.2 Refinement of Services and Lessons...

D4.2 Refinement of Services and Lessons Learnt 1

SIMON. ASSISTED MOBILITY FOR OLDER AND IMPAIRED USERS

Title: Document Version:

D4.2 Refinement of Services and Lessons Learnt 2.0

Project Number: Project Acronym: Project Title:

621041 SIMON aSsIsted Mobility for Older aNd impaired users

Contractual Delivery Date: Actual Delivery Date: Deliverable Nature-Dissemination level:

M18 M22 (v2.0: M39) R (Report) – PU (Public)

Responsible: Organisation: Contributing WP:

Manuel Vivó Furió ETRA I+D WP4

Authors (organisation):

Manuel Vivó Furió (ETRA I+D)

Roberto Arribas Lorenzo (ETRA I+D)

Marcus Handte (LOCOSLAB)

Stephan Wagner (LOCOSLAB)

Alberto Ferreras Remesal (IBV)

Eva Muñoz (ETRA I+D)

Abstract:

Deliverable D4.2 explains the lessons learnt from the preparation and execution of small scale pilot tests. The improvements applied on the SIMON services and applications are reasoned an explained.

Keywords:

Small scale pilot, refinement, applications, services



Revision History

Revision Date Description Author (Organisation)

V0.1 2015-06-15 Table of contents M. Vivó (ETRA I+D)

V0.2 2015-07-16 All contributions integrated New section 4 for refinement of applica-tions

A. Ferreras (IBV) M. Vivó (ETRA I+D) M. Handte (LOCOSLAB)

V0.3 2015-07-22 Refinement of SIMON CONTROLS applica-tion, abstract and conclusions

R. Arribas (ETRA I+D) M. Vivó (ETRA I+D)

V0.4 2015-08-20 Internal review M. Vivó (ETRA I+D) E. Muñoz (ETRA I+D)

V0.5 2015-10-01 Checking of consistency with D5.2. Section 2 clean-up.

E. Muñoz (ETRA I+D)

V0.6 2015-10-23 Section 2.3 Conclusions of Small Scale Pilot and Table for refinement

A. Ferreras (IBV)

V0.7 2015-10-30 Analysis and annexes E. Muñoz (ETRA I+D)

V1.0 2015-11-03 Document ready for submission E. Muñoz (ETRA I+D)

V1.1 2017-01-11 Update of the document: M. Handte (LOC) M. Vivó (ETRA I+D)

V2.0 2017-03-31 Document ready for submission E. Muñoz (ETRA I+D)



TABLE OF CONTENTS

1. INTRODUCTION ............................................................................................................ 5

1.1. Purpose of the Document .............................................................................................. 5

1.2. Scope of the Document .................................................................................................. 5

1.3. Structure of the Document ............................................................................................ 5

2. RESULTS OF SMALL SCALE PILOT TESTS ......................................................................... 7

2.1. Description of the testS .................................................................................................. 7

2.2. Evaluation methodology ................................................................................................ 7

2.3. Conclusions ..................................................................................................................... 8

3. REFINEMENT OF SERVICES ........................................................................................... 18

3.1. General aspects ............................................................................................................ 18

3.1.1. Needs identified ............................................................................................................ 18

3.1.2. Changes applied ............................................................................................................ 18

3.2. Refinement of SIMON SAYS .......................................................................................... 18


3.2.2. Changes applied ............................................................................................................ 20

3.3. Refinement of SIMON BOOKS ...................................................................................... 21

3.4. Refinement of SIMON OPENS ...................................................................................... 21


3.4.2. Changes applied ............................................................................................................ 21

3.5. Refinement of SIMON ANSWERS ................................................................................. 21


3.5.2. Changes applied ............................................................................................................ 22

4. REFINEMENT OF APPLICATIONS ................................................................................... 26

4.1. SIMON LEADS ............................................................................................................... 26

4.1.1. Extended Application Functions .................................................................................... 26

4.1.2. Improved Application Functions ................................................................................... 29

4.1.3. IOS Version .................................................................................................................... 33

4.2. SIMON CONTROLS ........................................................................................................ 35

4.2.1. Improvements and new features .................................................................................. 35

4.3. SIMON Authority operator Web application ............................................................... 37

5. CONCLUSIONS ............................................................................................................. 40

6. REFERENCES AND ACRONYMS ..................................................................................... 41

6.1. References .................................................................................................................... 41



6.2. Acronyms ...................................................................................................................... 41

ANNEXES ......................................................................................................................... 42

I. Annex 1. Incides and improvements during user tests of SIMON LEADS .................... 42

II. Annex 2. Incides and improvements during user tests of SIMON LEADS at each pilot site 46



1. INTRODUCTION

1.1. PURPOSE OF THE DOCUMENT This deliverable describes the evolution of the SIMON services and applications since the original design to the first stable version deployed for the large scale pilot tests in the city, including the reasons for applying the modification. Results of the small scale pilot are considered and analysed in order to leverage on the added value obtained from the users’ feedback.

In v1.0 of this document, only the mobile app for Android was available and the application for the public authority was not refined. In v2.0, issued by the end of the project, some updates are included: the description of the SIMON mobile app for iOS, developed upon the request of the SIMON Users Group; the final version of the Authority Operator Tool; the integration of new data sources –interurban buses- in Madrid; and finally, as requested by the EC reviewers in the SIMON second review meeting, the description of the indoor routing functionality. Some other minor updates are also including, regarding additional refinement of services. The new relevant text is indicated with the tag [new in v2.0] preceding it.

1.2. SCOPE OF THE DOCUMENT The initial design of services and applications was described in deliverable D4.1 (1). The integration of services and applications took place to get a first prototype of the SIMON system and the preparation and execution of the small scale pilot tests followed to help with the assessment of this first version of the ICT services and SIMON architecture. During these activities, new needs and issues have been identified, and the corresponding changes have been applied.

Some of the needs were detected by the development team during the integration process: they identified potential weaknesses, inconsistencies and vulnerabilities, and proceeded to the redesign of the corresponding features.

Once integration results were ready, the small scale pilot tests were executed with a limited number of selected users. Tests were mainly oriented to detect usability issues, especially for users with disabilities, but also to check whether the SIMON services were working as expected or not. The results of the test have been taken into account and the corresponding modifications have been made in the applications.

This document aims at describing this process: lessons learnt during integration process, aspects of the services that have been revised, conclusions of the small scale pilot tests and changes made in applications.

Another deliverable, D5.2 Small Scale Piloting (2) is devoted to the description of the design and execution of small scale pilot tests, as well as the extensive explanation of the tests results. As a consequence, they are out of the scope of this document.

1.3. STRUCTURE OF THE DOCUMENT The document includes the following contents:

• Section 2 aims at highlighting the most relevant aspects of the small scale pilot with regards to the evolution of services and applications. Subsections 2.1 and 2.2 provide an overview of the tests and the methodology used, while subsection 2.3 summarises the conclusions obtained from the tests.

• Section 3 describes the evolution of the SIMON services, having a subsection dedicated to each one: 3.2 to SIMON SAYS, 3.3 to SIMON BOOKS, 3.4 to SIMON OPENS and 3.5 to SIMON ANSWERS, with an initial 3.1 subsection for general aspects. Most of the changes applied to services were motivated by new needs identified by the development during the integration



phase, so the subsections dedicated to each of the services is subdivided in two parts, one for reasoning the changes and the other to describing them.

• Section 4 describes the modifications made on applications (SIMON LEADS and SIMON CONTROLS) in order to solve the issues reported by the users participating in small scale pilot tests. V02 of this document includes also the description of the AUTHORITY OPERATOR TOOL.



2. RESULTS OF SMALL SCALE PILOT TESTS A small scale testing phase took place at each of the sites –Madrid, Lisbon and Parma- to carry out a first assessment of the new ICT services and applications proposed by SIMON. Different tests were done in a controlled environment prior to the large deployment in the large scale piloting phase. The purpose of the small scale pilot tests has been to assess both functionality and usability aspects of the applications that will be used for citizens and controllers: SIMON LEADS and SIMON CONTROLS. These tests complement the technical tests performed by developers and pilot sites, whose goal was to check the technological robustness of the ICT services deployed.

In this section we provide a short description of these tests and the methodology used for the assess-ment, as well as a summary on the main conclusions. A more detailed and extensive description of the methodology of the test is available at deliverable D5.2 (2), specifically dedicated to the small scale pilot. The main results obtained with the technical assessment, together with the feedback gathered form end users have been used to fine tune the ICT services and to enhance the usability and ac-ceptance of the apps.

2.1. DESCRIPTION OF THE TESTS The activities performed by the Consortium in order to assess the initial versions of the mobile apps were planned in two differentiated ways, namely: the heuristic assessment and the citizen-focused testing:

• The members of the Consortium made a technological assessment of the robustness of the ICT services, identifying bugs and evaluating the feasibility of the proposed solutions, but also providing a first heuristic assessment of the proposed system based on the usability and accessibility requirements defined in D2.2 (3) and D2.3 (4) and always taking as a reference the conceptual design jointly agreed by developers and end users and described in D4.1 (1).

• Testing with final users. Citizens and controllers performed a set of proposed tasks with the apps (and extracted from the use cases and the conceptual design), in a controlled environment and under the supervision of the experts in the Consortium. The tests were performed at the three pilot sites with the participation of a total of 20 selected end users, including citizens and controllers.

2.2. EVALUATION METHODOLOGY Technical and heuristic tests with SIMON LEADS app were focused to achieve the following objectives:

• Firstly, it was key to ensure that all functionalities were perfectly working before user trials in real conditions. For this, bugs and incidences reported from the internal testers at each of the cities were assessed and solved by the technical staff at WP4.

• Secondly, general problems related to usability of the apps were detected following two different approaches: on the one hand, by a free use of the app, and on the other hand, performing the same set of users’ tasks already defined to be tested with them.

For the user tests, two procedures were defined, namely: the test for the citizens using the SIMON LEADS app and the test for the controllers using the SIMON CONTROLS app.

Disabled users were told to do different tasks covering the main functionalities related to: Basic Func-tions, Navigation menu, Information Menu and Validation Menu. On the other hand, controllers were also guided to do the main tasks allowed by their app, form login to different notifications. The detailed description of the tasks can be found in D5.2 – Section 5.1.

Each test had the following phases:

• PHASE 1: User profiling. The goal of the user profiling was to characterize the participants in the validation of the app.



• PHASE 2: Tasks development and individual inspection. Here the user performed the different tasks, while commenting openly all his/her impressions. The interviewer recorded all the de-velopment, gathering the impressions, difficulties and problems with specific templates. Each task could be done twice: Repeat 1 without any support (intuitive) and Repeat 2 supported by verbal indications.

• PHASE 3. Personal interview. The objective of this phase was to analyse (interviewer and user) the product performance after completing all the tasks. The interviewer asked the user about the benefits, requirements and problems of the app.

2.3. CONCLUSIONS As a result of the technical debugging and heuristic tests with SIMON LEADS app, some conclusions regarding functionalities and usability were advanced previously to the specific testing with users.

Later on, as a result of the small scale pilot with users, many aspects were highlighted by the users of the three pilot sites. The SIMON Consortium selected the advantages, limitations and proposed im-provements that were consistently mentioned at the three cities and by several users.

All this information has been reported in depth in D5.2 Small Scale Piloting (2), in which the reader can find the full list of recommendations gathered from the SIMON User Group. Now in this section we present the final analysis done to describe and classify those recommendations in order to understand the best way to undertake them. The complete list of recommendations and possible improvements has been included in Annex I, based on the templates used by the evaluators and the testing described in D5.2. The same information, classified by each pilot site, is shown in Annex II.

With the aim to achieve a refinement of services and applications, as intended in this final task of WP4, the possible improvements were discussed and a list of agreements was done for the implementation of the final version of SIMON apps. This list of proposed improvements is shown in Table 1. In this table, the Problem Detected is described, an Improvement Proposal is done for each problem, and a Prioritization is made for each possible improvement. This table was discussed and different decisions were agreed as is shown in the columns Comments and Agreements.

Following each of the improvements was implemented in one or another way, and this will be de-scribed in the following sections in this document.

.



SECTION/ TASK

PROBLEM DETECTED IMPROVEMENT PROPOSAL PRIORITY COMMENTS Agreements

GENERAL Lateral menu difficult to find Clearer icon for lateral menu (or the word menu)

Low Actual icon for menu is a standard in Android

Not change. Maintain actual icon

GENERAL Small font size Recommendation (tutorial/help) Increase font size via Android accessibility options

Medium Add accessibility options (larger text, Talkback…) at the tutorials and also at the contextual help at the app

Accessibility options will be available through the app settings

Help text will be done both for app and tutorials (IBV).

GENERAL Home icon at the lateral menu is not clear

Improve icon, add text High OK

GENERAL Icons difficult to understand (both at the general and at the lateral menu)

Improve icons High Change the navigation icon with a standard

GENERAL Lateral menu difficult to read Improve readability Medium OK

GENERAL Accessibility for blind users: labels and compatibility with screen readers issues

Label with audio all the possible navigation routes and the contents in fields

High User has to activate Talkback at the accessibility options in Android system.

Add accessibility options (larger text, Talkback…) at the tutorials and also at the contextual help at the app

Modify

Help text will be done both for app and tutorials (IBV).



SECTION/ TASK


GENERAL/ HELP

General help is not present Add general help about how to use globally the app (at the home page)

Medium OK Modify

Additionally to the tutorials, at the first start a brief tutorial will appear

GENERAL/ HELP

Help icon is hidden at the lateral menu

Ease the access to help button (visible from each screen)

Low / to study Not possible as it would saturate some screens.

Help text will be added in help section to explain the user that help is contextually available through the lateral menu

GENERAL/ FEEDBACK

Usability of feedback Should be possible to link an email account with the app and use it by default, in order to avoid questions to the user? (This could be an option in personal settings)

Feedback when message is sent should remain visible more time, in order that user has time to read it.

Low / to study OK Modify

Locoslab will remove some of the actual options (eg SMS/MMS) that are not valid and add an option in settings for that the user can set the “by default” email account

NAVIGATION /MAP

Lack of zoom. Magnification is not enough

More zoom range High OK



SECTION/ TASK


NAVIGATION/MAP

Name of streets is not visible until the magnification is too high. Moreover, little streets are difficult to see

Name of main streets should appear even with smaller zooms

Medium OK Add more detail is complicated but could be done in future revisions.

NAVIGATION/MAP

Icons are difficult to understand: zoom in/out is not comprehensible. Search icon seems to be a magnifying glass

Substitute zoom icons by

Low / to study Not urgent as there are different alternatives to do the zooming

Modify

NAVIGATION/MAP

Symbols / buttons of zoom in/out disappear when is a marker on the map

Increase consistency of contents among screens: items and elements should remain similar whenever possible

High OK Revise complexity and consistency among screens during the pilot testing

NAVIGATION/MAP

Too much information on map like rail tracks, tunnels or building profiles.

It should be possible to choose which information appears (for example, in settings)

Low / to study Not possible

NAVIGATION/MAP

Although double click on screen provokes zoom in, the frequency of double click was too fast for some users with upper limbs disabilities

Allow a slower double click to zoom (for example in settings)

Medium OK Modify.

This can be done with the accessibility options in Android.

Accessibility options will be available through the app settings



SECTION/ TASK


NAVIGATION/ SEARCH

Search for an address is a slow process: • Too much possibilities at

the search results • Writing the city slows the

process

The user should be able to filter the search results initially (everything, streets, stops, parking spaces…), at the menu in navigation or when the search box opens.

The user should be able to define the “by default” city to make searches

HIGH OK Filter by city. OK

Filter in search screen will be implemented with three options activated by default (see image). User will be able to deactivate some of these options to refine the search

NAVIGATION/ SEARCH/ MAP

Icons are not clear: • Bus icons (yellow) and ac-

cessible bus (blue) are not comprehensible / dif-ferentiated

• Icons are small • Icons of bus, metro, park-

ing doesn`t appear until zoom is too close

• Parking space icon is not easily visible and the meaning is also unclear

• Help in this area does not indicate the meaning of icons

Change /improve icons • Bus Icons should be clearly dif-

ferent and differentiated • Bigger icons • Icons should appear with less

zoom • Secondary functions when click-

ing an icon should be more visi-ble

• Use “P” for the parking places • Add information about mean-

ing of icons and secondary functions at the help

HIGH OK Modify

Following icons will be changed: • Accessible metro

station (for example “M+wheelchair”

• Reserved parking spaces (P)

The meaning of the map icons will be included at the contextual help



SECTION/ TASK


NAVIGATION / MAP

The arrow in the search field seems to have the “go” function, but it is only a picture without functionality

Remove or add functionality HIGH OK

NAVIGATION / MAP

Information about the bus stop or street that appears below when selecting a point/marker is not clearly visible (not highlighted, low contrast) and (once seen) user tend to think that it is clickable, but it is not.

The information about the stop that is shown in the lower part of the screen should be: • Clearly visible (and user should

be aware of the changes when clicking another stop).

• Clickable: clicking there should at least open some options (set as origin, see information,…). For example: o If it is a STREET or place:

should open the options “set as origin”, “set as desti-nation”, “detailed info”

o If it is a PARKING SPACE or place: should open the op-tions “set as origin”, “set as destination”, “detailed info”

o If it is a BUS/METRO STOP: should open the options “schedule/stop infor-mation”, “set as origin”, “set as destination”

• Another option is to use “pop up information” when clicking a marker or point in the map.

HIGH OK Modify

Change the way of what happens when a marker pin is selected: information will appear together with the different options of what to do



SECTION/ TASK


GENERAL Back button does not behave as expected (for example after clicking on a bus icon and asking for the timetable, back button should go to the previous screen (the map) but it goes back to the home page.

Back button should always go back to the previous screen

HIGH OK

NAVIGATION/ SEARCH

Search is lost if user goes back and returns to the search page

Store the last search Medium OK Modify

The system will store the last searches and show them first in the list when user starts typing, in order to speed the writing

NAVIGATION/ ROUTE

Search Route options are not intuitive nor ordered in the logical way

Secondary functions on each screen are very interesting but not usable as the user don’t see them and does not k now that they are available

Process must be sequential. Change the order of the actions to perform the route: • First the mean of transport op-

tions (walking, driving,… ): here we propose icons as it is in google maps)

• Origin-destination • Hour/date • Options

Differentiate clearly the active elements: what is clickable, what is a drop down menu, what is a text field,…

HIGH OK Modify In addition, the options button will change ac-cordingly to the transport mode se-lected: • Driving options • Walking options • Transit options



SECTION/ TASK


NAVIGATION/ ROUTE

Typing your current position is uncomfortable

System should register the real location of the user and offer it as “origin”

Medium OK OK

NAVIGATION/ ROUTE

Icons are unclear: • Set time to now is the

same icon as the timeta-ble

• Set origin / destination to here are confusing and same as other icons

Change the icons.

Avoid repeat the same icons for different purposes or different icons for same purposes

High OK Modify

NAVIGATION /ROUTE / FAVORITES

Favourites cannot be set as “origin”

A lot of features (delete, rename) that are shown at the help are not present

Put all the functionalities to favourites

High OK Modify

“Favourites” screen will be changed: • Remove the check-

box • Remove the left but-

tons • Add a shadowed

square to each fa-vourite and make it clickable

When user taps on each favourite, all the alternatives will appear (delete, rename, set as origin, etc…)



SECTION/ TASK


NAVIGATION/ ROUTE

Icons that appear in search results are confusing. Moreover, some are clickable and others not.

Icon for “route” is small and has low contrast

Improve visibility and meaning of icons

HIGH OK Modify Changes to be done: • draw a line to sepa-

rate the information section and the sec-tion of clickable items

• Information icons will also provide ex-planation when the user click on them

TIMETABLE Knowing the name or number of the stop is difficult. It should be possible to browse by categories (type of transport) or to search by bus number

• An option to choose/filter the types of transport preferred should be available

• Ease the search of stops: filter by city first, browse/search by type of transport, bus number, address nearby,…

Medium/high Possible. Future update

TIMETABLE “Enter/done” key in keyboard sometimes erase the entered data

Correct Medium OK

TIMETABLE Bus schedule is difficult to see and to understand. Icons don’t clarify the content. The information of the table is not clear: it is supposed that is the time in which the bus passes through that stop?

Improve Icons

Add help about the search and about the result and the meaning of icons

Ensure that there are no conflict with the meaning of other icons

Medium OK



SECTION/ TASK


VALIDATION It is confusing that, after login, the system tries to capture the position. User tends to abort the operation

Login should give access to an intermediate screen in which you can confirm that you want to perform a validation (in order to avoid to capture the position immediately and avoiding errors)

Medium/high OK

VALIDATION Some users did not read the instructions and went directly to QR code instead of simply approach the card

Improve the design/layout: instructions and questions

High OK Modify Validation screen will have three big buttons: • Validate with NFC • Validate with QR

code • Cancel

VALIDATION Some users did not understand the questions after approaching the NFC card. It was also for them difficult to distinguish that there were 2 questions. Moreover, the buttons were partially out of the screen.

Improve the design/layout: instructions and questions

High OK Modify

Layout will be changed, to make the questions successive and clearly distinguishable.

Additionally, the “continue” button will change so the text is clearly legible anytime and it will be easy to identify whether the button is active or not.

Table 1 - Prioritized improvements and implementation status.



3. REFINEMENT OF SERVICES

3.1. GENERAL ASPECTS

3.1.1. Needs identified In order to ensure a good performance for SIMON LEADS and SIMON CONTROLS, it was clearly identi-fied that those applications needed to cache some static information (data that change very unfre-quently) in the local storage of the smart phone Changes applied, instead of requesting them from SIMON services each time they were needed.

Such information shall be initially stored in the SIMON Backoffice database, that shall always contain the reference updated that for all systems, that shall retrieve the from SIMON Backoffice the first time they need them.

Then it was clear that an additional mechanism was required in order to ensure that the SIMON LEADS and SIMON CONTROL applications are informed that the static data in SIMON Backoffice database was changes and that they need to retrieve it again to update their caches.

For these purposes, an additional “Static Data” service was implemented in the SIMON Backoffice and offered to both SIMON LEADS and SIMON CONTROL applications.

3.1.2. Changes applied An additional “Static data” service was implemented in the SIMON Backoffice application, offering methods for getting access to the following elements of the data model:

• Parking spots (static information: identifier, name, coordinates, type, address, characteristics)

• Parking lots (static information: identifier, name, shape coordinates, type, total number of spaces per type)

• Parking spaces (static information: identifier, name, shape coordinates, type, total number of spaces per type)

• Access controlled areas (identifier, name, shape coordinates)

• Administrative divisions of the cities

• Types of infractions supported for registration (for SIMON CONTROLS)

• Supported characteristics of vehicles (brands, models, colours) supported for registration of infractions (for SIMON CONTROLS)

In order to ensure the correct synchronization between SIMON BACKOFFICE ant the cached data stor-age managed by the SIMON LEADS and SIMON CONTROLS applications in the users’ smartphone, the following mechanism was implemented:

• Each of the above mentioned sources of information is associated with a “data set” resource, and a version number is assigned to each data set.

• Applications may query the service for obtaining the current version of each “data set”, in order to check if it is higher that the version of the cached information, what would indicate that the information has changed and the data need to be retrieved again.

• For convenience of the applications, data sources are classified per model (“Parking”, “Access control”, “Shapes”, “Controller data”), what allows querying only the data sources of interest for the application at each time depending on the functionality in use.

3.2. REFINEMENT OF SIMON SAYS



3.2.1. Needs identified During the process of integrating services and data sources, developers of SIMON SAYS identified some needs that had not been identified during the specification phase or not enough carefully considered during the design phase.

• During initial integration phases, it was decide to simplify the architectural design by integrat-ing the functionality of the “SIMON CONTROLS front end”, the set of services offered by SIMON Backoffice to the SIMON CONTROL application, into the SIMON SAYS service.

• The identification of the end of a parking validation was more important that it was considered in the specification and design phase. This aspect is crucial for both the production of reliable car park spaces availability information and for fraud fighting.

o The occupancy status of car park spaces reserved for disabled people is managed by SIMON SAYS (although provided to the users by SIMON BOOKS), by controlling when users validate in the spot and when they leave it. As a consequence, a good control of when they leave the spot is crucial.

o To avoid misuse of the EU badges of mobility impaired users it is essential to detect or avoid the situation when different persons make use of forged copies of the badge to park simultaneously at different locations. This is only possible if SIMON SAYS has some control of when the user has really left one location before parking in another location. In this sense, it was decided that SIMON SAYS had to force users to confirm the ending of any previously active validation before letting him or her to begin a new one.

o The role of parking controllers in the identification of the real status of a parking spot is of great importance, and can be also very useful for identifying when a mobility im-paired citizen has really ended the use of parking spot but not notified it to the system. As consequence, it was clear that the service needed to be improved to enable the controllers indicate that a parking spot is free, occupied by the vehicle corresponding to a particular registered validation or occupied by a vehicle that has not validated in SIMON.

o An addition reason for enhancing the importance of the role of controllers managing the occupancy status of parking spot is that SIMON SAYS should never assume that the beginning of a validation by a user implies the end of a previous validation made by another user at the same place. The reason to this is to avoid that a malicious user uses the feature to end another user’s validation and put him in a fraud status. As a consequence, only a parking controller is trusted when indicating that a spot is free, or occupied by the same vehicle that made a particular validation.

• Some features of the services and application need to identify the city to which the user be-longs. In some case, in order to check the permission of the user to execute an action (e.g. controllers work only for one city and may report infraction in that city), or to avoid the neces-sity of capturing the GPS position of the user if just knowing in which city is located. For that purpose, it was decided that the login feature of the SIMON SAYS service should take into consideration the associated of the user with a particular city.

• In order to make more difficult the forging of fake EU badges, it was clearly identified that the content of QR codes printed on the badges should not contain any information that could be obtained from other information printed in the card (like the user ID), nor contain other secu-rity information like the identifier of the NFC tag. As consequence, the QR code had to be managed as a separate type of security token.



• In order to reduce the amount of sensitive personal information managed by SIMON, it was decide to avoid registering in SIMON database any identify information of the user. The draw-back of this decision is that it makes it more difficult to coordinate with the municipalities in the task to manage the database of authorised users. To facilitate that coordination, it was decided to introduce an additional item in the definition of users in SIMON Backoffice database devoted to contain a “record ID”, a unique identifier of the user that the municipality can use for matching the definition of the user in their own internal database of authorised users.

• In order to facilitate the initial registration if SIMON users in the system, without compromising the security of the system or the users’ privacy, it was decided that:

o Users would be registered initially in the SIMON Backoffice database with a temporary password provided by the authority operator.

o SIMON LEADS, when executing the user login for the first time would be informed that the password is provisional, and request the user to provide the final one, which would be kept secret by the system.

• The participants in the small scale tests for SIMON CONTROLS applications (see D5.2 Small Scale Piloting, (5)) pointed out the need of adding a feature to the application that enabled controllers to report incidents or send suggestions to the SIMON platform.

3.2.2. Changes applied

• All the functionality of the services that SIMON Backoffice had to provide to SIMON CONTROLS in the original architectural design were finally integrated into SIMON SAYS.

o Checking the validity of EU badges and the existence a parking validation for each parking vehicle

o Reporting infractions

o Setting the occupancy status of a parking spot:

Inform that a spot is free, ending any active validation registered in the spot

Confirm that the spot is occupied by the vehicle corresponding to the active validation, ending any other active validation registered in the spot

Inform that the spot is occupied by a vehicle that has not made any validation in SIMON, so any active validation in the spot should be ended

o Reporting feedback to the SIMON platform (incidents or suggestions)

• SIMON SAYS shall not accept an attempt by a user to validate at a parking spot until any pre-viously existing active validation is previously ended.

• The SIMON SAYS management of validations uses an additional property for an ended valida-tion, that indicates whether it was ended in a normal way (the user reported the ending at the time of leaving the parking spot), by the user with delay (hours or days later, may be at the time of initiating a new validation), or by a parking controller (that reported that the spot is free or occupied by another vehicle).

• The “login” method provided by SIMON SAYS:

o Accepts an additional parameter containing the city to which the user is expected to belong, in order to check that he or she is actually registered in SIMON Backoffice da-tabase for that city.

o Returns a response that contains the city to which the user is associated, allowing the SIMON LEADS or SIMON CONTROLS application to locate the user at a particular city.



o Returns a response that contains an attribute that indicates whether the password of the user is provisional and should be changed by the user.

• The methods for validating users identify in SIMON accept two new ‘types of token’ defined for values of QR codes and “record IDs” of the users.

3.3. REFINEMENT OF SIMON BOOKS Because none of the pilot site cities provide any possibility of making pre-reserves of parking spots, neither at on-street or private car parks, finally no functionality of this kind was implemented in SIMON BOOKS.

Regarding the real time information about parking spaces, it was simply reoriented to provide SIMON LEADS with the most efficient access to the information, tailored to its needs and the integration with the navigation functionalities.

For that reason, all SIMON BOOKS methods are oriented to provide the parking spaces available around a particular position and within a given range requested by SIMON LEADS.

To avoid the need by SIMON LEADS to store in the storage space of the smart phone of every user the static information about all the parking spaces in the city, it was decided to include in the definition of SIMON BOOKS service some methods that, when providing the information about the available spaces in an area, include both the static and dynamic information about the parking spaces.

3.4. REFINEMENT OF SIMON OPENS

3.4.1. Needs identified As it was anticipated in deliverable D4.1 (1), the SIMON OPENS service had to be reoriented in order to replace the functionality related to barriers with functionality for interacting with access control systems based upon number plate recognition.

The main purpose of this functionality is:

• To experiment with an innovative strategy for fighting fraud in the access to restricted areas, consisting in checking that the user is personally entering the restricted area, and thus the EU badge is not faked or misused.

• To provide end users with a convenient way to manage the request access to restricted areas with vehicles different of those they normally use and that are registered and associated to them in the municipality databases, by using SIMON to register a temporary association with a number plate.

3.4.2. Changes applied The method offered by SIMON OPENS to the users for requesting access to an area accepts the follow-ing input parameters:

• Initial date and time of the time window during which the user expects to get into the re-stricted area

• Final date and time of the time window

• Identifier of the area to which access is requested

• Number plate of the vehicle

3.5. REFINEMENT OF SIMON ANSWERS In the following, we describe the refinements of the SIMON ANSWERS service that have been imple-mented during the last months. Most refinements were either motivated by additional data sources



and data types that have been integrated from the target cities or by usability or scalability issues that resulted from the integration of additional data. In response, we have implemented new adapters to integrate the additional data and we have modified the internal implementation of the affected ser-vices. A key goal thereby was to keep the existing interfaces to service endpoints (where possible) as is and only modify the internal realization.

3.5.1. Needs identified As indicated previously, the refinements of the SIMON ANSWERS services were motivated primarily by the continued integration of additional data sources and data types. Due to this integration, several services and data adapters turned out to exhibit a sub-optimal implementation. Specifically, we found that the following services and adapters needed some refinement:

• Search Endpoint: The search service endpoint enables SIMON LEADs to resolve free form strings into places with WGS84 coordinates. In the first version, the search endpoint was using a context-free ranking for the search results, which required users to specify city names explicitly. This turned out to be cumbersome on mobile devices.

• Routing Endpoint: The car routing algorithm used for the first version of SIMON ANSWERS exhibited several deficiencies and the overall scalability of the algorithm turned out to be suboptimal. In addition, the interface of the endpoint was extended to enable the integration with the parking data of the cities (thereby enabling the computation of alternative routes to parkings nearby a destination). Furthermore, the route output was extended to not only in-clude street names but also street types (e.g. in order to create route summaries that only highlight highways). [new in v2.0] Finally, the routing endpoint was extended with indoor rout-ing in order to support the navigation in and across buildings.

• Data Import: As basis for transit routing, the routing endpoint was using a GTFS adapter that enabled the import of transit stops into the search index. For this, a static city name was pro-vided to assign stops to cities. However, it turned out that for large data sets such as the ones available for Parma and Madrid, the transit data not only encompasses a single city but a larger region consisting of multiple cities. To deal with this, the GTFS adapter was extended to dy-namically assign correct city names during import based on the WGS84 coordinate of the transit stop. [new in v2.0] In addition, a specific tool was developed to compute a GTFS file from 660 PDF files describing the interurban bus schedules in Madrid.

3.5.2. Changes applied Based on the needs identified, the following additions and modifications where implemented:

• Search Endpoint

o Addition of context-aware (local) search: To support the context-aware resolution of places, the search algorithm was extended with a second stage that ranks places re-solved in response to a query based on the position of the user. Towards this end, the search API has been extended with a second optional parameter enabling SIMON LEADS the specification of the user’s current GPS position. If this parameter is pro-vided, the resulting locations are ranked by several factors including the distance of the location from the user’s position. As a result, the search algorithm no longer re-quires the specification of a city in order to resolve addresses. Instead, the user can simply type in (parts of) street names, for example, in order to find suitable local re-sults.

o Improved search performance: As a result of the integration of a context-aware search, the search performance of the original resolution strategy degraded signifi-cantly. In response to this, it was necessary to replace the original HSQLDB-based



backend with a faster alternative. Towards this end, the backend of the search end-point was replaced with a new implementation that leverages the capabilities of the Apache Lucence full-text search engine. This engine turned out to provide a much bet-ter scalability and a significantly faster multi-index intersection that is necessary in or-der to drive the local search.

o Integration of transit and parking data: To further enhance the user’s search experi-ence, the additional data sources related to parking and transit data (i.e. parking place and transit stop locations) were directly integrated into the search index. Towards this end the index structure was extended with additional attributes to enable the search through these data sets as well. In addition, the API was extended accordingly to spec-ify that the search should only be executed on some parts of the data (e.g. search only for stops or parkings, etc.). Finally, the search interface was extended to support the retrieval of all places of a particular type in a particular target area. This can then be used to create map overlays as depicted below.

Example overlays in Madrid with transit stops (yellow), access to subway stations (blue), and parking places.

Created by querying the search in-dex for all places in a particular area such as the map’s viewport, for ex-ample.

• Routing Endpoint

o Improved OSM routing performance: In order to improve the routing performance of the street router on top of OSM data leveraged by the SIMON ANSWERS routing end-point, an additional index was introduced covering only the larger streets (e.g. high-ways, interstate roads, etc.). Then, the routing algorithm was modified to dynamically switch between the previously existing detailed index and the more abstract index dy-namically such that close to the origin and destination points, the detailed index is used and in between, the routes are only computed using the abstract index. As a result, the overall performance of the algorithm for longer routes improved drastically and thus, computing routes that span hundreds of kilometres can also be accom-plished in a few seconds.

o Improved road name extraction: To improve the output of the routing algorithm, the road name extraction algorithm was refined to also cover several special cases where



the OSM data is not optimally tagged. As a result, the output generated by the street router is now also able to provide street names in cases where this was not possible with the previous algorithm.

o API extension with road types: In addition to an improved road name extraction algo-rithm, the street router was also extended with the capability to return the street type as part of the routing result. This is useful in order to generate route summaries that only show the “important” roads of the route (e.g. the highways) which can help users to choose between different route alternatives more easily.

o Integration with parking data: Based on the availability of the parking data, the vehicle routing interface of the routing endpoint was extended to support the computation of route alternatives that lead to parking places. Towards this end, alternatives are gen-erated by determining available parking spaces in the vicinity of the destination and computing multi-modal (i.e. vehicle and walking routes) to the destination.

Example routing result with addi-tional (multi-modal) route alterna-tives.

Route 1 shows direct driving route to destination, route 2 and route 3 show alternative routes to parking places near the destination and in-clude a walking segment to get from the parking place to the final desti-nation.

o [new in v2.0] Indoor routing functionality: To support indoor navigation, the naviga-tion services have been extended with an additional routing algorithm that operates on the maps indoor model. This routing algorithm has then been integrated with the transit and street routing algorithm that previously computed routes such that walking routes may start and end in buildings and that transit routes may start, end or pass through buildings. Thus, an application can simply query for a route from an origin to a destination point and the resulting route outputs will consider not only the GTFS and OSM data but also the indoor models that are available for a environment. If a part of a route passes through a building for which a model exists, the resulting route will contain the necessary route instructions to traverse it.

• Data Import

o Automatic discovery of cities: The initial version of the data import adapters made the assumption that data provided by the cities would primarily cover a single city. How-ever, this assumption turned out to be incorrect. For example, the transit data pro-vided by Parma encompasses not only the public transport options available in Parma



but instead covers the whole Emilia-Romagna area – which encompasses several large cities including Parma, Bologna, etc. The same was true for the parking data provided by Madrid, which also covers some outskirts of the city. As a result, the static assign-ment of city names to the data items contained in the imported data sets turned out to be invalid and thus, had to be replaced. To do that, we have rewritten the data adapters to rely on the search index to locate the individual places contained in the sets. Towards this end, nearby places in the search index are analysed for their city, region and country name and the result is assigned to the data items that shall be imported. As a result, the data items imported from a single data set are automatically assigned to different cities. Of course, the overall import now takes significantly longer since for each data item in the data set, it is necessary to run (at least) one query for nearby places in order to detect the correct city.

o Automatic renaming of transit stops: In addition to automatically resolving the appro-priate city name, we also extended the GTFS based data import adapters to dedupli-cate non-unique transit stop names by automatically assigning alpha numeric exten-sions. This enables the user to memorize the extension in order to revisit a previously found stop more easily.

Example search result for transit stops in the Emilia-Romagna area.

Transit stops are automatically as-signed to cities (e.g. Parma, Boretto, Castelguelfo) based on their posi-tion.

Multiple stops with identical names and cities are extended with A, B, C, etc. to simplify the (re-) identifica-tion of a particular stop.

o [new in v2.0] Interurban bus schedules: The schedule data about the interurban bus connections in Madrid turned out to be only available in PDF format. In order to make this data usable for routing, an additional data adapter has been developed that ex-tracts the raw data from the PDF files and fills in missing information (such as the exact stop times, trip durations, etc.) using suitable heuristics. Since the resulting schedules may be imprecise due to this heuristic approach an additional incident feed has been integrated that provides “route incident warnings” for routes that leverage this data. This incident feed enables user to retrieve the PDF via a single tap in the Simon appli-cations.



4. REFINEMENT OF APPLICATIONS

4.1. SIMON LEADS In the following, we describe the refinements of the SIMON LEADS application that have been imple-mented during the last months. Most refinements were either motivated by the availability of addi-tional services that have been finalized or by the results of the tests with the end-users conducted in the different cities. In response, we have added the additional features enabled by the SIMON services and we have integrated solutions for important problems reported by the end users. The key goal thereby was to ensure that the SIMON application is fully functional for the deployment of the large-scale pilot while providing an initial set of usable interfaces to the end users.

In the following, we first outline the new functionality that has been added to the application before we discuss the improvements on the existing functions of the application as well as the IOS version of the application. To avoid overlap with other deliverables, we refrain from providing a detailed rationale for the changes that led to improved functions. Instead, we only mention the usability problem that has required the implementation of the corresponding change. However, since the initial tests were executed with a limited size user group, it is important to mention that the specific details of the user interfaces are subject to change, especially, in cases where the initial group of end users has not dis-covered all significant usability issues.

4.1.1. Extended Application Functions With respect to extended functions, the refined version of the application encompasses three new features.

The first one is the implementation of requests to access controlled zones via the disabled badge. For this, the application implements a process that is analogous to the validation process where the device is used to capture the user’s position and determines the access controlled zones in the vicinity. If zones are available, the user can select the desired zone, provide a license plate and specify the timeframe during which the access occurs. To specify the license plate, the user can type in a new plate or select from the recent history of plates that has been used with the application. The following screenshots highlight this process.



Figure 1 – Requesting Access to a Restricted Zone

The second feature enables users to review the usage history of their disabled badge with respect to validations and access requests to restricted zones. Towards this end, the application provides two new views implemented as part of the information perspective. The views show the begin and end times of the validation or the respective access permission to a zone. In addition, they show the parking (for validations) and the zone name and license plate of the registered vehicle (for access control). When the views are accessed for the first time, the associated data for the current logged in user are automatically loaded from the SIMON services. Thereafter, the user can press the refresh button at the top of the screen to load the lasts data items. The following screenshots highlight this new feature.

Figure 2 – Reviewing the Usage History of the Disabled Badge



[new in v2.0] The third feature enables users to navigate through an indoor environment that is equipped with a suitable iBeacon deployment. As basis for navigation, the application has been ex-tended with a hybrid positioning service that combines GPS positioning with iBeacon-based position-ing. This service automatically detects the presence of beacons and dynamically switches between GPS and iBeacons depending on their availability. To support multi-floor buildings, the position computed with the iBeacons extends the 2D position of GPS (latitude, longitude) with additional 2.5D information about the current floor (level). This information is then used to show a suitable overlay on top of the outdoor map with the indoor floorplan. Towards this end, the map visualization in the app has been extended accordingly. To determine the available overlays for a given map view, the application auto-matically downloads a building model upon start up. The building model contains the information about the location of the buildings as well as the floors. The model is then interpreted to create level switching buttons based on the current viewport of the map. Since the building information is only relevant for more detailed map representations, the interpretation considers the current zoom level and hides the overlay when the map is zoomed out. This is depicted in the figures below which show the same location (i.e. the Moncloa interchange station) at different zoom levels.

Figure 3 – Indoor Maps

[new in v2.0] The indoor navigation feature, however, not only provides a visualization of the user’s position but also includes the computation of end-to-end routes as well as the automatic trip tracking with step-by-step voice instructions. To enable this, the different views of the application have been extended to work with the 2.5D representation such that users can select origin and destination points not only on the outdoor but also on the indoor maps. In the navigation services, both, the street router and the transit router, have been extended accordingly. Furthermore, a new trip modality has been introduced into the routes that is used to represent trip segments within a building. In extension to regular (outdoor) walking segments, these parts of the route include additional details about the levels (which can then be used to draw different path segments on the overlay maps) as well as the level transitions (which can then be used to generate detailed voice instructions such as “take the stairs to level -2” or “take the elevator to level -1”, etc.). The result is shown in the figures below which show a route in the Moncloa Interchange Station in Madrid that covers multiple levels together with the as-sociated route instructions that not only show the turns but also indicate the level transitions.



Figure 4 – Indoor Step-by-Step Navigation

To be suitable for mobility impaired users. The wheelchair access routing function in the routing op-tions has been integrated with the computation of routes such that users which enable this option will not be guided onto stairs or escalators. Similarly, a new route option has been included for vision-impaired users which will result in the generation of different paths that consider the floor markings of the building.

4.1.2. Improved Application Functions In addition to the new functions, a number of existing functions have been improved based on the user feedback. The improvements crosscut through the whole application and some of them affect multiple – if not all – views.

Since the test with end users has shown that there are some issues with the use of the logo as a menu entry in the main menu, we decided to revise the main menu to change the visual appearance of the home button such that it becomes more apparent that it also represents an interactive element. More-over, due to the fact that the discoverability of the main menu has been reported as being suboptimal, we have extended the number of functions that are directly accessible via the home screen. This way, it is not necessary for less advanced users to find the main menu in order to access the different views. Instead, they can simply go back to the home screen and then navigate to the desired function. The following screenshots show these changes.



Figure 5 – Improved Menu and Home Screen

In addition, the tests also indicated issues with the application settings. Since users reported them to be confusing and hard to understand, we went to each of the available settings. Thereby, we followed the following strategy. First, we considered whether a setting was absolutely necessary. As it turned out, in this stage, we were able to remove several settings by either optimizing the application (e.g. a help related setting could be removed by ensuring that all screens exhibit a context-sensitive help to describe it) or optimizing the underlying algorithms (e.g. the text to speech settings were reduced from 3 to 1 by performing a better analysis of the available hardware features and the tracking and sensing settings were reduced from 4 to 1 by making the tracking algorithms adapt to the GPS precision re-ported by Android). For the settings, which we could not eliminate, we decided to regroup them in a more logical fashion and we modified their names and descriptions to (hopefully) improve the clarity. Finally, in order to support the further testing with users in different cities, we introduced a setting to manually select the city (instead of using GPS-based auto-discovery). The following screenshots show the results.



Figure 6 – Improved Application Settings

Besides from these more targeted changes, we also performed a large number of crosscutting optimi-zations and introduced several fixes for issues discovered during testing. In order to improve the read-ability of the texts in all views, we modified the colour scheme of the controls to make the texts blacker and less transparent. For some views (like the main menu) where this approach was not possible, we introduced a black drop shadow to ensure that the resulting contrast is high despite having a bright colour on a white background. Thereafter, we revisited all controls of the application and modified their backgrounds to ensure that interactive elements are always highlighted through a 3D drop shadow element. Furthermore, we ensured that for confirmations the element is green and for cancel operations, the element is red. Moreover, we introduced a number of fixes to handle layout issues discovered by running the application on different versions of Android. For example, the drop shadow of the action bar was not visible when the action bar operated in tab mode. Similarly, due to a bug in the application compatibility SDK some of the dialogs were not correctly modifying the navigation bar colour on devices running Android 5 and above. Last but not least, we revised all help screens of the application and ensured that the associated help text is correct, meaningful and (hopefully) easy to understand and we introduced help for screens that previously did not have one or were introduced as a result of the changes. The following screenshots show some of these changes.



Figure 7 – Improved Consistency, Contrast and Help

Furthermore, to handle some of the usability issues discovered when using the application in indoor environments, we rewrote significant parts of the positioning logic to not only rely on GPS but to make intelligent use of other sources of location information. As a result, the application typically responds more quickly. Furthermore, during the redesign of the logic, we also tapped into some of the sensors on devices that have them available. In particular, we decided to implement a bearing function using the GPS (while the user is moving) or the magnetometer (when the user is not moving or moving very slowly). This bearing information is then visualized on the map using different symbols (a dot, if the device is not moving and has no magnetometer – a dot with an arrow, if the device has a magnetom-eter but is not moving or moving slowly – and an arrow, if the device is moving fast). The result is depicted below.

Figure 8 – Improved Background Positioning and Visualization



[new in v2.0] Finally, to improve the usefulness of the map-based visualizations, the marker overlays shown on the maps have been extended with more details on different location types as well as real-time information on the parking availability. The former includes new locations types to represent stairs, escalators, elevators, restrooms, building entrances, security gates, information desks, etc. Thereby, the location types may exhibit different subtypes to indicate directionality (e.g. escalator go-ing up) or other details (e.g. women restroom, men restroom, etc.). The real-time parking availability information is indicated by a color scheme that shows available parking spots green and occupied parking spots red. If the occupancy information cannot be determined, the parking spots will be shown in white.

Figure 9 – Improved Marker Overlays

4.1.3. IOS Version [new in v2.0] To address the user requirement of supporting a broad range of device platforms, an IOS version of Simon Leads has been developed. The IOS version closely mirrors the features available on Android. However, due to the lack of NFC reader APIs on this platform, the badge scanning function-ality can only be provided via QR codes. To mitigate the possible loss of ease of use, a 3D touch launch-ing functionality has been integrated into the IOS version which enables users to directly access the badge-related functions. To ensure a consistent look and feel when comparing Simon Leads with other IOS applications, the color scheme of the IOS version has been slightly adapted and the application is using the native controls for buttons, tables, etc. Structurally, however, the implementation refrains from making changes to minimize the need for separate end-user testing. The figure below show some of the screens of Simon Leads on IOS.



Figure 10 – IOS Version



4.2. SIMON CONTROLS In this section we describe the improvements of the SIMON CONTROLS application that have been implemented due to the results obtained from the tests with the controller-users in the different cities. Additionally, the application has been upgraded to add new functionalities that enhance the user ex-perience and ease its use, especially regarding the amount of data to be introduced and number of needed steps to achieve the final statement. These changes will serve the controller to do his task faster and more secure, in the meaning of misspelling or wrong data typed.

4.2.1. Improvements and new features Two new buttons have been added to the main menu for direct access to report an infraction and send suggestions as feedback. The “Report infraction” button is needed in those cases where a badge is missing or could not be read; that way the controller can directly enter into the form to fill the required fields of the reporting infraction. That form is the same as the obtained after a verification of an invalid validation.

Figure 11 – Main menu with additional features

As a result from the tests with users, a “Suggestions” button has been included to easy report feedback about different issues, whether related to the application itself, or related to their tasks of controllers, such as reporting a new type of infraction detected. When the button is pressed, a form is opened to enter the desired observation. It contains a drop-down list to choose the subject of the message that is useful to organize and deliver the message to the appropriate responsible when it is received in the server.



Figure 12 – Suggestions form

The report infraction section has been enhanced to reduce the “manual” data that has to be entered by the controller to complete an infraction report. Most of the fields have been changed to a drop-down list control. It is much easier for the controller to choose a predefined value instead of entering each time a couple of words. It also avoids typing mismatches of the same value among controllers. Information like car models, brands and colours are internally handled with identifiers, but in the ap-plication are shown as strings, which are configured in the database. Thus, every controller will have the same text on the lists, and in case that any item has to be changed, it will be modified once on the database and automatically updated in the application, without the need to upgrade the full core of the application.

Due to the particularities of each city collected in the tests with controller-users, this form is built dy-namically to show different required fields depending on the provenance of the controller that has logged in. For example, Madrid requires a lot of fields, including vehicle model, vehicle brand, colour, license plate, address, infraction type, etc. On the other hand, Lisbon requires only two editable fields, vehicle category and a textbox for observations with wide text length. That way it has devoted an additional effort to adapt the application to the needs imposed by each city.



Figure 13 – Report infraction form customized for Madrid and Lisbon

4.3. SIMON AUTHORITY OPERATOR WEB APPLICATION [new in v2.0] SIMON Backoffice integrates a Web application offered to the local mobility authorities that provides their operators with:

• A tool for maintaining the database of registered users (citizens and controllers) and their iden-tification tokens (phones, QR codes, NFC tags).

o Registering and unregistering users

o Modify or correct existing users information

o Register, modify or update the identification tokens of each user

• A set of dashboards for evaluating the performance and relevance of SIMON system regarding fraud fighting in parking and access to restricted areas.

Implemented as a Web application, the SIMON Authority operator Web does not requires any specific installation or deployment effort in the computer of the user, and is even compatible with other de-vices such as high-performance tablets.

The application requires the authentication of the operator by means of a user name and a password, in such way that only authorised users have access to the information managed by SIMON. Regarding the management of registered citizens and parking controllers, each operator user is associated to his/her city and has access granted only to the users registered for that city.



Figure 14 SIMON Authority operator Web application: management of registered citizens

The management of citizens and controllers, as well as the skeleton of the application, were developed using Meteor technology, an open source framework for the development of attractive and dynamic web application based upon HTML5.

For the presentation of performance dashboards, a commercial business intelligence suite called Mi-crostrategy was used, which was configured and adapted to read and process the historical infor-mation stored in SIMON Backoffice (conveniently anonymised) and generate dynamic, attractive and useful graphs and reports, conveniently designed for the purpose of the project and the requirements of local authorities.

The dashboards prepared for the local authority operators were:

• Evolution of the frequency of usage of SIMON system by citizen users during the duration of the project, per month, week and day, and per city

• Number and average duration of parking validation using SIMON, per month, week and day, and per city and/or type of parking space (reserved for mobility impaired citizens or not)

• Number and proportion of parking validations per neighbourhood, per month or week, and per type of parking space (reserved for mobility impaired citizens or not). This dahsboards provides both graphical and map display.

• Number and proportion of parking validations per token type (QR code or NFC)

• Number of validated accesses to restricted zones, per day, month and week and classified per zone.

• Number of infractions reported by parking controllers, per month and week, and per control-ler.

• Number of parking validation checks made by controllers, per month and week, and per con-troller.



Figure 15 SIMON Authority operator Web application: evolution of parking validations dashboard

Figure 16 SIMON Authority operator Web application: parking validations distribution per

neigbourhood dashboard



5. CONCLUSIONS During the period between the publication of deliverable D4.1 and the preparation of D4.2 an important effort has been spent in the integration of the SIMON services and applications, in order to make them ready for the execution of small scale pilot tests. By the way, the development team identified a number of potential weaknesses in the design that were corrected on the fly.

The small scale pilot tests were designed and executed and are described in detail in deliverable D5.2. They produced an important set of conclusions regarding the usability of SIMON applications that have been taken into account and motivated some improvements in the software.

All redesigns and modifications have been reasoned and described in the present deliverable D4.2. As part of the reasoning, a summary of the small scale pilot tests and their conclusions is also included. These have been the starting point to start an in-deep analysis to find the best way of improving the app usability while also refining the SIMON services.

As a final step in the adaptation to the cities infrastructures, the new refined services are being deployed and the new versions of the citizen and controllers apps are ready to be used. D5.3 will describe the different integration and adaptation activities carried out at each of the pilot sites.

After this effort, the SIMON platform is ready for facing the wide scale piloting phase with reasonable expectations of success.



6. REFERENCES AND ACRONYMS

6.1. REFERENCES 1. SIMON Consortium. D4.1 ICT Services and Applications. 2. —. D5.2 Small Scale Piloting. 2015. 3. —. D2.2 Preliminary Set of Requirements. Brussels : s.n., 2014. 4. —. D2.3 Requirements Specification. Brussels : s.n., 2014. 5. —. D5.1 Deployment and Adaptation Plan. 2015.

6.2. ACRONYMS

Acronyms List

API Application Programming Interface

EU European Union

GPS Global Positioning System

GTFS General Transit Feed Specification

HSQLDB Hyperthreaded Structured Query Language Database

ICT Information and Communication Technology

MMS Multimedia Messaging Service

NFC Near Field Communication.

OMS OpenStreetMap

QR Code Quick Response Code

SDK Software development Kit

SMS Short Message Service

WGS84 World Geodetic System 1984



ANNEXES

I. ANNEX 1. INCIDES AND IMPROVEMENTS DURING USER TESTS OF SIMON LEADS TASK INCIDENCES IMPROVEMENT PROPOSALS TASK 1. APP ACCESS, MENU, SETTINGS AND EXIT

• Lateral menu difficult to find. • Small font size • Icons are difficult to understand. • (+) Very good settings options • (+) Easy

• Increase font size and icons • Clearer icons for the main menu and lateral menu (or

the word “menu”)

TASK 2. SEARCH FOR HELP

• (+) Good way of arrange help contents • Help button is in lateral menu: difficult to find • Lack of global help/tutorials

• Ease the access to help button (visible from screen) • Add general help and tutorials

TASK 3. ACCES TO THE FEEDBACK AND SEND AN EMAIL

• (+) Easy • Feedabck term is not very clear • (+) After sending the message the system goes back to the app • The location of the feedback is not intuitive. User expected to

have some feedback button on the actual screen.

• Should be possible to link a email account with the app and use it by default, in order to avoid questions to the user?

• Feedback when message is sent should remain visible more time, in order that user has time to read it.

TASK 4. NAVIGATE THROUGH THE MAP (ZOOM IN OUT)

• LACK OF ZOOM Zoom in (magnification) it’s not enough: seems that another zoom is needed

• Name of streets is not visible until the magnification is too high. Moreover, little streets are difficult to see

• Icons are difficult to understand: zoom in/out is not comprehensible. Search icon seems to be a magnifying glass

• Too much information on map like rail tracks, tunnels or building profiles. It should be possible to choose which information appears

• This task cannot be done by blind users if the system does not read aloud the data related with position of the user.

• Although double click on screen provokes zoom in, the frequency of double click was too fast for the user

• Symbols / buttons of zoom in/out disappear when is a marker on the map

• More zoom range: Add / lock another step of magnification Name of main streets should appear even with smaller zooms

• Use standard pictograms (universally accepted or easily recognisable). E.g.: google maps icons are easier. Substitute the “lens” symbol for other not similar to zoom. Make clearer symbols of zoom in/out

• Number of streets should be indicated to improve orientation in long streets, and also to make the searches and routes.

• Allow a slow double click to zoom • Pop up with more information when clicking in map (or

clearly show the information)



TASK 5. SEARCH FOR AN ADRESS OR BUS/METRO STOP

• Very slow process • Icons are not clear:

o Bus icons (yellow) and metro (blue) are not comprehen-sible/differentiated

o Icons of bus, metro, parking doesn`t appear until zoom is too close

o Parking space icon is not easily visible and the meaning is also unclear

o Help in this area does not indicate the meaning of icons • Secondary functions (set as origin… etc) are not evident nor

visible (hidden) • Writing the name of the city first is uncomfortable • Too much search results • The predictive search result list is very sensitive: when user tried

to scroll through the list clicked by mistake to an undesired address.

• Some sub-menus appear and disappear… • Map aesthetics is bad • Lack of Lisbon information

• Change /improve icons: o Icons of metro and bus should be clearly dif-

ferent o Icons should appear with less zoom o Secondary functions when clicking an icon

should be more visible o Use “P” for the parking places o Add information about meaning of icons and

secondary functions at the help (1) • When user indicates an “origin” should remain active

and don’t disappear during search • System should keep last position for if the case that

user is inside a building without GPS range • GPS activation should be indicated • Substitute coordinates with directions. • The user should be able to define the “by default” city

to make searches • The user should be able to filter the search results

initially (everything, streets, stops,…) • Improve map aesthetics • More zoom range

TASK 6. VIEW THE STOPS NEAR A POINT IN THE MAP

• The arrow in the search field seems to have the “go” function, but it is only a picture without functionality

• Information about the bus stop (or street…) that appears below when selecting a point/marker is not clearly visible (not highlighted, low contrast) and (once seen) user tend to think that it is clickable, but it isn’t)

• Zoom buttons disappear when a marker pin is on map • User did not notice about the “clock” button for the schedule

(that appears when a bus marker is selected) • The colour of the icons and also the symbols are not very

intuitive/visible, especially the parking spaces

• The information about the stop that is shown in the lower part of the screen should be:

o Clearly visible (and user should be aware of the changes when clicking another stop).

o Clickable: clicking there should at least open some options (set as origin, see information,…) similar to those that appear at the … menu. For example: − If corresponds to a STREET or place: should

open the options “set as origin”, “set as destination”, “detailed info”



− If corresponds to a PARKING SPACE or place: should open the options “set as origin”, “set as destination”, “detailed info”

− If corresponds to a BUS/METRO STOP: should open the options “schedule/stop information”, “set as origin”, “set as destination”

o Another option is to use “pop up information” when clicking a marker or point in the map.

• Store the last search • Improve colours and symbols of icons (stops, parking

spaces…) TASK 7. SEARCH FOR WALKING ROUTE

• Route sub-menu was not clearly visible • Typing/selecting an address is slow and requires a lot of effort.

List of streets is very sensitive (clicks by mistake were frequent, the list appears and disappears suddenly). Writing the name of the city first is uncomfortable

• Secondary functions on each screen are very interesting but not usable as the user don’t see them and does not k now that they are available

• Search Route options are not intuitive nor ordered in the logical way

• There’s no way of going back to the previous screen. Back but-ton leads to main screen. Moreover, going back deletes search options

• Icons that appear in search results are confusing. Moreover, some are clickable and others not. Icon for “route” is small and has low contrast

• If you search for a street, and go back this search is not kept and you have to type it entirely again

• System should register the real location of the user and offer it as “origin”

• Highlight the secondary functions • Change the order of the actions to perform the route:

first the mean of transport options (walking, driving,… as it is in google maps)

• System should ask for the street number • Improve the visibility of the different ways of moving

(driving, walking…) • Improve the symbols of icons in search results and

search and indicate clearly those with functionalities • Improve the alternatives of “set as origin/destination”

(see recommendations for task 6) • The user should be able to define the “by default” city

to make searches • FAVORITES LIST: Options should include “set as

origin”, “set as destination” and “see” • Try to keep the last search in memory, for if the user

goes back by accident, in order that does not need to type it again

TASK 8. SEARCH A BUS

• Bus schedule is difficult to see and to understand. Icons don’t clarify the content. The information of the table is not clear: it is

• Increase font size in results



TIMETABLE supposed that is the time in which the bus passes through that stop? Small font size in results

• “Enter/done” key in keyboard sometimes erase the entered data

• System don’t ask for the city when searching a stop. Does the system know that you are in Madrid?. The city for search should be defined first

• Knowing the name or number of the stop is difficult. In general is difficult to search only with the keyboard. It should be possi-ble to browse by categories (type of transport) or to search by bus number

• Information about public transport was very poor

• It should be available an option to choose/filter the types of transport preferred

• Ease the search of stops: filter by city first, browse/search by type of transport, bus number, ad-dress nearby,…

• Differentiate BUS and METRO icons. In general im-prove the icons.

• Improve connections between Navigation/Map and “information” features

• More information about public transport, including: o Accessible lines o Lines’ routes o Accessibility issues o Real time schedules (when will the bus arrive

to a stop) TASK 9. LOGIN IN VALIDATION

• (+) Easy and simple • It’s confusing that, after login, the system tries to capture the

position. User tends to abort the operation

• Login should give access to an intermediate screen in which you can confirm that you want to perform a val-idation (in order to avoid to capture the position im-mediately and avoiding errors)

• It should be possible to register/login using the NFC card instead of (or in addition to) writing a username and password

TASK 10. VALIDATE PARKING USING NFC

• (+) Process simple and easy. • Some aspects are confusing, because user doesn’t know what

the system is doing • Some users didn’t read the instructions and went directly to QR

code instead of simply approach the card • Some users didn’t understand the questions after approaching

the NFC card. It was also for them difficult to distinguish that there were 2 questions. Moreover, the buttons were partially out of the screen

• Add an intermediate screen with a menu in order that the user can choose the action that he wants to per-form.

• It should be possible to keep the position of the park-ing space that you have validated, in order to ease the return to the car (e.g. adding the position automati-cally to “destination”)

• If you are moving without having said that you left the parking space, the GPS should notice of that and warn you

• Improve the design/layout: instructions and questions



II. ANNEX 2. INCIDES AND IMPROVEMENTS DURING USER TESTS OF SIMON LEADS AT EACH PILOT SITE

TASK 1. APP ACCESS, MENU, SETTINGS AND EXIT

(Task 1: Access to the app. Locate the app and open it pushing the icon. Access the lateral menus, enter to some menu (for example the “settings menu” and go back to the home page. Exit the app..)

1) APP ICON

2) HOME

3) MENU

4) SETTINGS

5) HOME

6) EXIT

INCIDENCES PROPOSALS OF IMPROVE

MADRID • Problems of Access/usability not

detected . Process OK (2) • App icon is difficult to find (small size).

(2)

MADRID • Increase size of fonts, icons and

interactive areas. (2) • Design icons more easy to understand

for the main menus (2) • Support the lateral menú ítems with

pictograms / icons (1)



• Lateral menu has icons and words very small. Particularly “settings” options have very small font size. (2)

• Technical problems with Android operative system: does not make content scanning, auditory feedback is little understandable, tactile navigation is complex. …. (1)

• Very good settings options. (1)

• Label with audio all the possible navigation routes and the contents in fields (1)

• Rethink the content distribution on the main screen to avoid duplicities with the lateral menu. (1)

PARMA • Lateral menu was not easy to find (2) • Icon for the lateral menu was not clear

(1) • Easy. No problem (2)

PARMA • Clearly indicate the location of the

lateral menu with a clearer icon or word (2)

LISBON • Very useful for blind people • Lateral menu was not easy to find. Liked

the home page

LISBON • Indicate the word “MENU” in the home

page

TASK 2. SEARCH FOR HELP

Task 2: Search for help: access to the Navigation menu and search for help (using the lateral menu). Close help. Go back to Home page. 1) HOME

2) NAVIGATION

3) MENU

4) HELP


MADRID

• Help by blocks of contents/functions is preferred, so the information is closely related with what you want (4)

• Project Logo/drawing is used to “go home” but this function is hardly evi-dent nor visible for the user (2)

• Icons are not associated with their fun-ction in an intuitive way (2)

MADRID

• SIMON logo should be more evident that is clickable (e.g. a frame that indicates that it is a button) (2)

• Use icons more related with their fun-ctions, especially in Navigation (2)

• General help about how to use globally the app is necessary (very good for blind people, that learn theory before using) (1)



• “Navigation” pictogram is not associa-ted with the real function. (2)

• Help by function is barely useful for blind people. (1)

• There’s no specific button for “going back”. (1)

• Good that help is suited to the context. (1)

• Navigation/usability problems have not been detected. (1)

• Smartphone “back” button should be employed at the app to effectively go back (1)

PARMA

• If you don’t know that help is at the la-teral menu you won’t ever consult it (2)

• Close help button is not clearly visible, user tend to go backwards (3)

• Close help button was not easy to click (1)

• Go “Home” button is not present (1)

PARMA

• Help sign/button visible from the screen (1)

• Highlight close button and make it more sensitive (1)

LISBON

• No problems in general

• Information is not enough

LISBON

• Add more information about how to use the app (tutorials)

TASK 3. ACCES TO THE FEEDBACK AND SEND AN EMAIL

Task 3: Access to the “Feedback” and send an email with some content. Go back to the app. 1) MENU

2) FEEDBACK 1

3) FEEDBACK 2

4) SEND EMAIL




MADRID

• Ok, no problem (2)

• “Feedback” term does not let clear its functionality (2)

• User don’t understand the different al-ternatives of sending feedback: email, gmail,… (2)

• “Send message” icon is not evident (2)

• Good: that after sending the message the system goes back to the app (1)

MADRID

• Should be possible to link a email account with the app and use it by default, in order to avoid questions to the user (2)

• “Send message” icon should be more visi-ble and recognisable. (2)

• Alternatives to send feedback (e.g.: using the computer) (2)

• En la redacción del email indicar los cam-pos “Título” y “Texto”. (1)

• Feedback when message is sent should re-main visible more time, in order that user has time to read it. (1)

PARMA

• Problems using gmail and keyboard (external program) (2)

• The location of the feedback is not in-tuitive. User expected to have some feedback button on the actual screen. Locating the feedback at the lateral menu was not easy to find (1)

• OK (1)

PARMA

• Not SIMON problem: users should use an e-mail and keyboard app that is adapted to their needs.

LISBON

• Easy. No problem

• External program can be confusing. Ensure that once finished the action (send email) the smartphone goes back to SIMON LEADS where pre-viously was.

LISBON



TASK 4. NAVIGATE THROUGH THE MAP (ZOOM IN OUT)

Task 4: (Explore sub menu): Navigate through the map (zoom in/out). 1) HOME / NAVIGATION

2) EXPLORE

3) ZOOM


MADRID

• Name of streets is not visible until the magnification is too high. Moreover, little streets are difficult to see (4)

• Icons are difficult to understand: zoom in/out is not comprehensible. Search icon seems to be a magnifying glass (3)

• Too much information on map like rail tracks, tunnels or building profiles. It should be possible to choose which in-formation appears (2)

• General process is easy. (2)

• This task cannot be done by blind users if the system does not read aloud the data related with position of the user(1)

MADRID

• Name of main streets should appear even with smaller zooms (4)

• Debe indicar las vías principales con un zoom pequeño. (4)

• Use standard pictograms (universally ac-cepted or easily recognisable). E.g.: google maps icons are easier (3)

• Use Google maps to show the map and have then the possibility to have satellite view (3)

• Number of streets should be indicated to improve orientation in long streets, and also to make the searches and routes. (1)

PARMA

• Symbol confusion: user tried to make zoom using the “lens” symbol (inten-ded for search) (1).

• Although double click on screen pro-vokes zoom in, the frequency of dou-ble click was too fast for the user (1)

• Information doesn’t appear on map until is too close (2)

PARMA

• Allow a slow double click to zoom (1)

• Substitute the “lens” symbol for other not similar to zoom (1) Make clearer symbols of zoom in/out (2)

• Buttons of zoom in/out should not disap-pear from map (2)

• Big streets and avenues and also the city name should appear even with small zoom (2)



• Zoom in (magnification) it’s not enough: seems that another zoom is needed (the app does it, but goes back, it is not possible to keep it) (3)

• No problem. Intuitive to make zoom using two fingers (3)

• Symbols / buttons of zoom in/out disa-ppear when is a marker on the map (2)

• Symbols / buttons of zoom in/out are reversed (??) (1)

• The user did not realize what they were for the zoom buttons (2)

• More zoom range: Add / lock another step of magnification (3)

LISBON

• Information (when clicking in map) is not clearly visible

• Route menu complicated

• Lack of zoom (2)

LISBON

• More zoom range. Add / lock another step of magnification (2)

• Pop up with more information when cli-cking in map (or clearly show the informa-tion)

TASK 5. SEARCH FOR AN ADRESS OR BUS/METRO STOP

Task 5: (Explore sub menu): Search for an address or bus/metro stop (for example the user’s own street).

1)HOME / NAVIGATION

2) EXPLORE

3) SEARCH

4) CLICK ON A BUS STOP


MADRID

• Process is very slow (2)

• Bus icons (yellow) and metro (blue) are not comprehensible/differentia-ted (2)

• Icons of bus, metro, parking doesn`t appear until zoom is too close (2)

MADRID

• Change icons (3)

• Icons of metro and bus should be clearly different (3)

• Icons should appear with less zoom (2)

• Secondary functions when clicking an icon should be more visible (2)



• Secondary functions (set as origin… etc) are not evident nor visible (hid-den) (2)

• Parking space icon is not easily visible and the meaning is also unclear (1)

• Help in this area does not indicate the meaning of icons (1)

• “enter” in phone’s keyboard erase the text in search field (1)

• Icons are small (1)

• Use “P” for the parking places (1)

• Add information about meaning of icons and sencodary functions at the help (1)

• Avoid bad interactions between the app and the on-screen keyboard (1)

• When user indicates an “origin” should re-main active and don’t disappear during search (1)

• System should keep last position for if the case that user is inside a building without GPS range (1)

• GPS activation should be indicated (1)

• Substitute coordinates with directions. (1)

PARMA

• Very slow process (2)

• Writing the name of the city first is un-comfortable (3)

• Too much search results (3)

• Keyboard was difficult to use (1)

• The predictive search result list is very sensitive: when user tried to scroll through the list clicked by mistake to an undesired address. (1)

• Difficult of finding some name of streets: 20 may, XX may, twenty may…(2)

• No “Home” button (1)

• Not clear where to go to perform a search. Once arrived was easy (1)

• Search icon was not clear / visible (1)

PARMA

• The user should be able to define the “by default” city to make searches (3)

• Ease the displacement trough the search list result: less sensitive, add a button… (1)

• The user should be able to filter the search results initially (everything, streets, stops,…)(3)

• Not SIMON problem: users should use a keyboard app that is adapted to their needs.

• Add “home” button (1)

• Make more visible / clearer the search button (1)

LISBON

• Route menu is complicated.

• Some sub-menus appear and disap-pear…

• Icons are not clear

• Map aesthetics is bad

• Lack of Lisbon information

LISBON

• Clearer icons

• Improve map aesthetics

• More zoom range

• More information about Lisbon



TASK 6. VIEW THE STOPS NEAR A POINT IN THE MAP

Task 6: Explore sub menu): View the stops near a point in the map (click on a zone at the Madrid/Lisbon/Parma map, then click on the bus symbol to see the near stops, click on one stop to see the info).

1) HOME/ NAVIGA-TION

2) EXPLORE

3) CLICK ON A BUS STOP

4) BUS OPTIONS I

5) BUS OPTIONS II

6) BUS OPTIONS III

As noted in the execution cycle of the task (steps 4-6), some users used the "Information" menu to get the information from the bus, rather than the "Clock" secondary function.




MADRID

• The arrow in the search field seems to have the “go” function, but it is only a pic-ture without functionality (3)

• Information of the stop (or street…) that appears below when selecting a point or putting a marker seems to be clickable, bu it isn’t (1)

• Search for an address is complicated and costly (1)

• Information about the bus stop is not clearly visible (not highlighted, low con-trast) and (once seen) user tend to think that it is clickable (1)

• Clock icon is not visible and user does not sees its functionality (1)

• Information about bus schedule has not good visibility and it is not understanda-ble. Font size is little. Meaning of results is not clear (1)

MADRID

• Give the arrow in search field a real fun-ction (3)

• (3) The information about the stop that is shown in the lower part of the screen should be:

o Clearly visible (and user should be aware of the changes when click-ing another stop).

o Clickable: clicking there should at least open some options (set as origin, see information,…) similar to those that appear at the … menu

• Store the search (1)

• Improve the way in that Schedule infor-mation is shown (1)

PARMA

• Click on stop was not easy to understand (1).

• The information that appeared was not noticed by the user (3)

• Zoom buttons disappear when a marker pin is on map (1)

• User tried to click on the stop informa-tion that appears on the screen, but nothing happened. User did not notice about the “clock” button (3)

• The colour of the icons and also the sym-bols are not very intuitive/visible, spe-cially the parking spaces (2)

PARMA

• The information below when selecting a stop or a street (marker pin) should be more visible (specially when the user selects a place and then selects other place) (3)

• (3) The information that appears when a marker is active should be clickable:

o If corresponds to a STREET or place: should open the op-tions “set as origin”, “set as destination”, “detailed info”

o If corresponds to a PARKING SPACE or place: should open the options “set as origin”, “set as destination”, “detailed info”

o If corresponds to a BUS/METRO STOP: should open the options “sched-ule/stop information”, “set as origin”, “set as destination”

• Improve colours and symbols of icons (stops, parking spaces…) (2)



LISBON

• Not enough zoom range (2)

• Not easy to distinguish what is clickable and what not

• Information was not visible

• Information below was not clickable

• Parking spot icon: not intuitive design

LISBON

• More zoom range (2)

• The information below when selecting a stop or a street (marker pin) should be more visible (for example a “pop up”) (2)

• (2) The information that appears when a marker is active should be clickable

• Improve colours and symbols of icons (stops, parking spaces…) (2)

• Occupancy of the reserved parking spa-ces would be a nice option (2)

• Improve icons

TASK 7. SEARCH FOR WALKING ROUTE

Task 7: (Route menu): Search for a walking route. Then view the detailed information about the route. 1) HOME / NAVIGATION

2) ROUTE

3) COMPUTE

4) ROUTE DETAIL I 5) ROUTE DETAIL II




MADRID

(blind user did not perform this and the following tasks)

• Typing/selecting an address is slow and requires a lot of effort. List of streets is very sensitive (clicks by mis-take were frequent, the list appears and disappears suddenly)(3)

• Secondary functions on each screen are very interesting but unknown, as the user don’t see them and does not k now that they are available (3)

• Route options are not intuitive nor ordered in the logical way (3)

• There’s no way of going back to the previous screen. Back button leads to main screen. Moreover, going back deletes search options (3)

• Coordinates are not very useful (or at least, should be alternatives) (2)

• Icons that appear in search results are confusing. Moreover, some are clickable and others not. Icon for “route” is small and has low contrast (1)

MADRID

• System should register the real location of the user and offer it as “origin” (3)

• Highlight the secondary functions (3)

• System should ask for the street number (3)

• Back button should be available and behave always the same way (going back only one screen) (3)

• Improve the visibility of the different ways of moving (driving, walking…)(1)

• Improve the symbols of icons in search re-sults and search and indicate clearly those with functionalities (3)

PARMA

• Route sub-menu was not clearly visi-ble (2)

PARMA

• Improve the alternatives of “set as ori-gin/destination” (see recommendations for task 6) (3)



• Search from the map (instead of “route” sub-menu” should be more intuitive (3)

• Writing the name of the city first is uncomfortable (3)

• Difficult of finding some name of streets: 20 may, XX may, twenty may…(2)

• The route alternatives (walking, opti-ons,…) were not clearly perceived (4)

• Search results: “map” and “text” op-tions were not noticed by the user (3)

• Search results: map is not zoomable (1)

• “Navigate” clicking there leads you to a screen were all the menus are di-sordered (in different positions as in other places). This option is not clear (1)

• FAVORITES: options for the favourite list are not clear (2)

• If you sear for a street, and go back this search is not kept and you have to type it entirely again (4)

• The user should be able to define the “by default” city to make searches (3)

• Ease the displacement trough the search list result: less sensitive, add a button… (1)

• The user should be able to filter the search results initially (everything, streets, stops,…)(3)

• Change the order of the actions to per-form the route: first the mean of trans-port options (walking, driving,… as it is in google maps) (4)

• Make more visible the “map” and “text” options at the routes (3)

• Improve the layout of the “navigate” screen (1)

• FAVORITES LIST: Options should include “set as origin”, “set as destination” and “see” (2)

• Try to keep the last search in memory, for if the user goes back by accident, in order that does not need to type it again (4)

LISBON

• Map is not beautiful

• Too complicated to perform the route: order mot clear.

• Results of route were not clear: too much options and difficult to distin-guish those clickable.

• Map in route results are not clickable

LISBON

• Improve map design

• Improve usability of search results

• Set origin: use GPS location



TASK 8. SEARCH A BUS TIMETABLE

Task 8: Search a bus timetable near a zone or street 1) INFORMATION

2) SET STOP

3) TIMETABLE I

4) TIMETABLE II


MADRID

• Small font size in results (2)

• “Enter/done” key in keyboard some-times erase the entered data (1)

• System don’t ask for the city when searching a stop. Does the system know that you are in Madrid?. The city for search should be defined first (1)

• Knowing the name or number of the stop is difficult. In general is difficult to search only with the keyboard. It should be possible to browse by ca-tegories (type of transport) or to search by bus number (2)

• Bus schedule is difficult to see and to understand. Icons don’t clarify the content. The information of the table is not clear: it is supposed that is the time in which the bus passes through that stop? (1)

MADRID

• Increase font size in results (2)

• It should be available an option to choose/filter the types of transport prefe-rred (2)

• Ease the search of stops: filter by city first, browse/search by type of transport, bus number, address nearby,… (2)

• “Enter/done” key in keyboard must acti-vate the search (1)

• Coherence of search fields. The system should ask for the same data everywhere (1)

• Differentiate BUS and METRO icons. In ge-neral improve the icons. (1)

• Ease the link to the stop searches made in map with the information part (1)

• Add the possibility of knowing the route of the bus/metro line (1)

• Waiting time between the most closed set of buses (1).

PARMA

• Task didn’t work, as the data of Parma were not available (4)

• The text already present in the search field confused the user that

PARMA

• Improve connections between Naviga-tion/Map and “information” features (3)

• It should be possible to select/filter pre-viously by city (2)



didn’t noticed that it was a search field (1)

• Putting the city name each time is very uncomfortable. It should be possible to select/filter previously by city (2)

• Some users tried to access from “Na-vigation” menu, not using “Informa-tion menu”. Doing that way was not easy (see comments to task 5) (3)

• The clock icon is not clickable. The user tried to click on it (2)

• Remove the clock icon or clearly mark that is not clickable. In general differentiate clearly what are clickable items and which are not (2)

• It should be possible to browse/filter by type of transport, line, etc… not only wri-ting information… (2)

LISBON

• Information about public transport was very poor (4)

LISBON

• (4) More information about public trans-port, including:

o Accessible lines o Lines’ routes o Accessibility issues o Real time schedules (when will

the bus arrive to a stop)

TASK 9. LOGIN IN VALIDATION

Task 9: Login (username/password). 1) HOME / VALIDATION

2) LOGIN

3) DETERMINING POSITION


• Useful system (3)

• It takes a long time to capture the po-sition. User doesn’t know if this is normal and stops the operation. If you are inside a building the process does not stop (3)

• Login should access to an intermediate screen in which you can confirm that you want to perform a validation (in order to avoid to capture the position immediately and avoiding errors) (2)



• It should be possible to register/login using the NFC card instead of (or in addi-tion to) writing a username and password (1)

PARMA

• Typing username and password is un-comfortable (1)

• Very confusing that, after login, the systems tries to capture the position. User tends to abort the operation (3)

PARMA

• It should be possible to register/login using the NFC card instead of (or in addi-tion to) writing a username and password (1)

• Login should access to an intermediate screen in which you can confirm that you want to perform a validation (in order to avoid to capture the position immediately and avoiding errors) (3)

LISBON

• No problem. Easy

LISBON

TASK 10. VALIDATE PARKING USING NFC

Task 10: Validate parking using NFC: approach the card to the phone and follow the instructions.




• Ok. Process simple and easy. (3)

• If the card is not attached to the windscreen the pone doesn’t read NFC or capture QR. (1)

• Iphones doesn’t have NFC (I)

• It should be possible to keep the position of the parking space that you have valida-ted, in order to ease the return to the car (e.g. adding the position automatically to “destination”) (3)

• If you are moving without having said that you left the parking space, the GPS should notice of that and warn you (1)

PARMA

• Easy and useful (2)

• Some user didn’t read the instruc-tions and went directly to QR code instead of simply approach the card (2)

• Some users didn’t understand the questions after approaching the NFC card. It was also for them diffi-cult to distinguish that there were 2 questions. Moreover, the buttons were partially out of the screen (3)

• NFC was not easily read by the ap-plication (2)

PARMA

• Improve the design/layout: instructions and questions (2)

• Avoid that buttons after questions are to-tally/partially out of the screen (see figure) (4)

LISBON

• Process easy

• Some aspects are confusing, be-cause user doesn’t know what the system is doing

• Errors if used inside

LISBON

• Add a menu in order that the user can choose the action that he wants to per-form.

Date post:	26-Apr-2020
Category:	Documents
Upload:	others
View:	4 times
Download:	0 times

D4.2 Refinement of Services and Lessons...

Documents