Description of Components

User Listener

Involved: Architecture team, Microsoft and Emergya should get involved early in the process.

Short Description: The user listener is the first step in the process of customizing a device/program to the user. The user identifies him/herself to the listener and the listener is then responsible for starting the process of calling up the preferences server (perhaps via matchmaker or by some other indirect means).

User listener listens to user various means of user login (camera, usb key, 2D barcode, face recognition, voice recognition). 

Users might want to stay as anonymous as possible, so therefore we might want to implement this based on some kind of token rather than your ID – and it’ll retrieve your prefs. based on that.

MatchMaker

Notes/Short Description: Aka. “Fitter”. Takes information about user environment and token/identity, passes some of this to preferences server and retrieves relevant user preferences. Decides on useful solutions and their settings and returns this information to the launch Manager, which in turn calls the relevant SALHs to set up and trigger the programs.

The elements to be matched are the user preferences and user environment - where 'environment' includes available solutions on computer and in cloud, device characteristics and environment characteristics. In the first rounds of implementations, the environment is likely going to be simple, like a select group of AT/features and a select few device characteristics, and in later implementation this will then extend to a complete set of environment information.

Launch Manager

Short Description/Notes: Located on user device. Retrieves preferences from MatchMaker and triggers the relevant SALHs (which in turn sets up the application(s) and launces them).

The original plan was to implement this as a node.js server running locally with Express. This might have to be revisited due to firewall restrictions/etc, which would prevent GPII from being used in a broad range of locations (work/public libraries/various access points).

Settings and Launch Handlers (SALHs)

Short Description:

Custom SALH: Used by AT or mainstream device that has access features and build in an SALH – it’ll accept input from the launch handler and change/apply it. It should be able to both launch and set up the program based on the input. This is built by manufacturer. The frontend/interface part of this SALH would basically be our open source API. The backend (which basically going into the product and setting it up) could be proprietary, so the Custom SALH could be proprietary and belong to the AT manufacturer (except for the API/interfacing frontend of the SALH, which basically would be an open source C4A product).

Declarative SALH:* *3^rd party/common setting and launch handler. This will be an open source module that is separate from the AT product (so created by a different group), but will take the input from the launch manager and apply to the AT product (using its API). This SALH is likely to be less stable (and hence perhaps less preferable) than the Custom SALH, since it is built by a third party, and is more brittle due to changes in the ATs API, different version inconsistencies, etc.

Preferences Server

Notes/Short Description:  Holds user preferences. This includes both general preferences ("I prefer high contrast"), and preferences specific to contexts ("In late hours I want 1.5x textsize") and programs ("I want X screenreader to read at Y speed"). Will likely be using a nodejs server with couchdb for storing preferences. Rest API.

Solutions Reporter

Short Description: Reports what solutions are available to a user. This includes both those locally available (AT installed on computers, features built into the OS) and available via the cloud (services that the user is subscribed to or free services listed as preferable).

Device Characteristics Reporter

Description: Report characteristics of the device, eg. screen resolution, pixels/mm, mic/camera availability, OS type/version, etc, etc.