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

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?