The New KDE HIG
Improving the User Experience
The KDE Human Interface Guidelines aim to help developers improve the user experience across a variety of aspects, and revisions are underway.
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:
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.
Buy Linux Magazine
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters
Support Our Work
Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.
News
-
Halcyon Creates Anti-Ransomware Protection for Linux
As more Linux systems are targeted by ransomware, Halcyon is stepping up its protection.
-
Valve and Arch Linux Announce Collaboration
Valve and Arch have come together for two projects that will have a serious impact on the Linux distribution.
-
Hacker Successfully Runs Linux on a CPU from the Early ‘70s
From the office of "Look what I can do," Dmitry Grinberg was able to get Linux running on a processor that was created in 1971.
-
OSI and LPI Form Strategic Alliance
With a goal of strengthening Linux and open source communities, this new alliance aims to nurture the growth of more highly skilled professionals.
-
Fedora 41 Beta Available with Some Interesting Additions
If you're a Fedora fan, you'll be excited to hear the beta version of the latest release is now available for testing and includes plenty of updates.
-
AlmaLinux Unveils New Hardware Certification Process
The AlmaLinux Hardware Certification Program run by the Certification Special Interest Group (SIG) aims to ensure seamless compatibility between AlmaLinux and a wide range of hardware configurations.
-
Wind River Introduces eLxr Pro Linux Solution
eLxr Pro offers an end-to-end Linux solution backed by expert commercial support.
-
Juno Tab 3 Launches with Ubuntu 24.04
Anyone looking for a full-blown Linux tablet need look no further. Juno has released the Tab 3.
-
New KDE Slimbook Plasma Available for Preorder
Powered by an AMD Ryzen CPU, the latest KDE Slimbook laptop is powerful enough for local AI tasks.
-
Rhino Linux Announces Latest "Quick Update"
If you prefer your Linux distribution to be of the rolling type, Rhino Linux delivers a beautiful and reliable experience.