The KDE Visual Design Group (VDG) is barely seven months old. However, with the recent release of the Plasma 5 interface, its influence is already visible in the new default theme with its geometric wallpaper, icons, and fonts. The VDG’s next challenges are to integrate itself into the workflow of developers with a long history of working without designers, while avoiding the reactions that have plagued new design teams in Gnome and Ubuntu.

The KDE VDG started when illustrator and designer Jens Reuterberg attend a Plasma Sprint in Barcelona in January 2014. Although pleased by the friendly reception he received, Reuterberg could not help noticing the historical lack of designers in KDE: “I thought that was weird, considering how well we handled dev-work in general,” he says. Reuterberg decided to change that with “a group where inclusiveness, humility and acceptance were the guiding ideals and where anyone could be a part.” The result was the VDG, which now includes 11 regular contributors, whose expertise ranges from design to usability.

Andrew Lake, who oversees the development of the VDG’s new Breeze default theme, likens the situation in design to that of code: “Design has labored under the myth of the one genius or the ivory tower from which good design is handed down – the cathedral of Raymond’s legendary essay [The Cathedral and the Bazaar]. I saw in Jen’s posts and interviews the same seed that launched the free software movement, but for visual design – a democratization of design. It’s an opportunity for anyone, regardless of skill, to learn and contribute in a meaningful, sustainable way to KDE.”

Similarly, asked why the VDG is needed, Reuterberg’s first response is, “because it’s more than just a paint job. We needed to talk about this, to make KDE as a whole talk about it and feel that it was an issue that belonged to all of us as a community.”

After the often-chilly reception that Gnome and Ubuntu designers received in the last few years, Reuterberg worried that the KDE community “will hate me in a few months,” but he now says that “I’ve been proven wrong. Sure, there are some who may not like some of the changes, but everyone has been respectful and cool about things. I hope that’s because they feel like they are included in the process.”

Building Relationships and Interfaces

The VDG’s challenge is not just to improve the aesthetics and usability of Plasma. Another central part of its work is to convince developers to adopt its concepts.

To this end, Reuterberg would prefer that the interaction with developers be “as direct as possible. The issue is often that design and development work in different ways. There are different methods of work and communication used, making it a bit tricky to get one group to actively interact with the other.”

More specifically, Heiko Tietze, a partner at the usability company User Prompt, notes that the relationship between design and development has three main components:

• The first component is Structure. It contains the concept, vision, and principles, task flow and organization, and should answer questions like: What constitutes KDE software? Who is the user? Which use case has to be supported by the application?
• The second tier comprises traditional Guidelines, addressing questions like: How should a button behave? What widget do I have to use for a selection of one out of a few items?
• Last but not least is the Presentation tier, which primarily concerns designers, developers, translators, and the promotion team.

Tietze notes that, of these components, Presentation is the most noticeable to users but has the least effect on usability, as well as the least room for technical improvements. Instead, the starting point for design is usability. “This means to define the workflow, create mockups, and run user surveys,” he says. “After implementation, the application needs beautification by designers to fit into the common layout and to attract people.”

In Tietze’s view, the main challenge of designing for Plasma is its high configurability. “Our target user is not tech-savvy, and we have to find ways to balance her needs with the diversity of features for experts. For instance, we work on a simpler system configuration with basic settings for normal users, supplemented by the full spectrum of options if you switch to the design mode.”

To help with these challenges, the VDG is slowly evolving Human Interface Guidelines, as Gnome did several years ago. The guideline begins with basic principles:

• Identify and make very clear to the user what need is addressed and how.
• Give the user the final say. It should always be clear what can be done, what is happening, and what happened. The user should never feel at the mercy of the tool.
• Provide sensible defaults but consider optional functionality or customizations that do not interfere with the primary task.
• Make it easy to focus on what matters: Remove or minimize elements not crucial to the primary task; use spacing to keep things uncluttered; use color to draw attention; reveal additional information or optional functions when needed, not before.
• Make things easier to learn by reusing design patterns from other applications.
• Make complex tasks simple. Make novices feel like experts.

From these general principles, the guidelines are slowly evolving detailed advice on the presentation level. For example, the guidelines suggest when to use a context menu or a tree view or when to use radio buttons instead of comboboxes. Other suggestions are to use preexisting building blocks whenever possible and to know when to use notifications.

The VDG tries to show how to use these principles and guidelines in its blog. However, its efforts are complicated by the fact that, unlike the Gnome and Ubuntu design teams, the VDG only has the power to suggest, not to enforce. “I’d call it ‘herding cats’ if the cats being herded were skilled, dedicated, and intelligent, and knew what they were doing,” says Reuterberg. “It’s more like ‘keeping up with greyhounds on space scooters.’ ”

Avoiding Conflict

Given recent histories, the emergence of the VDG naturally invites comparisons with Gnome’s and Ubuntu’s design teams. In particular, can the VDG avoid the conflicts that these two predecessors faced?

Reuterberg emphasizes that he has nothing but respect for the Gnome and Ubuntu teams, both for the risks they took and for the interfaces they have produced. However, although he suggests that the mere fact of change is enough to produce resistance, he also thinks that the VDG is likely to be better received – and not just because it is revising an interface that people have had five years to become used to rather than introducing an entirely new environment.

“Both Gnome and Unity had something we don’t have in KDE,” Reuterberg says. “They were given given license to enforce the design changes. [By contrast,] we can’t. KDE is all about ‘anything can be changed,’ and that makes the changes we do a lot trickier. You can’t easily ensure a unified feel and workflow when everything is easily changed. So the conflict is never really that big. ‘I don’t like it so I changed back to this thing instead’ is about the size of it.”

Or, as Lake put it, the most that the VDG can do is “produce a credible default experience.”

Just as importantly, the KDE Visual Design Group is not designing an entirely new interface. It can enhance and refine, but only rarely invent from scratch. Just as its lack of authority grounds it in consultation, so its limited scope tends to grind it in the practical. Perhaps in the future the VDG will drift away from the pragmatic, but its first results suggest that, despite its relatively late start, it just might become one of the most successful design teams to emerge from free software.