d3.1 scenario functional and technical specifications … · d3.1 scenario, functional and...

53
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 applicat ions (1 st 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.

Upload: others

Post on 08-Oct-2020

8 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: D3.1 SCENARIO FUNCTIONAL AND TECHNICAL SPECIFICATIONS … · D3.1 SCENARIO, FUNCTIONAL AND TECHNICAL SPECIFICATIONS -RELEASE 1 March 2014 ABSTRACT This document is an updated version

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.

Page 2: D3.1 SCENARIO FUNCTIONAL AND TECHNICAL SPECIFICATIONS … · D3.1 SCENARIO, FUNCTIONAL AND TECHNICAL SPECIFICATIONS -RELEASE 1 March 2014 ABSTRACT This document is an updated version

© 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

Page 3: D3.1 SCENARIO FUNCTIONAL AND TECHNICAL SPECIFICATIONS … · D3.1 SCENARIO, FUNCTIONAL AND TECHNICAL SPECIFICATIONS -RELEASE 1 March 2014 ABSTRACT This document is an updated version

© 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.

Page 4: D3.1 SCENARIO FUNCTIONAL AND TECHNICAL SPECIFICATIONS … · D3.1 SCENARIO, FUNCTIONAL AND TECHNICAL SPECIFICATIONS -RELEASE 1 March 2014 ABSTRACT This document is an updated version

© 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

Page 5: D3.1 SCENARIO FUNCTIONAL AND TECHNICAL SPECIFICATIONS … · D3.1 SCENARIO, FUNCTIONAL AND TECHNICAL SPECIFICATIONS -RELEASE 1 March 2014 ABSTRACT This document is an updated version

© 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

Page 6: D3.1 SCENARIO FUNCTIONAL AND TECHNICAL SPECIFICATIONS … · D3.1 SCENARIO, FUNCTIONAL AND TECHNICAL SPECIFICATIONS -RELEASE 1 March 2014 ABSTRACT This document is an updated version

© 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

Page 7: D3.1 SCENARIO FUNCTIONAL AND TECHNICAL SPECIFICATIONS … · D3.1 SCENARIO, FUNCTIONAL AND TECHNICAL SPECIFICATIONS -RELEASE 1 March 2014 ABSTRACT This document is an updated version

© 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

Page 8: D3.1 SCENARIO FUNCTIONAL AND TECHNICAL SPECIFICATIONS … · D3.1 SCENARIO, FUNCTIONAL AND TECHNICAL SPECIFICATIONS -RELEASE 1 March 2014 ABSTRACT This document is an updated version

© 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

Page 9: D3.1 SCENARIO FUNCTIONAL AND TECHNICAL SPECIFICATIONS … · D3.1 SCENARIO, FUNCTIONAL AND TECHNICAL SPECIFICATIONS -RELEASE 1 March 2014 ABSTRACT This document is an updated version

© 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.

Page 10: D3.1 SCENARIO FUNCTIONAL AND TECHNICAL SPECIFICATIONS … · D3.1 SCENARIO, FUNCTIONAL AND TECHNICAL SPECIFICATIONS -RELEASE 1 March 2014 ABSTRACT This document is an updated version

© 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

Page 11: D3.1 SCENARIO FUNCTIONAL AND TECHNICAL SPECIFICATIONS … · D3.1 SCENARIO, FUNCTIONAL AND TECHNICAL SPECIFICATIONS -RELEASE 1 March 2014 ABSTRACT This document is an updated version

© 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.

Page 12: D3.1 SCENARIO FUNCTIONAL AND TECHNICAL SPECIFICATIONS … · D3.1 SCENARIO, FUNCTIONAL AND TECHNICAL SPECIFICATIONS -RELEASE 1 March 2014 ABSTRACT This document is an updated version

© 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.

Page 13: D3.1 SCENARIO FUNCTIONAL AND TECHNICAL SPECIFICATIONS … · D3.1 SCENARIO, FUNCTIONAL AND TECHNICAL SPECIFICATIONS -RELEASE 1 March 2014 ABSTRACT This document is an updated version

© 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.

Page 14: D3.1 SCENARIO FUNCTIONAL AND TECHNICAL SPECIFICATIONS … · D3.1 SCENARIO, FUNCTIONAL AND TECHNICAL SPECIFICATIONS -RELEASE 1 March 2014 ABSTRACT This document is an updated version

© 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.

Page 15: D3.1 SCENARIO FUNCTIONAL AND TECHNICAL SPECIFICATIONS … · D3.1 SCENARIO, FUNCTIONAL AND TECHNICAL SPECIFICATIONS -RELEASE 1 March 2014 ABSTRACT This document is an updated version

© 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

Page 16: D3.1 SCENARIO FUNCTIONAL AND TECHNICAL SPECIFICATIONS … · D3.1 SCENARIO, FUNCTIONAL AND TECHNICAL SPECIFICATIONS -RELEASE 1 March 2014 ABSTRACT This document is an updated version

© 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.

Page 17: D3.1 SCENARIO FUNCTIONAL AND TECHNICAL SPECIFICATIONS … · D3.1 SCENARIO, FUNCTIONAL AND TECHNICAL SPECIFICATIONS -RELEASE 1 March 2014 ABSTRACT This document is an updated version

© 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

Page 18: D3.1 SCENARIO FUNCTIONAL AND TECHNICAL SPECIFICATIONS … · D3.1 SCENARIO, FUNCTIONAL AND TECHNICAL SPECIFICATIONS -RELEASE 1 March 2014 ABSTRACT This document is an updated version

© 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

Page 19: D3.1 SCENARIO FUNCTIONAL AND TECHNICAL SPECIFICATIONS … · D3.1 SCENARIO, FUNCTIONAL AND TECHNICAL SPECIFICATIONS -RELEASE 1 March 2014 ABSTRACT This document is an updated version

© 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.

Page 20: D3.1 SCENARIO FUNCTIONAL AND TECHNICAL SPECIFICATIONS … · D3.1 SCENARIO, FUNCTIONAL AND TECHNICAL SPECIFICATIONS -RELEASE 1 March 2014 ABSTRACT This document is an updated version

© 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

Page 21: D3.1 SCENARIO FUNCTIONAL AND TECHNICAL SPECIFICATIONS … · D3.1 SCENARIO, FUNCTIONAL AND TECHNICAL SPECIFICATIONS -RELEASE 1 March 2014 ABSTRACT This document is an updated version

© 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

Page 22: D3.1 SCENARIO FUNCTIONAL AND TECHNICAL SPECIFICATIONS … · D3.1 SCENARIO, FUNCTIONAL AND TECHNICAL SPECIFICATIONS -RELEASE 1 March 2014 ABSTRACT This document is an updated version

© 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.

Page 23: D3.1 SCENARIO FUNCTIONAL AND TECHNICAL SPECIFICATIONS … · D3.1 SCENARIO, FUNCTIONAL AND TECHNICAL SPECIFICATIONS -RELEASE 1 March 2014 ABSTRACT This document is an updated version

© 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)

Page 24: D3.1 SCENARIO FUNCTIONAL AND TECHNICAL SPECIFICATIONS … · D3.1 SCENARIO, FUNCTIONAL AND TECHNICAL SPECIFICATIONS -RELEASE 1 March 2014 ABSTRACT This document is an updated version

© 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

Page 25: D3.1 SCENARIO FUNCTIONAL AND TECHNICAL SPECIFICATIONS … · D3.1 SCENARIO, FUNCTIONAL AND TECHNICAL SPECIFICATIONS -RELEASE 1 March 2014 ABSTRACT This document is an updated version

© 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:

Page 26: D3.1 SCENARIO FUNCTIONAL AND TECHNICAL SPECIFICATIONS … · D3.1 SCENARIO, FUNCTIONAL AND TECHNICAL SPECIFICATIONS -RELEASE 1 March 2014 ABSTRACT This document is an updated version

© FI-CONTENT 2 consortium 2014

D3.1 V2.0 - March 2014

Page 26 of 53

I can have some details about a recommended POI:

Page 27: D3.1 SCENARIO FUNCTIONAL AND TECHNICAL SPECIFICATIONS … · D3.1 SCENARIO, FUNCTIONAL AND TECHNICAL SPECIFICATIONS -RELEASE 1 March 2014 ABSTRACT This document is an updated version

