DELIVERABLE...Project Acronym: OPTIMUM Grant Agreement number: 636160 (H2020-MG-7.1 - RIA) Project Full Title: Multi-source Big Data Fusion Driven Proactivity for Intelligent Mobility

Project Acronym: OPTIMUM Grant Agreement number: 636160 (H2020-MG-7.1 - RIA) Project Full Title: Multi-source Big Data Fusion Driven Proactivity for Intelligent

Mobility

DELIVERABLE

D6.2 - OPTIMUM Mobile and Web Applications – Initial version

Dissemination level PU

Type of Document R+DEM

Contractual date of delivery 31.12.2016

Actual Date of Delivery 28.12.2016

Deliverable Number 6.2

Deliverable Name OPTIMUM Mobile and Web Applications – Initial version

Deliverable Leader FLU

Work package(s) WP6

Status & version 1.0 – Final

Number of pages 55

WP contributing to the deliverable WP6

WP / Task responsible WP6 / T6.3

Coordinator (name / contact) Mr. Konstantinos Thiveos (INTRASOFT International)

Other Contributors INTRA, NISSA, ICCS, UoW, UoA, AIT, JSI, ADRIA, BCC, TIS, UNINOVA

EC Project Officer Mr. Walter Mauritsch (EC, INEA)

Keywords: OPTIMUM, Mobile Application, Web Application

Abstract (few lines): Report on the initial version of the Mobile and Web Application. It describes the current implementation including functionalities and designs. An outlook on upcoming developments is given.

Project Title: OPTIMUM

Contract No. 636160 Project Coordinator: INTRASOFT International S.A.

Page | 2

D6.2 – Mobile & Web Applications – Initial version,

v.1.00, 28/12/2016

Document History

Version Date Contributor(s) Description

0.0 22/11/2016

Fluidtime (Anton Fitzhum, Bernhard Entler, Bilal Abunaim, Christoph Sladkovsky, Daniel Skrach, Eva Ganglbauer, Marvin Schwoiger, Michael Tucek, Nikolaus Thurner, Patrick Holcik, Stefanie Wappel, Stephan Strodl) INTRA (Spyros Mantzouratos, Konstantinos Perakis) UNINOVA (Paulo Figueras, Ruben Costa, Guillerme Guerreiro) Kapsch (Gabriel Makki, Rodrigo Barco) Adria (Skarja Metod) JSI (Luka Bradesko, Zala Herga, Matej Senozetnik, Jan Bercic, Tine Subic, Blaz Kazic, Jasna Urbancic) ICCS (Efthimios Bothos, Evangelie Anagnostopoulou, Babis Magoutas) AIT (Johann Schrammel) NISSA (Nenad Stojanovic, Jovica Zlatanovic, Marko Dinić, Milan Jović) BCC (Mel Bradfield) UoW (Panos Georgakis) UoA (Athina Tsirimpa) TIS (Alexandra Rodrigues)

Requirements, Feedback for design and prototype implementation Development, design and testing of applications

0.1 25/11/2016 FLU (Stephan Strodl) Initial version of documents

0.2 02/12/2016 FLU (Eva Ganglbauer) Setting up document structure and writing drafts for chapter 5 and 5.4.

0.3 09/12/2016 FLU (Stefanie Wappel) Documenting design decisions for chapter 5.4.

0.4 12/12/2016 FLU (Stephan Strodl, Daniel Skrach), JSI (Luka Bradesko)

Contributions: Mobile application

0.5 16/12/2016 FLU (Stephan Strodl) ICCS (Efthimios Bothos)

Contributions to architecture and introduction



Page | 3


v.1.00, 28/12/2016

0.6 16/12/2016 INTRA (Spyros Mantzouratos, Konstantinos Perakis)

Contribution regarding the web interface across all corresponding chapters

0.7 20/12/2016 BCC (Mel Bradfield) Review of the deliverable

0.8 20/12/2016 TIS (Alexandra Rodrigues) Review of the deliverable

0.9 20/12/2016 KAPTSCH (Gabriel Makki) Review of the deliverable

0.99 22/12/2016 FLU (Stephan Strodl) Final version of the document

1.0 28/12/2016 INTRA (Akrivi Kiousi, Irene Matzakou) QA, Final Approval, Submission to the EC



Page | 4


v.1.00, 28/12/2016

1 Table of Contents 1 Table of Contents..................................................................................................................... 4

2 Table of Figures ....................................................................................................................... 7

3 List of Tables ............................................................................................................................ 8

4 Definitions, Acronyms and Abbreviations ............................................................................... 9

1 Introduction ........................................................................................................................... 10

2 Architecture ........................................................................................................................... 12

2.1 Mobility Hub ................................................................................................................. 13

2.2 Mobile Application ........................................................................................................ 13

2.3 Web Application............................................................................................................ 14

2.3.1 Web Application Architecture Layers ....................................................................... 15

3 OPTIMUM mobile application ............................................................................................... 16

3.1 Functionalities ............................................................................................................... 16

3.2 Login .............................................................................................................................. 18

3.3 User profile and preferences ........................................................................................ 19

3.4 Route request and information .................................................................................... 21

3.5 Selected/ store route .................................................................................................... 26

3.6 Personalisation Service ................................................................................................. 27

3.7 Push-Notification .......................................................................................................... 28

3.8 Feedback ....................................................................................................................... 29

3.9 Routing format .............................................................................................................. 29

3.10 Database ....................................................................................................................... 30

3.11 Tracking library ............................................................................................................. 31

3.12 Availability ..................................................................................................................... 31

4 Web Application .................................................................................................................... 32

4.1 Functionalities ............................................................................................................... 32

4.2 Database ....................................................................................................................... 33

4.3 Dynamic Charging Service ............................................................................................. 34



Page | 5


v.1.00, 28/12/2016

4.4 Security & Authentication ............................................................................................. 35

4.5 Technology stack ........................................................................................................... 36

4.5.1 MongoDB .................................................................................................................. 36

4.5.2 Thymeleaf ................................................................................................................. 36

4.5.3 Java 1.8 ...................................................................................................................... 37

4.5.4 Spring Framework ..................................................................................................... 37

4.5.5 Spring Boot ................................................................................................................ 37

4.5.6 Spring Data REST ....................................................................................................... 37

4.5.7 Embedded Servlet Containers .................................................................................. 38

4.5.8 Token-based authentication ..................................................................................... 38

4.5.9 jQuery ........................................................................................................................ 38

4.5.10 Page.js ................................................................................................................... 38

4.5.11 Bootstrap .............................................................................................................. 38

4.5.12 Mapbox ................................................................................................................. 39

5 Design and User Interaction .................................................................................................. 40

5.1 Information Architecture .............................................................................................. 40

5.2 Interaction Design ......................................................................................................... 41

5.2.1 Wireframes ............................................................................................................... 41

5.3 Visual Design ................................................................................................................. 44

5.3.1 Colour ........................................................................................................................ 44

5.3.2 Iconography .............................................................................................................. 45

5.3.3 Typography ............................................................................................................... 46

5.3.4 User Interface Design ................................................................................................ 47

5.4 Usability and User Experience ...................................................................................... 48

5.4.1 Prototyping ............................................................................................................... 48

5.4.2 Expert reviews ........................................................................................................... 48

5.4.3 Design choices based on expert reviews and feedback ........................................... 48

5.4.4 Usability and User Experience process ..................................................................... 48

6 Conclusion and Outlook ........................................................................................................ 54



Page | 6


v.1.00, 28/12/2016

7 References ............................................................................................................................. 55



