Success Stories ‘08: Guidelines and Design Patterns for KDE4Published on October 4th, 2008 by Ellen Reitmayr
This project focused on finalising the Human Interface Guidelines for the K Desktop Environment.
Mentored by Celeste Lyn Paul and Ellen Reitmayr, Becca Scollan, a student of Science and Information at the University of Baltimore (USA), and Thomas Pfeiffer, studying Psychology at the Technical University of Darmstadt (Germany) identified common interaction problems in KDE4 and created generic design solutions. Additionally, they complemented the KDE4 HIG by several guidelines.
Read on for Becca’s and Thomas’ project report:
Human Interface Guidelines (later referred to as Guidelines) are documented guidelines based on usability standards for people developing or designing user interfaces for applications within a certain environment. The guideline goals are to enhance consistency among applications and to make knowledge from the user experience field easily accessible to developers. Half of our project involved picking up from where the KDE4 community left off on a collection of Human Interface Guidelines by adding to them and revising what existed.
For the other half of the project, we collaborated on several Interaction Design Patterns (later referred to as Patterns) for KDE4. Patterns offer solutions to recurring design problems by examining both successful and problematic examples in various applications.
In creating guidelines, the current Human Interface Guidelines from several desktop environments (primarily GNOME and Vista) were examined, as well as existing KDE4 applications as a resource. Descriptions of successful elements of current KDE4 applications were noted in the Guidelines. When elements within KDE4 were found to be either non-existent or not working according to usability standards, a new solution was discussed and added once agreed upon. All of these new guidelines were discussed and finalized at the end of the summer and await further discussion from the KDE4 community.
Process: Design Patterns
For Patterns, the process began by defining a problem. These were either pulled from questions asked by developers in the KDE-Techbase or usability problems found when analyzing current KDE4 applications. Many potential patterns were researched as the result of broad inconsistencies among current KDE applications, or owing to design problems that had been solved in a suboptimal way. Once a problem was defined, we examined applications from different desktop environments and operating systems to find extant solutions.
For some of the pattern work, an appropriate solution wasn’t available, most often because it was specific to KDE4 and not well-solved in current KDE4 applications. In such cases, we sketched and debated an original solution based on their knowledge and experience. Our next step was to integrate findings into a comprehensive yet compact solution to the problem. A brief summary, bulleted guidelines and wireframes were included in each solution. Once drafted, an iterative process of discussing and refining each pattern took place until we were satisfied with the results. Three detailed patterns were completed:
Creating guidelines and writing patterns turned out to be far more complicated than one might think. The greatest challenges for both activities were various exceptions and edge cases. Typical solutions for a guideline or pattern may be relatively easy to find, but beyond each case a variety of rare yet significant examples can emerge. An exception or two can complicate the guidelines for a pattern. With each case having its very distinct peculiarities, it can be difficult to find a single solution that works well for all of them.In the end it came down to choosing how many variants of a pattern to create. Too few variants leave too many cases unsolved or poorly solved. Too many variants make the whole system confusing for developers and designers. Finding the right balance between breadth and specificity became key. Such decisions often required multiple discussions in order to avoid missing any important aspects. Emphasis was also placed on describing a pattern or guideline in a concise and comprehensive way to assure consistent implementation. Misinterpreted guidelines are no help to the overall KDE4 experience.
The following images depict two solutions to the problem of selecting from a pool of items. Each version depends on how often the user will select from the pool. The left solution, called the “Picker,” is for cases in which the user often needs to know which items are selected without wanting to change the selection. It saves screen space as the whole pool of available items is only displayed on demand. To the right is “Two Lists with Arrow Buttons,” in which the list is more comfortable to edit. This pattern is for cases when it is more typical to edit the list rather than simply display the current selections.
All in all, the project was an excellent learning experience that helped to solve some pressing design problems for KDE developers. There is still much to be done for voluntary work outside the Season of Usability or for more projects in future Seasons.
This project was mentored by: