Solution Compatibility Roadmap

What makes a compatible solution?

In order to be compatible with the GPII Auto Personalisation from Preferences a solution must:

• be known to the GPII as a solution for specific user preferences
• have known settings and how they map to preferences described as common terms
• have a known way to be launched and closed

This is achieved by providing a few configurations files to the GPII that declare these details. The GPII is then able match user preferences (possibly including context) and launch the solution with optimal settings for the user when they identify themselves.

Compatible Solution Roadmap

Solution	Status	Lead	PTD Updated	Solution file	Registered	Test User	Notes
OATTS (Open Access Tool Tray System)	2015-3-1	Alfredo	✓
CCCC (Controlable Crowd Caption Correction) Tool	2015-3-1	Slim
JAWS	2015-3-1	Wayne					Settings files are in INI format
GAHRT (GPII Annotated Hand Raising Tool)
ReadWriteGold							In C4A, add more settings
MAGic							Screen enlarger that works with JAWS
WindowEyes							Screen reader (currently bundled with MS Office)(owned now by AI Squared)
ZoomText							Screen reader/enlarger from AI Squared

Common preference terms

It is vital to manage the large number of possible settings, especially as some have different names for the identical concept and others with the same name are actually different concepts. In addition the range of values allowed may or may not vary between common terms. The Preference Term Database (PTD) is the GPII's tool where all solutions settings are registered to provide a manageable database of terms. All settings for solutions are added to the PTD

Steps for making a solution GPII compatible

For each solution to be be made compatible the following steps will be performed (work is being lead by the Tiger Team)

1. Identify key contact person(s) and contact them.
   1. Permissions - ownership - mgmt etc
   2. Technical (launch - settings access - meaning of settings)
2. Redesign the way a product handles settings (optional)
   1. Saves preferences to better match the GPII
   2. Uses settings -- to allow live use of externally changed settings
3. Create a translation/un-packing tool (as required)
   1. to convert binary and other compressed settings files into GPII inferrable/adjustable/transformable form.
4. Register and align the preferences/settings in the product with the Preference Terms Definitions Registry (PTD)
   1. Developer might do -- but we should offer since MUCH MUCH easier for us to do because we know what is in Registry and what they are called
   2. Developer should participate because they know what their term mean
5. Launch and Setting handlers
   1. Create/adapt/select launch and settings handlers
   2. Register solution - add to a installedSolutions file
   3. Update installed solutions file
   4. Can we do “live” settings change for context etc?
6. Create a test user file
   1. Formal Testing?
7. Document
   1. Solution specific notes - in DSpace
   2. Generic documentation for others

Helpful Links

1. GPII_Core_Infrastructure - When a user logs in
2. Building_A_Simple_Solution Example
3. Authoring Solutions Tutorial details instructions for a solution entry
4. Architecture_-_Available_transformation_functions - Tutorial on Value transformation
5. http://wiki.fluidproject.org/display/docs/Model+Transformation - Fluid Infusion Framework (Transformation)