Notifications appear too low

Bug #434789 reported by ed10vi
72
This bug affects 13 people
Affects Status Importance Assigned to Milestone
Notify OSD
Invalid
Wishlist
Mirco Müller
notify-osd (Ubuntu)
New
Wishlist
Mirco Müller

Bug Description

The notification does not appear next to the top panel, they leave a place for the sound, brightness, etc notification

Ubuntu Karmic Koala 64bis
Notify-osd 0.9.21-0ubuntu2

Revision history for this message
ed10vi (ed10vi86) wrote :
Revision history for this message
ed10vi (ed10vi86) wrote :
Revision history for this message
Michael Martin-Smucker (mmartinsmucker) wrote :

I'm seeing this on both of the computers that I'm testing Karmic on.

Revision history for this message
Sebastien Bacher (seb128) wrote :

The bug is in fact a design decision

"notify-osd (0.9.21-0ubuntu1) karmic; urgency=low

  * New upstream version (LP: #427434)
    - Using a fixed slot-allocation scheme now. This means async
      bubbles (e.g. volume) always appear in the top slot/position
      and sync. bubbles (e.g. IM-message notification) always appear
      in the bottom slot/position."

Changed in notify-osd (Ubuntu):
importance: Undecided → Low
status: New → Invalid
Revision history for this message
Mat Tomaszewski (mat.t.) wrote :

Please note that the above comment confuses asynchronous with synchronous.

Sync (synchronous) - user-triggered, like volume or brightness

Async (asynchronous) - external-triggered, like IM or network

Revision history for this message
Michael Martin-Smucker (mmartinsmucker) wrote :

Could someone link to a mailing list topic or blog entry or something that explains the rationale behind this change? I doubt that many users are going to think, "Oh, of course the notification is placed there. It's asynchronous." More people will probably wonder why so many notifications don't show up in what they perceive to be the "right" spot.

For me, most of my notifications are of the asynchronous variety, so a majority of my notifications appear in their new slot, with a weird-looking gap above them. Plus, they're now much more likely to interfere with content on the rest of the page than they would be in the corner. This problem is much worse with non-widescreen, lower-resolution monitors.

But certainly there's some reasoning to defend this design decision, so I'd be interested in reading it.

Revision history for this message
Mirco Müller (macslow) wrote :

The main reason behind this is to predictability.

Changed in notify-osd:
assignee: nobody → Mirco Müller (macslow)
Changed in notify-osd (Ubuntu):
assignee: nobody → Mirco Müller (macslow)
Changed in notify-osd:
importance: Undecided → Wishlist
Changed in notify-osd (Ubuntu):
importance: Low → Wishlist
Changed in notify-osd:
status: New → Invalid
Revision history for this message
Michael Martin-Smucker (mmartinsmucker) wrote :

I'm certainly not trying to sound like an insistent jerk, but it seems like putting all notifications in the same place is more predictable than dividing notes into classes that that won't be immediately obvious to many users.

"I predict that the next notification will be in the top-right corner of the screen" is a much simpler prediction than "I predict that the next notification will be in the top-right corner if I cause the notification, but moved down a slot if an application causes the notification." The logic is more complex, notifications take up more valuable screen real estate, and the user interface doesn't look as consistent.

If this change really increased predictability, no one ever would have thought it was a bug in the first place. I won't be surprised if this gets several duplicates once Karmic is released.

Revision history for this message
Olivier Guéry (nemolivier) wrote :

+1 on this.
I was about to make a bug report when I find this.
For me notification is a stack processus don’t mater async or sync.
But I can understand your thinking.
Maybe If you realy want to seperate sync and async you could choose different aspect / place to follow the seperation.

For the moment, like the others, most of my notification are IM async and look weird with this gap since async are « surprized » and sync not (you can put them where you want : I know they gonne apear).

So, at least, inverting the locations of both ? Putting the async on top and sync on bottom ?

(PS : sorry for my bad english)

Revision history for this message
Davide Lasagna (lasagnadavide) wrote :

+1 on Michael note.
I have a lot of banshee notification popping out somewhere in the "middle of the screen". I'm sorry, but IMO I don't see any reason for this new behaviour.

Revision history for this message
Beto (es-beto) wrote :

I was also going to mark this as a bug until i saw this
maybe it is because we were used to the notifications in 9.04

Revision history for this message
Nicolas (nicolas-espina) wrote :

Yep... I have a lot of notifications of banshee and emesene...

Revision history for this message
Forlong (forlong) wrote :

The design should be the other way around. Most people don't even sit in front of a laptop so they won't EVER see the top bubble.

Revision history for this message
Jeremy Foote (jdfoote1) wrote :

I agree with the other commenters - if it ain't broke, don't fix it.

Revision history for this message
Speedboy (speedboyii) wrote :

"I agree with the other commenters - if it ain't broke, don't fix it."

I completely agree. It just doesn't look right like this.

Revision history for this message
spinstartshere (spinstartshere) wrote :

I also thought this was a bug, and have been waiting some weeks in the hope that it would be fixed in an update. It makes little sense and doesn't look very good, having the large majority of my notifications not directly below the panel, but about 2 cm below it. If anything, shouldn't user-triggered notifications be delegated to a lower priority since the user, having been the one who triggered it in the first place, would already know that something is being changed and to what degree? I don't think a bar needs to take priority over instant messaging and media player notifications to indicate to the user how much light they want to be hitting their eyes from the monitor when they can quite easily gauge this for themselves.

Revision history for this message
Chris Hutt (chrishutt) wrote :

I agree, the positioning of the majority of notifications looks wrong, unless I just happen to be adjusting the volume at the same time - which is unlikely. It's probably a lot of work but if they can ever be made to behave like in the video here http://www.markshuttleworth.com/wp-content/uploads/2008/12/jaunty904_notifications_example1_web_092.swf it would be great. At the moment I'm thinking they were better in Jaunty. Sorry.

Revision history for this message
Brownout (brownout) wrote :

This "feature" is extremely annoying on small displays (netbooks), notifications are displayed in the middle of the screen.
Please revert to the old behaviour or let users configure it.

Revision history for this message
Michael Martin-Smucker (mmartinsmucker) wrote :

I'm sorry if reopening this breaks Launchpad protocol, but I don't think "It's a design decision" is enough reason to invalidate a report that many people clearly consider a bug. If the reason behind the design decision is "predictability," as stated earlier, then the growing number of comments here suggests that the reasoning is flawed.

It seems like a larger number of people testing Karmic means a larger number of people adding "me too" comments to this closed bug report, so I'm reopening it in hopes that developers will seriously reconsider this before it's too late for Karmic.

Changed in notify-osd (Ubuntu):
status: Invalid → New
Revision history for this message
neuromancer (neuromancer) wrote :

+1 on Michael note also for me.
I was opening a bug when i found this discussion.

I understand that there are some design decision behind this solution but also for me, that I don't know this decision, the notifications appears to be wrong positioned.

Revision history for this message
Kendrick (kendrick90) wrote :

+1 I agree that all notifications should appear in the same place. In the event that two notifications appear at the same time, i.e. if you change the volume at the same time that the song changes in banshee, the asynchronous osd (banshee) should be moved down and the synchronous (volume) osd should take the first position. Otherwise it looks weird. At least make it a user configurable option.

Revision history for this message
Ongion (benpy2k) wrote :

I'm in the same boat as Dinero Francis. I've been using Ubuntu for about 4 years now, and I didn't pick up on the difference between "sync" and "async" notifications. From the standpoint of a new user, this would be even MORE confusing, because they wouldn't know where to look for an explanation. I don't feel that this "design" was very well justified.

Revision history for this message
Mark Shuttleworth (sabdfl) wrote : Re: [Bug 434789] Re: Notifications appear too low

There is an active thread on the Ayatana mailing list which includes the
current thinking on the notification position. Individual bugs saying
"too high" or "too low" or "should be somewhere else" should shift their
focus to that thread. We will try some other options for Lucid, then
move on.

Mark

Revision history for this message
Marcos Diaz (marcos-diaz) wrote :

 If an usablity fix seems a BUG, better do nothing.
At least is necesary an option to disable this "feature".

Revision history for this message
Thomas Dybdahl Ahle (lobais) wrote :

I like that thought is going into making the bubbles predictable.
I've always found notification bubbles very blurry in that aspect.
However perhaps the problem is, that sync notifications shouldn't actually be notifications, and have an entirely different positions scheme and appearance.
Jm5c.

Revision history for this message
Bracken (abdawson) wrote :

Any way I can have them all at the top now?

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.