Upload
others
View
4
Download
0
Embed Size (px)
Citation preview
D3.1
SCENARIO, FUNCTIONAL AND TECHNICAL
SPECIFICATIONS - RELEASE 1 March 2014
ABSTRACT
This document is an updated version of the initial release submitted in September
2013.
It describes scenario developed in the “Smart City Guide” platform applications
(1st release)
This document is a deliverable of the FI-CONTENT 2 integrated project supported by the European
Commission under its FP7 research funding programme, and contributes to the FI-PPP (Future
Internet Public Private Partnership) initiative.
© FI-CONTENT 2 consortium 2014
D3.1 V2.0 - March 2014
Page 2 of 53
DISCLAIMER
All intellectual property rights are owned by the FI-CONTENT 2 consortium members and are protected by
the applicable laws. Except where otherwise specified, all document contents are: “© FI-CONTENT 2 project
- All rights reserved”. Reproduction is not authorised without prior written agreement.
All FI-CONTENT 2 consortium members have agreed to full publication of this document.
The commercial use of any information contained in this document may require a license from the owner of
that information.
All FI-CONTENT 2 consortium members are also committed to publish accurate and up to date information
and take the greatest care to do so. However, the FI-CONTENT 2 consortium members cannot accept
liability for any inaccuracies or omissions nor do they accept liability for any direct, indirect, special,
consequential or other losses or damages of any kind arising out of the use of this information.
DELIVERABLE DETAILS
[Full project title]: Future media Internet for large-scale CONTent experimENTation 2
[Short project title]: FI-CONTENT 2
[Contract number]: 603662
[WP n°]: WP3 – Smart City Guide Platform
[WP leader]: Claire Bille-Bize Masson, Orange
[Deliverable n°]: D3.1
[Deliverable title]: Scenario, functional and technical specifications - release 1
[Deliverable nature]: Report (R)
[Dissemination level]: Public (PU)
[Contractual delivery date]: M12 - March 2014
[Actual delivery date]: 4 April 2014
[Editor]: Claire Bille-Bize Masson, Orange
[Internal Reviewers]: Robert Seeliger, FhG-FOK / Dirk Krauss, PIX / Martin Gordon, RBB / Kenny
Mitchell, BLRK / Pieter van der Linden, TSA
[Suggested readers]: Executives in internet services companies
[Keywords]: City Guide, Services, Enablers
[File name]: FI-CONTENT 2_WP3-004_D3.1_V2.0
© FI-CONTENT 2 consortium 2014
D3.1 V2.0 - March 2014
Page 3 of 53
EXECUTIVE SUMMARY
This document specifies the “Smart City Services” platform reference applications. Main scenarios
introduced in this document have been identified with all WP3 partners, technical partners and
experimentations site owners.
Our overall idea of a “Smart City Services” platform is a set of services and respective applications that
assist people and interest groups to find orientation, inspiration and help in urban environments assisted by
connected devices.
The application functionalities described in the document are: on site visit, local content and
recommendation, virtual mixed reality, device to device content sharing, content synchronization, geo
functionalities and social network.
© FI-CONTENT 2 consortium 2014
D3.1 V2.0 - March 2014
Page 4 of 53
LIST OF AUTHORS
Organisation Author
FhG/FOK R. Seeliger
FhG/FOK C. Krauss
FhG/FOK M. Zwicklbauer
Orange A. Brun
Orange C. Bille Bize Masson
Orange D. Deuff
Orange F. Feurtey
Pixelpark D. Krause
Thales Communications
and Security
F. Benbadis
I2Cat Sergi Fernandez
I2Cat Marc Aguilar
Grassroots Carmen Mac Williams
© FI-CONTENT 2 consortium 2014
D3.1 V2.0 - March 2014
Page 5 of 53
TABLE OF CONTENTS
EXECUTIVE SUMMARY ............................................................................................................. 3
LIST OF AUTHORS ................................................................................................................... 4
TABLE OF CONTENTS .............................................................................................................. 5
LIST OF FIGURES AND TABLES ................................................................................................. 7
ABBREVIATIONS ..................................................................................................................... 8
1 - INTRODUCTION – PURPOSE OF THIS DOCUMENT .................................................................... 9
1.1 - Overview ............................................................................................................................................... 9
The android native application user-centred process of design and development ....................................... 9
1.1.1 - The early design phase ............................................................................................................... 10
1.1.2 - The development phase .............................................................................................................. 11
1.1.3 - The experimentation phase ......................................................................................................... 12
1.2 - Terminology......................................................................................................................................... 12
1.3 - Cooperation with the others FI-CONTENT platforms ......................................................................... 13
2 - PLATFORM SCENARIOS .................................................................................................... 14
2.1 - Overview ............................................................................................................................................. 14
2.2 - Description .......................................................................................................................................... 14
2.2.1 - “On site visit” scenario ................................................................................................................. 15
2.2.2 - Local Content and Recommendation scenario ........................................................................... 21
List of functionalities : ...................................................................................................................................... 23
Screen shots: .................................................................................................................................................... 25
2.2.3 - Virtual/mixed Reality scenario ..................................................................................................... 27
List of functionalities: ....................................................................................................................................... 28
2.2.4 - Content sharing scenario ............................................................................................................. 29
List of functionalities: ....................................................................................................................................... 32
Screen shots: .................................................................................................................................................... 32
2.2.5 - Social network scenario ............................................................................................................... 34
List of functionalities: ....................................................................................................................................... 35
Screen shots ..................................................................................................................................................... 35
3 - CONTENT SOURCES ........................................................................................................ 36
3.1 - Experimentation in Barcelona ............................................................................................................. 36
3.2 - Experimentation in Berlin .................................................................................................................... 37
3.3 - Experimentation in Brest ..................................................................................................................... 37
3.4 - Experimentation in Cologne ................................................................................................................ 39
4 - CONCLUSION .................................................................................................................. 40
REFERENCES ....................................................................................................................... 41
© FI-CONTENT 2 consortium 2014
D3.1 V2.0 - March 2014
Page 6 of 53
ANNEX A USER CENTRED DESIGN METHOD ........................................................................ 42
ANNEX B EVOLUTION OF SUS AND ATTRAKDIFF RESULTS THROUGH 5 SHORT USER TESTING OF
THE ANDROID APPLICATION ................................................................................................... 43
ANNEX C RESULTS OF KANO’S METHOD APPLIED FOR DETECTING NEXT FUNCTIONS TO
DEVELOP 45
ANNEX D COMMON SCENARIO ........................................................................................... 48
© FI-CONTENT 2 consortium 2014
D3.1 V2.0 - March 2014
Page 7 of 53
LIST OF FIGURES AND TABLES
LIST OF FIGURES
Figure 1: Overview of the process applied on the android native application ................................................. 10 Figure 2: Overview of the reference service .................................................................................................... 14 Figure 3: UI of the Smart City Guide on a smartphone ................................................................................... 20 Figure 4: The four main phases of UCD, based on the schema given in ISO 9241-210 [10] ......................... 42 Figure 5: SUS and attrakdiff results progress through the android application’s development phase ........... 43 Figure 6: Attrakdiff hedonic (HQ-I, HQ-S) and attractiveness (ATT) indicators results with 12 users ............ 44 Figure 7: Distribution of Smart City core and potential functions regarding Kano’s model (function’s
description correspond to the number in the Table 1) ..................................................................................... 45
LIST OF TABLES
Table 1 Kano’s model results for 35 Smart City core and potential functions ................................................. 46
© FI-CONTENT 2 consortium 2014
D3.1 V2.0 - March 2014
Page 8 of 53
ABBREVIATIONS
API Application Programming Interface
AR Augmented Reality
FTP File Transfer Protocol
GE Generic Enabler
HTTP HyperText Transfer Protocol
IMS IP Multimedia Subsystem
LAN Local Area Network
POI Point Of Interest
QoS Quality of Service
QoE Quality of Experience
SE Specific Enabler
SCG Smart City Guide
SUS System Usability Scale
TCP Transmission Control Protocol
UML Unified Modeling Language
WAN Wide Area Network
XML Extensible Markup Language
© FI-CONTENT 2 consortium 2014
D3.1 V2.0 - March 2014
Page 9 of 53
1 - INTRODUCTION – PURPOSE OF THIS DOCUMENT
This deliverable mainly specifies the “Smart City Services” platform applications. Therefore, it describes
scenarios developed in task 3.1 and also identifies experimentation sites specificities. Main scenarios
introduced in this document have been identified with all WP3 partners, technical partners and
experimentation site owners.
This deliverable will give inputs to D3.2 Platform available for user test first iteration that identifies technical
functions that are necessary to set up the service and that define an overall architecture.
The final application of the “smart city guide” aims at having functions before, during and after a visit to a city.
Another goal of this application is to be available on various devices (mobile, tablet, PC, connected TV). In
this first iteration we mainly focused on mobile devices. The idea is then to extend the service to other
devices such as the tablet, PC and connected TV, and to other periods (before and after visit), while we will
have the core functions identified together with end users.
Two “reference mobile applications” have been developed and introduce the core functions of the Smart City
Service. One is an android native application and the other one is a web application based on HTML5.
1.1 - Overview
The android native application user-centred process of design and development
The process used to design and develop the Smart city android application is based on the user-centred
agile method [8]. On the basis of the fact that agile methods and user-centred design have points in common
(search of regularly feedbacks, process based on iterations, will to answer users’ needs), this method is a
mutual integration of the user-centred design method (Annex A User Centred Design method) and the scrum
agile method. The aim of the user centred agile method is to enable regularly feedbacks from users through
all phases of the project.
This process is divided into three phases Figure 1: early design phase, agile development phase and
experimentation phase. For each phases, we describes in next sections the methods applied to design and
develop the application.
© FI-CONTENT 2 consortium 2014
D3.1 V2.0 - March 2014
Page 10 of 53
Figure 1: Overview of the process applied on the android native application
1.1.1 - The early design phase
During the phase of early design, we built a first version of the Smart City Application to get data regarding
the users target needs.
The concept vision (see Figure 2) was built during a two day workshop.
Following these workshops, in order to get information regarding the users’ target, we conducted interviews
with 15 students. Results of analyse of these interviews enable us to focus on the main functions to develop
in the first version.
Once the functions’ perimeter is established, the design of the application started. To validate the first step of
the design, we used the RITE (Rapid Iterative Testing and Evaluation) method which consists of realising
successive sessions of user testing, and of modifying the application between sessions to improve the
design. During the sessions, users were invited to realised tests on a mock up realised with the Axure design
tool.
This early design phase aims at defining what could be the core of the application for first iteration in order to
launch developments.
UT = User Testing
© FI-CONTENT 2 consortium 2014
D3.1 V2.0 - March 2014
Page 11 of 53
1.1.2 - The development phase
Development of the application started on April 29th. It is a development based on Scrum agile method. An
iterative and agile approach aims at including any feedback during development phase. The distinctiveness
of the method we applied here is the integration of short user testing in each sprint to get user feedbacks [8].
Each sprint lasts 4 weeks of development. A sprint starts with a sprint planning and ends with a sprint
review. Everyday developers and the ergonomist (who is in charge of the design and the realisation of the
user testing) have a 15 minutes scrum meeting to know the application state of development.
Developers are using the interactive Axure mock up as inputs of their work. This Axure mock up continues to
be design and evolves during the development phase according to users’ feedbacks
Several testing methodologies were applied during the development phase. The main goal was to insure that
the application produced at the end of each sprint met the required quality level to be given to end-users.
1) To prevent regressions, automatic tests were implemented at the code level (unit tests and
integration tests) and at the GUI level, using Robolectric and Robotium frameworks.
2) A dedicated tester conducted intensive testing on the application, on the target devices (Samsung
Galaxy S3 and S4) with a mobile 4G data connection. During each sprint, once a stable release was
available, new features were tested systematically. Features previously implemented were also
tested to detect regressions. Those tests aimed at detecting bugs, but also any problem of stability
or performance impairing the user experience.
3) Before the first experimentation in Brest, a one-day field test was conducted. It involved 3 persons
who tested the application in real network conditions, insuring that the application behavior was
correct from a end-user perspective (usability, technical issues, performances…) for all the proposed
features.
Issues and feedbacks were tracked in a dedicated collaboration tool based on the Tuleap open-source
solution. Each item had a priority associated to insure that critical defects would be corrected first.
During the short user testing, the ergonomist meets individually four users in Brittany; two “new” users and
two users who come several times. These users were recruited by Imagin Lab. During this first iteration of FI
content, we were able to meet 14 users through 5 user testing. These users were asked to:
Realise a card sorting to identify the sub-categories which compose the different categories of
information (moving, entertaining, travelling, learning, managing our life, shopping). The idea is that
a point of interest belongs to a sub-category and then can be identify by a colour and a sub-category
icon. Results of this work is set out in section 3.3 -Experimentation in Brest
Evaluate the application under development through scenarios. The idea is to observe the ease of
use and to detect usability issues early in the process in order to make changes on the application to
improve it.
Evaluate through scenarios the functions available on Axure mock up but not yet been developed.
The idea is to detect design issues early in the process in order to make changes before
development start.
Answer three questionnaires: the System Usability Scale questionnaire, the attrakdiff questionnaire
and the kano questionnaire. The two first questionnaires are used as a metric to follow the evolution
of the user experience in term of usability, attractiveness and appearance. Results which are given
in Annex B (Evolution of SUS and attrakdiff results through 5 short user testing of the android
application) should be considered cautiously because only 4 users take part in each user testing.
The Kano questionnaire was applied to identify and prioritise the next functions to develop. Early
results are given in Annex C (Results of Kano’s method applied for detecting next functions to
develop).
Using this method enables us to get regularly end users inputs to define and to improve the application all
along the development phase.
© FI-CONTENT 2 consortium 2014
D3.1 V2.0 - March 2014
Page 12 of 53
This method aims at reducing the usability risks.
1.1.3 - The experimentation phase
From October, the 21th the application will be tested with 30 users. These 30 users are divided into two
groups of 15 persons who will use the application during 4 weeks in their environment. To gain users’
feedbacks regarding this first version of the application, we plan to:
create log files,
ask the users to answer questionnaires,
ask some users to participate to a focus group,
We aim through this experimentation to get information regarding the level of attractiveness and utility of the
application. These will help to improve the application and identify the orientation to take for the second
version.
The design phase continues in parallel and we had several exchanges, and one workshop and one specific
face to face meeting to define and improve common scenario with partners. This common scenario is our
common vision in order to take into account all feedbacks. The scenario gives ideas to improve and evolve
the application (Annex D: Common scenario).
The experimentation of the developed Smart City Service scenarios, applications and service took place at
the appropriate experimentation sites as follows:
Date Site Scenario
September 2013 Berlin On site visit
October 2013 Brest Local information and recommendation
November 2013 Brest Local information and recommendation
December 2013 Brest Device to device
February 2014 Cologne Social Network
February 2014 Barcelona Local information and recommendation
1.2 - Terminology
Application or
Application
software
Software layered on top of one or several platforms for realizing some (presumably)
useful tasks for end-users.
Architecture A structure of functional elements organized in a given way and presenting well
defined interfaces.
Enabler Software module or web service providing well-specified functionalities, accessible and
usable by application developers through clearly-described APIs (Application
Programming Interfaces).
Experiment or
Experimentation
Concrete test with actual users of one scenario in one of the experimentation sites in a
given time frame.
Functional
requirement
Either calculations, technical details, data manipulation, processing or other specific
functionality that define what a system is supposed to accomplish.
Generic Enabler An enabler realized by the FI-WARE project or its follow up sustainability project.
Platform A comprehensive combination of technology infrastructure and - Generic and Specific -
enablers capable to host and to support development of application software.
© FI-CONTENT 2 consortium 2014
D3.1 V2.0 - March 2014
Page 13 of 53
Point of Interest A POI is a place, an area or a journey (short distance) which are geo-located. For
example :
A place: a restaurant,
An area: a public garden,
A journey: a hiking trail.
A POI has possibly features such as :
Static features (opening hours, address, name description, etc.),
Dynamic features (price, menu, number of available places, the delay before
the next bus, etc.),
Event features (a beginning and an end).
Scenario Description of foreseeable interactions of users with one or several applications.
Specific Enabler An enabler realized by the FI-CONTENT2 project. Specific Enablers may be layered
on top of, or otherwise make use of, Generic Enablers. Please refer to the definition of
a FIcontent SE from deliverable D6.1 Architecture specification.
Interface The connections between domains (or sub domain or functional elements) serving the
actor’s actions by exchanging information.
1.3 - Cooperation with the others FI-CONTENT platforms
Deliverables 2.1 (Social Connected TV), 3.1 (Smart City Guide) and 4.1 (Pervasive Gaming) share
commonalities at many levels. First, the Reality Mixer will be used for Augmented Reality applied to any of
the scenarios in these deliverables. For example, AR may be equally applicable to tour guides as it is to
games. A second connection, is the social component which requires synchronisation of multiple users
using hand held devices or TVs. For example, while such synchronisation is potentially across multiple
devices in D2.1, it is also useful for synchronising the view of AR across multiple users for D3.1 as well as
D4.1. Further, new ideas such as leader-boards for gaming are potentially applicable to gamified tour-guide
scenarios. As an example, one of the field tests held at Aulani Hotel in Hawaii was using reality mixer in a
tour guide application, combined with an element of gameplay. Finally, at the core of providing a credible AR
experience lies the ability to track objects in video at real-time. The advanced UI GE’s provide such 3D web
and tracking for points-of-interest. For example, the POI Data Provider GE is a key component in many tour-
guide applications as well as games. Thus, the design of the GE’s is versatile and ties the scenarios
proposed in the three deliverables together at the level of functionality.
WP3 and WP2 Social Connected TV will also cooperate in the on site visit scenario. This cooperation sees
WP3 integrate the Second Screen Framework, developed in WP2, into the SCG app. This is used to create
a connection between the SCG app on the TV and the mobile device. Once the connection is established the
framework is used to handle communication between the application. The user can thus use the mobile
device to control the app on the TV and can receive related content on the mobile device while watching
user generated photos and videos on the TV.
A further WP2-WP3 cooperation is planned in the form of a joint experimentation. RBB plans a 25 hour-long
broadcast in November 2014 to mark the 25th anniversary of the fall of the Berlin Wall; this event will be
used as the basis for testing and demonstrating functionalities of the WP2 toolbox (Multi-Screen Experience
Scenario). WP2 and WP3 are exploring the possibility of running a joint experiment, testing WP3 on site visit
scenario as part of the toolbox experimentation.
© FI-CONTENT 2 consortium 2014
D3.1 V2.0 - March 2014
Page 14 of 53
2 - PLATFORM SCENARIOS
2.1 - Overview
Figure 2: Overview of the reference service
2.2 - Description
Readers familiar with the prior version of this document will observe a number of changes in the current
version. The FI-CONTENT 2 consortium introduced a common terminology to be used across the project's
documents. A number changes to the document were implemented in order to align its content with this new
terminology.
Thus the device to device content sharing in geo communities, content synchronization and geo
functionalities have been merged in one scenario.
We now have the 5 following scenarios:
- Scenario 1 “On site visit” is based on the outputs of a HTML 5 Smart City Guide application focused
on multidevices and end user contribution capacities.
- Scenario 2 “Local Content and Recommendations” is based on output of an Android Smart City
Guide application focused on integration of a large variety of contents and recommendations.
- Scenario 3 “Virtual Mixed reality” focused on spatial database capacities n the SCG context.
- Scenario 4 “Content sharing” focused on the ability to seamlessly share content between users
when no infrastructure connectivity is available.
- Scenario 5 “Social Network” focused on social interactions.
© FI-CONTENT 2 consortium 2014
D3.1 V2.0 - March 2014
Page 15 of 53
2.2.1 - “On site visit” scenario
Category/topic/context “On site visit”
Owner(s)/contacts Robert Seeliger (FhG/FOK), Chris Krauss (FhG/FOK), Miggi Zwicklbauer
(FhG/FOK)
Abstract Creating interactive content on SCG tour
Detailed description SCG users can use their SC Guide App on a tablet (Release 1 -R1) or
Smartphone (R1). In later releases users will be able to use the SCG on a
Smart TV in conjunction with a second screen app.
R1 (smartphone, tablet and SmartTV (Samsung SDK))
The mobile version of the SCG is designed to be used during the trip. It is a
web application running on iOS, Android and Windows devices. The user has
the opportunity to search for a point of interest (POI) on smartphone or tablet.
The user can view these on a map, in a gallery view or as a list. For each POI
there are details and related content is linked (first, second level). Events
happening near the user are also displayed on the map.
During the trip the user can use his smartphone to create and update POIs or
route information.
R2 (smartphone, tablet, PC, SmartTV and recommendation enabler)
The preparation of a trip can be done on a smartphone, tablet or PC. The
user creates a SCG account in the app and then enters a set of criteria for an
up-coming trip, for example, an area (a city or a specific section on the map),
a budget, a time interval (specific dates or times), his interests and how many
people would attend.
In R2 the recommendation enabler suggests suitable hotels and the user has
to choose one of them. Using this hotel as starting point, different routes are
generated showing all POIs, sights and events on a map. Otherwise the user
can create his own travel plan with the SCG (smartphone, tablet and PC).
The user could, for example, receive three trip suggestions for three days.
The first one being a walking route showing all important sights in the area
near the hotel. The second one shows routes to a local event on the second
day and the last route recommends renting a car in order to visit some
districts at the other end of the city.
The goal is to aggregate data during the trip in order to generate a report
afterwards. This report can be seen as an interactive photo book for
memories (in R3).
So users can record videos at a sight, create and display a video with content
enrichment, take pictures of events, check in at hotspot, rate POIs and view
related information while visiting. After the trip an automatic report is
generated, based on this UGC (e.g. images, videos, travel plan).
This report can be viewed on a smartphone, tablet, PC or SmartTV in
conjunction with a second screen app.R3 (all target devices, travel report,
augmented Reality, 3D map)
In R3 the end user gets recommendations for POIs during the trip. There is
© FI-CONTENT 2 consortium 2014
D3.1 V2.0 - March 2014
Page 16 of 53
even recommended content from partners about the POI proposed before
and while the tour. Another feature will be the augmented reality view of POI
around the user on mobile devices. For tablet version only, the user can view
public transportation around him in augmented reality and in real-time on a
3D map.
Afterwards a web application that runs on regular PCs, tablets, Smartphones
and TVs shows a resulting “interactive trip experience”. This is an
automatically generated review of my holiday highlights. This client uses the
content enrichment enabler and runs on all target devices again. In addition
to the automatically generated information the user can also select other
photos and videos taken during a predefined trip and attach related
information to the content using the application.
© FI-CONTENT 2 consortium 2014
D3.1 V2.0 - March 2014
Page 17 of 53
Planned experimentation
01. Experimentation site(s) Berlin
Estimated schedule 1st experimentation cycle (IFA trade fair Sep. 2013, Lab
trials March 2014)
Maturity of implementation Concept, lab test,
Content, provider, availability Existing content from Open City Database provided by
FhG/FOK and UGC taken by visitors via the app
02. Experimentation site(s) Barcelona
Estimated schedule April 2014
Maturity of implementation Lab test
Content, provider, availability Existing content from Open City Database provided by
FhG/FOK and UGC taken by visitors via the app
Functional requirements and their candidate enablers
From Sept. 2013
Functional requirement Candidate enabler GE/SE/Gap
01. Browse, show and add a Point of Interest Open City Database SE
02. Plan a trip Recommendation Services SE/ Gap
03. Add a video/photo to a POI Object Storage GE
04. Enrich a video with content Content Enrichment SE
05. Trip report on a second screen Second Screen Framework SE
© FI-CONTENT 2 consortium 2014
D3.1 V2.0 - March 2014
Page 18 of 53
Justification for inclusion
01. Audience and cultural criteria / justifications provides the user with more information on various European cities
user extend the database with content (POIs, pictures, comments, check ins, ratings, information)
smart travel guide with personalized recommendations before, while and after a journey
easier way to explore a known or unknown city
02. Academic criteria / justifications looking for open content to enrich the POI database
automatically generate information (public transport, opening hours, etc.) add by USG
research how users interact with a digital city guide using their smartphone, tablet, PC or SmartTV
Gather results on which content parts should be displayed where?
Gather results on how to present the content?
Gather results on interaction paradigms?
03. Commercial criteria / justifications creates new business models for museum, restaurant, sightseeing, theater etc.
Performance requirement
Type Requirement
Hardware
Software The Smart City Guide Web App runs on a node.js server as a meteor app (server and
client side) located at Fraunhofer FOKUS in Berlin.
The web app needs a stable and robust Internet connection (3G, LTE, Wifi) on mobile
devices in an HTML5 browser. Without this or with a lower connection (like EDGE) the
app itself and the communication between the app and integrated enabler (Open City
Database, Content Enrichment, Object Storage) will be interrupter.
A minimum level of administration rights is required allow users edit entries and to help
prevent abuse of the system. A user ID is required to add a Point of Interest to the Open
City Database. This ID is also necessary to write, delete or edit a POI in the database. For
example, apart from the OCD administrator, only the owner of the POI can delete it in the
Open City Database or any User can modify any public user generated POI.
Miscellaneous The SCG Web App receives its cities and Point of Interest data from the Open City
Database. This database deployed at Fraunhofer FOKUS needs qualitative and
quantitative data. The structure of a POI in the Open City Database should have a unified
format (JSON format).
A minimum of information must be defined to ensure any new POI entries by users are
© FI-CONTENT 2 consortium 2014
D3.1 V2.0 - March 2014
Page 19 of 53
relevant, i.e. each description must contain sufficient information to make it useful to other
users. To add a POI in the SCG app the user has to edit a form with required fields like
name, description, position (latitude, longitude), city, category, public or private and a
photo. The photo is taken by the integrated camera of the mobile device or uploaded on a
locale placed picture of the mobile device gallery.
© FI-CONTENT 2 consortium 2014
D3.1 V2.0 - March 2014
Page 20 of 53
Screenshots:
Figure 3: UI of the Smart City Guide on a smartphone
© FI-CONTENT 2 consortium 2014
D3.1 V2.0 - March 2014
Page 21 of 53
2.2.2 - Local Content and Recommendation scenario
Category/topic/context Local Content and recommendation
Owner(s)/contacts F. Feurtey (Orange), A.Brun (Orange)
Abstract Accessing local content aggregated from multiple sources (open data, web
sites, etc.), enriched with UGC and recommendations
Detailed description User profile management: creation, modification, deletion
03. Creation of a POI (place or event)/ a route
04. Search for a POI/a route
05. Evaluation of a POI /a route
06. Creation/modification/publication of UGC relative to a POI/a route
Provide recommendations to the user (POI, tours, content, etc.)
based on location and user’s profile
See the list of all functionalities bellow this chart
Planned experimentation
01. Experimentation site(s) Brest
Estimated schedule From October. 2013
Maturity of implementation Field trial
Content, provider, availability Existing content from open data and collaboration with
local content providers and public institutions
02. Experimentation site(s) Barcelona
Estimated schedule Feb. 2014
Maturity of implementation Field trial
Content, provider, availability Existing content from open data and collaboration with
local content providers and public institutions
© FI-CONTENT 2 consortium 2014
D3.1 V2.0 - March 2014
Page 22 of 53
Functional requirements and their candidate enablers
Functional requirement Candidate enabler GE/SE/Gap
01. Local content management Local Information SE
02. Recommender Recommendation services SE
03. Cloud object storage Cloud.ObjectStorage GE
Justification for inclusion
01. Audience and cultural criteria / justifications During the first interviews of students,
we get positive feedbacks and a strong
interest for the idea of having various
type of information pointed on a same
map.
From the mini user testing operated
during the development phase, we get
good results for the criteria of
attractiveness sprang from the
attrakdiff tool (Figure 5, Figure 6, page
44).
02. Academic criteria / justifications Research on how to integrate in a way that make sense for end user Open data, Professional content and User generated content
Adaptation and integration of technologies coming from different universe (Open data, TV, UGC, etc.)
Which content parts should be displayed where?
How to categorize contents?
How to present the content?
How to cluster Point of Interest?
03. Commercial criteria / justifications It was presented to some of our
institutional partners (Brest Métropole
Océane, Brest Tourism Office etc.)
which appeared very interested.
Performance requirement
Type Requirement
Hardware
Sofware
Miscellaneous In terms of technical performance, the two enablers involved have been tested
individually.
The backend server was tested:
10, 20 and 50 virtual users have simulated. The time of answer was observed as
well as the charge of the server.
© FI-CONTENT 2 consortium 2014
D3.1 V2.0 - March 2014
Page 23 of 53
The results were the following:
10 users 25 users 50 users
Nb of requests in
30 minutes
8715 (4,8 req/s) 21658 (12,0 req/s) 42889(23,8 req/s)
Error No No No
Time of answer
Average
Median
90% of times< 97ms
57 ms
48 ms
90% of times< 99ms
62 ms
48 ms
90% of times<100 ms
64 ms
50 ms
Charge Server Weak
CPU : 8,6%,
swap=0%
Weak
CPU : 8,6%,
swap=0%
Reasonable
CPU : 16,2%,
swap=0%
The times of answer are very satisfactory. In 90% of times the answers were below 0,1 seconds.
Thanks to optimized algorithms and code, the recommendation enabler is able to
handle several thousand users and/or items on a single server. The key resource is
the available memory (RAM).
The integrated application SUS (System Usability Scale) shows a good score of usability, attractiveness and appearance with 78.5 average score with the 43 potential users and experimenters who have tested the application.
List of functionalities :
My personal profile/data:
o I access to my profile
o I modify my profile
o I modify my photo
o I select descriptors
o I look to my personal lists
o I modify the rating of a POI in a personal list
o I look to the list of my posts
o I delete one of my posts
People:
o I see the profile of another user
Places:
o I see on a map the POI (places)around me
o I access to data relative to a POI (place) on a map
o I see in a list the POI (places) around me
o I do a search on a POI (place)
© FI-CONTENT 2 consortium 2014
D3.1 V2.0 - March 2014
Page 24 of 53
o I see in a list the POI (places) corresponding to my search
o I see in a map the POI (places) corresponding to my search
o I sort POI (places) of a list
o I see the description, of a POI (place)
o I see the details of a cluster of POI (places)
o I see the events associated to a place
o I access to recommendations of POI (places) close to me
Evaluation of a POI:
o I assign a rate to POI
o I see a rate I assigned to a POI
o I publish on Facebook the rate I assigned
o I add a POI in my desire list
o I see the global rate of a PIO (place)
o I see the global rate of an event
UGC for a POI:
o I post something on a POI
o I make my posts public or private
o I add one or several photos (from my gallery) in one of my post on a PIO
o I delete one of my post on a POI
o I see my posts relative to a POI
o I see public posts relative to a POI
o I see my photos relative to a POI
o I see the public photos relative to a PIO
o I see (full screen display) a photo relative to a POI and its description
Events:
o I see on a map the POI (events)around me
o I access to data relative to a POI (event) on a map
o I see in a list the POI (events) around me
o I do a search on a POI (event) by name, type, location, date, period
o I see in a list the POI (events) corresponding to my search
o I see in a map the POI (events) corresponding to my search
o I sort POI (events) of a list
o I see the description, of a POI (event)
o I see the places relative to an event
o I receive recommendations of POI (event) close to me
o I see the details of a cluster of POI (events)
Transports and routes:
o I see on a map the POI (bus, tramway) around me
o I search for a route (public transport)
o I see the details of a route (public transport)
o I see information about a bus/tramway stop
o I see information on a bus/tramway line
© FI-CONTENT 2 consortium 2014
D3.1 V2.0 - March 2014
Page 25 of 53
Screen shots:
I can modify my profile:
I can see POI around me on a map:
I can have few information about the POI:
© FI-CONTENT 2 consortium 2014
D3.1 V2.0 - March 2014
Page 26 of 53
I can have some details about a recommended POI:
© FI-CONTENT 2 consortium 2014
D3.1 V2.0 - March 2014
Page 27 of 53
2.2.3 - Virtual/mixed Reality scenario
Category/topic/context Virtual/mixed Reality
Owner(s)/contacts F. Feurtey (Orange), A.Brun (Orange)
Abstract Mixing virtual and real objects in a same hybrid reality
Detailed description This scenario consists of a spatial database and an application called
Hybrid Earth (web and mobile application)
It provides a list of neighbouring moving objects (either real of virtual)
according to positions
The position can be determined using available location features of the
smartphone, or by using the camera with AR marker databases
Functional requirements and their candidate enablers
Functional requirement Candidate enabler GE/SE/Gap
01. Mixing virtual and real objects in a same hybrid
reality
Virtual/mixed Reality SE
Justification for inclusion
01. Audience and cultural criteria / justifications The feature is available from a web
browser, or using by installing a mobile
application: anyone can register,
customize its appearance, enter the word
and chat with other users.
Several people visiting the same place
(physically or virtually) will be able to see
each other, communicate, exchange
information and participate in a tour.
Content creators (institutions, artists...)
will be able to add their own virtual
content to the world and share it with
other users.
02. Academic criteria / justifications Thanks to innovative algorithms, the
platform can scale smoothly to manage
virtually as many users and objects as
needed.
03. Commercial criteria / justifications Openness is guaranteed since the
platform offers an API to developers,
Performance requirement
Type Requirement
Hardware
Sofware
Miscellaneous The scenario can support several hundred to several thousand of simultaneous objects
and users, depending on the frequency of location update messages. Moreover, the
architecture is designed to scale to any number of objects and users by adding more
servers.
© FI-CONTENT 2 consortium 2014
D3.1 V2.0 - March 2014
Page 28 of 53
List of functionalities:
Available only on a second version of the SCG:
Visit a place virtually or in the real world, with added information (using AR)
Organize meetings mixing real people and avatars, for example for a guided tour (both outdoors and
indoors, which poses different challenges)
Insert moving objects from the real world, for example bus or tramways
Create, share and display UGC in the hybrid world (pictures, videos…)
Allow voice communication between users
© FI-CONTENT 2 consortium 2014
D3.1 V2.0 - March 2014
Page 29 of 53
2.2.4 - Content sharing scenario
Category/topic/context Content sharing
Owner(s)/contacts F. Benbadis (TCF)
Abstract Providing ability to seamlessly share content between users when no
infrastructure connectivity is available. Possibility to share content with geo-
fencing and geo-targeting capabilities.
Ability to synchronize content between two devices or between a device and
an online server.
Distribute/access content depending on geo-properties of user and content.
Detailed description Direct communications between users with no access to operator network.
Ability to share/synchronize content directly between users willing to avoid
roaming.
Synchronize UGC with content available online. Disseminate any type of
content in a geographical region.
Restrict the geographical scope of content broadcast.
Allows content synchronization between devices, in order to duplicate the
content or content synchronization between mobile device and online server,
in order to send content, generated in infrastructureless mode with online
server. Thus, other users, not in the vicinity of the user who generated the
content can get it.
Geo-targeting: distribute content in a certain area, defined by content
owner/provider
Geo-fencing: limit the diffusion of content to a certain area, defined also by
content owner/provider.
These capabilities are compatible with D2D communications as well as with
server to client communications.
Planned experimentation
01. Experimentation site(s) Brest
Estimated schedule Oct. 2013
Maturity of implementation Lab test
Content, provider, availability TCS, already available
© FI-CONTENT 2 consortium 2014
D3.1 V2.0 - March 2014
Page 30 of 53
Functional requirements and their candidate enablers
Functional requirement Candidate enabler GE/SE/Gap
01. Device-to-device network management Local network management SE
02. Content synchronization between users Local content management SE
03. Content synchronization between users and online
server
Online content management SE
04. Online content storage Content storage GE
05. Online content synchronization Content synchronization GE
06. Content geo-constrained diffusion Geo-targeting and geo-
fencing enablers
GE/SE
07. Establish ad hoc networks Community sharing SE
08. Discover neighbourhood Community sharing SE
09. Exchange content with neighbours Community sharing SE
10. Geo capable server Community sharing SE
Justification for inclusion
01. Audience and cultural
criteria / justifications
The device-to-device content sharing feature is available
through an Android library that can be used to exchange
content directly between users, without requiring any
infrastructure network. It will facilitate exchange between
people close, physically, to each other. It may be very
useful for tourist, preventing them from roaming expenses.
The content synchronization feature is also available as an
Android library to be used for synchronization of content on
two sides, either the content server or a terminal or
between two terminals. When infrastructure connectivity is
available, the synchronization feature allows the terminal to
download newly available content from the server. When
no connectivity with infrastructure is available, then it allows
content synchronization between terminals connected
directly, thanks to the device-to-device content sharing
feature. This latter content synchronization includes
downloaded content as well as locally generated content.
When terminals recover infrastructure connectivity, they
use the synchronization feature to upload content to the
online server.
The geo-functionality features allow the distribution and
© FI-CONTENT 2 consortium 2014
D3.1 V2.0 - March 2014
Page 31 of 53
synchronization of content according to geographical
information.
Geo-information is embedded in all generated content, it
allows locating the content generation, edition, or deletion.
It can also be used to either target the dissemination of a
content in a specific area, limit the diffusion of a content to
a certain area, or provide the availability of content in a
limited area.
02. Academic criteria /
justifications
Thanks to its new architecture, this platform may be used
as basis for development of new content distribution
applications. The ad hoc part of the library, as well,
provides direct communications for infrastructureless
communications.
We propose different types of synchronization algorithms,
based on QoS and user QoE, that allow investigation on
synchronization techniques in ad hoc situations.
We propose different types of synchronization algorithms,
based on QoS and user QoE, that allow investigation on
synchronization techniques in ad hoc situations.
03. Commercial criteria /
justifications
The features are provided through a library that provides an
API. It is dedicated to Android developers to embed these
features in their applications.
The features are provided through a library that provides an
API. It is dedicated to Android developers to embed these
features in their applications.
The geo-features are provided through a library that
provides an API. It is dedicated to Android developers to
embed these features in their applications.
Performance requirement
Type Requirement
Hardware
Sofware
Miscellaneous The device-to-device content sharing in geo-communities enabler is based on Apache
software, a web server used world widely and capable of handling thousands of
simultaneous requests, if the hosting platform has enough resources. The cloud
infrastructure that will be used to host this enabler guarantees resource availability.
The content synchronization enabler provides also direct communications between
users. Up to now, this enabler has been tested with up to 7 nodes exchanging and
synchronizing content with no performance issues.
The geo-functionalities provided in this specific enabler are embedded in the content
distributed thanks to the Apache server. Thus, they do not require any additional
resource and do not affect the performances of the application. Thus, the maximum
number of users capable of using this enabler are from the same order of magnitude
that the number of users able to access content from the Apache server.
© FI-CONTENT 2 consortium 2014
D3.1 V2.0 - March 2014
Page 32 of 53
List of functionalities:
Available in the first version of the SCG
Discovery of any terminals under wifi coverage.
Capability to join an existing network or create a new one.
Direct connectivity with neighbour terminals.
Direct communications with nearby terminals.
Periodic beaconing for control channel.
Availability as a library for Android.
Synchronize content between server and terminals. When a new content is available, it is sent to the
terminal. When a new content is generated on the terminal, it is sent to the server.
Synchronize content between different terminals
Synchronize content generated when no infrastructure was available with online server
The geo-features will be available in the second version of the SCG and will provide the following
capabilities
Embed geo-information in content
Display content on a map depending on geographic information. It can display where content has
been generated for instance.
Limit the synchronization of content outside a certain area.
Target the diffusion of content in a certain area.
Screen shots:
The library itself has no screenshot but we provide in the following an example of application using the
device-to-device content sharing library.
© FI-CONTENT 2 consortium 2014
D3.1 V2.0 - March 2014
Page 33 of 53
© FI-CONTENT 2 consortium 2014
D3.1 V2.0 - March 2014
Page 34 of 53
2.2.5 - Social network scenario
Category/topic/context Framework to establish social networking functionalities
Owner(s)/contacts Dirk Krause (PIX)
Abstract The social network scenario is linked to Social network enabler that is a
middleware that can be used to create a social network, either temporarily or
permanently for a group of users.
Detailed description It provides the functionality of social interactions in the digital world (like
posting status messages and images) apart from the major, proprietary
social networks (like Facebook). It is particularly useful for intra- or extranet
based social networks since users maintain the sovereignty about their own
data.
Planned experimentation
01. Experimentation site(s) Small scale experiment.
Estimated schedule
Cologne
March 2014
Maturity of implementation Small scale experiment, working prototype.
Content, provider, availability Carnival experiment with server parts hosted at FI-LAB
Functional requirements and their candidate enablers
Functional requirement Candidate enabler GE/SE/Gap
01. User social network management Social Network SE
Justification for inclusion
01. Audience and cultural criteria / justifications The Social Network Enabler is
targeted towards use cases that
require social network capabilities in
software infrastructures and political
environment that excludes or forbids
the usage of the big corporate
proprietary networks (like Facebook).
Since the SNE is free and open
source, maintainers and end-users
won’t be forced to give their personal
data to the big social media networks.
This is particulary important for end-
user groups that are not adult (like
pupil).
02. Academic criteria / justifications The SNE helps to enable and
measure a set of social interaction
tools for the end-users. The research
conducted on the user data is
abstracted from personal data and
evaluated in a qualitative way.
03. Commercial criteria / justifications The very liberal, open source MIT
licence makes it easy for SMEs to
use the software without limitations.
© FI-CONTENT 2 consortium 2014
D3.1 V2.0 - March 2014
Page 35 of 53
Performance requirement
Type Requirement
Hardware Cell phone of Nexus 5 class-type
Sofware Android 4.4.2
Miscellaneous - Number of concurrent users: 20 in small scale, 1000 in large scale.
- Bandwidth per hour per client: 100 MB
- Time to onLoad event: under 2 seconds
- UI quality perception by end user: better or equal to 'good'
- Overall quality perception by end user: better or equal to 'good'
List of functionalities:
I connect to the SNE
I disconnect from the SNE
I access status messages
I post status updates (text, images, etc.)
I follow users
I comment on posts
I ‘like’ posts
Screen shots
© FI-CONTENT 2 consortium 2014
D3.1 V2.0 - March 2014
Page 36 of 53
3 - CONTENT SOURCES
This paragraph gives the different content sources that will be used for the 4 Smart City Guide
Experimentations (Barcelona, Berlin, Brest, Cologne).
3.1 - Experimentation in Barcelona
Categories Sources / Themes Last
actualized
File
format
Link
List of culture
and leisure
equipment in
the city of
Barcelona
Types of Culture and leisure facilities to be found in Barcelona: libraries, cinemas, bookshops, museums, parks, viewing points, beaches, theatres, concert halls, auditoriums, etc.
30/08/2013 ZIP/RDF http://opendata.bcn.cat/ope
ndata/en/catalog/CULTURA_I
_OCI/equipamentculturailleu
re/
List of
restaurant
equipment in
the city of
Barcelona
Types of Restaurants to be found in Barcelona.
30/08/2013 ZIP/RDF http://opendata.bcn.cat/ope
ndata/en/catalog/CULTURA_I
_OCI/equipamentrestaurants
/#
List of
transportation
equipment and
related services
equipment in
the city of
Barcelona
Types of Transport and related services to be found in Barcelona: car parks, cycling lanes, petrol stations, car hire; air, sea, land and private transport; car-sharing etc.
30/08/2013 ZIP/RDF http://opendata.bcn.cat/ope
ndata/en/catalog/TRANSPOR
T/equipamenttransportsiserv
eisrelacionats/
Wifi hotspots WiFi access points, or hotspots, located in various municipal amenities and public access points. Coordinates UTM31 ED50. Barcelona has long offered a WiFi service that allows you to connect to the Internet through public access points located in various parts of the municipal facilities and public roads.
08/09/2013 CSV, OData & XML
http://opendata.bcn.cat/ope
ndata/en/catalog/CIENCIA_I_
TECNOLOGIA/puntswifi/
List of
accommodatio
n equipment in
the city of
Barcelona
Types of Accommodation to be
found in Barcelona: youth hostels,
apartments, camping sites, hotels,
boarding houses, student
residences, etc.
30/08/2013 ZIP/RDF http://opendata.bcn.cat/ope
ndata/en/catalog/TURISME/e
quipamentallotjament/
© FI-CONTENT 2 consortium 2014
D3.1 V2.0 - March 2014
Page 37 of 53
3.2 - Experimentation in Berlin
Available
Dbpedia
Open City database
Wikipedia
To be confirmed:
Berlin City data
VBB public transportation data
3.3 - Experimentation in Brest
Categories Sources used in the service
100 Entertainment
101 restaurants http://www.brest-metropole-tourisme.fr/
102 Leisure clubs http://www.brest-metropole-tourisme.fr/
103 Beaches
104 Golfs http://www.brest-metropole-tourisme.fr/
105 Movie theaters
106 Concert halls http://www.brest-metropole-tourisme.fr/
107 Shows
http://www.brest-metropole-tourisme.fr/
http://www.letelegramme.fr/agenda/
http://www.brest.fr/agenda/
108 bars/coffee
109 Camping grounds http://www.campingfrance.com
110 sport
111 Events, festivals http://www.brest-metropole-tourisme.fr/,
112 Theme parks http://www.parcsetloisirs.fr
113 Theaters
http://www.brest-metropole-tourisme.fr
114 Picnic area
200 Education
201 Points of interest Wikipedia,
202 Fair, trade show http://www.culture.gouv.fr/public/
203 Museum http://www.culture.gouv.fr/documentation/museo/
204 Conference, discussion
205 Historical buildings
206 Exhibitions
207 Libraries
208 Learning
300 Transports
301 Car parkings OSM Parking
302 Gas stations
303 Bus http://www.bibus.fr/ (not integrated)
304 Taxis OSM Taxis
305 Road traffic
306 Tramway http://www.bibus.fr/ (not integrated)
© FI-CONTENT 2 consortium 2014
D3.1 V2.0 - March 2014
Page 38 of 53
Categories Sources used in the service
307 Subway
308 Disabled parking OSM parking PMR
500 Daily life
worship
501 Youth information
502 Hospitals
504 Public administration
http://lannuaire.service-public.fr
Wikipedia
505 Theater
506 wifi Information provided by Orange
507 Nursing home
508 Public toilets
509 Place of worship OSM Worship places
510 Pharmacy
511 Post office OSM post office
512 Job agency
513 Cash ATM
514 Social agency
515 Waste collection centre http://www.sinoe.org
516 Mail box OSM Boxes
600 Shopping
601 Organic shops
602 Books
603 Sport
604 Supermarkets
605 Games
606 Clothes
Categories Sources used in the service
700 Travels
701 Railway station Wikipedia
702 Airport Wikipedia
704 Port
Wikipedia
Available
Brest city
French Culture Minister
Géo Pays de Brest
Keolis
OpenFlight
SNCF
Wikipedia
Le TélégrammeAgenda Culturel 29
© FI-CONTENT 2 consortium 2014
D3.1 V2.0 - March 2014
Page 39 of 53
Conseil Général Finistère
3.4 - Experimentation in Cologne
Available
Wikipedia
Export from myMaps within Google Maps
Export from “geonames”, which is a webservice providing geolocated Wikipedia data
© FI-CONTENT 2 consortium 2014
D3.1 V2.0 - March 2014
Page 40 of 53
4 - CONCLUSION
As conclusion the small scale experiments in the first experimentation cycle were a success and our
technology is stable enough to stage now large scale experiments with +1000 users in Europe and even
South America.
Due to the leave of the WP3 Leader Orange we are in this moment in a restructuring phase and we planning
to include new partners and a new leader in WP3. Currently we are preparing a large scale experiment with
all partners of WP3 around a cultural event in Barcelona called Festival LaMERCÈ with more than 1000
Participants and more than 500.000 visitors as rehearsal in Sep 2014 as well as THE final event for Sep
2015 as the show highlight of FI-CONTENT 2. We are in negotiation with the Barcelona City Municipality
representatives for their final official commitment and will update the Commission as soon we have official
news.
Starting 2014 we will also run more large scale experiments in all other FI-CONTENT 2 experimentation
sites as well as hopefully in South America around cultural and sport events to attract a large scale user
attention as well as third parties SMEs and Web developers from phase 3 to test our technology and co-
create a media ecosystem around the FI-CONTENT 2 and FI-PPP enablers.
© FI-CONTENT 2 consortium 2014
D3.1 V2.0 - March 2014
Page 41 of 53
REFERENCES
[1] Deliverable 3.2 – Platform description release 1 (FI-CONTENT 2)
[2] Content Enrichment Enabler - Specification (FOKUS)
[3] Open City Database - Specification (FOKUS)
[4] Local Information Specific Enabler (Ma Vie Locale product) - Specification (Orange)
[5] Recommendation Services Specific Enabler (Reperio Product) - Specification (Orange)
[6] Virtual/Mixed Reality Specific Enabler (Kiwano product) - Specification (Orange)
[7] Device-to-device content sharing in geo-communities - Specification (Thales Communications and
Security)
Documents available on the FI-CONTENT 2 Sharepoint (in WP 3 section)
[8] User-Centered Agile Method. D Deuff and M. Cosquer. ISTE Ltd, 2013.
[9] Brooke, J. (1996). "SUS: a "quick and dirty" usability scale". In P. W. Jordan, B. Thomas, B. A.
Weerdmeester, & A. L. McClelland. Usability Evaluation in Industry. London: Taylor and Francis.
[10] ISO/TR 16982, Ergonomics of human-system interaction — Usability methods supporting human-
centred design
© FI-CONTENT 2 consortium 2014
D3.1 V2.0 - March 2014
Page 42 of 53
Annex A USER CENTRED DESIGN METHOD
User-centred design (UCD) is an approach to the design and development of interactive systems. The
process is guided by knowledge of the end users, their use contexts and their needs, with the aim of
designing systems offering usefulness and ease of use. What is crucial in this method, is to meet users
regularly all along the project in order to offer the user the most positive experience possible with the product
or service.
The UCD method is described in the norm ISO 9241-210 [ISO 10]. According to this norm, UCD is a process
which has four main stages, and which is iterative on all or some of these stages, as illustrated by the
following diagram (Figure 4).
1. Understanding and specifying the context of use phase: there are three goals in this phase. One
aims at understand characteristics of the future users in relation to the service to be designed. One
consists in specifying the characteristics of the tasks relative to the future system; one intends to
identify the environment in which the future system will be used.
2. Specifying the user requirements: the goal of this phase is to write requirements that are constraints
stemming from data gained in the first phase and from the knowledge relating to the ergonomics and
the user interface.
3. Producing design solutions: on the basis of the previous stages, the objective here is to define the
user tasks in relation to the system and to design a version of the product or service.
4. Evaluating the design: This phase consists in meeting users and make them evaluate the product or
service provided by the previous phase. Products or services can be evaluated through various
formats depending on the degree of design progress. The improvement points identified during the
evaluation serve to validate a solution which satisfies the user requirements or serve as a basis for
the design of the next version.
Figure 4: The four main phases of UCD, based on the schema given in ISO 9241-210 [10]
As written in the norm ISO 9241-210 [10], the benefits of applying UCD are many and are regarded as
increasing the return on investment (ROI) [ISO 10].
© FI-CONTENT 2 consortium 2014
D3.1 V2.0 - March 2014
Page 43 of 53
Annex B EVOLUTION OF SUS AND ATTRAKDIFF RESULTS THROUGH 5 SHORT USER
TESTING OF THE ANDROID APPLICATION
At the end of each user testing session, following the activity based on scenarios that users have to do,
users were asked to answers to two questionnaires: the System Usability Scale questionnaire and the
attrakdiff questionnaire. The Figure 5 shows the results progress of the two questionnaires. It should be
noted that questionnaires were not filled because, the application under development was not enough
developed to be evaluated by users.
These results should be considered very cautiously as only four users answered the questionnaire each
time, and the application were under development and was not completed as user testing were realised.
These results are a tool during development to be alerted to bad perceived usability when the SUS score
or/and the pragmatic attrakdiff score decline sharply. As shown by Smart City results, these score were quite
stable and good during the progress of development. But they are not used as a significant score of the final
application perceived usability.
Regarding the hedonic and attractiveness indicators, the Figure 5 shows their progress during the
development phase, and the Figure 6 gives the results of attrakdiff questionnaire when holding concurrently
all answers gained through the development phase (the graphic and interaction design did not evolve during
the development phase).
These two figures show a strong level of attractiveness of the application, revealing a strong appeal to the
application concept.
Regarding the appearance indicators, except for the sprint 2, scores are stables. But scores are not high,
showing that appearance can be enhanced to improve the user experience.
Figure 5: SUS and attrakdiff results progress through the android application’s development phase
707580859095100
sprint 1 sprint 2 sprint 3 sprint 4 sprint 5
SUS results progress through the sprints
SUS
0.000.501.001.502.002.503.00
sprint 1 sprint 2 sprint 3 sprint 4 sprint 5
attrakdiff indicators results progress through the sprints
pragmatichedonic identityhedonic stimulationattractiveness
© FI-CONTENT 2 consortium 2014
D3.1 V2.0 - March 2014
Page 44 of 53
Figure 6: Attrakdiff hedonic (HQ-I, HQ-S) and attractiveness (ATT) indicators results with 12 users
© FI-CONTENT 2 consortium 2014
D3.1 V2.0 - March 2014
Page 45 of 53
Annex C RESULTS OF KANO’S METHOD APPLIED FOR DETECTING NEXT FUNCTIONS
TO DEVELOP
The Kano model is a model developed in 1984 by Professor Noriaki Kano in order to classify functions of a
product regarding customer preferences, expectation and satisfaction. Professor Kano showed that these
functions can be classified into five categories:
Must-be: functions have to be available in the product. They are considered essential functions in
the product.
Attractive: functions in this category were not expected but bring great satisfaction to the customer
if they are available.
One-dimensional: the more functions meet customer expectation, the more customer is satisfied,
and conversely.
Indifference: functions of this category have no influence on customer satisfaction.
Reverse: functions of this category increase customer dissatisfaction if they are available in the
product.
The Kano model is a tool that enables functions to be prioritised in order to support decision for design and
development phase.
The following figure (Figure 7) and Table 1 show results of Smart city core and future potential functions
regarding Kano’s model.
Figure 7: Distribution of Smart City core and potential functions regarding Kano’s model (function’s
description correspond to the number in the Table 1)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30 31
32
33
34
35
attractive one- dimensional
indifferent must-be
© FI-CONTENT 2 consortium 2014
D3.1 V2.0 - March 2014
Page 46 of 53
Table 1 Kano’s model results for 35 Smart City core and potential functions
function's number
numbers of users
function description must-be
one-dimensional
attractive indifferent reverse
1 12 profile account 0 4 4 2 2
2 12 changing the profile's image 1 4 3 3 1
3 12 disconnecting 0 11 0 1 0
4 12 geo-location of POI 0 12 0 0 0
5 12 account deletion 0 10 1 1 0
6 12 POI under lists 0 6 4 2 0
7 12 personal data modification 0 9 2 1 0
8 12 geo-location of a person 1 1 4 4 2
9 12 categories of POI 0 8 4 0 0
10 12 real time transport information
0 6 6 0 0
11 12 personal lists 1 9 2 0 0
12 12 giving a rate to a POI 0 4 2 5 0
13 12 commenting a POI 1 6 3 1 0
14 12 creating a POI 1 4 5 2 0
15 12 looking for POI 2 8 1 1 0
16 12 filtering POI 0 12 0 0 0
17 12 getting POI recommendations 1 5 2 4 0
18 12 getting POI's global rate 0 8 3 1 0
19 12 sharing POI through mail 0 1 3 6 1
20 12 sharing POI through facebook 0 2 2 7 1
21 12 adding images et videos to a POI
0 4 8 0 0
22 12 stating a contribution private or public
0 5 6 1 0
23 12 getting a route to a POI 0 10 2 0 0
24 12 getting profile of persons with same interests
1 2 5 2 1
25 4 getting access to newspapers and documentation regarding a POI
1 1 1 0 0
26 4 getting POI recommendations regarding my current situation
0 3 0 1 0
27 4 contacting volunteer people for a visit tour
0 3 0 0 0
28 4 getting mysterious and amazing route
0 2 1 0 0
29 4 discovering a place (history and anecdotes)
0 3 1 0 0
30 4 having access to the building historic evolving of a place
1 1 0 0 1
31 4 updating data without network connection
0 4 0 0 0
32 4 watching images et videos archive of a place
0 3 1 0 0
33 4 receiving notification when close to an interesting place
0 1 1 1 1
© FI-CONTENT 2 consortium 2014
D3.1 V2.0 - March 2014
Page 47 of 53
function's number
numbers of users
function description must-be
one-dimensional
attractive indifferent reverse
for me
34 4 managing an event agenda 0 2 0 2 0
35 4 creating a trip travel album 0 3 0 1 0
© FI-CONTENT 2 consortium 2014
D3.1 V2.0 - March 2014
Page 48 of 53
Annex D COMMON SCENARIO
The common scenario has been designed to have global view of what we can implement.
It aims at listing our function ideas for the SCG application by device according our feedbacks. It has been
worked in common with all partners. The idea is not to implement all of them but to identify in a way to help
design of application.
This is an extract of the ongoing work.
4 types of devices are identified: smartphone, tablet, PC and TV.
1. New user
(Identity Management GE, Community Sharing SE, Social Network SE)
Bob has downloaded the SCG app and configured the user profile.
The user can log in creating an account in our platform or using an existing account from other social
network like facebook or google+.
The user can manage the profile on any device, for example: setting an avatar, modifying personal
data, searching friends, defining categories of interest and deleting or unlinking the account (in case
of logging from other networks).
Bob could also get the application through the community sharing platform.
Bob arrives to Barcelona, he managed to get an Internet connection with his smartphone and tablet
and logged in.
2. Planning the day
(Recommendation Services SE, Local Information SE, Social Network SE Community Sharing
SE)
Bob wants to visit the center of Barcelona without any traditional guide. He does not know the city
and wants a first tour of maximum 4h.
The user can get routes (on smartphone and tablet) by time, kind of visit and coverage, in this
case, a generic route of 4h duration in the center of Barcelona. The resulting routes are the ones
generated automatically or uploaded by users. The user will get access to public routes with public
POI (Point of Interest), from their added contacts or their own saved ones.
The user can also use the community sharing to get routes.
If the user does not have a smartphone or tablet, he can browse and select a recommended route
on his PC at home and plan his trip ahead. He also has the opportunity to create a new route.
3. Getting access at PoI
(Local Information SE, Virtual/Mixed Reality SE, Social Network SE Location GE, Object
Storage GE, Video Streaming GE, Adv-user Interface GE (Augmented Reality))
POIs are some “Places of Interest” which are relevant for a user according to his preferences and
profile. A POI is a unique identifiable entity in a spatio-temporal reference system. It has - probably
multilingual - content attached to provide information about this “Place of Interest” to the user.
Bob can search for PoI (events, places, …) and get information about PoI according to its interests.
Different level of information can be suggested: a first level with geolocalisation, name and category,
© FI-CONTENT 2 consortium 2014
D3.1 V2.0 - March 2014
Page 49 of 53
a second level with sub category and main information such as opening hour and a third level with
much more details.
He could visualize PoI in a map or by list according to several criteria: rating, location, date for
events, like, category, opening …
Our User Bob can generally handle POIs in several ways:
a) Bob can get information about a POI according to his interests. Different levels of information
can be exposed to Bob (depends on the intended application):
a name or label with a geo-localization and a category/symbol/thumbnail
further information such as opening hours, detailed category/tagging and contact
information
and all the remaining details, like associated images, videos, 3D-content,
comments/reviews, …
b) Bob can search/query for a selection of POIs according to several criteria: rating, location,
distance, date for events, like, category, tags, currently opened, …
c) Bob can receive recommendations for POIs from his friends or based on his own preferences
and profile.
d) Bob can visualize a specific POI or a selection of POIs on a map. The map utilizes an
appropriate map projection and could be centered on the current position of Bob.
e) Bob can visualize a specific POI or a selection of POIs using augmented reality to ease the
orientation. Thereby, the POIs are drawn as overlay onto the camera image to indicate the
direction and distance of the POIs relative to Bob’s position and view.
Bob arrives to a PoI place or events, the smartphone vibrates and sends a notification (This happen
when he is near an event or place he doesn’t know but could be linked to what he likes). He clicks to
this notification and opens the PoI from his route, visualize data like video, image, text, audio or 3D.
If there is the option, he can also visualize it using augmented reality.
When the user is near to a PoI, if the user has not focus on the app will receive an internal
notification and a vibration; in case of having focus, it will appear some message to go to PoI data.
Once the user is in the PoI visualization, he will get access to the available data. These data will got
via Internet.
If there is a video available, it will be sent via streaming taking into account the characteristics of the
device and the network, to make an adaptive transcoding.
If it is possible, it will appear an option to represent these data in an augmented reality context.
There are additional capabilities if Bob is close to a specific POI:
f) If Bob gets close to a POI that relates to his preferences and profile he receives a notification
about the recommended POI. A notification message is shown and the smartphone vibrates if
not actively used by Bob to get his attention. He can click on this notification and get additional
information about this recommended POI as described in (a).
g) Further Bob can visualize the associated content of the POI and interact with it. Once the user is
in the POI visualization, he will get access to the available data. These data will got via internet
connection.
He can view images. Furthermore, an image can hold its camera information (position,
view, projection) and is then perspective-correct blended with today’s view of the POI via
augmented reality.
He can view a video, which will be streamed to the device taking into account the
characteristics of the device and the network, to make an adaptive transcoding.
He can view 3D-content attached to or replacing the real-world structure of the POI via
augmented reality.
The social network will also give some recommendation of routes.
© FI-CONTENT 2 consortium 2014
D3.1 V2.0 - March 2014
Page 50 of 53
4 . Find interesting people
(Local Information SE, Virtual/Mixed Reality SE, Social Network SE, Location GE)
Bob can receive information about people who have the same interest as him (where are the person
who also like jazz music now in Barcelona?) or people who has declared to be expert or guide of this
specific point of interest.
He could contact them if he wants according to the choice of these persons.
5. Generating data
(Content Enrichment SE, Object Storage GE, Location GE, Community Sharing SE, Social
Network SE)
Bob gets inside a building and makes some photos and a video. With his smartphone or tablet he
links this media with some tags and comments (post).
While writing the tags, it would appear dynamic suggestions. He marks parts of the image and video
to get detected in other ones, and share it in public or/and friend’s domain.
The app has to link images, videos or/and audios from disc or record it.
The app needs to get the GPS data or give the option to set the position on the map (in case of high
uncertainty).
Once added the media, the user can tag it. Tagging parts of the media and comments.
The user can share it public, private or with friends.
All the data will be at the cloud and available as open data in case of the user set it as public.
If the user has a bad internet connection (he can add a video to a POI, give feedback about a POI,
get Recommendations for POIs or create and display a video with content enrichment (tagging) later
in his hotelroom on PC or maybe via the TV app.
6. Comment and rate POI and and generate routes
(Community Sharing SE, Social Network SE, Local Information SE)
When Bob makes some tours, he decides to recommend and create a route to be shared with
friends.
The user has the option to create routes with own, friends or/and public PoIs and share it with the
most restrictive option.
The user can rate and comment POI and routes.
Bob has the possibility to interact with a single POI e.g. if he is close to one. He can add some
comment or review to this POI and add his rating which can be aggregated to an overall rating.
7. Teams and groups
(Local Information SE, Virtual/Mixed Reality SE, Social Network SE, Location GE, Object
Storage GE, Video Streaming GE, Identity Management GE, Community Sharing SE, Virtual
Reality Mixer)
Bob’s son is a guest student in a school in Cologne. The Cologne Computer Science Class decides
to create a media experiments around the cultural event Carnival in Cologne with three phases
called before, during and after Carnival and Bob is in a team with 5 other students.
1) Before Carnival
The student team prepares the Carnival fieldtrip by using the social network and adding content in
the platform. Fritz logs in the social network with a nick name and uploads content with metadata
© FI-CONTENT 2 consortium 2014
D3.1 V2.0 - March 2014
Page 51 of 53
(Time, place) and tags it to a map. The other in the team can edit, delete the content as well as
create comments. Bob content via Hashtags.
2) During Carnival
Bob and his team use smart phones to communicate and create content during the fieldtrip. Bob
logs on the platform and run around the streets. His movements through Cologne are recorded and
there are geo fencing.
Bob uploads content and searches content via Hashtags. Bob can even communicate with the
others in the team, when there is no internet connection. They can share content directly between
the smart phones.
Bob is suddenly bored and he can check the recommendations of the other teams, where there are
cool events in other parts of Cologne and he gets a recommendation for a new tour through the town
with traffic navigation. Bob also watches the live audiovisual content streams from the other
students. Bob can also chat with the other students as an avatar on a map.
3) After Carnival
The Team in schools edits the recorded audiovisual content and creates interactive tour reports
about Carnival. The content will be linked after people, Themes, time and places, so the students
can navigate through the content after their personal interest and mood and share their memories of
the event.
8. Different devices
(Object Storage GE, Video Streaming GE, Identity Management GE, Community Sharing SE)
Bob’s smartphone has been stolen in ramblas. After that, he continues using the tablet.
All data generated with the devices will be stored at cloud as soon as possible.
From the user account, it can be closed other sessions and the cached data can be deleted in the
other devices (smartphone, PC web site or TV app).
9. Travel reporting
(Content Enrichment SE, Social Network SE, Object Storage GE, Identity Management GE)
Bob returns to his city and wants to review some data of his stay. On his PC, tablet, SmartPhone or
TV he can visualize this data inside a map (like google maps) or other ways to visualize the data
such as a list in different devices.
It should also be time order: to visualize the tour itself. You see different colourfull routes walked
during the trip and annotated with recorded images and audio/ video data.
Once logged in different platforms, it will be accessible all data shared with the user, made by the
user, friends, public and team members.
The data will be accessible by navigating through the map, represented like a list.
10. Contribute POI and route
(Local Information SE, Social Network SE, Community sharing, Identity Management GE,
Object Storage GE)
Bob see something interesting on his tour between la Pedrera and Plaça Catalunya. He notice the
respective POI, which describes this place. Otherwise he has the ability to create a new POI and
provide some basic information and the location feature to find the POI. Furthermore, he can append
more content to this POI like pictures taken from happenings there or short video streams.
Bob shares afterwards his content of this POI with his friends or make them publicity available.
© FI-CONTENT 2 consortium 2014
D3.1 V2.0 - March 2014
Page 52 of 53
Each author will receive a request to update his data, in this case, it will be received by the author of
the public PoI and the author of the route.
The user that makes the modification proposal, until the modification is not accepted, he can get the
data with his own modifications.
The routes can be rated.
11. Marked PoI
(Local Information SE, Identity Management GE, Location GE)
Bob has been walking for a long time and he is searching for POIs that he did not visit before. His
profile contains the list of POIs visited by him.
Bob can now search/query for POIs that he did not visit yet. The result list then only contains these
POIs.
Furthermore, Bob can change the visualization to highlight not-visited POIs on the map and in the
AR view or hide the already visited POIs from the visualization or alternatively fading them close to
the background.
12. Advanced profile
(Social Network SE, Identity Management GE)
Bob is an active user of SCG and wants to improve his experience, his profile can be improved with
things that he likes, like music, food or other hobbies
The profile can be improved to get a more complete data about the user, this data can result in more
accurate results.
13. Instant recomendation
(Recommendation Services SE, Local Information SE, Social Network SE Community Sharing
SE)
Is late and Bob wants to do something different this night, he starts the application and asks for an
activity, the result is a nearby bar with live music with the kind of music that Bob likes.
Having a better profile can improve the search results, another point is getting recommendations
based on the agenda based on the local information.
14. Encourage PoI content
(Local Information SE, Social Network SE Community Sharing SE)
Bob gets an advice announcing a photo contest in the city, he only needs to tag the public photos
that he made with the contest tag. Three days later, Bob receive the second contest prize that is an
important discount to theater.
The SCG platform gives the option to make some events, in this case, the event is a contest and the
system to share the information is like twitter, also, the platform permits to send private message, in
this case with a discount code.
The result will be the capacity of administration or other interested to create public data for the SCG
or use the SCG like marketing using different tags.
© FI-CONTENT 2 consortium 2014
D3.1 V2.0 - March 2014
Page 53 of 53
15. Visited location-based chat
(Local Information SE, Social Network SE Community Sharing SE, Location GE)
Bob is near a monument without any data and uses the application to ask what is the monument in
the photo, later, he receive an answer from other user that was near to the position.
The SCG platform give the option to put temporal data in the public domain, in this case a text
message and a photo, also audio or video clips can be shared, the objective of this option is to ask
or comment to other users, near in location and in a temporal window.
end of the document