[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Ayatana] unity and notifications





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.