[GlobalPreferences] Preferences Architecture

Richard Schwerdtfeger schwer at us.ibm.com
Tue Apr 16 10:31:20 EDT 2013

Hi Colin,

I have reviewed the document. Thank you for putting this together.

You need to define "Inversion of Control Philosophy" in the first section.
You provide a link to Fluid's Infusion but the page says nothing about it.

The security and and privacy section says nothing about meeting U.S.
Federal requirements for security or privacy. Is OAuth adequate? You may
not know but I  think it should be the intent to meet U.S. Federal

The document should also say something about how preferences are defined.
They are not defined in terms of medical disabilities but rather functional
limitations which could be cause by something as basic as a low light
conditions when using a mobile device. This ties back to the main document

When it talks about the Enactor you give an example of removing landmarks:
"Enactors can be of arbitrary complexity. In many cases, an Enactor may
well manipulate DOM elements directly (such as a content simplifier that
removes HTML5 landmarks such as "banner" and "navigation", leaving the
"main" content untouched). In other cases, such as this closed captions
example, the Enactor may delegate the actual work of performing the action
to another module (such as an HTML5 video player component). Here's an
example of how a developer might configure a UI Enhancer component with
this new closed closed caption Enactor along with others:"

Where you talk about simplification, I think what you meant to say is that
you are removing the landmark regions. Also, technically these are HTML5
ARIA landmarks. I say this as we will also need to be able to remove HTML5
elements which have equivalent semantic means as those ARIA landmarks (e.g.
<nav>, <aside>, <footer>, and <main>)

Persistence information: Preference should NOT be communicated in a
"cookie". This is a privacy issue as these preferences flow over the
network and can be monitored. If we had to store domain-specific
preferences I would recommend at least storing them in HTML5 local data

Regarding the name "captions": The proper name should be subtitles. This is
what they will be called in Indie UI and it is also the name used for the
HTML5 video track element that exposes them. We are going to go back and
change AccessForAll V3 for this.

We need to also consider context adaptation. Even if we have an initial set
of preferences specified by the user, future devices will be passing
preferences that are modified as a result of environmental changes. For
example, the student is watching a video lesson and goes into a noisy room.
The subtitle preference may then be activated. Our UI components need to be
flexible in a mobile environment.

Somewhere in here we need to specify how the user gets specific AT tools
they need - such as a plug-in. For example, a key part of our solution must
address Math Comprehension. This will require, at least in the near term,
plug-ins like Math Player.

What we have here is heavily browser dependent. We need to specify why
specific browser levels are necessary. Such as:

ARIA Support
CSS2+ Support
HTML5 and HTML5 Canvas support


Rich Schwerdtfeger

From:	"Clark, Colin" <cclark at ocadu.ca>
To:	"globalpreferences at fluidproject.org"
            <globalpreferences at fluidproject.org>, Fluid Work
            <fluid-work at fluidproject.org>,
Date:	04/12/2013 08:24 AM
Subject:	[GlobalPreferences] Preferences Architecture
Sent by:	globalpreferences-bounces at fluidproject.org

Hi everyone,

For the upcoming Preferences for Global Access report, I have been working
on an overview of our how we're designing an architecture to support
preferences discovery, editing, and management:


I've tried to give an overview of our technical approach, particularly
highlighting the need for a general framework that enables us to build the
diverse preferences editors that our designers have been working on across
the Floe, Cloud4all, and PGA projects. I also discuss the linkage between
PGA and the Infusion and GPII architectures as well as showing some
diagrams and sample code to illustrate how the pieces are starting to fit
together in practice.

I'd love to hear your feedback and suggestions on this document.

Jess, Vera, and Cynthia, once the community has had a chance to comment and
edit, I think this should be ready to cherry pick from for the Google Doc
you're working on.



Colin Clark
Lead Software Architect,
Inclusive Design Research Centre, OCAD University

GlobalPreferences mailing list
GlobalPreferences at fluidproject.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20130416/5e42ceb0/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20130416/5e42ceb0/attachment.gif>

More information about the fluid-work mailing list