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!

Chances are that you’ve experienced this (probably quite a few times): You’re currently concentrating on what happens in the center of your screen, focusing your eyes on it, when suddenly something blinks, moves, appears or disappears in a corner or at an edge of the screen. Whether you would have known what it was without looking at it or not, your attention is immediately drawn to it. If this happens more than once, it becomes an annoying distraction which may be hard to ignore.

There is a simple reason for that: As you might remember from Biology class, there are two kinds photoreceptor cells in the human eye: Cones and rods. Cones are used for high-resolution color vision and are concentrated in the fovea centralis, which catches light from the object you’re focusing on. Rods, which are more common in the periphery of the retina (in fact they’re almost completely absent in the fovea centralis), are used for low-light vision and are especially good at detecting motion.This is useful to spot and quickly react to e.g. an attack coming from the side in the periphery of our field of vision.

Even though attacks are fortunately not that all that common for most of us nowadays, we are still biologically designed to focus our attention on anything that’s moving in the periphery. In the context of a computer screen, a sudden change of color or shape, something quickly appearing or disappearing can also be interpreted as movement. This is great if the movement signals something which actually deserves our immediate attention, but if it’s something that we don’t actually need to pay attention to at the moment but which grabs our attention anyway, it quickly becomes annoying. And if you finally manage to ignore the constant annoyance, you may miss if information which actually is important to you comes up in the periphery.

Accordingly, peripheral displays with moving information were found to decrease performance in information browsing [1] and text editing [2] tasks (though another study [3] did not find significant performance decrease in a browsing task).

So, bottom line / takeaway / tl;dr: If you need to grab your users’ attention, just animate/change something in the periphery and it’s pretty sure to work. But resist the urge to put something constantly moving like a scrolling ticker on the edge of the screen, it’s scientifically proven to distract users from their main task.

I bet there is hardly a person who has never experienced this situation: You want to do something in an application, but the control (UI widget) which does it is greyed out – and you have no fracking idea why!

This is a frustrating situation, and that is why it’s common sense among UX professionals that you should never disable a control without telling users why it is disabled. However, even though this immediately made sense to any developer I told about it as well, I find it implemented in practice very rarely.

Now the question is: How and when do you tell users why something is disabled? Following the same principle as in my last post, that information should be given to users exactly when and where they need it: At the moment they want to use the control which is disabled. The easiest way to do this is to simply add a tooltip to disabled controls with a short explanation of the reason why, and ideally what the user needs to do to get it enabled (again). Even if a control is disabled, users tend to move the mouse to it anyways, which is when they get the information they need. On touch devices you cannot display a tooltip on hover, so you should display it when the disabled control is touched.

Not all users might hover or touch disabled controls intuitively, but if this gets widely implemented in an ecosystem such as KDE, users will learn to expect that information once they’ve found it in some applications.

Now I encourage all developers and interaction designers: Whenever you implement or design a disabled control, put a tooltip on it, you will spare your users a lot of frustration!

Update, thanks to Kevin’s comment:

If a control already has a tooltip when it’s enabled, write the reason in brackets behind the usual tooltip when it’s disabled.

Example:

• Tooltip while enabled: Go to the next unread message
• Tooltip when disabled: Go to the next unread message (No unread messages left)

Offering help and support in user interfaces is not an easy task: You have to offer the right amount at the right moment. If you offer too little support, users are frustrated and feel stupid because they don’t know how to use your product. If you offer too much support or you offer it in the wrong situation, users are annoyed and feel treated like n00bs.

One such situation came up in a discussion on Google+ last December. In this discussion, Thomas Weissel brought up an example he often encounters with new KDE users: They accidentally remove the taskbar from their panel and have no idea how to get it back. To prevent this from happening, he suggested popping up a warning when users remove a widget from the panel, with the option not to show the warning again.

Using warnings usually comes to mind immediately for these situations. However, warnings are rather “negative”. They convey an atmosphere of danger which needs to be prevented. They are basically meant to scare readers in order to make them think twice before doing something they might regret later. That’s why warnings should only be the last resort for error prevention. They should only be used if two other methods are not feasible: Preventing the error in the first place or making recovery from it easy.

Preventing erroneous behavior in the first place would is generally a preferred solution, but it often has some negative side effects. In the case of the accidentally removed taskbar, one way to prevent the error would be to lock the panel completely by default. This would indeed prevent the accidental removal, but make the configuration of panels less straightforward. This is not desired, because the ability to be adapted to personal preferences is one of Plasma’s biggest strengths.

That’s where easy error recovery comes into play. Actually it is possible to re-add a widget to the panel in a few steps. The problem, though, is discoverability. Users who are new to Plasma may not know that they have to click the panel’s configuration icon and then “Add Widgets” to get their taskbar back.

Of course we could offer users a “Quick start tour” explaining all the basics when they first use their system, like a certain company from Redmond used to do, but seriously: Have you ever taken that tour? I haven’t. Why? Because when you use a system the first time, you don’t want to sit back and be told about things you might only use months later, if at all. No, you want to explore the system and see what it can do for yourself. At your own pace.

That’s why the aforementioned discussion gave me an idea: Instead of trying to keep users from accidentally removing their taskbar, why don’t we use the mistake as a learning opportunity and take that moment to show them how to add widgets to the panel? If they really removed it by accident, they damn sure want to know how to get it back and will welcome your advice with open arms. If they removed it on purpose, they probably know what they’re doing and just dismiss the offer to be shown how to get it back. This idea got quite positive feedback on Google+ back then.

To generalize the idea: Short tutorials should be offered to users at the moment they are most likely to actually need and want them: When they first need to use a certain feature which may not be easily discoverable, not the first time they use a product. Aaron Seigo coined the term “in-app tutorials” for tutorials which are presented in the context of a specific application. I would introduce the term “ad hoc tutorials” for those which are offered not only inside the application, but in the exact moment they are needed. They are something we want to use rather extensively in Plasma Active, but there are many places in Plasma Desktop or actually in any application where they may be helpful.