© 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.

Page 28: D3.1 SCENARIO FUNCTIONAL AND TECHNICAL SPECIFICATIONS … · D3.1 SCENARIO, FUNCTIONAL AND TECHNICAL SPECIFICATIONS -RELEASE 1 March 2014 ABSTRACT This document is an updated version

© 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

Page 29: D3.1 SCENARIO FUNCTIONAL AND TECHNICAL SPECIFICATIONS … · D3.1 SCENARIO, FUNCTIONAL AND TECHNICAL SPECIFICATIONS -RELEASE 1 March 2014 ABSTRACT This document is an updated version

© 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

Page 30: D3.1 SCENARIO FUNCTIONAL AND TECHNICAL SPECIFICATIONS … · D3.1 SCENARIO, FUNCTIONAL AND TECHNICAL SPECIFICATIONS -RELEASE 1 March 2014 ABSTRACT This document is an updated version

© 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

Page 31: D3.1 SCENARIO FUNCTIONAL AND TECHNICAL SPECIFICATIONS … · D3.1 SCENARIO, FUNCTIONAL AND TECHNICAL SPECIFICATIONS -RELEASE 1 March 2014 ABSTRACT This document is an updated version

© 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.

Page 32: D3.1 SCENARIO FUNCTIONAL AND TECHNICAL SPECIFICATIONS … · D3.1 SCENARIO, FUNCTIONAL AND TECHNICAL SPECIFICATIONS -RELEASE 1 March 2014 ABSTRACT This document is an updated version

© 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.

Page 33: D3.1 SCENARIO FUNCTIONAL AND TECHNICAL SPECIFICATIONS … · D3.1 SCENARIO, FUNCTIONAL AND TECHNICAL SPECIFICATIONS -RELEASE 1 March 2014 ABSTRACT This document is an updated version

© FI-CONTENT 2 consortium 2014

D3.1 V2.0 - March 2014

Page 33 of 53

Page 34: D3.1 SCENARIO FUNCTIONAL AND TECHNICAL SPECIFICATIONS … · D3.1 SCENARIO, FUNCTIONAL AND TECHNICAL SPECIFICATIONS -RELEASE 1 March 2014 ABSTRACT This document is an updated version

© 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.

Page 35: D3.1 SCENARIO FUNCTIONAL AND TECHNICAL SPECIFICATIONS … · D3.1 SCENARIO, FUNCTIONAL AND TECHNICAL SPECIFICATIONS -RELEASE 1 March 2014 ABSTRACT This document is an updated version

© 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

Page 36: D3.1 SCENARIO FUNCTIONAL AND TECHNICAL SPECIFICATIONS … · D3.1 SCENARIO, FUNCTIONAL AND TECHNICAL SPECIFICATIONS -RELEASE 1 March 2014 ABSTRACT This document is an updated version

© 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/

Page 37: D3.1 SCENARIO FUNCTIONAL AND TECHNICAL SPECIFICATIONS … · D3.1 SCENARIO, FUNCTIONAL AND TECHNICAL SPECIFICATIONS -RELEASE 1 March 2014 ABSTRACT This document is an updated version

© 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)

Page 38: D3.1 SCENARIO FUNCTIONAL AND TECHNICAL SPECIFICATIONS … · D3.1 SCENARIO, FUNCTIONAL AND TECHNICAL SPECIFICATIONS -RELEASE 1 March 2014 ABSTRACT This document is an updated version

© 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

Page 39: D3.1 SCENARIO FUNCTIONAL AND TECHNICAL SPECIFICATIONS … · D3.1 SCENARIO, FUNCTIONAL AND TECHNICAL SPECIFICATIONS -RELEASE 1 March 2014 ABSTRACT This document is an updated version

© 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

