webinos project deliverable Specification of webinos Proof of Concept Applications October 2011

Transcription

1 webinos project deliverable Specification of webinos Proof of Concept Applications October 2011 This work is partially funded by webinos, an EU-funded project under the EU FP7 ICT Programme, No This report is a public deliverable of the webinos project. The project members will review any feedback received; updates will be incorporated as applicable. The webinos project reserves the right to disregard your feedback without explanation. Later in the year, update to the report may be published on as well as being made available as a live and community maintainable wiki. If you want to comment or contribute on the content of the webinos project and its deliverables you shall agree to make available any Essential Claims related to the work of webinos under the conditions of section 5 of the W3C Patent Policy; the exact Royalty Free Terms can be found at: This report is for personal use only. Other individuals, who are interested to receive a copy, need to register to For feedback or further questions, contact: editors@webinos.org DISCLAIMER: webinos believes the statements contained in this publication to be based upon information that we consider reliable, but we do not represent that it is accurate or complete and it should not be relied upon as such. Opinions expressed are current opinions as of the date appearing on this publication only and the information, including the opinions contained herein, are subject to change without notice. Use of this publication by any third party for whatever purpose should not and does not, absolve such third party from using due diligence in verifying the publication's contents. webinos disclaims all implied warranties, including, with limitation, warranties of merchantability or fitness for a particular purpose. webinos, its partners, affiliates, and representatives, shall have no liability for any direct, incidental, special, or consequential damages or lost profits, if any, suffered by any third party as a result of decisions made, or not made, or actions taken, or not taken, based on this publication. Copyright webinos project 2011 webinos.org

2

3 page: 3 of 122 Abstract: This deliverable specifies the architecture and design of the proof of concept applications for phase I of the webinos project. The primary areas covered in this document are: 1) A user survey designed to show how the general public use and think of using applications on devices. Including information on how they would envisage future use patterns. 2) A description of the design methodology used in the application specifications themselves. 3) A description of how the project then went about selecting which applications to design (and in future develop) this is based on both the survey and the previous work carried out in the project e.g. in the requirements and use cases work. 4) Four large sections covering the application specifications themselves. This Word/PDF linear document represents only a snapshot of the application specifications for the purpose of dissemination, archiving, reviewing, delivery and dissemination as a single document. The actual application specifications are located on the webinos redmine/wiki. Those versions are the ones relevant for the work within the project. Due to the close interworking between the specifications and the implementation of the applications in webinos, experience gained about gaps that need to be filled in the specifications will be fed back directly into the online specifications. The Word/PDF document has been exported from the online version and represents the status of the specification on September 30 th, Keyword list: webinos, applications, application design

4 D5.1 Specification of Proof of Concept Applications page: 4 of 122 Contents CHAPTER 1 - INTRODUCTION Intended Audience Document structure and scope What is webinos? Objectives of Specification of Proof of Concept Applications Relationship to other work packages Reader Guidance CHAPTER 2 - SURVEY TO INFORM APPLICATION DEVELOPMENT Survey objectives Webinos Questionaires Survey questions Question 1: Please answer a few general questions about yourself Question 2: How often do you use the following devices? Question 3: In the future, what kind of devices would you prefer to use to access your personal information? Question 4: What kind of activities/ applications do you use your devices for? Question 5: In which situations do you access information and applications on your devices? Question 6: In which situations would you like to have more access to relevant information or applications on your devices? Comparing question Q2 and Q3: In the future, which devices are preferred for accessing personal information vs. the current use of devices? Overall recommendations from the survey CHAPTER 3 - SPECIFICATION METHODOLOGY Specification template UML for Web Engineering (UWE) CHAPTER 4 - APPLICATION SELECTION Application concepts Selection methodology Application comparison results Selected applications Unselected applications CHAPTER 5 - APPLICATION SPECIFICATIONS Introduction CHAPTER 5 PART A - KIDS IN FOCUS SPECIFICATION... 51

5 D5.1 Specification of Proof of Concept Applications page: 5 of INTRODUCTION Overview Target Users & Audience Target Domains & Devices USER BEHAVIOUR DESCRIPTION User Scenarios Requirements, Use Cases and User Stories User and Application Behaviour Diagram Assumptions, Limitations and Dependencies APPLICATION DESCRIPTION Abstracted Access Design High-level API Expected Platform Behaviour Security, privacy & policy management Local and Cloud Functionality TEST PLAN Application Test Plan Platform Test Coverage DISSEMINATION PLAN CHAPTER 5 PART B - WEBINOS ENABLED TWEETING INTRODUCTION Overview Target Users & Audience Target Domains & Devices USER BEHAVIOUR DESCRIPTION User Scenarios Requirements, Use Cases and User Stories User and Application Behaviour Diagram Assumptions, Limitations and Dependencies APPLICATION DESCRIPTION Abstracted Access Design High-level API Expected Platform Behaviour Security, privacy & policy management Local and Cloud Functionality... 84

6 D5.1 Specification of Proof of Concept Applications page: 6 of TEST PLAN Application Test Plan Platform Test Coverage DISSEMINATION PLAN CHAPTER 5 PART C - WEBINOS GAME STATION INTRODUCTION Overview Target Users & Audience Target Domains and Devices USER BEHAVIOUR DESCRIPTION Requirements, Use Cases and User Stories User Scenarios User and Application Behaviour Assumptions, Limitations and Dependencies APPLICATION DESCRIPTION Abstracted Access Design High-level API Expected Platform Behaviour Security, privacy & policy management Local and Cloud Functionality TEST PLAN Application Test Plan Platform Test Coverage DISSEMINATION PLAN APPENDIX C1: GAME METADATA APPENDIX C2: GAME METADATA EXAMPLE CHAPTER 5 PART D - WEBINOS TRAVEL INTRODUCTION Overview Target Users & Audience Target Domains & Devices

7 D5.1 Specification of Proof of Concept Applications page: 7 of USER BEHAVIOUR DESCRIPTION User Scenarios Requirements, Use Cases and User Stories User and Application Behaviour Diagram Assumptions, Limitations and Dependencies APPLICATION DESCRIPTION Abstracted Access Design High-level API Expected Platform Behaviour Security, privacy & policy management Local and Cloud Functionality TEST PLAN Application Test Plan Platform Test Coverage DISSEMINATION PLAN CHAPTER 6 - CONCLUSIONS Recommendations for Developers LIST OF TABLES LIST OF FIGURES REFERENCES

8 D5.1 Specification of Proof of Concept Applications page: 8 of 122 Chapter 1 - Introduction Intended Audience Primarily this document will be aimed at those members of the webinos consortium actually working on developing the proof of concept applications during the work package 5.2 task, especially those developers actually working on the four applications defined here - The specifications contained in this document will allow those developers to produce actual working applications in a timely manner. The document would also be of use to any developers (or anyone else) outside of the webinos project that wishes to better understand the capabilities of the applications that may be developed on the webinos platform, and how to go about specifiying or designing such applications to run on the platform once it is available. Whilst the text of the document itself should be fairly self-explanatory in nature, it is expected that the reader has a technical understanding of the (web application) development process, and also a basic understanding of UML to be able to fully understand the many diagrams included in the four application specifications. Diagrams are widely used in the specifications to help illustrate the design, in particular this document uses UML based Web Engineering (UWE) diagrams Document structure and scope This report conatins complete specifications for four different webinos proof of concept applications; the proof of concept applications themselves are intended to demonstrate a broad range of webinos functionality covering all four of the webinos device domains, a large number of webinos platform API's and other prominent webinos features such as secuirty and privacy. It is hoped that the applications specified in this report will demonstrate the unique capabilities expected of webinos as a cross domain, cross platform, application execution environment. The report itself is divided into a number of chapters; Firstly chapter one (this chapter) covers information on the intended audience, the document structure and the scope, as well as an overall description of webinos and a description of the work package 5.1 task. It also gives the reader some guidance on how to read the document, which is especially important if for example the reader wishes to discover about just one of the application specifications. The section is intended to allow a reader new to webinos but with an interest in webinos application development to understand both the webinos project itself, and how to use the document to fully understand the application specifications contained within it. Chapter two presents information regarding a survey carried out to inform the application development part of this project, it describes in detail the rationale behind the survey, the methodology used and then the results of the survey. It highlights the key findings that can be made from the results. The choice of applications for specification in this task are backed up by the results of the survey (and vice-versa)

9 D5.1 Specification of Proof of Concept Applications page: 9 of 122 The next chapter of the document (Chapter three) covers the specification methodology, a full description of the specification template, and includes a brief introductory description of the UWE methodology and how it was used in the specifications contianed within this deliverable. The fourth chapter describes how the webinos project actually decided upon the four applications that were to be specified in this document from a larger set of application ideas. This section includes details on the methodologies that were used for developing the initial applications concepts, and also the methods that were used to decide and vote upon which applications were to be fully specified in this report. Both the applications that were selected and not selected are outlined briefly so the reader may understand further some of the unique capabilities expected of the final webinos platform. Chapter five contains the four application specifications themselves - there is a brief overall introduction to the specifications and then the four applications are specified in detail using the same template. It should be noted that under normal circumstances a developer would make a seperate document for each application specification, but for the purposes of this deliverable we have incuded them all in one section with each specification being in its own part. The four application specifications are each given their own part number and cotain their own subsection numbering seperate from the numbering of the rest of this document CHAPTER 5 PART A - webinos: Kids in Focus CHAPTER 5 PART B - webinos enabled Tweeting CHAPTER 5 PART C - webinos game station CHAPTER 5 PART D - webinos travel Chapter six deals with conclusions arising from creating the specifications and the specification process itself. This section also includes a section containing recommendations to developers looking to actually develop the applications as they are specified here. The recommendations cover what the next steps should be to develop the applications, and also some thoughts on the problems that might need to be overcome to make a successful implementation, including an understanding of the dependencies each application has towards the platform What is webinos? webinos is a web-based platform defined by a suite of specifications with a reference open source implementation. The platform is necessary and sufficient to guarantee interoperability between web applications over multiple devices and multiple domains (TV, Automotive, etc). webinos is built upon the state of the art technologies described in Deliverable D02.3 by facilitating an abstraction layer (Overlay Network) allowing coordination of web applications across multiple devices in a secure, private, and usable manner. webinos builds on the vision that it should be possible to use and share applications consistently and securely over a broad spectrum of converged, connected devices, including mobile, home media

10 D5.1 Specification of Proof of Concept Applications page: 10 of 122 (TV), PC or automotive. This vision has an impact on the way services are developed as well as on the stakeholders involved: Services can be used in several contexts across all user devices Services can make use of the specific capabilities and resources the underlying hardware platform provides Services securely access private and non-private data and services on the cloud, as well as data on the user terminal Services are developed once by service providers and deployed anywhere. Manufacturers and network operators have a service platform constituted by open standards and open source, which satisfies the requirements of the four domains home media, mobile, automotive and personal computing. To materialise this vision a number of issues have to be addressed, relating to the coupling of applications and devices, context awareness of applications, the fragmentation of hardware platforms for these devices and the impact for different stakeholders and the missing security framework. Each of these issues is addressed below. A high level overview of the webinos application framework is given below. The physical devices expose and share a common API runtime. At the top the cloud services make possible the development of true convergence services Objectives of Specification of Proof of Concept Applications From the webinos Description of Work document : In (Task 5.1) Specification of Proof of Concept Applications the specific use cases that will serve as a basis for internal proof of concept creation and evaluation, will be defined. In this task, we will depart from a report of various application concepts that might be valuable as a reference source for designing, adapting and improving a small suite of applications and services based upon the webinos platform. In total, 2 to 3 applications will be chosen for full development. The applications will be chosen in this way that all the target media (mobile, home media, PC, automotive) are addressed, and a number of different functionalities. The applications to build will be conceptualized and designed, all capable of being added into customized webinos solutions as independent and interoperable modules. The objective of this task is clearly seen from above to be to define two to three applications from concept through to design. It is also apparent that the set of applications need to cover the "target media" (project domains) and also a number of differing funtionalities. Due to the number of webinos partners involved in both the Specification of proof of concept applications and the Proof of concept application development task, it was decided that it would be

11 D5.1 Specification of Proof of Concept Applications page: 11 of 122 better to specify and develop a slightly larger number of applications so that parallel working became easier to manage, rather than have all the involved partners try to collaborate on just two applications. It was therefore decided early on during the task that four applications would be a satisfactory number to specify in this task. This would allow 2-4 partners to work collaboratively on each application, and also allow enough time for each application to be properly specified Relationship to other work packages This task builds upon some of the work done in previous work packages; in particular it builds upon the webinos platform user Stories, Use cases and personas work. This task also heavily used the particpants in depth understanding of both the webinos platform specifications and API specs. During the segment of work for this task where we actually selected which four applications to specify, we heavily used and referenced work previously carried out in the webinos report D2.1 Use cases and Scenarios. The team itself based its decisions on which applications to choose, using their knowledge of the work in the webinos uses cases document and the four webinos domains. Each application specification in this document also has a small section ( 2.2) that points to related user stories and use cases in the D2.1 Use cases and scenarios deliverable. It was essentially forced upon each specification sub-team that they carefully considered their applications relationship to the previous Use cases and scenarios work. The survey on application usage contained in this report was conducted together with work carried out when developing the Industry landscape reports. The survey for this work is particularly focused on applications and end-user attitudes towards them. The survey results are co-related in this report to each of the specifications, in each case the relevance of the survey results to the application are highlighted. The work carried out in specifying webinos was also influential on the work done for this task, primarily when selecting a set of four applications to specify one of the key considerations was API coverage (the second set of figures in Table 1) this score was derived from the particiapnts knowledge of the complete set of API specifications work together with an estimation of how much API coverage each application would provide. There is also a forward looking aspect to the relationship with other work packages and tasks. In some way the work in this task should be used to guide or prioritise platform development work (Phase I platform development). The specifications contained within this deliverable will also be used extensively during development of these applications, it is also hoped that these specifications will be updated where needed during the development process. Finally the specifications of this deliverable can also be used during webinos demonstration and evaluation work to provide guidance as to how to demonstrate and test the webinos platform in an end-to-end manner.

12 D5.1 Specification of Proof of Concept Applications page: 12 of Reader Guidance This document is quite lengthy, and contains a lot of detail on each of the four applications that the project has selected to sepcify and develop in work package 5 phase I. The early chapters contain a description of the methodology used in the specifications and details on the selection process itself. In order to provide some guidance for a reader looking to obtain specific information on just a single application the following approach to reading the document is suggested: Chapter 1 - All sections Chapter 2 - Relevant sub-sections/survey questions Chapter 3 - All sections Chapter 4 - Sections 3.1 & 3.4 Chapter 5 - Relevant part(s) based on Application choices Chapter 6 - All sections

13 D5.1 Specification of Proof of Concept Applications page: 13 of 122 Chapter 2 - Survey to inform application development Survey objectives The objective of this survey is to explore information sharing aspects to personalised information and documents. This will inform us about user needs and expectations to the created application delivery environment, and its applications. Thus, the survey results will help inform our application descriptions, the development of applications, some platform implementation priorities, and some strategic choices needed for bringing webinos to the target device markets. The survey was anonymous, answered on a volunteer basis, conducted online, consisted of 10 questions, and aiming for about 15 minutes for each participant to complete all questions. The title of the survey was: user behaviour and expectations for accessing and sharing digital information. 2.2 Webinos Questionaires Methodology The purpose of this section is to provide background on the methodology chosen. The main aim being to gain some early insight and indications into potential users current concerns, and expectations of applications with a view to help inform application choice and design for the Webinos multi-platform, cross device, and cloud usage scenarios. It is important to view the questionnaire as part of a larger context of methods and not just one isolated study. For example, earlier on in the webinos investigation of security and privacy aspects it was used in conjunction with focus groups to help give an overall picture more specifically on those topics. Also, this does not mean that the questionnaires should stop here. They may be extended in the future and used to complement other sources of evidence in the future too and/or for a larger scale assessment such as with crowdsourcing (leveraging off the wisdom of the crowds ). The most popular of these is AMT (Amazon s Mechanical Turk) 1. For the purpose here, it was important for the questionnaire to be not too long and not too complex to complete. The overall aim at this stage was to get some idea of what to focus on (or what not to focus on) initially, the potential concerns, and highlighting aspects to consider when strategizing. We wanted to investigate what people are using and what might be necessary going forward. Why questionnaire? Questionnaires can be used for both formative and summative evaluation. The purpose of the first of these is (to inform) for the designer of the system. For example, to get opinions on work/usage 1 AMT requires companies to have registration in the USA and payment methods with a USA credit card. This made it less suitable within the time constraints for an initial investigation.

