| Date: | April 26, 2011 / year-entry #102 |
| Tags: | code |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20110426-00/?p=10833 |
| Comments: | 43 |
| Summary: | A customer asked what started out as a simple question, but by now you know that this sort of simple question only raises new questions: Is there a way that we can detect that the user has hidden our notification icon? No, there is no way to ask whether your notification icon is hidden or... |
A customer asked what started out as a simple question, but by now you know that this sort of simple question only raises new questions:
No, there is no way to ask whether your notification icon is hidden or visible. Users decide which icons they want to see, and you don't get to snoop in on the users' decisions. Questions like this scare me, because it sounds like this customer's program is going to respond to the user's choice to hide their icon by doing something even more annoying. This is another demonstration of Le Chatelier's Principle as interpreted by John Gall: Every system resists its proper functioning. In this case, a design to make programs less annoying and intrusive merely drives those programs to even more annoying and intrusive behavior. The customer's response confirmed this suspicion.
If you use a notification icon, then you have to accept that the user can hide notification icons. If you still want a notification icon, you can start by displaying a dialog box with a progress bar, and give it a button that says "Hide this dialog and display a notification when attention is required." With this design, converting the dialog box to a notification icon is an active step the user must take, and if the user hides the notification icon, it's their own fault. Or abandon the notification icon entirely. According to the notification area design guidance, you shouldn't use notification icons if immediate action is required.
Windows 7 lets you communicate the progress of the background operation unobtrusively by displaying the progress bar as part of the taskbar icon. |
Comments (43)
Comments are closed. |
But only if you enable Aero.
Not to mention you can hide notification balloons entirely, even if the icon itself is shown.
@Robert: Are you sure? I've disabled Aero and the progress bar functionality in the taskbar button is still there…
@Nick: It's disabled if you choose a classic theme which may be what Robert was thinking of.
Why is it so many developers have the extremely poor taste to think that they should override user-preferences and force their decisions upon their users? It pisses me off whenever an application I install tries to override good etiquette in ways such as this – or the damnable "me on top" – or even overriding what I'm typing to reformat it to what it thinks I should have been typing (or even just grabbing focus away, or injecting a notification dialog to interrupt whatever else I was doing).
Some developers have the most amazing myopic belief in their own perfect ability to predict all possible futures to know that their static choices in year X will be "smarter" than anything I, as a user, will think or want into the infinite future. Must be amazing to be that sure of yourself. :(
Sure you can! Take a screen snapshot, locate the tray, and see if your icon is there.
What you should do is force your dialog to the foreground. That way, when I'm doing something else entirely, the dialog box will pop up and I'll accept or dismiss it by change of what key I happen to be pressing. This makes the entire thing an adventure! Did I accept something I shouldn't have? Did I just cancel a mutli-hour operation?
(Sarcasm off.)
The tray icons auto-hider in windows 7 is a god sent feature. Any developer which tries to go around it should be beaten until he learns to respect users settings.
It's hard to take the notification area guidance seriously when the OS itself ships with Action Center which displays a notification icon 24/7, usually just to inform you there are "No current issues detected."
AC also shows the same plain white flag icon when there are non-serious messages waiting as when there are no messages at all. So you either ignore it all the time and miss those messages or you click it every so often to see if has any. Not great.
It does show a different icon when there are alerts about serious errors, but that is arguably breaking the rule about showing critical status via notification icons.
Action Center notifications are a good idea — those types of things were too hidden in Control Panel or Event Viewer in the past, and many still are today — but something went wrong in the design or the implementation, and it's undermining the advice given to third parties. This isn't some add-on by another team like Messenger or whatever; it's part of the OS.
Actually, what Joe said blogs.msdn.com/…/10157902.aspx regarding when the dialog is forced to the foreground and whatever I was typing becomes the de facto choice for the process. That is probably the <strong>worst-case scenario</strong> from a usability point of view.
I understand the developer's rationale, that by allowing the user to over-ride a decision point or delay it, it is the user who suffers ultimately (and then blames the developer for not designing a sensible interface- ugh…)
You can't assume rational behavior by users (just like Keynesian economists can't assume rational behavior by consumers). Don't design the interface such that the <strong>worst-case</strong> can occur. Otherwise, design according to best-practices as mentioned in the post above, "notification area design guidance".
And take comfort in the fact that Windows 7 themes are so delightful and varied that few will choose the "Classic theme", even though some may choose to disable Aero for the sake of performance (although I love Aero). And thus the wonderful functionality of displaying a progress bar in the task bar icon will subtly and unobtrusively be available to more and more users in the future as they transition to Windows 7.
@Leo – The Action Center is part of the "System Icons" grouping. Your comments regarding non-serious messages waiting can apply to any of the other system icons – volume, network, power status, etc. They too can be turned off by the user.
The abuse of the taskbar notification area by applications was widespread and laughable. Windows had to control the number of icons being shown and hiding non-system icons by default is a reasonable – if imperfect – solution.
Many things in Windows and other Microsoft products violate the guidelines – Microsoft developers can be as stubborn and ignorant of good practice as any other company. That's a lousy reason to discard good advice.
"There are Windows teams which fail to follow the guidance from the UI design team, either intentionally or out of ignorance."
"Many things in Windows and other Microsoft products violate the guidelines – Microsoft developers can be as stubborn and ignorant of good practice as any other company"
So there is no senior lead with a lead-weighed cluestick to beat the guidelines into the devs? That's what I always suspected.
It's a cultural issue, IMO. Some people are always going to think that they know best, and their end users are all too stupid to be trusted in any way shape or form.
It's this basic attitude: I must beat my users over the head and force them to make all the right decisions (and of course implied is "I know what the right decision is in the first place"). This culture should be expunged, especially from the up & coming ranks of new programmers in colleges and universities.
Just because there are some users who will do stupid things no matter how elegant and helpful your interface is, does not justify treating all end users as complete block heads, or deviating one inch in your interface for such fools. Let them complain. So long as they're not a significant portion of your actual user base, they can safely be told that this is their problem and they need to use the software as intended, instead of in whatever cockamamie way that they're doing.
Programming to the stupidest possible users is going to create the stupidest possible user interface.
If Microsoft can't be bothered to follow its own guidelines (especially for in-box components), why would you expect 3rd party developers to follow them?
It doesn't even matter at this point. This particular battle over the tray notification area is over; you have lost. Convincingly. The tray notification area now serves as a place where long-running applications are minimized to without taking up space on the taskbar.
As a developer I'm becoming less ambivalent about the feature as time goes on. When Win7 first came out, the default-hide policy caused some small amount of grief, but users seem to be getting the hang of it now. As a user, I now love the feature, and I have a serious case of rage whenever a program violates the new policy. Sadly, more and more programs are starting to do so, with DropBox being a prominent example. I understand that MS is a huge company with many teams, but when the AC violates the UI guidelines from the get-go, it kind of gives carte blanche to others to follow suit. Still, the notification/tray area is a far better place than it once was.
But when the stupidest possible users are your target demographic, sometimes you have to make concessions.
One of my least-favorite bugs involved leaving a prompt unanswered for about 3 days. By the time the user deigned to do something about the situation, things were in such a bad state that the machine had to be rebooted to get back to working again. It's generally unwise to ignore the screeching fire alarm for a couple of hours, or half a day. Unfortunately, with every program out there believing that "the soda machine is empty" requires the same level of user attention as "the coolant pumps have failed", the user has a high likelyhood of ignoring the really important stuff.
"One of my least-favorite bugs involved leaving a prompt unanswered for about 3 days. By the time the user deigned to do something about the situation, things were in such a bad state that the machine had to be rebooted to get back to working again."
The hard part is to make sure the error prompt does make things worse. That you don't shoot dialogs out of WM_TIMER or WM_PAINT handler. Or your low disk space handler doesn't log this event further to the disk. This is what design and code reviews are for.
I agree, but I don't see why this should scare you, Raymond. If I'm writing an app against an API that allows you to simulate user actions and upload anything on your system to anywhere, it's no more unreasonable to ask this question than asking how one can, say, enumerate HKCUSoftware registry keys.
Alex, the problem is that the UI design team is not the only one with a voice; when they say "our UI design says that system icon should …", the team responsible for that icon can just retort "ah, but OUR design says it shouldn't" – why do you assume someone senior enough to have authority over both teams will always side with the UI team, or indeed have time to mediate every inter-team disagreement? It's not like Legal saying "whoah, we can't use that icon, it infringes SomeCompany's trademark" – if software didn't ship until every team was happy with every detail including every other team's work, nothing would ever ship!
@Alex, Re Clippy et. al.: Removing them takes resources and testing, not to mention documentation update time. As adding them starts at -100 points, so does removing them.
@John:
> If Microsoft can't be bothered to follow its own guidelines (especially for in-box components), why would you expect 3rd party developers to follow them?
If you say "you're not allowed to try to educate third parties until you have the entirety of Microsoft marching in lock-step to the guidelines" then the rest of the world misses out on the advice he's trying to give us to help make our programs better.
So the gist of this conversation, from the Microsofties, appears to be that the guidelines are there for a reason and you should follow them. Unless you're Microsoft.
@No One:
Removing Clippy – change the installer default to "Don't install", which was actually ultimately done in MS Office.
Removing Search Puppy: Set the default to "Don't show".
Removing desktop cleanup: Set next invocation to 0x7FFFFFFFFFFFFFFF in the registry.
These are less expensive than many other fixes.
Yes, we're getting off-topic. But when I work on other peoples' computers, especially for less-savvy users who don't realize how many hidden notification area icons they have, I sometimes make all of them visible. Then I will discuss all of the background junk that is running. Usually I can uninstall 4 or 5 programs that way, which the user didn't realize were there. The computer may be slightly faster, and the user is happier.
On my own computers, I rarely hide any of them. If a program doesn't allow me to turn off its notification area icon as a preference, I generally look for another program to do the same job.
I think all of the commenters here agree with Raymond's point.
I'm not saying that Microsoft needs to be perfect or guidelines aren't useful. All I'm saying is that "do as I say, not as I do" usually falls on deaf ears; it's better to lead by example. I know Microsoft is a big company and Windows is a big product, but this is the out-of-the-box experience we are talking about.
The program designers might not realize that, even though they want the user to "take an action or make a decision", the user might be busy doing something else for a couple of hours, or half a day, or whatever. The user may have hidden the program's icon because the task is not urgent for that user *at the moment*.
The program can just wait until the user is ready to answer it. Otherwise, the program has lost its "less annoying" status.
@Alex Grigoriev:
No need to poke the registry for the last one: support.microsoft.com/…/320154
@Joshua: But you can leave icons visible and turn off notifications! Clearly the solution is to push a notification and *then* take a screenshot to detect if it showed up or not!
I wish developers would take the time to read the windows ui design guidelines. They aren't crazy long…
>No, there is no *supported* way to ask whether your notification icon is hidden or visible.
I'm sure it's possible to blit the notification area, and detect whether subtle changes in a pixel of your icon are visible or not. It will kill performance and break in the next version of Windows of course. But I bet some blockhead's doing it.
Even so, I think the principle is sound. Once you make it easy for notification icons to know that they're hidden, they'll immediately start to spam you with pop ups and sound effects, in order to pummel the user into making the icon visible again.
If it's a long-running process, leave it in a non-modal window so it shows up in my taskbar. Otherwise if it turns into a notification, I'll probably forget about it and it'll be stuck for weeks.
My personal "top four" remaining OS annoyances:
(1) Programs stealing focus when I'm typing something
(2) Win7 force-updating itself on (laptop) shutdown and/or startup
(3) No "update service" API, so every program installs a permanently running background task to check for its own updates
(4) Win7/Vista not using its "low battery" system sounds ("by design")
The Win7 notification area is actually quite usable. Thanks!
Microsoft has a history of shoving features down users throats no matter how much they complain. People loathed Clippy, so what did Microsoft do? They added an animated dog to Windows XP.
A valid use case for wanting to know whether a notification icon is visible is when changing it requires a potentially expensive operation, like polling a remote server for its status.
@hagenp:
(1) thankfully newer IE is not popping up anymore. Looks like some senior guy applied a cluestick, finally.
(2) Not necessarily. You can choose not to do that.
Also, Win7, unlike Vista, doesn't wake your computer (which can be in your living room) in the middle of the night to check for updates, thankfully.
(3) Lazy or ignorant programmers don't use task scheduler API (available since Windows 2000 or so) to check for updates. This doesn't surprise me.
Gabe: "A valid use case for wanting to know whether a notification icon is visible is when changing it requires a potentially expensive operation, like polling a remote server for its status."
Maybe, it would be better not do do any sort of expensive operation even when it's visible (expensive operations are not very scalable).
Whatever the excuse for the application to ask if its icon or baloon or other notification is visible, this may be useless infofmation. For example, I use a projector as secondary monitor. Nobody will look at the primary LCD untjl fhd movie is over.
Hence, the application should be prepared to react autonomously if for whatever reason the user decision is not available in time.
"You expect that there's somebody whose job it is to personally track every single line of code in Windows and beat up people who mess up? (And what if the people he goes after have their own lead-shielded armor?)-Raymond"
Raymond, no one is expecting a person to sift through lines of code. But surely there's a team of UI quality control folk that look at what UIs are being produced by various teams and tell them to fix it based on a set of guidelines. If there's not, then something is broken at MS.
davep: "Expensive" is relative. I'm not talking about "factoring 400-bit numbers" expensive, but something less trivial than showing a clock or battery level indicator.
If you're polling a server, you're keeping your own working set in memory, adding to the server's working set, and keeping a network connection up. If the server would otherwise be idle if not for your polling, why force it to be paged in if you're not even looking at the status indicator?
@Raymond: "There's not much difference betwen sifting through every line of code and sifting through every piece of UI. There are approximately twenty-five kajillion different pieces of UI in Windows"
Of course is there a very big difference between "sifting through every line of code" and testing the UI of Windows itself for consistency, to some completeness.
On the other hind, do you really think that the customer / end user should be the first one who should experience (and then live for many years) all the fails and glitches in the UI design of all the various development groups within Microsoft?
All the "grouping" of developers is completely internal to MS. It should NOT affect the consistency of the Windows UI.
Raymond, in all fairness, the posts that Angry about MS commented on do say what would be better, you just disagree with it. (As do I, but that doesn't change the fact that your riposte-link doesn't apply and only serves as a kind of thought-killer-cliché.)
@Raymond: "The post's recommendation was that there be a UI review team. I pointed out that centralized UI review does not scale. Reviewing every last piece of UI for what seems like a simple feature can take a whole day because of all the variations."
– It does not need to "scale", because its (a) an imperative requirement (no excuses accepted, sorry) and (b) it would be better to change fewer (not more) things in the Windows *UI* but with the goal of a very consistent UI and (c) Microsoft has so much software engineers that I just can't take that excuse seriously.
– Many if not most organizational problems can't be solved exactly but this does not stop people from seeking approximated solutions. You do not need to approve any last detail (especially in error-handling situations) but you should at least try to look for the standard use-cases, such as displaying icons and balloon-messages in the notification area by various windows applets (and also parts of other MS products, sorry).
In the end, you did not answer my question "do you really think that the customer / end user should be the first one who should experience (and then live for many years) all the fails and glitches in the UI design of all the various development groups within Microsoft?" But from your statement, it seems that you don't care about that. So, we just disagree.
@Raymond:
Your argument seems to be: "it does not scale" and "it's too huge to reach completeness". By that argumentation, one could also say "we don't test software" because "software testing don't scale well" and "it's not possible to cover everything by testing". Lets just declare this "a team effort" and hope that every programmer will do the right thing.
Software testing is imperative. So the "it does not scale" argument does not fit: You must only program that many software as you can test). I see it in the very same way in regards with the UI consistency thing we are discussing here.
I also work in a company with a few 10 000 employees, so I know for sure that guidelines without effective checks are not going to work. If you really care about consistency in the fullfilling of such guidlines, you need to install administrative checks.
I'm sorry, but I still don't understand why – in order to prevent someone SETTING a variable, they are barred from QUERYING that variable. That's just bad policy.