• Tidak ada hasil yang ditemukan

Contract Delivery Date Actual Delivery Date Deliverable Type

N/A
N/A
Protected

Academic year: 2018

Membagikan "Contract Delivery Date Actual Delivery Date Deliverable Type"

Copied!
21
0
0

Teks penuh

(1)

Document Title Document Version

D5.4 Intent-aware User Interface Software - Social Interfaces 0.8

Project Number Project Acronym Project Title

FP7-2011-7-287661 GAMBAS Generic Adaptive Middleware for Behavior-driven Autonomous Services

Contract Delivery Date Actual Delivery Date Deliverable Type Deliverable Access

M28 P (Prototype) CO (Confidential)

Document Author or Reviewer Organization Work Package

Stefan Foell OU WP5

Gerd Kortuem OU WP5

Marcus Handte UDE WP5

Abstract

(2)

Revision Organization Description

0.1 OU Created initial template

0.2 OU Added document structure

0.3 OU Added description of prototype iterations

0.4 OU Added description and screenshots of user interfaces 0.5 OU Added introduction and conclusion

0.6 OU Added requirements coverage

0.7 UDE Internal review.

(3)

Table of Contents

1 Introduction ... 5

1.1 Purpose ... 5

1.2 Scope ... 5

1.3 Structure ... 6

2 Prototype Coverage ... 7

2.1 Prototype 1 ... 7

2.2 Prototype 2 ... 7

3 Intent-Aware User Interface Layers ... 9

3.1 Transport Layer ... 9

3.2 Quality-of-Transport Layer ... 11

3.3 Personal Behaviour Layer ... 12

3.4 Social Behaviour Layer ... 14

4 Requirement Coverage ... 17

5 Conclusion ... 20

(4)

List of Figures

Figure 1 Intent-aware User Interface Model... 7

Figure 2 User interface menu ... 9

Figure 3 Route plannig interface ... 10

Figure 4 Indication of crowd levels on routes ... 12

Figure 5 Navgation Service ... 13

Figure 6 Personal user interfaces ... 13

Figure 7 User interface for sharing of trip goals ... 15

Figure 8 User interfaces for social travel Information ... 16

(5)

1

Introduction

This document reports on the development of the second prototype of intent-aware user interface software developed by the GAMBAS project. The document accompanies the actual deliverable, i.e. the code of the prototype, which can be accessed via the shared code repository hosted by UDE. In the following, we describe the key features of the software and present the four user interface layers which make up the GAMBAS user interface. The key innovation added in the final design iteration is the social user interface layer which supports social information exchange of public transport users.

1.1

Purpose

The aim of WP5 is the design, development and evaluation of a novel intent-aware user interface concept, with a particular focus on mobile guidance in public transport scenarios which denotes one key application domain in GAMBAS. This deliverable D5.4 presents the GAMBAS user interface framework, i.e. the concrete visual user interfaces and user interface software that has been developed as part of the GAMBAS project.

Early work in WP5 developed an intent-aware user interfaces model which maps out the user experience of an innovative mobile guide system (W5.1). The model is inherently data-driven, making use of context data, social information and public transport data use to create information-rich and effective user interfaces for mobile users. Altogether, the model consists of four layers with different features and services. (1) On the transport layer, public transport data is crawled and incorporated into mobile interface software. (2) On the quality-of-transport layer, qualitative information about conditions of transport usage and crowd levels on public transport routes is made accessible to users. (3) On the personal behaviour level, transport behaviour recommendations are delivered to travellers to improve navigation and decision-making in public transport networks. (4) On the social behavioural level, transport usage becomes a social experience as fellow travellers and information about their transport usage is visible. This deliverable D5.4 describes the complete GAMBAS user interface framework, i.e. the concrete realisation of this model. The framework encompasses user interfaces and software that for all four layers of the model. While previous reports have focused on personal interfaces, this Deliverable D5.4 includes a description of the social layer which extends the previous software release with features for shared, social transport experiences..

1.2

Scope

Deliverable 5.4 is the fourth deliverable in WP3: Deliverable 5.1 laid the groundwork by defining a design approach for intent-aware user interfaces; Deliverable 5.2 described the first version of the user interface framework; and D5.3 delivered first insights into usability aspects. In line with the overall project organisation, this deliverable D5.4 completes the design and development of the user interface software. While the first iteration of the software delivered personal user interfaces, this deliverable presents the entire stack of the user interface system including a new set of social interfaces.

(6)

1.3

Structure

The remainder of this document is structured as follows. In Section 2, we describe the evolution of the user interface prototypes over two iterations in relation to the proposed user interface model. In Section 3, we present concrete user interfaces which have been developed to support the complex information need of mobile users on the four layers of the model. Section 4 revisits the requirements for intent-aware user interface which have been defined earlier in the project as part of the requirement specification, and gives justification about their full coverage in the current implementation.

(7)

2

Prototype Coverage

The development of user interface framework follows the conceptual intent-aware user interfaces model which has been presented in D5. 1 [GIUIM] (Figure 1). The model is based on a stack of four layers, where each layer encapsulates interactive elements for a specific aspect of a mobile intent-aware transport application. Each layer is realized by a set of concrete user interfaces which provide effective support and guidance to users in public transport scenarios.

Figure 1 Intent-aware User Interface Model

The realisation of the complete user interface model was undertaken in two major iterations (GAMBAS prototype 1 and prototype 2), with each iteration covering a subset of the model features. In the following, we give an overview how layers were developed across both iterations.

2.1

Prototype 1

The first prototype realised the user interface foundation required by the GAMBAS mobile travel guide. In summary, the software encompasses the following components:

Personalized navigation: The user interface software provides support for continuous navigation which allows transport users to receive recommendation of the best next travel steps over the course of a journey.

Crowd information indication: The user interface software visualizes and indicates expected levels of crowdedness on transport routes to allow users make more effective travel decisions.

Voice input integration: The user interface software facilitates simplified user interaction by enabling voice commands as input to trip planning and navigation.

2.2

Prototype 2

(8)

Semantic annotation of user trips: The user interface software enables users to annotate routes they are following, giving trips a meaning and social context that can be shared among friends.

Exchange of social travel information: The user interface software is extended to collect and represent travel information from a user’s social network. This way, users gain insight into their friends’ travel activities and the routes they are following.

Social route planning: The user interface software integrates social network information into route planning functionality by giving user access to their friend’s real-time locations that can be used as destinations for planned routes.

(9)

3

Intent-Aware User Interface Framework

In this section, we describe the concrete user interface of the GAMBAS mobile prototype application. The following discussion follows the layer model outlined in the previous section, starting with the lowest layer which provides the central user interface for route planning. Then, on the next upper layer, we describe the integration of quality-of-transport information into user interface for the representation of crowd information on travel routes. Next, we describe a set of personalized user interfaces which assist users with continuous navigation features. Finally, we present the social user interface layer which enhances the interfaces with social features that allows users to share travel plans with their social network .

The interfaces and services on all layers can be accessed using the application menu shown in Figure 2. The top three entries in the application menu correspond to the transport, personal and social layers discussed above.

Figure 2 User interface menu

3.1

Transport Layer

3.1.1 Use cases

The following table indicates which use cases are covered by the Transport Layer. For details see Section 4 (Requirement Coverage).

User Interface Layer Supported Use Cases

Transport Layer UI_008

UI_017

3.1.2 Description

(10)

for a trip from a given origin to desired destination. For this purpose, an interface has been developed which encompasses the following elements:

 An origin field  An destination field  A time field

 A toggle button for selecting departure or arrival time  A list of returned route alternatives

By default, the origin is set to the user’s current location which is collected from GPS information on the user’s mobile device. This enables ad-hoc planning of routes from the current position of a user while being on the move.

The user can choose to use either text or voice input when interacting with the route planning interface. Voice input is incorporated to ease the process of user input. By pressing the microphone button, the user is asked to speak and indicate the name of the location which should be used either as origin or destination address. The voice is translated into a textual string and used to automatically update the fields with the required information.

