Technical innovations

From the technical perspective, Cloud4all/GPII implies a challenge for all the groups involved that has turned into some technical innovations:

  1. A comprehensive registry with all available software ATs. Cloud4all/GPII has gathered information from most important European AT databases, giving them credit for the source of information. Cloud4all/GPII has provided ATs with a Universal ID number, added metadata through a usable GUI and offered quick access to all this information through the so called Solutions Registry. Apart from letting developers and vendors make GPII-compatible new solutions, the GUI developed (Semantic Alignment Tool) lets them easily find the best match between their configurable settings and others already existing. An intelligent search engine suggests settings semantically close. Cloud4all/GPII has also developed a vocabulary for preferences -Preference Terms Dictionary- that complements the vocabulary at ISO 24751-2 and all the mechanisms to translate from singular, application-based settings into the abstract vocabulary of the Preference Terms Dictionary (PTD) and vice versa, even finding mappings n to n, i.e. from one preference to multiple settings, and from one setting to multiple preferences. Besides, the Semantic Alignment Tool (SAT) helps them to find similar products based on features (tags) rather than categories.
  2. Cloud4all/GPII provides applications with responsiveness to context without any extra development on their side. Responsiveness is limited to interface settings but applications do not need to implement anything on their side to become context responsive. Whenever an application is GPII-compatible, the interaction is modified without any intelligence needed from the application. Applications just need to periodically read and apply the settings suggested by Cloud4all/GPII. On top of that, users can define cued context (‘I’m tired’ or ‘use my tired preferences’) and the system is able to detect and react to noise and light conditions as well.
  3. The Cloud4all/GPII architecture is unique amongst accessible systems with its high degree of systemic re-configurability and flexibility. It provides a comprehensive means for changing the deployment geometry of the system components, providing integrators and administrators of a Cloud4all/GPII production system with the ability to move workloads between the local device and the cloud without changing the system’s code or inner workings. Owing to the fact that the system’s topology is entirely defined in JSON documents that are declarative and conform to a regular schema, tooling can, in future, augment this process. The system’s extensive use of inversion of control, which minimizes direct component coupling in favour of dependencies mediated by the Flow Manager, provides internally a level of system flexibility that mirrors Cloud4all/GPII’s adaptability at the human level. Component implementations can be swapped out, configured, augmented, or modified without causing these changes to cascade throughout the system or impact component internals. Among other advantages, this architectural feature supports Cloud4all/GPII’s ability to provide multiple matchmaking strategies (see section 7.4) that are optimized for different use cases and that embody radically different approaches to the problem of inferring the appropriate solutions and settings for a user. Not only can these different matchmaking components coexist within the system, but Cloud4all/GPII also supports, at the architectural level, conditional dispatching amongst them as well as the ability to create hybrid matchmaker pipelines.
  4. Cloud4all/GPII architecture has elaborated a unique programming model based around the schematic representation of an application’s static state as documents. For example, the Settings Handler subsystem represents a generalized means for representing and configuring an entire system (comprising, for example, the user settings of an OS, and a set of launched applications together with their configuration) using a model of its static state. The architecture provides a means by which a large variety of AT can be configured and launched by expressing the user’s desired system state (i.e. the output of the Matchmaking process) as a JSON document. Notably, this approach can be integrated into current industrial web development workflows (e.g. JavaScript, Node.js, etc.), yet, unlike traditional imperative development methods, is also capable of supporting the use of authoring tools, model-driven development, and automated user interface generation systems that, while out of scope for Cloud4all/GPII itself, can be implemented in the future on top of the model-based “kernel” that this architecture provides
  5. The architecture provides a novel implementation of Benjamin Pierce and Nathan Foster’s concept of Lenses, which encode bidirectional transformations of the structure and format of a model or data structure. In Cloud4All, the Transformer component provides a declarative language for defining lenses that transform, for example, between abstract preference terms and platform- or application-specific settings. Notably, these lenses are themselves represented as “models” (meaning, as schematic JSON documents), which are capable of being themselves transformed by other lenses and, potentially, authored by end-users with the help of graphical development tools. The pairing of this approach to representing state (including the state of user’s N&P) with the lensing idiom also enables Cloud4all/GPII to support multiple ontologies, aligning and transforming them as needed throughout the system. For example, generic, cross-application terms are aligned with and transformed to and from application-specific formats using lenses. The default flat preference set structure can be expanded into a hierarchical “view” better suited to defining privacy policies based on categories of preferences. Cloud4all’s support for multiple ontologies is provided at the highest levels by the SAT, which collects a “meta view” of all known ontologies and how they relate, and at the runtime level by the Preference Server Framework’s Ontology Handler, which stores and operates transformation lenses between common ontology formats.
  6. Finally, as noted above, the Cloud4all/GPII introduces for the first time an architecture that can unify an coordinate accessibility features at 5 levels; OS, installed AT, browser, cloud accessibility services, and web applications, turning on and configuring different features at different levels – allowing users to select features at different levels as appropriate for best effect. For example, text enlargement or screen simplification is best done at web application level, translation is best at cloud or browser/cloud level, reflow best at browser, enlargement at AT/OS level and screen resolution changes at OS level.