Page | 7


v.1.00, 28/12/2016

2 Table of Figures FIGURE 1 TECHNICAL ARCHITECTURE OPTIMUM ................................................................................................................... 12 FIGURE 2 MENU OF THE OPTIMUM APP ................................................................................................................................ 18 FIGURE 3 MOBILE APPLICATION LOGIN SCREEN ...................................................................................................................... 19 FIGURE 4 PROFILE QUESTIONNAIRE ...................................................................................................................................... 20 FIGURE 5 PROFILE OF THE OPTIMUM MOBILE APPLICATION .................................................................................................... 21 FIGURE 6 ROUTE REQUEST SCREEN OF THE OPTIMUM APP ..................................................................................................... 22 FIGURE 7 LOCATION SCREEN OF THE OPTIMUM MOBILE APPLICATION ...................................................................................... 22 FIGURE 8 ROUTE REQUEST WITH STOPOVERS ......................................................................................................................... 23 FIGURE 9 OPTIONS OF ROUTE REQUEST ................................................................................................................................. 23 FIGURE 10 ROUTE ALTERNATIVE LIST .................................................................................................................................... 25 FIGURE 11 ROUTE DETAILS ................................................................................................................................................. 25 FIGURE 12 ROUTE DETAIL MAP............................................................................................................................................ 26 FIGURE 13 ROUTE DETAILS WITH VIA POINTS .......................................................................................................................... 26 FIGURE 14 LIST OF STORED ROUTES ...................................................................................................................................... 27 FIGURE 15 DETAILS OF A STORED ROUTE ............................................................................................................................... 27 FIGURE 16 INFO NOTIFICATION ........................................................................................................................................... 29 FIGURE 17 FEEDBACK FUNCTIONALITY .................................................................................................................................. 29 FIGURE 18: OPTIMUM WEB INTERFACE DASHBOARD............................................................................................................. 32 FIGURE 19: OPTIMUM WEB INTERFACE REQUESTS ................................................................................................................ 32 FIGURE 20: OPTIMUM WEB INTERFACE TOLL DISCOUNTS ....................................................................................................... 33 FIGURE 21: OPTIMUM WEB INTERFACE MONGO DB COLLECTIONS .......................................................................................... 34 FIGURE 22: INFORMATION ARCHITECTURE AS WIREFRAME WITH NAVIGATION DRAWER. ................................................................. 41 FIGURE 23: EXTRACT OF WIREFRAMES FORMING A FLOW CHART WITH INTERACTIONS BETWEEN SCREENS AND ELEMENTS. .................... 42 FIGURE 24: EXTRACT OF WIREFRAMES FORMING A FLOW CHART WITH INTERACTIONS BETWEEN SCREENS AND ELEMENTS. .................... 43 FIGURE 25: WEB INTERFACE WIREFRAME. ............................................................................................................................. 44 FIGURE 26: COLOUR PALETTE IN OPTIMUM DERIVED FROM LOGO USED FOR VISUAL SCREENDESIGN. ............................................. 45 FIGURE 27: ICONOGRAPHY USED IN THE OPTIMUM APPLICATION. RED ICONS ARE ORNAMENTING ................................................. 45 FIGURE 28: COLOURS USED IN VISUAL DESIGN WITH TURQUOISE AS PRIMARY COLOUR AND ORANGE AS SECONDARY COLOUR................. 46 FIGURE 29 – OPEN ICONIC ICONOGRAPHY ............................................................................................................................. 46 FIGURE 30: ROBOTO FONT WEIGHTS AND SIZES FOR ANDROID APPLICATIONS. PICTURE FROM GOOGLE MATERIAL DESIGN GUIDELINES. ... 47 FIGURE 31 DESIGN PROCESS ............................................................................................................................................... 49 FIGURE 32: ROUTE SEARCH CHANGES ................................................................................................................................... 49 FIGURE 33: ROUTE RESULTS CHANGES .................................................................................................................................. 50 FIGURE 34: ROUTE OPTIONS CHANGES ................................................................................................................................. 51 FIGURE 35: ROUTE DETAIL CHANGES .................................................................................................................................... 52 FIGURE 36: WEB INTERFACE MOCK-UP .................................................................................................................................. 53 FIGURE 37: WEB INTERFACE PROTOTYPE ............................................................................................................................... 53



Page | 8


v.1.00, 28/12/2016

3 List of Tables TABLE 1 PUSH-NOTIFICAITON FORMAT ................................................................................................................................ 28 TABLE 2 EXCERPT OF THE OPTIMUMUSER OBJECT FROM THE MONGO DB ................................................................................... 30 TABLE 3: OPTIMUM WEB INTERFACE SAMPLE REQUEST & RESPONSE FOR DISCOUNTED TOLL PRICES ............................................... 34



Page | 9


v.1.00, 28/12/2016

4 Definitions, Acronyms and Abbreviations Acronym Title

CO Confidential, only for members of the consortium (including Commission Services)

CR Change Request

D Demonstrator

DL Deliverable Leader

DM Dissemination Manager

DMS Document Management System

DoA Description of Action

Dx Deliverable (where x defines the deliverable identification number e.g. D1.1.1)

EIM Exploitation Innovation Manager

EU European Union

FM Financial Manager

MSx project Milestone (where x defines a project milestone e.g. MS3)

Mx Month (where x defines a project month e.g. M10)

O Other

P Prototype

PC Project Coordinator

PM partner Project Manager

PO Project Officer

PP Restricted to other programme participants (including the Commission Services)

PU Public

QA Quality Assurance

QAP Quality Assurance Plan

QFD Quality Function Deployment

QM Quality Manager

R Report

RE Restricted to a group specified by the consortium (including Commission Services)

RUP Rational Unified Process

STEP Standard Technology Evaluation Process

STM Scientific and Technical Manager

TL Task Leader

WP Work Package

WPL Work Package Leader

WPS Work Package Structure



Page | 10


v.1.00, 28/12/2016

1 Introduction The deliverable describes the initial version of the mobile and web application of the OPTIMUM

project. It also describes the work that has been executed for the usability and user experiences

of these end user services. The web application serves as user interface for the use case 2:

dynamic toll charging. The mobile application focus on use case 1 and 3: improvement of

transport system (UK, Austria, Slovenia) and Car2X.

The mobile application provides a very user friendly way for the end users to interact with

functionalities the OPTIMUM platform. The application is implemented as native Android

application and allows using of services for transportation information in a personalised and

understandable manner. The application was designed and implemented in an iterative and

agile approach. Short development and release cycles allowed continuous feedback and

improvements of the application, its functionality, its design and the user interaction. The initial

version of the application focuses on the core functionalities to address the requirements

identified in WP1 with strong focus on the use cases of the improvement for transport systems

and pro-active approaches. The mobile application implements features such as login with user

credentials, request of personalised route recommendation (including persuasive mechanism),

visualisation and information about routes details, store and retrieve routes, receiving

notifications about selected routes, pro-active route suggestions and feedback for the

OPTIMUM platform.

The development and design approach followed an iterative approach. An initial design and

user interaction was drafted as Wireframes and distributed amongst design experts and project

partners. The received feedback was input for improvements and adaptions for following

versions. The designs were extended within every version with new functionalities and more

details. After settling core functionalities, design and interaction based on the feedback, a visual

design of the application was created. Feedback was provided by internal and external design

experts and the consortium. The revised visual design was the starting point for the application

development. Examples of the iterative design approach based on the feedback are presented

in this deliverable.

The development work also followed the iterative approach. Using continuous integration,

