unity-design team mailing list archive

[Diego Moya <turingt@xxxxxxxxx>]

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.