Page 40: D3.1 SCENARIO FUNCTIONAL AND TECHNICAL SPECIFICATIONS … · D3.1 SCENARIO, FUNCTIONAL AND TECHNICAL SPECIFICATIONS -RELEASE 1 March 2014 ABSTRACT This document is an updated version

© 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.

Page 41: D3.1 SCENARIO FUNCTIONAL AND TECHNICAL SPECIFICATIONS … · D3.1 SCENARIO, FUNCTIONAL AND TECHNICAL SPECIFICATIONS -RELEASE 1 March 2014 ABSTRACT This document is an updated version

© 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

Page 42: D3.1 SCENARIO FUNCTIONAL AND TECHNICAL SPECIFICATIONS … · D3.1 SCENARIO, FUNCTIONAL AND TECHNICAL SPECIFICATIONS -RELEASE 1 March 2014 ABSTRACT This document is an updated version

© 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].

Page 43: D3.1 SCENARIO FUNCTIONAL AND TECHNICAL SPECIFICATIONS … · D3.1 SCENARIO, FUNCTIONAL AND TECHNICAL SPECIFICATIONS -RELEASE 1 March 2014 ABSTRACT This document is an updated version

© 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

Page 44: D3.1 SCENARIO FUNCTIONAL AND TECHNICAL SPECIFICATIONS … · D3.1 SCENARIO, FUNCTIONAL AND TECHNICAL SPECIFICATIONS -RELEASE 1 March 2014 ABSTRACT This document is an updated version

© 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

Page 45: D3.1 SCENARIO FUNCTIONAL AND TECHNICAL SPECIFICATIONS … · D3.1 SCENARIO, FUNCTIONAL AND TECHNICAL SPECIFICATIONS -RELEASE 1 March 2014 ABSTRACT This document is an updated version

© 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

Page 46: D3.1 SCENARIO FUNCTIONAL AND TECHNICAL SPECIFICATIONS … · D3.1 SCENARIO, FUNCTIONAL AND TECHNICAL SPECIFICATIONS -RELEASE 1 March 2014 ABSTRACT This document is an updated version

© 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

Page 47: D3.1 SCENARIO FUNCTIONAL AND TECHNICAL SPECIFICATIONS … · D3.1 SCENARIO, FUNCTIONAL AND TECHNICAL SPECIFICATIONS -RELEASE 1 March 2014 ABSTRACT This document is an updated version

© 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

Page 48: D3.1 SCENARIO FUNCTIONAL AND TECHNICAL SPECIFICATIONS … · D3.1 SCENARIO, FUNCTIONAL AND TECHNICAL SPECIFICATIONS -RELEASE 1 March 2014 ABSTRACT This document is an updated version

© 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,

Page 49: D3.1 SCENARIO FUNCTIONAL AND TECHNICAL SPECIFICATIONS … · D3.1 SCENARIO, FUNCTIONAL AND TECHNICAL SPECIFICATIONS -RELEASE 1 March 2014 ABSTRACT This document is an updated version

© 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.

Page 50: D3.1 SCENARIO FUNCTIONAL AND TECHNICAL SPECIFICATIONS … · D3.1 SCENARIO, FUNCTIONAL AND TECHNICAL SPECIFICATIONS -RELEASE 1 March 2014 ABSTRACT This document is an updated version

© 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

Page 51: D3.1 SCENARIO FUNCTIONAL AND TECHNICAL SPECIFICATIONS … · D3.1 SCENARIO, FUNCTIONAL AND TECHNICAL SPECIFICATIONS -RELEASE 1 March 2014 ABSTRACT This document is an updated version

© 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.

Page 52: D3.1 SCENARIO FUNCTIONAL AND TECHNICAL SPECIFICATIONS … · D3.1 SCENARIO, FUNCTIONAL AND TECHNICAL SPECIFICATIONS -RELEASE 1 March 2014 ABSTRACT This document is an updated version

© 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.

Page 53: D3.1 SCENARIO FUNCTIONAL AND TECHNICAL SPECIFICATIONS … · D3.1 SCENARIO, FUNCTIONAL AND TECHNICAL SPECIFICATIONS -RELEASE 1 March 2014 ABSTRACT This document is an updated version

© 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