If you're itching to teach users how to use your application, make a tip window they won't want to turn off.
The first thing you see in many desktop applications is the “Tip of the Day” or “Did You Know?” window. I've seen an increasing number of tip windows on recent Linux systems, so here is a discussion of the most effective way to implement them. A tip window is not the same as a splash screen, which is the window that is briefly displayed while a program loads, links, configures and generally gets itself ready. The program closes the splash screen itself without any user action.
Even splash screens have variations. Usually they are created by desktop applications, but bootloaders and graphic drivers, such as NVIDIA, also can have them. Microsoft Office products typically have splash screens full of intimidating legal warnings. Adobe does nice splash screens: the legalese is low-key, there's a nice piece of artwork and a small text field shows the names of extensions and plugins as they are loaded. If you have an attractive splash screen for your application, document somewhere the location of the PNG logo it displays. You may be lucky and the user will put it on a Web page.
Why have splash screens? In an ideal world, we wouldn't. You can go a long way as a user interface designer by remembering only a few rules, among them the magic numbers 100ms and two seconds.
For most purposes, anything the computer can do in 100ms or less is perceived as instantaneous. If you are writing the pilot training simulator for a jet fighter, you have to be more precise, so if you can get your application to launch in 100ms, you've done a fabulous job, users will love your product, and a splash screen would be superfluous or might even be considered an illegal subliminal image.
The two-second limit is, on average, how long the computer can keep users waiting before breaking their concentration and making them aware that their time is being wasted by a machine. A launch time under two seconds ought to be possible for most desktop applications, but sometimes it is out of the author's control. The splash screen is meant to hide the delay.
A tip window is different. It tries to be useful rather than merely decorative, and it has to be dismissed by the user. It doesn't vanish of its own accord. The introductory sequences in many games are tip windows. Visually, they look quite different, but the function is exactly the same. You watch the briefing or backstory or whatever until you've learned what you need and click to continue.
Tip windows have become common in recent Linux distributions, matching Macintosh and Windows environments. And, as in the Mac and Windows worlds, 99 out of 100 users click the Don't Show Again button within a few days and never look at the tips again. This is a shame, because tip windows really are a good idea. We all know nobody reads manuals. A tip window gives you, the application developer a chance to walk the user gently through the capabilities of the application, presenting information in small convenient chunks. It doesn't even cost users any time; they have to sit through the launch delay anyway.
How can we encourage users not to turn off the tip window? Well first, why do they? Here it's useful to discover what is going on with a GOMS keystroke model. (GOMS—goals, objects, methods, selection—is a way of analyzing user interfaces and interaction.) Applied to tip windows, the GOMS keystroke model shows that the tip window has introduced a second unnecessary action to the launch process.
Taking a word processor or text editor as our example, the user's goal is to write something. The action is to click or double-click the appropriate icon. With no tip window, only a splash screen, no further action is required and users can start typing as soon as the application launches. The tip window, though, forces users to carry out a second action to dismiss it. The annoyance of this extra action is why tip windows are turned off; it has nothing to do with the helpfulness of the content.
If you're not convinced that merely one extra click can make such a difference, consider that “nagware” in the Mac/Windows environments relies exactly on this behavior. These applications are shareware and require a license fee but are free to download. Every time the application launches it shows a window reminding that you haven't paid yet. You have to dismiss this window every time. Only after you pay will the author send you a code that disables the nag window. It works because it is annoying.
Turning the tip window back into a splash screen and closing it as soon as the application has launched would remove the annoyance. However, only speed readers would be able to absorb the tips, which rather defeats the purpose. A fixed delay of a few seconds would annoy people in a hurry. The right thing to do is to close the tip window as a side effect of the user's first action. More technically, the first mouse entry, motion, button event or key event, closes the tip window and is then processed as normal by the application. Now the user can pause to read the tip window if it looks interesting or simply start working if not.
This isn't an original idea, by the way. Start a copy of Emacs or xemacs with no filename given. You get a blurb about Emacs, the Free Software Foundation and how to get more information, but the first key you press clears it all and is inserted into a new document. Perfect.
There is one small new problem: if the tip of the day is particularly fascinating, how can the user save it? They can't copy the text, because whatever they try will close the tip window. So, the application should remember which tip was displayed at launch and set the on-line help system to always open with that same text as the initial contents.