From KDE-HIG_Wiki

Table of contents

1 Automated HIG Checks in KDE 1.1 Menus, Context Menus and Toolbars 1.1.1 Menus 1.1.2 Context Menus 1.1.3 Toolbars 1.1.4 Accessibility 1.2 Layout and Visual Design 1.3 Dialog Behavior 1.3.1 Dialog Depth 1.3.2 Modality 1.3.3 Focus 1.4 Feedback 1.4.1 Response Times 1.4.2 Success and Error Feedback 1.4.3 Drag and Drop Feedback 1.4.4 Other feedback dialogs 1.5 Help 1.5.1 Context Sensitivity 1.5.2 Embedded Help 1.5.3 What's this 1.6 Interaction 1.6.1 Error Recovery 1.6.2 Inactivity 1.6.3 Accessibility 1.7 Usability Bug Regressions

Automated HIG Checks in KDE

In december, there will be a workgroup meeting in Hamburg/Germany to discuss the possibilities of automated tests on HIG conformity.

This page servers as a container to list possible test criteria.

Menus, Context Menus and Toolbars

Menus

Menubar:

• Sequence of items in the menu bar
• check that items in menubar consist of a single word only

Menus:

• Items in correct menus?
• Sequence of items in the menus
• Max 15 items in a toplevel menu?
• Grouping correct (max 4 in a group)?
• Number of menu levels max 2?
• Menu sizes correct (min 3)?

Menu items:

• Ellipses used?
• Unavailable items disabled?
• No toggle command items?
• Standard icons?

Context Menus

Availability:

• All context menu items in the menus?

Context menus:

• Left or Double Click action corresponds to first item?
• First entry not delete (or the like)
• Item subgroups correspond to menu item groups (even if items may be missing)?

... rest see above!

Toolbars

Availability:

• All toolbar items in the menus?

Toolbars:

• Item subgroups and their order corresponds to the menus?
• Grouping correct (max 4 in a group)?

Toolbar items:

• Tooltips available?
• For exclusive options: Rather drop-down than toggle buttons.
• Toggle buttons for max 2 exclusive options, separated from other toolbar items

Text and Icons:

• Toolbar texts not too long?

Accessibility

Accelerators:

• For all items?
• No collision?
• If possible: Standard Accelerators

Shortcuts:

• Standard shortcuts?
• No collisions (internally)?
• No collisions (with general shortcuts)?

Layout and Visual Design

Groups of Options or Settings:

• Max 8 in a group, otherwise subgroups (determine via padding?!)

Padding and Alignment:

• Padding to border?
• Left-alignment in each column
• Right-adjustment in each column
• Indent of all subgroups equal?

Margins:

• each widget should use exactly one margin of width KDialog::marginHint() Its a common problem that a widget and a container widget both set a margin making the widget use double the blank space around it. Widgets should also use the global margins instead of the hardcoded ones.

Text:

• Capitalization correct?

Dialog Behavior

Dialog Depth

• There should not be more than 3 to 4 (?) levels of dialogs

Modality

• Check for application-modal dialogs and list them for the developer to evaluate if application-modality is really of need.
• Possibly test if options in a dialog can refer to the selected element (document, tree node, etc) only, or to any element.

Focus

• Are dialogs always in front of their parent?

Check especially the following points:

• 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

Feedback

Response Times

• Is there any kind of visual feedback for response times > 1 second?
• Check for response times > 10 seconds and list them for the developer to evaluate if they are really of need.

Success and Error Feedback

• Can this be tested?

Drag and Drop Feedback

• Are there ways to provide specific dnd feedback? If so: How to test it?

Other feedback dialogs

• An application that locates itself in the systray must not do so at initial startup, and should provide a message informing the user about the fact that it is located there.

• Applications that do not quit but run in the background when closing the window should provide a message.

• Welcome screens (?)

Help

Context Sensitivity

• Do Help buttons in a dialog open the correct chapter in the documentation?

• Percentage of help buttons in the dialogs (?)

Embedded Help

• Percentage of buttons, labels, options with tooltips versus no tooltips in the whole application (?)
• Percentage of options with tooltips in the settings dialogs

What's this

• Check for available What's this help

Interaction

Error Recovery

Undo:

• All actions undoable?

Inactivity

• Non-available functions, buttons, etc. are marked as inactive.

• Buttons and functions that are never available are non-existent.

Accessibility

Tab Sequence:

• All elements reachable per tab?

Color Schemes:

• Color schemes apply to all ui elements (line edits, text areas, ..)

Usability Bug Regressions

We are collecting a number of issues to test for in order to avoid usability regression bugs (things that worked in a previous version). Example: Konqueror not focusing the address bar after start-up in KDE 3.5.

Please add your testing criteria on an extra page: Usability Bug Regressions