KDE HIG rebooted (again)

KDE HIG rebooted (again)

I hope that the majority of KDE contributors have at least heard of them, but they have not received much attention lately: The KDE Human Interface Guidelines (HIG).
Every major operating system and desktop environment has human interface guidelines, because they are an important instrument for

  • ensuring or at least improving consistency in appearance of and interaction with the different parts of an ecosystem and thus
  • facilitating the transfer of knowledge gained in one part to other parts of the ecosystem
  • promoting known best practices
  • freeing developers or user interface (UI) designers from having to reinvent the wheel each time or having to look at several existing UIs to know what the “standard” is
  • saving time which would otherwise spent discussing the same things over and over again

The value of HIGs depends to a large extent on their degree of completeness. However, creating – and maintaining – HIGs which cover most standardize-able aspects of UIs takes quite a lot of time and effort, from people with an interest in and knowledge of interaction design and usability, a rather scarce resource in KDE.
That is why the KDE HIGs are far from complete at the moment, and some of them are rather outdated. To improve this situation, I sent an email out to the KDE usability mailing list about three weeks ago, asking whether some people on that list would help me reboot the HIGs.
Thankfully, I got positive responses from three people so far: Heiko Tietze, Aurélien Gâteau and David Edmundson. The four of us met on the – recently pretty much abandoned – KDE Guidelines mailing list to start working.
First of all, we did what people usually do when they reboot some effort: We changed some fundamentals. Heiko introduced a new structure for the HIGs in general, as well as a new structure for each guideline (he’ll be talking about that soon in a blog post over at user prompt). We’ve already moved the links to existing guidelines into the new structure and are now working on updating existing guidelines and creating new ones.
Of course, help is always appreciated, so if you’re interested, hop unto the KDE Guidelines mailing list and join our cause!