14 D5.1 Specification of Proof of Concept Applications page: 14 of 122 practices, interfaces, and so on. The latter is used afterwards to summarise system acceptance by users/customers. We have used the questionnaire as an initial means of formative evaluation to help scope potential applications, devices, and security & privacy concerns. The advantages of questionnaires include the following: remote population access, in many cases communities and groups exist only in cyberspace i.e. have an online identity (relates well to our potential user groups) suitable context and forum to be asking if have a face-face opportunity then can go to people with computers (this makes it more in context i.e. at least they are using one of the Webinos devices) The disadvantages can be: sampling (there are many sampling issues to consider. We did not cover all potential groups of users but certainly aimed to focus on a good gender and age balance as much as possible though the dissemination didn t include teenagers in this deliverable. In order to further address potential sampling issues, when possible we used both online and traditional method of paper-based) maybe hard for participants to recall or tell truth about a controversial question (we tried to avoid questions that would require this as much as possible) Can seldom deal with context (they were distributed in contexts/situations to minimize the lack of certainty or knowledge around though we acknowledge that there is likely to be a lack of detailed context knowledge with this method of evaluation) Must ensure large sample will reply (not always necessary in early stages of formative evaluation, though would need to build on lessons learnt when working towards a summative one Questionnaire structure and testing We have based our questionnaire on a generic questionnaire design that includes an introduction stating what the study is for; background demographic information; and specific questions. Getting the questions right is usually a matter of drafting and redrafting. Piloting also helps for seeing whether participants find anything confusing or tricky. To this end, we piloted with 8 participants iteratively each with a separate feedback session resulting in the adjustment and finetuning of the introduction, the questions, the answer selections, and scales. We also built on our earlier expertise (Goker and Myrhaug, 2007) around type of questions that were useful and how to best phrase them. Our prior experience includes working towards some 480 questionnaires with responses from variety of channels and sources within a context of a mobile use study. In that case, early results from a formative round indicated very strongly what platform

15 D5.1 Specification of Proof of Concept Applications page: 15 of 122 should be used for the targeted group of users. The result was to abandon the course at the time and reprogram for another platform to ensure a higher probability of system uptake. A Likert scale is a short rating scale that looks for someone s opinion, usually whether or not they agree with a statement. Five-point Lickert scales are the norm and is enough to present a choice but not to overwhelm. Similarily where there was a rating scale, we have used a 5 point one. We considered the question of whether there should be a middle point but on balance decided that it would be premature at this formative stage to force participants to decide on one end or another. There is also the option of ignoring the middle point if necessary later on. So, in summary, each question had multiple answers that were answered on a 5-point Lickert scale. There were a total of 172 people respondents to the questionnaire, of which 33 persons answered the face-face questionnaire having a completion rate of 99.4%. The online version of the questionnaire was answered by 139 people, giving a completion rate of 71.1%. Both data sets were comparable with each other and responses seem to be independent of the media used for collecting ie. paper v.s. web browser. One answer within 5 of survey questions were included to be able to filter away eventual malicious response caused by randomly clicking participants or responses cause d by misunderstanding of questions. These were: Q5-1, Q7-23, Q8-23, Q9-17, and Q Each query had multiple answeres that were answered on a 5pt lickert scale. All online contacted respondents were through Linkedin. Linkedin because it is a worldwide community where people share information with each other online. The users receive regular s and tweets from their groups. Most importantly, we wanted to make sure the respondents had at least one device and are accessing the web, because Webinos is about multiple devices and web applications. We also put some checking mechanisms to ensure that the questions were completed genuinely. We used this questionnaire as a test for this too. It was anticipated that the respondents would provide either an end-of-scale value for these filtering answers. The results show that these filters will indeed work, and that our respondents pre-dominantly answered with sincerity. In a large-scale (more summative) online survey, where participants were to be paid to participate, this would seem to be a useful and relevant way of filtering away erroneous responses Rationale and Background for methodology Overall, the questionnaire is about informing our application development phase about users current expectations and to some extent current behaviour. This does not conclusively mean that this is how users will actually behave when an application is developed but it does form an initial formative guideline. It is also worth noting that if there is too great a mismatch between expectations and reality of how a system or application performs then there can be problems later when we have completed applications. Hence, the appropriateness of a check at this point. Background for methodology

16 D5.1 Specification of Proof of Concept Applications page: 16 of 122 In designing the mix-mode questionnaire we have been influenced by the work of several such as the following (Denscombe, 2005; Dillman, D. A. 2000; Millar, and Dillman, 2011; Groves, 1979; Groves, 1987; Groves,1989; Hansen and Haas,1988; Kaplowitz, Hadlock, and Levine, 2011; Manfreda, and Vehorar, 2002; Roberts, 2007; Wright, 2005) in addition to our own (Goker and Myrhaug, 2007). We considered designing mix-mode questionnaires and also considered the mode effects and aimed to address these as much as possible at this stage. Mix mode questionnaires are increasingly used (Roberts, 2007) and often can offset weakness of one mode against other or by quantifying the extent of it (Groves, 1979; Groves, 1987). We also considered that on balance there is little evidence of mode effect: between web based questionnaire and manual (even for young people s health) compared for completion and data content (Denscombe, 2005). Where relevant we have considered the means to reduce the effect of differences based on others earlier work (Dillman, D. A. 2000; Millar, and Dillman, 2011). As, studies had also previously shown that people give more accurate response with pen and paper (Manfreda and Vehorar, 2002; Hansen and Haas; 1998) we included the face-face questionnaire in the mix-mode approach. We have tried to ensure a good response rate (Kaplowitz et. al, 2011) and have a relevant response pool. We aimed to have a good and relevant data from population of interest whilst ensuring quality data Survey questions To explore these user needs and expectations, three categories of questions were identified: user demographics (question Q1), experience with devices and applications (question Q2-Q6), and security and privacy for personal information and documents (question Q7-Q10). The questions asked in the survey were: Q1: Please answer a few general questions about yourself Q2: How often do you use the following devices? Q3: In the future, what kind of devices would you prefer to use to access your personal information? Q4: What kind of activities/ applications do you use your devices for? Q5: In which situations do you access information and applications on your devices? Q6: In which situations would you like to have more access to relevant information or applications on your devices? Q7: Which personal information and documents are you happy to share with family and friends? Q8: Which personal information and documents are you happy to share with local shops and marketing agencies that you know? Q9: How much do you trust the following people and organisations to handle your personal information and documents in a secure way?

17 D5.1 Specification of Proof of Concept Applications page: 17 of 122 Q10: Which personal information and documents do you think others could misuse for their own benefits, or to seek harm? Questions Q2-Q6 was added to explore the user experience with multiple personal devices, applications, and information access in various situations. These questions were specifically related to application provision for multiple devices. The participants were specifically asked to state how much they currently are using their devices to access information and applications, and in which situations, through question Q2, Q4, and Q5. In addition to this, their future needs for personal information access across multiple devices were also explored with question Q3 and Q6. The findings for questions Q1-Q6 are located in the below sections, whereas the findings for questions Q7-Q10 are to be found in Deliverable 2.8, because those findings were specifically established to inform about self-attitudes on security and privacy. Recommendations related to each question can be found at the end of each question analysis. Additionally, a section with some overall recommendations for application development is located just after the presentation of the survey findings Question 1: Please answer a few general questions about yourself The online survey was conducted on various groups on LinkedIn. In the beginning of year 2011, there were about 101 million users on LinkedIn, and 41.1% of these were women (see presented by A. Verde). Our online survey resulted in a 39.6% female participation, which is close to the LinkedIn gender distribution. Also, the age distribution achieved for our online survey seems to be roughly on par with the general age distributions for LinkedIn users. The majority of our respondents were between years old.

18 D5.1 Specification of Proof of Concept Applications page: 18 of 122 The overall demographics of our participants became Figure 1 - Survey Question 1: Demographics Question 2: How often do you use the following devices? This question was asked to explore the variations in what kind of devices that people are using, and additionally also how often they use these devices. The possible answers could be anything between 'never' to 'daily' on a 5-point scale. In general, if the sample data shows that most people would have multiple devices, then this would naturally increase the need for webinos platform and applications. However, if people would be using only one device, then the need for webinos would seem to be less. Similarly, if people tend to use some devices daily or weekly, then these devices would probably gain more focus in the context of application provision than those devices that are rarely being used. However, note that if the trend is that a particular kind of device is being used less than others, then this does not mean that there would be a less potential for monetising from applications for such devices. Such devices would probably and typically be targeting a particular market niche.

19 D5.1 Specification of Proof of Concept Applications page: 19 of 122 Figure 2 - Survey Question 2: Device usage frequency 134 participants answered question Q2. The bar chart shows the average value of the responses. For analytics purposes, we have chosen to label the devices with average value between 4 and 5, on the 5 point scale, as 'devices frequently in use'. Similarly, the kinds of devices resulting with an average value between 2 and 4 are labelled as 'devices less frequently in use'. All other devices are grouped as 'devices not frequently in use'. The following types of devices are in average frequently in use: Mobile phone Laptop Wireless network & router Television The following devices are in average less frequently in use: Desktop computer Car audio & radio Camera & camcorder

20 D5.1 Specification of Proof of Concept Applications page: 20 of 122 Tablet computer, pad Home media station The following devices seem in average not frequently in use: Home game station Car computer & displays Reader digital book Digital picture frames Interestingly, for instance, home game stations, digital book readers, and picture frames figure quite low in the landscape. This is in quite contrast to the most frequently used end-user devices, which unsurprisingly are mobile phones, laptops, and the television. It seems worth noting that the car audio & radio seems in average to be more used than tablet computers. In light of question Q2, the recommendation for application development is to either combine a frequently used device with a less frequently used device, or to design the application with up to several frequently used devices in mind. Both strategies would quite likely lead to a faster uptake of the developed application, due to the increased availability of the application for the target users. Most certainly, providing an application for mobile phones, laptops, and television seems to be a very safe route to market for any application Question 3: In the future, what kind of devices would you prefer to use to access your personal information? There could be an upper limit to how many personal devices that a person possibly would want to be in the possession of to engage with information, friends, and applications on. The participants were therefore asked about their device preferences for accessing their personal information in the future. If the average answers reveal that people in general would like to access their personal information on any kind of device, then the limit would seem quite high. On the other hand, if the responses show that people carefully choose which device to access their personal information with, then there would probably be certain device features that would better meet the needs for personal information access than others. Perhaps information privacy, device size, and mobility would be amongst such factors.

21 D5.1 Specification of Proof of Concept Applications page: 21 of 122 Figure 3 - Survey Question 3: Expected future device usage The survey resulted in 124 responses for question Q3. This bar chart depicts the average values of these responses. By studying the results a bit further, it dawns that one could group the results into the three categories of 'medium to highly relevant', 'less to medium relevant', and 'not relevant to less relevant'. The value range for the first category is between 3 and 5, the second category captures the values between 2 and 3, whereas the latter category encloses the values between 1 and 2. Here are the kinds of devices that the participants thought to be of medium to high relevance for them to access their personal information with, in the future: Laptop computer Mobile phone Tablet computer, pad Wireless network & router Desktop computer Next, the following kinds of devices were thought would be of less to medium relevance for the participants to access their personal information with, in the future: Television Reader digital book

22 D5.1 Specification of Proof of Concept Applications page: 22 of 122 Camera & camcorder Car computer & displays Home media station Car audio & radio The following devices were considered as between not relevant to less relevant for them to use for personal information access in the future: Digital picture frames Home game station It seems worth noting that the home game station occurs in the latter group. It seems that games and personal information access does not really go hand in hand from a conceptual point of view. Another interesting observation at the desired end of the scale is the sudden occurrence of the tablet computer (pad) as a device of medium to high relevance for access to personal information. It seems to slip in between the mobile phone and the desktop computer. Tablet computers have been around for more than a decade, so it could be the recent lean form factor of these that makes this device type enter the top 5 list of wanted personal devices of the near future. Note that all respondents answering Q3 also responded to Q2. Given the findings of question Q3, a general recommendation for application development would be to target at least one of the personal devices that are considered of medium to high relevance for accessing personal information in the future. If the developed application is targeting a device type considered as less relevant for personal information access, then the combined availability of the application on a more preferred personal device would likely increase the uptake of the application. It is also recommended to design applications that can also run on tablet computers, because the respondents seem to be thrusting for tablet computers Question 4: What kind of activities/ applications do you use your devices for? There were 114 responses to question Q4. The results are exhibited in the figure below. The purpose of the question was to look into which applications or activities that people engage with on their devices, and also how often this interaction happens. Some types of devices could be considered more appropriate to provide certain applications on, whereas other devices could for instance be used to engage the users with only a small set of activities. The question is meant to capture the various types of activities/ applications independently of the type of device. By measuring the average user involvement in activities and applications, one would better know which kind of activities and applications that could be provided across multiple personal devices in order to achieve a fast platform adoption. This presumes that the value of the platform lies in the suite of applications/ activities provided to the users.

23 D5.1 Specification of Proof of Concept Applications page: 23 of 122 Figure 4 - Survey Question 4: Device activities After a closer review of the responses, it makes sense to analyse the results by dividing them into the three groups of: 'rarely to monthly basis', 'monthly to weekly basis' and 'weekly to daily basis'. The first category spans the average value range between 2 and 3. The second group is for average values between 3 and 4, whereas the latter one covers average values between 4 and 5, on a 5 point scale. By clustering the average answers into these categories, one could say that people generally seem to in average engage with the following activities/ applications on a weekly to daily basis: Send messages,

24 D5.1 Specification of Proof of Concept Applications page: 24 of 122 Use a web browser Search the web Access social network Text chats with people Search for local information Manage contacts Listen to music After this, people in average would seem to be involved in the following activities/ applications on a monthly to weekly basis: Watch online videos Use a map, navigate Transfer files between devices Check the weather Shopping, payment, banking For studies and homework Voice or video calls Take photos Share photos with others Travel information Furthermore, people seem to in average be engaged with the following activities/ applications on a rarely to monthly basis: Install applications, games Play a game Mobile TV, radio Health information Buy digital books Follow fashion It is noteworthy, that buying digital books, and installing and playing applications and games figure in the rarely to monthly category. These are activities known to generate income for the providers of

25 D5.1 Specification of Proof of Concept Applications page: 25 of 122 the digital content, applications, and games. Despite these not floating upstream to the two more frequently used categories, they still seem very profitable activities for electronic publishers to be involved in. Perhaps if the age demographics showed more respondents in the under 20 category, then playing a game would perhaps have migrated to the monthly to weekly category. Another observation could be that the weekly to daily activities/ applications seem to be surrounded with business models where online advertisement would be the revenue stream. The recommendation is to provide applications for some activities that people engage with on a weekly to daily basis. If an activity is located in for instance the monthly to weekly category, then it would be a good idea to try to combine this activity with a more frequent activity for the user. This could mean to integrate the application with a search facility, to add chat functions to the application, to make the application a social one by integrating with social networks, or to let the users send messages/ from within the application. If the main activities of the application are in the monthly to weekly category, then it would seem appropriate to develop applications for trading products or services, because the potential for advertisement revenue from less frequent activities would probably be less than for frequent activities. This is probably in particularly true for activities that people engage with for instance times per annum. Thus, the recommendation is to think advertisement business model for frequent applications/ activities, and transaction or subscription based business model for applications/ activities that seem to be less frequent Question 5: In which situations do you access information and applications on your devices? Knowledge about which situations people use their personal devices in, and how frequently people are in such situations, could help reveal more about the environments that users likely will be accessing information or using applications. The listed situations aimed to cover everyday situations in which people would be in during a day, with a focus on public and private spaces that they likely would have access to. In some countries there are recurring surveys that measure how much people watch television or listen to radio per day, in which these consumer activities mostly occur in a home situation. Thus, this question attempts to in a similar way to understand the various situations in which it seems natural to access information on personal devices - independent of the information or application at hand.

26 D5.1 Specification of Proof of Concept Applications page: 26 of 122 Figure 5 - Survey Question 5: Current usage situations After a closer study of the resulting chart, it seems reasonable to describe the results by dividing them into the three categories of: 'daily to weekly', 'weekly to monthly', and 'monthly to rarely'. The top category encloses the average value between 4 and 5. The medium one holds the average values between 3 and 4. The lowest category captures the average values between almost about 2 and 3. By sorting the answers into these three categories, one can state that people access information and applications on their personal devices, on a daily to weekly basis, in the following situations: At home At work, school Next, people access information and applications on their personal devices, on a weekly to monthly basis, in the following situations: On train, bus, metro In street, walking In other homes than yours Furthermore, people access information and applications on their personal devices, on a monthly to rarely basis, in the following situations:

27 D5.1 Specification of Proof of Concept Applications page: 27 of 122 In a cafe, bar, pub In a restaurant In stores, shopping centres In a library, museum Outdoor in nature On an air-plane When sporting Unsurprisingly, the home, work, and school situations are the most frequent situations in which people use their personal devices in. It is interesting to see that passenger situations followed by walking in the street, and other homes are in the next category. These situations would be happening in between the three top situations for using personal devices. In the more in-town and walking situations, people seem to make less use of their personal devices to access information and applications. It is also worth noting that in the situations where people are most physiologically active, i.e. outdoor in nature and when sporting, people seem to rarely access information and applications on their devices. The recommendation is to certainly design applications that are suitable to use in the most frequently occurring situations of home, work, or at school. The runner-up situations to design applications for seem to be when people are somehow moving between some of these three top situations. After this it would be interesting to design applications for when people are in the contexts of eating and shopping. In all of these more mobile situations, however, the recommendation is to design applications primarily for mobile phone and tablet computers, because the amount of time to access the application on the personal device would typically be much less than for the home, work, and school situations. When designing for the three top ranked situations, it would be relatively safe to design with the assumption that a wireless local area network will be used, and that there likely will be a mobile phone, a laptop, or a television at hand. However, this would not be a safe assumption for the mobile situations. In these mobility contexts, the recommendation is to design the application assuming that there likely is a slower mobile network at hand. In all cases, however, the application should be designed with the capability to start/ welcome the user without any network connection Question 6: In which situations would you like to have more access to relevant information or applications on your devices? Question Q6 resulted in 105 responses. All persons that answered Q6 also answered Q5. Compared to the previous question Q5, the listed situations in Q6 were instead focussing on situations that people would be in when typically outside homes, work, or school - such as in-town, eating, travelling and so on. By focussing on these situations, it would be possible to discover contexts in which there is a need for access to more relevant information. If such situations seem to exist,

28 D5.1 Specification of Proof of Concept Applications page: 28 of 122 where the needs for more relevant information is not filled, then this could imply that one could make applications that would address such possible gaps. Thus, by asking for this, we would not only learn if users in general regard the information needs for certain situations to be met, but moreover where more relevant information is actually needed. This will help inform the choice of applications to develop, and also which platform components to develop/use. The participants provided answers between 'not relevant' to 'highly relevant' on a 5 point scale. Here are the results: Figure 6 - Survey Question 6: Desired usage situations A nearer look on the chart finds it reasonable to analyse the results by clustering the answers into three relevance clusters: 'towards medium relevant', 'medium to quite relevant', and 'towards highly relevant'. The first cluster covers the average value range between 2.5 and 3, the second one captures the average value range between 3 and 4, whereas the latter cluster contains average values between 4 and 5. By adding the answers into those three clusters, one could state that the participants believe it to be towards highly relevant to gain more access to relevant information on their devices in the following situations: In airports Additionally, people seem to say it to be medium to quite relevant to gain more access to relevant information in the following situations, on their devices:

29 D5.1 Specification of Proof of Concept Applications page: 29 of 122 In train stations In hotels, lounges When nearby interesting places and objects In bus and train seats While in libraries, museums In shopping centres In cafes, bars, pubs While sitting down In cars as passenger In every imaginable situation Furthermore, only four of the situations occur in the towards medium relevance cluster: In pedestrian areas While walking between shops While in local shops In cars, as driver Four of the top five ranked situations seem related to travel and tourism. Three of the four bottom ranked contexts seem to involve walking and standing in an urban area. The lowest ranked situation is when being the driver of a car. It also appears that people would be in more need for pertinent information on their devices when they are seated on a bus, in the train, or in a car as a passengers, compared to when being the car driver themselves. The recommendation is to develop applications that target travel, tourism, or in-vehicle scenarios. It seems there is a need for more relevant information when people are passengers on train, buses, and in cars. Applications that are suitable to use within such passenger situations therefore seem to be quite natural design candidates. The question is what people mean is relevant information in these situations. This could mean information related to the travel, to the destination, or simply to a need for infotainment or communication whilst being seated in the vehicle. The recommendation is to design the application for mobile phone and tablet computers, and in the case of in-car situations to also design the application for car computer. For in-car use the recommendation is to focus on applications for the passengers probably more than the driver.

30 D5.1 Specification of Proof of Concept Applications page: 30 of Comparing question Q2 and Q3: In the future, which devices are preferred for accessing personal information vs. the current use of devices? The types and availability of personal devices have increased slowly the last twenty years. Today, people seem to use up to several personal devices to access their personal information on. In the early days, few could have been certain that the mobile phone and the laptop would turn into such personal devices. Also, the introduction of new kinds of devices could mean the start of a migration from one type of device towards the newly introduced device. For this reason, we are interested in assessing how the use of personal devices will be in the near future compared to today. Without adding another question to the survey, it was decided to try to derive this by somehow contrasting the results of question Q2 and Q3. This was to see whether the results could indicate if there would be such potential changes in device preferences arising. Here is the combined figure:

31 D5.1 Specification of Proof of Concept Applications page: 31 of 122 Figure 7 Survey Analysis: Frequency of device usage vs. Future relevance We propose the following take-away from this figure: At first, it seems that tablet computer seems to be in high demand by the respondents as a device to access personal information on in the future, compared to today's average use of tablet computers by the respondents. This could imply a window of opportunity for webinos to support application development for tablet computers. Secondly, the television does not seem to be perceived as a preferred device to access personal information on in the future. Thirdly, it seems that people would prefer to use tablets computers slightly more in the future than the desktop computers of today to access personal information on. However, this figure is more indicative and should not be used to draw any firm conclusions from, because the two 5 point relevance scales are not identical for the two questions. Thus, these interpretations would probably need some further investigations or considerations in the light of the proposed personal zone concept of webinos. However, it indeed seems reasonable to provide

32 D5.1 Specification of Proof of Concept Applications page: 32 of 122 applications for tablet computers (pads) within the project. This was more difficult to know at the project planning stage, simply because less tablet computers were in use at that time Overall recommendations from the survey The project partners will need to describe and develop a minimum of four applications as means to show case the webinos application delivery environment. It is important to note that the process of describing applications will be repeated also at the beginning of task 5.4 of work package 5. The recommendation is for each application to be carefully chosen in light of the survey results together with the criteria of being an innovative application. All webinos partners and affiliates are encouraged to create and develop applications to monetise either jointly or individually from the application. The overall rationale behind work package 5 is to make webinos-enabled applications for a living, and through this to add value to the webinos application delivery environment. The survey results indicate people's self-attitudes and preferences for personal devices, applications, and activities. It also shows some broader situations where people use these devices and applications. Furthermore, it also indicates some information and application needs that people have today and in the near future. The devices that indeed seem very safe for webinos application development are: Laptops Mobile phones Television Wireless networks and routers It also appears relatively safe to address the following devices: Tablet computers Desktop computers In-car consumer electronics Camera-equipped devices The need for car computers and displays has also been explored. It turns out that the current state of the art for in-car consumer electronics still seems to have gravity around car audio and radio. Adding value to the in-car experience by combining car computers with mobile phones or tablet computers could be an interesting route forward to explore. The following situations would need to be incrementally populated with webinos-enabled applications to ensure a faster uptake and spread of the webinos platform: At home

33 D5.1 Specification of Proof of Concept Applications page: 33 of 122 At work, school Mobile contexts The mobile contexts appear to involve using transport or walking. In these situations people turn out to have a preference for accessing information and applications on their devices in conjunction to transport hubs or when seated in vehicles as passengers. For webinos to become a success, the recommendation is to explore and address the survey results to inform the choice of applications to be developed. Also, more applications than the first four ones will most certainly need to be developed. The webinos partners and affiliates are therefore highly encouraged to develop more innovative applications with a view to monetise from these. The more applications that become available and the smarter our application choices are, the higher chance it would be for webinos to become adopted and widespread across devices and operating systems. The overall webinos vision of providing one application for multiple devices is important for application developers. However, there must also be interesting opportunities for users too, and a good way to do this is to make applications that cater for various information experiences across the devices in demand. The value of the platform would likely increase with the growing availability of applications. Converged information experiences and applications across multiple devices seem to be a unique selling point for webinos. Designing applications for multiple devices seems possible. The knowledge gained and lessons learned from making the first suite of applications will be used to inform the platform development. It will be important for application and platform developers to share their experiences.

34 D5.1 Specification of Proof of Concept Applications page: 34 of 122 Chapter 3 - Specification methodology Specification template Before writing the proof of concept application specifications the team writing the application specifications agreed on a standard template format for all of the specs. The specification template has a number of major sections and more minor sub-sections and follows a logical order in a "topdown" approach. As the reader progresses through each of the specifications more and more detail about the application and how it is to be coded is introduced. The template we defined was intended to give a reasonably good level of design information to allow a developer to actually go ahead and code the application - it is somewhat similar to a typical high level design document. It was decided not to try and make a more detailed (functional level) specification as this is not a typical approach for developers of this type of application, and would probably also require a more stable and complete platform than webinos currently is Introduction section Each of the specifications begins with an introduction broken into three smaller parts, the first of these parts is a textual description and overview of the appplication. The text will describe the application in a manner that enables the reader to get a good overview of the application features and capabilities - this is typically the kind of text a reader may encounter as an application description in an online application store. The next sub-section lists the target audience and also describes these in terms of defined webinos personas which were defined in task 2.7. The final introdcution sub-section describes the target domains and devices, briefly listing which kinds of devices the application will be expected to work for User behaviour description section The next major section of each specification is the user behaviour description, the first sub-section of which describes a few of the various user scenarios form a high level, these can be considered somewhat similar to use case stories that were used as part of the use cases and design of the main platform. The user scenarios are described in a textual fashion and are intended to give the reader a more detailed understanding of the concept and features of the application concenred. The next subsection in the user behavior description references relevant webinos use case stories and use cases as previously defined in the requirements and specification work. The section also includes a number of UML use case diagrams to highlight key use cases. The final sub-section in the user behaviour description lists the Assumptions, Limitations and Dependencies - where known we try to highlight the assumptions we have made in the specification (and in the application design in general) and we alo list any known limitations and dependencies on the paltform.

35 D5.1 Specification of Proof of Concept Applications page: 35 of Application description section The application description section defines the application in more detail using UML and UWE daigrams (see section 2.2). The first sub-section contains an abstracted access or UI design, from this diagram it should be possible to understand the flow of the application in terms of the various UI screens and menus that will be presented. The team made a concious decision to stop short of defining the exact look and feel of every UI screen (e.g. wireframing or storyboarding) because webinos applications will typically be deployed on so many devices and different screen sizes and capabilities that look and feel issues will be very difficult to describe in a document format. The high level API sub-section describes some of the high level webinos platform API's that the application will need to utilise to work. This can be described in terms of both textual descriptions and UML message sequences charts. It was decided that it was probably beyond the scope of the current task to define all of the inetractions of the applications in terms of message sequence charts, but we decided to include message sequence charts for the most important and critical interactions. The next sub section describes the expected platform behaviour in terms of how the appliction designer would expect the webinos platform to behave - these are essentially key criteria or assumptions that the application designer would expect of the platform itself. Security, privacy and policy management issues are then addressed in the next sub-section of the document; This sub-section lists some of the the security, privacy and policy issues that may be encountered by the application and then it addresses any identified or potential solutions to these problems. As always the platfrom security and privacy issues are an important concern with webinos both from a platform and an application perspective. The final sub-section of the application description deals with the local and cloud functionality - this is intended to highlight any issues or significant differences in local and cloud operations Test plan section Section four deals with the expected application testing and the impacts of testing. The first subsection deals with the test plan itself and is intended to be a brief outline of how a more detailed test plan could be created including listing areas that application testing may focus upon. It would be normal engineering practice to use this to create a much more detailed testing plan in future work. The next sub-section describes the high level understanding of which parts of the platform are expected to be exercised by this application. This is a high level overview and is intended to aid somewhat the planning of tasks in platform development Dissemination section The final section of each specification deals with dissemination and briefly highlights some key audiences and gives a high level overview of how the dissemination activity for the application could be approached.

36 D5.1 Specification of Proof of Concept Applications page: 36 of UML for Web Engineering (UWE) UWE overview During the phase where the team was deciding upon the specification template we also discussed the specification methodology - we decided to use the UML for Web Engineering (UWE) methodology. UWE is a model based approach, specifically developed for the design of complex web applications. This approach was selected because of its excellent applicability in adaptive web-based environments, and UWE's compatibility with standard UML (all resulting UWE diagrams and models are fully UML-comliant). Through the use of UML stereotypes, UWE adds some specific abstraction elements for modelling web-based applications. Model driven architecture (MDA) is a software design approach that provides a methodology for structuring system specifications, expressed as models. Through the use of abstractions, MDA clearly separates platform independent and platform dependent models. This is an interesting property. Especially for the specification of webinos applications, which will be deployed in a heavily fragmented environment (hardware characteristics, interaction methods, software capabilities, etc.). UWE applies the model based approach by separating the specification of an application's view on content, navigation, and presentation (both in terms of structure, as well as behavior). It was decided within the team to adopt some but not all of the UWE concepts and models for our application specifications. MDA's ultimate goal is to lay out a foundation for automatically generating an application's code based on the design models. Our aim, on the other hand, was limited to unambiguously specify flexible applications by utilizing MDA's strong abstraction mechanisms. Adopting all of UWE's models to achieve this goal would lead us beyond our scope. In result, the team decided to proceed with only a subset of UWE models. The sections below give a brief description of the UWE methodology. The following examples describe the steps for specifying an application for reviewing academic papers. The purpose of this application is to support the process of submission, evaluation, and selection of papers for a conference. The UWE methodology is described in detail at - it was developed by the web engineering group of the Ludwig-Maximilians-Universität München Requirements The first step towards developing a web system is the identification of requirements. UWE specifies the requirements in two levels of granularity: a rough description using use case diagrams, and a more detailed process description of these use cases by activity diagrams Use Case Diagrams UWE distinguishes three types of use cases (all identified by their own UML stereotype): <<navigation>>, <<process>>, and <<personalized>> use cases. All standard UML elements for modeling use case diagrams are available. E.g., system boundary box, packages, generalization relationships, stereotyped dependencies, etc. Navigation use cases are used to model typical user behavior when interacting with the web application, such as browsing the content, or searching information.

37 D5.1 Specification of Proof of Concept Applications page: 37 of 122 Process use cases are used to describe business tasks that end users will perform with the application. This are the "traditional" UML use cases and are thus modeled in the same same as done for traditional software systems. Personalized use cases are triggered by user behavior. This type of use case is not shown in the diagram below, but a possible example is "a PC chair being able to get an overview of the submitted paper since the last time he logged in". To create this diagram, authors should be able to rely on webinos deliverable D2.1 "Use Cases and Scenarios". Customization/adaptation requirements can be addressed through (actor) generalizations, personalization use cases, constraint specifications, etc. Figure 8 - Example UWE diagram: Use case diagram (Conference paper submission and reviewing application) Activity diagrams In this step, for each of the non-trivial process use cases at least one UML activity diagram is specified. The activity diagram will elaborate on the stream of tasks to be performed in order to provide the functionality indicated by the corresponding use case. As with the use case diagram, UWE introduces a number of web-specific UML stereotypes for specifying actions regarding: browsing, performing queries, transactions, etc. This level of abstraction enables designers to specify which processes their application should support, without going into detail on how it should be realized (separation of platform-independent and platform-dependent behavior).

38 D5.1 Specification of Proof of Concept Applications page: 38 of 122 Figure 9 - Example UWE diagram: Activity diagram (Conference paper submission and reviewing application) Design The requirements models provide a basis for the design models. There are three main design models: content model, navigational model, and presentation model. Each of these models are approached from a structural, as well as behavioral perspective Content The content model of a web application aims at capturing the underlying information and application logic and is similar to the corresponding model of a non-web application. Very often the

39 D5.1 Specification of Proof of Concept Applications page: 39 of 122 content model also includes entities of the domain, required for customizing/adapting the application. From this perspective, it could be useful to map the webinos context model with the entities from the applications domain model. The primary views for specifying the content model are UML class diagrams, and if necessary state machine diagrams for capturing the dynamic aspects. It is important to remark that the structure of the information in this model is fixed (even if the information itself changes). Figure 10 - Example UWE diagram: Content model (Conference paper submission and reviewing application) Navigation The navigation model represents all kinds of navigation possibilities based on the content model. The navigation model is actually considered as a view on top of the content model. Again, we can use UML class diagrams to model navigation. The <<navigation class>> stereotype is introduced to denote navigable nodes on top of the hypertext structure. The navigation interconnections show direct links between navigation classes. There are several options to model the navigation (based on the required degree of detail) Navigation Structure Model: Note: this presents a very basic model, only shows the navigation classes and their links to other nodes.

40 D5.1 Specification of Proof of Concept Applications page: 40 of 122 Figure 11 - Example UWE diagram: Navigation structure model (Conference paper submission and reviewing application) Navigation Access Model: More detailed model. In addition to the Navigation Structure Model's navigation aspects, it also describes orientation. Alternative navigation paths are handled by the <<menu>> UML stereotype. Access primitives are used to reach multiple instances of a navigation class (through <<index>>, or <<guided tour>> stereotypes) or to select items (through <<query>>). The Navigation Access Model can also be used to integrate business processes into its navigation paths (e.g. login, or register, etc.).

41 D5.1 Specification of Proof of Concept Applications page: 41 of 122 Figure 12 - Example UWE diagram: Navigation access model (Conference paper submission and reviewing application) Presentation The purpose of the presentation model is to model the structure and behavior of the user interface (and thus the look and feel) of the web application at a page level. The structural aspect describes the composition and design of each page and identifies recurring elements (headers, footers, etc.). The behavioral aspect on the other hand describes the mapping between elements and events.

42 D5.1 Specification of Proof of Concept Applications page: 42 of Presentation Structure Model: * This model provides an abstract view of the user interface. It is based on the navigation model and abstracts from concrete aspects of the UI (E.g., fonts, location of components, colors, etc.) Instead, the presentation model describes the basic structures that are used to present the navigation nodes from the navigation model. Various abstract building blocks can be used to specify this model. UWE introduces a number of UML stereotypes in support of an application's abstract UI specification: <<page>>, <<text>>, <<button>>, <<form>>, <<anchored collection>>, and <<pr'sentation unit>> to group related elements Presentation Behaviour Model: * UWE uses UML sequence diagrams to model the flow of events triggered by a user. Based on the structural components from the Presentation Structure Model, the sequence of actions throughout the application is represented. Figure 13 - Example UWE diagram: Presentation behaviour model (Conference paper submission and reviewing application) Customization Adaptivity is an increasingly important feature of web applications. Context-driven adaptation is supported throughout the different UWE models. This allows designers to create applications, which offer appropriate presentation, navigation, and content based on contextual properties. The UWE adaptability options range from simple UML constraint notes, to even pretty powerful techniques based on aspect-oriented modeling. This aspect-oriented perspective allows you to adapt an application's model based on patterns.

43 D5.1 Specification of Proof of Concept Applications page: 43 of 122 Chapter 4 - Application Selection This chapter deals with the process we used within the team to identify the four application ideas we would carry forward and specify. In total we looked at nine applications, the last of which "webinos travel" was decided upon becuase the group felt that we needed a strong travel based application to show off the automotive aspects of the platform Application concepts The following sub-sections describes a brief outline of each the application ideas we considered in the decision process to take forward application concpets into full specification. Later sections in this chapter describe the decision process itself and the four applications we chose to specify Kids in Focus Whilst driving to her parents, Helen starts an educational game between her child in the car and the grandparents in their living room. Grandparents can see and talk to the child via a combination of their mobile phone and television, they choose a picture to display on the child's screen and can listen to the child describing the object The application will allow - Discovery of grandparents tv and phone with Helen's car/tablet and pairing of those devices, Setup of the game: one side initiates (there may be safety issues with pushing to the car) Grandparents can talk, play and see where the car is Webinos Enabled Tweeting This application is about cross domain tweeting using TV, mobile phone, pc/laptop and in-car units. It involves tweeting media (pictures and videos) and comprises aspects of media sharing functionality. Contextual information can also be extracted from specific webinos APIs and can be used internally or cross-platform in order to facilitate and enhance the experience of the users writing tweets Webinos Social TV Watching TV is more or less non-social, passive entertainment. The social TV platform can extend watching TV to the wider social community of a user while enabling the user to connect to others while watching TV. While the user is watching TV he has several options join a chat associated with the currently running TV channel recommend others/friends to watch the same channel request to watch the same as a friend chat using the mobile phone for text input additionally a small video window is shown that renders the TV channel (allows user to type on smart phone without looking up and down) push content from any device to the TV set (e.g., show pictures stored on the mobile on the TV set and also navigate using the mobile)

44 D5.1 Specification of Proof of Concept Applications page: 44 of 122 (maybe this application could be implemented as facebook application because I not assume that we can create a community here to have chat partners?) Webinos Game Station The webinos Game Station (WGS or wgs) is a gaming portal aimed at casual games. Its main purpose is to allow gamers to find games and other gamers to play multi-player games. Gamers can either start closed sessions (if they want to play with their friends only) or open sessions (allowing everyone to see the invitation and join in for a game). For a gamer, this allows easy initiation of games sessions, especially since the webinos game station is not specific to a particular game, so the same interface can be used to start different games Webinos e-learning Webinos e-laerning is a context-driven UI adaptation proof of concept. It uses the idea of E-learning platform spanning across various devices that explore advantages of the context and adaptation. The application will make use of device discovery to look for devices that have higher adaptation capability or to have better content match/user experience. The user will be able to use time more effectively and learn wherever he is, stuck in the traffic jam, sitting in caffeteria, waiting for a bus etc. The application's UI adaptation features will be carried out not only on basis of device capabilities, but also using context information. It will address disabilities like short-sighted people Video sharing Jessica is visiting Bob s House She has a smartphone it beeps to indicate that one of her friend Janet s update Pulls her phone and haves a look Janet has given a review about a new movie in the stores Jessica shows Bob the review and she suggests to view the movie Jessica clicks the share button next to the review Dropdown gives the via social proximity, She picks the social proximity List of her facebook friends in her Profile (picks Bob Profile) She clicks on Bob and views the icon of Bob s TV Jessica and Bob are in the same Geographic location (Context awareness) Bob gives his TV a name Message appears on the Bob s that Jessica has a movie to watch Finally Bob plays the movie which is streaming on a cloud or on a website Federated Social Web Social communication/social activity today constitutes the fabric of the so called "social web". Yet such activity is today confined within dedicated platforms which operate as silo w.r.t. enabled social activities (i.e. friending, posting, commenting, messaging, tagging, being notified, etc), user privacy (what happens to the data/activities users contribute) and data portability (user contributed data cannot be moved from platform to platform).

45 D5.1 Specification of Proof of Concept Applications page: 45 of 122 webinos can provide an innovative infrastructure to enable federated social activity over a converged web (web and mobile web together). Using webinos as a development platform future social apps DO NOT have to be confined not operate within the boundaries of a particular social network E-health Monitoring and Alerting Webinos E-health monitoring and altering aims at helping patients suffering from diabetes. The patient is able monitor his/her health status via his/her webinos E-health monitoring and altering app that connects to his/her blood sugar sensor. The E-health web app sends alerts to his/her doctor and close family members, along with his/her location, whenever he/she needs medical attention. Webinos E-health monitoring and altering will also work while the patient is on travel. For example, while the patient is in a car, he/her can use in-car telematics communication unit to update his/her health status and inform his/her family members and doctor. The information sent will be based on the security framework and permissions set by the patient Webinos Travel Webinos travel is an digital travel assistant before, during and after a business as well as a leisure trip. While planning travel trip, a Webinos travel user is able to fetch information about relevant points of interest his/her destination or his/her own POIs to personal travel itinerary. The user can also invite friends to join his/her travel or asking helps from friends in the planning by suggesting POIs or travel routes. While on the go, the webinos travel user will will be guided to his/her POIs and he/she may receive suggestions based on personal interests. The webinos travel user can decide to share geographic location with his/her travel mates. He/she can also add photos taken to POIs and upload to his/her own social profiles After a trip the webinos user can browse his/her travel log book containing information about his/her travel route, visited POIs etc. Further, he/she can review his/her carbon footprint or simply share the travel experiences with friends Selection methodology The application selection process followed the following steps: Collect application ideas The application idea collection process were carried out in three parts: Firstly some ideas were collected during a brainstorming session during the Proof of Concept Applications kick-off meeting in Sophia-Antipolis in June Meeting attendees were divided into seven groups to work on ideas and proof of concept applications

46 D5.1 Specification of Proof of Concept Applications page: 46 of 122 Objective: To learn how the process will be for making application concept descriptions to webinos. To be creative and innovative. Desired outcome: 7 draft application concepts uploaded to the internal webinos wiki on proof of concept applications together with an action plan. Calling for new application ideas within webinos consortium at the start of the specification work. Integrating Use Cases and Scenarios specified in webinos deliverables. Overall, nine strong applications came out from this process Set up application selection criteria. The selection criteria were divided into three main categories with lists of sub-items: Domain coverage PC Mobile/tablet Home Media Automative API Coverage Attestation API Authentication API Context API Event API Gallery API AppLauncher API Messaging API NFC API Payment API Sensor API Discovery API TV API

47 D5.1 Specification of Proof of Concept Applications page: 47 of 122 Userprofile API Vehicle API Webinoscore API Widget API Horizontals coverage Group 1 (must have) Social media Multiplayer games Use multiple devices in parallel Group 2 (bonus) Location-based service Advanced media capturing/sharing News Cloud Vote on applications based on weightings guidelines Before voting on favourite applications, the partners involved were first asked to decide upon the important criteria for deciding on the applications themselves, the group came up with a list covering four key areas the Application device domains, the API Coverage, the Horizontal coverage and Innovation. The group the voted on the weightings for each criteria category above, given a total score of 100. e.g. a cast like 30/30/20/20 for Device Domain/ API Coverage/Horizontal coverage/innovations. This resulted in a weightings guideline for each application vote. The task members were then asked to cast votes on each application given a full score of 10 for each of the categories. e.g. 9/8/7/8 for Device Domain/API Coverage/Horizontal coverage/innovations. The final points for each application were then calculated by averaging the total votes and applying the weightings.

48 D5.1 Specification of Proof of Concept Applications page: 48 of Application comparison results Data used for voting and voting results are presented below. Device Domain/API Coverage/Horizontal coverage/innovations/total points Response Number Kids in Focus Webinos Enabled Tweeting Webinos SocialTV Webinos Game Station Webinos e-learning platform Video Sharing via Social Proximity Federated Social Web E-health monitoring and alerting #1 9/8/7/8/32 8/8/8/8/32 6/8/8/7/29 8/7/8/7/30 7/7/6/7/27 7/8/8/7/30 7/7/8/8/30 8/7/6/7/28 #2 9/8/8/8/33 8/9/6/7/30 5/6/7/7/25 7/6/8/8/29 7/7/8/8/30 5/8/8/7/28 6/7/8/9/30 8/7/8/8/31 #3 9/8/8/9/34 8/8/7/8/31 6/7/8/8/29 6/7/8/8/29 7/8/7/5/27 6/8/8/8/30 5/6/7/7/25 8/8/8/6/30 #4 9/8/7/9/33 9/9/7/8/33 7/7/7/9/30 8/7/8/8/31 8/8/6/7/29 7/8/7/8/30 8/7/7/9/31 8/7/6/7/28 #5 8/2/8/4/22 8/2/7/8/25 4/4/7/7/22 8/4/9/8/29 4/2/4/5/15 4/2/9/8/23 4/2/2/4/12 4/6/6/8/24 #6 7/6/7/8/28 7/7/7/8/29 6/5/7/9/27 7/4/7/9/27 5/4/5/5/19 6/5/7/8/26 6/4/7/6/23 8/6/6/7/27 #7 8/7/7/8/30 9/8/9/8/34 7/7/8/7/29 9/7/9/9/34 7/7/8/8/30 7/8/9/9/33 abstain 7/7/7/8/29 #8 8/7/8/9/32 9/8/7/6/30 7/4/5/7/23 8/4/4/6/22 7/5/2/5/19 6/6/4/7/23 6/5/4/4/19 9/7/5/7/28 #9 6/6/7/7/26 7/4/5/6/22 7/5/6/7/25 7/6/7/5/25 8/6/4/6/24 7/5/6/5/23 6/6/4/6/22 8/5/4/5/22 #10 9/7/8/6/30 8/7/9/8/32 8/6/6/5/25 6/7/7/3/23 9/8/7/8/32 5/4/4/4/17 6/6/7/3/22 7/7/7/8/29 Table 1 - Application Selection: Full comparison voting results Final (consolidated) voting results Kids in Focus Webinos Enabled Tweeting Webinos SocialTV Webinos Game Station Webinos e-learning platform Video Sharing via Social Proximity Federated Social Web E-health monitoring and alerting Table 2 Application selection: Final application voting results - consolidated average scores (max 10.0) Based on voting results, the group re-evaluated the applications by looking at the top four selected applications scope, synergy, and horizontal domain coverage to make sure that selected applications align with the full scope of webinos project. After the analysis, "Webinos Travel" application was added in lieu of the E-health application. This was done to improve our strength on Automative telematics area, along with the other top three applications from the voting process. All in the group still felt that there was great value in the E-

49 D5.1 Specification of Proof of Concept Applications page: 49 of 122 health application and it is recommended that this be used in Phase II as one of the applications delivered there Selected applications Four applications were selected to be specified in the Proof of Concept Applications Specification work: Kids in Focus webinos enabled Tweeting webinos game station webinos travel Unselected applications The following application were not selected for full specification in this work due to time restrictions, if later in the project sufficient time arises these applications may be revisitied. Webinos SocialTV Webinos e-learning platform Video Sharing via Social Proximity Federated Social Web E-health monitoring and alerting They were stored/put into a webinos wiki page for possible future uses. Meanwhile the work package 5 members encouraged other Consortium members to contribute more ideas to the bank at any time they come up with suitable application ideas.

50 D5.1 Specification of Proof of Concept Applications page: 50 of 122 Chapter 5 - Application Specifications Introduction This chapter is split into four parts and forms the main bulk of this deliverable each alphabetically named part describes each of the four selected applications in turn. The parts contain the application sepcifications themselves and follow the methodolgy and template as described earlier in section 3 of this document. It should be noted that under each Alphabetically named part of this chapter each application has its own section numbering (from 1-5) This allows each specifiaction to be read or treated in isolation from the main document. In each of the application specifiaction the user stories and use cases described in sub section 2.2 refer to the use cases and user story numbers described in deliverable D2.1 Use Cases and Scenarios

51 D5.1 Specification of Proof of Concept Applications page: 51 of 122 CHAPTER 5 PART A - Kids in Focus Specification 1 - Introduction Overview Kids in Focus is about remote communication between a home network and an in-car telematics system or a mobile device. It crosses different users, devices and networks. The application itself can support many different features, and may be integrated with other parts of the webinos platform, in particular interactive multimedia capabilities and social media Target Users & Audience Target Users: TV, Mobile, in-car telematics system users Target Audience: Parents: age 20-45; mobile phone and/or car computer and displays user; use device to send messages, , access social network and voice or video calls; use device while in-vehicle. Kids on travel: age under 10; dumb Tablet computer/pad user; use device to play a game or for studies and homework; use devices while in-vehicle. Remote babysitters: over 40 (specific for grandparent); television and Home Media station user; use devices at home; use device to play a game and access social network. Personas: [Ref D2.7: User expectations on privacy and security] Helen - Professional, young mother, Smart device owner Target Domains & Devices Domains & Devices: Automotive and Home Media network TV, Mobile, in-car telematics system, Dumb game stations etc Overall relevance of the application to the results of the survey Survey question Targeted users, devices and activities Q1: Please answer a few general questions Under 20 up to 60 and over

52 D5.1 Specification of Proof of Concept Applications page: 52 of 122 about yourself Q2: How often do you use the following devices? Q3: In the future, what kind of devices would you prefer to use to access your personal information? Q4: What kind of activities/ applications do you use your devices for? Q5: In which situations do you access information and applications on your devices? Q6: In which situations would you like to have more access to relevant information frequently in use: Mobile phone Television Car computer & displays Home media station Home game station less frequently in use: Tablet computer, pad not frequently in use: Desktop computer medium to high relevance: Mobile phone Tablet computer, pad less to medium relevance: Television Car computer and displays not relevant to less: Home game station on a weekly to daily basis: Search the web Access social network Search for local information on a monthly to weekly basis: Use a map, navigate Take photos Share photos with others Travel informations on a rarely to monthly basis: Text chat with people on a weekly to daily basis: At home on a monthly to weekly basis: In street, walking on a rarely to monthly basis: in stores, shopping centres highly relevant: in cars, as passenger

53 D5.1 Specification of Proof of Concept Applications page: 53 of 122 or applications on your devices? in cars, as driver Table 3 Kids in focus: Survey relevance for the application 2 - User Behaviour Description User Scenarios Whilst driving to her parents, Helen starts an educational game between her child in the car and the grandparents in their living room. The grandparents can see and talk to the child via a combination of their mobile phone and television; they choose a picture to display on the child's screen and can listen to the child describing the object. User scenarios can be defined at every stage of the application, from setting up remote communication to running the end application on the top of communication channels. Stage1: Discover connection party Before setting off or after pulling over onto the side of the road, Helen would like to find out if anyone is available to entertain her son, Alex, who is sitting in the passenger's seat. Helen switches on her smart phone and authenticated against her identity provider. The authentication enables access to all services that Helen is authorized to use with her identity. Helen's other devices inherit the authorization from her smart phone internet device. Helen then either: Calls or texts some of her family and friends who she thinks may be available to entertain Alex; Logs into her social network and shares her current activity with her friends and family; Got a notification from her social network indicating that her parents are having free time for the moment. This is based on the assumption that grandparents share their current activity with Helen via social network and Helen had registered her interest in grandparents activity earlier and ask for a notification when they are free. She discovers that her parents (Alex's grandparents) would be delighted to entertain Alex for her. Her device already knows the identity of their personal zone hub. These actions could also have been initiated by the grandparents from home. Stage2: Connection set up Grandparents: Sit down in front of the family television set. It has already been configured to communicate with their smartphone. The smartphone can provide a web cam (Helen's grandparents want Alex to be

54 D5.1 Specification of Proof of Concept Applications page: 54 of 122 able to see them) and potentially a network connection, unless the television already has a direct connection. Set up remote connection via their internet enabled television or smart phone. Helen: Connects her smart device with Alex's 'dumb' game/video/picture player device. e.g. the in-car telematics unit (TCU) or her smart phone is connected to Alex s dumb device. Set up remote connection via telematics unit or her smart phone. Stage3: Application execution environment There are two possibilities: The application is stored locally in grandparents home device and Helen's smart phone or Alex's game player. The application is hosted remotely on the internet. Stage4: During Use The Kids in Focus application supports the following scenarios while it is used and connected: Geo-location tracking: Helen's parents would like to know the position of Helen's car - they might change their game or video program content or length correspondingly. Helen can share information from any of her GPS devices and send her location back to her parents. Video is presented slightly differently to the grandparents and Alex; e.g. Alex's role as student whilst grandparents as teachers. The grandparents may be able to augment their video by overlaying photos. Alex will have different controls on his display to the grandparents. He will not be able to end the connection or start a new one without Helen's permission. The grandparents can exit at any time Requirements, Use Cases and User Stories User stories with related scope: WOS-US-1.1: Smart device integration WOS-US-1.2: Share GPS Receiver across Devices WOS-US-2.3: Converging applications within and across devices WOS-US-3.1: Content sharing service WOS-US-3.3: Social event sharing WOS-US-10.1: User Centric Video Playback WOS-US-11.1: Single Sign-On, Multiple Devices Use cases referenced:

55 D5.1 Specification of Proof of Concept Applications page: 55 of 122 WOS-UC-TA1-001: Virtual device WOS-UC-TA1-012: Bridging to the Home Network WOS-UC-TA2-005: Authentication WOS-UC-TA4-001: Subscribe and Publish Events WOS-UC-TA4-010: Synchronization WOS-UC-TA1-007: Linking Device to a User Account WOS-UC-TA4-013: Dinamically sharing content with other users in a controlled manner WOS-UC-TA4-020: Content sharing and storage WOS-UC-TA4-012: Sending a Picture via a Photo Sharing Service WOS-UC-TA6-002: Selecting Supported Media WOS-UC-TA7-004: Finding Devices in Close Physical and Social Proximity Use Cases Diagram: Figure 14 - Kids in focus: High level use cases diagram

56 D5.1 Specification of Proof of Concept Applications page: 56 of User and Application Behaviour Diagram Figure 15 - Kids in focus: User and application behaviour diagram - Discover Connection Party Process Figure 16 - Kids in focus: User and application behaviour diagram - In-car connection setup process

57 D5.1 Specification of Proof of Concept Applications page: 57 of 122 Figure 17 - Kids in focus: User and application behaviour diagram Home Connection Set Up Process Figure 18 - Kids in focus: User and application behaviour diagram - Run Application Process Assumptions, Limitations and Dependencies Assumptions In car user is able to connect to remote services either through the Telematics Unit or personal mobile devices. Smart devices in the grandparent's home are connected and work together. Limitations and Dependencies Cloud services for remote connection. Types of Sharing contents between Helen's in-car device and grandparents are limited by remote connection bandwidth.

