Report on first prototype of Building Block Repository · 2.2 AT Specific I/O Modules ... Easy...

Ecosystem infrastructure for smart and personalised inclusion

and PROSPERITY for ALL stakeholders

Report on first prototype of

Building Block Repository (1st iteration)

Project Acronym Prosperity4All

Grant Agreement number FP7-610510

Deliverable number D202.2-1

Work package number WP202

Work package title Building Blocks

Authors Till Riedel, Lukas Smirek, Chris Veigl,

Martin Deinhofer, Konstantinos Votis,

Nikolaos Kaklanis, Aggeliki Konstadinidou,

Dimitrios Tzovaras, Charalampos

Karagianidis, Anastasia Cheetham

Status Final Dissemination Level Public

Delivery Date 16/03/2016

Number of Pages 55

D202.2 Report on first prototype of Building Block Repository – 1st iteration (Public)

www.prosperity4all.eu 2

Abstract

Two years have passed in which components have been isolated, documented and gathered

within the GPII Developer Space Component Listing. This software deliverable comprises the

first release of this Software that is available on http://dspace.teco.edu. The current

document is a snapshot of building blocks that have been provided to bootstrap the effort as

part of the EU funded Prosperity4ALL project. While the online version should be self-

explanatory and much of the documentation found in this report actually replicates this

information (as of January 2016), this report furthermore explains the research and

development objectives behind building this software prototype as well as how resources

have been used to advance the state of the art.

Keyword List

Repository, Listing, Building Blocks, Developers, Components, Developer Space, Accessibility

http://www.prosperity4all.eu/



Version History

Revision Date Author Organisation Description

1 07/12/2016 Till Riedel KIT 1st version including TOC.

2 07/01/2016 Till Riedel, Lukas

Smirek, Chris Veigl,

Martin Deinhofer,

Konstantinos Votis,

Nikolaos Kaklanis,

Aggeliki

Konstadinidou,

Dimitrios Tzovaras,

Charalampos

Karagianidis,

Anastasia Cheetham

CERTH,FHTW,HDM,ID

RC,KIT

Input via the DSpace Prototype

3 14/01/2016 Till Riedel, Lukas

Smirek, Chris Veigl,

Martin Deinhofer,

Konstantinos Votis,

Nikolaos Kaklanis,

Aggeliki

Konstadinidou,

Dimitrios Tzovaras,

Charalampos

Karagianidis,

Anastasia Cheetham

CERTH,FHTW,HDM,ID

RC,KIT

Additional Input on Work done as

part of P4A

4 14/02/2016 Till Riedel KIT Integrated DSpace Screenshots

and eval feedback

5 26/02/2016 Lukas Smirek HDM Additional Input URC Docs

&Guidelines

6 26/02/2016 Till Riedel KIT Updated Content from online

description, including

categorization and Images.

Formatted correctly

7 29/02/2016 Till Riedel KIT Added text describing interaction

with SP1 and SP4. Added

conclusion

8 04/03/2016 Stefan Schürz, Alfred

Doppler

LFTL Internal Review, Typo fixes

9 15/03/2016 Andreas Stiegler HDM Internal Review

10 15/03/206 Till Riedel KIT Edits according to review




Table of Contents

Executive Summary .......................................................................................................... 7

Glossary............................................................................................................................ 8

1 The Role of the Building Block Repository ..............................................................10

1.1 Purpose and structure of this document .................................................................. 11

1.2 Purpose of Building Blocks in the GPII Developer Space ........................................... 13

1.3 Repository Creation and Management Strategies .................................................... 16

1.3.1 Service Design, Use Cases and Personas ............................................................ 17

1.3.2 Categorization and Structuring in a Prototype .................................................. 19

2 Content type examples ..........................................................................................25

2.1 External Building Blocks and online collection (FHTW) ............................................. 25

2.2 AT Specific I/O Modules (P4A T202.2) ....................................................................... 28

2.2.1 AsTeRICS AT Modules (FHTW) ........................................................................... 29

AsTeRICS Packaging Environment (APE) ...................................................................... 29

Managing Licenses of the AsTeRICS Building Blocks .................................................... 30

2.2.2 Websocket Interface for AsTeRICS Building Blocks (FHTW) .............................. 31

2.3 Generic Multimodal Interaction Modules (P4A T202.3) ........................................... 31

2.3.1 Arduino UNO: Microcontroller Interface (I/O Transducer Modules) (FHTW) ... 31

2.3.2 Universal HID Actuator: Mouse/Keyboard/Joystick Emulation (FHTW) ............ 31

2.3.3 Camera Input Module: FacetrackerLK, XFacetrackerLK: (FHTW)....................... 31

2.3.4 P4A Haptic Module (CERTH) ............................................................................... 47

2.3.5 P4A Android Vibration Module (CERTH) ............................................................ 47

2.4 Smart Device and Environment Modules (P4A T202.4) ............................................ 47

2.4.1 EnOcean: Smart Home Integration (FHTW) ....................................................... 37

2.4.2 KNX: Smart Home Integration (FHTW) ............................................................... 38

2.4.3 Point and Control: Spatial Interaction for Remote Control (KIT) ....................... 47

2.4.4 IndianaJS: Spatially aware Web of Things (KIT).................................................. 47

2.4.5 Context-WiFi Login (KIT) ..................................................................................... 47

2.5 Real-Time User Monitoring Modules (P4A T202.5) .................................................. 47




2.5.1 P4A SensorAPI (KIT) ............................................................................................ 47

2.5.2 FallDetectionModule (CERTH) ............................................................................ 47

2.5.3 P4ALL Affect Sensing Module (CERTH)............................................................... 47

2.5.4 Social Network Interaction Module (CERTH) ..................................................... 47

2.5.5 jActivity (KIT) ...................................................................................................... 47

2.5.6 Open BCI: Bioelectric Signal Acquisition and Processing (FHTW) ...................... 47

3 Templates, Tutorials, Handbooks and Documentation ...........................................48

3.1 Universal Remote Console documentation and templates (HDM) ........................... 48

3.1.1 Socket Templates ............................................................................................... 48

Woehlke web electricitysocket Template 1.0 .............................................................. 48

Plant Sensor Templates 1.0 .......................................................................................... 49

NetAtmo Templates 1.0 ............................................................................................... 49

Coloured light bulb Templates 1.0 ............................................................................... 49

DVD Player Templates 1.0 ............................................................................................ 49

TV set 1.0 ...................................................................................................................... 49

Twitter Templates 1.0 .................................................................................................. 50

UPNP-av Templates 1.0 ................................................................................................ 50

XBMC Templates 1.0 .................................................................................................... 50

3.1.2 Target adapter framework ................................................................................. 50

Easy target discovery manager .................................................................................... 51

Wöhlke target adapter ................................................................................................. 51

Time service Target adapter......................................................................................... 52

3.1.3 Tutorials and guidelines ..................................................................................... 52

Tutorial: Getting started with URC ............................................................................... 52

Tutorial: Creating Sockets with the SocketBuilder ....................................................... 52

Design Guidelines for User Interface Sockets .............................................................. 53

Making a business case with URC ................................................................................ 53

Frequently Asked Questions ........................................................................................ 53

3.2 Web Development Resources (IDRC) ........................................................................ 53




User Interface Options Tutorial .................................................................................... 53

Infusion Preferences Framework Tutorial ................................................................... 53

First Discovery Tool Tutorial ......................................................................................... 53

Accessible Standardized Testing Guide ........................................................................ 53

Inclusive EPUB 3 Guide ................................................................................................. 54

Accessible Web Games and Interactive Simulations ................................................... 54

4 Conclusion and Future Work ..................................................................................55




Executive Summary

With this deliverable we reached an important milestone regarding the components

provided within WP202 of the Prosperity4All project (aka Building Blocks). The searchable

and browsable Building Block Repository enables important interactions within the overall

ecosystem. It enables implementers to find suitable re-usable components in the domain of

assistive technology and accessible IT. The Building Block Repository presented in this

document is a community curated listing of code artefacts that are developed and

maintained in a strictly distributed fashion. It contains any contributions of components

made by the Prosperty4All project to the GPII Developer Space community, but will include

also any external component that can support the effort.

As this document is an accompanying report to a software deliverable, we encourage the

reader to follow the links to the online version for up to date information. The GPII

Developer Space prototype includes many more Building Blocks than those that are listed

here. We primarily included items in this document that were part of active development

within the first 2 years of the project span. Many of the Building Blocks have a history and

scope beyond the project but were refined and made available with the scope of specific

objectives of Prosperity4All. The three parts of the document describe the creation of a

prototype repository in the scope of the overall effort to create the GPII Developer Space,

describes the components as well as documentation contained currently in the prototype.

The online prototype that is currently reachable via dspace.teco.edu provides an alternative

way to explore the contents of this deliverable. To summarize: this deliverable documents a

snapshot of the ongoing work that was done as part of the Prosperity4All project for the

purpose of reviewing the past 2 years of project work within work package WP202. This

documents milestone for the project that finalizes an important phase, however, work will

continue within and beyond the project in an iterative, agile and dynamic fashion.




Glossary

Term Definition

Global Public Inclusive

Infrastructure (GPII)

Collaboratively created infrastructure that ensures that

everyone who faces accessibility barriers can access and use

information technologies.

Prosperity4All (P4A) Project funded under Contract Number 610510 within the

European Union's 7th Research and Innovation funding

programme (FP7). P4A builds important parts of the GPII.

GPII Developer Space An ecosystem enabling set of services within the GPII that

provide ease access to a comprehensive set of resources, tools,

and open community infrastructure to help implementer find

and use components and frameworks that have been built

with personalized accessibility in mind.

Implementer Stakeholders of the GPII Developer Space providing

applications, tools and services to end users adapted to their

needs (term used to distinguish from developers who provide

e.g. building blocks)

Building Block A term to describe reusable hardware and software

