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.