Once all input has been specified and direction information is requested, the interface lists different route options available for the desired journey. Each alternative is associated with contextual data about the journey, allowing users to make an informed travel decision about which route to choose. More precisely, each option shows the different transport modalities (walking, bus, train) in the same order as they need to be taken for the journey. In addition, each option shows the distance to travel, the duration of the journey, as well as the departure and arrival time of the journey (for non-walking segments only).

(11)

3.2

Quality-of-Transport Layer

3.2.1 Use cases

The following table indicates which use cases are covered by the Quality of Transport Layer. For details see Section 4 (Requirement Coverage).

User Interface Layer Supported Use Cases

Quality of Transport Layer UI_016

UI_017

3.2.2 Description

In addition to the directions returned by the route planning interface, additional quality-of-transport information is available which gives further insights into the conditions of a transport journey. This information becomes visible once the user clicks on a route option to look at its further details.

Route information is shown on a map to visualize the details of a journey. This representation helps a user to gain a better spatial understanding of a journey. For this purpose, the map shows the travel segments involved, from the origin to the destination location of the journey. A travel segment is represented as a spatial polyline which encodes the route trajectory. The route trajectory of a public transport segment contains all stops before the user needs to depart from the vehicle.

Different colour codes are used to distinguish between walking and public transport segments. For public transport routes, the width of the polyline encodes the expected crowdedness of the transport journey within the transport network. Crowdedness is a quality-of-transport measure that refers to the number of people travelling on a route segment in between two stops, in relation to the passenger capacity of a bus.

(12)

Figure 4 Indication of crowd levels on routes

3.3

Personal Behaviour Layer

3.3.1 Use cases

The following table indicates which use cases are covered by the Personal Behavior Layer. For details see Section 4 (Requirement Coverage).

User Interface Layer Supported Use Cases

Personal Behavior Layer UI_005

UI_011 UI_012 UI_014 UI_018 UI_019 UI_021 UI_022

3.3.2 Description

While route planning is performed before the start of a journey, navigation is realized as a personalized service which makes use of a user’s context information to adapt user interface and information provided to a user during a journey. The navigation starts as soon as a user a selects a specific route to follow.

The navigation service is accessible as a user interface shown in Figure 6. The interface is composed of the following key components:

(13)

Figure 5 Navigation Service

The geographic map provides a static visualization of the travel plan associated with the journey. This visualization is used as a base map which is overlaid with user’s current context. First, the user is represented as an icon which is dynamically updated to his current location. This allows users to navigate the travel plan in relation to their current context, e.g. to find a bus stop. Second, the map encodes the travel activities of a user using different icons which represent either bus ride or walking activity for further feedback.

(14)

The area above the map is used a notification area to supply users with situational navigation instructions. The instructions are tied to the user’s current context and contain information about the next steps to take. In case a user is walking, the interface shows the remaining distance to the end of the walking segment. If a user approaches a bus stop, the next bus arrivals are shown. Once the user is on the bus, information about the number of stops is given before an alighting is required. Similarly, corrective actions are notified that require special attention by users. For instance, the user is notified in case an alighting has been missed or a wrong bus has been accidentally been boarded. It is important to note that the interface has been designed to require no manual user input to elicit a notification. Each notification is automatically triggered by changes in the user behaviour which are detected from available context information.

Further, the personal user interfaces give users access to their trip ride histories. As shown in Figure 6, a trip history view is provided which lists a user’s past rides that have been recognized. Also, a voice tag management interface has been implemented which allows for creating new or deleting existing voice tags. This allows a user to introduce voice tags for stops which are important for his frequent travel needs, e.g. home or work.

3.4

Social Behaviour Layer

3.4.1 Use cases

The following table indicates which use cases are covered by the Social Behavior Layer. For details see Section 4 (Requirement Coverage).

User Interface Layer Supported Use Cases

Social Behavior Layer UI_013

UI_020 UI_021

3.4.2 Description

On top of the personal behaviour layer, an additional service is provided which augments personal experiences with views and information on social transport usage. The idea is that public transport can be a powerful platform for sharing information about journeys and rides among companion travellers. As public transport systems represent a shared mode of transport, rich travel activity information becomes available which can be visualized to let users perceive public transport usage as an inherent social experience.