components addressed towards implementers

Stakeholder A person, group or organization that are directly or indirectly

involved or affected by a service.

Actor Any person involved in the creation, delivery, support, or use

of a service. In case of the GPII Developer Space those are

mostly developers of components, authors of other content

and implementers.

Need A necessary and/or desired function or condition.

Entry Point Instances of access to a service, where actors are able to join

the service as customers, providers or stakeholders. The GPII

Developer Space front page, but also the listing of a single

Building Block can be such entry points.

Journey Map A visual representation of a particular actors’ experience with a

service.




Term Definition

Persona A representation of a user group with shared needs and

characteristics. Personas are the distillation of primary

research with people. A persona would be given a name and

characteristics as well as needs.

Assistive Technology (AT) Any product, whether off the shelf, modified, or customized,

that is used to increase, maintain, or improve the functional

capabilities of someone with disabilities (also temporal).

Accessible Accessible to people with a diverse range of hearing,

movement, sight, and cognitive ability.

Information technology (IT) Use of any computer aided devices, infrastructure and

processes to create, process, store, secure and exchange all

forms of electronic data.

Human Interface Device(HID) A computer device that interacts directly with humans (e.g. a

joystick, keyboard or mouse)

Application Programming

Interface (API)

Set of routines, protocols, and tools for building software

provided by a Building Block.


https://en.wikipedia.org/wiki/Peripheral



1 The Role of the Building Block Repository

The Building Block Repository (that you will also find as “Parts&Tools” pictured in Figure 1

within the related Web Version) is part of a global effort to build a Developer Space within

the Global Public Inclusion Infrastructure (GPII). The items described in this report can thus

be seen in a much broader scope as explained below (see 2.3). The Building Block Repository

is not actually repository, but rather a community curated listing of code artefacts that are

developed and maintained in a strictly distributed fashion. It contains any contributions of

components made by the Prosperty4All project to the GPII Developer Space community, but

will include also any external component that can support the effort.

Figure 1: Snapshot of the current front page build within Prosperity4All

The purpose of contributing Building Blocks as part of the funded effort of the project is to

bootstrap an ecosystem that provides developers with “Libraries, Software & Hardware

Modules as well Code Snippets that will help you build accessible and personalized

technology”.

It is not only the single component that should “make it easier, faster and less expensive to

conceive [and] create” any inclusive implementation, but the collection as whole. It is clear

that any Building Block Repository can hardly ever be complete. This deliverable, however,

adds and documents a considerable amount of new possibilities to the space of assistive

technology (AT) and accessible information technology (IT). Much of the work was started

before Prosperity4All but was made available for the first time under permissive open

source licenses and in a reusable manner as part of this deliverable. Furthermore, existing




components developed outside the project were systematically categorized in a community

effort.

With our contributions (both those we built and those which we found), we want to build a

bridge to other advanced research topics in the areas of AT Interfaces, Multimodal

Interaction, Cognitive Systems and Smart Spaces, Personalized Health and Active Aging,

Sensing Enterprises and Connected Social Media.

With the integration of the Building Block Repository into the “GPII Developer Space”, a

developer targeted service infrastructure that is part of the overall Prosperity4All ecosystem,

we provide concrete entry points (the search as well as the individual Building Blocks) for

those who seek to integrate innovations and bring them to use in the context of smart and

personalized inclusion. Not claiming completeness by any means, we want to provide

application programming interfaces and aim to stimulate the development of new intelligent

modules by researchers, students, and others to rethink novel interaction and context-

sensing techniques from the perspective of users with various kinds of permanent or

temporary disabilities.

1.1 Purpose and structure of this document

As this document is an accompanying report to a software deliverable, we encourage the

reader to follow the links to the online version for up to date information. The software

presented here was developed or improved as part of the BUILDING BLOCKS work package

of the Prosperity4ALL FP7 EU Project. The GPII Developer Space prototype includes many

more Building Blocks than those that are listed here. We primarily included items in this

document that were part of active development within the first 2 years of the project span.

Many of the Building Blocks have a history and scope beyond the project but were refined

and made available with the scope of specific objectives of Prosperity4All (according the

description of work):

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

To integrate existing assistive solutions from previous projects such as AsTeRICS and

extract useful sensors, processors and actuators from it to a more general API. To

integrate Human Interface Device (HID) emulators into Prosperity4All and unify them

under a unified API.

To collect, extend, integrate, and make production-ready a collection of web user

interface components and web framework infrastructure that will reduce the cost

and complexity of building accessible web applications and web-based assistive

technology

To foster a community of contributors, maintainers, and sustainers of these

components, ensuring they will be viable over the long term.




This document describes the common open repository of state of the art AT interface

modules globally and the concrete work of the development teams within it that provide AT

interface module developers the capabilities to excel beyond state of the art by providing

access to novel technologies.

This report includes all developments within WP202 with some exceptions.

Work that is dependent on new Frameworks and Tools that were not available after

the first year of the project as (e.g as part of WP203 or WP204) will follow in a further

iteration.

Work on common APIs that is running in parallel to other development activities is

ongoing and is only partially included in the current state of the Building Blocks. This

is mostly also due to interactions with Frameworks (e.g. the integration with the

Asterics REST API with the SensorAPI or refinement of WebComponent and

Messaging APIs that are compatible with the architectural Integration domains, P4A

Nexus / MyUI design patterns)

It will be the purpose of our second milestone and the accompanying document to

particularly fulfill the remaining objectives:

To ease integration of novel heterogeneous sensor sources into AT based on state of

the art algorithms

To enable smart and proactive adaptation of AT by sensing its usage context in terms

of the users current state and the environment

To show-case possibilities for adaption techniques based on real world interactions

of IT-based AT

This Section describes design considerations and the relation to this work towards other

parts of the project Section 3 is structured according to the description of Prosperity4All.

Separate boxes highlight work done as part of the project is highlighted. Further content was

taken from the current snapshot of the online documentation of the delivered software

prototype as of January 2016. Section 4 describes further non-software resources delivered

such as handbooks and templates and tutorials in more detail.

The online prototype that is currently reachable via dspace.teco.edu provides an alternative

way to explore the content this deliverable. To summarize: this deliverable documents a

snapshot of the ongoing work that was done as part of the Prosperity4All project for the

purpose of reviewing the past 2 years of project work within work package WP202. This

documents milestone for the project that finalizes an important phase, however, work will

continue within and beyond the project in an iterative, agile and dynamic fashion.




1.2 Purpose of Building Blocks in the GPII Developer Space

Although is not the objective of this document to reflect on the overall GPII Developer Space

architecture (this is outlined as part of deliverable D201.3) and its role in the ecosystem (this

is outlined as part of D201.1), it is important to understand this work within the scope of the

overall effort to create a GPII Developer Space within Prosperity4All.

Figure 2: How and for what implementers (source: D402.2)

From the perspective of Building Block developers, the developer space is a means of

interacting with potential implementers.

Up to this date only few and rather isolated space exist for implementers to explore

components to build AT and accessible IT. This is reflected in the result of the first survey’s

with implementers (see Figure 2), that personal contact with colleagues (or project partners)

or general search are the most common strategies for exploring the solution space. And our

preliminary studies suggest that they mostly are looking for concrete code rather than

detailed documentation. Also background interviews conducted by the SP4 team show there

is scales only in very limited way today, and implementers feel great need for a community

space that particularly focusses on giving them access to new building blocks (currently more

and more external implementers are interviewed to support this).

At the same time developers complain about slow adoption and few possibilities to connect

to potential users with a reasonable effort. This is particularly important as there is often no

direct incentive to commercially market: suitable Building Blocks are often living in a

research and/or open source domain. Initial input from the evaluation team suggests that

motivation is seldom monetary but often the interaction with other developers.




Figure 3: Motivation to contribute to a developer space (source: D402.2)

Figure 4: Building Blocks within the context of the project (seen on the upper left)

From the graphical project representation in Figure 4 (that also models parts of an

ecosystem) it becomes clear that in contrast to implementations by the solution developers,

the building blocks are addressed towards AT implementers as important part of the

ecosystem. As the project tries to bootstrap the ecosystem, it is important that building

blocks would reach a milestone in terms of quantity and quality early in the project. The




collection presented here will be the basis of interaction with implementers and we hope to

make relevant links through the developer space. One important milestone was reached as

the current developer space web prototype that includes all the building blocks reported on

here was tested with developers and potential implementers. Starting with this first internal

beta release the Building Block Repository will become the primary way to share artifacts

from WP202 with the rest of the P4A ecosystem.

They also interact particularly with Development Tools (WP203) and need to integrate with

an overall Infrastructure Architecture (WP201). This part will be the focus of the last part of

the work that will be reported in the next iteration.




1.3 Repository Creation and Management Strategies

One of the main challenges of the work on building blocks was the bootstrapping of a

bottom up movement for sustainable contribution. In order to emulate “the real world” as

best as we could, it was important follow the non-prescriptive path of inclusive design that is

outlined as part of the SP1 work. With many developers contributing very different pieces

from real projects and implementers sometimes waiting for someone to tell them what to

use, it was often difficult not to choose the easy (yet not sustainable) path of top down

matchmaking within the project. Instead, we started early to document the diversity of

possibilities that were offered to implementers, e.g. through the wiki (see Figure 5).

In order to analyze good categorization structures we looked at number of “marketplaces”

and repositories, including git hub, the google play store and stackoverflow, but also

hardware listings like octopart (evaluation in SP4 also compared user preferences towards

different listing styles). We also looked at particularly the added value of an accessibility

focused repository. Another concern was that we did not want to replace other repositories

and that “our” Building Blocks should “live" outside of our prototype as a precondition to

sustainable open source development.

Figure 5: Start of the repository in the wiki until mid-2015

It became soon obvious that if the project should succeed on the premises of voluntary

adoption, we would have to do much more to support the searching process of

implementers and incentivize them to try out the offering that were laid out to them.