mobile application versions were released in very short cycles. The release cycles included

either new features and refinements or modification of existing features or design

improvements. The short release cycles allowed immediate feedback for the designer and

developer about the current version. The approach ensured that the application implements

the required functionality with high acceptance of the user. The here presented initial version is

the result of 14 intermediate versions that were already tested and commented on by experts



Page | 11


v.1.00, 28/12/2016

and the project consortium. We did not used time based release in this project as the changes

vary in size and effort. We now have design, development, and test cycles in parallel. This

approach will be used to develop the final version of the application.

The OPTIMUM Web Application was implemented as user interface for the dynamic toll

charging use case. The prototype was implemented as Single Page Application presenting the

user all relevant information regarding toll costs of the motor way. The Web Application focus

on the presentation of information and the easy interaction with the OPTIMUM portal.

The portal was designed and implemented in close cooperation with the use case partner

ensuring that the portal meets all requirements of the users. The functionalities were driven by

the potential users. Core functionalities of the portal are for example the visualisation of the

24-hour time windows of the discounted toll prices along a selected route. The portal visualises

the routes in an interactive map including entry/exit points along with toll stations. The

requests of the users can be saved and load in the portal. Statistics of savings for the trips are

presented to the user. The portal implements authentication mechanism ensuring only users

with the right credentials can access it.

The document is structured as follows. Section 2 describes the architectural aspects of the

Mobility Hub, the mobile application and the web application. The mobile application is

described in detail in Section 3, followed by the description of the web application in Section 4.

Section 5 presents the work done for the usability and user experiences. A short conclusion and

outlook for the final version of the mobile and web application is provided in Section 6.



Page | 12


v.1.00, 28/12/2016

2 Architecture This section describes the architectural aspects of the OPTIMUM mobility hub, the mobile

application and web application. The architecture is shown in Figure 1 below, with the detailed

technical architecture is described in D6.1 OPTIMUM Technical Architecture.

Figure 1 Technical architecture OPTIMUM



Page | 13


v.1.00, 28/12/2016

2.1 Mobility Hub The Mobility Hub oversees the communication of the end-user services with the OPTIMUM

platform. Two end user services are provided the Android Mobile Application and the Web

Portal. Both services focus on providing access to the functionality of the OPTIMUM platform in

a very user-friendly way by hiding the complexity and personalising information and

functionalities for the individual users. All communications of the Mobile Application and the

OPTIMUM platform are sent via the Mobility Hub. The hub takes care of the communication

between the platform and the user frontends including connection errors for the mobile

application.

The Mobility Hub implements security and authentication mechanism allowing only authorised

access to the OPTIMUM platform. The authentication service builds the basis for

personalisation approaches of the services by providing unique user IDs. Figure 1 illustrates the

interaction of the Mobility Hub with the other OPTIMUM components. Detailed interactions

and interface specification are provided in D6.3 Integrated OPTIMUM Platform. Examples are

amongst others, route requests from the Multimodal Router. The Mobility Hub is triggered by

the Mobile Application to send route request to the Multimodal Route. The route results are

sent to the recommender before being presented to the user. The recommender personalizes

the route results by ordering the results and extending the results by persuasive messages.

Another interaction is the pub-sub middleware, user notifications (e.g. information about

routes) are published via the middleware. The mobility hub subscribes to events and sends

information to the mobile application as push-notifications.

The mobility hub provides all relevant information to the Web application from the Dynamic

Charger and the repository. The Mobility Hub provides a gateway for all user interactions with

the OPTIMUM platform. It provides specified interfaces for interaction implementing two

clients within the project.

2.2 Mobile Application The Mobile Application focuses on a user-friendly interaction with the OPTIMUM platform

without entry barriers for the user. The Mobile Application only interacts with the Mobility Hub

and the authentication service. It is implemented as native Android application.



Page | 14


v.1.00, 28/12/2016

2.3 Web Application The OPTIMUM Web Application is implemented

as a Single Page Application (SPA1). A Single Page

Application is a web application that fits on a

single web page with the goal of providing a user

experience like that of a desktop application. In

an SPA, either all necessary code – HTML,

JavaScript, and CSS – is retrieved with a single

page load, or the appropriate resources are

dynamically loaded and added to the page as

necessary, usually in response to user actions.

The page does not reload at any point in the

process, nor does control transfer to another

page, although the location hash can be used to

provide the perception and navigability of

separate logical pages in the application, as can

the HTML5 pushState() API.

Interaction with the Single Page Application

often involves dynamic communication with the

web server behind the scenes. SPAs dramatically

improve the user experience and provide great

development flexibility. This architecture can be

used to develop, maintain and scale various

types of modern style web applications. It

consists of a set of development best practises

along with the state-of-the-art technologies to

increase the overall performance of the web

application and minimize the software

development life cycle.

The architecture of OPTIMUM Web Application can be summarized in the following aspects:

o SPA architecture paradigm. Single Page Applications extremely improves user

experience (UX) & development flexibility.

o UI fragment composition. Assembly various parts of the web page on demand.

o Server-side rendering. Less error-prone web pages & more HTML5 compatible pages.

1 https://en.wikipedia.org/wiki/Single-page_application



Page | 15


v.1.00, 28/12/2016

o Framework agnostic. Choose your favourite framework or libraries and use it.

o Scalable. It enhances a horizontal development strategy.

o Stateless. No more heavyweight sessions (cookies), just a lightweight server-side signed

web token

2.3.1 Web Application Architecture Layers

The web application architecture comprises mainly three layers, the scope of each is explained

in the forthcoming paragraphs.

Front-end

The upper layer of the OPTIMUM Web Application architecture is responsible for delivering the

frontend through which the freight operators will be able to interact with the Dynamic Charger

Service. The OPTIMUM web application enhances the interaction between freight and toll

operator professionals by providing them with an interactive tool for a secure and efficient

information exchange. Each freight operator can use his/her credentials to have access to the

application. Additional information regarding the functionalities supported by the web

application can also be found in section 4.1 of the current document, as well as in D1.3 (use

case definition) and D6.3 (OPTIMUM integrated platform and description of functionalities per

user category).

Middleware

In the middleware, all the business logic takes places. With the chosen architecture, controllers

are logically divided into MVC controllers and RESTful web service controllers. The key

difference between a traditional MVC controller and the RESTful web service controller is the

way the HTTP response body is created. While the traditional MVC controller relies on the View

technology, the RESTful web service controller simply returns the object and the object data is

written directly to the HTTP response as JSON/XML.

Data Layer

The cornerstone of the Data Layer is a non-relational database that is used for storing the data

necessary for the operation of the OPTIMUM Web Application. Although, the logic of the

database is complex, it is meaningful to highlight some parts of the database that are crucial for

overall comprehension.

A fundamental concept of the OPTIMUM Web Application is the “Request”. A “Request”

represents practically the information that is needed for receiving toll discounts from the

Dynamic Charger Service. Indicative Requests include the highway, an entry and an exit point

etc. The database schema along with information per each collection is depicted in section 4.2.



Page | 16


v.1.00, 28/12/2016

3 OPTIMUM mobile application This section presents the implementation aspects of the OPTIMUM mobile application. The

mobile application provides the central user-interface to the functionalities of the OPTIMUM

platform. The mobile interface is implemented as Android native application with a strong focus

on solid user interaction and design. The focus of the mobile application is a seamless

interaction with the OPTIMUM platform.

3.1 Functionalities The functionalities of the mobile application are derived from the requirements specified in

D1.3 - OPTIMUM Use Cases and refined with the use case partner.

The mobile application implements the following core functionalities that are described in

detail in the following chapters:

o Login/Register

The app provides a log-in and registration mechanism for user to us the app. The login

ensures the secure usage of the OPTIMUM services, the privacy of the information and

is the basis for personalization approach. More details are presented in Section 3.2.

o User Profile and preferences

After the first login of the app, a questionnaire is presented to the user that supports

the creation of an initial user profile.

The user preferences allow to the user to set settings of the app, for example home and

work address for route search, or the tracking functionality for pro-active

recommendations and trip history as described in Section 3.3.

o Route requests

The mobile application enables the user to request routes with start and destination

location specifying the individual needs of the traveller (e.g. date and time of arrival or

departure, modalities, location of own car and bike, park place). The OPTIMUM platform

supports via-points for the route. Route alternatives are presented to the user by the

app. The list includes the used modalities, time and CO2 consumption for each trip

alternative. These alternatives are personalized in terms of routing optimization for the

individual user and its travel profile. A persuasive message is presented for specific

alternatives. The trip detail view lists the trip legs and provides a map view of the trip.

Details of route request are presented in Section 3.4.

o Selected/Store routes

The app supports the storage of current and future trips (as described in detail in

Section 3.5. It allows quick access to planned trips and allows the OPTIMUM platform to



Page | 17


v.1.00, 28/12/2016

inform the user about events that have impacts on the user’s trips (e.g. traffic,

accidents).

o Nearby POIs

The surrounding of the location of the user is shown as map with this functionality. It

allows the user to explore its location or a potential destination by showing POIs on the

map. The POIs can be filtered through categories and the POIs can be included in route

requests.

o Trip History

The OPTIMUM app implements a tracking functionality, described in Section 3.11. The

tracking can be turned on and off via the option menu. The captured tracks of the user

are presented in this feature. The integration of this functionality is planned for the

second version of the app.

o Feedback

The feedback functionality is very important to easily allow the user to communicate

with the OPTIMUM project. The feedback functionality allows to rate the app with 0-5

stars and provide feedback text. The functionality is described in detail in Section 3.8.

The side menu of the app is shown in Figure 2 providing an overview of the functionalities. The

flow between the screens is shown as Wireframes in Figure 24. It visualises the core artefacts of

each screen and the user interaction between the screens.

The first version of the app provided by M20 of the project focuses on the route search and

display functionalities. Functionalities for the second version include improvements of route

visualisation, navigation support for routes and the history of tracked routes of the user.



Page | 18


v.1.00, 28/12/2016

Figure 2 Menu of the Optimum app

3.2 Login The application starts with the login screen. By entering the user credentials the user can login

into the app as shown in Figure 3. The security approach of the OPTIMUM platform is described

in D6.1 OPTIMUM Technical Architecture. The authentication is done by using OAuth protocol2,

a token based authentication mechanism.

During the login, an access token is obtained from the OPTIMUM authorisation services using

credentials (username and password). The access token is used for communication with the

mobility hub ensuring authorisation of the app user. The mobility hub validates the access

token via the OPTIMUM authorisation services. For security reasons the communication

2 http://oauth.net/



Page | 19


v.1.00, 28/12/2016

between components (e.g. mobile application, authorisation service and mobility hub) is using

HTTPS secure protocol.

The access token contains the OPTIMUM User ID that is used to store user data (e.g. planned

trips or user profile in the database).

Figure 3 Mobile Application Login Screen

3.3 User profile and preferences After the first login into the app a questionnaire is presented to the user (see Figure 4). The

questionnaire is used for personalization and persuasive recommendation services of the

OPTIMUM platform. More details about the user model and personalisation approaches within

OPTIMUM are described in D5.2 Persuasive Interventions. The results of the questionnaire are

stored in the Mongo DB of OPTIMUM (see Section 3.10).



Page | 20


v.1.00, 28/12/2016

Figure 4 Profile questionnaire

The mobile application provides a user profile menu that allows to set personal preferences and

options. The screen is shown in Figure 5. It allows to define home and work adresses that are

can be used for routing requests. The OPTIMUM application includes a tracking library that

records the travel behaviour of the user. The collected data is used to detect the mobility

pattern of the user. The predication work resuts in pro-active recommendations for the user.

The recommendation about new destinations is implemented in the mobile application as a

Push-Notification, see Section 3.7. The work of the Mobility patterns detection and prediction is

described in D3.1 Orientation and Forecasting Blueprint. The user has the option to turn on or

off the tracking functionality of the app.

The profile contains information about the OPTIMUM project and the mobile application of

OPTIMUM.



Page | 21


v.1.00, 28/12/2016

Figure 5 Profile of the OPTIMUM mobile application

3.4 Route request and information The route request represents the core functionality of the application. Figure 6 shows the route

request screen, it is the start screen of the app. The screen allows user to a enter start and an

end location of the trip. Figure 7 shows the input screen for the start location of a trip. The user

can define the start location of the trip as current location, select a location from the history list

of previous locations, use home or work addresses or enter the address in the text box. The

application provides location suggestion during the input of an address.

The OPTIMUM platform supports trips with via points. Figure 8 shows the trip request with 2

stopovers.



Page | 22


v.1.00, 28/12/2016

Constrains of the trip request can be defined in the option menu shown in Figure 9. The option

includes the selection of modalities (e.g. car, car sharing, public transport, bike, ..) that should

be used, location of own car and/or bike (if it is not the start location of the trip) or the use of

parking garage.

The user can specify the time of travelling by entering departure or arrival time for the route

request. All these constraints are considered for the route calculation.

Figure 6 Route request screen of the OPTIMUM app

Figure 7 Location screen of the OPTIMUM mobile

application



Page | 23


v.1.00, 28/12/2016

Figure 8 Route request with stopovers

Figure 9 Options of route request

Figure 10 shows an example of a route request, with a list of alternative trips is presented. The

list shows for each trip the time, the used modalities as icons, CO2 consumption and the length.

The screen also shows an example of a persuasive message. The message is shown above the

list of alternatives. The trip(s) related to the message are marked. The example shown in Figure

10 refers to trips with bike sharing.

Details for a trip is shown in Figure 11. The screen shows for each leg of the trip start- and end-

point, the time, the duration, CO2 and the modality. The colour of the legs depends on the used

modality and gives a visual overview of the trip.



Page | 24


v.1.00, 28/12/2016

Figure 12 shows the map visualisation of a trip. Different legs are shown on the map in the

same colour encoding as the trip details. The map implements interactions as zoom in and out

and the focus on own location. Within the map visualised POIs that will be available in the

second version of the app.

The star button shown in Figure 11 and Figure 12 allows the user to store the route. It is used to

store current and upcoming trips that can directly be accessed via the menu “selected route” as

described in the next section. The stored routes also allow the OPTIMUM platform to inform

the user about events that affect the trips (e.g. traffic, accidents, etc.).



Page | 25


v.1.00, 28/12/2016

Figure 10 Route alternative list

Figure 11 Route details



Page | 26


v.1.00, 28/12/2016

Figure 12 Route detail map

Figure 13 Route details with via points

3.5 Selected/ store route The user can select and store current and upcoming trips within the app, as described in Section

3.4. They are accessible via the menu “Selected routes”. The menu lists all stored trips of the

user in chronological order as shown in Figure 14. The list allows direct access of the route

details (see Figure 15). The routes can be easily removed from the list via the trash icon.

The selected routes are stored in a central database and are used to notify the user about

events that affect the routes via push-notification.



Page | 27


v.1.00, 28/12/2016

Figure 14 List of stored routes

Figure 15 Details of a stored route

3.6 Personalisation Service Route suggestions of the OPTIMUM platform are personalised in multiple ways. The user profile

sets the weighting for the routing algorithm of the Multimodal router. This router calculates

routes that match with the preferences derived from the profile.

The route alternatives provided by the Multimodal router are sent to a personalisation service

that enriches and modifies the route suggestion. The service sets the order of the route

alternatives with a focus on incentives for more ecological routes. It further adds incentive

messages for specific alternatives. Figure 10 shows the list of alternatives with an incentive

message for bike trips. The service is deployed as a web service that receives the route

alternatives provided by the Multimodal router as Post request and return the personalised

result.



Page | 28


v.1.00, 28/12/2016

The selection of routes provides feedback functionality for the personalisation service of the

OPTIMUM platform as it reports which route alternative the user has selected.

3.7 Push-Notification The mobile application implements a push notification mechanism to inform the user. There

are three types of notification: info, re-route, new route.

o Info

Any new information that is relevant for the user without interaction (shown in Figure

16).

o Re-Route

News about a specific route of the user (e.g. traffic). The notification allows to re-routing

the trip or send a cancellation the notification. If the user decides to re-route, the

routing request screen is shown with a pre-filled target location.

o New Route

As a pro-active feature, the app can suggest a new target location that the user may be

planning to go to next (e.g. every morning to work). The suggestions are based on the

mobility patterns derived by the tracking functionality of the app. The app can provide

route alternatives for the trip. This notification allows the user to cancel the suggestion

or set a route query with the suggested target.

The push-notifications are handled via the PUB/SUB middleware. The mobility hub listens on

the exchange channel: push_notifications. The messages are specified as a JSON object as

defined in Table 1.

Table 1 PUSH-Notificaiton format

{ "type": "INFO|CHANGE|NEW", "message": "anyString" - (info, change, new), "tripId": "anyString" - optional (change), "userId": "anyString" - (info, change, new), "location_name": "anyString" - optional (new), "location_coordinates": "anyDouble-latitude;anyDouble-longitude" - (new) }



Page | 29


v.1.00, 28/12/2016

Figure 16 Info notification

Figure 17 Feedback functionality

3.8 Feedback The feedback functionality of the mobile application allows the user to provide feedback to the

OPTIMUM project in a very easy way. Figure 17 shows the feedback screen. It consists of a 5-

star rating and a text feedback. The feedback provided by the users is stored in a central

database.

3.9 Routing format All information about routing within the OPTIMUM platform is exchanged using the Ariadne

format. The format is an open source format and a successor of the SPROUTE format. The

specification and implementation of the format is available at:



Page | 30


v.1.00, 28/12/2016

https://github.com/dts-ait/ariadne-json-route-format

The format is used for route requests from the mobility hub to the Multimodal router, the

recommender service and the mobility hub. Selected routes of the user are also stored in

Ariadne format.

3.10 Database The data storage of the OPTIMUM platform is separated into two parts. The authentication

data is stored in a repository and the user data are stored in a Mongo-DB database. The

separation of these ensures privacy, as the Mongo-DB only contains a random User-ID as

reference.

The Mobility-hub stores the following data into the Mongo-DB

o Answers of the profile questionnaire (see Section 3.3) using the object OptimumUsers.

An example is shown in Table 2.

o Selected trips, as described in Section 3.5. The object UserTrip is used. The route is

stored in Adriane format as specified in Section 3.9.

o Feedback (Section 3.8) as UserFeedback object.

The data base contains also technical content like the Push-Notification token that is used to

push messages to logged in clients via the Firebase Cloud Messaging service3.

Table 2 Excerpt of the OptimumUser object from the Mongo DB

…. demographics" : { "gender" : "male", "age" : 35, "children" : 1, "education" : "Graduate or post-graduate degree", "occupation" : "Full time employed - flex schedule" }, … "owned_vehicles" : [ { "type" : "car" } ], "personality" : { "Q1" : 3.0,

3 https://firebase.google.com/docs/cloud-messaging/

https://github.com/dts-ait/ariadne-json-route-format

https://firebase.google.com/docs/cloud-messaging/



Page | 31


v.1.00, 28/12/2016

"Q2" : 5.0, "Q3" : 3.0, "Q4" : 3.0, "Q5" : 2.0, "Q6" : 3.0, "Q7" : 3.0, "Q8" : 4.0, "Q9" : 1.0, "Q10" : 4.0, "type" : 4.0, "typeStr" : "Agreeableness", "Extraversion" : 3.0, "Openness" : 3.5, "Neuroticism" : 2.0, "Agreeableness" : 4.0, "Consientiousness" : 3.5, "scores_calculated" : true }, ….