On top of the personal user interfaces, we have integrated a social networking service that fosters information exchange among travellers in two directions. On the one hand, transport users can annotate their trips with goals to inform their friends about their current routes and travel intents. On the other hand, we give users access to social views of the transport system which encompasses real-time status information about the latest travel activities of friends in their social circle.

(15)

Figure 7 User interface for sharing of trip goals

As shown in Figure 8, users can access social information about the latest real-time travel activities of their friends. We provide two different interfaces, a coarse-grained view which provides summary information about all friends and a finer-grained view which gives details about a single friend’s current activity.

The coarse-grained view shows the all friends in a user’s social circle. Friendship relations are derived from a user’s Facebook account [Facebook] which can be imported into GAMBAS. This is accomplished by the privacy preservation framework which controls the formation of social circles and privacy settings of shared context information [GPPS1, GPPS2]. For each friend, a list entry is shown that gives an overview about the user’s current status. The status information specifies whether a user is currently online or offline. If a user is found to be online, information about the distance between the user’s current location and that of his friend is given. This is to highlight friends in close distance who could be potentially interested in joint activities with the user.

For each online user, more detailed information can be accessed when clicking on the entry in the list associated with a user. Then, a separate interface is shown which presents the full user profile, including the friend’s description of his travel activity. This gives users a better idea of the rationale behind the journey of their friends. Moreover, the current travel activity of a friend is represented on a geographic map which is constantly updated. The map representation is able to reveal two different kinds of information. On the one hand, the friend‘s geographic location is shown and updated as he is moving. On the other hand, the map shows a representation of the travel plan currently followed by his friend. As a consequence, the social view of a friend’s travel activity conveys both real-time information about the current travel activity as well as future information about the prospective route on which the friend is travelling.

(16)

meet friends at their current location, minimizing the effort for negotiating spatial coordinates to find meeting points in urban spaces.

Figure 8 User interfaces for social travel Information

(17)

4

Requirement Coverage

This section revisits the relevant requirements for the development of intent-aware user interfaces as defined in D1.1 Requirements Specification. In the following, we discuss the coverage of the requirements in the user interface software prototype and demonstrate that all functional requirements have been fully incorporated into the user interface software. The non-functional requirements are outside the scope of this document as they relate to the study of user experience which is subject to the user evaluation deliverables D5.3 and D5.4. In the following, we iterative over the requirements and give the rationale as to which each requirement has been fully covered in the user interface software implementation.

This table contains the id, a short description, and the type of the requirement and its priority as they have been described in D1.1 Requirements Specification.

ID Description Type Priority

UI_005 The user interface performs proactive recommendations on trips.

Functional and data requirements

High

UI_008 The personal user interfaces support the visualization of possible routes.

Functional and data requirements

High

UI_011 The user interface component must recommend personalised transport routes.

Functional and data requirements

High

UI_012 The user interface component must provide personalised information related to user intent.

Functional and data requirements

High

UI_013 UI_013. The user interface component should enable users to become aware of friend's travel behavior.

Functional and data requirements

High

UI_014 The user interface should anticipate user information needs and be designed to minimize user input.

Functional and data requirements

Medium

UI_016 The user interfaces should be able to visualize crowd levels on public transport routes

Functional and data requirements

High

UI_017 The user interface should provide map-based representations of a user's transport opportunities.

Functional and data requirements

High

UI_018 The user interface should provide means to predict a user's travel profile from histories of past tansport usage

Functional and data requirements

High

UI_019 The user interface should be able to visuzalize a user's travel profile and link it with journey information.

Functional and data requirements

High

UI_020 The user interface should be able to able to represent the travel profiles from a user's social network.

Functional and data requirements

High

UI_021 The user interface should be automatically updated according to changes in the context of a user.

Functional and data requirements

Medium

UI_022 The user interface should allow for voice-based user input.

Functional and data requirements

(18)

Table 1 Intent-Aware UI Requirements

The rationale for the full coverage of each listed requirements is as follows:

