(bear with me on this one; I'm stuck at home ill, so this may be less coherent than would be ideal)
I can think of a few use-cases where the new implementation may/will cause problems as it's currently laid out: Problems relating to the window being opened for you: 1) If it appears at the bottom of the Z-buffer, it might be behind a long-running application such as Firefox. It may even appear behind a long-running application on a virtual desktop the user doesn't visit often; it's entirely possible that the window won't be noticed for days or weeks. 2) If it appears at the top of the Z-buffer, it will be distracting to the user; it's supposed to appear unfocussed, but what if the user has focus-follows-mouse? Will the window appear under the cursor, steal focus and (if the user happens to be typing at that moment) immediately start updating packages? 3) There's no single place to look to know you're up-to-date. In fact, for the average user, there will be no simple way to know they're up to date at all. It seems to be a "harsher" user interface - and thus it fails to follow the principle of least astonishment. (windows appearing when you don't expect them is astonishing; *notifications* appearing when you don't expect them is... expected!) Some thoughts on mitigation: 1) could be mitigated partially by making the window appear on all workspaces. 2) open at the bottom of the Z-buffer. Any other solution is still going to cause unwelcome astonishment sometime, with some (common) sets of options. Some thoughts that might, possibly, help: The new design specifies two different concepts of notification: "informational" and "demanding": Informational notification is ephemeral and can vanish quickly; it should never need a response. "demanding" notifications must have a response within a short time limit, so they pop up a window grabbing attention. I have to say, I very much like that... but I can see a third class of notifications that are not covered at all. "Patient" ones: something that needs a response but has a very long time limit. It seems that we're trying to force all notifications of this type into one of the other two, and this doesn't work well in all cases - such as this one. Icons in the taskbar *without* a bubble would be perfect for this: They call attention, but they don't demand it *now*. Based on some logic, they can be converted into a "demanding" notification later, if there's a good opportunity or a time limit is approaching. What would be really nice for the specific example of the update notifier is this: 1) When there's any update, assign a "passive" time limit (~30 minutes for security updates, ~2 weeks for upgrades). Pop up an icon in the taskbar that will launch or focus update-manager. Do *NOT* notify in any other way; hover text for the icon should be a nice, frendly explanation of what's up. 2) automatically convert to a demanding notification on login or (if the passive time limit is more than half used) when the system has been idle for some sane pre-determined time - 5 minutes, say. Having the window ready when you come *back* to the computer is much less astonishing than having it suddenly break your workflow. 3) if the passive time limit expires, convert to a demanding notification. (Now I re-read this, I realise this is too long and details for this place; I'm posting it so I don't lose it but I'll copy it elsewhere as soon as I can) -- [Jaunty] Removal of Update Notifier is WRONG https://bugs.launchpad.net/bugs/332945 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