3.11 Tracking library The OPTIMUM mobile application includes a tracking library to collect GPS data. The data is

used to detect mobility patterns and make predictions. The Mobility pattern detection and

prediction is described in detail in Deliverable D3.5 Online stream analytics. The tracking

functionality can be switched on or off by the user in the options of the Mobile Application (see

Section 3.3). The GPS data is sent by the mobile application in real-time to the server. The

server performs all analysis. A potential extension for the second version of the application is

the functionality of trip history. All tracked trips of the user can be made available within the

app and showing the user predictions of the next location based on the mobility patterns.

3.12 Availability The first version of the Mobility Hub and the mobile application was released. The Mobility hub

is deployed as Web Server using Tomcat 7. The mobile application is released as Android App

and available on an internal download page provided by Fluidtime for the members of the

project (https://download.fluidtime.com/ec/optimum/android). New versions are released via

the downloadpage allowing fast release cycles and continuous updates to project partners.

For the pilots, the app will be made available via the Google Play Store4 and can then be

downloaded by everybody.

4 https://play.google.com/store

https://play.google.com/store



Page | 32


v.1.00, 28/12/2016

4 Web Application 4.1 Functionalities OPTIMUM Web Application provides the following functionalities:

o Statistics for monthly/yearly savings

o Visualization of entry/exit points along with the toll stations on an interactive map

o Visualization of a 24-hour time window fluctuation of the discounted toll prices along

the selected route

o Save/Load request along with the response.

Figure 18: OPTIMUM web interface dashboard

Figure 19: OPTIMUM web interface requests



Page | 33


v.1.00, 28/12/2016

Figure 20: OPTIMUM web interface toll discounts

4.2 Database The OPTIMUM Web Application uses MongoDB5 for storing all needed information. The

collections of the database are the following:

o User: stores all user information like username, password, email etc.

o Request: stores all requests that a user performs between an entry and an exit point.

o Route: stores all the selected routes that a user chooses to save.

5 https://www.mongodb.com

https://www.mongodb.com/



Page | 34


v.1.00, 28/12/2016

o Highway Node: stores all the highway nodes of Portugal.

o Section: stores all the sections of a highway node needed for the Dynamic Charging

Service.

o Toll: stores all the tolls of each highway of Portugal.

o Toll Price: stores all prices per toll per vehicle class.

Figure 21 illustrates the collections of the MongoDB used by the web interface in OPTIMUM.

Figure 21: OPTIMUM web interface Mongo DB collections

4.3 Dynamic Charging Service The Dynamic Charging Service receives requests from the OPTIMUM Web Application per

highway section and returns 24-hour fluctuation of the discounted toll prices of the specific toll

section of the highway. The following table contains a sample request/response.

Table 3: OPTIMUM web interface sample request & response for discounted toll prices

Request:

/v1/tariff?date=2016-12-31&section_id=18

Response:

[

[{

"Time": "00:00:00",

"18": 1.0588,

"Date": "2015-02-02"

}],

[{

"Time": "01:00:00",

"18": 1.4108,

"Date": "2015-02-02"

}],

[{

"Time": "02:00:00",

"18": 1.5713,



Page | 35


v.1.00, 28/12/2016

"Date": "2015-02-02"

}],

………..

[{

"Time": "22:00:00",

"18": 1.1095,

"Date": "2015-02-02"

}],

[{

"Time": "23:00:00",

"18": 0.5741,

"Date": "2015-02-02"

}]

]

4.4 Security & Authentication The OPTIMUM Web Application uses the JSON Web Tokens (JWT6) technique for security and

authentication, which supports all standard signature (JWS7) and encryption (JWE8) algorithms.

JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-

contained way for securely transmitting information between parties as a JSON object. This

information can be verified and trusted because it is digitally signed. JWTs can be signed using a

secret (with the HMAC algorithm) or a public/private key pair using RSA. The JSON Web Token

is useful for a number or reasons such as:

o Authentication: This is the most common scenario for using JWT. Once the user is

logged in, each subsequent request will include the JWT, allowing the user to access

routes, services, and resources that are permitted with that token. Single Sign On is a

feature widely used by JWT nowadays, because of its small overhead and its ability to be

easily used across different domains.

o Information Exchange: JSON Web Tokens are a good way of securely transmitting

information between parties, because as they can be signed, for example using

public/private key pairs, you can be sure that the senders are who they say they are.

Additionally, as the signature is calculated using the header and the payload, you can

also verify that the content hasn't been tampered with.

6 https://jwt.io

7 https://tools.ietf.org/html/rfc7515

8 https://tools.ietf.org/html/rfc7516

https://jwt.io/

https://tools.ietf.org/html/rfc7515

https://tools.ietf.org/html/rfc7516



Page | 36


v.1.00, 28/12/2016

4.5 Technology stack The technology stack used in OPTIMUM is presented here sorted by layer of the architecture,

more specifically:

o The Database layer technology stack is presented in section 4.5.1.

o The Middleware layer technology stack is presented in sections 4.5.2 to 4.5.8.

o The Front-end layer technology stack is presented in sections 4.5.9 to 4.5.12.

4.5.1 MongoDB9

MongoDB is a free and open-source cross-platform document-oriented database program.

Classified as a NoSQL database program, MongoDB avoids the traditional table-based relational

database structure in favour of JSON-like documents with dynamic schemas (BSON format),

making the integration of data in certain types of applications easier and faster. MongoDB is

developed by MongoDB Inc. and is free and open-source, published under a combination of the

GNU Affero General Public License and the Apache License. MongoDB is typically used as the

primary data store for operational applications with real-time requirements (i.e. low-latency,

high availability). MongoDB is easy to operate and scale in ways that are hard if not impossible

with relational databases. MongoDB excels in many use cases where relational databases are

not a good fit, like applications with unstructured, semi-structured and polymorphic data, as

well as applications with large scalability requirements or multi-data center deployments.

MongoDB may not be a good fit for some applications. For example, applications that require

complex transactions (e.g., a double-entry book-keeping system) and scan-oriented

applications that access large subsets of the data most of the time may not be a good fit for

MongoDB. MongoDB is not a drop-in replacement for legacy applications built around the

relational data model and SQL.

4.5.2 Thymeleaf10

Thymeleaf is a modern server-side Java template engine for both web and standalone

environments. Thymeleaf's main goal is to bring elegant natural templates to the development

workflow — HTML that can be correctly displayed in browsers and also work as static

prototypes, allowing for stronger collaboration in development teams. With modules for Spring

Framework, a host of integrations with own favourite tools and the ability to plug in own

functionality, Thymeleaf is ideal for modern-day HTML5 JVM web development — although

there is much more it can do.

9 https://www.mongodb.com

10 http://www.thymeleaf.org

https://www.mongodb.com/

http://www.thymeleaf.org/



Page | 37


v.1.00, 28/12/2016

4.5.3 Java 1.811

Java is a general-purpose computer programming language that is concurrent, class-based,

object-oriented and specifically designed to have as few implementation dependencies as

possible. It is intended to let application developers "write once, run anywhere" (WORA),

meaning that compiled Java code can run on all platforms that support Java without the need

for recompilation. Java applications are typically compiled to bytecode that can run on any Java

virtual machine (JVM) regardless of computer architecture.

4.5.4 Spring Framework12

The Spring Framework provides a comprehensive programming and configuration model for

modern Java-based enterprise applications - on any kind of deployment platform. A key

element of Spring is infrastructural support at the application level: Spring focuses on the

"plumbing" of enterprise applications so that teams can focus on application-level business

logic, without unnecessary ties to specific deployment environments.

4.5.5 Spring Boot13

Spring-boot is a framework developed on top of spring framework to ease the bootstrapping

and development of new spring applications. It makes it easy to create spring powered,

production-grade applications and services with absolute minimum fuss. Projects that are to be

packaged and distributed will need to rely on build systems like maven/gradle. It is used with

spring as a rapid application development platform with various components of spring, and has

the ability to package an application as a runnable jar, which includes an embedded

tomcat/jetty/undertow server.

4.5.6 Spring Data REST14

Spring Data REST builds on top of Spring Data repositories, analyses the application’s domain

model and exposes hypermedia-driven HTTP resources for aggregates contained in the model.

Spring Data REST:

o Exposes a discoverable REST API for the domain model using HAL as media type.

o Exposes collection, item and association resources representing the model.

o Supports pagination via navigational links.

o Allows to dynamically filter collection resources.

o Exposes dedicated search resources for query methods defined in repositories.

o Allows to hook into the handling of REST requests by handling Spring Application Events.

o Exposes metadata about the model discovered as ALPS and JSON Schema.

11

https://www.oracle.com/java/index.html 12

https://projects.spring.io/spring-framework 13

http://projects.spring.io/spring-boot 14

http://projects.spring.io/spring-data

https://www.oracle.com/java/index.html

https://projects.spring.io/spring-framework

http://projects.spring.io/spring-boot

http://projects.spring.io/spring-data



Page | 38


v.1.00, 28/12/2016

o Allows definition of client specific representations through projections.

o Ships a customized variant of the HAL Browser to leverage the exposed metadata.

o Currently supports JPA, MongoDB, Neo4j, Solr, Cassandra, Gemfire.

o Allows advanced customizations of the default resources exposed.

4.5.7 Embedded Servlet Containers

Embedding a servlet container, such as Jetty/Tomcat/Undertow, inside a Java application has

many advantages over running the application inside a container. Testing is relatively painless

because of the simple start-up, and the development environment is closer to production.

Nasty surprises like mismatched versions of libraries or drivers are eliminated by not sharing

across multiple applications. While having to manage and monitor multiple Java Virtual

Machines in production using this model, the advantages offered by the simplicity and isolation

are significant.

4.5.8 Token-based authentication

Token based authentication is prominent everywhere on the web nowadays. With most of the

web companies using APIs, tokens are the best way to handle authentication for multiple users.

There are some very important factors when choosing token based authentication for an

application, with the main ones including: 1) support of stateless and scalable servers, 2) being

