Tuesday June 4th, 2013 by Björn Balazs and Heiko Tietze
Human interface guidelines (HIG) are software development documents that offer application developers a set of recommendations. Their aim is to improve the experience for users by making application interfaces more consistent and hence more intuitive and learnable.
The central aim of KDE HIG is to create a consistent experience across the software compilation. This means to apply the same visual design and user experience as well as consistent access and predictable behavior of common elements in the interface – from simple ones such as buttons and icons up to more complex constructions, such as dialog boxes.
Until now we have three different guidelines that collect articles about widgets or patterns: the HIG for desktop applications, the Active HIG, and the UI Design Pattern library. But all three have one problem in common: They are very incomplete and lack on visual examples as well as code snippets.
The quality and acceptance of a guideline depends to a large extent on its set-up. A good structure guarantees quick access to the information the reader looks for. Additional, links to the rationales behind the guideline as well as alternative solutions are helpful. A HIG should not only include widgets and their appearance but also core usability goals, generic design specifications, and user demands. To manage all these aspects we have chosen to adopt the “Universal Model of a User Interface” by Bob Baxley (2003) as basis for the new KDE HIG.
Baxley’s model consists of three tiers, each of which is made up of three layers:
- Structure contains concept, task flow and organization.
This tier is of primary interest for usability specialists. It should answer question like: What constitutes the KDE?, Who is the user of KDE?, and Where do we want to go in future?
- Behavior includes viewing and navigation, editing and manipulation and user assistance.
The part is more like ‘traditional’ guidelines, addressing questions like: How should a button behave in case of…?, or What widget do I have to use for a selection of one out of a few items?
- Presentation deals with layout, style and text.
It’s all about how applications look like including the platform style’s margins and spacings, user’s colours, fonts or icon sizes, grouped layouts, etc. These questions primarily concern designers, translators and the promotion team. But at least alignment and placement is relevant to developers too.
The elements of the presentation layers dominate the user awareness and, as a result, feedback given by the users. But those elements that users are least aware of – the conceptual model, task flow, and organizational model for example -, are also those elements that have the greatest impact on usability. Those core elements are rather hard to fix by hindsight and need to be well-considered in advance.
Each article should at least consist of three sections:
An introduction to the guidelines, serves as basic identification.
- Guidelines with examples:
A collection of best practices in terms of
- Use this widget in case of…,
- Consider to replace it by…,
- Don’t use this widget when..
- Some code snippets:
Help developers to use the correct code.
We will try to add pictures with good and bad examples to each advice that should make the point very clear. For an example have a look on the guidelines about check boxes.
Of course you are more than welcome to contribute. Tell us what you think about the HIG, whether it will help you or not. If you need input on a special topic we haven’t covered yet, let us know. You can follow the discussions on the kde-guidelines mailing list, you can share your knowledge directly in the articles of the HIG on KDE techbase, and you can still ask for assistance at the kde-usability mailing list or at the review board. Or join us at the KDE Akademy 2013 in Bilbao, where we plan to do a BoF on the styleguide.