Calligra/Usability and UX/Common/Dockers vs ToolOptions: Difference between revisions
No edit summary |
|||
| (2 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
== Tool Options vs. Dockers vs. Settings Dialogs - What to use when and why == | == Tool Options vs. Dockers vs. Settings Dialogs - What to use when and why == | ||
=== The Problem === | === The Problem === | ||
| Line 15: | Line 13: | ||
Each way is most useful for its own kind of options: | Each way is most useful for its own kind of options: | ||
*Tool option widgets change with the selected tool, so they are useful for any '''options/actions that do not apply to all tools'''. | *Tool option widgets change with the selected tool, so they are useful for any '''options/actions that do not apply to all tools''' i.e. that are context-specific. | ||
*Dockers are always visible, so they are useful for '''options/actions that are relevant to any context''' and '''are frequently changed/used''' | *Dockers are always visible, so they are useful for '''options/actions that are relevant to any context''' and '''are frequently changed/used''' | ||
*Menu items are always accessible but not as easily as dockers, so they are useful for '''options that are context-independent and unfrequently changed/used | *Menu items are always accessible but not as easily as dockers, so they are useful for '''options that are context-independent and unfrequently changed/used | ||
A special case are options/actions that are used frequently by some users or in some usecases, but only rarely by other users / in other usecases. Those actions can be made accessible by a menu item as well as an optional | A special case are options/actions that are used frequently by some users or in some usecases, but only rarely by other users / in other usecases. Those actions can be made accessible by a menu item as well as an optional docker, so the frequent users can activate the docker for easy access when needed frequently and otherwise disable them and still be able to access the option/action via the menu. | ||
The disadvantage of the tool options docker is that it shows a scrollbar if it contains too many widgets. This decreases usability, so the design goal is to '''keep the overall height as low as possible'''. | |||
This can be achieved by various means: | |||
*Remove unneeded elements | |||
*Use methods of [http://en.wikipedia.org/wiki/Progressive_disclosure progressive disclosure] (like menu buttons and combo buttons) to show more advanced features on demand | |||
*Group elements in tabs | |||
*Use widgets that don't require much vertical space | |||
=== Rationale === | === Rationale === | ||
| Line 27: | Line 32: | ||
The advantage of having context-specific elements in the tool options docker instead of dockers that are automatically enabled or disabled based on the selected tool is that the tool options docker stays the same height regardless of the selected tool, thus keeping the whole interface from "jumping". | The advantage of having context-specific elements in the tool options docker instead of dockers that are automatically enabled or disabled based on the selected tool is that the tool options docker stays the same height regardless of the selected tool, thus keeping the whole interface from "jumping". | ||
--[[User:Colomar|Colomar]] 13:50, 3 April 2011 (UTC) | |||
Latest revision as of 13:50, 3 April 2011
Tool Options vs. Dockers vs. Settings Dialogs - What to use when and why
The Problem
When editing a document, users often switch between different types of tasks (and thus tools). Many options that are currently available in dockers are usable in some of these tasks but not in others. So in order not to clutter their interfaces with dockers, users need to switch dockers on and off between tasks. This makes switching tasks very slow.
The Solution
We currently have three ways of presenting options and actions:
- As a tool option widgets
- In a docker
- In a menu item
Each way is most useful for its own kind of options:
- Tool option widgets change with the selected tool, so they are useful for any options/actions that do not apply to all tools i.e. that are context-specific.
- Dockers are always visible, so they are useful for options/actions that are relevant to any context and are frequently changed/used
- Menu items are always accessible but not as easily as dockers, so they are useful for options that are context-independent and unfrequently changed/used
A special case are options/actions that are used frequently by some users or in some usecases, but only rarely by other users / in other usecases. Those actions can be made accessible by a menu item as well as an optional docker, so the frequent users can activate the docker for easy access when needed frequently and otherwise disable them and still be able to access the option/action via the menu.
The disadvantage of the tool options docker is that it shows a scrollbar if it contains too many widgets. This decreases usability, so the design goal is to keep the overall height as low as possible. This can be achieved by various means:
- Remove unneeded elements
- Use methods of progressive disclosure (like menu buttons and combo buttons) to show more advanced features on demand
- Group elements in tabs
- Use widgets that don't require much vertical space
Rationale
If the above rules are applied, users won't have to break their workflow to switch dockers on and off. Dockers will be used to customize one's general user interface whereas tool options provide the context-specific UI elements.
The advantage of having context-specific elements in the tool options docker instead of dockers that are automatically enabled or disabled based on the selected tool is that the tool options docker stays the same height regardless of the selected tool, thus keeping the whole interface from "jumping".
--Colomar 13:50, 3 April 2011 (UTC)