mobile application ready, 3) passing authentication to other applications, and 4) guaranteeing

additional security.

4.5.9 jQuery15

jQuery is a fast, small, and feature-rich JavaScript library. It makes things like HTML document

traversal and manipulation, event handling, animation, and Ajax much simpler with an easy-to-

use API that works across a multitude of browsers. With a combination of versatility and

extensibility, jQuery has changed the way that millions of people write JavaScript.

4.5.10 Page.js16

Page.js is a small client-side routing library for use with building single page applications (SPAs).

It has a simple API which is inspired by Express. It utilizes the HTML5 history API under the

hood, which is what allows you to build smooth user interfaces while still having linkable URLs

for different pages of the app.

4.5.11 Bootstrap17

Bootstrap is a free and open-source front-end web framework for designing websites and web

applications. It contains HTML- and CSS-based design templates for typography, forms, buttons,

15

https://jquery.com 16

https://visionmedia.github.io/page.js 17

http://getbootstrap.com

https://jquery.com/

https://visionmedia.github.io/page.js

http://getbootstrap.com/



Page | 39


v.1.00, 28/12/2016

navigation and other interface components, as well as optional JavaScript extensions. Unlike

many web frameworks, it concerns itself with front-end development only. Bootstrap is

compatible with the latest versions of the Google Chrome, Firefox, Internet Explorer, Opera,

