From KDE-HIG_Wiki

Docker

Dockers present controls or settings that affect the active document window. Unlike non-modal Dialogs, they are meant to keep important controls and settings accessible at all times while the user is working on a task.

Several dockers can be open at a time. They can float on top of the document window, can be docked to it or appear as a tab in another docker window. Still, they take up screen space, so consider carefully if a non-modal dialog is more appropriate (the user performs settings and immediately closes the dialog).

General

Guidelines

When to use

• Use dockers to present controls or settings the user will at all times while working on a task.

When not to use

• Don't use dockers when the user performs settings immediately and will most likely not come back to them while working on the task. Use non-modal Dialogs instead.

Default positioning of dockers

• Remember how users arranged the dockers and open them at their previous position.

If opened the first time, keep the following rules in mind:

• Floating dockers:
  • Make sure your dockers do not cover relevant parts of the document window.
• Docked dockers:
  • First, arrange dockers at the right part of your document window.
  • Make sure the major interaction elements of each docker are visible by default.
  • When there are too many dockers for the right side, also fill the left side. Put overview dockers to the left, interaction dockers to the right. For example in KWord, the document structure is displayed on the left, zoom on the right side.
  • Avoid horizontal arrangement of dockers.
• Tabbed dockers:
  • To save screen space, you can provide related dockers in a tabbed dock window. Related along their context of use, not along technical relations.

Dockers and Document Interfaces

• Multiple Document Interface:
  • Provide dockers only once, that is for the parent window.
• Single Document Interface:
  • Provide dockers for each document window.
  • The usage of Single Document Interfaces is not suggested if a high number of dockers is expected to be utilized by the user.
• Tabbed Document Interface:
  • Provide dockers for each parent window. When single tabs can be detached, multiple parent windows may appear.
• Controlled Single Document Interface
  • Provide a parent window and tie the dockers to it. Each document window will refer to the same dockers. This approach has the disadvantage that dockers cannot be docked to the actual document window.
  • This approach is suggested when it is expected that the user will frequently switch between single documents, e.g. in an image manipulation application.

Auto-hiding

• Ability of auto-hiding when they lose focus > Don't do that (focus follows mouse)

Context sensitive dockers

Context sensitive dockers show up automatically on certain user actions, e.g. when an image is selected in a text editor, an image action docker shows up.

• Use contextual dockers for objects that are likely to be further operated, but the options are not currently displayed on the screen.
  • When an object of a certain type is selected, show the related contextual docker.
  • Provide them as floating docker by default. Make sure they don't cover the currently focused area. If the user docks the docker into the application, remember the position.
  • When the object is deselected, hide the contextual docker.
• Don't use toolbars for this purpose.

Docker Layout

• Use mini-controls in dockers to save screen space.
• Dockers are grouped in meaningful sections. The actions are grouped along their context of use, not along technical relations.
• Each section has a title.
• Labels are right-aligned, input widgets are left aligned.

Accessibility Notes

Implementation Suggestions

See Also

Related To