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.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Doing for User Space What We Did for Kernel Space
- Tech Tip: Really Simple HTTP Server with Python
- Parsing an RSS News Feed with a Bash Script
- SuperTuxKart 0.9.2 Released
- Rogue Wave Software's Zend Server
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide