Projects/Usability/HIG/Contributing

From KDE TechBase
< Projects‎ | Usability‎ | HIG
Revision as of 09:33, 27 June 2013 by Agateau (talk | contribs) (Transfer todos from Dialog and ListView here)

Report problems

If you found an area that was unclear or is not even covered in our HIG, tell us about it. We can be reached on the kde-guidelines mailing-list.

Conventions

Following is a set of guidelines to ensure the HIG itself is consistent.

Terminology

  • Use the word Control, not Widget to refer to a user interface element. Rationale: "Control" is more widespread outside the UNIX community. It is also reasonable to expect more and more applications will be written using QtQuick and QtQuick controls in the future.
  • Use check box and combo box, not checkbox or combobox.

TODO

Start page

  • Figure out what to do of the legacy stuff (at the bottom of the page)

Projects/Usability/HIG/Dialogs

  • Create "inline-editing" page
  • Create "info-panels" page

Projects/Usability/HIG/ListView

Purpose

Recommendation should be checked

Guidelines

Add subsections

Selection

Check against recommendation.

Choose between either:

  1. In any other case, use the dual-list pattern because it allows users to easily see which items are selected at any point, without having to scroll through the available options
  2. Use a list box for multiple selections with more than five options.

Get a new type of check boxes for list views implemented: KCheckBoxes:

  • KCB are flat (no frame, no shadow, no bevel) for clear differentiation from normal check boxes.
  • KCB are hidden by default, that means when no list item is selected.
  • KCB have a fade-in effect on mouse over to introduce themselves to users.
  • KCB are transparent and therby clearly part of the list item.
  • Legacy keyboard use applies to KCB as well. Thus, the whole item can be clicked to toggle option.

kdehig repository