https://github.com/

https://play.google.com/

http://stackoverflow.com/

https://octopart.com/



Figure 6: Testimonial of early success with repository building... (Source:

http://lists.gpii.net/pipermail/dspace/)

1.3.1 Service Design, Use Cases and Personas

When we started with the task, it was one of our first activities to try to create a better

understanding of our stakeholders and the interactions we wanted to support with our

service. We started off with small focus groups and persona building activities inside the

work package and building first functional mockups of a repository within the first year. At

the same time the first background interviews were conducted by the evaluation (SP4) team

with implementers (SP3) and the developers (SP2) listing their planned contribution and

their own expectations. The results werewere shared via the public project wiki

(wiki.gpii.net) and an open discussion started. While working on a better fit between

components and user needs, we experimented with different documentation strategies via

the project wiki and soon found first success reaching our implementers (see Figure 6).

Driven by the early success we created our first prototypes of a Building Block Repository

(see Figure 7). However, it soon became clear that sustainability and scalability of our

approach became an issue and would be important to understand the role of our Building

Block repository as an entry point to a whole Prosperity4All ecosystem. After the first year of

the project, we reached a point at which we understood the diversity of the contributions as

well as the expectation of implementers.




Figure 7: First functional prototype at the beginning of 2015

With the work of the ecosystem (SP1) team progressing, it became clear that the Building

Block repository needed to be part of orchestrated project effort to bootstrap the GPII

Developer Space (DSpace) and could not be designed without an understanding of the whole

service ecosystem. At the same time it was the only possibility to test the interactions within

the ecosystem already within the project. The journey map of a persona using the DSpace,

that helped building the current prototype, is depicted in Figure 8. Looking at it, it becomes

clear that a fully functional Building Block repository is essential for this persona.

Figure 8: Journey map describing possible interactions with the repository (source:SP1)

The general usefulness of any repository is naturally strongly dependent on the contributed

content. With more content available the usability became an increasingly important factor.

Within 2015 the process of iteratively increasing both usefulness (through more content)

and usability (by better navigation of this content) became one of the core schemes of our

collaborative work that were channeled into a unified to design of the GPII Developer Space.




Much of our experience with collecting components as part of the Wiki and communicating

with implementers inside the project are present in this design.

Figure 9: Design Sketch of the Developer Space

1.3.2 Categorization and Structuring in a Prototype

One of the main challenges when moving from service and interaction design ideas towards

a tangible prototype was an understanding about the search strategies of the users. The

evaluation team (SP4) helped considerably by formatively testing our ideas and prototypes

at an early stage. While personas were very helpful in the design phase to consider particular

edge cases as well as to generate hypotheses about “typical” users, we external feedback on

concrete designs was needed. With the milestone of creating a first internally usable version

the Building Block repository as described in this document, we are for the first time able to

watch implementers interacting with the offering we are making and ask them for concrete

feedback. Figure 10 shows that the importance of search seems to be at least reflected in

the use of the GPII Developer Space prototype by our project-internal implementers (we

tried to equally support both search and exploration at any stage)




Figure 10: Exploration strategies of users in the latest Developer Space user study.

While building the prototype we had to rely on assumptions and early research on the

concrete prototype. Supporting effective search and exploration, the organization and

categorization became an important issue.

One cornerstone was existing efforts and experiences by partners. For example we took

inspiration from the Raising the Floor Solutions Masterlist as we found out that classical

categorization schemes given e.g. by common standards were not fit for the users we had in

mind building the Developer Space.

While providing solutions in terms of specific needs was clearly a given criterion for

categorization, we looked at many other functional development sites and research on

adoption of open source software by developers and decision makers to understand better

useful criteria for our prototype. In the end we decided to rely on our concrete target group

when building the prototype, as they are our first users, without whom bootstrapping such

an effort that includes a strong community will not be possible.

Figure 11: Important factors when selecting Building Blocks (source: D402.2)


http://old.raisingthefloor.org/content/solutions-masterlist



Both the searchable prototype and the documented content delivered within this work

particularly consider the output by surveys and formative evaluations on wireframes

conducted by the eval team during the last year (see Figure 11). E.g. the faceted search

mechanism allows direct filtering by License (see Figure 12)

Figure 12: Search facets of the prototype

An important factor for the Developer Space will be that users (i.e. implementers) find useful

tools and that developers can offer their tools in a fashion that they are found specifically by

stakeholders in the accessibility domain. Therefore it is wise to look particularly at

categorization schemes. While this might be not so important for mainstream software

developers looking for concrete functionality, many non-classical developer types we want

to address, like AT product developers, healthcare professionals or relatives have a domain

specific view. Furthermore procurement might be a driving factor for accessibility

improvements and the need for adoption of components, so that alignment with existing

schemes might prove as an opportunity in some cases.

The final editing interface of the Building Block repository that we have built on top of

Drupal 7 is shown in Figure 13. It provides an easy to use web interface that allows

developers to add content. The categorization is done via a tagging interface whose

categories were derived from our research with users and whose terms were bootstrapped

from existing sources like the solution master list or other sites. Following an inclusive

approach the tagging interface, however, allows the user to specify new categories, if

needed. It will be one challenge to curate and merge those categories in the future,




however, already during the bootstrapping this method gave us good feedback e.g. on

missing dimensions (categories).

Figure 13: Editing interface for the repository

Figure 14 shows how a contributed component looks like in the listing. The categories allow

users to easily discover similar content or to filter searches (like in Figure 15) based on the

given criteria.




Figure 14: Example Listing

Important elements of the current listing structure are:

Quick access to examples (Getting started)

Quick access to further documentation (Read more)

A short overview description with an image

Filtering/Comparison based on relevant categories for implementers

Contact information

Access to up to date code

Commenting features (currently disabled until moderation possible)

Ability to add external video or demo content

Use of crowd-source tagging with a fixed initial shallow category (tag type) structure

and initial tags

Important additional features to enable the use cases in SP1 (not yet available) will be added

through the Quality Infrastructure, the overall gamification elements and the linking with

other parts of the GPII Developer Space.




Figure 15: Search results with faceted browsing capabilities




2 List of contributed Building Blocks by Task

In this chapter we report the list of different Building Blocks that are contained in the

repository. The structuring does not follow the categories that we used in the online

prototype, but reflects initial structure that we used in the Description of Work for the

funded Prosperity4All project. The subsections refer to the task number within the

Workpackage 202 (e.g. section 2.4 refers to Task 202.4). While large parts are available

online we added dedicated information that shows the progress made within the project.

This information is shown as boxes in section 2.2 onwards. Before we start explaining the

different components, section 2.1 (Task 202.1) particularly also covers the collection of

(project) external Building Blocks by either partners of Prosperity4All or external developers

that are part of a growing open source collection.

2.1 External Building Blocks and online collection (FHTW)

One important task of the WP202 activities is to conduct an extensive research on already

available open source modules, libraries and components by 3rd party developers. The

description of these external building blocks and their integration into the first version of the

Developer Space Repository helps to establish a comprehensive collection of AT-related

resources for developers, in addition to the building blocks which are contributed by P4All

consortium members in SP2/WP202. In subsequent improvements of the Developer Space

Repository infrastructure, database federation and the automated integration of external

sources will be supported so that further (manual) addition of external Building Blocks will

become less important.

By the time of project month 22, a first set of external building blocks has been collected

(mainly by FHTW and KIT) and added to the D-Space repository prototype. These modules

contain 3rd-party libraries, coding demos, hardware designs, and build instructions as well as

stand-alone software tools for applications in various fields of accessible design and assistive

technology. For the stand-alone tools it will be decided at a later stage of the

implementations if those tools should be classified as “products” and moved to the Unified

Listing repository.




The following tables gives a short overview on some of the collected resources and building

blocks:

Table 1 External Building Blocks for Input/Output and special interfaces

Resource / ext. Building Block

Description Link

Input Stick Android- and iOS compatible USB receiver supports

wireless keyboard, mouse, game controller HID emulation http://inputstick.com/index.php/en/

MaKey

Makey physical computing, alternative input devices http://makeymakey.com/

SmartGattLib Bluetooth LE Java library that simplifies the work with

Bluetooth SMART https://github.com/movisens/SmartGattLib

V-USB SW-defined USB, many applications for alternative HID input devices

https://www.obdev.at/products/vusb/prjhid.html

Table 2 External Computer Vision Building Blocks

Resource / ext.

Building Block Description Link

EyeWriter open source gaze tracking HW/SW http://eyewriter.org/developer/

Headtrackr Javascript library for real-time face tracking and head

tracking https://github.com/auduno/headtrackr/

tracking.js Computer vision algorithms for web applications in

Html5/javascript http://trackingjs.com/

Table 3 External Blindness/ low vision / speech creation Building Blocks

Resource / ext.


DAISY pipeline digital content migration to various formats; production and distribution of DAISY Digital Talking Books

http://www.daisy.org/pipeline2/overview




Describler accessible and reusable SVG

images https://github.com/shepazu/describlerhttps://github.com/shepazu/describler

ESpeak

Speech Synthesizer http://espeak.sourceforge.net/

LibLois Open-source braille

translator, back-translator

and formatter

http://liblouis.org/

Speak.js Speech Synthesizer javascript

library https://github.com/kripken/speak.js

SVG Sonifier Sonification of SVG charts

and graphs via Web Audio

and Speech APIs

http://schepers.cc/invisible-visualization

Table 4 JavaScript / HTML5 / Web related external Building Blocks

Resource / ext.


AFB Accessible, embedded video player with HTML5

controls

http://www.afb.org/info/programs-and-services/technology-evaluation/creating-accessible-websites/download-afbs-accessible-html5-video-player/1235

User Interface

Options

component allows users to transform the presentation

of the user interface and content resources so that

they are personalized to the individual user's needs

https://github.com/fluid-project/infusionhttps://github.com/fluid-project/infusion

Infusion Table

of Contents

component

component examines a page for HTML heading

elements, and generates and formats a list of links to

headings that can be used to navigate the page.

https://github.com/fluid-project/infusionhttps://github.com/fluid-project/infusion

Infusion Text-

to-Speech

component

javascript wrapper around the SpeechSynthesis

Interface from the Web Speech API. Web Speech API.

https://github.com/fluid-

project/infusionhttps://github.com/fluid-

project/infusion

First Discovery

Tool

Preferences Editor designed to be an entry point for

users who are new to customizing a user interface to

match their own needs and preference

https://github.com/GPII/first-discovery


https://github.com/shepazu/describler



https://github.com/fluid-project/infusion








https://dvcs.w3.org/hg/speech-api/raw-file/tip/speechapi.html

https://dvcs.w3.org/hg/speech-api/raw-file/tip/speechapi.html







Table 5: External remote control Building Blocks

Resource /

ext. Building

Block

Description Link

jQuery URC uses jQuery to simplify the access to

the official URC webclient library.

http://sourceforge.net/projects/traceurcsdk/files/Webclient-Generic-Client/3.1/http://sourceforge.net/projects/traceurcsdk/files/Webclient-Generic-Client/3.1/

JavaScript

URC

binding to UCH-provided sockets,

based on the URC-HTTP 2.0

specification

http://www.openurc.org/tools/friedolinfoerder-jquery.urc.js-1.0beta/jquery.urc.js

Table 6 Other external Building Blocks

Resource / ext.


AutoHotkey scripting language for OS automation https://autohotkey.com/

AMCharts Accessibility enhancements for a very versatile chart library http://paypal.github.io/amcharts-accessibility-plugin

Bootstrap extension for the Bootstrap 3 web development framework,

adds keyboard and screen reader support http://paypal.github.io/bootstrap-accessibility-plugin/

Docverter Service Convert documents written in HTML, Markdown, or LaTeX to PDF, Docx, RTF or ePub via HTTP API

http://www.docverter.com

Readium JS library for EPUB3 publications http://readium.github.io/index.html

2.2 AT Specific I/O Modules (P4A T202.2)

In Task 202.2, specific hardware and software modules by P4ll partners are refined (or newly

created) and integrated into the P4All infrastructure. In particular, these modules enable

special input- and output capabilities for building alternative Human-Computer Interface

(HCI) solutions and accessible interaction strategies for novel (or existing) products, including

microcontroller-based input (measuring sensors, processing switch input), output

(controlling external actuators) or camera-based input solutions (computer vision algorithms

for face tracking or feature extraction from live camera images). The following sections give

an overview on the state of these components:


http://sourceforge.net/projects/traceurcsdk/files/Webclient-Generic-Client/3.1/







2.2.1 AsTeRICS AT Modules (FHTW)

In course of the AsTeRICS project (FP-7 STREP, 2010-2013), a flexible system for graphical

design of Assistive Technology solutions has been developed, which includes a JAVA/OSGi-

based middleware / runtime system, a graphical editor for the design of assistive solutions

(so-called “AsTeRICS models”) and more than 150 sensing-, processing and actuator-plugins

which can be combined and parameterised using the graphical editor.

In the first year of the P4ALL project, strategies for a flexible integration of AsTeRICS-based

solutions into various application scenarios have been evaluated and implemented by

consortium member FHTW. Two AsTeRICS-based solutions were already applied in course of

SP3-implementations by consortium members LIFEtool and GuadalInfo.

Although it was initially planned to completely extract certain useful plugins from the

AsTeRICS framework in course of the WP202 tasks (respectively remove the bindings of

these plugins to the middleware and provide them as plain JAVA/C++ source code), the

discussions with the SP3-implementers revealed that it would be more useful for them to

provide a customizable, shrinked version of AsTeRICS (including the middleware) which

maintains the flexibility of the graphical design and adaptation of the solution, but

significantly reduces the needed system resources for its deployment and adds certain

communication channels to transfer live sensor data and control signals from/to the

AsTeRICS model to/from the implementer’s application. Thus, the AsTeRICS runtime

environment could run in parallel with the implementer’s application and expose additional

GUI components only if needed.

This concept was realized during project months 12-20 and turned out to be successful and

very flexible. AsTeRICS building blocks were implemented by LIFEtool (for their Windows-

based learning software “FlashWords”) and by GuadalInfo (for their Linux-based computer

terminals) to add camera-based cursor control.

To facilitate the process of building shrinked-down AsTeRICS deployments to different target

platforms which only contain the necessary plugins / building blocks and services, FHTW

developed the AsTeRICS Packaging Environment (APE) and a websocket interface for data

exchange with running AsTeRICS models, and a strategy for dealing with the various (and

often concurring) licenses involved.

AsTeRICS Packaging Environment (APE)

The AsTeRICS Packaging Environment allows the selection of a set of AsTeRICS model files

and creates a downstripped (minimum size) version of the AsTeRICS Runtime Environment

(ARE) including plugins, configuration files and data files to execute these models.

Optionally, the APE allows the creation of native installers for Windows, Linux and Mac using

JavaFX packaging technology..


http://www.asterics.eu/

https://github.com/asterics/P4AllBuildingBlocks/wiki/AsTeRICS-Packaging-Environment-%28APE%29





https://github.com/asterics/P4AllBuildingBlocks/wiki





http://docs.oracle.com/javase/8/docs/technotes/guides/deploy/self-contained-packaging.html#BCGIBBCI



The created packages are runtime-only versions and don't have an AsTeRICS Configuration

Suite (ACS) included. The packages are intended for developers of accessible products to

embed AsTeRICS functionality into their deployment by creating small and use-case

optimized packages for their platform of choice. If native installers are created for the

customized packages the Java Runtime Environment (JRE) is embedded and the application

is seamlessly integrated into the operating system (native launcher e.g. .exe file, icon,

shortcut, ...).

In course of the project Prosperity4All, several building blocks were created as downstripped

versions using APE. Check several example configurations here .

Managing Licenses of the AsTeRICS Building Blocks

Due to the many different plugins and their 3rd-party dependencies with dedicated licenses,

the original license of the AsTeRICS system had to be GLPv3 (because some of the plugins

contain GPL’ed code which then influences all the middleware and the whole AsTeRICS

release). In the P4All project, one requirement was to select the most permissive license for

a particular building block or use case - which makes it possible for a larger group of

implementers (including implementers of proprietary software) to use these building blocks.

In course of their P4All work, FHTW integrated a license managing feature into the APE

packaging tool. For a particular use case (for example involving 5 desired building blocks) the

APE tool collects all license information for the involved building blocks and puts their

license information into the deployment folder, so that it becomes easy for an implementer

to deduce the resulting license implications.

For all code developed in the AsTeRICS project itself (including all AsTeRICS middleware and

plugin skeletons), FHTW chose a dual-licensing approach (MIT or GPL) which allows to

license these source code modules for a particular deployment either with MIT (most

permissive) or GPL (if other GPL code is contained in the deployment). For more information

please refer to the AsTeRICS P4All Building Blocks repository:

https://github.com/asterics/P4AllBuildingBlocks/blob/master/LICENSE_dual.txt





https://github.com/asterics/P4AllBuildingBlocks









2.2.2 Websocket Interface for AsTeRICS Building Blocks

(FHTW)

The websocket building block provides a generic bidirectional data interface to a running

AsTeRICS deployment, where other AsTeRICS-based building blocks perform sensing,

processing or actuation tasks. Using this interface, sensor data can be forwarded to a

browser or another application to visualize the data or trigger actions. Vice versa an

application can send data into the AsTeRICS system - for example to trigger actuators like a

home control appliance. (Read more in the GPII Developer Space)

Addr. Special Needs: General Inclusion/Assistance

Technology Type: Prototyping

License: MIT / GPLv3 (dual licensed)

Used/Supported Tech.: Java, AsTeRICS

Addr. Tech. Solution: diverse (depending on application)

Source Repository: https://github.com/asterics/P4AllBuildingBlocks/tree/master/NetworkIO/

Work done as part of the Prosperity4All project until January 2016:

The exact details of the interface are still to be defined and could be adapted to

special requirements of implementers if necessary. The websocket interface was

newly developed by FHTW in course of the P4All project.

2.3 Generic Multimodal Interaction Modules (P4A T202.3)

In course of task T202.3, several hardware and software modules have been further

developed or refined for use within the P4All ecosystem by the responsible P4All partner

organisations. These modules serve various kinds of Human-Computer Interaction tasks

and/or allow interfacing of multimodal sensor data for application in assistive applications.

Specifically, the integrated modules include microcontroller platforms for interfacing sensors

or actuators to desired computing systems, camera input modules which use computer

vision algorithms for alternative computer input and haptic/touch I/O modules for adding

haptic feedback to various user interface components.


node/25

http://dspace.teco.edu/en/needs/general-inclusionassistance

http://dspace.teco.edu/en/technology-categories/prototyping

http://dspace.teco.edu/en/licenses/mit-gplv3-dual-licensed

http://dspace.teco.edu/en/implementation-technologies/java

http://dspace.teco.edu/en/implementation-technologies/asterics

http://dspace.teco.edu/en/solutions/diverse-depending-application

https://github.com/asterics/P4AllBuildingBlocks/tree/master/NetworkIO/



2.3.1 Arduino UNO: Microcontroller Interface (I/O Transducer

Modules) (FHTW)

The Arduino component provides an interface to the

popular Arduino Uno microcontroller and makes analog inputs and

digital inputs and outputs available for desired applications. The

Arduino UNO is one of the most popular boards of the constantly

growing Arduino ecosystem. It provides 13 digital input/output pins

and 6 ADC-channels with 10 bit resolution and 3 PWM channels for

D/A conversion. (Read more in the GPII Developer Space)

Addr. Special Needs: Physical, General Inclusion/Assistance

Technology Type: Microcontrollers


Used/Supported Tech.: C, C++, Java, AsTeRICS

Addr. Tech. Solution: Interfacing of sensors / actuators, environmental control

Source Repository: https://github.com/asterics/P4AllBuildingBlocks/tree/master/Microcontroller/Ardu...


● The Arduino component was refined and tested according to the requirements of

the P4All project

● The license information was extracted for the packaging tool (APE)

● A demonstration deployment for implementers has been created, showing

capabilities of the Arduino building block

● The demo deployment and configuration files were added to AsTeRICS P4All github

repository: https://github.com/asterics/P4AllBuildingBlocks

2.3.2


http://arduino.cc/de/Main/ArduinoBoardUno

node/15

http://dspace.teco.edu/en/needs/physical


http://dspace.teco.edu/en/technology-categories/microcontrollers


http://dspace.teco.edu/en/implementation-technologies/c

http://dspace.teco.edu/en/implementation-technologies/c-1



http://dspace.teco.edu/en/solutions/interfacing-sensors-actuators

http://dspace.teco.edu/en/solutions/environmental-control

https://github.com/asterics/P4AllBuildingBlocks/tree/master/Microcontroller/Ardu...



2.3.3 Universal HID Actuator: Mouse/Keyboard/Joystick

Emulation (FHTW)

The Universal HID Actuator is a hardware module which emulates

Mouse, Keyboard and Joystick HID devices on a target computer. It

receives the control commands via a wireless Bluetooth link. The

HID Actuator can be used to enable mouse cursor control,

keyboard input or game console control via a personalised input

setup - no extra driver installation on the target computer is needed. (Read more in the GPII

Developer Space)

Addr. Special Needs: Physical

Technology Type: Input Emulation


Used/Supported Tech.: C, Java, AsTeRICS

Addr. Tech. Solution: Input Device Emulation

Source Repository: https://github.com/asterics/P4AllBuildingBlocks/tree/master/Microcontroller/Univ...


● The HID actuator hardware and firmware were updated, several bugs were found

and the stability could be improved

● Use case scenarios and test procedures were defined and executed

● The license information was extracted for the packaging tool (APE)

● A demonstration deployment for implementers has been created, showing

capabilities of the HID actuator building block




node/16

node/16


http://dspace.teco.edu/en/technology-categories/input-emulation


http://dspace.teco.edu/en/implementation-technologies/c



http://dspace.teco.edu/en/solutions/input-device-emulation

https://github.com/asterics/P4AllBuildingBlocks/tree/master/Microcontroller/UniversalHIDActuator



2.3.4 Camera Input Module: FacetrackerLK, XFacetrackerLK:

(FHTW)

The FacetrackerLK component uses a standard webcam or

external camera and provides movement information of

facial features from a live camera video. The estimated

relative movement of a user's nose and chin are provided in

x- and y-direction.

The FacetrackerLK component builds upon OpenCV and

uses a combination of the HaarCascade and the Lukas

Kanade Optical Flow Tracking Algorithms to provide efficient and accurate tracking also on

low performance platforms. A re-calibration of the face position is initiated whenever

excessive drifting of the feature spots is detected. (Read more in the GPII Developer Space)


Technology Type: Computer Vision


Used/Supported Tech.: OpenCV, C++, Java, AsTeRICS, Windows

Addr. Tech. Solution: Alternative User Interface

Source Repository: https://github.com/asterics/P4AllBuildingBlocks/tree/master/CameraInput/Facetrac...


● The XFacetrackerLK building block was newly developed - it features cross-

platform compatibility and was used by P4All partner GuadalInfo for their

accessible Linux terminals.

● The FacetrackerLK component was refined and tested according to the

requirements of the P4All project - it was used by P4All partner LIFEtool for their

FlashWords application

● The license information for FacetrackerLK and XFacetrackerLK were extracted for

the packaging tool (APE)

● Demonstration deployments for implementers were created, showing capabilities

of the FacetrackerLK and XFacetrackerLK building blocks

● The demo deployments and configuration files were added to AsTeRICS P4All

github repository: https://github.com/asterics/P4AllBuildingBlocks


node/14


http://dspace.teco.edu/en/technology-categories/computer-vision


http://dspace.teco.edu/en/implementation-technologies/opencv




http://dspace.teco.edu/en/implementation-technologies/windows

http://dspace.teco.edu/en/solutions/alternative-user-interface

https://github.com/asterics/P4AllBuildingBlocks/tree/master/CameraInput/FacetrackerLK-windows



2.3.5 P4A Haptic Module (CERTH)

P4A WebHapticModule aims at simplifying the

whole process of adding haptic feedback to a

web application, towards improving web

content’s accessibility and also enhancing end-

users’ cognitive capabilities. It also makes web

content exploration more entertaining.

(Read more in the GPII Developer Space)

Addr. Special Needs: Vision, Low Vision, Cognitive

Technology Type: Web Technology

License: BSD

Used/Supported Tech.: C++, JNI, Java, Windows


Source Repository: https://github.com/P4ALLcerthiti/WebHapticModule

Work done as part of the Prosperity4All project until January 2016: A first version of the module that supports adding haptic feedback in web

applications was newly developed. This first version of the module along with corresponding usage instructions have

been uploaded to GitHub: https://github.com/P4ALLcerthiti/WebHapticModule A complete example showing how the P4A WebHapticModule can be used to add

a 3D scene with haptic feedback in a preferred web page/application has been also developed and uploaded to GitHub: https://github.com/P4ALLcerthiti/WebHapticModule/tree/master/TestApp

A video presentation showing a simple use case scenario is available at: https://www.youtube.com/watch?v=pFxUimFy8Mk

A paper that presents the P4A Web Haptic Module has been already presented in CogInfoCom 2015: Kaklanis, N., Votis, K., & Tzovaras. D. (2015). Adding haptic feedback to web applications towards improving end-users’ cognitive capabilities, 6th IEEE Conference on Cognitive Infocommunications (CogInfoCom 2015), 19-21 October 2015, Győr, Hungary

2.3.6


node/54

http://dspace.teco.edu/en/needs/vision

http://dspace.teco.edu/en/needs/low-vision

http://dspace.teco.edu/en/needs/cognitive-disabilities

http://dspace.teco.edu/en/technology-categories/web-technology

http://dspace.teco.edu/en/licenses/bsd


http://dspace.teco.edu/en/implementation-technologies/jni




https://github.com/P4ALLcerthiti/WebHapticModule

https://github.com/P4ALLcerthiti/WebHapticModule

https://github.com/P4ALLcerthiti/WebHapticModule/tree/master/TestApp

https://www.youtube.com/watch?v=pFxUimFy8Mk

http://coginfocom.hu/conference/CogInfoCom15/



2.3.7 P4A Android Vibration Module (CERTH)

P4A AndroidVibrationModule is an Android Library that offers a mechanism for easily

adding vibration feedback to Android applications. Even if it is based on the native Android

vibration framework, however, it offers greater simplicity compared to the native

framework. (Read more in the GPII Developer Space)

Addr. Special Needs: Vision, Low Vision, Cognitive

Technology Type: Android App

License: BSD

Used/Supported Tech.: Android


Source Repository: https://github.com/P4ALLcerthiti/AndroidVibrationModule

Work done as part of the Prosperity4All project until January 2016: A first version of the P4A Android Vibration Module was newly developed. A set of predefined vibration patterns is offered. Vibration feedback is supported for a variety of events (e.g. on click, on focus

change, etc.). This first version of the module along with corresponding usage instructions have

been uploaded to GitHub: https://github.com/P4ALLcerthiti/AndroidVibrationModule A complete example showing how the P4A Android Vibration Module can be used

to add vibration feedback to various GUI components of an Android application has been also developed and uploaded to GitHub: https://github.com/P4ALLcerthiti/AndroidVibrationModule/tree/master/MyTestApp

2.4 Smart Device and Environment Modules (P4A T202.4)

Integration with smart environments offers new business opportunities for AT providers

with regard to the internet of things and ambient assisted living. Building blocks that enable

real world interaction both regarding control and discovery were developed as part of the

project. One goal is to integrate also with standards like the Universal Remote Console (URC)

technology (ISO/IEC 24752) and its technical standards for implementation (published by the

openURC Alliance). A special focus was put on the inclusive aspect of smart environments

that allow spontaneous interactions of users with that environment, i.e. the fact that

anything that can be controlled by user standing in front of a switch should be able to be

controlled by anyone at a similar position with the same ease.


node/55




http://dspace.teco.edu/en/technology-categories/android-app


http://dspace.teco.edu/en/implementation-technologies/android


https://github.com/P4ALLcerthiti/AndroidVibrationModule

https://github.com/P4ALLcerthiti/AndroidVibrationModule

https://github.com/P4ALLcerthiti/AndroidVibrationModule/tree/master/MyTestApp



2.4.1 EnOcean: Smart Home Integration (FHTW)

EnOcean is an energy-harvesting wireless sensor network

widely used in home- and building automation tasks. As KNX,

enOcean provides many different sensors and actuators for

smart home control and management. This component

utilizes the Priscilla java library for the EnOcean

implementation. The EnOcean plugin provides an interface to the EnOcean sensors over an

USB stick (EnOcean USB300) or an IP gateway.



Technology Type: Smart Homes and Building Automation



Addr. Tech. Solution: Accessible Buildings

Source Repository: https://github.com/asterics/P4AllBuildingBlocks/tree/master/SmartHomeIntegration...


● The enOcean building block was newly developed

● Test cases were defined and executed

● The license information for the enOcean building block was extracted for the

packaging tool (APE)

● A demonstration deployment for implementers was created, showing capabilities

of the enOcean building block




http://portal.teco.edu/dspace/?q=en/node/12

http://www.enocean.com/en/home/

node/12


http://dspace.teco.edu/en/technology-categories/smart-homes-and-building-automation




http://dspace.teco.edu/en/solutions/accessible-buildings

https://github.com/asterics/P4AllBuildingBlocks/tree/master/SmartHomeIntegration/enOcean



2.4.2 KNX: Smart Home Integration (FHTW)

The KNX standard is one of the major European

standards for building automation. Many different

sensors and actuators are available from various

manufacturers including lighting control, heating,

ventilation and air conditioning, automated blends or

door actuators. (Read more in the GPII Developer Space)


Technology Type: Smart Homes and Building Automation



Addr. Tech. Solution: Accessible Buildings

Source Repository: https://github.com/asterics/P4AllBuildingBlocks/tree/master/SmartHomeIntegration...


● The KNX building block was updated (for using the new Calimero2.0 middleware)

and extended (to provide sensing capabilities - e.g. to read light switches)


● The license information for the KNX building block was extracted for the packaging

tool (APE)


of the KNX building block




http://portal.teco.edu/dspace/?q=en/node/11

node/11


http://dspace.teco.edu/en/technology-categories/smart-homes-and-building-automation




http://dspace.teco.edu/en/solutions/accessible-buildings

https://github.com/asterics/P4AllBuildingBlocks/tree/master/SmartHomeIntegration/KNX



2.4.3 Point and Control: Spatial Interaction for Remote

Control (KIT)

This module enables the user to place and retrieve URLs in the

environment by simple pointing gestures. This is realized with

the use of the Microsoft Kinect depth camera, which can track

multiple users in the room.


Addr. Special Needs: Literacy

Technology Type: Remote Controlling, Spatial Interaction, Physical interface

License: MIT

Used/Supported Tech.: C#, Javascript

Addr. Tech. Solution: Simplifying, Adjustable or Alternative Input Devices

Source Repository: https://github.com/teco-kit/PointAndControl


● Implemented and validated an interactive mechanism to specify new target

locations in the environment using the pointing approach. Prior to this, locations

had to be specified in a configuration file.

● Implemented and evaluated an alternate strategy to recognize which location a

user wants to select. This is based on machine learning instead of the strict

geometric approach using pointing rays and collision detection.

● Refactored the Android application for remote control to a modern Web-

Application to support multiple devices and operating systems. The system now

requires neither login nor downloading of any special software (only mobile web

browser needed)

● The external interfaces were updated to integrate with other remote control and

smart home solutions, e.g. URC and OpenHAB

● Improved code quality with continuous integration and testing platform

● Improved packaging and deployment of the component


node/6

http://dspace.teco.edu/en/needs/literacy

http://dspace.teco.edu/en/technology-categories/remote-controlling

http://dspace.teco.edu/en/technology-categories/spatial-interaction

http://dspace.teco.edu/en/technology-categories/physical-interface

http://dspace.teco.edu/en/licenses/mit


http://dspace.teco.edu/en/implementation-technologies/javascript

http://dspace.teco.edu/en/solutions/simplifying

http://dspace.teco.edu/en/solutions/adjustable-or-alternative-input-devices

https://github.com/teco-kit/PointAndControl



2.4.4 IndianaJS: Spatially aware Web of Things (KIT)

IndianaJS is a spatial location and interaction library for

Web-of-Things-enabled web sites. It scrapes web sites

annotated with relative position information and transforms

locations relative to the user. E.g. makes it easy to add

screen-reader friendly dynamic directions to real-world

related content. (Read more in the GPII Developer Space)

Addr. Special Needs: Blind, Low Vision

Technology Type: Web Technology, Remote Controlling

License: MIT

Used/Supported Tech.: Javascript, HTML5

Addr. Tech. Solution: Remote User Interface, Real-Time Navigation

Source Repository: https://github.com/indianajs/indiana-js


New module provide a framework for very simple spatial interaction on “Web of Things”

website by providing a unified wrapper around:

Orientational sensor data (Orientation and Acceleration)

Object identification (from web site data, using schema.org definitions)

Object tracking

Event mechanisms to inform library clients that specified objects are in a certain

position relative to the user

Added IoT-Compass Demo/Tutorial to the framework

o Use D3JS to create accessible SVG elements comprising the core compass

o Adding Touch gestures (using HammerJS) (e.g. turn the lamp on/off)

o Added Haptic feedback via HTML 5 API to signal to the user if an object is in

front of him (this is useful when 'scanning' for objects in a room)

o Added and Tested ARIA/screen reader support

o Read entire compass to see the objects in the room

o Read only what is current front of you (ARIA Live)

Demoed and presented at the Internet of Things conference:


node/50

http://dspace.teco.edu/en/needs/blind



http://dspace.teco.edu/en/technology-categories/remote-controlling



http://dspace.teco.edu/en/implementation-technologies/html5

http://dspace.teco.edu/en/solutions/remote-user-interface

http://dspace.teco.edu/en/solutions/real-time-navigation

https://github.com/indianajs/indiana-js



Andrei Miclaus, Jack Unseld, Alexandru Miclaus, Matthias Berning, Till Riedel,

Michael Beigl (2015) IndianaJS: Building Spatially Aware Web Sites for the Web of

Things, Proceedings of the 6th International Workshop on the Web of Things,

doi:10.1145/2834791.2834796

Andrei Miclaus, Matthias Berning, and Till Riedel: IndianaJS: Building spatially

aware web sites for the Web of Things, Proceedings of The 5th International

Conference on the Internet of Things (IoT 2015)

2.4.5 Context-WiFi Login (KIT)

This building block contains source code for different tag and

context based authentication schemes for open Wi-Fi access for so-

called captive portals.

It uses (polymer) web components to provide context-adaptive

login mechanisms that can be added post-hoc to many WiFi

installations where a basic level of access control is needed.

This includes access to accessible smart home installations in your home or providing access

to your company guest network without inaccessible password schemes that use paper.


Addr. Special Needs: Blind, Low Vision

Technology Type: Web Technology

License: BSD

Used/Supported Tech.: Web Components, Polymer, HTML5, Javascript


Source Repository: https://github.com/teco-kit/UsableWi-FiAccess


In the building block “Context WiFi Login” the KIT developed Smart Authentication

Modules for the easy inclusion of innovative authentication functionality into webpages,

as part of T202.4 (Smart Device and Environment Interconnection Modules).


http://dx.doi.org/10.1145/2834791.2834796

node/109

http://dspace.teco.edu/en/needs/blind




http://dspace.teco.edu/en/implementation-technologies/web-components

http://dspace.teco.edu/en/implementation-technologies/polymer




https://github.com/teco-kit/UsableWi-FiAccess



The work that was done is a continuation of research prior to Prosperity4All. In (Budde,

Köpke, Berning, Riedel, & Beigl, Ubicomp 2013) several novel methods for authenticating

mobile devices to a public Wi-Fi network had been presented. As part of that work, a total

of six authentication techniques were built and the code was shared with the community.

All the schemes can not only be used to log on to a Wi-Fi network, but more generally as a

method of web-based login.

In Prosperity4All, this work was continued. Even though different ways of encoding

credentials and/or using of out-of-band information for authentication have been

presented in research, the standard mode to authenticate to a guest Wi-Fi network still is

a combination of a login name and a password. This can be cumbersome on mobile

devices. Therefore, the goal was to introduce Smart Authentication Modules providing

seamless but secure access to smart environments, as providing wireless services is not

only about network quality but also about user experience and ease of access has become

an important factor. Integrating context-based access control and authentication

mechanisms into reusable web components offers easy-to-use technology that lowers the

barrier for active inclusion in today’s mobile and future cyber-physical environments.

Extending on the work before, a comparative user study was first conducted and

evaluated in order to get a better grasp of the usability of the six authentication modes.

The results have been published and presented at the “16th International Conference on

Human-Computer Interaction” in the session “Universal Access in Human-Computer

Interaction” (Budde, Riedel, Köpke, Berning, & Beigl, 2014). Subsequently, the prototypical

implementations that were used in the user study have been completely refactored and

built on state-of-the-art web technology, using the concept of so called reusable Web

Components that encapsulate both the behavior and the style of a web element that can

then be easily included and modified by developers. KIT’s new Smart Authentication

Buidling Block is built using the Polymer library.

2.5 Real-Time User Monitoring Modules (P4A T202.5)

Detecting the users need automatically is one the important prerequisite for adaptive,

inclusive interfaces. Building Blocks developed within the project allow developers to gain

more information about the current state of a user and to dynamically react to context

beyond static preference sets. Different components provide a technical basis for integration

of a diverse set of inputs beyond explicit interaction technology. The goal is the integration

with the run-time components developed in WP203 and to provide a basis for advanced

contextual user interface adaption. Current building blocks provide advanced processing

facilities employing advanced processing and cognitive system technology as a first step.




2.5.1 P4A SensorAPI (KIT)

The API provides web developers an easy and consistent way to handle devices with sensors

for multimodal inputs.

This framework provides unified APIs to access sensor that integrate smartphone build-in

sensors, external BT-LE Sensors (as already used for fitness tracking, health applications),

environment sensors via Wi-Fi, affect sensing sensors, virtual sensors implemented using

machine learners or e.g. model driven processing tools like Asterics in a unified way via web

interfaces (such as WebRTC, WebSockets) via a driver abstraction.



Technology Type: Sensor and Input Abstraction

License: Apache License 2.0

Used/Supported Tech.: Javascript, Cordova

Addr. Tech. Solution: Adjustable or Alternative Input Devices

Source Repository: https://github.com/teco-kit/p4a-sensorAPI

After different exploratory works using current Standards and APIs (like the Google

Chrome BT API), it was clear that current APIs are insufficient and too difficult to use for

Web Developers.

Within the scope of the project we developed a pluggable driver layer that can include

remote event sources (like from an Asterics model), as well as virtual sensors (see below)

in a unified fashion. The API abstracts from local and remote input sources. The API was

developed from scratch and can be used and extended by any JavaScript based

application.


node/48


http://dspace.teco.edu/en/technology-categories/sensor-and-input-abstraction

http://dspace.teco.edu/en/licenses/apache-license-20


http://dspace.teco.edu/en/implementation-technologies/cordova


https://github.com/teco-kit/p4a-sensorAPI



2.5.2 FallDetectionModule (CERTH)

P4A FallDetectionModule is module that detects falls (and/or potentially other human

locomotion activities) based on the activity-related recordings of accelerometers. The core

algorithm of the module has been built upon a neuro-fuzzy approach.



Technology Type: Desktop

License: BSD

Used/Supported Tech.: C++, Windows

Addr. Tech. Solution: Interfacing of sensors / actuators

Source Repository: https://github.com/P4ALLcerthiti/P4ALL_FallDetection

Work done as part of the Prosperity4All project until January 2016: Implementation of a mechanism for retrieving the accelerometer’s measurements. Implementation of a multilayer perceptron (Artificial Neural Network model). Several moving patterns, containing falls and other locomotion activities, were

recorded and annotated (1-fall containing, 0-no fall containing) for training the ANN. Implementation of a real-time mechanism for fall detection. Evaluation of the algorithm.

2.5.3 P4ALL Affect Sensing Module (CERTH)

P4ALL Affect Sensing Module offers a way to detect stress of individuals based on the

features extracted by emphatical sensors. A module that enables stress detection through

the data produced by the ProComp5 Infiniti Hardware paired with the SA9309M skin

conductance sensor and the EKG™ Sensor - T9306M .



Technology Type: Desktop

License: BSD

Used/Supported Tech.: C++, Windows


Source Repository: https://github.com/P4ALLcerthiti/P4ALL-Affect-Sensing-Module



node/57


http://dspace.teco.edu/en/technology-categories/desktop





https://github.com/P4ALLcerthiti/P4ALL_FallDetection

http://thoughttechnology.com/index.php/hardware/procomp5-infiniti-5-channel-biofeedback-neurofeedback-system-w-biograph-infiniti-software.html

http://thoughttechnology.com/index.php/sensors-83/skin-conductance-sensor.html

http://thoughttechnology.com/index.php/sensors-83/skin-conductance-sensor.html

http://thoughttechnology.com/index.php/sensors-83/ekgtm-sensor.html

node/59


http://dspace.teco.edu/en/technology-categories/desktop





https://github.com/P4ALLcerthiti/P4ALL-Affect-Sensing-Module



Validation of the results performed. Extraction of training data for threshold values completed. Threshold values for stress detection are to be determined.

2.5.4 Social Network Interaction Module (CERTH)

P4A SocialNetworkIteractionModule is a module that performs anomaly detection and root

cause analysis. Specifically, this procedure takes place with the use of K-partite graph.

Main features

The main features of P4A SocialNetworkIteraction include the following:

Two sets of test data: The first set is a simple example and the second set is an

example with real data from twitter where the followers and the following people

from random users are given.

Selection of parameters for k-partite graph. Default values are also given.

Level positions and the number of connections of each node are given as a result.


Work done as part of the Prosperity4All project until January 2016: Implementation of a Twitter parser Design of the storing input/output format Implementation of the k-partite based clustering algorithm Datasheet collection with users of Twitter and their Followings and Followers. Testing and preliminary evaluation the algorithm, using the Twitter’s datasheet

2.5.5 jActivity (KIT)

The module adds the possibility to classify the user activity

context during the browsing based on the acceleration of the

smart phone and leverages supervised machine learning to

create virtual sensors.


Addr. Special Needs: General Inclusion/Assistance, Vision, Cognitive

Technology Type: Activity Recognition, Virtual Sensors

License: MIT

Used/Supported Tech.: HTML5, Javascript, OpenCPU, R


Source Repository: https://github.com/teco-kit/jActivity/


node/58

node/2




http://dspace.teco.edu/en/technology-categories/activity-recognition

http://dspace.teco.edu/en/technology-categories/virtual-sensors




http://dspace.teco.edu/en/implementation-technologies/opencpu

http://dspace.teco.edu/en/implementation-technologies/r


https://github.com/teco-kit/jActivity/




At the begin of the project, we committed ourself to provide the actiServ system as a

building block for virtual sensors (http://dx.doi.org/10.1109/ISWC.2010.5665868). The

original implementation was based on MATLAB. The scheme allows crowd-sourcing of

virtual sensors using a client/server machine learning scheme for end-users.

Within prosperity4all we gradually created a new modular system that had a server and a

client component written in Javascript, gradually exchanging the parts for re-licensing,

while modularizing the system. The current version relies on standards and is modular and

extensible. It supports a wide range of HTML5 events, e.g. DeviceOrientation,

DeviceMotion and TouchEvent. Though it can be extended by any other HTML5 event and

the corresponding features. The current system contains three main components:

1. Database API to manage the crowd-sourced data including the specific user agent of

the device that was used to collect the data to allow a differentiation of different

users and devices.

2. An exchangable OpenCPU implementation that allows to run R code to build

classifiers based on the data available from the database.

3. A newly developed PMML to JavaScript converter that, eventually, brings the

JavaScript classifier into the web browser.

2.5.6 Open BCI: Bioelectric Signal Acquisition and Processing

(FHTW)

The Open BCI project provides open source hardware and

software for bioelectric signal acquisition systems (biosignal

amplifiers). The OpenBCI hardware consists of an 8-channel

bioelectric signal amplifier board with TI ADS1299 24 bit EEG front end, SD card slot and

Bluetooth Low Energy (BLE) wireless link. It also includes an ST LIS3DH accelerometer.



Technology Type: Bioelectric Signal Acquisition and Processing



Addr. Tech. Solution: Adjustable or Alternative Input Devices

Source Repository: https://github.com/asterics/P4AllBuildingBlocks/tree/master/BioelectricSignal/Op...


http://dx.doi.org/10.1109/ISWC.2010.5665868

http://www.openbci.com/

node/13


http://dspace.teco.edu/en/technology-categories/bioelectric-signal-acquisition-and-processing





https://github.com/asterics/P4AllBuildingBlocks/tree/master/BioelectricSignal/OpenBCI




● The OpenBCI hardware was ordered, set up and tested

● The OpenBCI building block was newly developed


● The license information for the OpenBCI building block was extracted for the

packaging tool (APE)


of the OpenBCI building block



3

3

3

3

3




3 Templates, Tutorials, Handbooks and Documentation

Apart from providing components as part of the Building Blocks we were also committed to

provide users with better resources for existing technologies. This particularly included work

providing development resources for the Universal Remote Console as part of the work on

Smart Environments (T202.4) and on accessible Web Development (T202.6).

3.1 Universal Remote Console documentation and templates

(HDM)

The Universal Remote console (URC) is standardized in ISO/IEC 24752. The purpose of the

URC framework is to provide a user interface exchange mechanism for all kinds of electronic

device or service (also called target). The idea is that everyone can connect to any target

with the user interface fitting their needs best. In order to enable such an exchange

mechanism every target must provide an abstract description of its operational interface. In

URC terms these abstract descriptions are called User Interface Socket Descriptions (or just

sockets). Based on these descriptions user interface developers can create personalized user

interfaces and virtually plug them into the target at runtime.

3.1.1 Socket Templates

An important prerequisite for the success of sockets is that they are as stable as possible.

This should be avoided as the change of a target’s socket makes it also necessary to adjust all

related user interfaces. Hence, the OpenURC Alliance provides a set of standardized master

sockets that can be refined and used for any specific target.

A master socket should be applicable to a whole class of targets. In order to equip any target

in that class of devices with a socket description, developers can choose from a set of master

sockets. If it is intended to describe only the most common, functionality of a device or

service that is typical for a target class, sockets can be directly used without any

adjustments. If a developer wants to add additional features he can still use a master socket

to describe the most common features and extend it by device specific aspects.

This reuse of master sockets reduces the risk of failures, reduces the effort of creating new

sockets and supports the grouping of devices in classes.

Wöhlke Web Electricity Socket Template 1.0

This document describes the various URC master documents for a “Wöhlke Websteckdose”.

The Electricity Socket developed by Wöhlke is a via HTTP controllable electricity socket with

an integrated temperature sensor. Based on these documents personalized user interfaces


http://dspace.teco.edu/en/node/21



https://www.woehlke-websteckdose.de/



can be developed in order to control such a device. All related documents were developed

by HDM during the first year of P4a.

Plant Sensor Templates 1.0

This document describes the various URC master documents for any plant sensor. All documents

can either be used directly or can serve as templates for more specialized devices. Based on the

abstract definitions of the plant sensor personalized user interfaces can be developed.

All related documents were developed by HDM during the second year of P4a.

NetAtmo Templates 1.0NetAtmo Templates 1.0

This document describes the various URC master documents for the NetAtmo weather

station. Based on these documents personalized user interfaces can be developed. The

NetAtmo weather station is a device that can record different in- and outdoor values about

the current weather situation. More information can be found at

https://www.netatmo.com/en-US.https://www.netatmo.com/en-US. All related documents

were developed by HDM during the second year of P4a.

Coloured light bulb Templates 1.0Coloured light bulb Templates 1.0

This document describes the various URC master documents for a coloured light bulb. Based

on these documents personalized user interfaces can be developed for controlling any

lighting system. This includes colour, brightness and saturation. All related documents were

developed by HDM during the second year of P4a.

DVD Player Templates 1.0

This document describes the URC master documents for any DVD Player. All URC Master

documents are on a generic level andan can be used by user interface developers or by

Vendors to make their device controllable via the URC framework. During the first to years

of the P4a project, HDM provided assistance and guidance for writing and standardizing all

related documents.

TV set 1.0

This document describes the various URC master documents for a TV-set. They can be used

as template or the final URC files for any controllable TV-set.

During the first to years of the P4a project, HDM provided assistance and guidance for

writing and standardizing all related documents.







https://www.netatmo.com/en-US

https://www.netatmo.com/en-US





Twitter Templates 1.0

This document describes the various URC master documents for Twitter that serve as

the base for the development of further personalized user interfaces.

During the first to years of the P4a project, HDM provided assistance and guidance for

writing and standardizing all related documents.

UPNP-av Templates 1.0

This document describes the various URC master documents for a UPNP entertainment

system. Based on these documents personalized user interfaces can be developed. All

related documents were refined by HDM during the first two years of the P4a project.

XBMC Templates 1.0

This document describes the various URC master documents for a XBMC entertainment

system. Based on these documents personalized user interfaces can be developed for

controlling a XBMC entertainment system via the URC framework.

All related documents were developed under the responsibility of HDM as part of T

202.4.The developed socket descriptions were used in T 301.4 of the P4a project in order to

test the prototype of the UCH / openHAB

3.1.2 Target adapter framework

The advantages of exchangeable, personalized user interfaces that are enabled by the

Universal Remote Console (URC) can also be applied to not standard compliant targets

(target ~ any electronic device ordeviceor service). In order to do this, the Universal Control

Hub (UCH) must be used as integration gateway that can connect to targets via target

adapters. Latter implement specific protocols that are needed to control certain devices or

services.

The target adapter framework provides a set of Java classes that simplify the building of new

target adapters and with that the integration of new targets. It frees developers from

implementing the integration in the UCH runtime by providing ready-to-use mechanisms for

update and session management. Hence, developers can concentrate on the

implementation of mapping socket elements on their related functions that must be

executed in order to control a target.

This framework was builtbuild during the first and second year of Prosperity4all in order to

enable a faster and easiereasyer integration of new targets that are needed by SP3

implementers. Furthermore, in T203.3 the project members UCY, FHG and HDM are working




on a prototype of the GPII runtime by combining the technologies of Asterics, MYUI and

UCH. Here, an appropriate demonstrator will be build. The demonstrator will implement one

of the use cases described in [1]. Therefore new target adapters will be needed which can

profit from the effort that was spent on the development of the target adapter framework.

Easy target discovery manager

This module can be used to register new targets in the UCH, just by editing an XML file. So

far, each target required its own target discovery module with a hard coded discovery

process. Due to the simple configuration mechanism by using an XML file this can be

avoided.

The module is of special value for targets that do not support a network based discovery

mechanism as well as for targets that do directly run inside the UCH. Furthermore, testing of

new targets is simplified.

The module was developed during the second year by HDM and simplifies the integration of

new targets that are needed by other project partners.

Wöhlke target adapter

This is a target adapter that can be used to control the electricity socket mentioned above

via the Universal Control Hub (UCH). The Woelke electricity socket is remotely controllable

multi electricity outlet with three electricity outlets and a temperature sensor that uses

HTTP.

The advantage of using the HTTP controlled electricity socket in combination with the UCH is

that it cannot only be controlled via its own web interface. Instead, all kind of personalized

user interfaces can be developed and used. Thereby taking the different user needs and

preferences into account.

HDM has developed and published this new target adapter as well as a configuration

manager for it. Latter is accessible via the UCH itself and can be used to add and configure

new targets of type “Wöhlke Websteckdose”.

All modules were developed during the second year of Prosperity4All and are based on the

target adapter framework as it is described above. The” Wöhlke Websteckdose” was chosen

due to its very generic character. It can be used to control a huge variety of devices just by

switching them on or off. Possible devices are lights, heating, TV sets, etc.




Time service Target adapter

This module can be loaded by a Universal Control Hub (UCH) instance. It provides the

current system time and date so that they can be displayed by any personalized,

individualized user interface.

This UCH module is target adapter and target at the same time. It is based on the target

adapter framework described above Being simple in its functionality, it is ideal for

demonstrating the principles of the target adapter framework. However, showing the time

in different formats and modalities is still a valuable functionality.

The module was developed by HDM during the second year of Prosperity 4All.

3.1.3 Tutorials and guidelines

During the first 22 months of the P4a project a new tutorials section at

http://www.openurc.org was created. http://www.openurc.org was created. This new

tutorials section comprises already existing as well as new, during the P4a project created

tutorials, guidelines and technical documentation.

So far, all tutorials were related to specific URC tools and components. This made it difficult

for new URC developers and users to find a good starting point or to find the appropriate

tool and related tutorials for the tasks they wanted to execute.

The new tutorials section organizes tutorials and other documentary sources in a more

process oriented manner. Furthermore, all sources are now organized according to their

importance for different user groups. This includes end users, backend developers or user

interface developers.

Furthermore, the following tutorials were created (click on headlines to read more on the

Developer Space):

Tutorial: Getting started with URC

This tutorial will give you an understanding of the main components of the URC framework

and the idea of exchangeable and personalized user interfaces. The main concepts of

Controllers, Universal Control Hub (UCH), targets, Sockets and the Resource Server are

explained in a simple scenario. For the basic example you need nothing more than a PC with

Internet access.

Tutorial: Creating Sockets with the SocketBuilder

This tutorial explains the creation of a socket for a very simple Todo-Service that we want to

control. We will create the Socket with the SocketBuilder step by step and deploy it on a


http://www.openurc.org/





node/29

node/28



local UCH instance for testing purposes. By creating the Socket the three types of Socket

Elements - variables, commands and notifications - will be explained.

Design Guidelines for User Interface Sockets

URC sockets are the base on which personalized user interfaces can be build. Since sockets

are the common base of all possible user interfaces they should be well designed and stable

in time. These guidelines help to develop reliable and well-designed sockets so that they can

be used by third parties (e.g., user interface developers)

Making a business case with URC

This user story tells a fictive business case which shall illustrate the concepts of URC Super

Sockets.

Frequently Asked Questions

This is a collection of some typical questions that users and developers encounter when they

are using the URC framework.

3.2 Web Development Resources (IDRC)

As shown in section 2.1 new compontents e.g. for sonification (flocking), additionally

improved documentation for parts developed e.g. as part of the Fluid project were included

in the Developer Space prototype. Documentation originating from different projects was

overhauled and included in the Developer Space (click link on headlines to read more):

User Interface Options Tutorial

This tutorial will walk you through the process of adding the Infusion User Interface Options component to your website.

Infusion Preferences Framework Tutorial

This tutorial will walk you through the process of building a Preference Editor using the Infusion Preferences Framework.

First Discovery Tool Tutorial

The First Discovery Tool documentation provides tutorials and API information about the First Discovery Tool.

Accessible Standardized Testing Guide

In a traditional test environment in education, if a student requires accommodations special arrangements and exceptions are required. The Accessible Standardized Testing guide on the Inclusive Learning Design Handbook aims to give strategies that provide computer-aided features which benefit all students.


node/56

http://wiki.gpii.net/w/URC_Super_Sockets_user_story

http://www.openurc.org/tutorials/FAQs.html

node/80

node/79

node/84

node/77



Inclusive EPUB 3 Guide

The Inclusive EPUB 3 guide within the Inclusive Learning Design Handbook (ILDH) provides practical strategies to thorny inclusivity and accessibility issues found in EPUB 3, and covers topics such as math, narration, and interactive content within EPUB 3 publications.

Accessible Web Games and Interactive Simulations

The Accessible Web Games and Interactive Simulations guide within the Inclusive Learning Design Handbook (ILDH) provides insights and techniques for creating accessible interactive content. Topics include orienting a screen reader user, communicating events, and cognitive load.


node/66

node/67



4 Conclusion and Future Work

As stated in the beginning of this document, it represents work in progress that has been

contributed and will be maintained in a collaborative way within the Developer Space. With

this deliverable we reached an important milestone regarding the components provided

within WP202 of the Prosperity4All project (aka Building Blocks). The searchable and

browsable Building Block Repository enables important interactions within the overall

ecosystem. It enables implementers to find suitable re-usable components in the domain of

assistive technology and accessible IT. If this collection can, however, make a long term

impact will highly depend on the active contributions of large community. We already know

that we can reach people through such an interface, but it only becomes useful to many

developers if high quantity and high quality content can be provided. It is a challenge for the

remaining work in the project to ensure both.

Technically the usefulness and usability of individual tools will be strengthened by the results

of the Frameworks (WP203) team that will provide tools to create highly adaptable systems

from a set of components by interlinking components. Some “missing” Building Blocks will

be contributed as part of feeding back those efforts into the GPII Developer Space (i.e.

Media Transformation and Self Adaptive Web Modules).

With important work from WP201 on architecture (like the quality infrastructure) and

gamification mechanisms we hope to solve the challenge of sustainable partially with the

help of crowdsourcing, partially with the help of infrastructure elements. The work on the

current state of the GPII Developer Space that includes highly innovative components

allowed us to engage already a number of both component developers and solution

implementers. Yet not all components will be useful for everyone. More tutorials on how to

integrate technology easily will have multiplication effects and will lead to further

interactions. While the importance of each individual Building Block or integration of many

might be of high value to an individual stakeholder or even a number of them, the important

value is the match making and community building role of the created repository within the

GPII Developer Space. Guided by parallel user testing and iterative integration with the other

parts of the GPII Developer Space we will build on top of the current milestone to now

dynamically improve on top of a living ecosystem.

Again: during this evolutionary process the main challenge will be the sustainable growth of

the GPII Developer Space. Crowdsourced tagging and descriptions already call for crowd-

sourced curation and editing. New (non-monetary) business models, gamification and

quality management strategies will need to be applied not only by the users of a GPII

Developer Space (ie. implementers) but also the GPII Developer Space itself. Further

dogfooding the outputs of other work done within the project will be an important part of

future work on a useful Building Block repository.


Report on first prototype of Building Block Repository · 2.2 AT Specific I/O Modules ... Easy...

Documents

Transcript of Report on first prototype of Building Block Repository · 2.2 AT Specific I/O Modules ... Easy...