Ideas for User Interface Transformation

This list of potential user interface transformations that might be supported by the FLUID framework was compiled during a working meeting on Thursday, May 2nd with the ATRC development team and Richard Schwertdfeger from IBM. This is by no means a comprehensive or definitive list; just an unordered, unprioritized collection of ideas about transformation. Please feel free to add to it.

Categories of Transformations

Layout & Presentation
Navigation (ie. Changes to the relationships of parts of the user interface to each other)
Control

Layout and Presentational Transformations

Density and complexity
- of information
- of user interface controls
Font sizing
Font leading and tracking
Borders and colours
Spacing
Text and layout direction (vertical vs. horizontal, left vs. right)
Linearization and flattening of columns, etc.
The appearance of textual cues: sarcasm, emphasis, humour, etc
Form field indications: required vs. optional, etc.
Speed of transitions
Self-voicing
Link affordances:
- external links
- navigational cues
- purpose of a link(eg. definitions, relationships, tags, etc.)

Navigational and Behavioural Transformations

Time-space condensations - separation of elements that were presented simultaneously into a linear sequence, or vice versa.
- Auto-portalisation - opening of "windows" in-place to other parts of application state without losing view context on demand
Focus cues
Concept maps
- Describes the structure or overall shape of a user interface visually, showing regions and how they relate to each other
Importance levels (eg. politeness in live regions, etc.)
Sorting (ascending vs. descending)
Breadcrumbs
Tool tips and expanded descriptions

Control Transformations

Auto-completion, word prediction, especially in context- or application-specific ways
Toolbars and menus

Other

Accessibility compliance of content

Modalities	Control Types
Visual	Pointer
Auditory	Keyboard
Textual	Voice
	Switch
	On-screen keyboard: pointer vs. scanning

Transformation in Context

For a user who has screen magnification enabled or is using a low resolution display, there are certain types of transformations that are most important. The ability to linearize the screen, flattening columns and laying out the page vertically is particularly effective. The user interface needs to be flexible enough to respond to this need, as well as to handle presentational and styling issues such as effective word-wrapping and re-sizing of UI controls.

Transformation and Non-transformation

An "all-win" modality for transformation is non-transformation - presenting alternative modes for access in one and the same view as a "fat interface" (with possibly latent behaviours). For example, a reordering control could be simultaneously accessible by Web 1.0-style numeric dropdowns as well as Web 2.0-style drag and drop. Alternatively, parts of the interface which could become dynamically editable when clicked on, but simultaneously presented with old-style navigation controls leading to a dedicated view for editing. Where this can be achieved it is ideal, since the form of the interface remains familiar to all users, especially where the "advanced" rendering would gracefully degrade to the basic rendering in the presence of primitive clients.

Except, of course, in cases where we can deliver a significantly improved user experience by designing alternative components that are specifically designed for a particular control scenario, assistive technology, or personal need. One of the potentially exciting abilities of FLUID is to, through transformation, deliver a user experience that is designed for unique needs rather than optimized for nobody in the universal design scenario.

Implementing UI Transformation

Metadata and Preferences are critical.

What information do we need to know to perform these transformations? How should this be represented to the user, and how do they interact with the transformation behaviour?
When should we ask for preferences?
- Ahead of time, in the abstract (eg. PreferAble; System Preferences, etc.)
- In context, when interacting with the user interface
How abstract should the preferences be? How do we show the user the affect their preferences settings will have on the application?

Browser not supported