Balloon Timeout and Notification Duration

Today I was reading a new post on one of my favorite blogs, The Old New Thing by longtime Microsoft developer Raymond Chen. I got to know Raymond in the waning days of 1994 when we were working on "Chicago", the codename for what would become Windows 95. I was a rookie Program Manager for this new thing called "accessibility" and he was the go-to developer for just about anything in the guts of Windows.

In his blog post today, Raymond discusses balloon notifications in Windows, specifically why applications no longer have control over how long a notification may appear visible. In Windows 2000, an application could call the Shell_NotifyIcon function to display a popup balloon near the taskbar notification area. If you specified a timeout value via the NOTIFYICONDATA.uTimeout member, the value would be used to determine how long to display the notification.

However, starting with Windows Vista, the shell ignores the uTimeout member and instead uses the global message duration value that is set and retrieved using the SystemParametersInfo function, specifically the SPI_GET/SETMESSAGEDURATION value.

The reason for ignoring the application-supplied timeout is so that users can gain more control over their working environment. People with various sensory, cognitive and mobility disorders often request more global configuration settings to help them deal with the tremendous amount of information presented in a graphical user interface. Some examples:

  • A person with low vision needs more time to read something. Having the message fade out after a few seconds is frustrating. This is true of people with certain reading disorders.
  • Some cognitive disabilities affect the way people react to information display peripherally. It might take longer for some people who are focused on one area of the screen to react to something displayed in the bottom right corner.
  • A person using a mouth-stick or other external aid to move the mouse pointer may need more time to move the pointer to the message so that it can be clicked and acted on.

FYI – you don't have to be disabled to have need for these options. There are many situations where otherwise so-called able-bodied people have their vision, perception and mobility affected. I have good vision, but with multiple monitors, I've missed notifications appearing on one display while my attention was focused on another display.

A "timeout" setting was something the accessibility team was pushing for in Windows 95 to give the OS and applications an indication that the user required more time to process things that would otherwise time out. There weren't balloon notifications back then, so it wasn't as urgent. With Windows XP and the explosion of non-modal timed notifications, it became imperative and thus the SPI_SETMESSAGEDURATION setting was incorporated into Windows Vista and exposed in the Ease of Access Center.

The user interface to control the message duration value is contained within a section of the Ease of Access Center:

  1. Click the Start button or press CTRL+ESC
  2. Type "ease" and choose the Ease of Access Center
  3. Choose "Make it easier to focus on tasks"
  4. The option "How long should Windows notification dialog boxes stay open" is towards the bottom of the list

The default value is 5 seconds, and can be set to 7, 15, 30, 60, and 300 seconds (5 minutes).

Some of the commenters on Raymond's posting were concerned that ignorant and/or poorly behaved applications that wish to have their notifications displayed for as long possible would abuse the SPI_SETMESSAGEDURATION value and thus adversely affect all applications.

The reason there is a public API is simply that the Ease of Access Center needs to do it. In addition, Microsoft wishes to enable other accessibility aid vendors the ability to create their own tools to meet the unique needs of their customers. Windows cannot currently segregate vendors and say, "only accessibility aids may touch this setting." If the API is public, then it can be used – and abused – by any application running with the user's permissions.

If a specific application wishes to have a message display for customizable period, then that's up to the application to handle the message display. I hope that this application would query SPI_GETMESSAGEDURATION, become informed of the user's request, and act appropriately.

5 Comments

  • > The reason for ignoring the application-supplied timeout is so that users can gain more control over their working environment.

    So, what about users who want to give the control to the application they run? (Which are the tools actually powering the user).

    I mean, what stopped Vista guys having a checkbox that said 'Let the applications decide for each message' (even if they would choose not having it checked by default - which would be the right thing to do IMO).

    > The default value is 5 seconds, and can be set to 7, 15, 30, 60, and 300 seconds

    More power to the user, especially those who want to set it to 8 seconds, or 20, or 45...

    You may defend the Vista way, but not having an XP compatible option, IMO, is not defensible...

  • @Burak: The reason Windows doesn't support per-application settings for message duration is simple; it's too complex and has dubious benefit.

    After all, most users don't have a need to customize the notification duration per application.

    But if there was such a feature, there would have to be end-user UI to manage it. Just look as the existing "Notification Area Icons" control panel, which lists all the recent icons. In my list, there are icons for applications that I haven't used in quite awhile. Now imagine there was a similar list for all the different notifications - it could be hundreds of entries. I know of one security product that has dozens of different notifications.

    The UI support to make each notification message customizable just isn't worth it to support the small set of users who'd want it. In my opinion.

    Regarding allowing finer grain control. The API that sets the time out accepts milliseconds, so feel free to write an utility that gives the resolution you desire.

    The designers of the Ease of Access control panel decided that it better to offer a smaller set of values that cover the majority of values.

  • > most users don't have a need to customize the notification duration per application.

    There are users, clueless, exposed to hostile Internet environment. There are users in a controlled environment, who run only a few custom applications. And the applications are run by users, as an extension of themselves where the application is the user.

    I wouldn't consider an application assigning different timeout values to each of its messages too complex.

    XP powered the user, Vista took it away, with no good reason. (I would say the reason could be trying to be a 'nanny OS' if this was done deliberately..)

    Vista could have switched to this new behavior, but left the option to go back to the powerful XP state via a single checkbox. But Vista being Vista, this didn't happen :(

    > The UI support to make each notification message customizable

    A single checkbox too much? How many people are not calling Vista bloated right now because of this missing checkbox, I wonder...

    If Vista did everything correctly, why did it fail? And remember even pirates complained that they made a loss with their Vista sales...

    Sorry if my tone is a bit harsh, I've invested too much into Windows and I hate it when Windows fails and my customers ask for Mac versions of our products which we don't have...

  • >>XP powered the user, Vista took it away, with no good reason

    Let's make sure we're talking about the same things here. For balloon notifications, XP allowed applications to specify a timeout. XP imposed a minimum of 10 seconds and a maximum of 30 seconds. I believe the default if not specified is 10 seconds.

    As for the reason why Windows Vista "took it away", I gave you a good reason - to help users who needed ALL notifications to last longer. That's a very good reason.

    > A single checkbox too much?

    You advocated allowing each notification to be customizable with regard to duration. That customization has to live somewhere either in the application or the operating system

    > If Vista did everything correctly, why did it fail?

    I never implied that Vista did everything correctly. However, it was a big step forward for accessibility for people with disabilities due to the growing recogition of the need for system-wide constructs that allow users the ability to inform the OS and appilcations of their desires.

    > I hate it when Windows fails and my customers ask for Mac versions of our products

    That sounds like a larger issue than just balloon notifications - which by the way Mac OS X has no concept of. Each application has to code their own status messages and there is no way for a user to inform Mac OS X that they need things to not timeout quickly

  • FYI, after doing some additional reading on Mac OS X, they used to have balloon help, but took it out. It's simply not available anymore.

    Contrast that with Microsoft's approach, which often keeps outdated technologies around for legacy purposes. The Briefcase and QuickView technologies come to mind.

Comments have been disabled for this content.