Designing Tip Windows
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.
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
|Non-Linux FOSS: Seashore||May 10, 2013|
|Trying to Tame the Tablet||May 08, 2013|
- RSS Feeds
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- New Products
- Validate an E-Mail Address with PHP, the Right Way
- Drupal Is a Framework: Why Everyone Needs to Understand This
- A Topic for Discussion - Open Source Feature-Richness?
- Download the Free Red Hat White Paper "Using an Open Source Framework to Catch the Bad Guy"
- Home, My Backup Data Center
- Tech Tip: Really Simple HTTP Server with Python
- Please correct the URL for Salt Stack's web site
42 min 17 sec ago
- Android is Linux -- why no better inter-operation
2 hours 57 min ago
- Connecting Android device to desktop Linux via USB
3 hours 26 min ago
- Find new cell phone and tablet pc
4 hours 24 min ago
5 hours 53 min ago
- Automatically updating Guest Additions
7 hours 1 min ago
- I like your topic on android
7 hours 48 min ago
- Reply to comment | Linux Journal
8 hours 9 min ago
- This is the easiest tutorial
14 hours 23 min ago
- Ahh, the Koolaid.
20 hours 2 min ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?