I support the NotifyOSD goal to create not intrusive messages, but I think the current design falls short of that goal. Now that it has been in the wild and used in real contexts, some of the initial controversial decisions that were boldly supported should now be reconsidered, in particular the zero-configuration and no-dismissable bubbles.
In my opinion some kind of lightweigh configurability would help tailoring the tool and making it useful for frindge cases, avoiding the one-size-fits-all problems. For example, allowing dragging the bubble to persistently change the placement of notifications would put users back in control to fine-tune their experience.
Said that, I like the mockup that places notifications at the indicator menus area. At least in that case the only information obscured is system state, never user content.
On 20 September 2010 13:30, Matthew Paul Thomas
wrote:
> 2) Yes - the current implementation of the bubble is functional. It
> notifies the user, it does fade when the mouse cursor is over it and
> you can work below it. Many people feel though that it hangs around
> too long
Often it does hang around too long, because length-based duration has
not been implemented yet. <
https://wiki.ubuntu.com/NotifyOSD#duration>
Length-based duration wouldn't help in cases were the user didn't want to see the notification but the content below it. In those cases only closing or moving the bubble would relieve the feeling that the notification is being obstructive.
Diego Moya wrote on 17/09/10 13:59:
> Yes, those bubbles are actually quite similar to what NotifyOSD tries
> to do. But look how Jef required a way for the user to take control of
> how bubbles are presented.
Which was unrealistic. By the time you had remembered, and then typed,
the command to reduce the opacity, the error would have faded away by
itself anyway.
I think it was meant to configure the default opacity to a level at which the user feels comfortable. The Ayatana design dismissed the idea to let users configure notifications to their needs, and I never got the reason for that.
> The Ayatana notification design took the
> original idea and then changed it to its opposite by removing every
> safeguard feature to put user in control and keep it humane.
That is not true. I had read the book years ago, and seen that idea, and
thought it was crack (mainly because the mockup was obviously rigged to
ensure the error text didn't overlap the background text). But by 2008
I'd forgotten about it.
And then you went designing a notification system based on translucent, non-dismissible bubbles? I didn't mean using a similar design was a deliberate decision, but surely it had some influence?
> The current design for OSD notifications is heavily modal - it blocks
> access to the visible area until the bubble disappears, and it doesn't
> give the user a way to claim that blocked area. The provided workaround
> to reach the blocked screen area requires a complex interaction (the
> repeated fading out and in as the mouse moves away) that can be quite
> distracting and doesn't work if the user needs the cursor elsewhere.
>...
We could do better with the fading, but I find myself unable to imagine
a situation where someone simultaneously (a) needs to see what's under a
notification bubble and (b) "needs the cursor elsewhere". Can you give
an example?
I think Michael Jonker already provided one at this very thread; that's why I elaborated on it. When working with the Gimp, he needed to see the layers panel while working on the scene, and it was obscured by the bubble.
This will happen in general whenever the top-right corner of the application contains an information panel, which is intended to contain readable data that can be read with a glance while working on the main interface. This is quite usual in IDEs and design tools.
>When we designed Notify OSD, we did not have touch screens in mind.
Does that mean they will not be supported, ever? Or are suggestions welcome to also support touch screens, even if it implies changing the original design?
>> The starting point i feel is: You touch it and it goes away.
>>...
>
>So, how would you avoid touching it by accident just after it appears?
Several viable options to avoid the problem:
- Touching it don't dismiss it for the first 0.5 second, enough for the user to notice it.
- Don't show notifications if there has been user interaction in the previous 5 seconds.
- Even if the bubble is closed, allow the user to reopen it from the Me menu.