GNOME Bugzilla – Bug 776048
Allow expanding notifications from the list
Last modified: 2021-07-05 14:15:15 UTC
With the new notifications design that landed in 3.16, we lost the ability to expand notifications after they've been displayed as a banner. This is something that people have understandably missed, particularly in relation to chat (since the inability to expand a notification also means that you can't reply to messages - see bug 757588). Background to why the decision not to allow expanding notifications from the list can be found in bug 757588. The primary reason was that it is difficult in UI terms - in order to be able to expand a notification from the list, each notification would need to: 1. Indicate whether it can be expanded or not. 2. Provide two actions - one to open and one to expand. Given that notifications are somewhat small, this is a challenging design problem. However, it might not be impossible.
I find the notification system in Android (Especially in Nougat version) is really powerful, and resembles a lot of GNOME notifications characteristics. Why not see how they're doing it? (from a design point of view) This is the most annoying issue to me since I started using GNOME 3.16+, I really missed the bottom notification drawer for that feature.
*** Bug 782984 has been marked as a duplicate of this bug. ***
*** Bug 783054 has been marked as a duplicate of this bug. ***
First, as Florian Müllner said in bug 782984 ( https://bugzilla.gnome.org/show_bug.cgi?id=782984#c3 ), why don't have just the possibility to expand the notification by hovering it with your mouse but just to see the whole message ? Without talking about actions or chatting that make some issues and hard coding, hovering could only display the whole text of a notification..because, for now, if the text is too long, you can't see the end of the message, so, the list is corrupted.
Secondly, why is it mandatory to have to expand a notification to see the whole text display on it ? Is it a constraint of design or an other thing ? I still talk about just text. If not, why don't we begin to display the whole text of a notification without having to expand it ? ps: I read previous discuss in several bugs before and I don't reach the answer^^
(In reply to freeroot from comment #6) > ps: I read previous discuss in several bugs before and I don't reach the > answer^^ Did you also see this one? https://bugzilla.gnome.org/show_bug.cgi?id=757588#c11 Although primarily about notifications from messaging applications, many of the points made are also applicable to most notifications more generally. I don't know whether the designers still feel the same way, or if perhaps there are newer comments somewhere that I haven't seen. But maybe that's useful anyway.
(In reply to Daniel Boles from comment #7) > (In reply to freeroot from comment #6) > > ps: I read previous discuss in several bugs before and I don't reach the > > answer^^ > > Did you also see this one? > https://bugzilla.gnome.org/show_bug.cgi?id=757588#c11 Yes I red this comment. Please tell me the link between "see the text of a notification" as I said and "reply to a IM message". One is just a text, the other an action like it is said in the comment you recommended to me. > Although primarily about notifications from messaging applications, many of > the points made are also applicable to most notifications more generally. I'm ok with it. So, imagine your contact sending you a long message : without talking action, are you agree on just have the possibility to read the beginning of this long message ? If yes (because it's a dialog text), why can't I read the whole text of other type of notifications ? > I don't know whether the designers still feel the same way, or if perhaps > there are newer comments somewhere that I haven't seen. But maybe that's > useful anyway. Design is a constraint, it's normal. But if no one stand up an idea of design now and here, we make us more constraint that it's necessary to find the good solution. Design can be changed a little bit if it's very useful, it's normal too.
(In reply to freeroot from comment #5) > First, as Florian Müllner said in bug 782984 ( > https://bugzilla.gnome.org/show_bug.cgi?id=782984#c3 ), why don't have just > the possibility to expand the notification by hovering it with your mouse > but just to see the whole message ? I meant that to see the whole text, you would want to expand the notification like we do when hovering a banner. I didn't suggest that hovering was the best way to implement expansion in the message list as well. (Not saying it isn't either, though it's clearly a pointer-only method) (In reply to freeroot from comment #6) > Secondly, why is it mandatory to have to expand a notification to see the > whole text display on it ? Well, to see more text in a notification, you either: - make the notification bigger - make the text smaller - duplicate the text outside the notification (for instance in a tooltip) You probably mean the last option, but we have been generally moving away from tooltips - they aren't very discoverable and only work with the mouse (that is: no keyboard, no touch).
(In reply to Daniel Boles from comment #7) > I don't know whether the designers still feel the same way, or if perhaps > there are newer comments somewhere that I haven't seen. You are linking to a comment from Allan, who also filed this very issue. So I'd say comment #0 qualifies as "newer comments somewhere" :-)
(In reply to Florian Müllner from comment #9) > (In reply to freeroot from comment #5) > > First, as Florian Müllner said in bug 782984 ( > > https://bugzilla.gnome.org/show_bug.cgi?id=782984#c3 ), why don't have just > > the possibility to expand the notification by hovering it with your mouse > > but just to see the whole message ? > > I meant that to see the whole text, you would want to expand the > notification like we do when hovering a banner. I didn't suggest that > hovering was the best way to implement expansion in the message list as > well. (Not saying it isn't either, though it's clearly a pointer-only method) > > Ok, my mistake^^ > (In reply to freeroot from comment #6) > > Secondly, why is it mandatory to have to expand a notification to see the > > whole text display on it ? > > Well, to see more text in a notification, you either: > - make the notification bigger > - make the text smaller > - duplicate the text outside the notification > (for instance in a tooltip) > > You probably mean the last option, but we have been generally moving away > from tooltips - they aren't very discoverable and only work with the mouse > (that is: no keyboard, no touch). I don't know how it could work or not with a tooltip, I believe in you. But my option were the first one : make the notification bigger, in fact, with the same height than the popup notification in order to display the text. I add an attachment to be more understandable.
Created attachment 352539 [details] Comparaison of text of popup notification and message-tray notification (comment 11)
Happy to see activity on this bug, and I find this an opportunity to say *again*: What about Android notification system? It has all these features and more. What about MacOS notification center? Windows 10 notification center? The later is trying to target both mouse & keyboard/touch users.
(In reply to freeroot from comment #11) > my option were the first one : make the notification bigger, in fact, with > the same height than the popup notification in order to display the text. So to rephrase that: Expand the notification like banners ;-)
I'd certainly like to see the design team look at this issue properly and design something detailed and then have it built. However, in the interim maybe a simple compromise solution would be ok: have the notification summary list add not only a close cross icon but also a "maximise" icon to a notification in the list, which when clicked (or selected by keyboard) would redisplay the notification again as it was displayed the first time, thus giving people a second chance to read the longer text and maybe press the action buttons. This seems like something that would probably be doable via an extension
(In reply to Florian Müllner from comment #14) > (In reply to freeroot from comment #11) > > my option were the first one : make the notification bigger, in fact, with > > the same height than the popup notification in order to display the text. > > So to rephrase that: Expand the notification like banners ;-) There is a confusion about the word "expand": For you, it's to have a correct size. For me, it's to have the possibility to open and collapse So, there is quiproquo between us^^. This bug is to "allow expanding notification" (it's a action) and, before, I would like to understand why "have expanded notification" (it's a state) is not the rule. To sum up, why notifications in message-tray don't have, at least, the same height as banner one in order to display the text. Let's talk about actions in a second time, it's a bigger issue.
OK, to add perspective to my last comment 13: here's guides to both MacOS and Windows 10 Notification/Action Centers: https://support.apple.com/en-us/HT204079 http://me.pcmag.com/windows-10-preview-release-date-news-features/2723/feature/how-to-use-windows-10-action-center Windows 10 Action Center notifications can be expanded with using a small down arrow (under the notification time). MacOS concept of the Notification Center is more versatile and powerful than even Android one (it combines the power of Notifications and Widgets at the same time) and it's really customizable. When I look into the design plans for the notifications in GNOME: https://wiki.gnome.org/Design/OS/Notifications & https://wiki.gnome.org/Design/OS/Notifications/MessageTrayDrawer .. I see that you had these ideas from day 1, but after the notification revamp in 3.16+, I feel like you lost this sight.
(In reply to Stuart Langridge from comment #15) > I'd certainly like to see the design team look at this issue properly and > design something detailed and then have it built. However, in the interim > maybe a simple compromise solution would be ok: have the notification > summary list add not only a close cross icon but also a "maximise" icon to a > notification in the list, which when clicked (or selected by keyboard) would > redisplay the notification again as it was displayed the first time, thus > giving people a second chance to read the longer text and maybe press the > action buttons. This seems like something that would probably be doable via > an extension Redisplay a notification because those on message-tray are unreadable ? Your solution could work but it looks like a new bug.
(In reply to freeroot from comment #16) > There is a confusion about the word "expand": > For you, it's to have a correct size. > For me, it's to have the possibility to open and collapse > So, there is quiproquo between us^^. I have no idea what you mean. When I say "expand", I certainly mean open/collapse ...
(In reply to Florian Müllner from comment #19) > (In reply to freeroot from comment #16) > > There is a confusion about the word "expand": > > For you, it's to have a correct size. > > For me, it's to have the possibility to open and collapse > > So, there is quiproquo between us^^. > > I have no idea what you mean. When I say "expand", I certainly mean > open/collapse ... He wants to make the size (height) of the notification item in the notifications list bigger (higher) to have capacity for more text before it truncates it, preferably the same size (height) of the banner one (in its default/collapsed state).
(In reply to Florian Müllner from comment #9) > we have been generally moving away > from tooltips - they aren't very discoverable and only work with the mouse > (that is: no keyboard, no touch). Hm, on the rare occasion that I use my tablet, I can see the tooltips of things (when testing my GTK+ application) by tapping, dragging while holding the tap, then releasing over the thing whose tooltip I want to see. I don't know if Windows is unique in that regard; I've never tried GNOME on a touch device. But that seems accessible enough to me (full disclosure: I am an enthusiastic user of Vim, so my judgment may be impared ;-) Either way, IMO tooltips are essential for interfaces that tend towards minimalist design, e.g. like a lot of GNOME programs that only show icons in buttons. For as hard as the artists work on icons, there will never be a set that 100% of users instinctively know what 100% of the icons mean. I then find it essential to have a tooltip that confirms what the image really represents. And I have several times been disappointed when applications don't provide them. If not by this, then how else can we reconcile concise and sometimes cryptic image buttons with intuition/discoverability?
When I say : "I can't read texts of notifications", you tell me "We can't expand to notification because of IM". When I say : "I want to read texts of notifications", you tell me "You want to expand notifications". When I say : "I want to have expanded notifications limited to text details without any actions or IM answering, in order to read the text because for the moment message is truncated ans it's an idiot state I can't understand my notifications", you tell me "You want to allow expanding notification". When I say : "First talking about the text details of notifications and not about any actions", you tell me "Read previous discussions : expand notification is a problem with IM". It looks like a crazy dialog sometimes lol Please make a distinction between "text of notification" and "other stuff that makes issues". And, maybe, if texts and other stuff are not distinguish in the code, as it's not distinguish in this discuss, it is maybe the origin of this issue.
I don't understand what you don't understand. A notification consists of text and optionally one or more action widgets, such as buttons or text entries. In the list of previously received notifications, the text is abbreviated, and action widgets are not shown. The ability to expand notifications in the list would allow you to see the full text, and _optionally_, to reply to IMs.
(In reply to Daniel Boles from comment #23) > I don't understand what you don't understand. A notification consists of > text and optionally one or more action widgets, such as buttons or text > entries. In the list of previously received notifications, the text is > abbreviated, and action widgets are not shown. The ability to expand > notifications in the list would allow you to see the full text, and > _optionally_, to reply to IMs. Thx for your clear message :) This solution is in contradiction with what Allan Day said (https://bugzilla.gnome.org/show_bug.cgi?id=757588#c11) : do not have the possibility to reply to IMs in notification list. If it's something that changed, ok, but you are the first to say that. It's confusing because on comment 7, you link me to this comment, so, I thought you agreed with him. Well. IMO shorten notification is useful for popup, because you can go on to work on your stuff without having a big part of the screen hidden by the notification. Hovering the popup, if the notification interest you at the moment, and you can have access to entire information and action it deliver. It's what is existing now. But the notification list has a complete different use. The main difference is that, when the notification list is displayed, the user has already choose to have the focus on his notifications. In this way of displaying, there is a contradiction to display shorten notifications whereas the user wants, obviously, see his notifications and, obviously, all there contents. Why two action would be required (one to open notification list then one to open a notification) whereas the user has one clear intention and it's possible to deliver it in one click/shortcut ? That's why I don't understand why, in the notification list, notifications are not displayed straight expandED. Just display notification entirely, the goal wanted by allowing expanding notification would be reached quickly and easily, isn't it ?
(In reply to freeroot from comment #24) > (In reply to Daniel Boles from comment #23) > > I don't understand what you don't understand. A notification consists of > > text and optionally one or more action widgets, such as buttons or text > > entries. In the list of previously received notifications, the text is > > abbreviated, and action widgets are not shown. The ability to expand > > notifications in the list would allow you to see the full text, and > > _optionally_, to reply to IMs. > > Thx for your clear message :) > > This solution is in contradiction with what Allan Day said > (https://bugzilla.gnome.org/show_bug.cgi?id=757588#c11) : do not have the > possibility to reply to IMs in notification list. > > If it's something that changed, ok, but you are the first to say that. It's > confusing because on comment 7, you link me to this comment, so, I thought > you agreed with him. Yes, it changed. It changed when he opened this very thread! proposing that the ability to reply from the notification list should be considered again, after all: (In reply to Allan Day from comment #0) > With the new notifications design that landed in 3.16, we lost the ability > to expand notifications after they've been displayed as a banner. This is > something that people have understandably missed, particularly in relation > to chat (since the inability to expand a notification also means that you > can't reply to messages - see bug 757588). > > [...] > > Given that notifications are somewhat small, this is a challenging design > problem. However, it might not be impossible. I linked to that older comment to indicate why this feature was not included in the past. I didn't mean that it was still being discounted, obviously, since the very existence of _this_ thread disproves that. (In reply to freeroot from comment #24) > That's why I don't understand > why, in the notification list, notifications are not displayed straight > expandED. Just display notification entirely, the goal wanted by allowing > expanding notification would be reached quickly and easily, isn't it ? That would be fine if you only receive a few notifications, and you always want to see them all. I doubt all users feel that way. The idea of abbreviating them is so that more information can be summarised, in one place, without bombarding the user with info - and possibly having e.g. 1 huge notification that means they can't fit any more on the screen... what if they don't care about that huge notification, and it means they miss others which they _do_ care about? etc. But of course, abbreviation without the possibility of expanding to see the full thing is not very useful. Hence our wishes for expansion, and this thread. ;-)
(In reply to Daniel Boles from comment #25) > (In reply to freeroot from comment #24) > > (In reply to Daniel Boles from comment #23) > > > I don't understand what you don't understand. A notification consists of > > > text and optionally one or more action widgets, such as buttons or text > > > entries. In the list of previously received notifications, the text is > > > abbreviated, and action widgets are not shown. The ability to expand > > > notifications in the list would allow you to see the full text, and > > > _optionally_, to reply to IMs. > > > > Thx for your clear message :) > > > > This solution is in contradiction with what Allan Day said > > (https://bugzilla.gnome.org/show_bug.cgi?id=757588#c11) : do not have the > > possibility to reply to IMs in notification list. > > > > If it's something that changed, ok, but you are the first to say that. It's > > confusing because on comment 7, you link me to this comment, so, I thought > > you agreed with him. > > > Yes, it changed. It changed when he opened this very thread! proposing that > the ability to reply from the notification list should be considered again, > after all: > > > (In reply to Allan Day from comment #0) > > With the new notifications design that landed in 3.16, we lost the ability > > to expand notifications after they've been displayed as a banner. This is > > something that people have understandably missed, particularly in relation > > to chat (since the inability to expand a notification also means that you > > can't reply to messages - see bug 757588). > > > > [...] > > > > Given that notifications are somewhat small, this is a challenging design > > problem. However, it might not be impossible. > > > I linked to that older comment to indicate why this feature was not included > in the past. I didn't mean that it was still being discounted, obviously, > since the very existence of _this_ thread disproves that. > > > (In reply to freeroot from comment #24) > > That's why I don't understand > > why, in the notification list, notifications are not displayed straight > > expandED. Just display notification entirely, the goal wanted by allowing > > expanding notification would be reached quickly and easily, isn't it ? > > That would be fine if you only receive a few notifications, and you always > want to see them all. I doubt all users feel that way. The idea of > abbreviating them is so that more information can be summarised, in one > place, without bombarding the user with info - and possibly having e.g. 1 > huge notification that means they can't fit any more on the screen... what > if they don't care about that huge notification, and it means they miss > others which they _do_ care about? etc. > > But of course, abbreviation without the possibility of expanding to see the > full thing is not very useful. Hence our wishes for expansion, and this > thread. ;-) Ok, let's go for the complicated way^^. You are right, my way to use notification is not universal. But maybe other people would agreed with me after all.
In this case of abbreviated notifications in the list, IMO : 1. In all case, automatically reduce notifications which are not selected. Only one notification can be expanded at the same time to go on to simulate a summary. 2. · With the use of keyboard : Expand the selected notification. When message-tray is opened, auto-focus on the first notification and using TAB to go to the next notification. Press ENTER to enter/expand it. Once in it, using TAB to reach buttons/input, ENTER to start actions selected or the global action and ESCAPE to come back to selection of notification. · With the use of mouse : The first click on a notification expands it/opens it. All other clicks on the notification are linked to the notification itself (action widget, ...). · With the use of finger : The same as mouse. 3. In the case of a notification which is not abbreviated because its contents is too small, use the same process : Always having the same process avoid mistakes for the user. That's why I needed to talk about expand/open/enter as a same thing. 4. To communicate to user that a notification is expanded/opened, we can play with the background. Currently, a middle grey for all notifications, a light grey for the selected notification, and a dark grey for message-tray's background. We can imagine to use the dark grey, for example, to communicate to user which is the selected notification. 5. No need of new buttons. Keyboard/mouse/finger have similar approach. Easy and QoL. 6. Negative point : I don't have a coding approach.^^ I'm wide open to discussing.
*** Bug 790420 has been marked as a duplicate of this bug. ***
jesus christ a year old bug to just expand the freaking notifications in the tray to actually make them usable?
(In reply to jljatone from comment #29) > jesus christ a year old bug to just expand the freaking notifications in the > tray to actually make them usable? I reckon you are going to attach a patch then?
will it be accepted even if it doesn't meet the currently unspecified UX requirements? most of this thread is nit picking over UX decisions. so unless you have actual requirements for what the patch needs to meet, then no I won't waste my time generating a patch.
and just so we're clear, that was me offering to write a patch if the goal posts are clearly marked before I start.
I have the same. Setting "Show message content in Popups" for a concrete app is just a little help. 1) 'notify-send' is unusable 2) any popups disappear from the slightest mouse movement, I do not have time to notice anything. We need a real working list of all notification to able expand everyone. Please fix
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/ Thank you for your understanding and your help.