Projects/Usability/HIG/Contributing

From KDE TechBase
< Projects‎ | Usability‎ | HIG
Revision as of 10:03, 27 June 2013 by Agateau (talk | contribs) (Add TODOs from Notifications page)

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

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.

Projects/Usability/HIG/Check_Box

  • Redo screenshots using Designer
  • Fix missing page: list

Projects/Usability/HIG/SOU_Workspace/Two_Lists

Projects/Usability/HIG/Slider

  • Refresh page: it is copied from GNOME guidelines and contains references to figures we do not have

Projects/Usability/HIG/Notifications

Purpose

Examples

  • Add screenshots

Guidelines

  • Do not add controls to notification.
    • Thomas: I would remove this. Adding action buttons is allowed in the API and has reasonable use cases, other controls simply cannot be added technically
  • Do not override system settings.
    • (remark: more specific)
    • Thomas: Which settings do you mean here?
  • Provide title and content text
    • (remark: not precise enough)
    • Thomas: guidelines regarding the wording of title and content are indeed very important. Maybe celeste can help here.
  • Customize notification with the origin's icon.
    • Heiko: word "origin" needs to be replaced; "icon" might be replaced by technical term
  • Provide actionable information (e.g. "Low battery power" "Only 13 min (2%) capacity remaining. Please save your stuff now. Your system will get shut down soon.")
    • should be according actual text
  • Heiko: to be defined: Are all notifications configured in KCM? If not, how to separate?
    • Kai Uwe: All notifications emitted through KNotify (ie. application has a notifyrc file) can be configured. Using the FDO notification dbus iface directly is discouraged. In 4.11 there's a configure button on notifications.

kdehig repository