Like a lot of people, I was really happy with the big notification redesign that landed in 3.16. However, I’ve been itching to return to notifications for a little while, in order to improve what we have there. Prompted by some conversations we had during the Core Apps Hackfest last month, I finally got around to spending a bit of time on this.
One of the main goals for this is to focus the UI – to improve the signal to noise ratio, by refining and focusing the interface. This can be seen in the new mockups that have been posted for the shell’s calendar drop down – the number of extraneous visual elements is dramatically reduced, making it much easier to pick out interesting information.
The other aspect of my recent work on notifications is to improve the quality of the notifications themselves. Notification for events that aren’t of interest, or which stick around for longer than necessary, can undermine the entire notifications experience.
This is why, aside from updating the shell’s UI for presenting notifications, the other aspect of this effort is to ensure that applications are using notifications effectively. This includes making sure that applications:
- Only show notifications that are actually interesting to the user.
- Revoke notifications once they have outlived their usefulness.
- Give every notification a useful title and body text.
I’ve recently reviewed a bunch of GNOME applications to ensure that they are using notifications correctly, and have created a wiki page to track the issues that I found.
If you spot any GNOME applications not using notifications effectively, it would be great if you could help by filing bugs and add them to the wiki page. Likewise, if you work on an application that uses notifications, make sure to check that you’re following the guidelines. It would be really great if GNOME could achieve across the board improvements in this area for the next release!
one thing i’m really missing from my desktop experience is having google chrome notifications inside gnome notification area. according to google devs (there is a ticket) the current freedesktop-notification protocol doesn’t support various features that would be needed for them to implement chrome’s notification “native” for the linux (gnome) desktop, as they are already available on macOS and Windows10
That would be good indeed! Can you find that ticket?
I believe this may be the one: https://bugs.chromium.org/p/chromium/issues/detail?id=53239
There isn’t a lot in that issue page, but there’s a link to their Technical FAQ with some more information. Big ones: the notification protocol (and server) needs good support for arbitrary HTML, and Chrome’s notifications need an options menu. Also there’s the issue that Ubuntu’s very simple notification server will never do any of this (but hopefully they wouldn’t mind a patch that checks capabilities and falls back to the old stuff if needed).
It would be nice if gnome-shell had a way to let the user discover which application is responsible for a particular notification. E.g. Android lets you do this with a long hold.
This wouldn’t necessarily have to be a user-level feature; a dev tool where you could e.g. run a command in a console and see the originator for each non-dismissed notification would suffice. Or maybe Looking Glass could show the info?
I’m asking for this because sometimes it’s unclear which system component is responsible for a particular notification, so I’ve no idea where to file a bug.
Hi Allan,
I know that world is moving on from open chat protocol :'( … but I would like your opinion about chat notification workflow in gnome 3..
Imagine a user with several workspaces. One of this workspace contains his chat application (e.g empathy). He uses this workspace when he want to initiate a conversation.
Most of his time, this user uses others workspace.
Now it receives a chat notification, he can answer immediately using the expanded banner (ctrl+N). That’s good !
Now imagine it want to finish something before to answer. (or any other reason which will not allow him to answer instantly …). When he want to answer, he can use (ctrl+M) to see notification chose the missing notification and open it. Currently this will move him to the chat application workspace, now it can answer and then go back to the previous workspace. This seems not so good :/
How could we enhance this ? Maybe when we open the chat notification this could open the expanded banner instead of open the chat application. WDYT ?
Simon
The question of whether to allow replying to chats from the calendar drop-down is one that has been discussed at some length. I’m personally interested in how we might allow that to happen. It does involve some tricky UI questions that we haven’t been able to develop sufficient answers to yet, but we’ll keep looking. I’ve filed a bug to track this issue – https://bugzilla.gnome.org/show_bug.cgi?id=776048
Would this cover action buttons in notifications too? Right now, once the popup is gone, those actions are inaccessible. Apparently this makes it impossible to reply to (or hang up on) SIP calls in Empathy. Far from ideal! I opened a bug about this, but it was marked as a dupe of one about chat replies, though without any confirmation of whether it was being considered alongside those (which seem to be the main focus of everyone, except me :) https://bugzilla.gnome.org/show_bug.cgi?id=775190
I’d say that’s more of an Empathy bug myself – you shouldn’t rely on notification actions for essential functionality.
Sure, it’s crappy that Empathy does that. Was anyone in any doubt about the general fitness of that app? But actions on notifications are far less useful for this, given that they can disappear after a few seconds and not be accessible again (barring, presumably, some inconvenient way to retrigger them from elsewhere in the app). I agree that no program should be structured around action buttons on notifications, but that doesn’t mean they should be relegated to quite so extreme a degree of transience/novelty feature that they currently are.
One thing I would *love* would be to have aggregate notifications. Geary does this on its own at the moment (which you can see in your screenshot), aggregating all the new, unread emails.
However, it would be way cooler to have a notification ‘You have x new mails’, which you can expand with a button to the different mails (and shrink). That would also decrease the visual noise, since notifications could get grouped.
Hi, I would love it too! :p
The thing that I would like to see in gnome notifications is having a keyboard shortcut that clears all the notifications.
Right now what I do is clicking Meta+M, , or .
It would be nice if we have one shortcut.
I know that KDE doesn’t support this either. The only thing I found that support this is Dunst http://knopwob.org/dunst/index.html
I meant clicking Meta+M, (Tab) , (Enter) or (Space).
The commenting system didn’t like the angular brackets that I used :)
Decent idea.
At the moment, I guess Super+V, Right, Enter is tolerable.