and Safari browsers, although some of these browsers are not supported on all platforms. Since

version 2.0 it also supports responsive web design. This means the layout of web pages adjusts

dynamically, taking into account the characteristics of the device used (desktop, tablet, mobile

phone). Starting with version 3.0, Bootstrap adopted a mobile-first design philosophy,

emphasizing responsive design by default. Bootstrap is open source and available on GitHub.

4.5.12 Mapbox18

Mapbox is built on vector maps, an advanced approach to mapping where data is delivered to

the device and precisely rendered in real-time. The result is smooth, fast maps. Maps render at

a super-high framerate — allowing the maps to fluidly respond to user feedback or scripted

events and opening up a whole new class of apps. Vector maps animate scale changes on the

fly, providing smooth zooming on mobile and desktop devices. You can rotate the map, tilt it,

and zoom in and out fluidly. Icons and labels adjust to maximize legibility from any angle. The

data for every feature you see in a vector map resides on the client, not the server. That means

data can be instantly queried, allowing for flexible map changes and user interfaces that adapt

to the map automatically. You can customize every aspect of your map, from tweaking the

colours, to hiding or showing specific layers, to choosing which information to present on your

map, all while your users are interacting with the map.

18

https://www.mapbox.com/maps

https://www.mapbox.com/maps



Page | 40


v.1.00, 28/12/2016

5 Design and User Interaction The User Experience Design of the OPTIMUM mobile application and web interface aims to

fulfil and form the requirements emerging from the project, while still being useful to end-users

of both applications. Of course, more emphasis is placed on the mobile application, given that it

contains a larger number of screens and interaction items, and is offered on mobile devices

with significantly smaller screen size and resolution than the web interface.

5.1 Information Architecture A well-considered information architecture organizes different elements to support usability

and findability. Organising information has the intent to support users in creating a mental

model so they can navigate easily within the application and find features and information they

are searching for and expecting to find. The information architecture comprises of the elements

o Upcoming Routes

o Nearby

o Route

o Trip history

o Profile

o Feedback

o About OPTIMUM

Users should be able to find all information, functions and elements necessary to use the

application.

The Information on Android is accessible via a navigation drawer19, which resonates with

Android design guidelines and spans the height of the screen, with everything behind visible but

darkened. Please see Figure 22 for the information architecture in the Android application as a

wireframe.

19

https://material.google.com/patterns/navigation-drawer.html

https://material.google.com/patterns/navigation-drawer.html



Page | 41


v.1.00, 28/12/2016

Figure 22: Information architecture as wireframe with navigation drawer.

5.2 Interaction Design Interaction design is the discipline of designing interactions regarding intuitive, positive and

target-oriented usage. In this phase designers synthesise requirements and imagine things,

elements, and functions how they might or ought to be. This element of interaction design is

what clearly marks interaction design as a design field as opposed to a science or engineering

field. Designers develop the system interactions step by step and document them by providing

a flow chart in wireframes. Prototypes are developed for critical user interactions and

evaluated with the help of project partners and their imaginations. These results feed into the

further wireframe flow charts.

5.2.1 Wireframes

The functional interaction design of the frontend OPTIMUM application is presented as

wireframe. Wireframes are created to arranging elements to depict the layout, interaction and

arrangement of the application’s content. This includes interface elements and navigational

systems, and how they work together. A wireframe purposefully lacks typographic style, colour,

or graphics, since the focus lies in interactions, functionality, and behaviour. Figure 23 and

Figure 24 comprise an example wireframe of the mobile application, while Figure 25 constitutes

the wireframe that was used for the development of the mock up and the actual interface of

the web application.



Page | 42


v.1.00, 28/12/2016

Figure 23: Extract of wireframes forming a flow chart with interactions between screens and elements.



Page | 43


v.1.00, 28/12/2016

Figure 24: Extract of wireframes forming a flow chart with interactions between screens and elements.



Page | 44


v.1.00, 28/12/2016

Figure 25: Web interface wireframe.

5.3 Visual Design The visual design of the application was inspired by the existing visual language provided by the

logo and the project website20. Moreover, the application follows wherever possible the

Android design guidelines and the metaphor of material design.

5.3.1 Colour

As on the website, turquoise is used as the main colour in both applications and orange as the

secondary colour. Please see Figure 26 for all OPTIMUM colours and Figure 28 how they are

used in the Screendesign. OPTIMUM red is used as a visual element for icons, green for green

transport modalities and OPTIMUM dark grey for typography.

20

http://www.optimumproject.eu/

http://www.optimumproject.eu/



Page | 45


v.1.00, 28/12/2016

Figure 26: Colour palette in OPTIMUM derived from logo used for visual Screendesign.

5.3.2 Iconography

The icons used throughout the mobile application are taken from Google’s material design

iconography21 when the appropriate icon is available from the collection. New icons are

designed according to the material design system icon guidelines22, so that newly designed

icons blend in with the visual language of icons from the material design icon collection.

Figure 27: Iconography used in the OPTIMUM application. Red icons are ornamenting

21

https://design.google.com/icons/ 22

https://material.google.com/style/icons.html

https://design.google.com/icons/

https://material.google.com/style/icons.html



Page | 46


v.1.00, 28/12/2016

Figure 28: Colours used in visual design with turquoise as primary colour and orange as secondary colour.

The icons used for the OPTIMUM Web Application are taken from Open Iconic23, an open

source icon set with a lot of marks in SVG, web font and raster formats.

Figure 29 – Open Iconic Iconography

5.3.3 Typography

The standard font for Android applications, according to the guidelines, is Roboto24. Roboto is

described as mechanical and friendly at the same time. Different weights come with this font

and for the use in Android, it is specified in different heights depending on the importance of

23

https://useiconic.com/open

24

https://material.google.com/style/typography.html




Page | 47


v.1.00, 28/12/2016

information. For reasons of coherency, Roboto is also used as the font of the OPTIMUM Web

Application.

Figure 30: Roboto font weights and sizes for Android applications. Picture from google material design guidelines

25.

5.3.4 User Interface Design

The User Interface Design of the OPTIMUM mobile application lends itself to material design26

guidelines, a visual design language developed in 2014 by Google. Material behaviour derived

from physics is used as a metaphor for the interactions and visual design, where different layers

indicated by shadow depth relate to each other by rules of motion from the real world. The

user interface design process must balance the requirements of technical functionality and

visual elements such as iconography, typography and colour to create an aesthetically

appealing and usable system. The OPTIMUM Web Application is based on Bootstrap27 layout.

25

