unity-design team mailing list archive

[Diego Moya <turingt@xxxxxxxxx>]

On 21 September 2010 15:57, Matthew Paul Thomas wrote:

> Diego Moya wrote on 20/09/10 15:59:
> > 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.
>
> For the same reason operating systems don't have visible controls for
> configuring the appearance of tooltips. If they're designed right, they
> should be below the threshold of triviality. If a substantial proportion
> of users want to configure them, there's something wrong that we need to
> fix.
>

Both situations are not really comparable. Notifications have proven to be a
more difficult problem than tooltips, which are basically local to a single
widget each time (and notifications are unrelated to the content below
them). Notifications are global to the system, so you should ultimately take
the whole system into account to get it right. The smallest misappreciation
could produce a less-than-optimal solution. You should be omniscient to
create your "right design"!

That scorched earth approach of zero-configuration ("if it ain't perfect,
disable it!") means that until you get it right some people will suffer in
the meantime without a way to fix it, even assuming that the perfect design
exists.

Also think that "configuration" doesn't need to be "panel with check boxes".
Allowing direct manipulation of bubbles (for example to reposition them)
would potentially fix with a one-time drag-and-drop any problem of obscured
content, without being a burden to the user.




> > 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.
>
> As Mark Curtis said, that's a potential problem no matter where the
> bubble appears. And any interaction to move or dismiss the bubble would
> be just as much of an interruption as moving to fade it.
>

But less severe than having to wait 5 seconds. Also it usually should be
done just once, while obscured content can be annoying every time.



> >>> 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.
>
> That's a possibility, but we would need to define more carefully what
> "don't dismiss it" means. If I clicked on the part of a bubble above a
> window's close button, 0.45 seconds after the bubble appeared, would it
> close the window, or do nothing at all?
>

It should do nothing, because the meaning of the click would be ambiguous.
This counts as a mode error, but it's less severe than the alternative which
is a misplaced command.

This is a personal preference, but I really don't like the idea that
clicking on a widget hidden below the notification should have some effect.
The whole "click-transparent notification" idea in the current design is
disturbing to me, it always felt weird and uncertain on what would be the
result.



>
> > - Don't show notifications if there has been user interaction in the
> > previous 5 seconds.
>
> Interesting idea, though it might result in a long queue.
>

Only in cases of really heavy user interaction, in which notifications
wouldn't be noticed anyway. Most user flow (except for typing long
paragraphs) is made in small bursts of short interaction, wait, evaluate UI
feedback, more interaction.

The 5 seconds could be fine-tuned through some user testing, maybe 2 or 3
seconds would be enough. Also, notifications queued for more than one minute
could be safely discarded as irrelevant, just as if the user was away.

In my suggestions I'm relying heavily on the notion that missing a
notification is not a big deal - I think that was one of the design
guidelines. I'm just pushing it to the extreme in order to reduce
interruptions to the user flow while working with application content.



>
> > - Even if the bubble is closed, allow the user to reopen it from the Me
> > menu.
>
> Many if not most notification bubbles have nothing to do with social
> networks or instant messaging, so that would be a poor fit.
>

... or somewhere else, where logging that class of notifications was
appropriate. If there isn't a sensible place where to log the message in a
particular bubble, it wasn't that important to begin with.