Comments: 34

  1. Markus S. says:

    Declare switches evil and toolbars to be located below toolbars and I’ll be happy. 😉

    • Yes, we should explicitly discourage the use of switches on mouse-/keyboard-driven systems (the standard Plasma Component for switches simply displays a checkbox in a non-touchscreen-environment anyway). We won’t discourage their use in Active applications, though, because here they do make sense for certain uses.
      What do you mean by “toolbars to be located below toolbars”?

    • Markus S. says:

      Slide switches are an outdated form of skeuomorphism that’s so outdated in real life, probably the most common real life hardware people may still have in their homes are 1990s Nintendo consoles (rocker switches, push switches, and recently touch switches are more common).
      I don’t see how they’d make sense in Active. People will recognize them because iOS has them but nice big (ie easy to tap) checkboxes work just as well.
      As soon as someone makes QML apps that work on both Active and Desktop but use switches because Active has them, Desktop will become inconsistent (luckily I don’t print or else I would now see Daniel’s “NIH Switches” that provide a 3rd layer of inconsistency…).
      Toolbars: Typo. I meant Tabs belong below toolbars. Chrome has them the other way around and KDE’s Chrome clone Rekonq has them the other way around (with no option to configure).
      Dolphin and everything else has them in the common order.
      BTW: Kexi is a KDE app with an uncommon UI. I think it makes sense to look into Kexi and see why it chose this UI and possibly adapt aspects of it into the official HIG. Maybe Kexi can more look as other KDE applications again once required aspects have been defined in the HIG

    • Sliding switches do not simply replace checkboxes in Plasma Active. Only iOS does that, and it’s indeed a bad idea.
      They both serve a distinct function: Switches are for turning things on and off immediately, whereas checkboxes are used to tick or untick an option in a list of options.
      Actually, check boxes are a skeumorphism as well. They come from paper forms and were designed to indicate agreement with a statement, not to switch things on or off.
      You can find my detailed discussion of “checkboxes vs. switches” in a mail to the plasma-devel mailing list.
      If someone reuses a QML UI for Plasma Desktop and Active (which nobody should, because UIs have to be specifically optimized for each environment!), we’re safe: The slider component simply renders a checkbox on Plasma Desktop, Marco Martin has taken care of that 😉
      Daniel’s changes to the printer manager were an act of stubbornness which went against the consensus on the plasma-devel mailing list and will hopefully never be part of Plasma. I don’t think he would heed the HIG, but we will add a guideline which specifically says “No sliding switches in desktop applications!” soon, anyway.
      @tabs: Ah okay, now it makes sense 😉 Yes, you do have a point there. In rekonq it’s kind of a “me too!” situation because Chrome and Firefox did it. I can’t blame Andrea for simply imitating the major browsers, but yes, we should discourage others from imitating rekonq via an HIG.
      As always: If you could write such a guideline and send a draft to the mailing list, that would be awesome! If not, we’ll write it ourselves eventually, but it may take longer since we’ve got a ton of work to do right now.
      Kexi is a special case indeed. Yes, it makes sense to look at what they did and see whether some things are good – and generalizeable – enough to be turned into HIGs.

    • Markus S. says:

      I’m aware that checkboxes are based on paper forms but slide switches are nonetheless no longer used on real life devices. You know what are? Buttons.
      In a hypothetical case where a checkbox is not enough a button can work just as well without adding an additional widget.
      I assume the actual use for actually turning something off is rather limited, right? In Active something like airplane mode would be a switch, right?
      Considering that this is an invasive function anyway, the user would would be needed to be warned anyway. I imagine a pref window like this:
      == Connectivity settings ==
      | WiFi >
      | GPS >
      | Airplane mode >
      (Tapping one item scrolls to a new “pref slide”.)
      == Airplane mode ==
      | Airplane mode turns off all connections, including telephony, WiFi, GPS, and Bluetooth.
      | You cannot be phoned and you cannot use Bluetooth headsets.
      | __________________
      | | Turn connections off |
      | —————————–
      After tapping the button, the label is changed to “Turn connections on”.
      Sure, it’s more text but so many people are confused by switches (see the mail you linked), a simple button is so unmistakably clear, everybody will understand it.

    • Heiko Tietze says:

      Just added: “Do not use sliding switches in Desktop applications. They only offer good user interaction on touch screens, so they should only be used in applications for [http://community.kde.org/Plasma| Plasma Active].”

    • I think, Slide Switches do have a use on the desktop, when the action is ‘dangerous’ or would be awkward to or take a long time to recover from accidental pressing. Rather than have a dialogue box saying “do you really want to do that?” and interrupting your mental flow, you make the action harder to accidentally do, such as dragging a slider.
      On my printer, the physical power push-on-push-off button is recessed to avoid accidental operation, the stop and abort this printing requires a 2 second press of the stop button.
      For example, I am forever closing the browser, instead of the tab (when I have two browser windows open). My wife seems to often press icons, while only trying to move the cursor, on her laptop’s touch-pad – the natural arc of a finger dragged across the pad, tends to press harder in the middle and the touch-pad thinks this is a click.
      You appear to have identified two different uses for many of the controls: values for a form with an OK/Cancel button and immediate action. The form controls have a two stage action: click the check-box, then click OK. The immediate object off/on for things that can change state in less than 0.5 seconds without any lasting effects.
      Control: Form example – Immediate example
      Text-box: name – search (as you type)
      Check-box/Toggle-button: member – bass boost
      Radio-buttons: age range – channel
      Action-button: help page – auto-tune
      Select-1: occupation – surround sound effect
      Select-n: skills – favourite tracks
      Tumbler: age – track, copies
      Slider: rating – treble

    • Markus S. says:

      @Robert Forsyth:
      The switches don’t have to be dragged. A click is enough.

  2. Jan says:

    Will you be reconsidering the whole check box text on the left brokenness? The only benefit they give _may_ be neat alignment, but in the expense of broken usability/functionality.
    Here is why it is broken:
    – The label on the left often doesn’t have a buddy relationship with the check box on the right: No automatic mnemonic to toggle by keyboard.
    – Nor is there a clear consensus as to put a colon “:” at the end of the label text. (Which seems to happen with other label+widget pairs too.)
    – Even if the check box and label are buddies, you cannot click on the label to toggle the check box. You reduce the clickable area to the tiny little rectangle of the check box. And believe me, it’s annoyingly hard to hit.
    – Also, on some occasions I come across a settings page where there is only a few check boxes with this stupid label on the left and broken functionality. No other controls or labels to be found on the page (that would need to be aligned with the form layout), and yet the devs did break a very simple qt widget this way for no apparent reason (the “Advanced settings” page in “Power Settings” comes to my mind here. One of the check boxes there even has a label buddy, while the other has not!).
    It certainly is fixable. But then you have to provide a check box buddy label widget that allows the same selection/click mechanics of a regular QCheckBox (allow mouse clicks which toggle the check box, have the visual clue of a mouse hover or keyboard selection (on the buddy label _and_ the check box), etc. etc.).
    The label on the left for form layouts is a good idea in principle to give some nice looking alignment. But it must not break simple usability and functionality. Breaking things just so it looks only slightly more aligned is not a good idea.
    So I would say it either needs to go away or these issues (some of them were even mentioned in the old HIG but ignored) need to be fixed properly before reintroducing/carrying it on into the new HIG. Also worth mentioning is the fact that with this rule one would have to repeatedly switch between 2 different ways of interacting with the same control, which I wouldn’t exactly call usability.

    • David Edmundson says:

      Checkboxes are an active topic right now 🙂

    • Indeed. As David mentioned, we’re already on it.
      Have a look at http://techbase.kde.org/Projects/Usability/HIG/Form_Label_Alignment#Checkboxes
      You may like what we’re suggesting there 🙂

    • Markus S. says:

      Great. Don’t forget to modify the all the plasmoid Preferences windows which from my experience are the worst offenders regarding weird checkbox alignment. 🙂

    • Well, that’s not the job of the HIG team. It’s up to the developers to implement the HIGs and polish their UIs, as Aaron mentioned in his blog post http://aseigo.blogspot.de/2013/06/polish-all-ui.html . Some of us do not even have the programming knowledge to do it, since we’re psychologists, not software developers.
      We can only guide others to make their UIs better.

    • Markus S. says:

      I was on the usability mailing list for a while. I unsubscribed because it lead nowhere. Many great suggestions, nobody to implement them. At least Aurélien and David are programmers.

    • I know that a situation where HIGs don’t get implemented simply because no developer has the time to do it is very frustrating. Still, I do not think that we should go ahead and change all the UIs that are not HIG-compliant. We can point application teams to inconsistencies with the HIG and we may provide a patch here and there if we think the problem is easier solved than described, but that should not be the norm.
      Calling for a KDe-wide “UI polishing sprint” may be a good idea, though.

    • Heiko Tietze says:

      Just added:
      “Do not separate check box and label. Clicking on both the box and the label should toggle the option.”
      “Label every check box or radio button.”
      “Assign a unique access key to each label.”
      “Do not use ending punctuation (neither dot nor colon).”
      >”Also, on some occasions I come across a settings page where there is only a few check boxes with this stupid label on the left and broken functionality.”
      Is it an issue related to HIG? Sounds like bugs.

  3. xpete says:

    Include this in the HIG:
    And check this too:
    There’s lots os things that can be improved on search forms… starting by placing the search field on the top right corner of every app that needs it.

    • The first one is definitely a good point!
      Actually, there was a UI design pattern created for these cases back in 2008: http://techbase.kde.org/Projects/Usability/HIG/SOU_Workspace/Administer_Themes
      It is slightly different from your suggestion, but we might change the split button to separate buttons again.
      The UI pattern library has never really seen the light of day yet, but that’s another goal of our reboot. So yes, this topic is being addressed as well. Of course when the pattern is finished and properly announced to the world, we need to get KCM developers to actually implement it.
      The second one is not really an HIG or pattern issue, since it only affects a single application. This needs to be addressed by the System Settings developers directly.
      Search is indeed a good candidate for an HIG. We can write one for that, but of course it would be wonderful if you could write a draft for it and send it to the mailing list. Ideas are great, concrete HIG drafts are even better 😉

    • xpete says:

      I think the second is a pattern issue in some parts as this issues also exists in Dolphin. As I said i my comment to that post the list should have alternated colors to improve readability an not that lines wasting space. The fonts and wording should be different as well. I thinks this is the main things that makes OS X settings better than KDE Settings on a usability point of view.
      About Search I just did this:
      I hope this can be used as a draft.
      I also did some comments on some HIG pages on the wiki…. I think it’s a better way to keep things on topic and not to loose them.
      Btw, switchs is a very good idea for touch interfaces and should ALWAYS be used as a replacement for check boxes. On a touch screen you can change a check box by mistake but you can’t change a switch by mistake. I guess that’s why Apple used them in 1st place. I already had problems with that. As some desktop are starting to have touch screen maybe it makes sense to use switchs on desktops as well but in a way that’s easy to see if the switch is on or off (checked/unchecked) and can be changed only with a mouse click.

  4. xr09 says:

    Please, take note of my laments on okular. I even made a mockup…
    Also, encourage simpler shortcuts, i.e. “Ctrl+Shift+F” is overkill for fullscreen.

    • Those ideas for Okular are really interesting (which I already stated on the mailing list thread 😉 )!
      However, they are concerning a specific application and as such are not HIG matter. HIGs are not a way to make developers implement a new UI idea, they are meant to ensure consistency with the “state of the art”.
      So even though I like the ideas (and others in the thread did as well), I’m afraid you’ll still have to convince the Okular developers to implement them (or even better: directly submit a patch 😉 ).
      If they get implemented by Okular and other developer teams find them useful for their applications as well, they are likely to turn into an HIG at some point.
      Just remember: HIGs usually reflect existing best practices instead of suggesting new ones.

    • Indeed. This does include Ctrl-Shift-F for fullscreen, though.
      The problem here is: While just pressing F to go fullscreen may work well for an application where users do not type anything, it cannot be used for any application where users can type, and thus can never go into an HIG. Ctrl-F is already set for Find and Alt+Letter is for menu access keys. Finding good shortcuts for everything isn’t exactly an easy task, though I admit that there is still room for improvement in KDE applications.

  5. Rodrigo says:

    Now that the HIG is being rebooted perhaps you could do away with the inane rule that closing the last tab must not close the window, or, at the very allow an option to be presented to the user. This would give it more consistency with all the other browsers in the planet and also tabbed terminal applications. Rel: https://bugs.kde.org/show_bug.cgi?id=57694

    • It makes sense to standardize the behavior here indeed. We’ll have to look at different applications to see what the majority does.

    • xpete says:

      On Opera when you close the last tab it show a empty tab with the speed dial… I think it’s the best think to do. I don’t think it makes sense to close the window when you just want a clean tab… if the user want to close the windows he should… close the window.

  6. […] finds a flaw in one or more of the KDE Human Interface Guidelines and points it out in a comment on my post about them, that’s totally fine with me and I’m ready to discuss that flaw with that person (and […]

  7. The HIG is also part of the branding (for many desktops) although it should not interfere with easy of use.
    They are also guidelines, not hard rules, so each have to argue its existence.

    • I agree with you on both points. The HIGs can be overruled whenever it makes sense, but it would be helpful if developers talked to us when they think that an HIG should be overruled in their case, so that we can keep a certain consistency even among the exceptions

  8. TheBlackCat says:

    A few comments on what I have seen:
    1. A lot of what I see with the widgets is “use this widget under this circumstance, use this other widget under this other circumstance”. This might lend itself to a tree, where the user selects from a list of progressively more specific options until they get to a single widget.
    2. In the “two lists” page, it is unclear grammatically whether allowing supporting drag-and-drop is mandatory or optional. It also might be good to have separate “sortable single list” entry, and refer people to the HIG on that for the right-hand list. There is also nothing about the placement of the arrows, especially the up-down arrows which are often placed inconsistently (i have seen right, top, and bottom for sortable single lists).
    3. I think combining the spin box and slider pages might be good, especially with the combined spinner/slider case mentioned at the end of the slider page. Also, should there be any rules about prefixes and suffices in spinners? What about float vs integer guidelines?
    4. Should the “wording” page mention something about warning dialogs for “delete”?
    5. In the ellipses section, in the third entry you say not to use ellipses with “Print”, but everywhere else on the page you say to use ellipses with “Print”
    6. In “wording”, “Use Options for a configuration dialog which provide.” is not a complete sentence.
    7. I think the “don’t make the menu bar hideable” should be amended to include something like “unless it is automatically replaced with a toolbar button”.
    8. I think the KNS entry should mention that there should always be a button to install an item without using KNS (since KNS only works with files hosted on the KNS page, which many files are not).
    9. In the “Date Time” page it is not clear what is wrong with the “bad” example”

    • Thank you for all the suggestions! It seems like we need to put all the suggestions given in comments to this post (and the ones over at user prompt) somewhere so we won’t forget any when we revise the affected guidelines…
      Since it seems like you care about the HIGs and you have good ideas: We’d be happy to welcome you on our mailing list (if you’re not on there already) 🙂

  9. […] BoF I’ll definitely join but haven’t initiated is the one on the KDE Human Interface Guidelines (on Tuesday as well). Here the HIG team will go over the HIGs we’ve (re)written so far to […]

  10. […] Tietze is putting great effort into the HIG (without him, not much would have happened since I rebooted them) and Björn Balazs helps where he can as well, but there is only so much they can squeeze in […]

Add your comment