PROJECT PERIODIC REPORT
Grant Agreement number: 610510
Project acronym: Prosperity4All
Project title: Ecosystem infrastructure for smart and personalised inclusion and PROSPERITY for ALL stakeholders
Funding Scheme: Collaborative Project – Integrated Project (IP)
Date of latest version of Annex I against which the assessment will be made: 03 February 2015
Periodic report: 1st ■ 2nd □ 3rd □ 4th □ 5th □ Period covered: from Month 1 (February 2014) to Month 12 (January 2015)
Name, title and organisation of the scientific representative of the project’s coordinator1: Matthias Peissner, Dr.-Ing. Fraunhofer IAO
Tel: +49 711 970 2311
E-mail: [email protected]
1 Usually the contact person of the coordinator as specified in Art. 8.1. of the grant agreement Declaration by the scientific representative of the project coordinator1
I, as scientific representative of the coordinator1 of this project and in line with the obligations as stated in Article II.2.3 of the Grant Agreement declare that:
. The attached periodic report represents an accurate description of the work carried out in this project for this reporting period;
. The project (tick as appropriate):
■ has fully achieved its objectives and technical goals for the period; □ has achieved most of its objectives and technical goals for the period with relatively minor deviations2; □ has failed to achieve critical objectives and/or is not at all on schedule3.
. The public website is up to date.
. The financial statements which are being submitted as part of this report are in line with the actual work carried out and are consistent with the report on the resources used for the project (section 3.6) and if applicable with the certificate on financial statement.
. All beneficiaries, in particular non-profit public bodies, secondary and higher education establishments, research organisations and SMEs, have declared to have verified their legal status. Any changes have been reported under section 5 (Project Management) in accordance with Article II.3.f of the Grant Agreement.
Name of scientific representative of the Coordinator1: Matthias Peissner
Date: .01/ April / 2015
Signature of scientific representative of the Coordinator1:
2 If either of these boxes is ticked, the report should reflect these and any remedial actions taken. 3 If either of these boxes is ticked, the report should reflect these and any remedial actions taken.
2
1. PUBLISHABLE SUMMARY Prosperity4All is a 4 year project to create a development infrastructure that would make it easier and less expensive for diverse companies, organizations, and people to create, market, and support accessibility solutions (both assistive technologies/services and mainstream features) for people facing disability, literacy, digital literacy or ageing related barriers to the use of digital products and our digital future.
Prosperity4all is part of an integrated and global effort to create a Global Public Inclusive Infrastructure (GPII.net). This infrastructure will be a paradigm shift in e-Inclusion through facilitation of one-size-fits-one digitally-inclusive solutions. The three major functions of the Global Public Infrastructure (GPII) are: • To provide the infrastructure to make it easy for individuals who have difficulty in using ICT to be able to discover what features or technologies they need in order to make ICT usable for them. • To provide an infrastructure to allow users to use their needs and preferences sets to cause any software/ devices/ media services to automatically change into a form that they can use instantly and without their understanding how to do it. • To provide the infrastructure that can make it easier, less expensive, and faster to innovate and then move these innovations through development and to markets internationally; as well as to enable the development of entirely new types of accessibility solutions and delivery systems.
The first step of this effort was the FP7 Cloud4all project that focused on creating an “auto- personalization from preferences” (APfP) capability for AT and accessible mainstream products.
Phase II is Prosperity4all which focuses on developing the infrastructure to allow a new ecosystem to grow that enables a broader range of developers to create, market and support products internationally, more easily and at lower cost. Of particular interest are products that can address the needs of low incidence groups at the tails and tails-of-tails of population distributions.
In the first twelve months of the project, the major management, communication and collaboration procedures of the overall project, sub projects and work packages have been set up. The project has been made visible to the scientific community and the general public by press releases, the project website (www.prosperity4all.eu), extensive dissemination materials, and the appearance at the HCII 2014 conference with an own GPII Mini Conference and an exhibition booth.
A special focus in the first project phase has been set on SP 1 » Economic Model«. This Sub Project will be a key for the project success as expressed in the project objectives. The first deliverable D101.1 »Documented process for modelling and analysis and report format for reporting back to project« has set the ground for the current analyses of demand-supply chains, major stakeholders and their specific needs. Two further SP 1 deliverables are currently being finished: D101.2 presents and discusses potential business models to be used in the P4A ecosystem. It outlines the P4A platform as a cross-channel ecosystem, actor-driven with high levels of coproduction and participation. D102.1 describes the schedule for the remaining modelling and design activities in SP 1 and documents a communication plan for engaging partners and stakeholders in participating in these activities.
3
In Sub Project 2 the technological infrastructure is being built. SP 2 provides the technical platform for consumer-developer relations, tools and building blocks that enable the efficient provision and development of successful access solutions and accessible mainstream IT services. A first step in this SP was to modularize tools and building blocks to enable integration into a common GPII architecture and technical framework as well as existing product implementations. To prepare the adoption of the tools and modules by implementers, documentation and mock-up versions were collected and published in the DeveloperSpace Repository. Moreover, concepts, designs and first prototypes for the infrastructural components of the DeveloperSpace, including the Unified Listing and MarketPlace have been developed. Finally, a first prototype of the Assistance-On-Demand (AoD) service platform has been developed. This platform supports user and service supplier registration and flexible service search.
In Sub Project 3 the technological infrastructure will be proven by implementing real-world applications with the provided tools and technologies. This work package is dependent on SP2 and was therefore started in Month 6. A first mapping of tools and technologies from SP 2 to the implementations in SP 3 has been completed. Time plans for the provision of SP 2 artefacts have been coordinated between SP 2 and SP 3 to ensure proper uptake and evaluation by SP 3 implementers.
Sub Project 4 is all about Evaluation. Early in the project, evaluation procedures and methods have been prepared and planned. Evaluation criteria and phases have been defined. A strong emphasis is put on extending the evaluation focus beyond the traditional technical validation and usability assessment to measuring success in the broader economic sense. Close collaboration and exchange of ideas and requirements between SP 1 and SP 4 have been established to align the evaluation criteria and procedures (SP 4) with the economic objectives and strategies (SP 1) and the SP2 and SP3 development teams in order to set which mapped developments will be available for first iteration with implementers.
4
2. PROJECT OBJECTIVES FOR THE FIRST YEAR
2.1. Overview Major objectives of the first year of the Prosperity4All project are:
Organizational • Get all teams in place and fully briefed • Create both 1st year and fast-start targets • Create the sub-teams and cross-work package teams • Install mechanisms and procedures for efficient communication and collaboration • Plan and carry out dissemination activities to gain attention by relevant target audiences in academia, technology and business; including the development and provision of high quality dissemination materials.
Programmatic • Set up the process for economic modelling and analysis as a basis for the prosperity-based ecosystem for inclusive design • Identify, select and revise candidate market models and strategies for sustainable prosperity • Develop concepts, designs and initial prototypes for the overall architecture and the infrastructural components like Unified Listing, MarketPlace and DeveloperSpace including approaches for gamification. • Collect and create an extensive repository of alternative input, output and processing modules, components and adapters to facilitate development of assistive technologies and accessible interfaces. • Design a generic open source infrastructure that supports the current and emerging needs for Assistance-on-Demand services. • Identify feedback and feedforward information needs and preferred modalities for engaging customers over time to maximize the satisfaction of the consumers and developers. • Identify the SP2 tools to be used by the SP3 teams and those targeted at outside developers • Establish timelines, priorities and critical paths for the developments of SP 2 tools and SP 3 implementations. • Specify the conceptual framework for evaluations with end users and implementers and identify the evaluation methods and procedures • Plan evaluation cycles for iterative testing • Define technical validation plans for tools and applications developed in the project.
2.2. Follow-up of previous review (if applicable) Not applicable
5 3. WORK PROGRESS AND ACHIEVEMENTS DURING THE FIRST YEAR
3.1. Progress overview and contribution to the research field
3.1.1. SP1 Economic Model SP1 has investigated the range of stakeholders, the variety of needs or demands, the value proposition for these stakeholders, the design of the diverse entry points onto the platform that will draw each stakeholder group to the platform and the value chains that will enable successful transactions. This informs the work of the other sub projects by providing design specifications for needed functionality. These findings will be refined through future iterations.
The SP 1 team has articulated an inclusive design process within 102.1 that will be paired with a co- design approach with stakeholders participating in each stage of design. The inclusive design practice ensures that each stage of design research is concerned with empowering end users, with building the most inclusive platforms, and with designing in an integrative, multi-modal way. This approach has begun with extensive research into actors within the platform, their value propositions and entry points.
Although much is written in theory about these economic models, this is the first time that anyone has set out to try to build an ecosystem based on them, especially in a social-technical field. At this time the contributions have been in applying and developing these concepts to apply to this area. Most of the contribution however will come in the trial and refinement that will result during the project.
During the reporting period, the WP101 deliverables were completed as planned. The other deliverables in WP102 and WP103 have been restructured in light of resource changes among the P4A partners. The new deliverable schedule below reflects the modifications to the Description of Work approved February 19, 2015 by the European Commission.
The deliverables have been reprioritized so that the changes to resources and milestones will have the least impact on the other SPs while still achieving the project goals. The table below shows the deliverables that will be created following this update. The first (D102.1) informs the other project team members about the iterative process that will be used for economic and design modeling and documentation. D102.2 and 103.2 are composite deliverables that include material originally in WP102 and WP103 – this deliverable will be updated every 6 months from Month 18 through Month 36, showing the evolution of the economic and design work. D103.2 is a final deliverable of the final wireframes for the various component parts of the Prosperity4All system.
Deliverable Final Version Due D101.1 Month 12 D101.2 Month 13 D102.1 Month 13 D102.2 Month 18 (1st rev) D103.1 Month 18 (1st rev) D103.2 Month 42
D101.1 and 101.2 have been left as-is in the original DOW document. JIBS has completed work toward those two deliverables as outlined below.
6 3.1.2. SP2 Building the technological infrastructure This sub-project focuses on designing and creating the infrastructure that will allow the new ecosystem to develop. During this first period (M1-M12) the teams focused on defining initial requirements for the design and development of the DeveloperSpace, ensuring all tools are harmonized and interoperable (this one is planned to be ready for trial during year 2). The Unified Listing was extended to include mainstream products, and architectural requirements were defined for both the database and secure payments infrastructures. Initial findings on accessible gamification have been achieved and will feed into requirements of the P4A the infrastructure and ecosystem.
During this first year, existing AT interface modules and novel technologies were identified, analyzed and are currently being integrated in the DeveloperSpace so implementers can begin evaluating APIs and modules. A decision was made to support flexible development approaches, in order to maximize accessibility support and ensure adaptive user interfaces (individualized and accessible). Initial developments and mock-ups have been put into place during year 1. Additionally, external modules and extensions for media transformation (including media types such as flv, mp3, and html5 audio files) have been integrated and/or synced (Kaltura, Amara, Vimeo and others) and the requirements for easy crowd contribution strategies and technologies (i.e. subtitles and side to side editing) were specified.
A first version of the AoD service platform prototype that supports user and service supplier registration and flexible service search has been made available for technical validation and testing with users during the first evaluation iteration. Initial user studies have been carried out. They served to all WPs to help guide their needs and requirements for the technical developments. The creation of an initial set of personas, scenarios and requirements helped define the requirements for the tools to be developed, and channels or methods to be used later in the project.
The main contribution to the research field so far relates to providing a universal platform for tools and components for accessibility. The developed architecture and harmonization activities allow researchers and developers to integrate their components into a bigger ecosystem and provide interfaces for interoperability with other technologies. The DeveloperSpace extends the reach of their components and fosters the uptake by other developers. The public DSpace Listing helps developers to find existing components that they can use for their own implementations.
3.1.3. SP3 Proving the infrastructure with real world applications Work in SP3 started in Month 6 for all 3 relevant work packages. This subproject builds on results and technologies from SP2 and includes a number of tasks in each WP, each of which addresses (in most cases) a different real-world product. It is worth noting that, even though SP3 deliverables are not meant to deliver any innovation per se compared to the current state-of-the-art (other than improved user interfaces and improved accessibility), thanks to the integration of SP2 results, they significantly contribute to verifying and validating the innovations developed by the rest of the Prosperity4All project.
A major part of the SP3 work during the period focused on creating a mapping between SP2 components/results and each SP3 product/implementation for all SP3 tasks. All SP3 teams studied the resources available in the DeveloperSpace (tools, infrastructures and guidelines) and established an understanding of what is being offered in each SP2 deliverable. The Dspace (including SP2) offerings were matched against the technical specifications of each SP3 implementation addressed in the different tasks of WP301, WP302 and WP303 and each SP3
7 implementation team selected those Dspace tools that are most beneficial for the respective product to be integrated during the project lifetime. The results of the initial mapping between SP3-SP3 outcomes can be found at https://docs.google.com/document/d/1wG-lXsgQ- cEiTMu8sw6tENn60o9Hc7OBXFHuxxv9TEw/edit. This is a live document that is being kept continuously updated.
All this activity was facilitated through several face-to-face meetings (e.g. at HCII in Crete, June 2014, project plenary meeting in Stuttgart, February 2015, several bilateral meetings between teams), as well as conference calls, email communication, written documents, etc. As detailed in each WP/Task progress report, several SP3 teams have already started re- implementation of their products and integration of SP2 resources into their products (e.g. FlashWords, GuadalInfo, Sociable, etc.) so it is expected that adequate integrated or semi-integrated SP3 prototypes will be ready for the 1st testing iteration with implementers that will be carried out with selected internal (SP3) teams.
3.1.4. SP4 Evaluation Sub Project 4 is all about Evaluation. Early in the project, evaluation procedures and methods were prepared and planned. Evaluation criteria and phases have been defined. A strong emphasis is put on extending the evaluation focus beyond the traditional technical validation and usability assessment to measuring success in the broader economic sense. Close collaboration and exchange of ideas and requirements between SP 1 and SP 4 have been established to align the evaluation criteria and procedures (SP 4) with the economic objectives and strategies (SP 1) and the SP2 and SP3 development teams in order to set which mapped developments will be available for first iteration with implementers.
3.2. Work packages progress
3.2.1. Work Packages of Sub Project 1
WP 101 – Economic Modeling of Marketplace Infrastructure
Objectives for the period • Identify, select and appropriately revise economic modeling tools that are applicable to the proposed ecosystem, • Gather marketplace data that is applicable to the proposed ecosystem and identify data gaps, • Fill gaps in marketplace data, • Develop and test market strategies to address the common challenges of the proposed complex two-sided network (including the chicken and egg problem, ghost town problem, critical mass problem and double user problem), • Determine the effect and impact of marketplace design decisions to help optimize the design of the Prosperity4All infrastructure, • Provide the design criteria for the overall infrastructure and identify processes that must be supported by the ecosystem • Explore, design and evaluate potential sustainability models for the platform.
Progress and significant results - Task 101.1 and 101.2 WP 101 is slightly delayed. It will be finished in Month 15 (instead of Month 12).
8 D101.1 has been completed in June 2014. D101.2 is currently in progress and has been submitted for internal review.
The re-allocation of resources and the re-definition of the WP have influenced the WP and its original plan. This has, however, not affected the quality of the work in progress nor will it affect the final quality of the deliverables. o Publications: º Jutta Treviranus, Colin Clark, Jess Mitchell, Gregg C. Vanderheiden, Prosperity4All: Designing a Multi-Stakeholder Network for Economic Inclusion, HCII 2014, Crete º Gregg Vanderheiden, Jutta Treviranus, Colin Clark, Matthias Peissner, Gianna Tsakou. Prosperity as a Model for Next-Generation Accessibility, HCII 2014 Crete o After participating in the kick-off meeting in Stuttgart, JIBS started working on deliverable #1, D101.1, laying out the general outline of JIBS’ contribution to WP1 in respect to a list of feasible business models for the P4A platform that would go into deliverable #2, D101.2. o To better address the different requirements in expertise, work for D101.2 was internally divided in three main streams, one connected directly to the business models, one connected to the stakeholders, and one connected to the general overview and maintenance of the whole deliverable. o When work resumed, meetings were scheduled and a draft document for D101.2 was opened up on Google Docs and made available to partners. o In early October, a workshop was also run with external guest Simon Norris, CEO of design firm Nomensa (UK), to gather feedback on P4A and D101.2 itself. A few suggestions were incorporated.
Main Results: o D101.1’s primary role is to provide a list of candidate business models for the P4A platform. These models will be used by later packages to inform the features and requirements of the platform based on a variety of actors who will participate in it. Our approach has been stakeholder and user-oriented, providing potential business models that these stakeholders will apply to the services they will deliver through the platform. o The report is divided into five parts: Part I deals with business models, value creation, taxonomies for business model categorization, and the candidate list. Part II deals with stakeholders and actors. Part III deals with P4A as a cross-channel ecosystem. Part IV deals with user scenarios and Part V draws a few conclusions and offers a bibliography. o We learned from the report that it is necessary to analyse the terminology used. This is because the concept of business models is not suitable for organizations that are classified as non-profit organizations o We also learned that we will need to classify the services in development in order to connect them to some specific business model. o Different stakeholders on the platform may engage with actors in many different ways, so a single business model will not be appropriate for all instances of interaction. We suggest in the report that the P4A platform should strive to provide support for different business models that may be suitable for the goals of the different groups of actors that will be active on it.
Schedule and achievement of critical objectives All critical objectives for the tasks of WP101 are on their way. WP 101 is slightly delayed. D 101.2 is now within the internal review process and will be finished by M15 (instead of M12). Nevertheless, we expect no serious effects on other activities within the project.
9 Deviations from work plan and corrective actions None – except for the slight delay. This delay doesn’t affect Prosperity4All as a whole. It will be compensated within the second reporting period.
Statement on the use of resources Due to delays in start resulting from the LSEE withdrawal, WP 101 is not finished. Reports will be finished within M14. There will be a corresponding shift in PMs from year 1 to year 2. (Spending is in line with progress but both are a bit behind and catching up in year 2.)
WP 102 – Detailed Demand-Supply Transaction Modeling
Objectives for the period D102.1 is a new deliverable that was not included in the original project plan, and was added as part of the February 2015 amendment to the DOW. D102.1 is meant to serve an integrative role among the primary members of SP1. This deliverable informs the other project team members about the iterative process that will be used for economic and design modelling and documentation.
Progress and significant results JIBS and IDRC have been working on the 102.1 deliverable. It is currently within the internal review process and will be delivered by the end of Month 14.
The first iteration of D102.2 and D103.1 will be delivered in month 18, providing the necessary economic and design guidance and direction for the SP1 team and the other project teams. This guidance will take the form of specific economic, business, marketing, and payment (currency) models that would need to be supported by Prosperity4All and high-level design and architecture documentation supportive of those economic models and reflective of the user requirements of Prosperity4All. The IDRC started the design work for the Month 18 deliverable in year 1. The following are activities the team began in Year 1: o Identified actors, points of entry, value propositions and more (with direct input from the 101.x deliverables) http://wiki.fluidproject.org/pages/viewpage.action?pageId=42008847 and http://wiki.fluidproject.org/display/fluid/Value+Propositions+and+Functionality o Created mind maps and environmental scans of the various P4A components; this research represents the first step towards designing wireframes and concrete user interfaces. http://wiki.fluidproject.org/download/attachments/42009032/Value Exchange Map.jpg?version=3&modificationDate=1422891864877&api=v2 o Produced a draft flow chart of user “flows” through the system:
10 http://wiki.fluidproject.org/pages/viewpage.action?pageId=42009237 o Designed use cases and scenarios to explore different aspects of the P4A platform, how it will be used, and the services it can offer. º Use cases: http://wiki.fluidproject.org/display/fluid/P4A+Use+Cases º Scenarios: http://wiki.fluidproject.org/display/fluid/Use+Cases+and+Scenarios Schedule and achievement of critical objectives D102.1 is will be submitted by the end of Month 14. This deliverable is the first deliverable being submitted since the amendments to the DOW and is an important clarification of how the SP1 team will work together. The writing team has been taking care and time to ensure all SP1 members are involved in giving feedback to the deliverable. To improve this feedback and collaboration process for the future, D102.1 includes a communications plan that will help make this process more efficient and effective.
Deviations from work plan and corrective actions • LSEE – the major partner in WP 102 was struggling to resolve legal and financial issues within FP 7 projects. From the beginning of the project, they were in contact with the URF Validation services in order to raise their funding rate (from 50% to the 75% for SMEs). LSEE has now withdrawn from the project as a partner. • JIBS has taken on a bigger role with respect to the market and currency deliverables to make up for the loss of LSEE as a partner. • A bid for delayed submission of the upcoming deliverable D 102.1 »Portfolio of candidate demand-supply chains« has been accepted by the Project Officer to allow them to catch up on the missed work. • The IDRC and JIBS submitted and received approval for a modification to the DOW • The IDRC and JIBS are proceeding with the deliverables as defined in the DOW modification approved February 19, 2015 by the European Commission • Per the changes to the DOW, JIBS and IDRC will help to provide all necessary information from SP1 to other depending activities, such as Evaluation framework (WP 401) and technical development activities in SP2.
Statement on the use of resources There are no significant deviations between actual and planned person-months for the partners contributing to WP102. There is a slight shift of work from year 1 to year 2 due to the LSEE problem and transfer of work to JIBS.
11 WP 103 – Ecosystem Requirements WP 103 has started in M7.
Objectives for the period • Synthesize the results of WP101 –WP102 to derive design specifications for the project delineating the necessary services, infrastructure and supports required to enable the growth of the ecosystem. • Identify evaluation criteria based on determinants of a prosperous and sustainable marketplace for use in WP 405. • Identify overall value propositions for main stakeholder groups • Identify good practice guidelines for internal project use as they pertain to business practices, infrastructure design and user experience design for required transactions. • Outline initial good practice guidelines for external use.
Progress and significant results
Task 103.1 Requirements, success criteria and associated technical specifications D103.1 will be delivered Month 18 and will build upon the early design work outlined above from WP102. The objective for this deliverable during the given period has been to build upon early work from WP102. The continuation of that work will yield a number of iterations that will culminate in D103.1. The work has been structured and planned to deliver designs to the other SPs, aligning that roadmap with the overall project plan and timeline of deliverables.
Task 103.2 Final review of specifications D103.2 will be delivered Month 42 and will reflect the evolution of the design solutions from early design research to generating innovative solutions to delivering high-fidelity wireframes. The objective for this deliverable during the given period has been to plan the design work, creating a strategy of iterative improvements on designs that will culminate in the final wireframes in delivery of D103.2.
Schedule and achievement of critical objectives All critical objectives for the tasks of WP103 are on schedule. All critical objectives for the period have been achieved.
Deviations from work plan and corrective actions None
Statement on the use of resources No deviation. The EC resources have been used as planned. JIBS has supported the project with some additional work-force consisting of three doctoral candidates that have collaborating to perform the stakeholder analysis and the business models. They have worked under 3 months 20 % each. The IDRC is on schedule with the allocation of resources for the various WPs within SP1.
12
3.2.2. Work Packages of Sub Project 2
WP 201 – System Architecture and Unified-Listing/Marketplace
Objectives for the period • Design the Prosperity4All architecture, technical framework, and collaborative ecosystem • Gather use cases to inform the design of the DeveloperSpace and MarketPlace • Prepare the adoption of gamification and crowd sourcing approaches to diverse aspects of the Prosperity4All infrastructure • Study the relevant state-of-the-art and design a secure payment infrastructure that will enable the on-line payment of (multiple) services following different charging models on behalf of the end-users and, equally importantly, will allow crowd-sourced financing of R&D, supporting micropayments and bids. (This work will be reported in D201.1, due M18)
Progress and significant results
Task 201.1 Architecture and DeveloperSpace (incl. Localization) This activity includes the establishment of architectural patterns, idioms and a scalable, forward- looking framework to ensure that P4A tools are closely harmonized and interoperable. The DeveloperSpace involves the establishment of a network of contributors and the creation of collaborative forums and tools to close the gap between developers, designers and end-users. Progress: • Initial integration strategies were explored and prototyped with SP2 team members. A Web Sockets communication bus for AsTeRICS was created to enable integration of components with the AsTeRICS construction set. • A first version of the Prosperity4All Quality Infrastructure was designed, specifying the requirements for an infrastructure that a) supports component developers in crucial production tasks such as automated unit and acceptance tests across platforms and b) helps DeveloperSpace users to better understand the current state and trajectory of a tool component featured in the DSpace. An initial version of this infrastructure will be implemented and made available to P4A developers in Year 2. • The core integration toolkit of the Prosperity4All architecture, called the Nexus, is currently being designed. It will provide a means for different components to be connected seamlessly across language, toolkit and process boundaries, helping to reduce
13 the complexity of using multiple SP2 building blocks together. An initial version of the Nexus will be implemented and tested with SP2 and SP3 technologies in Year 2. • Initial research and design of the DeveloperSpace was conducted. Significant Results: • Use cases for the DeveloperSpace were created and will be used for inspiration while designing and developing the DeveloperSpace. See also http://wiki.gpii.net/w/Developer_Space • Initial architecture requirements were presented to the Prosperity4All community
Task 201.2: Unified Listing and MarketPlace architecture and implementation Progress: • Core technologies for the Unified Listing have been identified. • The first prototype Unified Listing core is done, • The investigation of methods to harmonize and federate different databases is complete. • Technical work has been begun extracting ICT access related information automatically from mainstream federated data. • The mainstream product data from the Mobile Manufacturers Forum has been loaded. • Performed state-of-the-art review on micropayment and user bidding systems • Worked on defining the preliminary use cases and indicative usage scenarios and derive the relevant requirements for the micropayment and user bidding subsystems. • The design and architecture definition of the micropayment and user bidding subsystems is under way in close collaboration with T201.3 (Security Architecture and Secure Payment Infrastructure), since micropayment and user bidding will be parts of this Infrastructure. Moreover, the WP205 team has been consulted at several occasions, since micropayment and user bidding are expected to be important functions of the Assistance-on-Demand infrastructure. Several internal meetings (face-to-face and phone-based) have taken place between the teams of the above-mentioned WPs. • Worked on defining personal data and privacy management perquisites for the micro- payment subsystem. • Contribution to updating and reorganization of the project wiki in relation to T201.2b descriptions Significant Results: • 1st draft of use cases, indicative usage scenarios and preliminary requirements for the micropayment subsystem • 1st draft of use cases, indicative usage scenarios and preliminary requirements for the user bidding subsystem • Preliminary architecture of user bidding database defined • First Unified Listing prototype that can support mainstream products completed • First mainstream product accessibility features database loaded
Task 201.3: Security Architecture and Secure Payment Infrastructure Progress: • Performed state-of-the-art review on technologies for payment and security in terms of Identity and Access Management systems, as well as surveyed state-of-the-art relate to platforms for global systems • Identification of the requirements that the security and payment infrastructures have to meet and definition of preliminary usage scenarios • The design and architecture definition of the security and payment infrastructures is under way. Collaboration with the WP205 team, since security and payment are
14 expected to be important elements of the Assistance-on-Demand infrastructure. Several internal meetings (face-to-face and phone-based) have taken place between the teams of the above-mentioned WPs. • Communication with SP4 teams and contribution to the definition of test scenarios for the future technical and user evaluation of the payment and security subsystems • Participation to P4A meetings and contribution to updating and reorganization of the project wiki in relation to T201.3 descriptions Significant Results: • 1st draft of use cases, indicative usage scenarios and preliminary requirements for the security infrastructure defined • 1st draft of use cases, indicative usage scenarios and preliminary requirements for the payment infrastructure defined
Task 201.4: Gamification and Crowdsourcing Framework for Engagement and Quality Progress: The Gamification patterns widely used in the industry often rely on their visual representation. This is a problem for Accessibility, where many constraints regarding presentation and interaction with digital content are invoked. After a first analysis of a bunch of patterns it became clear that a simple adaptation would greatly limit the Gamification approaches we can use. Therefore, we went one step back and started looking at digital games, rather than Gamification approaches. From an analysis of commercial games we derived an array of more abstract Gamification patterns that are representation agnostic. Their implementation in prototypes has begun. Significant Results : • Finding: Gamification approaches cannot be directly adapted for Accessibility. One example is the fundamental requirement of Gamification to be optional. With a typical 2D representation of information (a webpage on a screen) it is easy to put optional information in a sidebar. A 1D representation of the same information (a webpage on a screen reader) has significant limitations here. • Approach: We analysed the literature as well as several commercial and non-commercial games and derived patterns from their gameplay and game mechanics that are representation-agnostic • Result: A list of categorized gamification patterns as candidates for implementation. The important categories are Development, Reward, Action Space, Challenge, and Discovery. These results are summarized as a first draft of the living document D201.3 in two academic papers published at the HCII2014 (Gamification in the Development of Accessible Software, Stiegler2014) and will be published on the HCII2015 (Gamification and Accessibility, Stiegler2015).
Schedule and achievement of critical objectives All tasks are on schedule. All critical objectives have been achieved.
Deviations from work plan None
Corrective actions No Corrective Action is necessary
Statement on the use of resources
15 There are no deviations worth-reporting between actual and planned person-months for WP 201. Less than 25% of PMs have been expended but this is in line with expectations due to the lower PM needed for early portions (as compared to latter) and the heavy use of Dr Vanderheiden who doesn’t show up in the Prosperity4All Budget.
WP 202 – Building Block Set
Objectives for the period This work package creates new possibilities for assistive technologies and services by (1) providing mainstream developers a common open repository of state of the art AT interface modules and (2) AT interface module developers the capabilities to excel beyond state of the art by providing access to novel technologies. The main objective of the first year was the collection of all existing modules (background) in a way that they are perceived useful for the internal developers. Providing self-contained code repositories, central documentation and clear licensing was a core aspect of the work on many modules. A core active objective for individual modules was supporting integration existing assistive solutions from previous projects (background contributed by partners) particularly by extracting useful reusable modules from the code base and to expose them via a more general API. The goal of the first year is summarized by reaching milestone MS221, a “common component repository methodology”.
Progress and significant results The first half of the first year focussed on the collection and documentation of all background (i.e. existing components, which are relevant for the planned work) and the release of all relevant code and documentation in publically accessible repositories including compatible licenses.
The second part of the year was dedicated to harmonization and integration activities both on documentation and code, preparing the adoption of components by implementers. With content and a mock-up version online as well as both activities successfully finalized we reached MS221 common component repository methodology. This methodology has been partially documented in Deliverable 202.1 (Report on repository standards, common Interfaces and APIs) and that is an important step towards the delivery of the first version of the repository (D202.2 respectively MS222).
We particularly reached the goals of the first year that were “to enable the informed decisions for implementers” and “successfully point implementers to relevant resources via the DeveloperSpace Repository”. In the scope of consolidating the modules partners also delivered technical validation
16 plans and integration scenarios were defined around existing implementation were identified in order to assess the interoperability of WP202 components among each other and towards the frameworks on WP203. Future and ongoing work is on the refinement of the APIs and modules based on the feedback of the implementers to lower adoption cost and based on identified synergies and potentials to provide unified (web technology based) interfaces to increase reuse of modules.
After the F2F kick-off, work on WP202 started in Month 2. The WP integrated well into the existing GPII infrastructure (mailing-list, issue tracking, wiki). Priorities-and-expectations roadmaps for individual components were documented by all partners. A well-attended bi-weekly teleconference was established that is open towards the whole GPII (http://issues.gpii.net/browse/DSPACE-42). Bilateral F2F integration meetings between FHTW- IDRC (Month 4), KIT-HDM (Month 2, Month 6), KIT-FHTW (Month 5), FHTW-KIT-RtFI (Month 5) were held with concrete actions on integration and extension of the technologies.
Task 202.1 Repository Creation and Management (KIT) • Repository Technical Prototype and Content Management (FHTW) o Concept development based on workshops o First Mock-up implementation based on document generation system released (DocPad) o Potential synergies and differentiation criteria with the work on the Unified Listing (WP201) were identified • Collection and Documentation of Resources (ALL) o Structured collection of Building Blocks available on http://wiki.gpii.net/w/Developer_Space/Components o High level unified documentation is available for all building blocks contributed within P4A available o Development plans and expectations documented with questionnaires o Started collection and documentation of external modules and resources (http://wiki.gpii.net/w/Developer_Space/Resources). First successful matches for implementers also based on this collection. • Standardization and common APIs (KIT) o Collection of relevant APIs and standard used by all partners. o New directions for standardized/existing interfaces (GPII Flowmanager, WebSockets, WebRTC, IndieUI, URC) were discussed and implemented partially as proof of concepts. o Based on the experiences within all components the documentation on use of standards within building blocks was prepared and published as Deliverable 202.1.
Task 202.2 AT-specific I/O-Modules (FHTW) • Modularization and Adaptation AsTeRICS AT-modules o Adaptations to the AsTeRICS Runtime Environment (ARE) and processing modules have been performed to support identified use cases and the Linux porting effort Currently ARE runtime system runs on Linux and was successfully tested on Fedora / Ubuntu / Raspbian (Raspberry Pi). First version of low-level image processing / computer vision algorithms now running Linux o Architecture and API refinements to AsTeRICS Modules Implementing new Webs Socket and REST APIs for model auto start, integrated into auto personalization. "Lazy loading" of plugins: plugins are only loaded "on-
17 demand" - saves time on start-up. (REST API implementation work will be picked up by UCY in course of WP203) • Behind the firewall versions Robobraille Transformation Modules (SENSUS) o The overall architecture of the open-source document transformation toolkit was defined. Building on industry-strand interfaces (REST-based web service for authentication, job submission, status enquiry and job result retrieval; SQL for transaction management and scheduling), the architecture will allow for implementation as a document transformation engine by third parties in hosted environments, in sheltered behind-the-firewall environments and as part of black-box solutions. Using the web service API, third parties will be able to integrate the document transformation service with other systems, including mobile apps and document-heavy systems such as digital libraries, learning portals, learning management systems, healthcare portals and similar. o Web service interface part of the transformation toolkit was designed and implemented. The web service interface enables developers to integrate with the service through HTTP requests, submitting parameters as well as documents. The interface will support synchronous as well as asynchronous document transformation requests, depending of the conversion profile in question: Some mobile apps are likely to require immediate results through synchronous document transformations (e.g., “snap a picture of a menu and have it converted immediately to an audio file for immediate consumption”) whereas other, more time-consuming must be handled asynchronously (e.g., “upload a batch of inaccessible PDF files from a healthcare portal or learning management system for conversion into accessible PDF, MP3 and digital Braille and return the results when they are ready to be published alongside the inaccessible source”). Access to the transformation toolkit can be controlled through an authentication mechanism based on API Key Authentication. The work of this task is coordinated with tasks T204.3 and T204.4 in WP204. o A technical validation plan was designed and described. The test plan described the prerequisites of establishing a document transformation system based on the toolkit in terms of hardware and software, and summarises how the various document conversion paths can be validated.
Task 202.3 Security Architecture and Secure Payment Infrastructure • Concepts and prototype for the extraction of AsTeRICS powered vision components (FHTW) o Setting up eclipse build flow o creation of "P4ALLBuildingBlock" GitHub repository within AsTeRICS o Adaptation of AsTeRICS modules as "stand-alone" application without the ARE/OSGi framework. o Solving licensing questions / developing strategies for re-licensing o Development of first stand-alone version of module "FacetrackerLK" - targeted to implementers (LifeTool, GuadalInfo) o Technical validation plans defined.
• Concept and prototype for Haptic/Touch IO (CERTH) o An analysis of previous work on haptic technologies (e.g. 3DHapticWebBrowser, AEGIS Haptic RIA Maps, AEGIS Mobile Open/Touch Sound Maps) was conducted
18 to identify which parts/software modules can be reused and refactored in a way that will properly address the use cases of Prosperity4All. o An analysis of existing open-source haptic APIs was also conducted to identify the most suitable API(s) on which the Prosperity4All Haptic/Touch I/O Modules will be based on. o A first prototype showing how the Prosperity4All Haptic/Touch I/O Modules can be used to add haptic feedback on a web page/web application was also implemented o Technical validation plans defined.
Task 202.4 Smart Device and Environment Interconnection Modules (KIT) • Universal Remote Console tutorials (HDM) o Ongoing work on new tutorials explaining the concepts of URC, UIs connected to Sockets, and assistive technologies (estimated release Month 17, part of this work is already posted at http://wiki.gpii.net/w/URC_Super_Sockets). • Universal Remote Console Super-Socket templates (HDM) o Work on standardization of URC Device (Socket) Templates within openURC (http://www.openurc.org/TPL/, estimated release Month 23). Reference implementations for XMBC media system, IP-controlled power socket, Philips hue (illumination). • Smart Discovery Modules (KIT) o Modularization of Spatial selection using REST-based interface for Point & Click interactions. Modules and RESTful-APIs derived from standalone version removing specific UI dependencies preparing integration with URC o New demonstration version now working purely with HTML5 web-browser on client side including the use of vibration API. o New modular system for easier installation of new devices by pointing gestures. o Web-based API for Bluetooth LE based device selection released, working towards technology independent interface for spatial device selection (addressing concerns particularly concerning camera-based systems) o Technical validation plans defined. • Smart Authentication Modules (KIT) o Full release of all authentication modalities with demo prototype: QR-Code, Touch (Restricted-Wifi, NFC), Password/PIN under new license terms. o Web-component based concept for exchangeable authentication interfaces developed. New Concept for proximity based out-of-band authentication using blue- tooth low energy (URI-Beacons) and HOTP defined and to be implemented/released. o Ongoing investigation of alignment with FIDO-Alliance standards. o Technical validation plans defined.
Publications: Matthias Budde, Till Riedel, Marcel Koepke, Matthias Berning, Michael Beigl, A Comparative Study to Evaluate the Usability of Context-based Wi-Fi Access Mechanisms, HCII 2014
Task 202.5 Real-Time User Monitoring Modules (CERTH) • Sensor Abstraction Layer (KIT, UCY) o Analysis of requirements and alternative existing technologies. Initial work on Bluetooth LE started based on based on Apache Cordova and recently released Google Chrome APIs. Identification of usability deficits and adoption barriers started. Integration of new AsTerICs Web-Socket interface ongoing.
19 • Affect Sensing Module (CERTH) o An analysis of previous works on affect sensing technologies (e.g. through bio signals processing and virtual activity sensors) was conducted to identify which parts/software modules can be reused and refactored in a way that will properly address the use cases of Prosperity4All. o A first prototype showing how the Prosperity4All Affect Sensing Module can be used toward the recognition of emotional states such as stress from data collected by physiological sensors. • Crowd-sourced Virtual Sensor Modules (KIT) o HTML-based client server system for annotation and learning released with support for downloadable device optimized Java Script based classifiers working o First prototype of cloud hosted machine learning platform demonstrated. Supports walking/falling detection within standard HTML5 compliant web browsers.
Task 202.6 Web-based Smart Personalization and Interface Adaption Modules • First conceptual work on Web UI modules started in M07 containing logic for self- adaptation (UStutt) and URC connectivity (HDM). Partners are working towards a light- weight JavaScript framework for adaptive Web components. A first release as open-source is expected by early next year.
Publications: • Lukas Smirek, Alexander Henka, Gottfried Zimmermann (in press): Giving Elderly Access to Smart Environments Providing Adaptive User Interfaces Based on Web Components, the Universal Remote Console and the Global Public Inclusive Infrastructure. HCII 2015, Los Angeles. (to appear) • Gottfried Zimmermann, Annkristin Stratmann, David Reeß, & Tobias Glaser (in press). Patterns for User Interface Adaptations - Towards Runtime Adaptations for Improving the Usability of Web Forms for Elderly Users. HCII 2015, Los Angeles. (to appear)
Schedule and achievement of critical objectives All tasks are on schedule. All critical objectives have been achieved and MS221 was reached.
Deviations from work plan and corrective actions None
Statement on the use of resources The overall planned effort for this work package is 129,5 man-months, within the reporting period 33,8 man-months of researchers have been committed to this work package within this reporting period. The major part of the remainder of the allocated time is expected to be used during the subsequent reporting period, with effort particularly on self-adaptive user interfaces expected to be used in the third year.
20
WP 203 – Collaborative development tools and environments
Objectives for the period The following objectives (taken verbatim from the DoW) have been relevant at least partly in the reporting period. • To maximize accessibility support by integrating complementary approaches of AT integration (AsTeRICS), user interface sockets (URC: Universal Remote Console) and flexible, runtime adaptive user interfaces (MyUI). • To provide an integrated environment for the effective development, configuration and run- time of highly individualized and accessible user interfaces for commercial products. • To foster industrial accessibility mainstreaming by providing intuitive and efficient development tools and environments which build on model-based development approaches and graphical editors: (1) for creating an abstract model of the interaction with an application as a basis for adaptive UIs and UI sockets, and (2) for plugging alternative I/O devices (assistive technologies). • To support industrial uptake of model-based adaptive user interfaces for eInclusion by (1) bringing adaptive user interface development into the Prospoerity4All ecosystem and (2) by providing a reference implementation of an adaptive UI development toolkit which satisfies industrial market requirements. • To work towards harmonization and cross-compatibility of promising model-based approaches to accessible user interfaces to boost international standardization and scientific progress as a basis for their use in commercial product development. • To develop steppingstone applications as showcases and starting point for mainstream ICT products accessible for users with low ICT literacy and cognitive impairments.
Progress and significant results
Task 203.1 • Identification of key requirement to support different development approaches and different levels of software development expertise. • Decision to support flexible development approaches from the usage of single adaptive UI elements to model-based generation of complete application UIs. • Different Scenarios for users with motoric impairments were developed. • Based on scenarios and use cases first Mock-Ups were developed and implemented as web interface.
21 • Conceptual work on an architecture for integrating MyUI, URC and openHAB resulting in the publication Smirek, L., Zimmermann, G. & Ziegler, D. (2014). Towards Universally Usable Smart Homes - How Can MyUI, URC and openHAB Contribute to an Adaptive User Interface Platform? (pp. 29-38). Presented at the IARIA Conference, Nice, France: Think Mind. Retrieved from http://www.thinkmind.org/index.php?view=article&articleid=centric_2014_2_30_30048
Task 203.2 • Initial design decisions have been taken prior to during the F2F meeting in Linz. • The architecture of the ACS has been reworked to guarantee a solid and extendable basis for the web-version. • Implementation in Javascript has been started, using the KineticJS framework for the graphical parts. Some basic functionality like opening models, inserting components, drawing channels, etc. is already working. • The communication between webACS and ARE has been discussed and a RESTful interface has been decided as the way to go.
Task 203.3 • Concepts for the runtime integration of AsTeRICS, URC and MyUI including event communication, automatic coordination of interaction mechanisms and runtime adaptations based on the SmartHouse scenario from T301.4. • MyUI Runtime o Concepts on integration with GPII to be aligned with GPII architecture o Browser-based runtime will be independent of application’s server-side technology • In the context of the adaptation of the AsTeRICS Runtime Environment initial development efforts were successfully completed for exposing the runtime environment through a REST interface to facilitate the on-going development of the REST API functions. • In the context of adaptation and integration of the three existing runtime environments (AsTeRICS, URC and MyUI), the Internal Report “D203.1-1: The Runtime Environment Specification and Architecture Design” was prepared as an interim version of D203.1.
Task 203.4 • Researched current solutions for target user groups and options for creating components that encapsulate the core features. • Working with the W3C cognitive accessibility task force who are deeply analysing user requirements and techniques • Assessed the various HTML technologies available for supporting “components” and evaluated the dependencies they introduce. • Compared options for using other WP203 components in the outputs of this task and along with architectural benefits of leaving integration to the solution using these components. • Have a roadmap for the 1st iteration including features of key components to be implemented. Decision to use HTML web components and so minimise dependencies required for developers. Components will be real world tested in OpenDirs WP3 activity. • A first draft of D203.3 has been delivered to the project members.
Publications: • Smirek, L., Zimmermann, G. & Ziegler, D. (2014). Towards Universally Usable Smart Homes - How Can MyUI, URC and openHAB Contribute to an Adaptive User Interface Platform? (pp. 29-38). Presented at the IARIA Conference, Nice, France: Think Mind.
22 Retrieved from http://www.thinkmind.org/index.php?view=article&articleid=centric_2014_2_30_30048 • Gottfried Zimmermann, Gregg Vanderheiden, Christophe Strobbe, Towards Deep Adaptivity - A Framework for the Development of Fully Context-Sensitive User Interfaces, HCII 2014, Crete • Matthias Peissner, Andreas Schuller, Daniel Ziegler, Christian Knecht, Gottfried Zimmermann, Requirements for the Successful Market Adoption of Adaptive User Interfaces for Accessibility, HCII 2014, Crete Meetings: • Kick-off meeting in Stuttgart (12.-13.2.2014) • F2F in Linz (13.-15.5.2014) • Monthly skype meetings
Schedule and achievement of critical objectives All tasks are on schedule. All critical objectives have been achieved.
Deviations from work plan and corrective actions None
Statement on the use of resources All resources have been used according to plan.
WP 204 – Media and Material Automated/Crowd-sourced Transformation Infrastructures
Objectives for the period • Modularization and Extension of Media Transform Engine • Making Captioning easier and less costly Developing Low-Cost CrowdCorrected Captioning Platform • Defining the architecture of the modularization of the document transformation engine, a test plan developed and described. Objectives for the period for Task 204.3 and Task 204.4 • To break down the current RoboBraille service into a set of conversion modules and user interface modules.
23 • Design an infrastructure for a document transformation engine based on the conversion and interface modules. • Implement a conversion path that utilises the document transformation infrastructure, including an application end-point, transaction management, job scheduling and actual transformation. • Define and implement a web service interface to the document transformation service. • Define a test plan for the modularised document transformation engine.
Progress and significant results
Task 204.1 Modularization and Extension of Media Transform Engine • Implemented external sites module to enable integrations (subtitle syncing) with external hosting services • Implemented subtitle syncing capabilities with Kaltura and Brightcove. • Added support for subtitling additional media types, such as flv, mp3, and html5 audio files. • Implemented API modules to enable direct integration with Vimeo • Implemented the static media module to improve the handling of static media • Implemented the caching module to improve site performance • Generated clear public documentation for Amara’s API, Syncing and Media modules. • Standardized the string translation methods to enhance crowd contributions
Task 204.2 Making Captioning easier and less costly Developing LowCost CrowdCorrected Captioning Platform • Implemented data model modifications required to allow for dynamic manymany relationships between subtitle languages. • Implemented sidebyside editing of subtitle languages in the Amara editor • Implemented ability to support switching between languages • Implemented changes to compare differently timed subtitle languages in edit mode. • Implemented support in Amara editor for additional media hosts / types such as Brightcove, mp3 and ogg audio types • New Editor was released as Amara’s primary subtitle editor platform during 2014. • Amara embedder: a tool to view enable crowd contribution to subtitle creation, released with support for YouTube, Vimeo, Brightcove, html5 video and audio mp3 audio files and flv video.
Task 204.3 Modularization and Replicability of Transformation Engine and T 204.4 Modular Interface to Extend function for Tables and Language Trans The current architecture of the RoboBraille service was analysed. Although the functionality of RoboBraille can be divided into a set of logical modules, the current implementation of the service is monolithic. During the reporting period, the logical interfaces and future conversion capabilities were broken down into a set of discreet modules. In addition to the current transformation modules (OCR processing of image-type documents, Conversion of Office-type documents, E-book conversion, MP3-conversion, Structured audio book conversion, Digital Braille conversion), a number of new transformation modules were defined: A Machine Translation (MT) module for translation between different natural languages (e.g., French and English), a Text-to-Sign Language Translation (SL) module for conversion of text into animated sign language in various languages and an Optical Structure Recognition (OSR) module for recognising the semantic structure of
24 documents. The overall architecture of the modularised document transformation engine is illustrated below:
A job scheduler will read incoming requests from the transaction database and request conversion from one or more conversion modules. An example may be an incoming request for conversion of the text contained in an image in JPG format to be converted into an MP3 file in French. The job scheduler will request the following sequence of conversions: 1. Request the OCR conversion module to convert the image into a Unicode text file. 2. Request the Audio conversion module to convert the text file into an audio file in WAVE format using French speech synthesizer. 3. Request the Audio conversion module to convert the WAVE file into an MP3 audio file.
Subject to a successful conversion, the job scheduler will return the result to the transaction database to be passed to the requesting process through a web service interface. Similar conversion sequences can be defined for other conversion paths, e.g., conversion of a Microsoft Word document including mathematical equations into a DAISY Structured Audiobook with spoken math or Conversion of a Microsoft PowerPoint presentation into an accessible PDF file. The requesting process may be a user-driven mobile app, web interface or desktop application, or it may be another system requesting. As planned, an asynchronous conversion path was implemented, allowing processes to convert text contained in JPG images into MP3 audio files. The conversion path included the implementation of a REST-based web service, a transaction database (Microsoft SQL Server), a job scheduler as well as a prototype OCR conversion module and an Audio conversion module. To illustrate use of the transformation engine, an Apple iOS demonstrator app was developed. The app allows users to capture images using the built-in camera of an Apple iOS device for conversion into audio using the document transformation engine.
During the reporting period, project partner ENG (beneficiary 10) expressed an interest to integrate its technology with the document transformation engine with the aim of producing accessible documents in tagged PDF from HTML/HTML5 documents. Although the current implementation of RoboBraille does include conversion into accessible, tagged PDF from certain source formats (Microsoft Word, Microsoft PowerPoint), HTML/HTML5 documents are not supported. Consequently, to address the requirements of ENG, research commenced into how an HTML/HTML5-to-Accessible PDF conversion module can be established.
25 A test plan for the modularised implementation of the document transformation engine, including each of the user interface and document conversion modules, was developed and described.
The work of these tasks is coordinated with tasks T202.2 in WP202.
Schedule and achievement of critical objectives All tasks are on schedule. All critical objectives have been achieved. In addition, work on an HTML/HTML5-to-Accessible PDF conversion module was commenced.
Deviations from work plan None
Corrective actions Not applicable
Statement on the use of resources The planned amount of man-months has been used on this work package. The remainder of the allocated time is expected to be used during subsequent reporting periods.
WP 205 – Assistance-on-Demand Services Infrastructure
Objectives for the period • Define the needs, requirements and preferences of the different potential user groups (e.g. disabled, older people, employees and employers with different skills and expectations) for the targeted application domains (e.g. daily living, e-health & safety, education, leisure, entertainment, job technical support). Express these in terms of indicative usage scenarios and use cases and agree these with the wider community (within and outside the project). • Design a generic open source infrastructure that supports the current and emerging needs for Assistance-on-Demand (AoD hereinafter) services, employing where applicable leading edge cloud computing technologies and matching the Prosperity4All overall architecture defined in WP201. • Design a framework for creating “dashboards” of assistance services, customizable (per person or community/group or application domain) and supporting a wide set of service selection criteria (e.g. service type, price, developer, presentation, quality and security
26 level), while offering zero/default configuration options for efficiently supporting non- professional and/or disabled users.
Progress and significant results
Progress: The efforts of this WP, as a whole, in the first year focused on the following activities: • Review of state-of-the-art platforms allowing for service search in different application domains so as to identify limitations, common interesting features and problems to be addressed by P4A AoD (included in document uploaded to P4A wiki); • Definition of several indicative use scenarios, covering multiple AoD functionalities, which were communicated both to internal and external P4A entities, notably our Advisory Board members who already have experience in developing AoD services, and potential users for collecting feedback. Revision of use scenarios to address comments received (included in document uploaded to P4A wiki); • Definition user requirements, including accessibility requirements for the AoD platform based on the use scenarios; • Development of wireframes to showcase the evolution of different use scenarios and form a basis for discussion with project partners and end users (uploaded to P4A wiki); • Definition of a high-level generalizable open-source architecture for the implementation of the P4A AoD; • Development of a detailed AoD platform delivery timeplan; • Delivery of the 1st version of the AoD service platform that supports user and service supplier registration and flexible service search. This has been made available for technical validation and testing with users during the 1st evaluation iteration (It is worth stressing that this achievement was not scheduled for the 1st year. Nevertheless, it was considered useful for collecting early user feedback that will influence further development work); • Communication with SP1 partners with respect to the definition of AoD target groups and P4A ecosystem requirements, with other SP2 WPs teams to agree on the functionality borders between different components (e.g. security and payment), with SP3 partners to discuss and accommodate the requirement of service developers and with SP4 partners for defining the test scenarios of the AoD for the evaluation that will take place in SP4. Several internal meetings (face-to-face and phone-based) have taken place between the teams of the above mentioned WPs. • Attendance to all plenary meetings and SP-related phone calls and contribution to updating and reorganization of the project wiki in relation to T205 descriptions; • Preparation of one conference paper and contribution to project’s dissemination material preparation. The publication details are: Gianna Tsakou, Helen C. Leligou, Nikos Katevas, „A Novel Infrastructure Facilitating Access to, Charging, Ordering and Funding of Assistive Services“, HCII 2014, Crete
Results: • 1st version of the AoD service platform prototype that supports user and service supplier registration and flexible service search. This has been made available for technical validation and testing with users during the 1st evaluation iteration. It is worth stressing that this achievement was not scheduled for the 1st year. • Draft of D205.1 documenting all work described above (e.g. indicative usage scenarios, preliminary requirements, architecture, state-of-the-art review, technologies to be used, etc.) available at project wiki and communicated to project internal and external entities,
27 including user associations: (http://wiki.gpii.net/w/AOD_- _Assistance_on_Demand_Infrastructure#Documentation.2FFAQs); • Series of wireframes for numerous AoD functionalities available at http://wiki.gpii.net/w/AOD_- _Assistance_on_Demand_Infrastructure#Documentation.2FFAQs
The progress and results achieved per task are described next:
Task 205.1 Creation of an open-source generalizable Assistance-on-Demand Service Infrastructure • Definition of use scenarios for the AoD infrastructure based on the state-of-the-art review of service search platforms targeting diverse application domains after collection of feedback from potential user groups; • Definition of the high level architecture of AoD and the technologies that will be used • Development of the basic AoD functionality that includes user and service supplier registration and flexible service search. • Development of wireframes showcasing the AoD platform functionality, as detailed above.
Task 205.2 Cascading "Try Harder" Assistance-on-Demand infrastructure • State-of-the-art review on QoS handling in platforms enabling service search and preliminary use scenarios definition.
Task 205.3 Peer/community support network infrastructure • Definition and refinement of use scenarios on the provisioning of multi-modal technical support (see detailed work description above) • Development of wireframes showcasing the provisioning of multi-modal technical support (see detailed work description above).
Task 205.4 Consumer/Family/Professional configurable Assistance-on-Demand service • Definition and refinement of use scenarios on the selection and configuration of AoD service networks by carers and care-givers (see detailed work description above); • Development of wireframes showcasing the selection and configuration of AoD service networks by carers and care-givers (see detailed work description above).
Task 205.5 Employment of non-tech personnel • Definition and refinement of use scenarios on the employment of non-tech personnel focusing on easy registration and social networking functionality
Schedule and achievement of critical objectives All objectives are on or ahead schedule as explained above. All critical objectives have been achieved and further work has been delivered ahead of time.
Deviations from work plan and corrective actions Positive deviation is observed. All tasks are ahead of schedule. A basic functional prototype has been delivered ahead of schedule for testing and collecting feedback.
Statement on the use of resources Slightly higher number of person-months (approximately 10%) have been consumed in this WP compared to planned for Year 1 due to the intensive work undertaken (i.e. several cycles of refining
28 use scenarios with all relevant stakeholders) and due to the additional effort required to deliver an early functional prototype (not planned in the DoW for Year 1). This deviation is not expected to negatively affect the WP, on the contrary, it has been deliberately pursued for reasons analysed above.
WP 206 – Sustainable Meaningful Consumers-Developer Connections (Pull vs Push)
Objectives for the period • Identify the feedback and feedforward information needs and preferred modalities to maximize the satisfaction of consumers and developers:
Progress and significant results During the first 6 months of the project, the Technosite team has focused on research about the different components to be developed by the end of this WP. An initial desk research was done in order to clarify the different classifications and fields to be assessed regarding those components. Moreover, a clear research methodology was defined in order to carry out field work and analyse the functional requirements. Currently, Technosite´s team is finalising a set of in-depth interviews, writing down the initial conclusions of the observation sessions done in two Guadalinfo Centres and compiling the material obtained from developers online (This digital ethnography has been based in the most popular developer´s sites where interesting insights can be found).
The second half of the first year period, the Technosite team has been focused on analysing the raw data obtained from the field work and desk research. The categorisation of material from the virtual ethnography as well as the items observed and written down in the in-depth interviews was made. With the aforementioned categorisation documented in D206.1 an initial set of personas, scenarios and requirements were generated in order to give the main hints for the tools to be developed in further tasks. The combination of an exploratory field work along with an analytical desk research has enabled us to end up with the main categories and workflows in the engagement of users’ overtime; furthermore this work has produced significant results for developers in the rest of activities in this work package.
This activity has been key input to the other activities of this WP. It will reorient the efforts in the other activities in order to maximize the consumer and developer satisfaction with the tools resulting from this WP. The connection of the WP developments with social networks such as Facebook, Yahoo, Google+, etc. has been assessed in this activity from a non-technical perspective.
29
The deliverable submitted until now is: D206.1 Best ways to engage customers over time: This deliverable is the result of “T206.1 Study of feedback and feedforward needs and preferred modalities” and contains guidelines regarding the feedback and feedforward that users want to provide and developers want to obtain, as well as their preferred tools or channels or methods to provide/obtain it. There have been informal coordination calls with SP4 leaders in order to treat the issue of evaluation. There have been some relevant meetings regarding the technical work up until now:
• Kick off meeting with members if the technical team in order to allocate subtasks and roles (internal Technosite) 18th March 2014 • Meeting with Guadalinfo P4all team in order to gain access to the centres for field work 16th April 2014 • Internal meetings among social researchers and the development team in order to foster the co-design sessions Monthly • Meeting with Pizarra´s Guadalinfo Centre head in order to arrange the field work June 2014 • Meeting with Cártama´s Guadalinfo Centre head in order to arrange the field work June 2014
Task 206.1: Study of feedback and feedforward needs and preferred modalities Due to the fact that tasks within this WP are developed diachronically, the only task in this work package for the first twelve months has been this one. For this task a field work was carried out in Guadalinfo centres and some internet communities along with an analytical desk research in order to end up with: • What consumers want with regard to the ability to provide feedback to developers and input that would direct future development efforts, intersected with the developers’ needs for information. • What the tools or channels or methods are that different consumers or types of consumers prefer to use, intersected with developers preferred mechanism to obtain it. • The main result of this activity has been D206.1 Best ways to engage customers overtime (Delivered on-time)
Schedule and achievement of critical objectives All tasks are on schedule. All critical objectives have been achieved.
Deviations from work plan and corrective actions None
Statement on the use of resources Resources have been used as planned within the DoW.
30
3.2.3. Work Packages of Sub Project 3
WP 301 – Communication, Daily Living, Health & Accessible Mobility
Objectives for the period • Study the resources available in the DeveloperSpace (tools, infrastructures and guidelines) and establish an understanding of what is being offered in each SP2 deliverable. • Match Dspace (including SP2) offerings against the requirements of each application addressed in WP301 and select those Dspace tools that are most beneficial for each WP301 application to be integrated by the respective WP301 team (at activity level) during the project lifetime. • Define, using Dspace, which are the best ways to facilitate the uptake of ICT for all citizens using open ICT access points, while at the same time engage Public Administration in the P4A ecosystem.
Progress and significant results
Task 301.1 Learning and training s/w applications • Progress: Within the range of this task LIFEtool redevelops and enhances the application called FlashWords. The application targets persons who can hardly speak or have only insufficient speech abilities. Especially children with Down syndrome, according to their condition, face special problems with their speech development (hearing, speech motor function, short auditory memory, comprehension). FlashWords is optimized for touch-input and running cross-platform on iOS, Android and Windows environments. In order to reach as much motor impaired users as possible LIFEtool is closely cooperating with the technical university of applied sciences in Vienna. The following results have been achieved within the first year of the project: o Redevelopment of the FlashWords application in order to use p4all components. o Several online meetings regarding implementation activities have been held with the developer team of the TU Vienna. o The AsteRICs configuration suite was studied and tested thoroughly (basis of the developed modules by TU Vienna). o The requirements for the implementation of the camera input module were identified. o The camera input module developed by the TU Vienna was evaluated thoroughly.
31 • Results: o The results of the mapping between Flashwords and SP2 (Dspace) offerings and the relevant benefits expected from the integration of SP2 tools are documented at: https://docs.google.com/document/d/1wG-lXsgQ- cEiTMu8sw6tENn60o9Hc7OBXFHuxxv9TEw/edit o Integration work of SP2 tools is ready to start within the next period. Task 301.2 Improving access to technology for dementia sufferers/carers (leader: OpenDir, Duration: M1-M48) • Progress: o Investigated all SP2 components plus DSpace entries and how they might enhance Brian. Drew up a short list. o Considered architectural changes and associated effort needed to work with various SP2 components in a HTML web environment o Analysis of using Infusion to re-implement as this allows significant personalisation capabilities. • Results: o Identified a short list of which SP2 components can realistically be used to meet the objectives for a 1st iteration. GPII auto personalisation is most significant for 1st iteration, but URC and MyUI also look possible long term.
Task 301.3 Public Access Points to ICT: GuadalInfo • Progress: GUADALINFO role in the project is to act as a facilitator and multiplier for the P4A SP2 tools and infrastructures by enabling access for citizens to several of the results of the project as well as by connecting and enhancing existing services using the SP2 tools and infrastructures. With this undertaking, GUADALINFO expects to make its network of centres more inclusive to a wide range of users with different capacities. In the first part of project, we have implemented a suitable, but not fully functional, version of the Asterics facial recognition function of the camera mouse module, which is recently running under our Guadalinex OS (Ubuntu based). Next step will be developing a fully functional camera mouse module and including it in the next upgrade of the system, through uploading the developments in the repository. Our implementation schedule has also been defined during this period and is as follows: o Short term scenario consists in implementing existing facial recognition developments in a Guadalinfo centre collecting our experience in integrating Dspace tools (in this case the face recognition). o Medium term scenario consists in developing a fully operational Asterics camera mouse module and providing the upgrade to a test group of Public Access Point to ICT. This scenario involves the following steps: º Select a test group of centres. º Install the system upgrade º Train the facilitator in charge of the centre in using the camera mouse module º Reveal and document deployment issues if any o Final scenario consists in scaling the system upgrade including the camera mouse module to the whole Access Point Network. End users test. This scenario involves the following steps: º Upgrade the whole Guadalinfo Network º Select a test group involving associations, groups of interest and individuals identified as target beneficiaries of the Asterics module.
32 º Functional validation. º Comparison with the similar tracking software currently installed and used in the Guadalinfo accessibility framework. º Reveal and document functionality issues if any. • Results: o Delivery of a suitable, but not fully functional, version for Linux of the Asterics facial recognition function of the camera mouse module, which is recently running under our Guadalinex OS (Ubuntu based). Implementation in Guadalinfo environment is being developed in cooperation with Centre Verein Fachhochschule Technikum Wien (FHTW) (SP2).
Task 301.4 luggable user interfaces for home appliances, home entertainment and home services • Progress: o URC socket templates under development. o A master course “Universal Remote Console (URC) Project „is under preparation. In this course students will work with tools and tutorials which were (further) developed in T202.4 and T203.1. Based on these concepts they will develop personalised and adaptive user interfaces for smart homes. This course will result in example user interfaces for smart homes. o For making as many home appliances, home entertainment and home services (targets) available via the UCH, it was decided to integrate the UCH with the open- source openHAB framework (also known as Eclipse Smarthome). We will work within the openHAB community and thus make GPII more visible in mainstream development of smart home technologies. • Results: o First drafts of template sockets (e.g., XBMC targets, illumination) available in the SVN repository the openURC Technical Committee.
Task 301.5 Game-based cognitive rehabilitation & • Progress: o Reviewed all resources available in the DeveloperSpace (tools, infrastructures and guidelines) and established an understanding of what is being offered in each SP2 deliverable. o Matched Dspace (including SP2) offerings against the requirements and technical specifications of Sociable (the SILO commercial application that will be the basis of this task) and selected those Dspace tools that are most beneficial for the application to be integrated in the next months. o Created integration plan for the next 6 months. o Communication with the SP2 teams (face-to-face meeting and several skype calls) developing the selected tools for Sociable (T301.5) and conduction of in-depth discussions on the existing and future components and functionality for each tool of interest, technical specifications, integration issues, etc. o Contribution to the WP402 test scenarios for the enriched with SP2 tools Sociable application that will take place in SP4. • Results: o The results of the mapping between Sociable and SP2 (Dspace) offerings and the relevant benefits expected from the integration of SP2 tools are documented at: https://docs.google.com/document/d/1wG-lXsgQ- cEiTMu8sw6tENn60o9Hc7OBXFHuxxv9TEw/edit
33 o Integration work of SP2 tools is ready to start within the next period. Task 301.6 Routing Guidance System • Progress: o Available solutions at DeveloperSpace wiki page: o http://wiki.gpii.net/w/Developer_Space_Components were checked for their appropriateness and compatibility with the MLS destinator. This task has been completed; it will be revised during the implementation process. o The team specified general details and technical issues regarding T301.6 activity as follows: º Solution: MLS Destinator Talk&Drive™ (http://www.mls.gr/?pid=60&la=2&itmID=224) º Platform support: Android OS º Users: Type of drivers {elderly, vision impaired, Parkinson disease, stressed} º Use cases: Different type of drivers (novice, older drivers, and older drivers with age –related problems) uses the same MLS navigator device at the vehicle. Personalisation on application level. º Languages support (internationalization): Greek, English, German (?), and Spanish (?) º Outcome: the result of this task will be an enhanced navigation system which has an improved graphical interface and is more accessible. Work will focus on the driver using the navigation system but other use cases might be considered: e.g. making maps more accessible for persons with visual disabilities when they are riding in a car. The navigation system to be used is the commercial product MLS Destinator Talk&Drive™. The enhancements after the integration of SP2 tools are synopsized below. • Results: o Table showing the results of the mapping between SP2 solution and the MLS Destinator (“Routing Guidance” application). o Integration work of SP2 tools is ongoing. Schedule and achievement of critical objectives All critical objectives for the tasks of WP301 are on schedule. All critical objectives for the period have been achieved.
Deviations from work plan and corrective actions None
Statement on the use of resources There are no deviations worth-reporting between actual and planned person-months for any of the partners contributing to WP301.
34
WP 302 – Education eLearning, Business and Employment
Objectives for the period • Study the resources available in the DeveloperSpace (tools, infrastructures and guidelines) and establish an understanding of what is being offered in each SP2 deliverable. • Match Dspace (including SP2) offerings against the requirements of each application addressed in WP302 and select those Dspace tools that are most beneficial for each WP302 application to be integrated by the respective WP302 team (at activity level) during the project lifetime. • To design and develop counselling and tactile graphics printing services to achieve a comprehensive inclusion of the students with visual impairment into higher education and everyday life; To establish the workflow that can be used by any organisation to produce highly standardised tactile graphics; • To improve the accessibility to educational content for blind and partially sighted students/workshop attendees exploiting flexible format transformation tools
Progress and significant results
Task 302.1 Accessible Business Intelligence Progress: Based on DeveloperSpace, a first selection of the SP2 tools was done and shared between the SpagoBI team and the P4All developers. The analysis of the DS tools to integrate suggested a review of the SpagoBI platform toward a RESTful architecture, which has been designed and partially implemented. After this architectural adaptation, among the identified tools (AmCharts, Describler, Fluid, Robobraille) a first integration has been designed for Robobraille and a POC (Proof of Concept) has been implemented. Results: A prototype is under implementation and will be ready for the review meeting.
Task 302.2 Establishment, design and development of a counselling and printing services for tactile material for visually impaired Progress: Due to the case that it's quite difficult and expensive (price of a tactile printer for A3 is more than 80 k€ at the moment) to create good and usable tactile material/prints, KIT-SZS wants to develop and design an online printing service for future customers/users. Therefore KIT-SZS is
35 working in this task on the one hand on a good working work flow and on the other on the design/development of the online-service itself. Finally this service should be combined with other SP3 packages like micro payment or an online marketplace. Our first results in the first year are: • We have a workflow. • The front- and back-end of the counselling and printing web service as well as the process itself are growing.
With the user front-and a user can - after a simple login - upload a file on the SZS server for printing. For every upload the responsibles get an email for checking quality and status of the document and approving the final print. Users without an account can open a new one filling the registration form.
Figure 1 & 2: Front-end screenshot; 1: Uploading documents, 2: Registration
The back-end so far: • Obtaining information from the database, for example the name, the e-mail or the address associated with a filename. • Manage the print of the documents through three checks/steps.
1. Open the file for checking if all is proper (font, color background and so on). If all is fine, the document can be send to the printer by clicking twice on the first check symbol (it will become green). If something is wrong, click only one time on the first check symbol and it will become red and all the other checks will be disabled. As soon as everything is fine click again on the symbol and the printing starts. 2. If the first check is "green", a new window will be open. It contains the address associated with the file, for the shipment which will be automatically printed. 3. After the print of the files someone has to check the prints. If no problems occurred in the printing process, they are ready to pack and mail. Otherwise leave the check "red" to indicate that an error was occurred with that file and the problem should be solved. • As soon as all checks are successful, the document and information are moved to the "old requests list".
36
Figure 3: Back-end Screenshot
• Results: • First test version of the online service is running and ready for internal testing by university stuff and students inside the KIT. (Next step will be combination with other P4A tools.)
Task 302.3 Accessibility of learning material for visually impaired by flexible transformation tools Progress: As mentioned in the DOW, in P4A the SZS will profit from and contribute to an infrastructure that addresses the need to transform very different kinds of material, especially learning material, to different formats. Once the conversion components are in place, SZS will capitalise on the vast amount of educational content is has gathered and will transform it to an accessible e-Learning content. It would be a great opportunity to use the accessible Web-Components developed in this project to give interactive access to this content. Therefore we have the first conversion tool to make LaTeX-documents readable for blind as an offline version running. Results: • The first offline version of a tool to convert LaTeX files to an accessible easy readable HTML result is ready to use. Improvements have still to be done and finally an online version has to be created.
37 Figure 4: Offline Tool LaTeX2aHTML including example and result in the background.
Task 302.4 Special Educational Programs and learning tools Within this task LIFEtool is designing an App which helps the users first to get to know about money, but this includes not only the knowledge of the individual coins and banknotes, but also the knowledge of the value of money itself. Children and young people should get a feeling for how much daily life costs, such as food and drug products, as well as electronic equipment and other everyday objects. It will be optimized for touch-input and running cross-platform on iOS, Android and Windows environments. This application will be improved by the Haptic and Touch IO Module developed by CERT/ITI. With the help of this tool the users are provided with normal tactile response like they were pressing a physical button. • Progress: • The results of the mapping between the money App and SP2 (Dspace) offerings and the relevant benefits expected from the integration of SP2 tools is documented at: https://docs.google.com/document/d/1wG-lXsgQ- cEiTMu8sw6tENn60o9Hc7OBXFHuxxv9TEw/edit • The communication with the Team of CERT/ITI has been established.
• Results: • The user requirements for the application have been gathered within the range of various user sessions. • The UI design and the technical requirements have been specified.
Task 302.5 Integration of Prosperity4all with FLOE This activity includes the creation of new resources and tutorials within the Floe Inclusive Learning Design Handbook to support teachers and authors in creating accessible and personalized resources. The areas of activity and the creation of tools and examples are rooted in the needs of the Floe community, solving issues that teachers and learners face in a way that fits into their existing workflow.
• Progress: • A guide for content creators and educators wishing to use EPUB3 was created. It outlines strategies for making complex and interactive information accessible such as graphics, math and scripting. • An exemplar was created using a physics simulation to illustrate the possibilities in improving EPUB accessibility.
• Results: • The EPUB3 guide was integrated into the Inclusive Learning Design Handbook, a resource that will be available in the DeveloperSpace. http://handbook.floeproject.org/index.php?title=Inclusive_EPUB_3 • Work will continue with PhET Interactive Simulations http://phet.colorado.edu/ to ensure the EPUB3 resource meets the needs of learning content authors.
Schedule and achievement of critical objectives All tasks are on schedule. All critical objectives have been achieved.
38 Deviations from work plan None
Corrective actions None
Statement on the use of resources Resources have been used as planned within the DoW
WP 303 – Assistance-on-Demand Service
Objectives for the period • To identify the features for Assistance-on-Demand, payment and funding, and connection “consumer-developer” that can be integrated in a commercial micro-tasking service. • To use the AOD framework of SP2 to enhance an already existing technical AOD set up.
Progress and significant results
Task 303.1 Consumer Assistance-on-Demand system • Progress: o Technosite technical team has been researching about the different ways and workflows in which the user-consumer expresses their demands. An initial scenario of accessibility-bug-reporting has been foreseen. The main research of this task has been combined with the research carried out in WP206 by doing field work and desk research. o The main results can be consulted in D206.1, nonetheless at the end of the implementation, a full documentation will be delivered in D303.1”Consumers, Business and Accessibility Assistance-on-Demand systems in a micro-tasking platform
Task 303.2 Business Assistance-on-Demand system • Progress: o For this activity, on this initial stage a look on the existing microlabora platform has been done. The different schemes coming from microtasking and crowdsourcing platforms have also been researched. As in the previous task, this also has been
39 research in combination with WP206 components. Through virtual ethnography, the different ways in which demands are expressed by business in the net were also described. o The main results can be consulted in D206.1, nonetheless at the end of the implementation, a full documentation will be delivered in “D303.1Consumers, Business and Accessibility Assistance-on-Demand systems in a micro-tasking platform” .
Task 303.3 Enhancing existing technical AOD services (LIFEtool) No Progress has been made since the start of this task is foreseen for next year. The main result foreseen for M42 will be D303.2 Assistance-on-Demand integrated in an existing technical support AOD service.
Schedule and achievement of critical objectives All tasks are on schedule. All critical objectives have been achieved.
Deviations from work plan None
Corrective actions No Corrective Actions need
Statement on the use of resources Due to the fact that an initial effort by Ilunion (TECH) was put into WP206 and that many research activities are somewhat connected between both work packages, the main effort for WP3 will be done from the second year of the project onwards. Therefore the use of some by-products of WP206 has enabled us to save Manpower for further efforts.
3.2.4. Work Packages of Sub Project 4
WP 401 – Evaluation framework and technical validation
Objectives for the period • Identify and document a complete set of evaluation methods used in Prosperity4All.
40 • To define the basic evaluation planning framework for iterative testing of the different P4All developments. • To define specific validation plans for tools/applications developed in the framework of SP2/SP3. • Activate all project partners relevant to the technical validation (notably SP2 and SP3 partners) and achieve a common understanding of the role of technical validation in the project; collect everyone’s feedback on the respective technical validation plans; • Establish the high level technical validation framework as groundwork for all specific technical validation activities to take place during the project lifetime. • Establish a preliminary technical validation plan for all verification and validation activities to be conducted for software items of SP2 and SP3 and deliver D401.2.
Progress and significant results • Evaluation gained great attention directly during the project kick-off in February. The whole third day of the meeting was dedicated to evaluation issues. All SP-leaders and some selected WP-leaders were participating to discuss and shape the directions of evaluation in Prosperity4All. • Organized separate online meetings in order to define their requirements, ideas and preferences with SP2, SP3 and SP4 teams in order to dynamically shape the dimensions of the framework and communicated the results to P4All members. • Established a regular bi-weekly SP4 meeting and communicated with partners about aspects related to evaluation and initial SP2 and SP3 status. Leading teams from SP1, SP2, and SP3 participate in these meetings. • Very soon - also after a couple of discussions during the biweekly P4A conference calls - it became clear that evaluation in this project must go beyond technical validation and usability testing. The assessment of the economic and societal objectives of the project requires particular (and innovative) evaluation approaches and methods. • Created an online Google Space dedicated to SP4 activities and share it with the Consortium. • Conducted separate Skype calls with SP1 partners in order to define to actors and their functional roles within the project. • The overall project objectives and KPIs as described in the Technical Annex have been mapped to appropriate evaluation procedures and techniques. • A detailed description of the evaluation framework with the specific evaluation objectives for testing with implementers and end-users, a time plan with the different evaluation phases, plans for recruitment of participants, and ethical evaluation issues was added in D401. • An initial matching template was prepared and communicated to SP2 and SP3 teams in order to define their choices, especially with regards to the first iteration in order to initiate the matching process. • Submitted D401.1 “Evaluation framework and supporting materials for evaluation design” to EC which included two major parts: The actual framework for carrying out the evaluations and the compilation of appropriate methods.
Task 401.1 Evaluation methods and tools This task ended in M8. • Progress: o Defined the overarching evaluation questions for the evaluation to be carried out within the project.
41 o Connected the Key Performance Indicators (KPIs) within the project with specific end of project success criteria and established the link with the evaluation questions to be asked for the project. o Set the dimensions and logical evaluation models for the three evaluation phases with implementers, the two with end-users and the impact estimations and assessments. o Identified ethical issues related to the conduction of pilot sites and addressed them in close collaboration with FhG-IAO, the project’s ethics manager.
• Results: o Prepared elaborate tables connecting high level objectives, with constructs, appropriate methods, techniques and specific indicators, as well as success thresholds, separately for testing with implementers, end-users and analytics relevant to impact estimations. o The tables per target group involved in all iterations were uploaded on the GPII Wiki along with resources about instruments, questionnaires and measures. These tables will serve as a pool and reference for planning the separate evaluation phases; connecting, thus, the framework with the actual planning that will take place during the lifetime of the project. o The work carried out in this task is extensively depicted in D401.1, submitted to EC. o A detailed ethics section was prepared, including a preliminary consent form template, an application for local/regional ethics committee template, and considerations for recruiting participants with various accessibility needs and they were made available to the project’s wiki.
Task 401.2 Participants recruitment • Progress: o Defined the appropriate methods for recruitment on high level, general level and they have documented in D401.1. o Defined the different recruitment methods by segmenting the different audiences to be targeted for recruitment based on the categorisation of actors, as defined in SP1. The main criteria for profiling have been revised. These criteria were related to digital literacy among users and accessibility competence among developers. Furthermore, a close look at the different ways to engage users for evaluation has been done. The ecosystem approach for this evaluation has been taken into account for the recruitment strategy.
• Results: o A definition of the different recruitment material (toolkit) was done in order to standarise the process. An initial recruitment process was put in place related to co- design of 206WP tools which also serves as an initial stage of the formative evaluation. o The main documentation related to this activity will be integrated in D402.1 and D402.2 and the exact planning for involving the P4A Collaborative Network for initially conducting the evaluations with implementers is currently underway and will be included in D402.1.
Task 401.3 Technical validation activities • Progress:
42 o Identified requirements related to a realistic technical validation plan for each SP2 and SP3 main deliverable; o Intense communication with all SP2 and SP3 teams, conducted mainly over phone calls and email as well as the project wiki and Google drive, to understand which are the main deliverables that need to undergo regular technical validation and to establish a common understanding of the role of technical validation in the project; the SILO technical validation team provided at many occasions support and explanations about the technical validation plan and the input expected to the data collection template; o Establishment of high level technical validation methodology and strategy and definition of basic steps of each SP2/SP3 technical validation plan; o Creation of a data collection template for collecting the structured feedback of each SP2/SP3 development team. Using this template, the following information was collected from each SP2 and SP3 team, at activity level: º the tools/services that will be delivered by SP2; º the enriched applications that will be delivered by SP3 thanks to the use of SP2/Dspace tools; º the responsible partners/development teams; º the main features and capabilities of each SP2/SP3 deliverable; º the technologies necessary for conducting the technical validation of each SP2/SP3 deliverable; º the final users of each SP2/SP3 deliverable; º the test scenarios of each deliverable under technical validation. o Compilation of D401.2, including the results of all work described above and submission to the EC; o Communication with all other SP4 teams (participation to regular SP4 calls and other communication events) and contribution to the definition of the overall high level evaluation framework, evaluation KPIs and measurement methods, evaluation plan for developers (1st iteration); o Effort in T401.3 for SILO also includes general SP3 coordination work (organisation of SP3 meetings, SP3 feedback collection, contribution to establishment of mapping between SP3 applications and SP2 tools and services, etc.).
• Results: o Software verification and validation plan of SP2 established; o Software verification and validation plan of SP3 established; o Compilation and submission of D401.2; o 1st technical validation iteration is ready to start as soon as SP2/SP3 prototypes are made available.
Schedule and achievement of critical objectives • The work carried out within this work package is according to schedule. All anticipated achievements are according to plan and fulfilled for all target groups. • Up to now, all tasks are on schedule. All critical objectives have been achieved. However, the strong dependency of the schedule of T401.3 with the delivery schedules of the respective SP2 and SP3 prototype deliverables for each testing iteration should be noted. Potential delays in the delivery of SP2/SP3 prototypes will affect the schedule of T401.3 work.
Deviations from work plan and corrective actions
43 • Deliverable D401.1 was ready for submission M8 but it was finally submitted to EC M12 as there was a delay because of changes happening within the project and preparation of evaluation specific Wiki content. It was anticipated to enrich the deliverable with the demand and supply chains and respective business scenarios when they were finalised in SP1. Then these could be applied and used for creating the application scenarios to be added in D401.1. However, due to the delays in WP 102 the available information on application scenarios and demand-supply chains is not stable yet. The deliverable 401.1 was nevertheless submitted and some information was drawn from informal sources (direct communication with SP 1 players instead of official deliverable D 102.1) It was decided to add them later to the deliverable, to avoid further delays.
• Although the high level technical validation framework was available on time (M10), the delivery of D401.2 to the EC was made with a 2 month delay. This is because of the time necessary to establish a common understanding about the technical validation work and to collect the feedback of all SP2 and SP3 teams, at activity level, that took longer than expected. On the other hand, the vast majority of technical validation plans, as well as the almost full draft D401.2, were already available before the end of M11 so the effect of this delay on other project tasks was minimal.
• Increased resources were allocated to this task and more intense communication with SP2 and SP3 partners who were delaying sending their feedback was undertaken by the task leader (SILO) in order to minimise the delay. In the end, all SP2 and SP3 partners provided the necessary feedback (subject to continuous updating throughout the project, as per the DoW).
Statement on the use of resources • There are no deviations worth reporting for T401.1. • In this period the amount of resources consumed by Ilunion (TECH) for T401.2 has been 0.55 MM, whereas the planned was 1 MM. This is due to the fact that the main effort regarding recruitment will be done in the different iterations. • There are no deviations worth-reporting between actual and planned person-months for T401.3.
44 WP 402 – Evaluation with implementers
Objectives for the period • To plan the evaluations with implementers. • To provide a generic framework to SP2 implementers that will enable them to collect mostly formative data for the first iteration. • To provide assessment tools to gather qualitative feedback by only internal implementers.
Progress and significant results
Task 402.1 Evaluation plan and instantiation for pilots with implementers • Progress: o Defined the evaluation questions for the evaluations to be carried out for all iteration phases. o Prepared a preliminary draft of the evaluation plans with implementers. o Categorised the SP2 and SP3 developments in their main categories based on their purpose and use. o Initial questions were prepared and a first draft for the baseline interviews for implementers was uploaded in the common SP4 space and was made available to involved partners. Prepared an initial matching template for connecting the SP2 resources, tools and applications with SP3 products and communicated to SP2 and SP3 teams for further elaboration as an online document.
• Results: o The initial timeplan is ready and available in D402.1 o The initial mitigation strategy is available in D402.1 o The logical model for implementers is presented in D402.1. o A pool of methods and techniques is available and documented in-depth in the GPII wiki.
Task 402.2 Iterative pilot testing with implementers • Progress: o Collaboration between SP2 and SP3 teams was established in order to define the requirements for testing with implementers. o Contacts have been established for conducting the first iteration. o The preliminary interview with implementers is drafted and available. o A timeline was developed for technical validation
• Results: o Timeline is set for first iteration to be carried out May 2015. o Technical validation will be carried out one month prior to any testing. o The first set of matched SP2 and SP3 integrations was conducted. Schedule and achievement of critical objectives The initial backbone was documented in the evaluation framework and a lot of work is already available for application in the evaluation plans for implementers. The work in this WP is very closely related and dependent to work and progress achieved in SP2 and SP3 developments.
Deviations from work plan and corrective actions
45 • The evaluation plans are undergoing as the actual mapping between SP2 and SP3 developments started after the end of the first year as since it was important for involved SP2 and SP3 teams to discuss it during the Developers Fair at the annual plenary meeting at Stuttgart, 12 of February 2015. Therefore, the actual planning started after the discussions and matching between the two development-oriented SPs in order to provide a mapping of which developments will be available for the first iteration, to proceed in preparing the actual plans and materials. This small delay has been recapitulated in the meantime and will not have any effect on the progress of the project. • There is a small delay in the first iteration. Testing will start when the first prototypes and proofs-of-concept are available. Initially, they were scheduled for February 2015 but as work within SP4 is heavily depending on when the initial versions will be available, timeline for first iteration was postponed to May 2015. This will allow development teams to deliver prototypes with more working functionalities instead of mock-ups, which is expected to be beneficial for the testing. • Testing of the AOD (WP205) has been added to the testing plan, although it was not foreseen at this early stage of the project to test any user-facing tools, thanks to the availability of an early functional prototype (earlier than planned in the DoW) from WP205 and the desire to collect early user feedback. • D402.1 will be delivered end of April due to an unforeseen case of illness.
Statement on the use of resources Most work within WP402 is still to come, so for this first reporting period only small use of resources has to be reported. This is consistent with the plan within the DoW.
WP 403 – Evaluation with end-users Not yet started (M30)
WP 404 – Assessment of Prosperty4All platform Not yet started (M18)
WP 405 – Demonstration Not yet started (M18)
46 3.2.5. Work Packages of Sub Project 5
WP 501 – Project Management All Work done as well as schedule or possible deviations within WP 501 are described in chapter 5.1
Statement on the use of resources The use of resources is in plan with the DoW.
WP 502 – Dissemination and Training
Objectives for the period • Develop the dissemination plan, to include a successful dissemination strategy to identify key targets, channels and objectives of the dissemination actions. • Design and launch a project website to serve as a place where all the information and latest outcomes of the project can be accessed. • Start building a contact database of relevant stakeholders and key messages targeted to each audience stakeholders. • Participate in a series of meetings, conference and workshops to address different target audiences. • Set up a training environment.
List of deliverables submitted during year 1 • D502.1 Dissemination plan and activities • D502.2 Project website • D502.3 Dissemination materials, including leaflets and posters and electronic media.
Progress and significant results During the first year of the project: • Most dissemination objectives were achieved, with the exception of the forum participation that will be strengthen as the project advances, and the 2nd newsletter was to be send at the beginning of year 2, to ensure there were some project news relevant to the audience and the items mentioned below in the deviation section, in which refer to partner’s event dates moved, and the activities proposed will be carried out at a later time during the project • Partners have been active and contributed to disseminating the work of P4A
47 • Systems are in place to effectively disseminate, gather and evaluate results
The progress and results achieved per task are described next:
Task 502.1 Dissemination plan, material and project website • Progress: o A revision of the Dissemination plan has been done to facilitate the qualitative and quantitative measurement of dissemination activities done through different channels. o Different project materials have been produced: º Logo º Website º Documents and templates º 2 project leaflets º 1 roll-up º 1 flash drive (with the project’s information) º 2 press releases º 1 newsletters º 1 newsletters email-briefs o Social media accounts have been opened: linkedin, twitter, youtube and slideshare. o In month 3 the project website was launched and is regularly updated with the project’s latest outcome. • Results: The project website conforms to Conformance Level “AA” of the W3C-WAI WCAG 2.0 (Web Content Accessibility Guidelines). In addition it was created using on a new form of WordPress template designed by a Prosperity4All partner (IDRC), which allows any user to adapt the interface to adapt to their specific needs and preferences.
The first year of Prosperity4All has been especially relevant in setting up the online stakeholders’ engagement strategy of the project to engage potential collaborators, users, developers, policy makers etc. in the discussions and debate online. Partners have been very active on social media too.
During this first year, P4A produced 1 video interview (https://www.youtube.com/user/p4allvideos) The P4A video interview is the first of a series of videos that will be produced to disseminate the project and its benefits, (viewed more than 301 times, as YouTube is not providing views beyond this number at this point).
The P4A’s twitter reach for Year 1 (mentions+tweets+retweets+ favourites) has been over 25,000 users. Partner NCBI sent P4A’s press release to their CEUD-ICT mailing list (181 members), a public discussion list of academics, practitioners, and UD advocates, opening discussion and contributions on Prosperity4All within this list.
Task 502.2 Events and other dissemination activities
See also chapter 5.2 for details on dissemination. • Progress: o Creation of a contact database (ongoing): >500 o Project’s appearance in partners’ corporate websites and dissemination networks.
48 o 11 one to one meetings and assistance to 8 networking events o 8 workshops and webinars have been organised o 18 presentations in conferences o 22 international publications Task 502.3 End user’s and Stakeholder Connections This task begins on M12.
Task 502.4 Training Activities • Progress: Prepared a training template in order to gather feedback from the partners about the following: o Preferred look and feel o Priorities in implementation o Training platform specificities o Training platform options o Connection with other SPs
• Results: An initial version of the training platform created on Atutor training platform was communicated to the partners including the following: o Categories of users o Structure of curriculum o Links with the website o Integrated accessibility preferences as existing in C4A Schedule and achievement of critical objectives All tasks are on schedule. All critical objectives have been achieved.
Deviations from work plan and corrective actions Deviation #1 In DoW (Annex 1, part B, v.1.5, 31 July 2013, p.161) it is stated that: “Partner KI-I will organize a Special Thematic Session regarding the Prosperity4All topics on the ICCHP Conferences in 2014 and 2016.” Corrective action: The STS was not organized in ICCHP 2014. Instead partner KI-I organized in 2014 a workshop at the IKTForum. In addition, partner SENSUS assisted ICCHP 2014 and presented the paper: “The Use of Assistive Technologies to Facilitate Flexible Learnining in Higher Education,” Goldrick, M, Christensen Lars, B, and Stevns, T.
Deviation #2 In DoW (Annex 1, part B, v.1.5, 31 July 2013, p.162) it is stated that:
"In addition to the general dissemination with the projects partners’ business networks, the project will exploit the participation of AGE (and its network) on the consortium in order to research to a larger number of stakeholders in Europe (mainly) and beyond. In particular: AGE will disseminate the developments and results of Prosperity4All to its network of about 160 older people’s organisations and to EU policy makers and stakeholders (European Parliament Intergroup on Ageing and Solidarity between Generations, European Commission,
49 EUnetworks, etc) through various channels (AGE monthly online newsletter, brochures, participation in seminars, workshops and campaigns and the AGE website). AGe will regularly update on Prosperity4All its Universal Access and Independent Living Expert Group, composed of experts from the different EU Member States, who can disseminate the results of the project at national level. AGE also set up an EU virtual network on age friendly environments addressing stakeholders and local/regional authorities willing to find innovative solutions to support active ageing and develop age friendly environments, which could be used as another dissemination channel. Finally, AGE will be able to disseminate the developments and results of the project through the contacts it built within the different expert groups and initiatives it takes part in, i.e. AAL Programme, standardization, European Innovation Partnership on Active and Healthy Ageing, Vodafone Smart Accessibility Awards,etc."
Corrective action: Beginning of 2014 the AGE expert group has been reorganized. That has the effect that groups named in the DoW don’t exist anymore. The UAIL expert group has now become the Task force on Accessibility. Another task force on Standardization has been created. When P4A’s project needs users’ point of view on specific activities, the project can ask for feedback to these new task forces. The EU virtual network on age-friendly environments has become the AFE- INNOVNET. A webpage on P4All can be found in: www.afeinnovnet.eu.
For P4A, this is a minor deviation, as all activities that AGE planned, will be done as planned, but within a changed communication structure.
Statement on the use of resources Overall the use of resources is more or less in accordance to the DoW, although there are minor things to note in detail:
Re. to Dissemination: • RtF-I: A significantly higher number of person-months have been consumed in this WP for Year 1 due to the intensive work undertaken at the beginning of the project, which includes the creation of the first dissemination plan, the website, all dissemination materials templates and basic designs, and participation in one of the international events committed in the DoW (HCII). This deviation is not expected to negatively affect the WP, on the contrary, it has been deliberately pursued to ensure a good base is set up for this WP to achieve the project’s dissemination goals. • HdM: Spent some more than 25% in the first year. This was due to a focus on CENTRIC 2014 and HCII 2015 (we got 4 papers accepted at HCII 2015).
Re. to Training Activities: • The actual PMs for T502.4 were 0.42 PM and the planned were 2 PMs. Less PMs are reported because the work carried out involved the development of an initial training platform and work on the training courses and materials was not possible to start during the first year of the project, as development teams were still working and communicating in order to search and define the tools they would like to use.
50
WP 503 – Market observatory and exploitation
Objectives for the period • Conduct a thorough Market analysis, supported by the technological state of the art surveys of SP1 (due M18). • Begin to review trends and alternate predictive scenarios detailing possible 5 -10 year trends in technology • Begin to explore revenue models will also be explored to help ensure sustainability while keeping the service open to all. • Reuse of existing standards and technologies (in particular by mainstream), wherever possible. • Develop and validate new standards on GPII technologies, wherever necessary. • Work towards harmonization, adoption and inclusion of the GPII standards in standardization, industry, research and governments.
Progress and significant results • The market report is ongoing and going through its final phase for delivery on M18. • Public release of the revised Universal Remote Console (URC) standard ISO/IEC 24752 in 5 parts, and CD stage for the GPII preferences standard ISO/IEC 24751-3.
The progress and results achieved per task are described next:
Task 503.1 Market observatory and business models
• Progress: For this first year the activities concentrated on determining the main actors on the technology trends, with a particular attention on the open source companies.
• Results: The scope of this first activity, in collaboration with SP1, will be finalized by Month 18 with the first version of the deliverable. Academic courses were analysed to determine the attention the educational world is giving to assistive technologies and to challenge the technical forecast for next 5-10 years.
Task 503.2 Exploitation and deployment
51 This task begins on M12.
Task 503.3 Market observatory and business models
• Progress: Several partners are working in a collaborative fashion on standard-related activities. For coordination purposes, an internal mailing list was created, a first telecon took place, and a portal page on the GPII Wiki was established. A GPII standardization roadmap was set up as a working document, including items for international standardization, national standardization, cooperation and concertation activities, and planning & outcomes. An initial set of standards related to personalization has been identified, in preparation of D503.4, Standardization and Concertation Report (due M18).
• Results: Public release of the revised Universal Remote Console (URC) standard ISO/IEC 24752 in 5 parts, as of 2014-12-12. CD stage for the GPII preferences standard ISO/IEC 24751-3, as of 2014-09-18.
Schedule and achievement of critical objectives All tasks are on schedule. All critical objectives have been achieved.
Deviations from work plan and corrective actions None
Statement on the use of resources • Re. to Market observatory: SP1 started late due to a partner change, therefore less resources used than initially planned. These resources will be needed later on within the project. • Re. to Standardization: we are pretty much in line with our planning regarding resources in WP502 and WP503. In general, we have not planned for a linear spending of PMs during the 4 years of the project.
52 4. DELIVERABLES AND MILESTONES TABLES
Deliverables (excluding the periodic and final reports)
TABLE 1. DELIVERABLES Del. Deliverable name WP Nature Delivery Actual / Forecast Planned Comments no. no. date from delivery date effort (from Annex I Annex I) (proj month) 501.1 Project Presentation 501 R 1 1 3 PM and Project Description Leaflet 502.2 Project website 502 O 1 1 2 PM 101.1 Documented process 101 R 3 4 5.5 PM for modelling and analysis and report format for reporting back to project 501.2 Management 501 R 3 4 3 PM First version delivered M3. Update on Ethics delivered in M10 Handbook, Knowledge Management System (KMS) and Quality and Risk Control Plan, Ethics Manual 502.1 Dissemination Plan and 502 R 4 7 45.5 PM Activities 502.3 Dissemination 502 O 6 7 2 PM materials, including leaflets and posters and electronic media 401.1 Evaluation framework 401 R 8 12 10 PM Deliverable D401.1 was ready for submission M8 but it was finally and supporting material submitted to EC in M12 as there was a delay because of changes for evaluation design happening within the project and preparation of evaluation specific 53 Wiki content. It was anticipated to enrich the deliverable with the demand and supply chains and respective business scenarios when they were finalised in SP1. Then these could be applied and used for creating the application scenarios to be added in D401.1. However, due to the delays in WP 102 the available information on application scenarios and demand-supply chains was not stable yet. The deliverable 401.1 was nevertheless submitted and some information was drawn from informal sources (direct communication with SP 1 players instead of official deliverable D 102.1) It was decided to add them later to the deliverable, to avoid further delays. 401.2 Prosperity4All 401 R 10 12 6 PM technical validation: plans and results 202.1 Report on repository 202 R 12 14 4 PM standards, common Interfaces and APIs 206.1 Best ways to engage 206 R 12 12 16.5 PM customers over time 102.1 Map of modelling 102 R 12 14 8.5 PM methods and approach
Forecast: Deliverables not yet delivered:
402.1 Evaluation plan for 402 R 12 15 5 PM Deliverable is slightly delayed. Work on content is almost finished. evaluation with Deliverable will be delivered in M15. implementers 101.2 Comprehensive and 101 R 12 15 18 PM Deliverable is slightly delayed. Deliverable is currently within project classified list of internal review process and will be delivered in M15. candidate market models and strategies, together with brief descriptions of each
54 Milestones
TABLE 2. MILESTONES Milestone Milestone name Means of verification (from Annex I) Delivery Achieved Actual / Comments date from Yes/No Forecast no. Annex I achievement date MS111 Market models and Delivery of D101.2 12 No M15 Milestone will be reached in M15, when strategies and D101.2 will be delivered sustainability models relevant to Prosperity4All MS221 Common Individual (partner) and common 12 Yes M12 component (stakeholder) goals for the component repository collection defined and documented in the methodology WiKi. Initial Listing pages for each component presented in the WiKi following common description structure, metadata, categorization. Delivery of D202.14
4 No Means of verification defined for this Milestone within Annex I
55 5. PROJECT MANAGEMENT
5.1. Management activities
5.1.1. Consortium management tasks and achievements • Set-up and establish work, collaboration, and communication procedures o In the very beginning of the project, a Management Handbook has been created and published within the consortium to define the management and collaboration procedures in the project (D501.2, Month 4). o A google site has been set up as a common reference for collaboration resources (https://sites.google.com/a/raisingthefloor.org/p4amanage/). It includes a list of people in the project with their contact details, a table of deliverables and deadlines, an easy-to- read version of the work programme, a page with all meeting dates and meeting minutes, scanned versions of all contracts and dissemination materials for download. o A google drive has been set up for sharing presentations and for collaboration on working versions of internal and official documents. o Set up technical facilities for teleconferences at GoToMeeting.
• Plan, schedule and monitor the timely procession of tasks in the consortium o A review process for all project deliverables has been defined and specified in the Management Handbook. o The implementation of this review plan has been specified: Internal reviewers have been assigned, due dates for all intermediate versions of the deliverables have been scheduled (https://sites.google.com/a/raisingthefloor.org/p4amanage/home/ procedures/deliverable-peer-review-status). o A service of reminder emails has been installed to make sure that partners are aware of relevant due dates.
• Reporting and Quality Assurance o All deliverables submitted so far have been reviewed by the Coordinators (in addition to the technical reviewers as specified in the internal review schedule)
• Help partners with organisational and administrative issues o Clarify reimbursement and other financial issues for partners new to FP 7 o Mediate between URF validation services / PO and partners to clarify their status. o The biggest administrative issue in the first six months was clarifying LSEE’s status in the project. LSEE left the project, see chapter 5.1.4.
• Foster communication and collaboration between all relevant partners in the consortium o Organize and invite to regular plenary teleconferences (bi-weekly) to discuss topics of general interest, especially topics with specific needs for collaboration across the different Sub Projects.
• Prepare and coordinate an amendment of the Description of Work (DoW) (04 February 2015) o Compensate for LSEE’s withdrawal from the project (see below) and o Restructure and reschedule SP 1 activities and deliverables in close collaboration with the main SP 1 contributors IDRC and JIBS.
56
5.1.2. List of project meetings, dates and venues • A three-day Kick-Off-Meeting (plenary meeting) has been organized and held at the Coordinator’s premises in February 2014. • Bi-weekly conference calls have been carried out for coordination in the P4A leaders’ team including SP-leaders, WP-leaders and other key partners. • A three-day plenary meeting at the Coordinator’s premises has been planned and prepared for February 2015 (Month 13). • Several face-to-face meetings and telcos have taken place within the different sub projects. • A public, visible dissemination event and GPII networking opportunity at HCII 2014, Crete, has been organized: o Almost every partner of P4A took part o 35 GPII-related paper presentations in six interactive paper sessions (see http://raisingthefloor.org/HCII2014). o Break-out sessions on specific Prosperity4All Topics (internal project meetings); e.g. coordination between SP technologies and SP 3 implementers, integration of SP 2 building blocks and tools into the overall architecture, alignment of SP 2 developments, etc. o Collaboration/Networking Meeting with all GPII projects • The first Annual Advisory Board Meeting has been organized and prepared for 18 March 2015 (Month 14). The Advisory Board Meeting was held as a teleconference/webinar to make it easier for our non-European board members to join.
5.1.3. Ethics • An Ethics Manual for implementation as well as testing activities has been written. • The Manual aims at being a manual for P4A project partners as well as all persons that work on the GPII. • Working materials on ethical issues, such as questionnaires, informed consent, checklist etc. have been provided. • All partners have been informed about the ethics-related activities and materials. Feedback has been collected through a questionnaire. The feedback will be used to make the document even more useful for the partners.
5.1.4. Changes within the consortium
5.1.4.1. LSEE LSEE chose to withdraw from the consortium of Prosperity4All due to financial issues. They had expected to be accepted as a SME with 75% EC funding. When they realized that this was not possible because of their association with the London School of Economics (LSE), they did not find themselves able to bear the higher co-financing necessary (50%).
This process of realizing the new situation, deciding to withdraw and carrying out the necessary administrative steps took about four months on LSEE’s side. The unclear situation in the meanwhile caused delays in all tasks with significant (planned) participation of LSEE. We had to wait until end of October 2014 to receive the official withdrawal letter from LSEE. Then, an amendment of the Description of Work (DoW) was prepared.
57
The decision was made to shift all LSEE assigned tasks, deliverables, and funding to JIBS (Jonkoping International Business School), who was already a significant contributor to the tasks LSEE was going to lead, and was the leader for the other SP1 tasks. Once that was accomplished, work started on the replanning of SP1 and preparing the DoW Amendment (see above).
5.1.4.2. Clevercherry The partner Clevercherry (CC) noticed in March 2015, that not the current organization “Clevercherry Limited” is partner within the consortium, but the previous organization “Clevercherry.com Limited”. They will try to do an UTRO (universal transfer of rights and obligations) within the next weeks.
5.1.5. Communication and collaboration with other Projects • Close collaboration with the other GPII-projects, especially Cloud4All, in all overall architectural and infrastructural regards. • Bi-weekly conference calls for coordination with other GPII-players. • GPII networking event at HCII 2014, see above (section 5.1.2).
5.1.6. Risk Assessment Part B of the DoW lists a set of general risks to the whole project and corresponding plans for mitigation and contingency (p. 71). The following table provides an assessment of these general risks. At the current point in the project, most risks are still difficult to assess because they relate to later activities and events.
Risk # SP/WP Description Probability Impact Assessment 1 SP2 & Serious delays in the Low Minor At the moment none of the SP 2 SP3 technical deliverables overall developments is delayed (see section 3.2.2). High that we Some tasks are even more advanced than will lose one originally planned (e.g. WP 205 AoD). out of the Most SP 3 tasks have just started in Month 6. long list All tasks are running as scheduled or even better. We will be able to present first SP 3 implementations at the first annual review meeting. 2 SP3 One of the companies High Medium Cannot be assessed at this early stage. implementing the solutions in their products in SP3 fails to deliver
3 SP4 Recruitment actions Medium Medium The recruitment has been very well prepared taken fail to secure by defined target groups and recruitment enough developers and methods (cf. D401.1). end- users for the project test 4 SP5 Coordination problems Medium High The coordination of this complex project caused by the complexity remains a challenge. Up to now, no of the work plan and the coordination problems have become size of the Consortium apparent.
58 5 SP5 Lack of sufficient Medium Medium Dissemination has been a strong aspect of outreach. This is a broad the project in the first year. We will try to project with many keep up this high level of engagement of all stakeholders that are not partners in outreach activities. all easy to reach.
6 All Consortium partners Low High No clues for potential conflicts at this stage. cannot agree because different interests arise
7 All Failure or Low Medium The only case of underperformance in the underperformance of one consortium was due to uncertainty issues of the partners about the partner’s financial covering and continued participation in the project (cf. section 5.1.4.1). This issue has been cleared. 8 All Difficulties with Low Medium Effective knowledge-sharing platforms are in knowledge transfer within place from other GPII projects. the Consortium
9 All Cloud4all project fails Low Low Cloud4All has developed in an excellent manner. With less than one year left for the C4A project failure becomes extremely improbable.
The assessment of the WP-specific risks (table 5 in the DoW) is covered in the WP descriptions (section 3.2) where appropriate.
5.2. Dissemination and use of the knowledge P4A partners have been very active in this first year on Conference presentations and publications targeted to different TAGs. Although initially planned for Month 36, most partners were present and actively involved in the major international conference HCII with 15 sub-conference events (presentations, demonstrations, and publications). Moreover, partners also participated in the CSUN conference, the Mozilla Festival 2014 and the Funka Accessibility Days, discussions and presentations were held on P4A and web accessibility.
P4A partners have attended various events outside Europe, greatly facilitated by US and Canadian P4A partners. The project has been presented in Washington DC, USA, (M-Enabling 2014 and A11Y Accessibility Conference), in San Diego, USA, (CSUN Conference), in Sacramento, USA (AHEAD Conference), in Irvine, USA (DML 2014) in Toronto, Canada, (DEEP Conference and A11y Camp), in Houston, USA, (Openstax Annual Conference), in Quebec, Canada, (VTE Lab), in Boston USA (DML2014), in Monteria, Colombia (CAVA Conference), in Santiago de Chile (CEDETI), and in Hawaii, USA (Pacific Rom Conference). Additionally, P4A has also been presented in the United Nations in the Seventh session of the Conference of States Parties to the Convention on the Rights of Persons with disabilities.
During the first year of P4A, 11 one to one meetings were held with the different TAGs identified in our dissemination strategy, in 6 different cities. Meetings held for potential collaborations have been a priority and mostly participants have been: developers, end users and their associations, industry organizations and service providers, and members of the scientific community. Additionally, partner JIBS organizes monthly meetings with informatics doctoral candidates.
59
Project partners attended 8 networking events with developers, industry organizations, scientific community, and end user associations. Partner HDM organized for the first time a networking event on December 5th held under the theme “Innovation through Accessibility“. Prosperity4All Project was presented and visitors from industry, public policy, and university attended the event. After this first experience it is planned that the “Accessibility Day” will be organized every year. Partner SENSUS attended two networking events, Enviter network in Krakow, Poland, and another event targeted to dyslexia specialists in Nuuk, Greenland. IDRC organized a Hackathon in Madison, Wisconsin. P4A’s key communication message varies depending on the target audiences’ of these networking events.
5.2.1. Web Site www.prosperity4all.eu and social media
Year 1 - Online presence: Launched the website www.prosperity4all.eu and updated it on an ongoing basis. Reached the 10 P4A’s target audience groups to raise project’s awareness and to inform key stakeholders. Created social media accounts in YouTube, Twitter, LinkedIn, and SlideShare. Welcomed 166 Twitter followers, reached over 25,000 people, via Twitter. Sent 565 personalized newsletter mailings to key stakeholders. 17 partners have posted information on P4A in their corporate websites (see table below). Received mentions in 12 other websites. Produced 1 end-user video interview with over 300 visits (views limited by YouTube). Distributed 4 user video demos in YouTube channel.
List of partner’s websites Channel Partner Link Partner’s corporate web AGE http://www.age-platform.eu/news-press/all-latest-news/all-eu-news/31-age-work/age-policy- work/accessibility/latest-news/2037-launch-of-prosperity4all-project-a-new-ecosystem-for- accessible-technologies Partner’s corporate web AGE http://www.age-platform.eu/age-work/age-projects/new-technologies-ict/2133-prosperity-for-all Partner’s corporate web CC http://clevercherry.com/#news-156 Partner’s corporate web CERTH http://www.imet.gr/Default.aspx?tabid=72&language=en-US Partner’s corporate web FHG http://www.hci.iao.fraunhofer.de/ Partner’s corporate web FHTW http://embsys.technikum-wien.at/projects/prosperity4all/index.php Partner’s corporate web FONCE http://www.fundaciononce.es/es/pagina/proyectos Partner’s corporate web GUADA http://www.consorciofernandodelosrios.es/ Partner’s corporate web HdM http://www.hdm-stuttgart.de/view_news?ident=news20140815152254 Partner’s corporate web Ki-I http://www.ki-i.at/index.php?id=57&L=- 1%27&tx_ttnews[tt_news]=299&cHash=2725abb25522fcf42df742af298ec4a6 Partner’s corporate web KIT http://www.teco.edu/research/prosperity4all/ Partner’s corporate web LIFETOOL http://www.lifetool.at/research-development/rd-projects/project- details.html?L=1&tx_ttnews%5Btt_news%5D=488&cHash=16da3167649ab086ffe63cad05bb3 cbc Partner’s corporate web MLS http://www.mls.gr/?pid=184&la=1
60 Partner’s corporate OPENDIR http://opendirective.net/blog/2014/02/user-experiences-for-low-digital-literacy-and-cognitive- web/blog disabilities/ Partner’s corporate web PCF http://about.amara.org/2014/02/28/launch-of-p4a/ Partner’s corporate web SENSUS http://www.robobraille.org/robobraille-projects Partner’s corporate web Singularlogic http://portal.singularlogic.eu/eu-projects Partner’s corporate web UCY http://www.cs.ucy.ac.cy/seit/index.php?p=p4all
5.2.2. Events Year 1 - Face to face participation: 11 one to one meetings and 8 networking events (see table below). Project partners attended 8 networking events with developers, industry organizations, scientific community, and end user associations. Partner HDM organized for the first time a networking event on December 5th held under the theme “Innovation through Accessibility“. Prosperity4All Project was presented and visitors from industry, public policy, and university attended the event. After this first experience it is planned that the “Accessibility Day” will be organized every year. Partner SENSUS attended two networking events, Enviter network in Krakow, Poland, and another event targeted to dyslexia specialists in Nuuk, Greenland. IDRC organized a Hackathon in Madison, Wisconsin. P4A’s key communication message varies depending on the target audiences’ of these networking events. 8 workshops (see table below) 17 presentations on conferences (+ the presentations on the HCII 2014) Organization of a complete mini-conference thread at HCII 2014, with a total of 35 papers and 15 sub-events Attended 14 events outside Europe, (United States, Canada and Colombia), including a presentation in the United Nations (Convention on the Rights of Persons with Disabilities).
List of One to One Meetings and networking events
Date Partner Message Type/Participants City April 15th OPENDIR P4A work on cognitive accessibility Meeting. Steffan Johannson Online May 8th HdM Work together on the URC ecosystem Meeting. SUCH project Saarbrücken members September 15th IDRC PGA workshop with stakeholders and Meeting. IDRC team and PGA Washington D.C. 16th co-design team team October 10th MLS Meeting to discuss the project's plan Meeting. Project’s members. Thessaloniki and progress October 15th SENSUS Infrastructure, collaboration, project Networking event. Dyslexia Nuuk, Greenland dissemination specialists October 16th, 17th IDRC P4A within DEEP Conference Meeting. IDRC team hosted. Toronto, Ontario October 20th HdM Are personal interfaces relevant for Networking event. M2M Düsseldorf M2M? Summit attendees October 22nd FHG Adaptive user interfaces as technology Networking event. Attendees Stuttgart for elderly people of the business talk (around 100). October 23rd-26th IDRC Information on P4A’s project Meeting. GSOC Summit Mountain View participants & Justin Obara California
61 November 5th SENSUS Alternate media to support learning, Networking event. ENVITER Krakow, Poland search for partners and dissemination Network about P4All November 11th OPENDIR GPII, P4A and possibility of student Meeting. Education Online projects institution’s Board meeting December 1st HdM Networking event. 200 Brussels Looking for various collaborations in participants of EIP-AHA P4A Partner Meeting December 3rd, 4th RtF-I P4A latest developments Meeting. UIITA-RERC - All Madison Wisconsin Hands Meeting December, 4th IDRC Developments based on GPII Networking event. GPII Madison Wisconsin Hackathon participants December 5th HdM P4A and Innovation through Networking event. Stuttgart Accessibility Accessibility Day 100 students and people from industry December 5th RtF-I P4A latest developments Meeting. RtF-US Annual Madison Wisconsin Meeting January 7th, 2015 OPENDIR How GPII works and possible Meeting. Aiden Parr Online collaborations with P4A (UKATNews) January 8th, 2015 OPENDIR GPII, P4A use in W3C cognitive Meeting. Lisa Sleeman (W3C Online accessibly work coga11y task force) January 15th, 2015 CC Presentation of P4All at partner’s Networking event. Elders-UP Seville, Spain meeting for other EU project (Elders- Partners UP)
List of Workshops
Date Partner Title of workshop Participants City February 19th HdM AAL Interoperability Days 40 Brussels April 2nd SENSUS ROBOBRAILLE. Workshop at University Cluj-Napoca UBB May 5th HdM EIP-AHA C2 Workshop 50 Berlin July 2nd KI-I AsTeRICS Workshop 50 Linz July 7th OPENDIR Final Project: Possibility student accessibility software competition. SS12EU finals at ICCHP November 3rd SENSUS Infrastructure, RoboBraille. Copenhague November 6th SENSUS Alternate formats, Infrastructure. Kracow SENSUS CEDETI 45 university Santiago de Chile Presentation and demo libraries of Chile
List of presentations at conferences
DATE PART EVENT/CONFERENCE PRESENTATION/PUBLICATION CITY AUTHORS/PRESENT NER ERS March 6th IDRC DML2014 Harnessing the Open Web To Create Irvine Presented by Michelle Inclusive Learning Environments D'Souza and Jess Mitchel March 19th IDRC CSUN Conference on Personalizing Interfaces: An Inclusive San Diego Presented by Dana Technology and Persons with Design Approach to Increase Access Ayotte and Jess Mitchell Disabilities
62 March 20th IDRC CSUN Conference on Fluid Infusion: Building the Next San Diego Presented by Colin Technology and Persons with Generation of the Accessible Web Clark, Antranig Disabilities Basman, and Kasper Markus March 26th IDRC VTE Lab "Active Learning, Inclusive Classrooms: ICT Integration Quebec Presented by Anastasia Universal Design for in Postsecondary Education Cheetham and Michelle Learning (UDL) in D'Souza collaboration with Technology," April 1st IDRC OpenStax CNX annual The State of Accessible OER Houston Jess Mitchell conference Solutions from the FLOE team April 4th OPEN Fukanu Panel discussion on Web accessibility Shadi from W3C DIR May 19th IDRC Pacific Rim International Invited Presentation / Co-Chair Hawaii Jutta Treviranus Conference on Disability and Diversity June 10th RTF-I M-Enabling Summit Invited Presentation Washington Gregg Vanderheiden D.C. June 10th- IDRC The United Nations: Seventh New York Jutta Treviranus 12th Session of the Conference of City States Parties to the Convention on the Rights of Persons with Disabilities June 23rd All HCII 2014 Complete GPII mini-conference Heraklion div. partner thread of HCII 2014 organized with a s total of 35 Presentations July 14th SENS AHEAD Conference The Use of Assistive Technologies as Sacramento Goldrick, M. Stevns, T. US Learning Technologies to Facilitate Christensen, L.B. Flexible Learning in Higher Education July 27th SENS ICCHP The Use of Assistive Technologies as Paris Goldrick;Michael; US Learning Technologies to Facilitate Christensen, Lars Flexible Learning in Higher B.;Stevns, Tanja Education August 27th IDRC Colombia South America Keynote Monteria Jutta Treviranus CAVA Conference September IDRC A11y Camp Toronto Co-designing use cases using Toronto Dana Ayotte and Jess 27th inclusive design practices Mitchell September SENS IKT Messe Inklusionsteknologi Nyborg Stevns T., & 27th US Christensen L.B. October OPEN Mozilla Festival 2014 Discussions about webapps and London Steve Lee 10th DIR community development October HDM, CENTRIC Towards Universally Usable Smart Nice Smirek, Zimmermann, 12th FHG Homes - How Can MyUI, URC and Ziegler openHAB Contribute to an Adaptive User Interface Platform? October RtF-I Deep Conference Preferences Server Toronto Jutta Treviranus and 16th Gregg Vanderheiden January FHG Zukunftsforum »Working Gemeinsam Smart - Mensch-Technik Stuttgart Matthias Peissner 30th Smarter – Menschen. Räume. Interfaces für intelligente Technologien« Umgebungen
5.2.3. Publications See also http://www.prosperity4all.eu/outcomes/publications/) 1. Ayotte D., Vass J., Mitchell J., Treviranus J. Personalizing Interfaces Using an Inclusive Design Approach. In: Universal Access in Human-Computer Interaction. Design for All and Accessibility Practice, ser. Lecture Notes in Computer Science, C. Stephanidis and M. Antona, Eds. Springer International Publishing, 2014, no. 8516
63 2. Ballieu Christensen, L. & Chourasia, A. (2014). Document Transformation Infrastructure. In: Universal Access in Human-Computer Interaction. Design for All and Accessibility Practice, ser. Lecture Notes in Computer Science, C. Stephanidis and M. Antona, Eds. Springer International Publishing, 2014, no. 8516. 3. Budde, M., Riedel, T., Koepke, M., Berning, M. & Beigl, M. (2014). A Comparative Study to Evaluate the Usability of Context-based Wi-Fi Access Mechanisms. In: Universal Access in Human-Computer Interaction. Design for All and Accessibility Practice, ser. Lecture Notes in Computer Science, C. Stephanidis and M. Antona, Eds. Springer International Publishing, 2014, no. 8516. 4. Cheetham A., Ayotte D., Hung J., Vass J., Clark C., Mitchell J., and Treviranus J.: Accessible Metadata Generation: In: Universal Access in Human-Computer Interaction. Design for All and Accessibility Practice, ser. Lecture Notes in Computer Science, C. Stephanidis and M. Antona, Eds. Springer International Publishing, 2014, no. 8516 5. Christensen L.B., Chourasia A. (June 2014) Document Transformation Infrastructure. In: Universal Access in Human-Computer Interaction. Design for All and Accessibility Practice, ser. Lecture Notes in Computer Science, C. Stephanidis and M. Antona, Eds. Springer International Publishing, 2014, no. 8516 6. Clark C., Basman A., Bates S., and Markus K. (June 2014).Enabling Architecture: How the GPII Supports Inclusive Software Development. In: Universal Access in Human-Computer Interaction. Design for All and Accessibility Practice, ser. Lecture Notes in Computer Science, C. Stephanidis and M. Antona, Eds. Springer International Publishing, 2014, no. 8516. 7. Goldrick M., Stevns T., Christensen L.B. (July 2014). The Use of Assistive Technologies as Learning Technologies to Facilitate Flexible Learning in: Higher Education. Springer International Publishing AG. 8. Hernández J., Clark C., Markus K. The GPII on Desktops in PCs OSs: Windows & GNOME: In: Universal Access in Human-Computer Interaction. Design for All and Accessibility Practice, ser. Lecture Notes in Computer Science, C. Stephanidis and M. Antona, Eds. Springer International Publishing, 2014, no. 8516 9. Lee S., Vanderheiden G., Chourasia A. (June 2014) AT and GPII: Maavis: In: Universal Access in Human- Computer Interaction. Design for All and Accessibility Practice, ser. Lecture Notes in Computer Science, C. Stephanidis and M. Antona, Eds. Springer International Publishing, 2014, no. 8516 10. Jansen, D., Alcala, A. & Guzman, F. (2014). Amara: A Sustainable, Global Solution for Accessibility, Powered by Communities of Volunteers. In: Universal Access in Human-Computer Interaction. Design for All and Accessibility Practice, ser. Lecture Notes in Computer Science, C. Stephanidis and M. Antona, Eds. Springer International Publishing, 2014, no. 8516. 11. Peissner, M., Schuller, A., Ziegler, D., Knecht, C. & Zimmermann, G. (2014). Requirements for the Successful Market Adoption of Adaptive User Interfaces for Accessibility. In Universal Access in Human-Computer Interaction. Design for All and Accessibility Practice, ser. Lecture Notes in Computer Science, C. Stephanidis and M. Antona, Eds. Springer International Publishing, 2014, no. 8516. 12. Peissner, M., Vanderheiden, G., Treviranus, J. & Tsakou, G. (2014). Prosperity4All – Setting the Stage for a Paradigm Shift in eInclusion. In: Universal Access in Human-Computer Interaction. Design for All and Accessibility Practice, ser. Lecture Notes in Computer Science, C. Stephanidis and M. Antona, Eds. Springer International Publishing, 2014, no. 8516. 13. Schwerdtfeger R., Vanderheiden G., Treviranus J., Clark C., Mitchell J., Petrides L., McLaughlin L., Jimes C., Tobias J., Trewin S., Brennan M. (June 2014) PGA: Preferences for Global Access: In: Universal Access in Human- Computer Interaction. Design for All and Accessibility Practice, ser. Lecture Notes in Computer Science, C. Stephanidis and M. Antona, Eds. Springer International Publishing, 2014, no. 8516 14. Smirek, L., Zimmermann, G. & Ziegler, D. (2014). Towards Universally Usable Smart Homes - How Can MyUI, URC and openHAB Contribute to an Adaptive User Interface Platform? (pp. 29-38). Presented at the IARIA Conference, Nice, France: Think Mind. Retrieved from http://www.thinkmind.org/index.php?view=article&articleid=centric_2014_2_30_30048 15. Smirek, L., Henka, A., Zimmermann, G. (in press): Giving Elderly Access to Smart Environments Providing Adaptive User Interfaces Based on Web Components, the Universal Remote Console and the Global Public Inclusive Infrastructure. HCII 2015, Los Angeles. (to appear) 16. Stiegler, A. (2014). Gamification in the development of accessible software. In: Universal Access in Human-Computer Interaction. Design for All and Accessibility Practice, ser. Lecture Notes in Computer Science, C. Stephanidis and M. Antona, Eds. Springer International Publishing, 2014, no. 8516. 17. Treviranus, J., Clark, C., Mitchell, J. & Vanderheiden, G. (2014). Prosperity4All: Designing a Multi-Stakeholder Network for Economic Inclusion. In: Universal Access in Human-Computer Interaction. Design for All and Accessibility Practice, ser. Lecture Notes in Computer Science, C. Stephanidis and M. Antona, Eds. Springer International Publishing, 2014, no. 8516. 18. Tsakou, G., Leligou, H. & Katevas, N. (2014). A novel infrastructure facilitating access to, charging, ordering and funding of assistive services. In: Universal Access in Human-Computer Interaction. Design for All and Accessibility Practice, ser. Lecture Notes in Computer Science, C. Stephanidis and M. Antona, Eds. Springer International Publishing, 2014, no. 8516. 19. Vanderheiden, G., Treviranus, J., Clark, C., Peissner, M. & Tsakou, G. (2014). Prosperity as a Model for Next-Generation Accessibility. In: Universal Access in Human-Computer Interaction. Design for All and Accessibility Practice, ser. Lecture Notes in Computer Science, C. Stephanidis and M. Antona, Eds. Springer International Publishing, 2014, no. 8516. 20. Vanderheiden, G., Treviranus, J., Ortega-Moral, M., Peissner, M. & de Lera, E. (2014). Creating a Global Public Inclusive Infrastructure (GPII). In: Universal Access in Human-Computer Interaction. Design for All and Accessibility Practice, ser. Lecture Notes in Computer Science, C. Stephanidis and M. Antona, Eds. Springer International Publishing, 2014, no. 8516.
64 21. Zimmermann, G., Vanderheiden, G. & Strobbe, C. (2014). Towards Deep Adaptivity - A Framework for the Development of Fully Context-Sensitive User Interfaces. In: Universal Access in Human-Computer Interaction. Design for All and Accessibility Practice, ser. Lecture Notes in Computer Science, C. Stephanidis and M. Antona, Eds. Springer International Publishing, 2014, no. 8516. 22. Zimmermann, G., Stratmann, A., Reeß, D. & Glaser, T. (in press). Patterns for User Interface Adaptations - Towards Runtime Adaptations for Improving the Usability of Web Forms for Elderly Users. HCII 2015, Los Angeles. (to appear)
5.2.4. Dissemination Material The following list shows dissemination material done within the first year: Logo Website Documents and templates 2 project leaflets 1 roll-up 1 flash drive (with the project’s information) 2 press releases 1 newsletters 1 newsletters email-briefs
65
6. EXPLANATION OF THE USE OF THE RESOURCES
6.1. Justification of major cost items and resources
Information on the use of resources may be found within the report of the NEF.
66 6.2. Budgeted versus Actual Costs5
5 All Euro values of IDRC are zero, as IDRC as canadian partner won’t get EC funding, so they are reporting manpower (PM), but not monetary costs
67
68
69
70
71
72
73 6.3. Planned versus Actual effort
74
75
7. FINANCIAL STATEMENTS – FORM C AND SUMMARY FINANCIAL REPORT
7.1. Financial Statement Beneficiary 1 – FhG-IAO
76
7.2. Financial Statement Beneficiary 2 – RTF-I
77 7.3. Financial Statement Beneficiary 3 - IDRC6
6 All Euro values of IDRC are zero, as IDRC as canadian partner won’t get EC funding, so they are reporting manpower (PM), but not monetary costs
78 7.4. Financial Statement Beneficiary 4 - LSEE
79 7.5. Financial Statement Beneficiary 5 - JIBS
80 7.6. Financial Statement Beneficiary 6 - SILO
81 7.7. Financial Statement Beneficiary 7 - HdM
82 7.8. Financial Statement Beneficiary 8 – CERTH
83 7.9. Financial Statement Beneficiary 9 - TECH
84 7.10. Financial Statement Beneficiary 10 - ENG
85 7.11. Financial Statement Beneficiary 11 - PCF
PCF is currently in discussion with the EC, regarding a correction of the cost model. Therefore, they are not able to finalize Form C currently.
Data provided by PCF until now is:
PCF agreed that these figures are stable, as far as they are not concerned by the change of the cost model.
86
7.12. Financial Statement Beneficiary 12 - SENSUS
87
7.13. Financial Statement Beneficiary 13 – KIT
88 7.14. Financial Statement Beneficiary 14 – KI-I
89 7.15. Financial Statement Beneficiary 15 – FHTW
90 7.16. Financial Statement Beneficiary 16 – UCY
91 7.17. Financial Statement Beneficiary 17 – FONCE
92 7.18. Financial Statement Beneficiary 18 – AGE
93 7.19. Financial Statement Beneficiary 19 - NCBI
94 7.20. Financial Statement Beneficiary 20 – GUADAL
95 7.21. Financial Statement Beneficiary 21 – OpenDir
96 7.22. Financial Statement Beneficiary 22 – LFTL
LFTL is currently in the progress of defining the LEAR role. As currently there is no LEAR for LFTL, they haven’t been able to define their FSIGN and therefore they haven’t been able to finalize work on their form C.
LFTL agreed that all data given within the form C is stable and won’t be changed any more.
97 7.23. Financial Statement Beneficiary 23 – MLS
98 7.24. Financial Statement Beneficiary 24 – CC
CC has difficulties with their LEAR role. Currently, it is not clear if they will define a new LEAR for their current organization, or if there will be an organizational change within the consortium.
As currently the LEAR for CC is not available any more, they haven’t been able to define their FSIGN and therefore they haven’t been able to finalize work on their form C.
CC agreed that all data given within the form C is stable and won’t be changed any more.
99 7.25. Financial Statement Beneficiary 25 – USTUTT
100 7.26. Summary Financial Report7 8 9
7 Data of LSEE is missing, as this partner is not in the consortium any more and the form C is available only offline (signed paper), not online. 8 Data of PCF, LFTL and CC is missing as these partners have not been able to finalize their form C, due to different reasons as documented within chapter 7.11, 7.22 and 7.24 9 All Euro values of IDRC are zero, as IDRC as canadian partner won’t get EC funding, so they are reporting manpower (PM), but not monetary costs
101
8. CERTIFICATES ON THE FINANCIAL STATEMENTS No certificates are necessary for reporting period 1.
List of Certificates which are due for this period, in accordance with Article II.4.4 of the Grant Agreement.
Beneficiary Organisation Certificate Any useful comment, in particular if a short name provided? certificate is not provided yes / no 1 2 3 Etc.
According to the table above a copy of each duly signed Certificate on the Financial Statements (Form C) should be included in this section (signed originals are to be sent by post).
102 9. ANNEX: RISKS PER WORK PACKAGE AND KPIS - ASSESSMENT SPRING 2015
As requested by the review report, this annex contains risk assessment to WP or task level as appropriate. In future periodic reporting this information will be explicitely included.
Table 1: Risks per WP
Risk WP Description Mitigation and/Contingency Plans Assessment Risk # (April 2015) Cleared?
102.1 102 Poor coordination among activities This can be mitigated by overlapping the activities, No change. within the same work package. such that the new activity begins before the previous one ends, allowing time for consultations between the participants.
102.2 102 Coordination with the other Considerable effort will be made to disseminate the No change. members of the project (outside progress of SP1 over the whole project and progress SP1) may be complex. will be monitored regularly through WPs 103 and 405.
201.1 201 Difficulties interfacing with GARI They already federate with other places, places we We are now federated with them. So risk no longer Yes interface will be federating with (like the US FCC). So have exists. alternate paths to the data.
201.2 201 MarketPlace volume is low. Increase public awareness through guerilla The MarketPlace will be a place for people who advertising. cannot sell elsewhere. So low marketplace is not a problem - except to people who don’t know about it and have no place to sell.
The Marketplace is not yet implemented so we don’t have any more data on risk at this point.
103 Risk WP Description Mitigation and/Contingency Plans Assessment Risk # (April 2015) Cleared?
201.3 201 In a fast-changing technology The Prosperity4All architecture will be designed No change landscape, there is a risk that some using cross-platform techniques and tools in order to technical approaches will fall out reduce the risk of technology-specific brittleness and of use or currency. to ensure that it can be rapidly ported to strong emerging technologies.
201.4 201 Differences in legal and taxation While differences in legal and taxation systems exist No Change. Will know more much later in the systems restrict the target and are expected to impose limits to the actual implementation after systems are up that will use geographical area of deployment of the Prosperity4All payment the payment system. Prosperity4All system. infrastructure, the target of Prosperity4All is to prove the feasibility and provide the technical solution for such systems while in parallel will work on raising awareness and sensitivity on the assistance services issues, considering that once these systems are offered in multiple countries, their success will open the way for overcoming legal and taxation issues.
201.5 201 Gamification is a well-researched The research and broad survey of technologies and No change topic, but we see a lot of bad approaches is done in each activity to reduce this risk examples out there. Gamification as much as possible. is therefore inherently affected by the risk of user acceptance.
201.6 201 The Runtime Servers will be It is good practice to expect such dramatic events Not much risk until we deploy. We hope to have designed for high user counts, yet when designing large-scale community sides. The new funds within the year from US/Canada that certain unforeseen scenarios can architecture will therefore be designed for easy will allow fully redundant runtime servers with still prove to be bottle necks and maintenance while still maintaining tight mapping of continual mirroring to avoid the problem. significantly reduce the server the underlying hardware for maximum performance. performance.
104 Risk WP Description Mitigation and/Contingency Plans Assessment Risk # (April 2015) Cleared?
202.1 202 The biggest issue of the API specifications will go along with an internal We do not expect (nor is it necessarily healthy) for component collection can be seen feasibility study of what kind of behaviour can be all components to have the same API. We will work in the creation of a unified way to normalized and exposed in one API. If one of the toward common APIs where it is useful - but also access several components. areas explored is too heterogeneous to support a support components that have their own API common API, components will retain their respective where that is most functional (as in systems) APIs and be placed in the repository without unification.
202.2 202 Components will not prove to be Prosperity4All will at least provide a repository of No change placed under a useful wrapper for available devices as starting point. multiple devices.
202.3 202 Components cannot be extracted A diverse set of technologies will be picked that We don’t expect that all parts of all systems will be from existing projects because of already has important preconditions for inclusion in useful as stand alone components. We don’t tight dependencies. Prosperity4All. The project does not rely on a currently have any major components that were complete integration of all technologies but a intended to be stand alone - that cannot be broken complementary set. out and provided in such a way that they can be adapted for use in other projects.
We currently plan for better packaging of individual components to handle complex dependencies (e.g. Java Runtime, Asterics Runtime)
202.4 202 Components will not be adopted Prosperity4All offers a wide range of independent No change by mainstream industry, e.g. no technologies to pick from and makes it easier for products with URC sockets will be mainstream developers to include Prosperity4All available. technologies mainstream products and services. The project aims will provide a long term infrastructure that enables adoption and active participation in development also and especially beyond the project scope.
105 Risk WP Description Mitigation and/Contingency Plans Assessment Risk # (April 2015) Cleared?
203.1 203 The adaptation of the Runtime A feasibility study, runtime solution performance and REST was identified and selected as the most Environment and its reliability analysis will be performed through the appropriate technology for exposing the implementation using a cross- research and evaluation of existing cross-platform functionalities of the AsTeRICS ARE as web platform development tool (e.g. development tools, which will allow to base the services in order to enable cross-platform PhoneGap) entails the possibility specification and design (M10) and pursue a development and allow the use of these sensors and performance and reliability issues development approach for adapting and actuators functionalities irrespective of the client in terms of the solution. implementing the ARE for different platforms. platform.
203.2 203 The web technologies, used to o Substitution of some functionalities of the No Change - will be able to re-evaluate this risk implement the AsTeRICS Configuration Suite with new and mitigation strategy when we are bit further Configuration Suite on web functions/workarounds along technologies does not provide all o Inclusion of step by step wizard reduce the needed functionality for a full editing effort graphical editor. o Usage of alternative UI components and methods (e.g. ARIA). Additionally deep technology review on possible technologies.
203.3 203 User interface: Clinical Personal User Interface will be simplified as much as possible This will always be a risk - or rather - it will always and non-technical experts often and step by step wizards will request user needs and be a certainty. The question is not if but how much find difficult to operate complex requirements. interfaces. can we simplify this.
204.1 204 Software development delays. Access to entire network of people around the world No Change. No delays to date. through the P4A/FLUID/GPII network of programmers and developers.
204.2 204 Copyright entanglements. International guidelines being developed by We have outlined a strategy involving Prosperity4All project. implementing servers in key countries - allowing us to avoid the border crossing issues and conform to local laws as required.
106 Risk WP Description Mitigation and/Contingency Plans Assessment Risk # (April 2015) Cleared?
205.1 205 The satisfaction of all user As a first mitigation step, Prosperity4All includes During the first year, neither the likelihood nor the requirements leads to the design of industrial partners with re-known experience in the mitigation approach of this risk has changed. While a complex AOD service development and integration of complex software the user (service consumer) requirements have infrastructure which can’t be systems and solutions. Second, the generic AOD been captured and prioritized, the requirements implemented during the project. service architecture will follow a modular approach stemming from the support of other (digital) and will define the functionality and interfaces of the services under development within P4A have not required components. If the satisfaction of the entire been crystalized. In the current AoD design, an set of requirements can’t be ensured throughout the incremental development approach has been project lifetime, the requirements will be classified planned to accommodate any requirements that and prioritised to ensure that all types of requirements are addressed, leaving unmet only those come at a later stage. with lower priority. The overall design will ensure that these will be met in a later stage easily integrating more sophisticated versions of the components. For example, with respect to Quality of service or technical support sub-systems, few levels/models may be supported by the developed infrastructure allowing for finer discrimination in the future.
205.2 205 Definition of inappropriate The partners involved in Prosperity4All have the In the first year, the AoD design team has focused semantics and service models. right balance in competence, industrial need and on capturing the diverse user needs. The description Inconsistencies at this place will location to define the needed concepts, models and of the services in the 1st year’s version of the AoD therefore endanger the semantics. The integrated character of the project will platform is achieved combining service applicability of project results on ensure and guarantee validation using the conceptual classification in categories and keywords the different domains. and design approach of each module. To rectify any association. Semantic description will be inconsistencies with respect to the diverse application considered during the 2nd year, taking into account domains, an update of the AOD infrastructure more elaborate requirements stemming from the specification is foreseen periodically. services developed in other WPs and SPs.
107 Risk WP Description Mitigation and/Contingency Plans Assessment Risk # (April 2015) Cleared?
206.1 206 The results of “T206.1: Study of The planned developments are based on the wide No addenda is needed since the Dow feedback and feedforward needs expertise in user-developer connections of the contemplated the main items to develop and preferred modalities” may consortium partners, and consequently a radically (corelated to the different tasks of the WP). The show that the developments unexpected result in T206.1 is not likely. study does not drastically modify the future planned in the other activities of Nevertheless, the planned developments in the other activities even though it certainly shapes them. the WP (T206.2, T206.3 and activities will be adapted to the study results. In the T206.4) must be drastically unlikely case that such adaptation implies a drastic modified to be adapted to the modification of the planned activities (e.g. customer and developers needs elimination of some activities and/or addition of new and preferences. ones), a addenda of the Description of Work (DoW) document will be requested in order to ensure that the results maximize the consumer and developer satisfaction.
206.2 206 Users may not use the feedback We will build in a mechanism to send feedback to It is still soon to asses this risk, nonetheless an systems. Developers may not developers so they are aware. Because this will be a especial effort has been made in order to foster look. unique place for finding all (kind of a Google for engagement and participation of the future accessibility solutions) it is expected to have high components developed. This has been done in the volume and as a result – will be seen by many field work and desk research for D206.1 consumers. This will motivate developers/ manufacturers to visit and take comments seriously.
301.1 301 The outcomes of SP2 that WP301 As more than one SP2 outcomes are used in each SP3 There are already initial results coming out of SP2 developments are based upon are activity, the development will start with the available and WP301 partners are working on integrating not available on time, jeopardising outcomes. In any case, SP2 will follow a fast-start them, so this risk is fully under control. the overall Prosperity4All plan and has been carefully designed with proper timeplan: person effort and assignment to partners.
108 Risk WP Description Mitigation and/Contingency Plans Assessment Risk # (April 2015) Cleared?
301.2 301 The outcomes of SP2 that WP301 This is one of the Prosperity4All evaluation metrics This is a real risk during the first development is based upon is not and will be monitored since the first testing cycle integration/implementation cycle and concerns as easy to use as expected, thus with developers, which means that if a Prosperity4All almost all of the current versions of SP2 outcomes. introducing delays in the WP301 tool is not easy-to-use, partial redesign will be However, the WP301 team is aware of this risk and activities completion. attempted from the early stages of the project. is prepared to provide feedback to SP2 teams about how to improve usability of their tools. WP301 and relevant SP2 teams are already working very closely together to resolve usability issues. This is the main purpose of the first implementation iteration..
301.3 301 The implementation of the In the unlikely case that such adaptation implies a MLS has already identified some SP2 results and mechanisms produced in SP2 may drastic modification of the planned activities (e.g. has started their integration in the MLS Destinator, be not feasible to be used for MLS elimination of some activities and/or addition of new so this risk has not occurred. Destinator Talk&Drive™, for ones), a addenda of the Description of Work (DoW) technical, legal or operational document will be requested. reasons.
302.1 302 Tactile graphic printing is very As Prosperity4All focuses on ICT, the cost of highly Not central to Prosperity4All - so not a serious risk. expensive impeding its wide standardized tactile graphics is not at the adoption in learning/lecture giving. Prosperity4All focus. However, Prosperity4All contributes in the reduction of such costs as follows: the extraction of information in various formats, electronic registration of all available learning resources in combination with wide and flexible service infrastructures, will maximise the utilisation of the e-learning applications. This way the same content will be shared among a wide group of users, and thus any associated cost per educated person will decrease due to the number of users.
109 Risk WP Description Mitigation and/Contingency Plans Assessment Risk # (April 2015) Cleared?
302.2 302 R302.2: The outcomes of SP2 that If this risk occurs, we will either alter the design of No change the WP302 applications will be the applications of this WP, or implement a prototype based on are not available on time. with reduced functionality using those SP2 tools that are available.
303.1 303 The implementation of the TECH will also participate in the RTD efforts carried So far an addenda is not needed. The mechanisms produced in “WP205 out in the three WPs where this WP has dependencies implementation of the different components is still Assistance on Demand Services to ensure the compatibility of the results with the under consideration without foreseen any major Infrastructure”, “WP201 payment planned implementation in microlabora. deviation of issue to mention Infrastructure”, and/or “WP206 Nevertheless, the extent and specificities of the Sustainable Meaningful mechanisms to be implemented will be determined in Consumers-Developer the first phase ofT303.1. The planned Connections (Pull vs Push)” in implementations carried out in T303.1 and T303.2 microlabora may be not feasible will be adapted according to the results of the for technical, legal or operational feasibility analisys. In the unlikely case that such reasons. adaptation implies a drastic modification of the planned activities (e.g. elimination of some activities and/or addition of new ones), an addenda of the Description of Work (DoW) document will be requested.
110 Risk WP Description Mitigation and/Contingency Plans Assessment Risk # (April 2015) Cleared?
303.2 303 The implementations in Microlabora is an existing portal offering its services The implementation of Microlabora plattform is microlabora may not reach a publicly which already has participants. still on plan along with the other components critical mass of participants (both Nevertheless, by means of the dissemination developed in WP205 by Silo. No major deviation is demanding and offering activities planned in the project and TECH foreseen at this moment due to the fact that not assistance) to ensure its connections in Spain the potential participants will be full implementation is in place. sustainability. encouraged to participate. Note that TECH is a technology and consultancy company belonging to the business corporation of FONCE, and that the microlabora portal also belongs to FONCE. FONCE has created and consolidated more than 45,592 jobs for people with disabilities. Moreover, FONCE in turn belongs to ONCE, the National Organisation of the Spanish Blind, which takes care of the specialised care activities required for more than 70,000 members with blindness or severe visual impairment. TECH and FONCE will use its connections and its umbrella organisation ONCE to ensure the critical mass of participants.
401.1 401 The principal risk is the ability of This risk is addressed by the number of pilot sites More of an effort issue than a risk issue at this the pilot sites to recruit and involved (there is reasonable redundancy) although point. Always hard. maintain participants for the pilot this course of action will impact on the results’ cross- study. However, this is mediated cultural value. Early recruitment of staff and the by the use of pilot sites where the replacement of part of or all of a pilot site’s activities host organisations have significant by another partner is an alternative response. links into their respective communities.
401.2 401 Costs for pilot site setup are higher The Consortium will seek to motivate as many No change. Careful planning is the key - and than planned: as the evaluation stakeholders as possible in participating in the experience from Cloud4all will help for some with implementers will run project’s evaluation activities which is expected to aspects remotely, the relevant costs are result in a substantial resources multiplication. expected to remain grossly within budget.
111 Risk WP Description Mitigation and/Contingency Plans Assessment Risk # (April 2015) Cleared?
503.1 503 Since this is an infrastructure to To address this, we are engaging our stakeholders This isn’t so much a risk as a certainty. And if our support a new ecosystem, it is closely, from consumers through developers, design could not handle this then it would not be quite possible that the form of the throughout the project. We will also be reassessing of much use or last very long. We expect we will ecosystem will be different than the focus of oure resources as we progress in order to need to adapt and adopt within the project — and currently envisioned. This is identify the best allocation of our resources; the best design the infrastructure to be adaptable after. especially true since this is in a way to deploy what we have to create the best technology area that is changing so intrastructure – the best support for the new emerging rapidly. It is therefore highly likely (or evolved existing) ecosystem. that our current Envision of both the ecosystem and the best infrastructure to support it will be not completely accurate.
112 Risk WP Description Mitigation and/Contingency Plans Assessment Risk # (April 2015) Cleared?
503.2 503 Prosperity4All consortium To efficiently face that unlike case where the No change. Progress good on all key standards includes partners strongly involved Prosperity4All standardisation actions are not fronts at this point. in standardisation bodies that come adopted by standardisation bodies and development from Europe Canada and US and based on Prosperity4All approach evolves in parallel, thus the consortium is positive that the project will: all major standardisation efforts will be closely monitored to • produce technical reports, drafts and maximise compliance and implementations that can be used to influence of the Prosperity4All facilitate adoption when standards can solutions. be opened up The fact that the Consortium includes partners with very strong • develop adaptation modules for the influence to, practically, all Prosperity4All solutions for which relevant standardisation bodies (some of our partners are, in fact, timely exploitation is crucial and leading such bodies), and that this is a new approach receiving much • adopt already from the design phase, as attention, allows us to believe that generic interfaces as possible leaving Prosperity4All will receive timely the development of concrete information on emerging standards to consider, as well as having the interfacing modules towards the end of Prosperity4All solutions the application development phase. considered within the relevant standardisation forums. The current strong involvement, commitment and on-going activities of the Consortium partners towards this direction (c.f. section 3.1.9) is certainly an important asset.
113 Table 2 Assessment of Key Performance Indicators (KPIs)
Prosperity4All Evaluation phase Key Performance Indicators Assessment vision 1) Reduce costs WP402 Reduction of time required by implementers for Not yet applicable developing/adapting/modifying an SP3 application, using the SP2 tools = at least 15% Too early – tools still in development reduction reported for developers knowledgeable on how to make an application accessible, and at least 30% reduction reported by developers with little experience in accessibility issues. (mean value over all project evaluations with developers in all iterations). WP403 At least 25% of users report that they able to use Not yet applicable the user-facing tools and/or SP3 applications that they were not able to do before, or are more First testing of users facing tools is year 3 efficient; without additional cost or -even- at reduced cost. WP404 At least 60% of involved stakeholders present a Summative evaluation will be done in year four positive WTH attitude and 30% of them a positive WTP range.
2) Address the full The full range of Year3: SP2 tools related to individuals with Summative evaluation will be done in year four. range of users beneficiaries are specifically various access needs achieve a usability and testing the Proseprity4All user acceptance rating (mean) over 3 in a 0-5 developments within scale. WP403. We use common performance indicators for Year 4: SP2 tools related to individuals with all groups for comparison various access needs achieve a usability and reasons. user acceptance rating (mean) over 3.5 in a 0-5 scale.
3) Address the tails WP 402 for implementers At least 20% of the developers who use the Summative evaluation will be done in year four.
114 and the tails’ tails DeveloperSpace or Tools report that they are more likely or will develop for smaller markets as a result of the DeveloperSpace, Tools, or the Unified Listing and Marketplace. This would be significant because AT vendors are struggling already and asking them to address the tails where the profit is very small, is very hard for them.
4) Address all WP402 for implementers 70% of developers enhancing/developing SP3 Most SP 3 implementers plan to use SP 2 tools technologies applications make successful use of SP2 tools for enhancing their applications. Successive (in each application domain). progress in terms of this KPI can be assessed in future periodic reports. WP403 for end users For any SP3 application enhanced with Not yet applicable. Summative end user Prosperity4All SP2 tools, user acceptance is acceptance will be evaluated in WP 403 in year improved by at least 1 unit in a 0-5 scale four. (compared to the initial rating of the non optimized applications)
5) Provide a SP1 and WP404. Also The number of business models deemed Business modelling in SP 1 is not sufficiently plan/mechanism for exploitation related appropriate for the functioning and viability of advanced to collect meaningful feedback from creating a vibrant, the Prosperity4All ecosystem provided by SP1. internal and external stakeholders. A first profitable, assistive- assessment of this KPI will be included in the technology market At least 65% of the Consortium stakeholders next periodic report. (notably companies), Project Collaborators and other external stakeholders report that the SP1 market mechanisms proposed address their needs and could be adopted by them.
6) Decrease costs WP402 for implementers, Same as for number 1-A) above. Summative evaluation will be done in year four. and expertise WP404 and exploitation required of related Also the number of mainstream companies mainstream embracing the Prosperity4All ecosystem and companies using our tools.
115 At least 3 unfunded mainstream companies express strong interest in the project results during the project lifetime and/or become Collaborators.
7) Do a better job of Exploitation related. The number of exploitable components from Summative evaluation will be done in year four. moving research other research that are accessed from the and development to Prosperity4All/GPII DeveloperSpace and market incorporated into a commercial product or service. Number of times a Prosperity4All/GPII service infrastructure is used by SME to offer a service. (also during project execution possible)
8) Involve consumer WP404 for stakeholders At least 30 consumers per site involved in Successive progress in end user involvement and consumer product development design during the course will be assessed in future periodic reports. expertise in product of the project using the P4A platform and tools. development 9) Be based on SP1 and Exploitation related Same as for objective number 5 above Same as 5 above. realities, business cases, and value propositions 10) Recruit and WP402 for implementers Number of unsubsidised external developers In the first project year, we have not focused on engage more (SME and Large) that engage in the project engaging external developers. We will report on players during its run >10 (of which at least 5 with little progress in the next periodic report. or no experience in making products accessible WP404 for stakeholders Number of unsubsidised external stakeholders In the first project year, we have not focused on engaged in P4A during the project duration >15 engaging external stakeholders. We will report (>10 involved in crowdsourcing paradigm, > 5 on progress in the next periodic report. clinical,)
11) Not forget WP204 and WP404 Number and quality of results coming out of Not yet applicable documents, media, WP204 on Media and Material Automated/Crowdsourced Transformation 116 and services Infrastructures. Extent of usage of the enhanced features of these tools produced within the Prosperity4All project
12) Provide both WP 403 70% of users rating the Assistance on Demand Summative evaluation will be done in year four. technology and over 3 in a 0-5 scale (of those that tested it) human accessibility service support WP404 >75% of users at each site able to use Assistance Summative evaluation will be done in year four. on Demand service.
13) Work across all WP402 Implementations by external unfunded parties in Not yet applicable. domains of life: all of the identified domains within the project cycle. WP 403 For any SP3 applications enhanced with P4A Summative evaluation will be done in year four. tools, user acceptance improved by at least 1 unit in an 0-5 scale.
14) Be applicable, WP402 External implementers participating in Not yet applicable. The first evaluation cycle and work evaluations from at least 8 countries including 2 with implementers (year 2) is restricted to internationally non European. internal implementers. WP404 Stakeholders participating in Evaluations from Not yet applicable. at least 8 countries including 2 non European.
Table 3: Prosperity4All Success Indicators
117