58 D5.1 Specification of Proof of Concept Applications page: 58 of Application Description Abstracted Access Design Figure 19 - Kids in focus: Abstracted access model diagram

59 D5.1 Specification of Proof of Concept Applications page: 59 of High-level API Sequence diagram Figure 20 - Kids in focus: High level API sequence diagram Note: This sequence diagram shows messages from Helen's side. Similar message sequences happen in grandparents' side although not shown here.

60 D5.1 Specification of Proof of Concept Applications page: 60 of Expected Platform Behaviour The webinos platform should perform each step of process against policy rules once they are specified. The webinos platform should be able to provide persistent or long-lasting seamless communication sessions within and across personal zones. The webinos platform should allow synchronization between the PZP and PZH at reasonable update frequencies. The webinos platform shall support both local, remote and social media communications. The webinos platform shall process authentication at user, device and application levels Security, privacy & policy management There are relatively few security and privacy concerns with this application. The following threats are relevant: Alex uses the in-car system to call a different contact rather than his grandparents. Helen shares her current event/activity with her families, but she could accidentally share them with other contacts by mistake. Grandparents leave the system connected and this ends up costing them a lot of money in network fees. Alex uses the in-car system when Helen is not aware, and it allows him to play with her devices and delete her data. Grandparents use shared data from Helen to work out that she is driving faster than they would like, embarassing Helen. Another passenger - a friend of a friend - is in the car with Helen and takes advantage of the application to call other people. Another passenger - a friend of a friend - is in the car with Helen and accidentally calls Alex's grandparents. Helen's devices compile contextual information. This is spoilt when her son Alex uses it, as he has different usage patterns and styles. This upsets the context database and spoils analytics. Grandparents struggle to set up the application, and accidentally allow anyone to call them at home. Telemarketers take advantage. In order to prevent these from happening, the following design options should be taken: Alex should have limited access to Helen's personal zone and devices. He should only be able to play the games, and should not be able to change any settings. This implies that Helen delegates limited functionality to Alex's device. Alex should not be able to initiate any calls, unless Helen has allowed him to (not by default).

61 D5.1 Specification of Proof of Concept Applications page: 61 of 122 Helen should have policies which limit who she can share data with, and use this application with. The policies may depend on whether the application is an online application or an installed one. Helen should be aware of when calls are being made - some kind of alert on her display. Grandparents should only allow incoming calls from trusted individuals through this application.

62 D5.1 Specification of Proof of Concept Applications page: 62 of Local and Cloud Functionality Figure 21 - Kids in focus: Local and cloud functionality sequence diagram (see also additional page at end of document additional page is best printed on A3 paper for improved visibility)

63 D5.1 Specification of Proof of Concept Applications page: 63 of 122 The cloud functionality is mainly implemented with events, messaging and routing that happens behind the scenes, as well as any security implications. Local functionality involves media capture API, Geolocation and event managing. 4 - Test Plan Application Test Plan Integration tests Create manual test scripts for the following scenarios, including "test for success" approaches (e.g. normal situations) and "test for failure" approaches where an unusual event has occurred, or some edge-case is included. Ideally, run each of these tests on each combination of devices - (mobile -> PC, mobile -> TV, mobile -> mobile, in-car -> mobile, in-car -> TV,... etc). Realistically, focus on in-car and tablet to TV or PC. Test for success complete scenario run-through, using a tablet for the "in car" computer and a PC for grandparents. This includes: o o o o o parent creating an initial connection; grandparent answering; parent hands device to children; children play three runs of the game with the grandparents; grandparent ends the connection; Document assumptions and create new scripts which alter them. Consider the following situations: children ending the connection, parent ending the connection, loss of connection, etc. Test for failure Use a television for the grandparents and an in-car computer for the kids? a scenario where the grandparents don't answer the request, or their device is turned off, or they allow the request to nearly time out. the "naughty child" test script: run through scenarios where the child does as many odd things to the application and device as possible. test using a device without an internet connection which must use another device for connecting (e.g. a tablet with a bluetooth connection to a phone).

64 D5.1 Specification of Proof of Concept Applications page: 64 of 122 a test with a user who has a fresh webinos install, and therefore may have no pre-defined contacts or identities. Test what happens when the grandparents have not got the application installed yet. test what happens when the device moves from a bluetooth connection to wifi. test what happens when the user accidentally clicks on a different contact to the grandparents - when will they realise, and how will they cancel it? test the application in real (physical) circumstances: with users in different parts of the country (or world). Testing for threat mitigation Check that, when a "Helen" instantiates a connection with the grandparents, some kind of authentication is required (unless pre-approved). Check that the grandparents must accept incoming calls. Unit tests Unit tests will be carried out when the application is being developed Platform Test Coverage By using this application and testing it, the following Webinos capabilities are also tested: Authentication: Authenticating the users is mandatory to make use of the functionalities required to use this application. Service Discovery: Before using any service, the Service Discovery API will be used to identify which are the services available in the other end. Application Launcher: The Application Launcher API will be used once all the services available are known. Messaging: Messaging is the preferred way to contact to the other end in this scenario, due to that the messaging API will be tested when executing this application. Contacts: The contacts API is used to look for contacts stored in the Address Book. Gallery/Media Capture: The grandparents can select pictures from their media gallery or from the Alex media gallery to be displayed to play the game. In addition, they could capture a picture of any object in their living-room on the fly to be displayed to Alex. Geolocation: Grandparents may be able to locate the place where Alex is. User Profile: To get information about the preferred social networks so that the status can be updated on them.

65 D5.1 Specification of Proof of Concept Applications page: 65 of Dissemination Plan The dissemination of this application should target two key audiences: Education and Edutainment: Demos to companies creating educational games for pre-school (e.g. Disney), impact on educational forums and media (e.g. education.com) or to EU funded projects with focus on kids. Potential industry partners: Car entertainment equipment providers and TV/Set-top-box manufacturers. This scenario should be demoed to these potential industry partners at the relevant fairs.

66 D5.1 Specification of Proof of Concept Applications page: 66 of 122 CHAPTER 5 PART B - webinos enabled Tweeting 1 - Introduction Overview This application is cross domain tweeting using television, mobile phone, pc and in-car units. It involves tweeting media (pictures and videos) and comprises aspects of media sharing functionality. Webinos Enabled Tweeting application represents a new experience in terms of social networks. It uses a common social platform (Twitter) and a simple process (post status) to highlight webinos' easy of use and device integration; a Twitter user so far had to use one device and refer on any other source different that text with existing online sources (URL). Any information should be typed or captured through an image can be tweeted. With this approach a Webinos user is able to use information on different platforms to extract information and post them on the fly. This application will provide unique experience through inter device interoperability. Users will overcome constrains of network access media and device owning. Feature of different devices, belonging to the same Personal Zone Area, will cooperate together in order to provide an innovative way of sharing statuses, comments and media. At the moment webinos discovery system allows including information from a television set or a in car device. Webinos Enabled Tweeting application also has been designed to highlight policy awareness supported by webinos platform. Guest webinos users have to be authorized by the PZH owner to have access to specific devices features. Moreover, Webinos Enabled Tweeting application has been designed to fulfill webinos platform users needs and allow them to get the most from a common social network like Twitter. To sum up: No need of any further registration No admission fee required No need to buy any specific device No learning curve for the user, common tweeting with extended information Extendable with any Webinos new feature that provided data or any new supported device No need to build new social network and bring connections from other platforms By enabling webinos platform on desired devices, signing up, authorize Twitter and it will just work!

67 D5.1 Specification of Proof of Concept Applications page: 67 of Target Users & Audience Television, Mobile, in-car units, PC users, Social Media Users Target Audience: Social Media Users: age 15-40; users who are willing to share thinks with a community, tech-savvy, they build their connections on social networks and communicate with their friends in any way Non Social Media Users Users: age 25-50; users with little care or knowledge about social media, they own a TV or Car with webinos capabilities but they are not aware how they can share staff with their community. They usually use their for communication Personas: [Ref D2.7: User expectations on privacy and security] George: main Mobile Phone and/or PC user, may also has a TV and/or car to combine with his main device. He is an owner of a Twitter account. John: Car driver, where George is a passenger Alice: Television user, Alice has to Authorize George to use her TV Lia : Twitter user, friend of George Nick: Facebook user, friend of George Mike: contact, friend of George The main targeted users for this application are the mobile phone users. With Webinos Enabled Tweeting users can access other devices with their mobile phones, use mobile phone's feature (keyboard) to extract information from these devices (owned by them or maybe friends) and post a status on their network. Currently Twitter is supported, as it is an open network easily accessible in an essence of a /sms on public. Users outside webinos will be informed through their social profiles, and they may be interested to try webinos on their own (audience coming from Social Media). In conclusion, Webinos Enabled Tweeting application focuses on mainstream users, with a mobile phone, owning a social media account, wanting to send a message to their contacts on public (through Twitter) Target Domains & Devices TV, PC/Laptop, Mobile, Automotive Webinos Enabled Tweeting application allows a mobile user to access Twitter with their webinos enabled application and post a status message. Additionally, it allows mobile phone users to access other devices, less popular for accessing the Web but still attractive devices, in order to collect additional infromation and display information on a bigger screen. This activity can take place mainly at home (or car relatively), even at work or even at public places, wherever access to a television is

68 D5.1 Specification of Proof of Concept Applications page: 68 of 122 available and allowed. Thus it includes various devices, in order to highlight webinos' local discovery and authorization capabilities. In conclusion, Webinos Enabled Tweeting application focuses on mobile phones and PCs, but also supports using features from all webinos' domains, television and Automotive Overall relevance of the application to the results of the survey Survey Question Features and Target Users/Devices Q1: Please answer a few general questions about yourself Q2: How often do you use the following devices? Q3: In the future, what kind of devices would you prefer to use to access your personal information? Q4: What kind of activities/ applications do you use your devices for? Q5: In which situations do you access information and applications on your devices? under 20 up to 40 (social network users) average frequently in use: Mobile phone Laptop Wireless network & router (PZH) Television average less frequently in use: Desktop average not frequently in use: Car computer & displays medium to high relevance: Mobile phone Laptop Wireless network & router (PZH) Desktop less to medium relevance: Television Car computer & displays on a weekly to daily basis: Access social network Text chat with people Manage contacts on a monthly to weekly basis: Take photos Share photos with others on a rarely to monthly basis: Install applications, games on a weekly to daily basis: At home At work, school on a monthly to weekly basis:

69 D5.1 Specification of Proof of Concept Applications page: 69 of 122 In other homes than yours Q6: In which situations would you like to have more access to relevant information or applications on your devices? on a monthly to weekly basis: In cars as passenger on a rarely to monthly basis: In cars, as driver Table 4 - webinos enabled tweeting: Survey relevance for the application 2 - User Behaviour Description User Scenarios George wants to tweet from his mobile phone and use content that exists in other devices. These devices might be a Television or an Infotainment system. In particular he wants to capture pictures or videos, with channel information attached, from his webinos enabled television (e.g. to share with his network a funny moment or his favourite scene from movies/sports), or maybe use data like location, route, consumption, speed or destination from his car to tweet e.g. to inform his followers when estimated to arrive at his destination. The uniqueness about this application is it is device independent, covers all media aspects, makes webinos social platform independent and handles connectivity between devices seamlessly. This application will involve local discovery aspects of webinos project, messaging between devices, security, privacy and context awareness. Login, Register: George wants to login the application. He is landing on the application loading page, and he is called to login or register. If he is already registered, he is prompted to put his PZH credentials. Otherwise he has to register first. He fills in a registration form and chooses login credentials. Next George authorizes the webinos enabled Tweeting Twitter Application to have access on his followers/followees and post status on his profile. Then he is prompted to login and if successful he is on the PZH credentials page. Editing Tweet on television (1/2): While watching TV, George wants to make use of his mobile phone (MP) to enter tweeting data but the context will be shown on the television. Television should discover his mobile phone and identify the keyboard that can be used. He would also like to have this application in order to review a video that he has seen, it will include information about video, if he needs to capture particular captured photo in the stream. He should be able to access his data stored in the PC/Laptop /Network Storage on television system, and allow it to be used in tweet. Note: George can use either his PC or his mobile as input devices to control the Television, navigate through menus and edit the text of the Tweet

70 D5.1 Specification of Proof of Concept Applications page: 70 of 122 In detail, while George chooses to Edit a new Tweet, a list of the available screens he can use to display the content is provided. He chooses to use his authorized television to display the tweet he is going to edit. Then an option to search for media-enabled devices is available, or use directly the television media capture capability. If George chooses (a) to search for media-enabled devices, a list of the available devices on his PHZ is shown on the TV. He uses his Mobile Phone/PC and chooses the device he wants to connect, and a connection is established (or an error message is displayed if unavailable). Then he is able to browse an index of the available media files and select the one he will use for current tweet (The W3C Gallery API). If alternatively George selects (b) to use his TV s media capture capability, he is able to take a snapshot or capture a frame from the television (The W3C Media Capture API). In any case, George is capable to edit image (rotate, crop, resize), or choose a frame of video/audio to post with his tweet. The link of the file is extracted and incorporated on the tweet. George now uses the input device (Mobile Phone/PC) to insert text and complete his tweet. Then he proceeds on selecting addressed users. Editing Tweet in the car (2/2): When George starts a trip in his car, he is using the webinos Enabled Tweeting application on his mobile to get-in his car. The get-in is a function provided by the application (much like the Foursquare check-in) that allows you to state that you are using some kind or means of transportation. The app retrieves the destination and the estimated time of arrival from the car navigation service and automatically posts to George s Twitter account George is on the way to the Alps, be there in 4 hours along with his current location. webinos Enabled Tweeting also uses the address retrieved by the navigation service to show Mary how many of her friends have previously been in this hotel (i.e. by retrieving relative Foursquare check-ins). Note: George can use only his mobile phone or the in-car device as input device. In detail, George enters his car and on his mobile phone (after logging in) he chooses the Get-In function this time. He is prompted to choose if he wants to use the screen of the infotainment or his mobile device to browse the application. Then he gets a list of all the available devices that can be used as input, with devices in near proximity. The application accesses the car module and gets the destination, current location end estimated time of the root (The vehicle module) and generates an automated message: Username is on the way to the DestinationPOI, be there in EstimatedTime (plus current location as metadata). George now uses the previously selected input device (Mobile Phone/Infotainment) to insert text and complete his tweet. He can also edit previous message, and remove current location. Then he proceeds on selecting addressed users. Selecting addressed/mentioned users: While choosing to address the Tweet to specific friends of his network that may be interested, George realizes that there are some friends that are outside Twitter. Thus he has to use other means to reach them.

71 D5.1 Specification of Proof of Concept Applications page: 71 of 122 Note: George can uses his Mobile Phone/PC to access the agenda, and the selected device to view the index. In detail, George and starts typing a name. From Twitter he is able to find only one friend, Lia, who has a Twitter account (Twitter GET users/lookup). He chooses Lia, and clicks on the add from agenda button to find more relevant friends from his contacts. He gets access to his agenda (The W3C contacts module), and chooses two (2) more friends: Nick who has a profile on Facebook (the URL of which is stored at George s agenda under Nick s entry) and Mike who has available only an . Overview of the users that George has chosen to mention on his Tweet: Lia is on Twitter Nick is on Facebook Mike has only a Google Then George chooses to post his comment on Twitter. Note: In case we allow the Webinos enabled Tweeting app to post also on Facebook, we need to describe a Facebook app authentication during user s registration, at Login, Register step. The tweet is public, thus it is needed only a mechanism to allow notification over different networks to be provided by the Webinos enabled application. The notification system works as following: Lia is notified by Twitter, natively Nick receives a Facebook chat (inbox if offline) message with the content of the Tweet and a URL of the original message on Twitter (Facebook Chat API, XMPP based) George needs to have a Facebook account. Mike receives an , with subject Username mentioned you on a Tweet, the content and the URL of the original message an application based (e.g. username@appname.com) from George is used to send the (or do we need a Gmail authorization here and allow the user to use his personal ?). Then the application authorizes the used accounts to have access on any tagged media files, stored at the webinos Cloud storage. Policy aware webinos application: All the aspects are control based on policies to access between devices. It will involve authentication between devices. The aspects covered will change if George's friend Paul visit him and wants to use George's devices (integrating "Network Independent Virtual Device"), access and policies will differ completely.

72 D5.1 Specification of Proof of Concept Applications page: 72 of 122 Alice opens the application on the television and initiates a discovery search for location proximity. Alice spots her devices that are already authorized to use her TV, but she finds also this time the mobile phone of George which a guest device outside her PZ area. Alice authorizes George to get access to some contents (e.g television information but not images and videos stored on his TV) and allows George to use his mobile phone to insert text on the television application. George takes control of the television and logins with his credentials (George has to be registered already on the application, otherwise he is prompted to do so) George edits the tweet through his mobile phone and posts it to his account The process is similar for in car usage, with George to be a passenger at John's car who wants access to the in-car device to tweet Requirements, Use Cases and User Stories Relative User Stories: WOS-US-1.1: Smart Device Integration WOS-US-7.1: Designing Policy-aware webinos Applications WOS-US-8.2: Seamless Navigation (relatevly for Twitter) WOS-US-11.1: Single Sign-On, Multiple Devices Relative Use Cases: WOS-UC-TA1-001: Virtual Device WOS-UC-TA1-002: Network Independent Virtual Device WOS-UC-TA1-003: Virtual Device Ownership (for usage of the television from a user B who does not own the device) WOS-UC-TA1-004: Communication between webinos Applications WOS-UC-TA1-005: Sensors and Actuators WOS-UC-TA1-008: Webinos Federation (?) WOS-UC-TA1-012: Bridging to the Home Network WOS-UC-TA2-005: Authentication WOS-UC-TA2-006: Authorization WOS-UC-TA2-007: Register Social Media Account WOS-UC-TA3-003: Application Advertisement WOS-UC-TA3-004: Embedding Proprietary Extensions WOS-UC-TA3-005: Background Execution (scheduled tweet or event triggered tweeting) WOS-UC-TA4-001: Subscribe and Publish Events (subscribe to an event) WOS-UC-TA4-003: Proximity Detection WOS-UC-TA4-013: Dynamically Sharing Content with other Users in a Controlled Manner (Images/videos on tweets) WOS-UC-TA4-020: Content Sharing and Storage

73 D5.1 Specification of Proof of Concept Applications page: 73 of 122 Figure 22 - webinos enabled tweeting: High level use case diagram Tagged users outside the application (Lia, Nick and Mike in our case) are able to interact with webinos, to have access on media files on webinos Cloud Storage service. This diagram is given seperatly because it is not a part of application's core functionality, but a system's (webinos) feature. But it is needed to give a complete image of the usage scenario. Figure 23 - webinos enabled tweeting: Tagged user use case diagram User and Application Behaviour Diagram Use Case 1:Tweet from Device (Login, Register, Authenticate Social Media, Edit Messageand Tweet) George, the device owner of a Moble Phone/PC and a TV/in-car-device wants to post a new Tweet on Twitter. He logs in (or registers if needed) the application and accesses his PZH. He then selects where to display the application (e.g use the display of TV/Car or his Mobile Phone/PC if he wants to

74 D5.1 Specification of Proof of Concept Applications page: 74 of 122 use the app as a common Twitter app). He is prompted if he wants to select media files; he has three (3) options: (a) access gallery from the device, (b) use existing file from the webinos cloud service or (c) capture screen display (only for television and if allowed for the specific content). He refuses or adds the media file and then he is asked if he wants to use contextual information from the display device (e.g. location and destination from in-car device, or channel info from TV). Whether he adds contextual data or skips it, he is called to select the input device (may use PC or Mobile Phone). He then is asked if he wants to tag users (browse agenda) and then he is able to edit his Tweet. He can delete the URL of the media file, he can delete contextual data and tagged users, and he can insert/edit text. Then he can drop or post the Tweet. Note: If the User is a Guest User (George), must be first be authorised by the owner of the PZH (Alice/John). The flow diagram is the same, with the difference that George has access to Alice/John's resources that he is only authorized by them to use. This Use Case is described below with a diagram.

75 D5.1 Specification of Proof of Concept Applications page: 75 of 122 Figure 24 - webinos enabled tweeting: User and application behaviour diagram - device based tweeting

76 D5.1 Specification of Proof of Concept Applications page: 76 of 122 Use Case 2: Discover and Authorize Guest Devices Alice or John, the authorized user of the PZH where the target device (television or In-car device relatively) exists, is capable to search for guest devices and authorize it with specific access rights. Figure 25 - webinos enabled tweeting: User and application behaviour diagram - guest device discovery and authorisation

77 D5.1 Specification of Proof of Concept Applications page: 77 of 122 Use Case 3: Browse Twitter The user (George. Alice or John) is able to browse their Twitter account, as a normal Twitter application. Figure 26 - webinos enabled tweeting: User and application behaviour diagram - browsing twitter account Assumptions, Limitations and Dependencies Assumptions Discovery data Sensor data User input Limitations Depends on device in nearby proximity Webinos Cloud storage service required, with social media accounts authorization Information about PZH assumed Connectivity and messaging between devices in proximity are handled by webinos via XMPP Dependencies Mobile phone needed to enter text for TV Mobile phone and PC medium support loading of media files An app mail server must be used to send notifications Facebook and Twitter API methods

78 D5.1 Specification of Proof of Concept Applications page: 78 of Application Description Abstracted Access Design The diagram below gives an overview of the UI, with navigation classes and objects that will be shown. Generally, the Webinos Enabled Tweeting application will act first as a typical Twitter application. In addition it will be able for the user to establish communication between devices, user's device in close proximity, to exchange data or device features. Figure 27 - webinos enabled tweeting: Abstracted access design model

79 D5.1 Specification of Proof of Concept Applications page: 79 of High-level API Sequence diagram This diagram gives an initial, simplified and abstract idea (example) of how a user will be able to use his mobile phone (Mobile Phone) to tweet through his TV. Figure 28 - webinos enabled tweeting: High level API sequence diagram

