From The Document Foundation Wiki


    • Use check boxes for non-exclusive options that have clear alternatives. If the opposite is ambigous, e.g. portrait vs. landscape, use two radio buttons instead. In case of multi-selection with many items consider a dual-list paradigm.
    • Use radio buttons for a few mutually exclusive options. If there are more than five options (or if there is not enough space to arrange four or five options), use a dropdown/combobox or list instead.
    • Use a dropdown list for single selection of one out of many items. If users should be able to add items use a combobox. For a single selection out of a large number of items (n>20), use a list view.
    • Prefer a list view to show items that belong together and in case there is enough space.


    • Do not use the selection to directly perform a command.
    • Do not add controls to the drop-down (e.g. check boxes for each item).
    • The selection should always "enable" an option or change the state of an option to "on". Checking a negative or disabling option is a double negative and causes confusion and errors.
    • Prefer controls that show the options without further user interaction, except for the following cases:
      • the list of options may change over time,
      • the contents are obvious from the label and the one selected item, for example Month and January
      • the control is part of a related sequence of controls. For example, to set a reminder to ring 5 hours or minutes before or after an event.


    • In a group of options (in particular radio buttons) make the first item the default.
    • Place options that represent general options (e.g. all, none) at the beginning of the list.
    • Sort list items in a logical order. Make sure sorting fits translation.
    • Do not have blank list items; use meta-options, e.g. (None) instead


    • When the dropdown/combobox is on toolbars or sidebar, changes should not become effective until the user leaves the control or collapses the open widget. In particular, hoovering over the expanded dropdown or wheeling respectively navigating with arrow keys the closed control should not apply the selection on-the-fly. The change is made effective with tab and enter only.
    • On dialogs, consider to apply changes immediately; that means when another list entry is selected by mouse wheel or arrow keys.
    • Do not initiate an action (like print, send, delete) when the user selects an item in a group of radio buttons.


    • When options are subordinate, this relation should be visualized by indenting the sub-options.
    • Make sure the items are easily accessible via keyboard by moving distinctive letters to the beginning of each option. For example, in a list of countries on continents, write "Germany (Europe)" instead of "Europe/Germany".
    • Label a group of controls with a descriptive caption to the top left of the group.
    • Create a buddy relation so access keys are assigned.
    • Use sentence style capitalization without ending punctuation (neither dot nor colon) for group label.
    • Do not add line breaks in captions. If necessary place an additional label below the control.

    Floating dropdown widgets

    • If appropriate, make dropdown widgets on toolbar or sidebar floating after undocking.
    • Floating controls show the function name in the title and allow to close per x (style ToolWindow). Not other controls are placed in the title panel (e.g. toolbar functions).
    Example for a floating control
    Example for a widget while in floating mode
    • Floating controls are non-resizable, stay on top of the app, and close on escape. They are part of the F6 cycling mechanism for accessibility.
    • Whether a control can be floating is clearly indicated in collapsed state.
    left non-floating, right with indicator that this widget can be floating
    Non-floating widget at left, with the indicator that this widget can become floating right