Libs
From KDE-HIG_Wiki
This is the section where we collect requirements that must be implemented in qt or kde libs, not through the hig.
| Table of contents |
Visualisation of Focus
Marking the Active Panel
It seems that there is no consistent way (or any at all) how the panel (frame) that has the focus is visualised in KDE. Take e.g. Kontact or Konversation, and you use the tab key: How do you know where the current focus is, and thus: where e.g. your arrow keys effect.
It also seems that neither gnome nor windowsxp do this. gnome only marks the button that would respond to "enter" action. If you take e.g. nautilus, you never know when the focus is on the main pane (the folders and document pane). same with windows.
macosx does it, by drawing a tiny rectangle around the pane that has the focus. this is the behavior and visualisation i would suggest for kde4.
Marking the Active Input Element
Additionally, the panel which does not have the focus must not mark it's children as if they were active.
Take Kontact:
You have 3 list/tree views, the quick buttons in the left sidebar, the folder view and the mail list. In each of the three lists, an element is marked as the active element. This is wrong! They may only be marked as the active element when the panel actually has the focus, that means when you clicked/tabbed into the corresponding panel.
The problem with marking both as the active widgets is that the user
never knows when typing a letter will move him within the folder view
and when there will be no effect - try it yourself.. ;-)
Thunderbird does it correctly, see screenshots.
On the other hand: sometimes KDE does not mark at all which interface element is currently focused.
Take Kontact again: Hit Tab several times till it reaches the Search field above the Email list. Hit Tab again and it moves to the Status Drop-Down. Hit Tab again and .... the focus indicator is gone! Hit Tab three more times and it is back on the first link in the mail preview panel.
The indicator to mark focused links and tabs, or text input fields is not that eye-catching either.
Suggestion
- Only mark the active interface element as active. Other elements should be marked as selected only.
- Clearly mark active interface elements (use stronger indicators for the input focus).
- Draw a thin border around the panel of the active interface element.
Tabbed Window Layout
The Tabbed Window Layout is adopted by more and more applications and is a powerful way to let the user arrange related contents.
However, KDE's/Qt's current tabbed window layout has some shortcomings:
- It allows to undock tabs but not to dock them
- Arranging the sequence of tabs is possible in some, not in all implementations of the TWL.
- Arranging the sequence of tabs is difficult and requires calling the context menu multiple times.
Suggestion
- Make the tabs fully flexible (detaching, docking, changing the sequence) via drag and drop (requires a handle to grab a tab and adequate visual destination feedback where it will be dropped)
- Allow to grab multiple tabs and detach/move them together.
- Possibly, think of providing an alternate tab design which is not arranged horizontally but vertically and provides a preview of the tab's contents (like sidebar in KGhostview).
Toolbar Buttons that open Drop-Down Menus
In KDE 3.x, toolbar buttons that open a drop-down menu are marked by a little black arrow at the lower right corner.
In several usability tests it was found that users do not understand this. E.g. in Konqueror tests, users were not able to switch the view modes even if the moderator gave a hint ('You can change the mode with this toolbar button'). Even more alarming, they were not able to change the mode even if the moderator showed them how it works in the beginning of the test.
Suggestion
Instead of using one button to activate an action with a short click (e.g. 'back'), and to open the drop-down menu with a long click, use a broader button with a separator:
-------- | |v| --------
While the left part activates the default action, the right part of the button contains a small arrow to open the drop-down menu. The click-behaviour of two button parts should be independent of each other.
Modality
Dialogs should always be on top.
Current problems are:
- Dialogs in non-KDE applications (e.g. File Open in OOo with KDE Plugin)
- PGP Password dialog, e.g. in KMail (blocks application, but sometimes hidden by other windows) -> In general, there are problems when there is an interaction between two applications.
- Dialogs open on another desktop than main window
Language Aware Icon Support
Currently KDE doesn't support icons that change depending on the chosen interface language. KDE applications e.g. use a [B] icon for "Bold". In German "Bold" means "Fett" with the consequence that the corresponding icon should be [F] in a German language setting, and not [B].
Similarly there are icons which depend on the user's familiarity with the Roman ABC that is not used in all languages on earth. Again an example taken from office suites: The "spell checking" icon there uses "ABC". People not used to the Roman ABC may have severe problems understanding the meaning of this icon. An icon that uses letters which are familiar to him could solve this problem though.
Other icons that are affected by language settings include such that show directions - indention with tabs e.g. or the icon for "enter" which points from top right to bottom left. For languages that are read from right to left these icons point into the wrong direction.
Suggestion
Adapt icons depending on the language the user chose.
Correct and Consistent Cursor Usage
KDE uses a mix of desktop and web metaphors which uses both the cursor (arrow) and pointer (hand).
For example: KTreeWidget uses the pointer in order to select text whereas the QTreeWidget uses the cursor to select text.
For example: In KMail, the cursor is used to select a mail message for preview, however in Akgregator, the pointer is used to select a feed for preview.
See http://www.freedesktop.org/wiki/Standards_2fcursor_2dspec for more information. This standard is to help merge the behaviour between desktops so one cursor doesn't mean one think in one desktop, and another in a different desktop (as well as meaning one think in one _application_ and another in a different application).
Suggestion
- Standardize library usage so the same libraries are used in similar applications
- If QTlibs and Klibs are different, state which library to use in the HIG and consider other usages a violation
- Follow the standard provided by FreeDesktop.org for implementing cursors.