https://material.google.com/style/typography.html 26

https://material.google.com/#introduction-principles 27



https://material.google.com/#introduction-principles




Page | 48


v.1.00, 28/12/2016

5.4 Usability and User Experience User experience and usability feedback are vital to design an application easy and intuitive to

use. The usefulness of a product, user-friendly navigation and aesthetically pleasing interfaces

are the basis for satisfying and good user experience. Good user experience guarantees that

complex processes are transformed into clear and easily understandable interfaces and

interactions. To support the agile development process throughout the whole project, on-going

prototyping (Buxton, 2010) with informal expert reviews (Vredenburg, 2002) by the design

team and other experts and stakeholders of the project are provided.

5.4.1 Prototyping

The importance of prototyping from the beginning of a project has been proven to be vital for

developing good experiences (Buxton, 2010). Prototyping is used to imagine and synthesise a

future system on e.g. sketches or wireframes (see chapter 5.2.1) which enable to evaluate new

designs. The aim of constant prototyping is being able to improve the system through

discussing and forming requirements for the next version of a prototype. These will also provide

specifications for the real and working system. Prototyping and learning during this prototyping

process as well as the reflections on the prototypes are critical to improve and move on.

5.4.2 Expert reviews

Informal expert reviews are a widely-used method to provide feedback for prototypes. Expert-

based methods are widely-used because of their practicality, effectiveness, costs, speed, and do

not require the recruitment of users (Vermeeren, 2010). Feedback from these reviews provide

food for the next iteration of a prototype and incrementally develops a better understanding

and design of the prospective system.

5.4.3 Design choices based on expert reviews and feedback

Design choices are on the one hand based on the designedly abilities of the design team, and

on the other hand on minding constraints of technologies and requirements from different

stakeholders. Making the most important design choices is visible in this deliverable.

5.4.4 Usability and User Experience process

For the OPTIMUM application, an iterative approach was chosen to develop the design and the

user interaction. In short release cycles, new designs were released. Internal and external

experts provide their feedback for improvements and enhancements. The process was

performed during the conceptual design, the visual design, prototyping and during

development with feedback loops between the phases. The process is visualised in Figure 31.

The following section highlights some examples of evolutions of design aspects of the mobile

application.



Page | 49


v.1.00, 28/12/2016

Figure 31 Design process

Figure 32: Route search changes

At the first iteration was the focus on main function (from, to, time/date, option) of the route

request. Within the second iteration, the design has been optimized as shown in Figure 32. The

design has more icons for visual support. The main function, the search button, is highlighted.

The placeholder text in the search fields are not so technical, but friendlier questions.

Furthermore, the route search has more function than at the first version. You can change the

search fields and you can add via points.

When you tap into the search field, first you get main options (current location, home address,

work address and history). After the user enters text into the search field, this options will be

disabled and the search results are shown.



Page | 50


v.1.00, 28/12/2016

Figure 33: Route results changes

The main difference between the first and the second version of the route results is the

iconography (see Figure 33). Modality icons always have a filled background. The modality icons

contrast with the remaining icons in the app. The colour of the modalities depends on the type

of modality. For example, walk and bike is green because they are very eco-friendly.

The incentive message for the route result has the background colour as the matching result

(see Figure 33).



Page | 51


v.1.00, 28/12/2016

Figure 34: Route options changes

The options screen for route requests have separated sections e.g. parking and modalities (see

Figure 34). If the modalities car and/or bike are selected, the user can add the location of the

own car/bike. The modality icons are also displayed.



Page | 52


v.1.00, 28/12/2016

Figure 35: Route detail changes

Figure 35 shows the iterative improvement of the route details, the main difference between

the first and the second version is the usage of tabs. The screen is separated in details and map.

The map view is now full screen and information shown on the detail screen is reduced with

focus on the legs of the trip. A floating action button is used to select routes. Every leg has the

colour of its modality. Additional details per leg are provide such as distance and CO2. The user

can zoom in and out on the map.

The same process was followed for the web application as well. The consortium was engaged in

prototyping and also engaged both experts and end-users so as to deliver the final version of

the first iteration of the web application. As illustrated in Figure 25, the consortium created the

wireframe based upon the analysis of user requirements. After engaging both experts and end-

users, the consortium created the mock-up of the web interface, as illustrated in Figure 36,

which was in turn further evaluated by the design team and the end-users, and that eventually

led to the development of the prototype of the web interface as illustrated in Figure 37, which

facilitates easier usage.



Page | 53


v.1.00, 28/12/2016

Figure 36: web interface mock-up

Figure 37: web interface prototype



Page | 54


v.1.00, 28/12/2016

6 Conclusion and Outlook The deliverable describes the initial version of the Mobile App and the Web application

improvements will be made during the trials that will take place. For that the end user

information is fundamental to present better and more fine-tuned tools.

The Mobile Application presents the interface for the user to the functionalities of the

OPTIMUM platform. The app provides improved, personalised and pro-active information for

common travellers. It also addresses the need of motor van travellers exploring a new city or a

new country. The application provides a powerful tool to equip the user will all information

about the trip and keep the user up- to date about ongoing and upcoming trips. The final

version will extend the functionalities of the initial version by providing a map view to explore

different POIs in the surrounding area (e.g. camping places) of the current location as well as

for potential destination. The tracked GPS positions of the user can be made available within

the app providing a trip history. The route information will be extended by a navigation feature.

The navigation provides travel instructions for the user for the ongoing tips. The planed trails

will be used to collect as much feedback as possible to improve the mobile application and the

components of the OPTIMUM platform. Iterative improvements of the application are planned

following an agile development approach.

In the second and final version of the Web Interface, apart of course from extensive testing and

debugging as deemed appropriate, based upon the feedback received from the pilot trial

partners, and according to the availability and validity of data used for the dynamic charging

component, the consortium partners will proceed with enhancing the functionalities of the

interface. Initial enhancements discussed between the partners involved in the development of

the web interface, which will be considered to be integrated include: 1) selection of specific

routes and timings out of the total calculated forecasts, that can be sent to the corporate truck

drivers, 2) exclusion of toll stations across a specific route along a highway, for the corporate

truck driver to be able to exit the highway prior to the specific toll stations and enter the

highway in a subsequent entry point, 3) calculation of the complete amount of tolls to be paid

along a specific route, talking into consideration the fluctuation of the discounts during the day,

and the time required to pass through the toll stations along the route based upon historical

traffic flow data, 4) actual calculation of the total savings on a monthly and annual basis, based

upon the timings selected for the truck to pass through toll stations along a specific route, as

per the enhancement described before.



Page | 55


v.1.00, 28/12/2016

7 References Buxton, B. (2010). Sketching user experiences: getting the design right and the right design.

Morgan Kaufmann.

Vermeeren, A. P., Law, E. L. C., Roto, V., Obrist, M., Hoonhout, J., & Väänänen-Vainio-Mattila, K.

(2010, October). User experience evaluation methods: current state and development needs. In

Proceedings of the 6th Nordic Conference on Human-Computer Interaction: Extending

Boundaries (pp. 521-530). ACM.

Vredenburg, K., Mao, J. Y., Smith, P. W., & Carey, T. (2002, April). A survey of user-centered

design practice. In Proceedings of the SIGCHI conference on Human factors in computing

systems (pp. 471-478). ACM.

Documents

DELIVERABLE...Project Acronym: OPTIMUM Grant Agreement number: 636160 (H2020-MG-7.1 - RIA) Project Full Title: Multi-source Big Data Fusion Driven Proactivity for Intelligent Mobility