User Interface Options Design Considerations

Owned by Gary Thompson
Last updated: Mar 31, 2009 by Jess MitchellVersion comment
6 min read

Overview

User Interface Options is presented as a two-pane interface. The left pane contains the options. The right pane displays a preview. When options are set or changed in the left pane, the preview in the right pane is updated immediately to show how the option will affect the interface.

Also reference: User Interface Options Wireframes

Options

Options in the right pane are represented as familiar form inputs and controls, with the addition of a slider control for some options. There are many options, so related options are grouped into a section with a plain-language title - "Easier to See", for example. As there are many options (and the number of options may grow in the future), an accordion interface was employed. The accordion was chosen so as to reduce the amount of information and controls displayed to the user at one time to reasonable, manageable chunks. Displaying all of the controls at once was explored, but was determined to make the right pane too long (incurred a scrollbar even at high resolutions and some options fell out of view) and intimidating (all of the controls displayed all at once interfered with people easily understanding the interface and quickly locating the controls they needed). The accordion allows the rollup of controls into a clickable heading, with only one section visible at a time, and the ability for the user to quickly open and close sections by clicking on the headings.

Using the accordion does necessitate good headings and descriptors for people to understand the groupings and find the controls they need. Additionally, some options could fall under more than one heading. Subsequently, the ability to quickly click and expand areas is necessary to solution.

Preview

The live preview provides a user immediate feedback of changes made to the options, increasing efficiency and accuracy of option selection and preference setting. There are some inherent design issues with the preview:

  • What content is represented in the preview? (real or representative?)
  • How much content is represented in the preview? (how much is enough?)
  • Does all potentially affected content need to be represented? (text, headings, images, layouts, forms, tables, etc.)

Because the pane is at most 50% width of a normal page, it will not be a true representation of a page, and it may be difficult to represent much content without resultant scrolling of the pane.

  • What happens when a user increases the text size substantially? (and then most of the preview content is pushed out of view)
  • What happens when the user cannot see the content that shows the result of changing a preference within the confines of the preview pane when changing the preference? (i.e., the user is not able to see a preview because the element(s) affected are not within view - would require scrolling - and thus without seeing the feedback, a user might conclude that the control change did nothing, leading to confusion)

These issues might necessitate tabs on the preview pane, each tab showing a smaller section of content. The problem with such tabs, however, is that it assumes that the user knows to change tabs to the "correct" corresponding content to preview her preference changes (which is unlikely). Perhaps the component can be smart enough to automatically change to the "correct" tab of content, however, many options affect multiple sections of content. So then which is the "correct" one to show?

Default Values

When a user access UI Options for the first time, the component needs to present default values for several controls (like text size). The question is, what is considered "default"? It was determined that the best starting value is the read/calculated value from the CSS that is currently being applied via the system theme/skin. Once a user has changed the default value by overriding it with a preference change, the overriding (user set) value will be preserved until the user further changes the preference setting or discards preference overrides. Reading in and/or calculating values requires some form of contract between UI Options and the system it is integrated with. In other words, the system must tell UI Options where to look for the "default" value. For example, "default" text size should be determined by looking up the font-size attribute of the body selector in the skin.css file.

The Result

A critical issue for UI Options is the result it can achieve. How much of the interface needs to reflect the change when the user submits preference changes? Is it acceptable for only 50% of the interface to increase text size? 80%? 100%? What is the user to conclude when only a portion of the interface really changes? In an environment like a portal, for example, content is being aggregated from disparate sources of varied content management models of varying authors. In some cases, each piece of content might have different structure, semantics, models, markup, and style. How is a cohesive result achieved?

There is an assumed expectation that a component like UI Options will transform 100% of the resultant interface. Anything less will confuse the user. Why didn't that_change? Why does _that look different? Didn't I set minimum font size to 24 point? (The user can go back and verify, yes she did) Why then does this section change to 24 point, but that section does not? There are no obvious answers and the user must conclude that the component is broken and not worth using. A half-this and half-that interface is likely less usable than a consistent interface. In those conditions, UI Options is really of no value.

What is to be done? It was decided that a contract is necessary. The contract is an agreement between the system and the UI Options component. The contract is wholly trust-based, with the system integrator specifying agreement of the system to provide the necessary access and control to UI Options to affect necessary change. If the system does not live up to the contract, UI Options cannot really do anything about it. The contract would have 3 levels:

  1. Basic - the system guarantees nothing
  2. Standard - the system guarantees some things
  3. Full - the system guarantees everything

Based on the level of contract specified, UI Options will filter the preferences and controls available through the interface. For example, a Basic contract means that UI Options will only present controls for preferences it knows it can successfully effect when it knows nothing about the system. This is likely to reduce UI Options down to just a few controls that a user can set, but UI Options is reasonably certain to have a 100% resultant effect. The Standard contract would expect the system to provide UI Options a defined set of access/control, which would allow UI Options to present more options and controls to the user. The additional information provided by the system via the contract ensures that UI Options has a 100% resultant effect (that it would otherwise be unable or unlikely to achieve without that information being provided). A Full contract would indicate that the system agrees to all of the requirement UI Options has to present all options and controls and be assured a 100% resultant effect. Thus UI Options will need to be able to flex to the system it integrates with, but the resultant effect must always be 100%. Verifying and/or enforcing the 100% effect is up to the integrator.

Ability To Use The Interface

UI Options desires to meet a broad spectrum of needs and preferences on a per-user basis. There exist very real scenarios where a user may not be able to use the UI Options interface without first applying preferences to the UI Options interface itself. For example, a user with low vision might need to immediately increase the text size/spacing of the interface or apply a high-contrast color scheme before being able to interact with UI Options at all. This might necessitate a "Make this easier to see" button that when clicked applies some preset preferences that would help a user with low vision successfully use the interface. But what if the user has perfect vision, but has a motor impairment? Would UI Options then need several high-visibility buttons in the interface and how does UI Options guess and rightly apply some set of preferences so a user with particular needs may successfully use the interface? Or does UI Options assume that such users will already have some form of assistive technology which does that for them?