support X and Y hints for notifications

[Dylan McCall]

Many applications use the X and Y hints to explicitly place their notifications. This is typically accessed in libnotify via notify_notification_attach_to_widget. Very popular to link a notification to a status bar applet. In fact, this functionality is even showcased in the concept video! <http://www.markshuttleworth.com/archives/253>

It would be sensible to support this hint in notify-osd. To go with the "relaxed" design philosophy, the notification itself should not be placed according to the hint, but when it fades out (and perhaps when it fades in) it should indicate the widget it is attached to. This way the user will know, if he wishes to act on the notification, exactly which button to press.
I suspect that this would work better than the existing "place the notification at the hinted location no matter what" behaviour of the original notification-daemon, since here developers can set location hints knowing that they aren't being obtrusive. Thus, no need for more buttons; just point the user to where they already exist.

So, err, please support this hint!

[Mark Shuttleworth (sabdfl)]

Dylan, this was a subject of intense discussion. In the original
concepts, we did use the fade behaviour to indicate the relationship
between the bubble and a point on the screen. But in reviewing it with
users, this was considered "weak", because you had a fade, shrink and
move all happening quickly (250ms). So, we had to decide between this
weak option, and the overly strong option of the "arrow on the bubble".
In the end we decided to keep the notifications minimalist.

In my mind at least, this is an open item, we haven't yet proven the
case one way or the other. I don't know how best to reflect that in the
bugtracker - if we get a LOT of feedback on this, or find use cases
where it's really the only solution, we would raise the priority of the
problem and see if we have creative solutions. For the moment, neither
the "arrow" nor the "fade destination" are going to get implemented.

Do you have other suggestions we could mockup?

[Dylan McCall (dylanmccall)]

Hi Mark! Thanks for response and the information.

One thing I think is that the actual presentation part should avoid looking too sure of itself. With the classic notification-daemon, there were often notifications pointing at the wrong places on screen because their related applets had moved. Not great for usability, as a user would expect that indication to be correct. I think it could be a bit smoother to have this feel more like a gentle nudge in the right direction; it directs the user's eyes towards where the attached coordinate is If he is reading the notification.

Think of how people indicate things in the real world. One can either point, which is what the old system did, or he can quietly indicate with a nod of the head, for example. Either way, it often feels way easier for everyone to do it with physical movements than with words (or at least a mixture of the two). Especially so when it's up in the air whether someone will read those words in time ;)

Tomorrow I'll hopefully have some time to try different kinds of visual information, and I'll post screencasts probably on a forum thread and ubuntu-devel-discuss.

Two things spring to mind right now:

* Scaling is bad. It's visually quite distracting, and suggests that pointiness thing I want to avoid. Just glide + the existing fade effect could be applied. I was thinking there could be a sort of radial gradient as the notification fades out, so one end (the pointing end) would appear more prominent, giving us the same pointiness as the scale effect without really adding more movement. It could help so the gliding makes a bit more sense without adding more distraction (except for a strong desire to gaze at the awesome effect).
A possibly big issue then is that in some cases the notification bubble ends up racing really quickly across the entire desktop, which could be /slightly/ helped by a parabolic curve for movement speed, but only slightly.

* Just an arrow. Not sure if this is what you're describing, but perhaps no extra animation needs to be done; there could just be a little black arrow pointing out from the notification towards the attached coordinates, varying in style baed on the distance that area is from the bubble. The notification itself would not move.
Seems like that would be an okay last resort, if not the optimal solution. In that case I don't think the loss of roundness would be too bad, and the effect would be super subtle.

[Mark Shuttleworth (sabdfl)]

OK. Go ahead and mock some things up, let's see how it works.

Mark

[Matthew Paul Thomas (mpt)]

I think it would be valuable to have a help bubble mechanism that can point at or highlight particular interface elements (useful for guided tours, tutorials etc), but I don't think notification bubbles can be that mechanism. Queueing notification bubbles means that the relevant interface element is even more likely to have moved by the time the bubble appears. And when a confirmation bubble (volume, brightness, etc) is already on the screen, it's quite likely to be placed between any newer notification bubble and the thing it wants to point to. (notification-daemon blithely ignored this problem, which resulted in bubbles covering each other as they fought to point at different elements on the panel.)

[David Barth (dbarth)]

Setting to 'Wishlist' while it's back on the drawing board.

[James Schriver (dashua)]

Dylan,

This animation really does add a nice effect, especially when used with compiz. Nice work. I'm testing your branch now. The animations are obviously must smoother than the in the screencast, but not bad for a reference.

[James Schriver (dashua)]

I would like to add these animations are also very effective on darker themes. Example, I was focused in the left side of the screen searching for an application in the menu and I did not observe the notification appear, but it caught my peripheral vision as the closing animation faded off the screen. Possibly enabling an opening animation or at least making that customizable would also have a great usabilty factor.

I am using Dylan's version from bzr trunk.

[Michaël Vanderheeren (michael-vanderheeren)]

This should be a blueprint...

[Noel J. Bergman (noeljb)]

Would this "defect" also address the absolutely incessant and irritating problem where with service-discovery-applet, the notice window is almost CONSTANTLY showing up to indicate what services appear and disappear? I don't so much mind the notifications as I do that they are in a highly crucial part of the screen, rather than out of the way.

I am attending a conference and, using it as an example, notify-osd has already been active for the past hour quite literally non-stop. Rather annoying when it is sitting over the titlebar and tab area of browsers and apps, despite the fact that it will fade when mouse hovers. So much for being unobtrusive.

While we wait for adjustments, Is there a setting to manually move the thing?

[David Barth (dbarth)]

I think this is more a problem with service-discovery-applet. Thanks for pointing this one out.

I've opened a new bug report for this one, and subscribed you. Can you comment on:
https://bugs.launchpad.net/ubuntu/+source/service-discovery-applet/+bug/348377

Thanks

[Noel J. Bergman (noeljb)]

I have commented. Mind you, I'm not sure that the service-discovery-applet is at fault. We can discuss on Bug 348377 what else it could do, but this never bothered me prior to the new notify-osd, which sticks its face where the controls are for maximized windows, tabs on tabbed windows, etc. The upper right of the screen has hardly an unobtrusive portion of the screen. If anything, I could argue that it was selected for maximum visibility, not maximum unobtrusiveness.

For what it is worth, we're over two hours on, and I'm almost prepared to remove the service-discovery-applet from my panel -- it is that annoying.

And the service-discovery-applet is not the only potential source of high(er) volume notifications. Same with Pidgin, as people appear and disappear, and send messages.

[Noel J. Bergman (noeljb)]

I've switched back to Intrepid to test perceptions, and despite having the same volume of notifications, they are *far* less intrusive both because they are in the bottom right of the screen, and because they stack when appropriate, meaning that as entities come and go, the related notifications appear in a batch, not one after another after another incessantly. So, yes, it may well be that fixing this bug takes care of the problem.

[Mark Shuttleworth (sabdfl)]

David, please open a discussion about having the service discovery
applet use append mode.

I think it would help folks if we could see Pidgin in append mode, at
least. What's the story on that?

Mark

[David Barth (dbarth)]

Mark Shuttleworth wrote:
> David, please open a discussion about having the service discovery
> applet use append mode.
>
The discussion is now on a separate bug report (#348377), and append is
indeed an excellent suggestion.

I think Cody or Ted mentioned it also yesterday during the engineering
call, because of the pidgin fixes, btw. Great minds come together.

[Noel J. Bergman (noeljb)]

Thanks, Mark. I've submitted a tentative patch for review.