Calligra/Usability and UX/Common/Dockers vs ToolOptions: Difference between revisions
| Line 1: | Line 1: | ||
== Tool Options vs. Dockers - What to use when and why == | == Tool Options vs. Dockers vs. Settings Dialogs - What to use when and why == | ||
(This Article | (This Article is not finished yet) | ||
=== 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'''. | |||
*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 dockers, 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. | |||
=== 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". | |||
The disadvantage is that the tool options docker shiws 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. | |||
Revision as of 10:59, 3 April 2011
Tool Options vs. Dockers vs. Settings Dialogs - What to use when and why
(This Article is not finished yet)
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.
- 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 dockers, 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.
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".
The disadvantage is that the tool options docker shiws 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.