UI_005: The navigation service performs proactive recommendations on the user’s next travel steps. Based on information of a user’s current context and his selected route, notifications are triggered which suggest the most effective travel actions to the users.

UI_008: Geometric maps and associated visualization components are available. The maps are able to visualize route information for all bus services in Madrid.

UI_011: Route and navigation information is presented to a user in a personalized way. The user’s current context and transport behaviour is used to trigger the most informative instructions for a trip goal. This includes detection of deviating behaviours and suggestions of corrective actions, e.g. when a bus alighting has been missed.

UI_012: The user’s intent in form of his overall trip goal is central to the navigation service. This information is used by the continuous navigation service to provide step-by-step recommendation as to which actions the user should take in order to successfully complete a trip.

UI_013: The most recent travel activities of users are exchanged within social circles. The social travel information includes the semantic trip purpose and planned route. Also, the location of the friends can be accessed from the social user interface.

UI_014: Updates to the personal user interface are triggered by the navigation services without any need for explicit user interaction. Contextual information originating from transport activity detection and location recognition is used as a trigger instead.

UI_16: Crowd information of bus routes is integrated into a map based representation of a user’s travel plan. The degree of crowdedness (low,high) is visually encoded using visual clues (line width) and semantic labels attached to route segment.

UI_17: A map based interface has been developed which shows a user’s travel plan using a geographic representation. The map visualizes the trajectory of a route and distinguishes between different modes of transport (walking, public transport) which make up a transport journey.

UI_18: The route planning interface has been augmented with different forms of user inputs. One implicit form of user input is the prediction of a user’s next likely visited location. The predicted location is used to suggest a possible destination for route planning.

UI_19: A representation of a user’s travel profile has been developed which encodes the routes regularly visited by a user. The travel profile can be visualized to show a personalized view on the transport network that only contains routes being relevant to the user.

(19)

UI_021: The user interface software has been implemented as a context-aware system. Changes in the user’s context such as transport mode, location or travel behaviour trigger dynamic navigation messages which are specific to behaviour and intent.

(20)

5

Conclusion

(21)

6

Bibliography

[Facebook] Facebook, online at http://www.facebook.com

[GIUIM] GAMBAS Consortium, Intent-Aware User Interface Model, Public Deliverable D5.1.1, November 2012, online at http://www.gambas-ict.eu

[GPPS1] GAMBAS Consortium, Privacy Preservation Specification 1, Public Deliverable D3.1.1, September 2012, online at http://www.gambas-ict.eu

Gambar

Figure 1 Intent-aware User Interface Model
Figure 2 User interface menu
Figure 3 Route plannig interface
Figure 4 Indication of crowd levels on routes
+5

Referensi

Dokumen terkait

Teknik pengumpulan data adalah studi kepustakaan, studi lapangan (observasi dan wawancara) dan dokumentasi. Penulis mengunakan teknik analisis data kualitatif melalui

Jika garis pada satu himpunan dengan himpunan lainnya tidak ada yang sejajar dan tidak ada 3 garis berpotongan di titik yang sama, maka jumlah titik perpotongan yang

Penelitian ini dilatarbelakangi oleh rendahnya produktivitas kerja, kurangnya kualitas pelayanan, rendahnya akuntabilitas perangkat desa dalam memberikan pelayanan,

Dua bangun atau lebih dikatakan kongruen jika bangun-bangun tersebut memiliki bentuk dan ukuran yang sama serta sudut-sudut yang bersesuaian sama besar.. Kongruen disebut juga

1. Pelaksanaan pemberdayaan masyarakat oleh Pemerintah Desa di Desa Cimindi Kecamatan Cigugur yang bertujuan untuk menciptakan masyarakat yang lebih mandiri dan mampu

• Berdasarkan struktur huruf dapat di bagi beberapa macam meliputi jenis, bentuk dan keluarga huruf • Berikut ini uraiannyaeriku... 9.2

Jika dua sudut yang bersesuaian dari dua segitiga sama besar dan sisi yang berada di antaranya sama panjang (sd.s.sd) maka kedua segitiga itu kongruen.. Setiap pasang

[r]