The Preferences Framework

[Clark, Colin]

Hi everyone,

Over the past several months, we have been working on a framework to support the creation of preferences editing and discovery tools. Several such tools are already in development: Cloud4all's Preferences Management Tool and Personal Control Panel, and PGA's Exploration Tool. We know that a single user interface won't work for all users in all contexts, so the framework offers a set of building blocks and components to simplify the process of implementing tailored preference editing experiences.

This framework grew out of our initial work on User Interface Options, but has been profoundly generalized and expanded on as part of the PGA and Cloud4all projects. It includes:

* panels, views, and adjusters that allow users to edit their preferences and settings
* enactors that respond to a user's preferences and provide previews or full-fledged web transformations
* a component for persisting preferences sets in the GPII Preferences Server
* application schemas and a builder component for defining and binding the user interface of a preferences editor

Notably, the preferences framework offers a declarative means to define and assemble preferences editors without having to write large amounts of hard-to-change code. Instead, applications are authored as JSON documents that can be shared, merged, and modified amongst a community of developers. In the future, this approach will also support graphical tools that will offer helpers, occupational therapists, and members of the community a way to assemble their own customized preferences editing UIs without writing any code. More information about the architecture of the preferences framework is available in the GPII wiki:

http://wiki.gpii.net/index.php/Preferences_Framework_Overview

I know terminology has been confusing for people during the evolution of this framework. Moving forward, I'd like to suggest that we use the term "Preferences Framework" to identify this infrastructure we've created for building preferences editors. The term "UI Options" should only be used to describe the default Infusion component that can be added to the top of a web page (i.e. this thing: http://build.fluidproject.org/infusion/demos/uiOptions/html/uiOptions.html).

To avoid confusion, we've done a major renaming and simplification of the preferences framework in Infusion's master branch, which will ship in the 1.5 release. We've tried to ensure as much backwards compatibility as possible, and we'll also help the developers of the current tools port their code to the new naming scheme. Justin has described the changes here:

http://lists.idrc.ocad.ca/pipermail/fluid-work/2013-October/009213.html

Since its inception, one of the critical goals of Fluid Infusion has been to support our vision of a personalizable and end-user authorable web. To this end, the preferences framework will ship with and be supported as an important part of Infusion. Anastasia and others have been working hard to expand the documentation for it here:

http://wiki.fluidproject.org/display/docs/Preferences+Framework

Colin

---
Colin Clark
Lead Software Architect,
Inclusive Design Research Centre, OCAD University
http://inclusivedesign.ca