Designing Tip Windows

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.

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.