Several months ago, Visual Basic Q&A looked at how to add an icon to the Status Notification Area (SNA), also known as the System Tray, Taskbar Notification Area, and Notification Area. One Builder.com member subsequently took me to task for not explaining appropriate use of the SNA. To make amends for that oversight, I’m going to diverge from our usual Q&A format here and examine the dichotomy between what Microsoft says and what Microsoft does regarding the use of the SNA. I’ll also provide some guidelines to help you locate that happy middle ground that lies somewhere between the official party line and abuse of the SNA.

Gratuitous use of tray icons
Member Dave Taylor wrote in to say that I should have pointed out that SNA icons tie up system resources that might be needed by other applications, resulting in poor system performance. He added that since many of the applications that use SNA icons are set to automatically start when the system starts, they add to boot time. Besides, he said, it’s simply against the rules.

“Actually putting an icon [that stays] in the system tray is an abuse of the system tray, which was designed for status notification only. According to Microsoft documentation, its proper use is illustrated by the printer icon that appears and goes away after the print job finishes.”

That can’t be right, can it?
Although his system performance concerns are valid, I was initially skeptical of Dave’s interpretation of Microsoft’s documentation. After all, of the nine icons that are currently permanent residents of my SNA, five of them were placed there by Microsoft apps. That would seem to indicate to me a change in Microsoft’s attitude concerning the use of the SNA. I figured Dave’s documentation must be dated.

Imagine my surprise when, after looking high and low on the hopelessly disorganized MSDN Web site, I found the following paragraph early in Chapter 1 of an electronic edition of Microsoft’s Official Guidelines for User Interface Developers and Designers:

“Another common mistake is using the taskbar status notification area inappropriately, as shown in Figure 1.4. The Windows taskbar notification area is intended only for quick, short-term notification (for example, a document is printing) or status information for some ongoing process or event (for example, a low battery warning). A taskbar icon should persist only if it is important for a user to have it available, such as for a dial-up connection. This helps ensure that the user will notice changes in the notification area.”

Figure 1.4 is reproduced here as Figure A.

Figure A
Inappropriate use of the Status Notification Area (Source: Microsoft)

Interestingly enough, many of the icons that don’t represent the “quick, short-term notification” or “important to have available” uses sanctioned by the guidelines in this bad example are for Microsoft products. That’s not surprising, really. In fact, parts of the Official Guidelines are a hoot to read when you compare the proposed best practices with Microsoft’s common practices.

There are advantages
I believe there is utility in using the SNA for purposes other than for transient notification icons. For one thing, placing an icon in the tray when starting an application that doesn’t otherwise have any UI elements lets the user confirm at a glance that, yes, it is indeed running. SQL Server is a good example of this use. Users also benefit from having access to frequently used configuration options via an SNA icon, such as the volume control icon that is loaded by default into the SNA.

At the same time, there is an obvious potential for abuse. Take RealPlayer, for instance. RealPlayer sticks its icon in the SNA uninvited and even discourages you from removing it with a cryptic warning that doing so may adversely affect the performance of the application.

Proper SNA etiquette
Since the official guidelines are rather vague on when it’s acceptable to persist an SNA icon, I think we need to define some more concrete guidelines for proper use of an SNA icon. So may I present to you my suggestions for proper SNA etiquette:

  • Add an icon for an application that does not otherwise have a UI only if knowledge that the application is running is important to the user.
  • When considering an icon for the purposes of providing access to configuration, ask yourself these questions: Is this something the user will likely want to adjust frequently? Can the user perform that operation conveniently without using the icon? You should use an SNA icon only if the answer to the first question is “Yes” and the answer to the second question is “No.”
  • When providing an SNA icon for purposes of configuration access, provide an easy way for the user to enable and disable the icon. The best practice is to not add the icon by default.
  • If your application is a service, consider building a Control Panel snap-in to provide configuration options rather than using an SNA icon for that purpose.
  • If possible, put your application to sleep while waiting for a Shell_Notify callback; otherwise, you are consuming system resources that could be needed for the application that the user is actively using.
  • Do use different icons to represent the different states of your application.
  • Follow normal guidelines with respect to mouse button functionality: Right-clicking should result in a context menu; double-clicking should activate any user interface elements you want to display. For an example of the misuse of this standard, see the Windows 2000 Local Area Connection icon.

Many of these suggestions are simply common sense, but I’ve seen every one of them abused at one time or another. Try to bear these guidelines in mind so that you don’t fall into the trap of using an SNA icon for no other reason than its coolness factor. And please, keep your elbows off of the table when you eat, people.

Do you have a VB question?

Send us your Visual Basic or VB.NET questions and see them answered right here in Builder.com’s Visual Basic Q&A.