80 D5.1 Specification of Proof of Concept Applications page: 80 of 122 In the diagram below it is considered that all the actions take place on the initially launched application, and when the user finishes every step (select media, select tagged users, select context etc.) the application tries to connect to the display device (if selected initially) and update it with the selected data. We consider transfered data of small size (media files from the initial device to the display device are sent as URL string only), and less power consuming to initiate connection between devices when needed to update content (apart from the case the communication is established via XMPP, thus the connectivity issue is handled by webinos and the app has only to handle application messages). The only case we need direct connectivity is while typing from the initial device (PC, Mobile Phone) to the display device (incar, TV). (Note: methods are arbitrary and focus on giving a functionallity and functions flow overview, ruther than describe specific API methods and Javascript handling)

81 D5.1 Specification of Proof of Concept Applications page: 81 of 122

82 D5.1 Specification of Proof of Concept Applications page: 82 of 122

83 D5.1 Specification of Proof of Concept Applications page: 83 of 122 Figure 29 - webinos enabled tweeting: Sequence diagram - application workflow Expected Platform Behaviour Webinos platform when performed service discovery, should list devices in close proximity. Behavior expected in terms of security is only devices belonging to user should be listed and authentication is

84 D5.1 Specification of Proof of Concept Applications page: 84 of 122 performed before connecting to the device. The device should then perform connection and it should check policy management to see if the information about the device should be stored. This information will be checked when user will try connecting to same device next time. The service discovery mechanism that is expected is to find devices based on ZeroConf discovery mechanism. It should be also able to provide WiFi connectivity details and list of connected devices to the target device Security, privacy & policy management Policy requirement that this application needs to meet are: 1. Check if device is under same user 2. Perform authentication with device 3. If input device is selected, check who is owning the device Local and Cloud Functionality 1. Local discovery will search for devices in close proximity. 2. In case of accessing remotely, PZH will be used to retrieve list of devices 3. Access Webinos Cloud Storage to get media file url 4 - Test Plan Application Test Plan Tests will be performed in two different scenarios. First, just devices from a single user Personal Zone Area will be involved. Afterwards will be scheduled tests with guest devices. Basically tests will be a combination of mobile_user, tv_user, pc_user, car_user and finally hosted_user. First scenario with mobile_user and tv_user for posting a tweet test discovery mechanisms test authentication test discovery external service test external service (twitter) authentication verify tweeting functionalities Successive test for sending notifications Tagged user on Facebook is informed. Test Facebook Chat notification Tagged user via is notified. Test notification via .

85 D5.1 Specification of Proof of Concept Applications page: 85 of 122 Same scenario, but with media content tagging. Test tag visualization. All tests should be repeated introducing pc_user and car_user with different connection layers. Second scenario with the same configuration of the first, but with a hosted_user test discovery of hosted device verify discoverability of target device by hosted_user test policies verify tweeting functionalities After this two scenarios it's necessary to test twitting activity with media contents and tagged replies. Media content scenario test discovery and policies behavior of authorized/unauthorized multimedia features (e.g. pc webcam from mobile phone or builtin mobile phone camera from pc) after capturing media contents, tagging above mentioned data, verify successful upload Post tagged replies perform above mentioned steps for receiving a reply (refer to test case "test for receiving a reply") check conversation thread (collection of sent messages/replies) select replying message and forward it as a tweet. Test its preview and its effective publication verify impossibility to modify the replying message. Constrain required to preserve replying message consistency test notification to published tweet author Test for failure: test recovering from connection loss verify behavior when tagging/uploading unauthorized media contents test horizontal handover among different network layers Platform Test Coverage The following Webinos APIs are tested: Media Capture API: capture no proprietary media from the television (personal photo albums or videos) Geolocation API: use geolocation info on tweets

86 D5.1 Specification of Proof of Concept Applications page: 86 of 122 Gallery API: Access media files on a Device and use them for tweeting DeviceInteraction API (for usage feedback, e.g. vibrate when tweet has been sent) Contacts Module API : choose mentioned users from the Agenda, for Facebook and notification Vehicle Module: get rout info, used to access vehicle information and eventually tweet some of them, such as location, trip time, etc. TV Module:get channel info, acquires and manages streams from television sources Sensors Module: use keyboard of the smartphone to type on television (or infotainment) Remote Application Access API (The WAC deviceinteraction module) Attestation: to verify that genuine version of application is running Authentication: only authorized users can use this application, therefore this API is very important Application Launcher: this API will be invoked to launch the application itself on other devices, after that external services are discovered Messaging: exchange messages is the goal of this application. Applications via different devices must communicate in order to exchange data and launch applications on different devices. Discovery Module: used to discover remote services and devices User Profile: fundamental API for the application. It'll be used not only to fetch information about the social networks profile, but also to update statuses and perform all operations on profiles not belonging to webinos. 5 - Dissemination Plan In light of the intrinsic nature of the application, it should be promoted through the web, in order to reach the key audience. For instance some ways of promote it, would include: a dedicated demo website to show this all new way of tweeting a Facebook Page when Facebook users (tagged on tweets and received notification) will be navigated to get information and be redirected to application website a YouTube video with guidelines a promo Video where a user tweets about "anything" on a typical working day (e.g. from smartphone to car and then back home to watch football at night) (if possible) partners social media accounts and webisite

87 D5.1 Specification of Proof of Concept Applications page: 87 of 122 a promotional twitter account to invite users to try it for free collaborative tweeting promotion through webinos and partners channels pre loaded demo application into webinos platform potential partner sites to exchange ads with native devices implementation on non-traditional tweeting domains Future extensions: Twitter may be the beginning for a Social Media webinos application, as it is a simple, easily adapted and open platform, but any Social Network can be used to post user's information. Moreover, a cross platform notification system could be developed, thus the application will be able to extract audience (e.g. Android, iphone users) from other devices to webinos. Any future device that can be connected with webinos, can be addes on current application with minor changes. The whole concept is only to get data needed from another device or use another display for the application.

88 D5.1 Specification of Proof of Concept Applications page: 88 of 122 CHAPTER 5 PART C - webinos game station 1 - Introduction Overview The webinos Game Station (wgs) is a gaming portal aimed at casual video games. Its main purpose is to allow gamers to find games and other gamers, to play in multi-player mode. Gamers can either start closed sessions (if they want to play with their friends only) or open sessions (allowing everyone to see the invitation and join in for a game). For gamers, Webinos Game Station allows easy initiation of games sessions, especially since the webinos game station is not specific to a particular game, so the same interface can be used to start different games. For game developers, especially those of small and casual games, webinos Game Station removes the need for a function that allows users to discover other gamers. The application allows developers to concentrate on the game itself by using a webinos service for such a common need. wgs uses a widget-model in the sense that developers package their games, plus a specification of its behaviour, and let the wgs do the rest. Very simple games will exist only within webinos, more complex games may use some server on the internet to provide the gaming logic or additional resources. As far as the webinos game station is concerned, it does not make a difference whether the games themselves are packaged web applications or enhanced web sites, as long as the description on the webinos game server provides either the game URL or the packaged web application. wgs serves to illustrate specific webinos strengths: Device and service discovery User presence Connectivity In addition, wgs also offers: the above from a gaming perspective; e.g. connections based on the setting of (social or physical) proximity parameters abstracted group presence; it is aware of the conditions that are needed to play a specific game (for example, playing 'Skat' would always need three players with individual devices and an arbitrary number of 'table overview' on large TVs. A poker game might just need two players to get started, but allow up to six players)

89 D5.1 Specification of Proof of Concept Applications page: 89 of 122 resource management; applications and media are pushed to devices, based on device capabilities and presence of the owner and others Very interesting is the combination of these functionalities, as this results in the support of scenarios where the game (view) adapts to local conditions. For example, if player one on a poker game has a large screen and a mobile device, the mobile device would just use the card handling application. If the second player had just a mobile device, that device would need to show the cards as well as the current status on the 'poker table'. If player three sits alone at home, the cards might as well be displayed on the TV, as long as none of the other players can observe them. At a later stage, much of the functionality developed for wgs may be redesigned or repackaged as generic webinos user collaboration APIs and/or services Target Users & Audience The goal of this document is to give an idea of what the webinos Game Station is and what its scope is. It is meant for everybody who has an interest on playing video games that interact with other users. Especially the webinos team working on the wgs may use it as a live document and platform for discussion. Note that this document is in no way meant to be a design of the wgs or its games. wgs itself is targeted at future webinos end-users and developers, with the goal of introducing webinos and webinos principles respectively. The games that are to be developed as part of the demo target both TV and Mobile users. In the future, in-car players may be considered too. (Note: in-car game example and discussion removed, see history.) For demonstration purposes, webinos will provide at least a poker game. A (currently non-webinos) versions is currently available through one of the webinos partners will be adapted for webinos. There will also be a simple two player game (along the lines of Rock/Paper/Scissors or Tic-Tac-Toe) to allow the demonstration of the basic principles of the webinos game station during presentations at exhibitions. There are ideas for including a multiplayer game with a (conceptually) unlimited number of players to allow live demonstrations during conferences and other presentations in front of larger audiences. These games only represent the content webinos will provide as a project. The webinos games server will, obviously, also host and support games by other providers Target Domains and Devices As mentioned above, mainly Mobile and TV are addressed, plus the combination thereof. A tablet is considered a mobile device Overall relevance of the application to the results of the survey. Survey question Targeted users, devices and activities Q1: Please answer a few general questions Main target group is the age from 20 to 49,

90 D5.1 Specification of Proof of Concept Applications page: 90 of 122 about yourself Q2: How often do you use the following devices? Q3: In the future, what kind of devices would you prefer to use to access your personal information? Q4: What kind of activities/ applications do you use your devices for? Q5: In which situations do you access information and applications on your devices? representing 86% of the survey participants high frequency of use (weekly to daily) Mobile phones Laptop/Desktop computer below average frequency of use Tablets Car computer high relevance Mobile phones Laptop/Desktop computer medium relevance Tablets low relevance Car computer on a monthly basis: Play a game Among the six highest scoring answers were four answers that imply waiting (bus and train seats, train stations, airports, hotels and lounges), giving an indication that an easy system to start casual games with friends would be an appreciated service. (While 'In car as passenger, does not score quite as high,it also scores more than average interest here. Table 5 - webinos game station: Survey relevance for the application 2 - User Behaviour Description This section provides a general overview of how users interact with wgs and the games on it. The primary personas used throughout this section are Gloria and George, the persons involved are Gloria, Jack, Jill, Ian, Shaun and Sharon (with everyone but Gloria having the George persona). Gloria will do the invitations. The following examples are based on poker scenario, where two to six players can take part in a poker game.

91 D5.1 Specification of Proof of Concept Applications page: 91 of Requirements, Use Cases and User Stories User stories with related scope: WOS-US-1.1: Smart Device Integration WOS-US-2.1: Cross Domain App Store WOS-US-2.3: Converging Applications within and across Devices WOS-US-5.1: Context Sensitive Triggering WOS-US-12.1: Multiple Device Gaming Use cases referenced: WOS-UC-TA-1001: Virtual Device WOS-UC-TA-1004: Communication between webinos Applications WOS-UC-TA-3001: Application Push WOS-UC-TA-3006: Initiate a Game Use WOS-UC-TA-4010: Synchronization WOS-UC-TA-4011: Creating, Storing and Displaying Content on a Multitude of Devices WOS-UC-TA-5003: Installation and Update of webinos Applications WOS-UC-TA-6001: Adapting Application Interface to Different Devices WOS-UC-TA-6003: Content Adaptation WOS-UC-TA-7004: Finding Devices in Close Physical and Social Proximity WOS-UC-TA2-005: Authentication User Scenarios A little story: Gloria wants to play a game of poker with some friends. She connects to a game server, selects poker and opens a 'closed game invitation'. She then invites a couple of friends, sending them a 'secret link' to the session. Three of them connect to the server, which would be sufficient to start a game. However, Poker supports up to six players and it's more fun to play with a full table, so she opens up the game invitation. Any player looking for a seat at a poker table can now discover the game. After a minute, two more players have arrived. Gloria starts the game. (We're talking about a friendly game of poker here, so we don't really care about purchasing costs for the game or any revenue flow between the players in case someone wins.) From the little story above we can distinguish three roles, namely game initiator, invited players and other players. The UML figure below depicts some of their use cases. Note that UML use case diagram have no 'order' or 'sequence' in them; they represent high level functionalities that need be addressed when building the system.

92 D5.1 Specification of Proof of Concept Applications page: 92 of 122 Figure 30 - webinos game station: High level use case diagram Sessions can be either private or public, the choice is up to the Game Initiator to decide. Private sessions can only be populated through invitations. Public sessions can be populated either through invitations or by browsing the lists with public sessions, after which a player may 'join'. Game Initiators 'own' the session. They can send invitations to whom they want. Receivers of an invitation are Invited Players. They can accept invitations or just ignore them. Any player can obtain a list with public sessions by browsing. Handy for those who want to play but don't know what game or with whom. They can join any session that is in the list, as only public sessions will be on theirs. Invited Players that don't react on the invitation will still find the corresponding game on the list when they browse for games User and Application Behaviour In order to further examine the behaviour of the system, the story continues: The server determines the available devices: Gloria herself sits at home and uses the mobile phone as the input device, but she wants to see the full table (including a copy of her own cards) on her large TV. Jack, Jill and Ian are sharing a flat with a big TV. They want to see the table on the TV, but obviously not each others cards, which they see on their mobiles. Shaun sits at home at his PC and uses only this to show his cards, the full table and input his bets. Sharon is commuting on a train and only has her mobile with her. The server then checks whether all systems already have the poker application and (depending on the implementation) either distributes different versions of the app to those devices that don't have it already installed of just send the same app, but differently parameterized (e.g. Gloria gets a 'betting input only' version on her phone and a 'table and

93 D5.1 Specification of Proof of Concept Applications page: 93 of 122 own cards' version on her TV; Jack, Jill and Ian get a 'table' only version on their TV and a 'bet and see own cards' version on their mobiles, while Shaun and Sharon get 'everything on one device' versions.) The apps are installed and the game starts Assumptions, Limitations and Dependencies It is assumed that the webinos Game Station has access to discover the devices belonging to each of the users involved, and that it can (with optional user confirmation, based on policy settings) remotely install web applications on those devices. Games are provisioned by developers and/or administrators, but that is considered out-of-scope for the moment. 3 - Application Description Zooming in a bit on some of the UML use cases from section 2.2 gives more insight in what wgs should be capable of: Figure 31 - webinos game station: Abstracted Access design diagram Abstracted Access Design In this section, some interesting (and non-trivial) UML use cases are examined in more detail. Assumed that changes in the game status are propagated to all connected participants during their connection to the game server in a sensible manner.

94 D5.1 Specification of Proof of Concept Applications page: 94 of Connecting to Webinos Game Station Figure 32 - webinos game station: Sequence diagram - connecting When Gloria decides she is in for a game, she visits the game portal Selecting and creating a game Figure 33 - webinos game station: Sequence diagram - selecting and creating games

95 D5.1 Specification of Proof of Concept Applications page: 95 of 122 Gloria is shown a number of possible games. Upon selecting one of the games (Poker), she can adjust settings and start. (As an alternative, it is possible that the same screen allows other games to join.) Inviting a friend This can be achieved in many ways. One approach is to have the game server generate a unique globally addressable (and reachable) URI and have the game owner forward that to friends. Another approach is to provide a mechanism such that wgs can send the invites after the game owner has indicated how. For simplicity, the former is chosen for now. Figure 34 - webinos game station: Sequence diagram - Inviting to games

96 D5.1 Specification of Proof of Concept Applications page: 96 of Waiting for others to join Figure 35 - webinos game station: Sequence diargram - waiting for others to join The last notification is of course used to update Gloria's screen Starting a Game While doing the administration, the WGS also checks if game demands are met. For example, when a third friend joins in, the poker game becomes 'active'. With the examples above, this would be trivial Adjusting the Poker Game to a user Depending on available devices, a user is asked which combination of devices should be used. Depending on privacy settings and whether the game is already installed, the game either starts immediately or it is installed (after a possible permission prompt) and started then High-level API The webinos game server interface is provided as a web site by the webinos game server itself. On accessing the site, a user will provide credentials to the site (at least a nickname and an identification of the user's PZH). Updates on the session's state will be provided by events pushed to the client device.

