The KDE Human Interface Guidelines (HIG) first appeared near the end of the first decade of the millennium. It was a time when the Linux desktops had caught up with their proprietary counterparts but had paid little attention to the user experience. In 2008, at the O’Reilly Open Source Convention, Mark Shuttleworth challenged developers to “shoot beyond the Mac,” and “to figure out how to deliver something which is crisp and clean.” In response, over the next few years, Ubuntu, Gnome, and KDE experimented with rethinking the desktop, with varying degrees of success and mixed user response. Since then, distributions such as elementary OS, Deepin, Zorin, and Pop!_OS have conducted their own experiments, but KDE’s HIG have been little changed. However, in 2024, KDE developer Nate Graham has started a much-needed update.

The revised KDE HIG are still a work in progress, but the draft is a glimpse into an aspect of software development that users rarely consider (Figure 1). Many of the HIG are practical, such as suggestions about where and how to use icons, how to space navigation aids, and when to use different input tools such as sliders and text fields. More generally, under “What Makes a KDE App a KDE App?,” the revised HIG highlight the characteristics of guidance for novices, customizability for a variety of uses and needs, and constant evolution – a description that seems a good answer to the question of why users might want to try KDE.

Recently, Graham talked to Linux Magazine about some of the larger issues surrounding the KDE HIG:

Figure 1: The revised KDE Human Interface Guidelines give developers user guidelines, and others an insight into the user experience.

Linux Magazine (LM): Why was it time to update the KDE Human Interface Guidelines? How did the KDE HIG begin, and how have they developed?

Nate Graham (NG): The original KDE human interface guidelines were over 10 years old, predating my involvement in KDE. They had drifted out of date and a lot of the content was inapplicable to today’s world, or not expressed in a way that was very easy to understand. As a result, they weren’t a useful resource for most KDE developers, who quite justifiably ignored them. Equally problematically, they were so inapplicable that contributions were being suppressed, because any small change you might want to make would pale in comparison to the magnitude of the whole problem and you’d get depressed and abandon your change proposal.

The HIG needed a rewrite. For some time I’d wanted to rewrite the document to reflect what would actually be useful for KDE’s developers, so when I was offered the chance to use work time for this project, I leapt at the chance!

Though I’m not formally a designer or a usability expert by training, I’ve had a long-standing interest in these topics and have worked on them in KDE on a volunteer basis for years. My goal here was not to produce the best HIG ever on the first try, but rather to build a strong foundation that would be useful to today’s KDE developers and could be updated over time by those more knowledgeable than myself to remain relevant. Though I'm the de facto maintainer of the new HIG today, I see myself more as a custodian of the overall project than a guardian of its current text. That text will change over time; it has to.

So far the rewritten KDE HIG are very new — under one month old. So the feedback received thus far has been limited — but mostly positive. My biggest goals for the new HIG are to remain relevant and encourage further contribution, so openness to feedback is high.

Future projects on my roadmap include adding more images, overhauling the icon design section to reflect the in-progress new icon theme, and building more re-usable components that we can encourage the use of in the HIG, so developers won’t have to re-invent the wheel and consult the HIG so much in the first place.

LM: How have data-visualization experts such as Edward Tufte influenced the HIG?

NG: The text of the new HIG is informed by a variety of sources including Tufte, the Nielsen Norman Group, other guidelines by peer organizations, and our own hard-won experience over the years. Something to keep in mind about Tufte is that while the field of data visualization is related to user interface design, they aren’t the same thing. The principle of maximizing information density doesn't always apply to interactive tools, especially those whose users aren’t experts.

LM: Can you summarize the latest version and how the philosophy mentioned under “What Makes a KDE App a KDE App?” shows up on the desktop?

NG: Years ago, Plasma adopted the motto “Simple by default, powerful when needed.” Over time, this has become the motto for KDE software in general, and encouraging adherence to this principle animated a lot of decisions for the new HIG text. In essence, we want our software to be usable by people with basic to moderate tech skills, but grow with them over time and facilitate usage by experts as well.

Scaling all the way from beginners to experts is no mean feat! It means offering guidance that fades away as you gain proficiency; being customizable but not shoving it in your face, because the default settings are well chosen; and being extensible with the basics being already there. That sort of thing. Not easy, but doable.

LM: How do KDE’s HIG compare with those of other desktops/software compilations?

NG: At this point, some companies and communities have larger and more detailed guidelines, while others are smaller or non-existent. During the rewrite project, I sought inspiration on the topic of content structure from the Apple, Gnome, Google, and elementary OS HIGs. I really respect the elementary OS folks and I found their HIG to punch above its weight, offering lots of useful information in a compact form, and I endeavored to meet this standard in KDE, too.

LM: Are the HIG simply guidelines for individual developers, or are they enforced in some way?

NG: KDE is a large and anarchic community made up primarily of volunteers, so almost everything we do revolves around convincing rather than compelling. As such, there is no formal enforcement mechanism. The hope is that the document’s guidelines are self-evidently correct and applicable, and people will start to adopt them organically over time. Since its deployment last month, we’ve seen modest attention and adoption from design-curious developers around the areas of button labeling, capitalization and punctuation, error messaging, and tab bars.

The more people apply one element of the HIG to their app and find that the results work well, the more likely I think it is that they’ll consult the document in the future and trust that its recommendations make sense.

LM: Does the HIG document include any ergonomic or accessibility guidelines?

NG: In our industry, sometimes topics like accessibility, ergonomics, right-to-left languages, and translations are treated like afterthoughts. I wanted to avoid that in the new HIG by weaving information about these topics throughout the text to make it clear that they’re important considerations from the get-go. So the accessibility page at the end mostly talks about how to test your app for accessibility, on the assumption that you've followed the other guidelines and already done a good first pass at it.

LM: Do the HIG include any guidelines for use of newer technologies, such as containers or AI?

NG: In general, the HIG are focused on people and design, not technology and features. The idea isn’t to dictate to developers what’s in their app, but to help them present whatever is in a more effective way.

In Closing

Graham is currently continuing his revision. He plans to add more illustrations to help developers understand the advantages of following the guidelines. In the end, the user experience will be stronger for such efforts.