Notifications should interact with the user in some cases

Bug #883046 reported by Dmitry Misharov
28
This bug affects 6 people
Affects Status Importance Assigned to Milestone
notify-osd (Ubuntu)
New
Undecided
Unassigned

Bug Description

In some cases Notifications require user interaction. For example in chat message was sent hypertext link and we would want to open it immediately just click on it, but no we must open Empathy window and click on link there.

Tags: uix
Revision history for this message
Jon Elofson (jon-elofson) wrote :

I agree 100%. I realize that these are "passive" notifications, but some would be much more useful if you could interact with them. Gwibber is another case where you want to click a link, but can't. Additionally, the mouse over effect of blurring seems counter-intuitive. Putting the mouse over blurs the notification, but not so much that you can really see through it. I always mouse over them thinking I can keep them in the forefront longer and get a chance to read them.

Things like volume control, it currently makes decent sense, but I still think the mouse over is not what I would consider the expected behaviour.

Revision history for this message
Dylan Weremeichik (dylan.weremeichik) wrote :

I'm not to overly familiar with Notify OSD, but with just a quick browsing through the code it seems that this is defiantly something that's possible, probably without too much work as well. This bug is rather annoying, especially in relation to im's. When i see an im pop up, i naturally want to click on it to reply. Obviously Notify OSD knows which window is calling it, so all that should need to be added is an event that allows you to click it, triggering x windows to pull the window to the front of the screen.

Revision history for this message
Javier Melero (ricmelero) wrote :

I completely agree. In fact, notifications are almost useless the way they are right now.

Click support.
First of all, notification bubbles SHOULD BE clickable which also implies to remove that confusing hover effect. 99% of times, a notification requires user attention, IF there something to notify, is highly probably that THERE IS something to attend to, but, the way it works right now, user only can see that something is happening and nothing more, if one want to do something about has to find by itself which application fired that notification.

Proposal.
My proposal is to have an unified behavior for all notifications:
On left click, first, look for a custom action for that application (applications should be able to send it with the message). Second, if there isn't a registered action, look for the main window of the application that fired the notification, bring to front and give focus, and finally, if there is no application window nor application indeed, just ignore that click.
On right click, dismiss the notification, marking it as read it.
This way, independently of the applications, you can bring to front the one that need your attention.
I think that buttons inside the bubbles and multiple custom action aren't a good idea, as they ends up by having an heterogeneus behavior across applications. But,... to support text links could be fine, I think.

Notification Queue.

The other aspect I think make notifications useless, is the fact that two (or more) notifications of the same "type" can't be showed at the same time and go to a queue. The most common case when this is noticed is when two contacts login and at the same time someone else chat you, you'll see that someone has logged in, a few second later will see that another friend has logged in, finally almost a minute after, you will see the message who talks to you. Most probably by the time you see the notification, you've already answered.
And this is the simplest and more frecuent example, but the situation could be much worst, when you have a music player, gwibber, etc.
It's pretty obvious that if you have a lot of applications running, you will have a lot of notifications, but that's not problem of notifyOSD module, the problem that appear in this case is the delay between the event that fired the notification and when it is showed, and this IS concerned by the notifyOSD module.

My proposal.
Stack notification bubbles vertically while the screen's height allow, when not, then send it to a queue. This behavior plus the action of dismiss notifications by right clicking on it, could improve a lot the usability.

Revision history for this message
Javier Melero (ricmelero) wrote :

Another consequence of the notifications queue, is that despite of the fact that a notification has been queued, the sound notification is not queued, so you might hear two (or more) bell's sounds but you'll see only one bubble, which is pretty confused at first, but then, when you get used, it's worst, 'cause you stare at the first bubble waiting to see whatever else needs your attention without a clue if what is, and with nothing to do to speed up that process, which is frustrating on a daily uses.

Revision history for this message
Javier Melero (ricmelero) wrote :
tags: added: uix
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

affects: notify-osd → notify-osd (Ubuntu)
Changed in notify-osd (Ubuntu):
status: New → Confirmed
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.