97 D5.1 Specification of Proof of Concept Applications page: 97 of 122 Once the initiating user activates the game, the server uses discovery to find the available devices, maps them to the required sub-modules of the game (for poker this would be 'table view' 'card view' and 'playing interface') and suggests appropriate combinations to the user. The server then uses remote install to provide the packaged web applications to the devices and starts the game components Sequence diagram Includes user interaction, WRT and JavaScript API interaction. WRT is not focus of this section, more emphasis on JavaScript API. In UWE's terminology, it will be. Presentation Behavior Model Expected Platform Behaviour The webinos platform should list devices in near proximity of the individual users during the discovery phase. The platform should then allow, depending on individual policy settings, the remote installation, invocation and parameterization of packaged applications by the server.

98 D5.1 Specification of Proof of Concept Applications page: 98 of 122 Figure 36 - webinos game station: State diagram - high level behaviour Security, privacy & policy management The runtime needs to ensure that platform policies are observed when widgets are remotely installed and executed Local and Cloud Functionality Individual games may use or require cloud functionality, which is however not directly related to the operation of the webinos game station.

99 D5.1 Specification of Proof of Concept Applications page: 99 of Test Plan Application Test Plan At least one game will be provided (most likely this is going to be a poker game or something similar, since this provides the best choices about distribution of interfaces/displays and number of players limitations (minimum/maximum) - other games like Skat or Pong have more rigid fixed player numbers and less opportunities for game element distribution). The game will be started in various configuration of available devices, at least: One common table display (TV), individual cards and playing interfaces on multiple phones. Combined table, cards and interface on PC. Combined table, cards and tablet computer. Individual card display on mobile phones or even 'display only' device, but table and betting interface on shared tablet Platform Test Coverage Testing of remote application installation and invocation. Observance of privacy setting. Discovery of available user devices and their features via remote PZH query. 5 - Dissemination Plan Showcasing of game station (and associated games) and on-site demos to industry partners and at industry fairs (at least IFA, CeBIT, probably others). Once the wgs is available in prototype form, game development companies will be contacted and invited to use the service.

100 D5.1 Specification of Proof of Concept Applications page: 100 of 122 Appendix C1: Game metadata Game providers will need to give information to the game server in order to enable the server to find appropriate numbers of gamers with appropriate devices to launch the game. This information will be similar to a manifest file from a packaged application (and may for convenience copy elements from that description), but will require additional information, such as the minimum and maximum number of players. The format for this metadata file is most likely somewhat like this: (This is most likely not the final form, since some specifics might be updated later, but it should be close.) name This is the human-readable name for the game. description A human-readable description of the game. icon A custom icon for the game. minplayers Minimum numbers of players for the game as a number. If minplayers is missing, minimum number is assumed to be one (player). maxplayers Maximum numbers of players for the game as a number. If maxplayers is missing, maximum number is assumed to be unlimited. If a maxplayer number is given and the number of players for a session is reached, game will be distributed and started immediately. bestnumberofplayers Number of players a game is best suited for. Often that will be the maximum number of players, but there may be reasons to be explicit in the game (such as having primary and secondary characters, with secondary players less interesting to play) or resulting from the implementation (like experiencing severe lag with more than 50 participants in dance game). The bestnumberofplayers is mainly for informative for the players and will probably not have any direct effect on the server. configurations This describes the possible game configurations. For most simple games there will be only one configuration, but to showcase the capabilities of webinos, we should allow more complex scenarios.

101 D5.1 Specification of Proof of Concept Applications page: 101 of 122 configuration This describes a single possible game configuration. Players need to select one of the possible configurations to play. element One of the elements in a configuration. elementdescription This is the human-readable description for the element. elementrequired This can have one of these three values "perplayer" (required for each individual player), "pergroup" (each player in a group needs to have access to the element, but it can be shared - usually used for info, score or overview screens) and optional. elementexclusive This has either value 'true' or 'false', depending on whether this element can be combined with other elements on the same device. For example, a full screen application might not be usefully combined with another application. In most cases (presumably), elements will be exclusive if they have specific application packages, while elements that use the same (parameterizable) application package are likely to be nonexclusive. elementurl Access to the element that fulfills the function. This can either be a web link for a web based game or the link to a packaged web application containing the game. Note that this does not need to be different for individual elements. If the same widget can perform various functions, then all elements of a configuration might point to the same packaged application, elementrequirements These are the requirements that need to be matched on a device in order to be able to execute the element there. This is not finalized, but it is assumed that this can include JavaScript code that runs within the webinos game station client on a user's device (following the local privacy settings there) and returns a 'true' value when the requirements are met.

102 D5.1 Specification of Proof of Concept Applications page: 102 of 122 Appendix C2: Game metadata example A description file for poker may look somewhat like this: 1 <name>poker</name> 2 <description>description a friendly poker game among friends - no real money involved, but lot's of fun.</description> 3 <icon> 4 <minplayers>2</minplayers> 5 <maxplayers>6</maxplayers> 6 <configurations> 7 <configuration> 8 <element> 9 <elementdescription>everything on one screen</elementdescription> 10 <elementrequired>perplayer</elementrequired> 11 <elementexclusive>true</elementexclusive> 12 <elementurl>pokergame.wgt</elementurl> 13 <elementrequirements> 14 (screen.width>600)&&(screen.height>400)&& (mouse.available() keyboard.available())) 15 </elementrequirements> 16 </element> 17 </configuration> 18 <configuration> 19 <element> 20 <elementdescription>overview screen</elementdescription> 21 <elementrequired>pergroup</elementrequired> 22 <elementexclusive>true</elementexclusive> 23 <elementurl>pokergame.wgt</elementurl> 24 <elementrequirements> 25 (screen.width>600)&&(screen.height>400) 26 </elementrequirements> 27 </element> 28 <element> 29 <elementdescription>card display</elementdescription> 30 <elementrequired>perplayer</elementrequired> 31 <elementexclusive>false</elementexclusive> 32 <elementurl>pokergame.wgt</elementurl> 33 <elementrequirements> 34 ((screen.width>320)&&(screen.height>200)) ((screen.width>200)&&(screen.height>320)) 35 </elementrequirements> 36 </element> 37 <element> 38 <elementdescription>input device</elementdescription> 39 <elementrequired>perplayer</elementrequired> 40 <elementexclusive>false</elementexclusive> 41 <elementurl>pokergame.wgt</elementurl> 42 <elementrequirements> 43 (mouse.available() keyboard.available()) 44 </elementrequirements> 45 </element> 46 </configuration> 47 </configurations>

103 D5.1 Specification of Proof of Concept Applications page: 103 of 122 Chapter 5 PART D - webinos travel 1 - Introduction Overview Webinos travel is your digital travel assistant before, during and after a business as well as a leisure trip. While planning your trip, you can get information about relevant points of interest for your destination or you can add your own POIs to your travel itinerary. You can invite friends to join your travel or they can assist you while planning, by suggesting Points Of Interest (POI) or a certain route to your destination. While on the go, you will be guided to your POIs and you may receive suggestions based on your interests. You can decide to share your geolocation with your travel mates, so you won't get lost. Similarly you can share the location with your friends, so they know you are having a good time. Pictures taken with your mobile phone can be added to POIs on the go and can be upload to your social profiles. After a trip you can browse your travel log book containing information about the taken route and visited POIs, including the pictures you have taken. Furthermore, you can review your carbon footprint or simply share your experience with friends Target Users & Audience The target user is everybody who is planning a travel, either for pleasure or for business. Webinos travel targets an audience who is seeking a seamless trip planing using different devices (smartphone, pc and ivi-system). Furthermore, it enables a geographically separated group of people (circle of friends, sales representatives and back office) collaborate on a collective travel plan. From the personas presented in the deliverable D2.7: User expectations on privacy and security the most relevant to webinos travel are the following: George for planning family vacations Gloria for organizing trip with friends Helen for managing her daily life Justin for organizing trip with friends Peter for managing business travels

104 D5.1 Specification of Proof of Concept Applications page: 104 of Target Domains & Devices During the planning phase the target domains are television, PC and mobile phones. During the travel phase the main domains are addressed in car and mobile phone, but also television and PC can apply (for example the television of the hotel room). The following table illustrates how the different domains are involved in webinos travel. Mobile phone Television PC In-Car Plan Travel edit travel and POIs, handle invitations use television as external display in conjunction with mobile edit travel and POIs, handle invitations During Travel log position perform last steps navigation by adding taken pictures to POI, broadcast location, plan next day use television as external display in conjunction with mobile browse travel plans, request guidance to POIs, logging relevant trip data for logbook, calculate CO2 footprint, broadcast location After Travel analyze, rate and publish trip; present travel log book with pictures taken during the travel present travel log book with pictures taken during the travel analyze, rate and publish trip; present travel log book with pictures taken during the travel Table 6 - webinos travel: Target domains vs. activity Overall relevance of the application to the results of the survey. Survey question Targeted users, devices and activities Q1: Please answer a few general questions about yourself Under 20 up to 60 and over Q2: How often do you use the following devices? average frequently in use: Mobile phone Laptop computer Television average less frequently in use: Tablet computer, Pad, Desktop computer average not frequently in use: Car computer and displays

105 D5.1 Specification of Proof of Concept Applications page: 105 of 122 Q3: In the future, what kind of devices would you prefer to use to access your personal information? Q4: What kind of activities/ applications do you use your devices for? Q5: In which situations do you access information and applications on your devices? Q6: In which situations would you like to have more access to relevant information or applications on your devices? medium to high relevance: Laptop computer Mobile phone Tablet computer, Pad, Desktop computer less to medium relevance: Television Car computer and displays on a weekly to daily basis: Search the web Access social network Search for local information on a monthly to weekly basis: Use a map, navigate, take photos and share with others. Travel informations. on a weekly to daily basis: At home. on a monthly to weekly basis: Into the street while walking. on a rarely to monthly basis: Into a café, a bar or a pub. Into a restaurant. Into a library and into a museum. highly relevant: quite relevant: In hotels and lounges. When nearby interesting places and objects. While in libraries and museums, into a café, a bar or a pub or in a car as passenger. medium relevance: In pedestrian areas and in a car as driver. Table 7 - webinos travel: Survey relevance for the application

106 D5.1 Specification of Proof of Concept Applications page: 106 of User Behaviour Description User Scenarios Scenario 1 (the one described in the Webinos video): George and his wife, while watching television, see an advertisement of skiing holidays. They like the idea and decide to book it immediately by using their mobile phone. Once booking is done, they use their laptop/mobile to plan the trip. On the day they leave, the on-board navigation system of their car already knows where to go. During the trip, Victor, their child, is entertained using another app (Kids in Focus? Game station?). Once they arrive at the destination, their mobile phone will guide them to their hotel so they can immediately start skiing. Scenario 2: Justin is planning a 4 days vacation and decides to go to Paris and visit the city. He launches the webinos Travel app on his PC. He checks the POIs available and adds some of them to his travel. He wants to visit also the Musée Picasso but he can't find it in the available POIs; so he creates a new one and adds it to the itinerary. He remembers his friend Gloria, who told him about a good restaurant in Paris, so he checks his friend's POIs and adds the restaurant to the travel. Then Justin invites Gloria and additionally Charles and Jessica to join him. Charles sees the invitation on his mobile phone and accepts it. Gloria sees the invitation on his television and accepts it. She checks the travel planning and suggests to add two more POIs to the travel plan. Justin accepts the suggestions. Jessica receives the invitation on her phone, she realizes that she is already busy in that period and refuses the invitation. On the planned day, the travel begins using Justin's car. They are guided to their hotel in Paris, and then they start visiting the city as planned. From the television of the hotel room Justin, Charles and Gloria can review their travel plan and receive advertisements and discounts for restaurants, museums, etc. All of them decide to share their position with other travel mates, so they won't get lost. While visiting the city they can update their own POIs (or social profiles) with pictures/descriptions or add new POIs and events. In general the idea is that a person can: create, edit or select a travel plan edit or add new POIs to a travel plan invite friends to join your travel add data to a user's calendar get assistance during the trip

107 D5.1 Specification of Proof of Concept Applications page: 107 of 122 suggest POIs to be added to the trip plan share locations and see a friend's location install the app and see the travel details on a hotel television, and remove the app when leaving update the own social profile during the travel log the travel (route, visited POIs, carbon footprint, gas costs) and do a presentation about the travel logbook Optional features receive ads based on your interests the application may suggest other POIs based on user's profile get and give recommendations about the various points of interest or events once the destination is reached, get info about how to move in the city (parking, underground, public buses, taxis, bike sharing,...) and which are the points of interest (restaurants, museums, ski pistes,...) or events Requirements, Use Cases and User Stories User stories with related scope: WOS-US-1.1: Smart device integration WOS-US-2.3: Converging applications within and across devices WOS-US-3.1: Content sharing service WOS-US-3.3: Social event sharing WOS-US-5.1: Context sensitive triggering WOS-US-8.1: The holiday planner WOS-US-8.2: Seamless navigation Use cases referenced: WOS-UC-TA1-001: Virtual device WOS-UC-TA1-006: Pairing a new device to clone settings WOS-UC-TA1-008: Webinos federation WOS-UC-TA2-005: Authentication WOS-UC-TA4-010: Synchronization WOS-UC-TA4-013: Dynamically sharing content with other users in a controlled manner WOS-UC-TA4-020: Content sharing and storage WOS-UC-TA5-006: Removal of application WOS-UC-TA5-007: Sync application state WOS-UC-TA6-001: Adapting application interface to different devices WOS-UC-TA6-003: Content adaptation

108 D5.1 Specification of Proof of Concept Applications page: 108 of 122 WOS-UC-TA7-005: Seamless session transfer between devices WOS-UC-TA8-001: Receiving local messages and alerts Use case diagram: Figure 37 - webinos travel: High level use case diagram User and Application Behaviour Diagram Use-case: Create Travel Use-case: Review travel plan Figure 38 - webinos travel: User and application behaviour diagram - Create travel

109 D5.1 Specification of Proof of Concept Applications page: 109 of 122 Figure 39 - webinos travel: User and application behaviour diagram - Review travel

110 D5.1 Specification of Proof of Concept Applications page: 110 of 122 Use-case: request guidance to a POI Figure 40 - webinos travel: User and application behaviour diagram request guidance to POI Assumptions, Limitations and Dependencies Assumptions: users have mobile phones and a webinos enabled car; probably they also have a television and/or a pc; the application keeps a db of user POIs synchronized on all his devices; the travel data is synchronized among all devices belonging to users taking part in the travel.

111 D5.1 Specification of Proof of Concept Applications page: 111 of 122 Limitations: since the user should be geolocated, for demo purposes the travel part should show POIs near the demo location; lack of EPG API for the television it is used primarily as a display device (for booking scenario in User Story 1). Dependencies: a map provider is needed; a POI provider is needed; an external source providing messages/advertising is also needed. 3 - Application Description Abstracted Access Design The following diagram illustrates the functionality of the UI. Figure 41 - webinos travel: Abstracted access design diagram High-level API Webinos travel focuses on using the following webinos APIs: