Page Comparison

...

The goal of UI adaptation is two-fold: 1) to

1. To build a degree of flexibility into Web-based user interfaces so they can better accommodate the diverse needs of users under differing circumstances and contexts

...

2. to make it easier for Web developers to make UIs accessible from the start, and harder to cut corners or bolt on "one-size fits all" solutions.

We envision a UI framework that leverages good code design techniques, markup and styling practices, and dependency injection in order to minimize the built-in expectations about how a user interface is presented and controlled that tend to make them brittle, less reusable, and hard to configure.

...

How Will Fluid User Interfaces be Flexible?

Fluid's user interface layer is built with flexibility in mind, allowing The Fluid framework will allow three main aspects of the user interface to be varied based on context or preference:

1. Layout, sizing, and presentation: leveraging Web standards such as HTML and CSS, and providing easy ways supply deliver alternatives as neeededneeded
2. Navigation: using simple, embedded microformats, the framework will generate alternative ways to navigate within an application
3. Control: customize keyboard controls, accelerators, and tabbing schemes by injecting alternative JavaScript handlers

In contrast to early architectural sketches for FluidRather than a wholesale swapping of Fluid components, we're no longer planning to swap components out for alternatives as part of this approach. Rather, we're leveraging leverage existing Web technologies that foster separation of structure from presentation, and augmenting those with a more effective means for delivering variations on the presentation and control bindings at runtime. Simply put, Fluid will enable key pieces of our components to be easily modifieduse the strengths of HTML and CSS to deliver modified presentations and behaviour for our components based on user preferences.

Categories of Adaptation

...

Some of this material is already available in ARIA, others will need to be defined.

UI Semantics:

User interface semantics provide agreed-upon names for aspects of user interfaces:

...

Fluid components are built out of smaller, encapsulated units that are injected into them in as parameters. Not only might you combine several smaller components into a larger one, but individual components themselves are composed of logical units that can be substituted or extended during development or at runtime based on user preferences.

...

The use of an IoC container will foster a more declarative approach to building user interfaces, allowing developers to wire up behaviour and declare bindings in a way that can be overridden by the user or implementor. Key The key to this is offloading certain the types of programmatic logic to the framework that is most susceptible to the risk of hardcodinghard-coding to the framework. For example, keyboard handlers:

These examples are still half-baked, Sunday night musings...

Typical barebones JavaScript approach:

...

Framework-managed key bindings: Example 1: Typical barebones JavaScript approach. In this example, keyboard bindings are hard-coded into the handler function, making them hard to modify.

 function handleCutKeyPress () {
   $ (element).keydown (function (event) {
     if (event.which === fluid.keys.C && event.ctrlKey === true) {
       copyFunction ();
     }
   });
 }

Example 2: Framework-managed key bindings. In this example, the keyboard bindings have been externalized and the framework is responsible for generating the appropriate handlers, calling client code when needed.

var keymap = {
   modifier: CTRL,
   key: C
};

$ (element).bindActionToKey ("Copy", keymap, cutFunctioncopyFunction);

Example 3: Declarative dependency injection:. In this example, keyboard handlers are defined in an entirely declarative manner. Functionality is "wired up" by injecting keyboard maps and their associated logic into the component. While this JSON syntax is more verbose than the previous example, it contains no code, and thus other wirings can be more easily substituted to reconfigure the component. This approach is also significantly lighter-weight than parsing XML data.

 beans {
   textEditorComponent: {
     bindings: {
       keyMaps: windows
       actions: actionBindings
     }
   },

   windows: {
     Copy: {
       modifier: CTRL,
       key: C
     }
   },

   mac: {
     Copy: {
       modifier: Command,
       key: C
     }
   },

   actionBindings: {
     Copy: myObject.copyFunction
   }
 }

Background material

• Accessibility Transformation Brainstorming