KDE Human Interface Guidelines update

Presentations & Interviews, User Interface Design 2 Minutes

It’s been about a month and a half since I wrote about KDE’s new Human Interface Guidelines (HIG). It turns out there’s a surprising amount to report since then!

First of all, the news got picked up by Linux Magazine which did a story about it, including an interview with me! That felt nice.

Next, there have been a number of contributions and enhancements:

Joshua Goins

  • Fixed a lot of typos, awkward wordings, and small errors.
  • Added information about using Qt to set Task Manager badges directly.
  • Expanded the instructions on contributing to the HIG.

Thiago Sueto

  • Corrected several typos and spelling errors.

Christoph Wolk

  • Improved the grammatical correctness of one of the text recommendations.

Nate Graham (me)

  • Polished up the text some more.
  • Added additional suggested inclusiveness-related text replacements.
  • Clarified when a hamburger menu is and isn’t appropriate.
  • Updated the icon size recommendations.
  • Added examples and suggested replacements for common acronyms.
  • Wrote a recommendation for how to implement “go home” navigation.
  • Mentioned when first-run wizards are and aren’t appropriate, migrating some content from our old “Frequently discussed topics” wiki page.
  • Refined the recommendation for button length and combox text capitalization.
  • Described when it’s appropriate to shorten button labels because nearby context indicates what they affect.
  • Expanded the Icons page to offer more concrete guidelines about how to choose an icon and what style to use, and also added more pictures.

Overall I think it’s looking pretty good now, especially the Icons page which received a lot of attention recently.

In addition, there are more pending merge requests by Christoph Wolk, Emir Sari, and me. So it feels like an actual team project now! I think the goal of encouraging more contribution can be called a success.

Finally, Christoph Wolk and I have been going through System Settings pages and tweaking them to comply with the HIG. System Settings is good low-hanging fruit since it’s almost all QML at this point, so changes are easy. And there are a lot of pages, so it’s not hard to find small inconsistencies.

But were not finished yet! More eyeballs are needed. A few TODOs need resolving. More images could be helpful. So check out these two links to learn how to contribute changes:

Even a beginner developer can help out by tweaking the user interface to conform to the HIG. And if you’re a hardcore developer, we still need some more components for writing powerful QML apps.

Still too scary? Then donate to KDE. Our budget is tiny, so your money genuinely does have an impact!

Unknown's avatar

Published by Nate

Published

5 thoughts on “KDE Human Interface Guidelines update”

  1. “Added additional suggested inclusiveness-related text replacements.”

    Please expand on this. I sincerely hope wokeness is not creeping into KDE/Plasma… Thanks.

    Like

    Reply

  2. I don’t know if my Firefox settings are making the page render in a slightly wonky way, but there are some weird visual misalignments on the HIG.

    For one, the options at the bottom of the main page have more whitespace padding on the bottom than they do the top, which makes them feel unbalanced. That, and the “icons” button on the left menu is slightly indented – I’m thinking it’s meant to imply that it’s a subsection of “Text and Labels,” but considering it’s the only option styled in this way, it’s pretty unclear and seems more like a visual glitch.

    Finally, in the “accessible language” portion you linked to in another comment reply, the arrow characters used aren’t vertically centered, and instead sit at the bottom of the text field.

    Like

    Reply

    1. Renaming git branches isn’t a HIG topic because regular users don’t have contact with git branch names.

      But even if it was, we already recommend not using the word “slave”, but IMO there’s nothing wrong with “master” in a clearly technical context. It’s also a word that has many normal and positive meanings (“I need to master this language”, “She’s a master at Battleship”, etc) and throwing those out doesn’t make sense to me.

      I don’t think I’ve ever seen anything called a “master window” or a “master tab”, but I have seen things called “master plan” and “master slide”, and those seem fine.

      Like

Leave a reply to Lilo538 Cancel reply