GNOME Bugzilla – Bug 641723
We can easily miss incoming messages when using the Shell
Last modified: 2021-07-05 14:04:11 UTC
Currently when you receive an incoming Telepathy message, the notification is displayed during a few seconds and then hidden at the bottom of the screen. The user has to move his mouse to the right down corner to see them. Those notifications are pretty important, and if the user missed it (because he was distracted or AFK) he may not notice that there are people trying to talk to him before a while. We got LOADS of feedback from people saying there are missing messages because of Ubuntu's indicator patch: just making a small icon turn green is not visible enough for them to notice they have messages; gnome-shell is making this even worst as those incoming messages are not visible at all on the desktop.
So, concretely, do you have suggestions for changes? I think the only real option we have within our current UI framework would be to make the "urgent" so they would pop up at the bottom of the screen until explicitly dismissed. Note that the messages aren't intended to vanish if you are idle (not sure how much of that is implemented), so the AFK case shouldn't happen.
We have a patch in bug 617225 for keeping the message tray showing if the user is idle and there were new notifications, which is in my queue of patches to review. This should improve the situation with missing messages. We don't want the user to miss being aware of any new notifications in the tray, not just the chat ones. At the same time, making the chat notifications urgent and requiring the user to react to them as they show up would make the tray behavior not respectful of the user's focus. At most, we can make the first of the chat notifications from a particular person urgent.
Showing notifications when coming back from away is nice but not enough. User could miss a notification because he's making a cup of tea or briefly chatting with a co-worker without reaching the time to automatically detect idleness. I think we should distinct 3 type of notifications here: - Important ones (text chat, incoming calls, incoming file transfers, etc) which have to be seen and answered ASAP because they may not stay valid for a long time. - Normal ones (new mails or new feeds to read, download finished, missed call, etc) which are an useful information to tell to the user but which are not critical for him to see ASAP. The current notification system works pretty well for those I think. - Volatile informative ones (song changed in rhythmbox, contact becoming online/offline) which are pure information which are nice to tell to the user when it happens because are not really worth being kept in the notification bar afterwards. We could probably use notification hints for that.
I think this bug should be a GNOME 3 blocker. If we don't fix it I except loads of users will be really upset because they'll miss important messages. Trust me, we already experienced that with Ubuntu's indicator patch.
(In reply to comment #4) > I think this bug should be a GNOME 3 blocker. If we don't fix it I except loads > of users will be really upset because they'll miss important messages. Trust > me, we already experienced that with Ubuntu's indicator patch. All told, I've probably missed at least 30 new messages in the few months I've been running gnome-shell full-time. This is even with event sounds (which were only turned on for me due to a broken gsettings package or something). Now that that's fixed, I have a feeling I'll miss even more messages.
So bug 617225 has been fixed making the tray show up after the user comes back from away. Bug 643014 and bug 636838 will implement showing a tray after a short period of inactivity if there are new notifications and highlighting the sources for these notifications. In combination with the fact that the tray is always visible in the overview, this should improve the user's awareness of the new notifications. Beyond that, we can keep chat sources highlighted as new until the user interacts with them and/or make the first of the chat notifications from a particular person urgent. From the code perspective, chat messages are already in category of there own and have HIGH urgency value. The messages that come through the notification daemon, have their own urgency value that can be LOW, NORMAL or CRITICAL. So there is no need for an additional hint. HIGH urgency is used it to push chat messages towards the top of the notification queue, just after CRITICAL, if there are multiple queued messages.
The linked bugs are both marked important and should alleviate the problem. Not sure it is worth keeping this one open too.
I'd keep it open until the 2 other bugs have been fixed so we'll have a chance to reconsider with the new behaviour.
What about simply highlight the "message" icon in top panel (aside user's name)? Like it is in Unity (yeah, I know, its a competitor...). It is not disturbing and user always can see if there is some message waiting. I really like that I'm not disturbing by messages, but I also really hates that when I didn't spotted it, I don't know for long time that someone sends me something important... I think that this bug also breaks goal "remind for unseen messages" mentioned in https://live.gnome.org/GnomeShell/Design/Guidelines/MessageTray
(In reply to comment #10) > What about simply highlight the "message" icon in top panel (aside user's > name)? Like it is in Unity (yeah, I know, its a competitor...). It is not > disturbing and user always can see if there is some message waiting. I don't think that's a valid option - not because it's done by a competitor, but rather because it is entirely disconnected from the message tray. The natural reaction to an icon change like this is to click the icon - which will open the user status menu and not show waiting messages.
(In reply to comment #11) > I don't think that's a valid option - not because it's done by a competitor, > but rather because it is entirely disconnected from the message tray. The > natural reaction to an icon change like this is to click the icon - which will > open the user status menu and not show waiting messages. It's true, I didn't think about it this way. So another approach could be highlighting the Activities button. When user click on it, in the Dash is visible message tray. Or it could re-appear notifications there. Only trying to help :) Thanks
Hi, I have this same problem, i miss messages in chat. I like this options: - highlighting the Activities button (hey, missing notifications is activities to do.) - ... or... simply highlight the "message" icon in top panel - have a queue of notifications in Dash.
(In reply to comment #13) > Hi, I have this same problem, i miss messages in chat. > > I like this options: > > - highlighting the Activities button (hey, missing notifications is activities > to do.) > - ... or... simply highlight the "message" icon in top panel > - have a queue of notifications in Dash. May be a border glow in button of screen like this animation: http://i.imgur.com/bhh9C.gif
(In reply to comment #14) > May be a border glow in button of screen like this animation: > http://i.imgur.com/bhh9C.gif This seems to me like too much disturbing, which is exactly opposite of that we are trying to converge to - not disturb but give a clear way to inform about notifications ;) Florian had true argumentation why don't highlight message icon. Yeah, it was my suggestion, but I really like the idea of highlighting Activities button. Lets wait for reaction from someone inside Gnome :)
See also bug #649230 where an user is complaining he's missing a load of messages because of the Shell.
(In reply to comment #16) > See also bug #649230 where an user is complaining he's missing a load of > messages because of the Shell. I still miss a message for hours nearly every day for some of the same reasons described in that (and this) bug. And that's with relatively few incoming IMs. This is with Gnome Shell 3.0.0.2 (since it was brought into Debian experimental; earlier versions for months before that). Showing the Activities view after a long timeout helps a little, but I almost never see that when I come back to my computer after a long break (usually lunch). And though I often have new messages when I unlock my computer at the beginning of the day, I rarely notice them immediately. I could train myself to check for them, but that seems like excessive work on the user's part. I also think (as I predicted above) that part of the reason I'm missing new incoming messages is because I've turned off event sounds. (I don't think turning them back on is a solution, 1. because I want to deal with incoming messages on my own time schedule; 2. they tend to blend into whatever music I'm playing anyhow; and 3. if I do hear them, they annoy me).
I think my usage pattern may be falling between 2 cases that are currently handled well: * zero incoming messages (moot point) * frequent incoming messages * these users likely know to check for messages as necessary and just want the slightest notification; they'll get around to it when they reach a natural break point The problem is that I get messages rarely enough that I'm not in the habit of checking for them when I hit a natural break point. But when I finally do notice them, it's usually been 1.5 to 4 hours since the original message was sent (and I've generally been at my computer, non-idle nearly the entire time). So it looks like I've been intentionally ignoring the message, not at my computer, etc.
*** Bug 649328 has been marked as a duplicate of this bug. ***
another bad experience here! :) from my point of view: 1. i looked at gnome shell, clicked the date/time icon to see nice calendar. what i see there? the calendar of course and schedules for today and tomorrow, date time settings starter and ability to start full calendar application. simple and advanced enough. 2. now... i expected to see the _message_ icon in top-right corner blinking when i have unread messages. instead i am being annoyed by message tray (even when empathy's chat tab/window is focused). it allows you to change visibility and access acounts, but there is no more messaging related information (i.e. in calendar i have schedules, then why no info/indication about unread messages here?) i have been using gajim for years and it just blinks its icon when there are unread messages. no balloons, poping up windows, etc. very simple notification mechanism, whenever you are actively sitting in front of your computer or you are just back from lunch. for sure _much_less_ annoying than message tray in gnome shell. imho, message tray would be great in activities view (still kinda duplicates with avatars in bottom-right corner?). this and related bugs are few months old now and several proposed solutions are more or less complex, so imho it would be good to have some simple solution at the begining: - display message tray only in activities view - checking for new messages is simple as pressing Alt-F1/win-key in such situation - provide gconf switch to enable blinking message icon in top-right corner when there are unread messages - if it is ok with UI concept, then enable this option by default above proposal is quite simple, easy to implement, does not require any special behaviour algorithms (based on timeouts, screen saver settings, inactivity guessing, etc) and does not prevent you from implementing more advanced techniques in the future, imho.
I totally agree with wrobell. My proposal is to put an icon in system status area for centralized notification notification handling (xchat icon is good example). When user click on this icon, list of all notifying items appears. User should be able to mark all items as read with one click and notification icon turns to its inactive state and will be ready for new notifications. This is needed, because some times you don't have time to pay attention to everything and if you see that currently there is not so urgent apps requiring your attention, you can leave it as is and prepare notification area for new possibly more important notifications. If user click on an item, that asks for attention, action provided by sender application should be performed: mail client opens list of unread emails, chat client opens chat window, IRC client shows list of channels that are monitored for activity, etc. Also it would be great to blacklist some apps or some kinds of notifications in an app. This would be really useful if you see, that an app is asking for your attention to often with not so important information.
How about adding a slight glow or even a small icon in the message tray hot corner when there are new notifications? That way it's directly connected to the message tray, and shouldn't be too distracting.
Created attachment 187743 [details] Notification example
This is my suggestion for notifications https://bugzilla.gnome.org/attachment.cgi?id=187743 When there is something to notify, an animated icon should clearly tell you, that there is something, that needs your attention. When you press that animated icon, list of all notifications are provided. You can mark all notifications as read, to make notifications area ready for new notifications, that you don't want to miss.
while not perfect... http://bone.twbbs.org.tw/blog/archives/2148
*** Bug 650795 has been marked as a duplicate of this bug. ***
This bug is several months old and still unconfirmed. Is there a chance to accept it as a bug... or is it invalid?
bug #649356 could also help a little in this area.
Once the Shell acks messages (bug #644297) we could tweak the message tray to keep the notification always displayed while there are unread messages.
(In reply to comment #29) > Once the Shell acks messages (bug #644297) we could tweak the message tray to > keep the notification always displayed while there are unread messages. I would prefer this solution the most (in combination with the "new message" indicator being static, not flashing and showing the message count as in comment #28).
(In reply to comment #30) > (In reply to comment #29) > > Once the Shell acks messages (bug #644297) we could tweak the message tray to > > keep the notification always displayed while there are unread messages. > > I would prefer this solution the most (in combination with the "new message" > indicator being static, not flashing and showing the message count as in > comment #28). imho, flashing icons vs. static with message count should be theme thing?
We discussed this at the IM, Contacts & Social hackfest. See <https://live.gnome.org/Hackfests/IMContacts%20Social2011/Tasks/ShellDesignChat> for fuller notes of the discussion. Here are three broadly orthogonal changes we came up with that could make it harder to miss messages: • Currently, any events that occur while you're set to Busy are shown when you switch back to Available are shown. This is great: we could extend it to also re-show notifications that you hadn't dealt with at the moment you switched to Busy. For instance: I'm writing an email, and Danni sends me an IM. I want to reply, but only once I've finished my mail. So I flip my status to Busy. When I finish the email, I go back to Available, and the shell reminds me about her message. (Currently, I forget about the message by the time I've finished my mail.) • Currently, notifications are shown for 5 seconds, and then disappear. We could change this to only count down while there is mouse and keyboard activity. So if the user looks away from their computer for 30 seconds (to talk to a colleague), notifications for messages they receive while not looking would still be on the screen when they look back. (Whereas currently, those notifications are hidden and the user has no idea that a message arrived.) • We could consider adding a ripple—like the ripple from the top-left hot corner—which shows every minute or so (possibly with some kind of backoff) to remind the user that they have pending notifications. This is more controversial than the above two: not nagging the user is a design goal. But there's a trade-off between allowing the user to continue their work uninterrupted, and not risking the user missing (or forgetting about) important messages for hours.
(In reply to comment #32) [...] > • Currently, notifications are shown for 5 seconds, and then disappear. will be there a possiblity to switch off that as well? it raises privacy concerns (i.e. i am available to chat, but someone looks above my shoulder, bug 648376) and is quite annoying for some people (bug 649028). [...]
(In reply to comment #33) > (In reply to comment #32) > [...] > > • Currently, notifications are shown for 5 seconds, and then disappear. > > will be there a possiblity to switch off that as well? it raises > privacy concerns (i.e. i am available to chat, but someone looks > above my shoulder, bug 648376) and is quite annoying for some > people (bug 649028). > > [...] Setting your desktop status to 'Busy' using the top right chooser will disable those.
(In reply to comment #34) > (In reply to comment #33) > > (In reply to comment #32) > > [...] > > > • Currently, notifications are shown for 5 seconds, and then disappear. > > > > will be there a possiblity to switch off that as well? it raises > > privacy concerns (i.e. i am available to chat, but someone looks > > above my shoulder, bug 648376) and is quite annoying for some > > people (bug 649028). > > > > [...] > > Setting your desktop status to 'Busy' using the top right chooser will disable > those. i know. but it will change empathy status to "busy" as well. i would like to be available for my friends but to not be distracted by message tray at the same time.
(In reply to comment #32) > • We could consider adding a ripple—like the ripple from the top-left hot > corner—which shows every minute or so (possibly with some kind of backoff) to > remind the user that they have pending notifications. This is more > controversial than the above two: not nagging the user is a design goal. But > there's a trade-off between allowing the user to continue their work > uninterrupted, and not risking the user missing (or forgetting about) important > messages for hours. I started to develop a habit of moving my mouse down the the bottom-right corner every few minutes after I missed a few urgent email notifications at work. This may really help. Just put a static ripple at the bottom-right when there are unread, non-volatile notifications after a moment, so that I only need to glance at the corner, no mouse movement needed. I guess it's less interrupting than ripple animation every few minutes.
Thinking a bit more, I think my problem is that my work mails are expected to be read within a short period of time. So if I can set due time to some source (evolution for example), then when notifications go past that time unread, they are escalated to urgent (ie. won't disappear until I read them). That may help chat messages too (say due in 5 minutes). Anybody knows how hard to do this?
The Shell now displays the number of unread messages in each Chat source (bug #654139) that should improve things a bit as we can now easily see if we have unread messages.
I'd reiterate what's been said earlier, for my use case at work, it would be really beneficial to have the same type of indication for email as well.
(In reply to comment #39) > I'd reiterate what's been said earlier, for my use case at work, it would be > really beneficial to have the same type of indication for email as well. Given that Evolution uses one notification per message, the same indicator should work there as well. Otherwise, unless we implement a custom source for Evolution, I'm not sure it would work.
(In reply to comment #32) > We discussed this at the IM, Contacts & Social hackfest. See > <https://live.gnome.org/Hackfests/IMContacts%20Social2011/Tasks/ShellDesignChat> > for fuller notes of the discussion. Here are three broadly orthogonal changes > we came up with that could make it harder to miss messages: > > • Currently, any events that occur while you're set to Busy are shown when you > switch back to Available are shown. This is great: we could extend it to also > re-show notifications that you hadn't dealt with at the moment you switched to > Busy. For instance: I'm writing an email, and Danni sends me an IM. I want to > reply, but only once I've finished my mail. So I flip my status to Busy. When I > finish the email, I go back to Available, and the shell reminds me about her > message. (Currently, I forget about the message by the time I've finished my > mail.) > > • Currently, notifications are shown for 5 seconds, and then disappear. We > could change this to only count down while there is mouse and keyboard > activity. So if the user looks away from their computer for 30 seconds (to talk > to a colleague), notifications for messages they receive while not looking > would still be on the screen when they look back. (Whereas currently, those > notifications are hidden and the user has no idea that a message arrived.) > > • We could consider adding a ripple—like the ripple from the top-left hot > corner—which shows every minute or so (possibly with some kind of backoff) to > remind the user that they have pending notifications. This is more > controversial than the above two: not nagging the user is a design goal. But > there's a trade-off between allowing the user to continue their work > uninterrupted, and not risking the user missing (or forgetting about) important > messages for hours. I'd really like to see improvements in this area for 3.4. Design guys: what do you think of these suggestions?
I want to get my solution heard: Why not just remove the bottom message-tray and instead add a new icon to the top black bar, called "Notifications"? You click the icon and get one of those black-with-white-borders-speech-bubble listing all trayed apps. If you have new notifications, the notifications-icon can flash from grey to white or like glow up or whatever. Thats minimalistic and clears up the bottom part of the screen for apps to use. (sometimes when I move my cursor to the bottom right I don't mean to show that message-tray but rather switch back from fullscreen on YouTube.) Kind of like Windows 7, but with class and style :D
(In reply to comment #14) > (In reply to comment #13) > > Hi, I have this same problem, i miss messages in chat. > > > > I like this options: > > > > - highlighting the Activities button (hey, missing notifications is activities > > to do.) > > - ... or... simply highlight the "message" icon in top panel > > - have a queue of notifications in Dash. > > May be a border glow in button of screen like this animation: > http://i.imgur.com/bhh9C.gif I like that border glow a lot. :D
sirex and I have a similar idea but my involes removing the message-tray and adding a speech-bubble at the top instead. I also agree with what wrobell is saying about all that nasty idle & timing algorithms you suggest. The simplest solution is often the best. I also don't like when people speak for others - speak for yourselves or refer to some kind of study - like what Mozilla does to find out usage patterns. It seems like everyone here has major epilepsy since flashing is always considered bad. I kind of like flashes, they can be slow and smooth. Windows 7 also does that. (I used to use Windows 7)
Wrobel: in 3.2 IM status and desktop notifications are separated: we can be available and still disable notifications. My 2 cents here: * when we disable desktop notifications we are sure to miss them. In this case highlighting the status menu makes sense. Clicking on the menu should highlight the "notifications" switch which is disabled and reveal the message tray. * When notifications are not disabled, it gets harder to make a connection between the status menu and notifications, but having some visual feedback in the top panel still seems to be the most attractive way for me. Highlighting the bottom right hot corner also makes sense (but I do NOT want it to be highlighted if I decided to disable notifications). This should of course also depend on notifications hints.
*** Bug 662357 has been marked as a duplicate of this bug. ***
I'd like to tell my story about it too. I love the "not getting in the way" thing, I totally understand it and support it. Problem is, the "missing incoming messages" happens to me not only when I'm AFK or distracted, it also happens when I'm focused on my task. I see the notification, but I'm so focused on what I'm doing that I forget about it instantly. Which in the end equals missing it. I like the idea in the comment 42 a lot. Please look into into it. Maybe it could, at least, exist as an extension.
I also favor the suggestion in comment 42. The bottom notification bar doesn't make much sense to me. It's easy to inadvertently trigger when using the bottom right in an application. Why not just merge it's functionality into the top bar? There's tons of free space up there that is mostly wasted. My tweak is to allow users to make it more visible. Use a standard cutout-type icon that's a single color. Make it glow from black to a chosen color. User that don't want to be bothered can pick a darker "flash" color, so they're not distracted. Users like me, who want to be constantly notified about incoming messages, would pick something like red or yellow. Do a simple glow effect to transition between the two. I made a switch to Gnome-Shell (3.2) at work last week after rewriting several of our business applications to work properly in Linux. This week I'm back to OS X because of the message tray. I keep missing Empathy notifications. My coworkers are irritated at me and think that I'm ignoring them. I understand the desire to avoid nagging users, but some of us need that capability. Gnome-Shell stands apart from every DE that I've ever used on any operating system. There desperately needs to be some way to persistently show some notifications. A simple glowing icon on the top bar would do wonders for usability.
*** Bug 663046 has been marked as a duplicate of this bug. ***
Just missed a notification. In my case I'm on a multi-monitor display, and my attention wasn't any where the notification while it was up. It went down, I was never really idle, so it never came back. (At least I think this is what happened... I never saw the notification come up or go away so it's hard to be sure :) )
You could also do something like Android / iOS and have the top bar dragged down for notifications. Hint, hint :P
A bit of another "me too". I tend to be very focused at the task at hand, and being able to glance over at something now and then to see if something is waiting would be a very important feature to me. I agree it should be unobtrusive, so any major UI elements is out. Something in the bottom right corner seems sensible as that is where you actually get at the notifications. An animation seems unsuitable as movement is something our brain actively picks up on and hence can be very distracting. I'd rather see something static in the corner. Some composition of the relevant icons, or a general notification icon. A stilised white bell on a black gradient perhaps? Relevant, sober, and discrete.
*** Bug 663969 has been marked as a duplicate of this bug. ***
You already know the small visual effect you see when you move the mouse in the top-left part of the screen? I mean the small circles fading... well! You could display the same visual effect in the bottom-right part of the screen, until the user actually move the mouse in thatdirection. In this way the user doesn't risk to have unread messages for hours. The small visual effect is not intrusive. What do you think about?
(In reply to comment #54) > In this way the user doesn't risk to have unread messages for hours. The small > visual effect is not intrusive. There is a huge difference between a short visual effect done in response to a user action (top corner) and an ongoing visual effect done until the user performs some action (proposed effect).
(In reply to comment #55) > (In reply to comment #54) > > In this way the user doesn't risk to have unread messages for hours. The small > > visual effect is not intrusive. > > There is a huge difference between a short visual effect done in response to a > user action (top corner) and an ongoing visual effect done until the user > performs some action (proposed effect). Florian, what is the problem with the solution I just proposed? It would be a nice effect.. I really would like to have it. Why don't you make it optional/configurable if someone don't like it and prefer it quiet? Bu really... we cannot keep missing messages like this :\
(In reply to comment #56) > Florian, what is the problem with the solution I just proposed? It would be a > nice effect.. I really would like to have it. Why don't you make it > optional/configurable if someone don't like it and prefer it quiet? Bu > really... we cannot keep missing messages like this :\ The Shell's philosophy is precisely against nagging the user until he performs an action. The effect could be shown once, but it you repeat it, you force people to react, and they may have reasons not to care. Making it configurable is not a solution either: you'd require users that don't care to go to some obscure control panel and disable this? We need a solution that works for everybody, or it will only be implemented as an extension.
(In reply to comment #57) > (In reply to comment #56) > > Florian, what is the problem with the solution I just proposed? It would be a > > nice effect.. I really would like to have it. Why don't you make it > > optional/configurable if someone don't like it and prefer it quiet? Bu > > really... we cannot keep missing messages like this :\ > The Shell's philosophy is precisely against nagging the user until he performs > an action. The effect could be shown once, but it you repeat it, you force > people to react, and they may have reasons not to care. > > Making it configurable is not a solution either: you'd require users that don't > care to go to some obscure control panel and disable this? We need a solution > that works for everybody, or it will only be implemented as an extension. well.. you could do the contrary: add an option for people that want to enable this feature and keep it disabled by default. Or please someone implement this an extension, but please someone do it :S
I think we might be getting lost in the details of specific proposals. What most users that are missing messages are contending that we need a persistent, static and unobstructive visual indication that there are unread messages waiting, but I don't see any developers agreeing with this sentiment. Whether that is a static ripple in the bottom-right corner, a highlighted activities button, or an envelope in the status area is largely irrelevant. Short of tracking the user's eye movements, it's simply impossible to guess whether the user has noticed a particular message. Frankly, the idea that the current implementation is less distracting than the alternatives is laughable: I've really tried giving this a chance, but now I find myself constantly interrupting my workflow to check if there are any messages waiting, yet I still frequently don't notice messages or emails until much later. And to add insult to injury, it looks like (bug #636117) the developers are trying to make it even harder to check the status of the message tray and leave keyboard, touchscreen and tablet pc users out in the cold.
(In reply to comment #56) > Florian, what is the problem with the solution I just proposed? There are two reason why users may not act on a notification: (1) they missed it (2) they actively chose to not deal with it right now Your proposal addresses (1) at the cost of (2) - nagging the user constantly until (s)he performs some action would mean that we could just keep the notification open in the first place. A proper solution would tie the hiding behavior to user activity, e.g. only hide the summary when mouse or keyboard activity indicates that the user has seen the notification, but does not want to deal with it right now (this probably includes detecting mouse movement towards the message tray) Adding an option is a poor workaround, as it forces people to choose whether (1) or (2) is more important to them, rather than working for both cases.
(In reply to comment #60) > (In reply to comment #56) > > Florian, what is the problem with the solution I just proposed? > > There are two reason why users may not act on a notification: > > (1) they missed it > (2) they actively chose to not deal with it right now > > Your proposal addresses (1) at the cost of (2) - nagging the user constantly > until (s)he performs some action would mean that we could just keep the > notification open in the first place. the time the user in case (2) would spend simply moving the mouse in the bottom part is a fraction of the time the other users spend to constantly check the bottom tray because they suppose to have missed some messages. I'm spending lot of time moving the mouse down because I think "and if someone wrote me?". Once again: I could say that if the user doesn't want any notification he could set his status to OFF, but I propose again a simple setting "Blink bottom bar for unread notification" and set it OFF by default, so we'll spend just a minute to enable it and other users would not be bothered by unwanted blinking. > A proper solution would tie the hiding behavior to user activity, e.g. only > hide the summary when mouse or keyboard activity indicates that the user has > seen the notification, but does not want to deal with it right now (this > probably includes detecting mouse movement towards the message tray) that's it! The use simply move the mouse down and the notification stops blinking. Is it too hard to implement? Just like you show the traybar when the user move the mouse down, you can also call a stopBlinkingNotification() method. > Adding an option is a poor workaround, as it forces people to choose whether > (1) or (2) is more important to them, rather than working for both cases. I don't think so.. and at least we would fix this problem. Better than nothing, isn't it? Anyway we must take a decision. I really don't care which implementation we're going to use, neither where you decide to show the notification, but please: show it somewhere. Thanks.
> The Shell's philosophy is precisely against nagging the user until he performs > an action. The effect could be shown once, but it you repeat it, you force > people to react, and they may have reasons not to care. The catch with this philosophy is that sometimes my computer is just better than me at knowing what I have to do. I program it with todo-lists and reminders. It knows when I have an important meeting coming up. It knows I have messages queued up to deal with, and it knows which ones are important enough to deserve my attention (either because I've designed filters to tell it which events qualify, or because it's learned from my behavior, as in Gmail's "important" flag). In this scenario, I for one *really do* want the shell nagging me until it's convinced that I've dealt with the notification.
> A proper solution would tie the hiding behavior to user activity, e.g. only > hide the summary when mouse or keyboard activity indicates that the user has > seen the notification, but does not want to deal with it right now (this > probably includes detecting mouse movement towards the message tray) That's a great and lofty goal, but right now we're just not good at detecting whether or not a user has seen the notification. Until such time as we have really good intelligence to act on (either cues from mouse/keyboard response, or eyeball-tracking, or whatever), the only source of information the shell has to tell whether the user has dealth with the notification is simply whether or not the user has specifically told the shell it is so.
(In reply to comment #60) > A proper solution would tie the hiding behavior to user activity, e.g. only > hide the summary when mouse or keyboard activity indicates that the user has > seen the notification, but does not want to deal with it right now (this > probably includes detecting mouse movement towards the message tray) There are just so many things wrong with this: 1. It just won't work. No matter how smart your are trying to be, it's not possible to decide if a user has noticed a particular message. All you're going to accomplish by implementing some elaborate scheme to interpret user activity is to confuse users who now have no clue why the message (tray) stays open sometimes and sometimes doesn't. 2. It raises privacy concerns to leave messages open indefinitely. When I'm, say, meeting with a student and the student happens to look in the direction of my screen the moment I receive a new message, that's obviously not a big deal, but if the message is there on my screen for the whole time of the meeting for everybody in the room to see, that's a different story. 3. Without resorting to polling, it is not possible for a wm to detect mouse movements in X11. 4. I don't know about you but I don't perceive the blue envelope that ubuntu/unity shows when new messages are waiting as 'nagging'.
(In reply to comment #62) > In this scenario, I for one *really do* want the shell nagging me until it's > convinced that I've dealt with the notification. This case is already handled correctly: that's called "Urgent notifications", and they stay in the bottom of the screen until you click on them. In other cases, the computer doesn't know what you want to do with the notifications.
(In reply to comment #65) > This case is already handled correctly: that's called "Urgent notifications", > and they stay in the bottom of the screen until you click on them. In other > cases, the computer doesn't know what you want to do with the notifications. No, it is not. Unless every "new message" notification that I have received is for some reason not considered urgent, no notification is persistently visible on the bottom of my screen. There must be an indication of its existence visible *at all times* until I confirm that I have seen it, with whatever method.
(In reply to comment #66) > No, it is not. Unless every "new message" notification that I have received is > for some reason not considered urgent, no notification is persistently visible > on the bottom of my screen. What is your distribution and GNOME version?
Fedora 15 x86_64, somewhere between GNOME 3.0.0 and 3.0.2 as I'm not which package version to check.
(In reply to comment #64) > (In reply to comment #60) > > A proper solution would tie the hiding behavior to user activity, e.g. only > > hide the summary when mouse or keyboard activity indicates that the user has > > seen the notification, but does not want to deal with it right now (this > > probably includes detecting mouse movement towards the message tray) > > There are just so many things wrong with this: > > 1. It just won't work. No matter how smart your are trying to be, it's not > possible to decide if a user has noticed a particular message. All you're > going to accomplish by implementing some elaborate scheme to interpret user > activity is to confuse users who now have no clue why the message (tray) stays > open sometimes and sometimes doesn't. you don't have to "guess" it, just consider this: moving the mouse in the botto-right part of the screen = I'm aware that there are new messages > 2. It raises privacy concerns to leave messages open indefinitely. When I'm, > say, meeting with a student and the student happens to look in the direction of > my screen the moment I receive a new message, that's obviously not a big deal, > but if the message is there on my screen for the whole time of the meeting for > everybody in the room to see, that's a different story. you don't have to keep the messages open: just "pulse" a graphic effect in the bottom-right corner, a very small graphic effect. That's it. Small, useful and nice to see. Non intrusive at all. > 3. Without resorting to polling, it is not possible for a wm to detect mouse > movements in X11. how do you detect that mouse is in the bottom-right corner when you show the tray bar? Just call the stopPulsingNotify() or whatever too... easy. > 4. I don't know about you but I don't perceive the blue envelope that > ubuntu/unity shows when new messages are waiting as 'nagging'. the blue envelop would not fit our situation, because if the user sees a blue notice in the top-right corner, he expects the notification to be there, instead it will be in the bottom-right.
(In reply to comment #60) > A proper solution would tie the hiding behavior to user activity, e.g. only > hide the summary when mouse or keyboard activity indicates that the user has > seen the notification, but does not want to deal with it right now (this > probably includes detecting mouse movement towards the message tray) No it's not. I have a large screen and I do miss mail notifications because I focus (i.e. typing constantly) on the part of the screen that's far from the bottom edge. The proper solution would be eye focus tracking, if you could do that with regular computers.
I really don't like idea, that gnome-shell are going to decide, what I want and what I don't... Now gnome-shell has user menu, where I can set if I'm busy or available. If busy option is selected, then I agree, that all notifications should be much less visible. But if I select, that right now I'm not busy, then I do want to see all notifications instantly, with some smooth animation, until I take attention to them. Let users decide for him self if they want be disturbed or not. There are too many cases to decide this for user.
(In reply to comment #60) > (In reply to comment #56) > > Florian, what is the problem with the solution I just proposed? > > There are two reason why users may not act on a notification: > > (1) they missed it > (2) they actively chose to not deal with it right now In this case (2), user should just turn off the notification switch.
(In reply to comment #72) > (In reply to comment #60) > > (In reply to comment #56) > > > Florian, what is the problem with the solution I just proposed? > > > > There are two reason why users may not act on a notification: > > > > (1) they missed it > > (2) they actively chose to not deal with it right now > > In this case (2), user should just turn off the notification switch. No: "You have new mail from foo-list" - I'll deal with it later "You have new mail from bar" - Oh, I'll read it right now The notification switch is an all-or-nothing solution, the decision to react on a notification now or later is not.
I really think that if someone doesn't start coding an extension for this feature, we'll never see this bug fixed :\ Let me see that this "I want it" vs. "I don't want it" is non sense. There should simply be an option for it, that's all. Then YOU decide which value must be the default one, and I can accept it and understand it, but the option there should exist. Again: a very small visual effect "pulsing" in the very bottom-right corner would not disturb anyone at all. You don't like it? Ok, give an option to enable/disable it. What's the problem?
(In reply to comment #74) > Again: a very small visual effect "pulsing" in the very bottom-right corner > would not disturb anyone at all. You don't like it? Ok, give an option to > enable/disable it. > > What's the problem? No problem. But what you call "options" in the Shell is implemented as extensions. The default experience only provides features that most users won't need to disable.
You cannot satisfy everyone by default. It's not possible. I hate the nagging notification about inserted memory sticks. I diasbled it. I'm happy. Some kind of slow smooth pulsing is by far the best solution(if you are going to keep the current message tray). (In reply to comment #14) > http://i.imgur.com/bhh9C.gif Andrea Grandi has some good opinions on pulsing. * When you get some kind of notification it starts to pulse. * If you want to ignore it you slide the cursor to the bottom right corner and it stops. * If you want to handle it you do the same but actually handles the notification by reading it or whatever. * If you don't want pulsing you either disable it in the system settings or set your status to busy. This is my opinion if you are going to keep the current message tray. Otherwise you could have a counter in the top bar displaying a total of all notifications and have it drop down to a bubble as described in comment #42 (but with the flashing replaced by a static counter of total notifications.
"* If you want to ignore it you slide the cursor to the bottom right corner and it stops." That's not ignoring it, that's interacting with it. I think that's against what GNOME 3's design is aiming for when it comes to distraction-free computing. I am happy with the current design, if I go idle, then when I return the message tray pops up for a few seconds showing me any notifications I have missed. When I installed Ubuntu, the idle time for this feature was disabled, that may have been caused by my method of installation, or maybe it's a bug, somebody should check if they have the same issue with Ubuntu. The idle time should be set to 10 mins by default, but I needed to change it to 3 mins to be of any use. After changing that, I am quite pleased with the experience. If anybody else wants to change this value, open dconf-editor, then navigate to org/gnome/desktop/session, and change idle-delay to the number of seconds you want for it to consider you idle. Perhaps it might be an idea to reduce the default idle time though, I find 10 mins too long. If I just go to grab a drink or something taking 5 mins or less, then it obviously doesn't work. As I said, I've found 3 mins to be a good time.
(In reply to comment #77) > "* If you want to ignore it you slide the cursor to the bottom right corner and > it stops." > > That's not ignoring it, that's interacting with it. I think that's against what > GNOME 3's design is aiming for when it comes to distraction-free computing. Except sometimes the communication (incoming IM messages) is the very point of computing. It's common for me to miss incoming messages while working with a remote team. These messages are a crucial part of what I do, not a mere distraction. > I am happy with the current design, if I go idle, then when I return the > message tray pops up for a few seconds showing me any notifications I have > missed. What about the messages you miss while using the computer? I am rarely idle and I miss a large fraction of the messages. Even more since switching to a 1920×1080 display. A separate issue is working with maximized apps when trying to click near the bottom of the window causes you to accidentally dismiss the notifications.
(In reply to comment #77) > "* If you want to ignore it you slide the cursor to the bottom right corner and > it stops." > > That's not ignoring it, that's interacting with it. I think that's against what > GNOME 3's design is aiming for when it comes to distraction-free computing. > > I am happy with the current design, if I go idle, then when I return the > message tray pops up for a few seconds showing me any notifications I have > missed. > > When I installed Ubuntu, the idle time for this feature was disabled, that may > have been caused by my method of installation, or maybe it's a bug, somebody > should check if they have the same issue with Ubuntu. > > The idle time should be set to 10 mins by default, but I needed to change it to > 3 mins to be of any use. After changing that, I am quite pleased with the > experience. If anybody else wants to change this value, open dconf-editor, then > navigate to org/gnome/desktop/session, and change idle-delay to the number of > seconds you want for it to consider you idle. > > Perhaps it might be an idea to reduce the default idle time though, I find 10 > mins too long. If I just go to grab a drink or something taking 5 mins or less, > then it obviously doesn't work. As I said, I've found 3 mins to be a good time. This is simply not a sufficient solution. If I look away for a second and a notification occurs, and I look back, I have no idea that I missed one because I did not go idle. If I do go idle and come back, but look away just after unlocking my screen, then I miss them. The simple fact is, these applications are designed to change their tray icon to indicate that new messages are waiting. This fact must be shown persistently, whether by displaying the icon and not hiding it, or by the envelope icon mentioned before (which I think is an acceptable compromise). There is no need for an animated indication, but since there is only one panel in GNOME 3 that is persistently visible, then as far as I can tell the notifications must be indicated here.
(In reply to comment #77) > "* If you want to ignore it you slide the cursor to the bottom right corner and > it stops." > > That's not ignoring it, that's interacting with it. I think that's against what > GNOME 3's design is aiming for when it comes to distraction-free computing. > > I am happy with the current design, if I go idle, then when I return the > message tray pops up for a few seconds showing me any notifications I have > missed. > > When I installed Ubuntu, the idle time for this feature was disabled, that may > have been caused by my method of installation, or maybe it's a bug, somebody > should check if they have the same issue with Ubuntu. > > The idle time should be set to 10 mins by default, but I needed to change it to > 3 mins to be of any use. After changing that, I am quite pleased with the > experience. If anybody else wants to change this value, open dconf-editor, then > navigate to org/gnome/desktop/session, and change idle-delay to the number of > seconds you want for it to consider you idle. > > Perhaps it might be an idea to reduce the default idle time though, I find 10 > mins too long. If I just go to grab a drink or something taking 5 mins or less, > then it obviously doesn't work. As I said, I've found 3 mins to be a good time. You're missing the point here. People are missing notifications while they are NOT idle. That may sound crazy to you, but with a big screen, or with a big focus on another part of the screen, it's actually very easy to not see or to skip notifications popping up on the bottom of the screen. It also happens that I'm focussed on a task, I get a notification, I see it but I decide to ignore it because I'm in the middle of something important. 2 mins later, my important task is over, but the memory that I recieved this notification is also gone. I need something, that don't stand in my way, but also let me know at any time if I have a new message, without having to manually check. The waves waiting till interaction in the bottom right corner sounds fine for me.
People have suggested about three kinds of solutions till now: 1. Show some kind of static notification in the top panel. 2. Show some kind of pulsing / highlighting / symbol to notify that you should look in the lower panel. 3. Do some magic ninja algorithm to determine if the user is idle / is looking at the notification or whatever. The third solution is just silly. I saw some guy actually mentioning eyeball tracking. Seriously? Come on! The whole idea of having a lower panel that is not only hidden when you want to see it, but also is popping up and distracting when you don't want it is just a bad idea. (In reply to comment #78) > A separate issue is working with maximized apps when trying to click near the > bottom of the window causes you to accidentally dismiss the notifications. It's not just me that find the bottom panel popping up when trying to click the lower part of a window. The second solution may work using pulsing or stuff but you obviously don't like that. The first solution is the only one that can be implemented without people being distracted. You can have a pulsing envelope, you can have a static envelope, you can have a static counter or you can have a drunken santa flashing his wiener. Whatever.
I agree with a09alehu about auto-hide. I have always hated any UI element that auto-hides because: 1. I can't see the information when I want to. 2. When aiming for something nearby, overshooting causes it to pop up and hide what I am aiming for. 3. When aiming for something on the autohide bar after making it visible, overshooting causes it to disappear again, and I have to repeat the entire process of making the bar visible, etc. I would be very happy if I could make the notification area always visible for those reasons, but it would also nicely solve the problem of missed notifications. No flashing or pulsing required, no UI element in the top bar when notifications are at the bottom, etc. If I'm stuck with auto-hide, then I want something that stays visible until I've dealt with the notification (not just acknowledged that it's there, or I'll forget to come back to it later). Anything that pulses or flashes would definitely distract me. I would prefer something static but always visible - icon in the top bar, whatever.
(In reply to comment #82) > I would be very happy if I could make the notification area always visible for > those reasons, but it would also nicely solve the problem of missed > notifications. No flashing or pulsing required, no UI element in the top bar > when notifications are at the bottom, etc. forcing the visibility of the tray bar can be annoying for this reason (I will do just an example but you can find many): the tray bar covers the bottom part of the screen/application, if I've to press a button that is in the bottom part of the application I cannot do it. Suppose you're playing World of Warcraft in the mean time ;) (ok... very particular example, but you understand...) > If I'm stuck with auto-hide, then I want something that stays visible until > I've dealt with the notification (not just acknowledged that it's there, or > I'll forget to come back to it later). Anything that pulses or flashes would > definitely distract me. I would prefer something static but always visible - > icon in the top bar, whatever. as you said, the top bar is not the proper place to show this, because we would have the notification on top and the message at the bottom: very very confusing! What I'd like to realize is a small extension that catches the arrive of a message and shows a very small visual effect in the bottom-right corner (a very little one). In this way, without touching mouse or keayboard, but just with a rapid look, you can see if there are any unread messages/events. The problem is: I've never written a Gnome Shell extension before... JavaScript doesn't scare me, but I don't know how to interact with Gnome parts and catch the events. I'll have to study this a bit. Any help is welcome!
(In reply to comment #83) > > The problem is: I've never written a Gnome Shell extension before... JavaScript > doesn't scare me, but I don't know how to interact with Gnome parts and catch > the events. I'll have to study this a bit. Any help is welcome! I've been investigating a little. Example ripple effect from the top left corner in: /usr/share/gnome-shell/js/ui/layout.js Notifications are handled in /usr/share/gnome-shell/js/ui/notificationDaemon.js IM Notifications are handled in /usr/share/gnome-shell/js/ui/telepathyClient.js I'd say you'd have to declare the ripple effect in layout.js and trigger it in notificationDaemon.js or telepatyClient.js, depending on if you want to show the ripple effect only for IM or for all notifications. I don't have much more time to look further into it. Good luck!
(In reply to comment #84) > (In reply to comment #83) > > > > > The problem is: I've never written a Gnome Shell extension before... JavaScript > > doesn't scare me, but I don't know how to interact with Gnome parts and catch > > the events. I'll have to study this a bit. Any help is welcome! > > I've been investigating a little. > Example ripple effect from the top left corner in: > /usr/share/gnome-shell/js/ui/layout.js > > Notifications are handled in > /usr/share/gnome-shell/js/ui/notificationDaemon.js > > IM Notifications are handled in > /usr/share/gnome-shell/js/ui/telepathyClient.js > > I'd say you'd have to declare the ripple effect in layout.js and trigger it in > notificationDaemon.js or telepatyClient.js, depending on if you want to show > the ripple effect only for IM or for all notifications. It's even easier than that: the MessageTray tray handles all notifications. You can get to it with Main.messageTray. > I don't have much more time to look further into it. > > Good luck!
(In reply to comment #85) > It's even easier than that: the MessageTray tray handles all notifications. You > can get to it with Main.messageTray. even if it's correct, isn't the MessageTray part of the Gnome Shell core? From what I can read they don't want to include this feature in the core but implemented as extension, so we have to write it as an extension if we want to have a chance to make it work.
(In reply to comment #83) > forcing the visibility of the tray bar can be annoying for this reason (I will > do just an example but you can find many): the tray bar covers the bottom part > of the screen/application, if I've to press a button that is in the bottom part > of the application I cannot do it. Suppose you're playing World of Warcraft in > the mean time ;) (ok... very particular example, but you understand...) If it didn't auto-hide, obviously it would not display over top of applications but rather reduce the space available for windows by the height of the panel. Just like the top panel does, or Gnome 2 panels.
Hello everybody: While I'm mostly comfortable with the current notifications behaviour (and it is true that I have also missed some messages), as far as I remember, the gnome devs said that the wanted to make the IM a "first class citizen", and since it seems that the only reason to change the notifications and message tray behaviour is the IM notifications, why not give them an actuall special treatment and made it (along with the IM a more important gnome-shell citizen). What I'm thinking of is to split the user menu in two: the icon for one part and the name for the other. the name would behave as it does nowadays, and the icon could have a counter (nothing blinking please), and when clicked, it could simply show who has talket to you, and how many messages he has sent to you, your status, and maybe also a very simplified version of the contact list (status and nick, for example). Here is the mandatory image: http://img256.imageshack.us/img256/9909/63736508.png (Of course I think this is compatible with the inline chat notifications) What do you thik?
For those looking for a quick (and dirty) extension, Marco wrote one: http://blog.barisione.org/2011-11/permanent-im-notifications/
These notifications are a true issue: - We miss important messages (all my co-workers switched to XFCE because of this) - The messages bubbles are a privacy issue (and if I disable notifications, people stop to talk to me because I'm shown busy, there is no way to disable them while being shown available on 3.2 arch linux) - These notifications are disturbing my work because they are animated and hide a part of my window. They even show up when I'm using a full screen Totem! - I often open the tray accidently when I want to access some gtk widget at the bottom of my window Please stop ignoring these issues. I understand the philosophy of GNOME3, so I'm sure that these disturbing and unefficient IM notifications are a bug and the whole thing should be rethinked.
Created attachment 201929 [details] Comment 42. Variant of sirex's solution. No bottom panel.
Created attachment 201931 [details] Another, more touch oriented solution (I like this the most)
(In reply to comment #92) > Created an attachment (id=201931) [details] > Another, more touch oriented solution (I like this the most) I like it (I'd display a counter next to the Activities like the one on icons). Bonus points if people you chat with get separate icons in dock as well (and please, generate some temporary avatars for people who don't have one so we can tell them apart).
(In reply to comment #93) > (In reply to comment #92) > > Created an attachment (id=201931) [details] [details] > > Another, more touch oriented solution (I like this the most) > > I like it (I'd display a counter next to the Activities like the one on icons). > Bonus points if people you chat with get separate icons in dock as well (and > please, generate some temporary avatars for people who don't have one so we can > tell them apart). Yes this is just a basic idea that could be modified in a number of ways. What I'm really trying to do is get rid of the bottom panel. That is one of the things I really hate about GNOME 3. Using the solution in comment 92 would mean the same number of gestures to complete a task. (slide cursor to upper left corner & click notification vs slide to bottom right & click notification)
Created attachment 201937 [details] Another, more touch oriented solution (I like this the most) #2
Contacts should be top-level objects, not subobjects of Empathy. Overview shows them as first class citizens.
Well, I think that a09alehu@student.his.se 's proposal is very interesting. Why do we need duplicated icons (in the dock and in the message tray) for a notification when only the dock can do it? (thinking on a new evolution mail, or the rhythmbox message icon, for example) (although , IMHO, the notification counter would be better placed near to the activities button, instead of in the right side of the top panel. And, even knowing that this has been discussed, I still think say that having notification counters on the icons in the Alt+TAB switcher would be an improvement (at least is another way of noticing a pending notification))
Created attachment 201971 [details] Touch oriented solution (Ipad / Android) (#3)
It's basically about merging the bottom panel to the dock and adding a static notification counter to the top bar. Everything is controlled from Activities.
Created attachment 201972 [details] Touch oriented solution (Ipad / Android) (#4) Haha sorry for spamming this thread but I had to fix the icons :)
Another option would be to make the bottom panel persistant like the top panel.
(In reply to comment #101) > Another option would be to make the bottom panel persistant like the top panel. Yes but then you will lose screen space. Also, it's ugly.
I agree but it is the only solution I found so far to keep all the IM integration that is already coded and working, like for exemple the chat bubbles. With your proposal, all these features will have to be removed and be replaced with something more empathy oriented, isn't it?
(In reply to comment #103) > I agree but it is the only solution I found so far to keep all the IM > integration that is already coded and working, like for exemple the chat > bubbles. > With your proposal, all these features will have to be removed and be replaced > with something more empathy oriented, isn't it? I thought about this and I don't believe you need to remove anything really. It depends on how they want it to work. What is the purpose of those chat bubbles? Is it only for quick respond (then you just respond at the bottom as usual when someone writes to you), or is it something like a second theme to the chat? It's not that hard to solve, just add some entry in the jump-list like "Open in bottom" or whatever. This is application specific really. How do the Empathy team want their client to work? Currently it opens up that shell-style-chat by clicking the chat session in the bottom panel. It doesn't have to be activated exactly like that. You can bring that shell-style-chat any other way really. Currently: Bottom right corner, click session, chat in shell-style or: Bottom right corner, doubble click session, chat in the real window This can really be as simple as having a simple button in the chat window to switch between shell style and normal style. When you respond directly to the message it's shell style (as it's currently) It's all about thinking outside the sphere. It can be solved really in any way. Having two panels will surely solve it but then you are just going back to GNOME 2 and not evolving.
Or just drag the chat window to stick it to the bottom and chat in shell-style. Whatever solution works.
(In reply to comment #105) > Or just drag the chat window to stick it to the bottom and chat in shell-style. > Whatever solution works. Notifications and stuff are a central piece of an GUI. My proposal is kind of a big change but I really think it can work in a great way once it matures. Look at KDE 4.0 and compare it to KDE 4.7. It takes time to form a masterpiece. * merge bottom panel to dock * add static counter to activities button * change some behaviour in Empathy and other apps to match this proposal Have an awesome GUI that saves screen space, looks tight, doesn't distract people yet gives them an obvious way of interacting with apps and it's notifications. :)
In a previous message, you say "This is application specific really. How do the Empathy team want their client to work". But one of the big step of gnome3 is that IM is so integrated to the shell so far that you can even not have empathy installed or launched, the chat works anyway. The contacts and the chat bubbles have been taken out of empathy. How are you going to display your number in the dock if there is no empathy icon?
(In reply to comment #107) > In a previous message, you say "This is application specific really. How do the > Empathy team want their client to work". But one of the big step of gnome3 is > that IM is so integrated to the shell so far that you can even not have empathy > installed or launched, the chat works anyway. The contacts and the chat bubbles > have been taken out of empathy. How are you going to display your number in the > dock if there is no empathy icon? Implementation is not a problem. Just display an icon if you want one. Empathy is just a Gtk3 app. Shell doesn't hande chat stuff. Thats all in Empathy using Gtk3. I'm no expert in GNOME code but I'm and expert programmer in general. Empathy is just an application.
Re-read comment #107 - with GNOME 3.2 you can do all the IM stuff (well, not group chats) without actually running Empathy.
Created attachment 201989 [details] This is my complete proposal. Touch, no tray. Static. Inspiration to the GNOME team.
(In reply to comment #108) > (In reply to comment #107) > > In a previous message, you say "This is application specific really. How do the > > Empathy team want their client to work". But one of the big step of gnome3 is > > that IM is so integrated to the shell so far that you can even not have empathy > > installed or launched, the chat works anyway. The contacts and the chat bubbles > > have been taken out of empathy. How are you going to display your number in the > > dock if there is no empathy icon? > > Implementation is not a problem. Just display an icon if you want one. Empathy > is just a Gtk3 app. Shell doesn't hande chat stuff. Thats all in Empathy using > Gtk3. I'm no expert in GNOME code but I'm and expert programmer in general. > Empathy is just an application. Well... actually... Gnome DOES handle chat stuff. I'm pretty sure you can delete empathy from your machine and still be able to chat through the shell. The shell reimplements a "full" IM client, with bubbles, notifications, the contacts app, and the ability to search contacts in the "Activities view" (How is this view called?)
(In reply to comment #110) > Created an attachment (id=201989) [details] > This is my complete proposal. Touch, no tray. Static. Inspiration to the GNOME > team. When a notification comes, how do I know it? Will the "activities" button flash or the dock show up (without bringing the whole overview mode)? What does "9" near "Activities" button mean? The number of unread notifications?
(In reply to comment #111) > (In reply to comment #108) > > (In reply to comment #107) > > > In a previous message, you say "This is application specific really. How do the > > > Empathy team want their client to work". But one of the big step of gnome3 is > > > that IM is so integrated to the shell so far that you can even not have empathy > > > installed or launched, the chat works anyway. The contacts and the chat bubbles > > > have been taken out of empathy. How are you going to display your number in the > > > dock if there is no empathy icon? > > > > Implementation is not a problem. Just display an icon if you want one. Empathy > > is just a Gtk3 app. Shell doesn't hande chat stuff. Thats all in Empathy using > > Gtk3. I'm no expert in GNOME code but I'm and expert programmer in general. > > Empathy is just an application. > > Well... actually... Gnome DOES handle chat stuff. > > I'm pretty sure you can delete empathy from your machine and still be able to > chat through the shell. > The shell reimplements a "full" IM client, with bubbles, notifications, the > contacts app, and the ability to search contacts in the "Activities view" (How > is this view called?) Never seen. How does it work today? Inspiration, I don't have every possible answer you have to think for your self also. Look at Android and iOS. They does this stuff already and it works just fine. (In reply to comment #112) > (In reply to comment #110) > > Created an attachment (id=201989) [details] [details] > > This is my complete proposal. Touch, no tray. Static. Inspiration to the GNOME > > team. > > When a notification comes, how do I know it? Will the "activities" button flash No. No pulsing. I have written about that before. You should read this thread, I have written about this stuff for some time. > or the dock show up (without bringing the whole overview mode)? > No. > What does "9" near "Activities" button mean? The number of unread > notifications? Yes.
I'm not going to answer every possible question, I don't know. This is stuff that has to mature. You see, I just provided some inspiration. Get inspired. Android and iOS do this. Mac OS X have no tray, just a dock. Windows 7 have no tray just pulsing icons (there is a tray for compatibility ofc... but it's not really needed). Look at how Windows Live Messenger moved from the tray to being a big fat icon that pulses. Tray is so 90s. :)
Hey!? I don't even understand what you mean. You are going way off topic. * What is normally placed in the bottom panel is placed in the dock - compatible? yes! (The dock IS the tray, 100% compatible) * A total of all notifications is shown near the Activities button - compatible? yes! * Individual icons in the dock gets a counter - compatible? yes! (and already implemented in gnome 3.2!) I don't see any sort of connection between moving the tray to the dock and some Empathy-in the bacakground-off topic stuff. What is normally in the tray, shows up in the dock. That stuff about dragging windows to the bottom is just some extra thing. You can do the exact same with menus if you prefer. Read the thread before commenting.
(In reply to comment #115) > The dock IS the tray, 100% compatible It's not. Clicking on an icon in the dock shows the application. Clicking on an notification in the tray shows notification menu. Right click on an item on the dock and the tray (as systray implementation) are also different.
I'm sorry I didn't want to bother you! Maybe what I said was not well expressed enought because my english is not very good. I read all the thread before commenting. Here is my question expressed differently: In your mockup, the number "3" is shown on an icon whowing a smile. This is the empathy icon, if I am right. This icon exists if you installed empathy, and is placed in your dock if you want. So to display this "3", you have to have empathy installed. However, it looks like gnome3 supports IM directly by itself, without the need of empathy being installed. So there may be a case where people have pending messages, without the right icon to display the number of messages next to it. Is it understandable now? I'm not here to work against you, but with you. And I would realy like to see some gnome3 active developpers reacting to all the recent proposals we made because the final result depends a lot of them.
Okay so I got my brain all screwed back in place now. I know what I mean now, haha. I tend to come up with something and then forget it before I even can describe it and then I just write a lot of bullshit. This is what I really have been trying to say, from the beginning :D 1. People (including me) don't seem to like the auto-hide behavior of the bottom panel (the "tray"). 2. People in this thread have talked a lot about a static counter of total notifications to be displayed in the top bar. What I would love to implement / suggest is two very simple and 100% backward compatible modifications to gnome-shell 3.2 to solve these two listed issues. 1. We place that counter everyone have talked about, in the top panel. (enough already :P) 2. The bottom panel is kept only in theory. In GNOME 3.2, developers have already implemented notification counters for notifications. When you have three unread messages in a chat session in Empathy (just an example), the bottom panel have that notification displayed with the number 3 drawn over the icon in question. This is already implemented. What could be done is to draw the contents of the bottom panel into the dock. The exact same content only with bigger icons (obviously). The exact same mouse clicks / touch events done on a notification in the dock calls the exact same it would if the notification was placed in the bottom panel. This way the dock IS the bottom panel, containing both icons representing programs And icons representing notifications. This way we get rid of the bottom panel and it's auto-hide behavior yet keeps an absolute 100% backward compatibility. A bit more clear now? It's actually two very small changes that can be tested as an extension first. If you'd like, I can draw one of those crappy images displaying the result (it's about the same as before but without all that bullcrap I wrote before) ;)
In general: Can everybody please avoid forum-style conversation noise and keep things technical? Thanks in advance!
Created attachment 202015 [details] Yet another illustration
I've a suggestion. I really like how Guillaume describe the 3 kind of notifications in comment 3 and I agree that the problem is only for urgent notification. My suggestion is, if there is an incoming notification waiting and hidden, to have a subtle glow, a kind of halo which would subtly highlight the corner. This would be subtle enough so you can ignore it on purpose but not too much so you cannot miss it. An example of implementation is Docky. If you have auto-hide enabled with Docky but that one application need focus, you will see a red glowing halo from the side of your screen when your Docky bar is. I find that really useful and I use it to not miss any notification in GNOME-shell.
Created attachment 203132 [details] Simple, not animatet notifications indicator. What is wrong with this solution that was used for years?
(In reply to comment #121) > I've a suggestion. > > I really like how Guillaume describe the 3 kind of notifications in comment 3 > and I agree that the problem is only for urgent notification. > > My suggestion is, if there is an incoming notification waiting and hidden, to > have a subtle glow, a kind of halo which would subtly highlight the corner. > > This would be subtle enough so you can ignore it on purpose but not too much so > you cannot miss it. > > An example of implementation is Docky. If you have auto-hide enabled with Docky > but that one application need focus, you will see a red glowing halo from the > side of your screen when your Docky bar is. I find that really useful and I use > it to not miss any notification in GNOME-shell. Pulsing has been shot down 9238462 times in this thread already. (In reply to comment #122) > Created an attachment (id=203132) [details] > Simple, not animatet notifications indicator. > > What is wrong with this solution that was used for years? Great. Someone should implement this now because this bug report is just ridiculous.
I'm doing fine since I use: http://blog.barisione.org/2011-11/permanent-im-notifications/
This thread is long enough I'll keep it short: 1. notifications are messages, why not treat them as such using an inbox-like system? 2. not all users are interested in being notified about the same things or to get a pop up at all in some cases. Why not let the user manage subscriptions from that inbox (e.g. un-subscribe from Banshee notifications)? 3. pop-ups should be distinguished from notification. Notification must be visible otherwise it is pointless 4. the notification / popups should be centralised and clean (right now I need to tell each application separately whether or not it should send notifications and those clutter my tray). The existing Gmail extension could be a good example of how notifications could work imo.
(In reply to comment #125) > [...] > > 2. not all users are interested in being notified about the same things or to > get a pop up at all in some cases. Why not let the user manage subscriptions > from that inbox (e.g. un-subscribe from Banshee notifications)? > > [...] > > 4. the notification / popups should be centralised and clean (right now I need > to tell each application separately whether or not it should send notifications > and those clutter my tray). See https://live.gnome.org/Design/SystemSettings/Notifications
Wouldn't it be possible for someone to create an extension to show an animation in the lower right corner when a notification arrives? I mean something similar to the subtle ripple animation that is displayed in the upper left hot corner when you move your mouse there. That animation could keep on going until you hover the mouse over it which would mute it until a new notification arrives.
(In reply to comment #127) > Wouldn't it be possible for someone to create an extension to show an animation > in the lower right corner when a notification arrives? I mean something similar > to the subtle ripple animation that is displayed in the upper left hot corner > when you move your mouse there. > > That animation could keep on going until you hover the mouse over it which > would mute it until a new notification arrives. The goal of this bug is find a proper solution, not a hack through an extension. Another extension has been mentioned earlier in this bug workarounding it for now.
Created attachment 207020 [details] Propositoin of Status Menu
(In reply to comment #128) > (In reply to comment #127) > > Wouldn't it be possible for someone to create an extension to show an animation > > in the lower right corner when a notification arrives? I mean something similar > > to the subtle ripple animation that is displayed in the upper left hot corner > > when you move your mouse there. > > > > That animation could keep on going until you hover the mouse over it which > > would mute it until a new notification arrives. > > The goal of this bug is find a proper solution, not a hack through an > extension. > > Another extension has been mentioned earlier in this bug workarounding it for > now. Hello, I'm not a programmer or a developer but a long-time user of gnome. I love Gnome shell/3. Here is what I think would be a proper solution to the notificaiton area, that would be logic for me and totally unubstrusive. See the attachement. I see no need for permanent notifications, or blinking stuff. So I would put everything in the status menu, where I think it belongs. And I would remove everything from the status menu that I think has nothing to do with the status (like system settings and online accounts sttings). By the way, I would put all settings in the Activities pane. I could see in the Activities: Windows, Library, Applications and Settings. If there is something new to see in the status menu, one could only make the letters in a different color or make the icon different, or if it would be me, nothing at all. In the status menu, we should be able to change if we are busy, away, etc (see attachment on 2).. and change the text of our status. If the user writes that he is away, (see attachment on 3) the screen should appear to ask if her wants to do something (Lock screen, log off, etc...) That's how I think would be a good way to shut down or reboot the computer: completely integrated with the status. Of course, changing our status would also change the settings of notifications. In contacts, it would be indicated how many contacts are available for instant communication (via chat, videocalls or cellphone). Clicking on it would open the contacts application. From there, we would be able to do whatever we want with the contacts (IM, email, video, skype, facebook, etc...). With that kind of contact application, we don't need the empathy contact list any more. In Messages, shows unread email messages AND chat messages, clicking on it could open evolution to see these messages or compose a new message. However, evolution can not read instant messages, so for now, it could be another category. But I think that logically, chat messages and emails could both be treated only as messages. In Broadcasts, we would see how many notifications there is from twitter, facebook, and other social networking. Obviously, we would be able to set what get notified in the setttigns, kind of how Gwibber does. Clicking on it could open Gwibber. In News, we could see how many feeds or podcasts are unread. Clicking on it could open the feed reader of user's choice. I know, this could not be done for tomorrow, but that would be part of my ideal Gnome 3.
I added the patch for bug 643014 that shows the message tray that has new notifications when the user becomes active if the user was inactive while these notifications were originally shown. This will ensure that the user is always informed by the system about the existence of new notifications.
To be clear, while that may help with the idle/afk case, it's not designed to help with the large-display/multi-monitor/just-too-distracted-by-something-else-to-notice cases, right?
The patch for bug 643014 has landed and it should help the users not miss notifications. Please try it out in 3.4 and reopen this bug if needed. It addresses idle/afk case, and doesn't address large-display, multi-monitor, just-too-distracted case. The goal of the notification system is to not be distractive and there is currently nothing in the design to make the notifications show up more permanently on the screen.
I don't see any reason to try the patch then. I miss notifications several times a day, while I'm not idle or AFK, so this won't help anything.
Until there is a permanently visible indication of new notifications (for new messages) this bug is not fixed.
We already have a clock and date in the top bar, and also network, status, and volume indicators. They're taking space and I can see at them easily just with a small eye movement. I don't understand why these are more important than notifications. I like the idea of having them in the top bar, where I can notice it easily anytime without having to use the keyboard or move the mouse. It could be an alert effect over the status indicator, but if that would confuse someone, I like the idea of showing it in the Activities button, maybe with a notification counter added at the right. Getting notifications right is important to make them useful, and right now they're broken because they're lost too many times.
Hopefully this 3.6 feature should improve things: https://live.gnome.org/ThreePointFive/Features/MessageTrayImprovements
The main problem of current implementation is that is designed to handle _synchronous_ events. I try to explain better what I mean: The current notification implementation works great if you can handle the event just when it arrives. In fact you receive a visual notification, or even a way to respond to chat messages in the moment the notification arrives. After that the user receive no other visual notification, and must actively check for new events making users losing their messages (as showed on this bug report thread). With other words: or you handle the notification event as soon as it arrives, or you can miss it, or worse forgot about it. But notification event are asynchronous and the user should be able to handle it just when they will. So the notification should be visible until the user don't make an action (default "do nothing" for some notification events should be used). This persistent visual notification must be as non-intrusive as possible, so popup message cannot be used for this. For example Apple do this putting a badge with the number of unhandled notification events on the application icon. In Windows ,Gnome 2, and other UI in the systray a new icon or a different icon show the needs of notification. As you can see, in all this interfaces notifications are always _visible_ to the user. For this reasons i think that the current "hide notifications" design is simply broken. In my opinion a good notification system should allow the user to discover new notification events and which application sent them with just a look. Otherwise the user is "forced" (let me pass the term) to handle the notification event, or he risk to forgot about it. As already proposed, i suggest to put an indicator that shows new events. However this solution is not optimal because don't allow to know which application sent a notification event without human action.
I have tied many extensions and in my opinion, best solution is this: https://extensions.gnome.org/extension/150/message-notifier/ But, as extension author describes: http://blog.barisione.org/2012-04/better-notification-support/ there is no single API for message handling, so each application must be adapted manually. Well, at leas, the way, how user is notified about new messages is really efficient, informative and don't disturbing. Also you can turn notifications off, if you like. I think, this should be implemented in gnome-shell core and integrated with everything else more tightly.
That's not saying that there's no single API -- in fact, there is a single API -- libnotify and the notification specification. The checkboxes are just for turning the access to that API in each application on.
With 3.6 I'm not sure it improved, could even be worse... For example, when I'm working (mouse or keyboard activity) the notification briefly appear and gets hidden. When I'm done with what I was doing, nothing on the screen reminds me of the msg, and I just forget. Eventually 2h later I go to activities and maybe I'll see that msg there if I'm paying attention. In practice most of the time I see IM msg when I'm in firefox because facebook tab blinks, and I end up chatting on web page... Since extensions breaks every releases and it's a pain to wait for update, please consider merging https://extensions.gnome.org/extension/150/message-notifier/ into the core of gnome-shell. That's exactly what's needed!
I wonder if putting a small "you've got mail" icon on a corner of app icons in alt-tab helps, assuming users use alt-tab often and the relevant apps are open.
(In reply to comment #142) > I wonder if putting a small "you've got mail" icon on a corner of app icons in > alt-tab helps, assuming users use alt-tab often and the relevant apps are open. It was considered, but sometimes there isn't really a match between the two. What should we put with gnome-shell for individiual chat notifications? Mail notifier if you don't have evolution open? Should alt-tab start evolution for you?
(In reply to comment #143) > (In reply to comment #142) > > I wonder if putting a small "you've got mail" icon on a corner of app icons in > > alt-tab helps, assuming users use alt-tab often and the relevant apps are open. > > It was considered, but sometimes there isn't really a match between the two. > What should we put with gnome-shell for individiual chat notifications? Mail > notifier if you don't have evolution open? Should alt-tab start evolution for > you? I guess you already have an answer for this. For the record, what about the above for notifications that have matching applications and a generic "you've got notifications" fake app icon that would pull the notification tray up for those that are not attached to any running apps?
How about a solution that does not rely on people pressing alt+tab? Even if that was a good place to show it (it's not), the idea of notification is to be non-invasive. When people go to switch apps they are clearly in the middle of something.
What about changing the presence icon in the top bar (the one next to your name) to a red number indicating the number of unread IM messages? That would be a nice way to integrate Marco's very popular extension ( https://extensions.gnome.org/extension/150/message-notifier/ ) which is a must have for people actually caring about their IM messages.
(In reply to comment #146) > What about changing the presence icon in the top bar (the one next to your > name) to a red number indicating the number of unread IM messages? > > That would be a nice way to integrate Marco's very popular extension ( > https://extensions.gnome.org/extension/150/message-notifier/ ) which is a must > have for people actually caring about their IM messages. Oh actually there is already another extension doing exactly that: https://extensions.gnome.org/extension/258/notifications-alert-on-user-menu/
It seems bug #719649 (Message Tray isn't easily discoverable (isn't shown in Activities Overview)) is related to this bugreport. Lots of users (including me) like GNOME 3.4 behavior, when notifications area/message tray is visible in activity overview, see this question for example: http://askubuntu.com/questions/404055/always-show-notifications-in-activity-overview-gnome-shell-3-10
(In reply to comment #148) > It seems bug #719649 (Message Tray isn't easily discoverable (isn't shown in > Activities Overview)) is related to this bugreport. Not really, this bug was filed long before those changes and is as much about the behavior in 3.4 as the one in 3.10 ...
(In reply to comment #147) > Oh actually there is already another extension doing exactly that: > https://extensions.gnome.org/extension/258/notifications-alert-on-user-menu/ Stuff like this (permanent reminder of notifications) really should be part of core Gnome, not some extension that may or may not be maintained in the next version of the shell. I came to this bug report via this page: https://wiki.gnome.org/Design/OS/Notifications Still no mention of users being able to select an option to have that permanent notification in the panel (which is an area that almost never gets obscured, ergo, can be _seen_ at all times). This is _basic_ stuff. Take a look at the "peeking into the drawer" on this page: https://wiki.gnome.org/Design/OS/Notifications/MessageTrayDrawer If I have to _remember_ to look for notifications and then do something about it, it's not much of a notification system, now, is it?
I second the previous poster, having a permanent indication of non-dismissed notifications seems like a natural and basic option for enhancing the "clock-text-area". As it is now, I have to click on that area to see if there are any notifications I forgot to deal with. A gentle little number next to the date would make me happy. :)
(In reply to Erik Hedberg from comment #151) > As it is now, I have to click on that area to see if there are any > notifications I forgot to deal with. A gentle little number next to the date > would make me happy. :) With 3.18, there's a dot next to the date when there's undealt notifications. I think that suffices and this bug can be closed? It's practically impossible to miss notifications now.
The new notifications system is spot on, at least for me. It's gone a long way since the original report. Thanks for all the work!
(In reply to Nirbheek Chauhan from comment #152) > With 3.18, there's a dot next to the date when there's undealt > notifications. I think that suffices and this bug can be closed? It's > practically impossible to miss notifications now. I tested the dot-functionality, and it works as described in https://wiki.gnome.org/Design/OS/Notifications, i.e. when there are three notifications queued up to be displayed any additional notifications get sent directly to notification list and the dot is displayed. So the dot doesn't help you to know if there are any unread notifications, except for notifications with urgency-level critical, they are always indicated by the dot. I would also suggest at least an option to replace the dot with the number of unread notifications (or put the number inside the dot), as that would allow me to see if any new notifications has arrived. Motivating example: I'm working focused on something and get two emails, I see the senders in the pop-up and know that they can wait. I look away from the screen for some time, when I look at the screen again I see there are now three unread notifications, so I check them and see there's now an urgent email.
(In reply to Erik Hedberg from comment #154) > So the dot doesn't help you to know if there are any unread notifications Uhm - the presence of unread notifications is *exactly* what the dot is supposed to indicate. > Motivating example: I'm working focused on something and get two emails, I > see the senders in the pop-up and know that they can wait. When a notification has been shown as banner, it is considered read - so at this point, the number of unread messages in your example is 0. > I look away from the screen for some time, when I look at the screen again I > see there are now three unread notifications Well, no. Another notification banner was shown, so there are now three read notifications in the list, but the number of unread notifications is still 0. However note that banners only time out when there is user activity, so unless your example is "look away from the screen for some time while moving the mouse or typing on the keyboard", the notification would still be on screen on your return.
Thanks for clarifying, I see I should have used non-dismissed instead of unread. I guess what I would like to see is an option to let "read" equate "dismissed" instead of "displayed". Two things I've noticed are: - When I'm focused on my second monitor I don't always notice notifications on the primary monitor. - When I notice a notification while working , I often want to keep focus on what I'm doing and read them later, and would prefer not to have to remember that manually. I understand this is about preference, so I'd just like to put my voice in for an option. And thank you for your work!
This issue is still present in Gnome Shell 2.26. I first thought that "dot next to the clock" would help, but (as described in the design document at https://wiki.gnome.org/Design/OS/Notifications), the dot only appears when an application sends 4 or more notifications in quick succession. It does not appear if all that happens is a transient notification (by the email application, or whatever) being shown and ignored. I have now installed Notifications Alert <https://github.com/hackedbellini/gnome-shell-notifications-alert/> to fox this, now at least I have *some* indication of there being notifications that I did not act on yet. The situation has gotten worse as the systray status icon area gets more and more deprecated -- typically, my main use for the systray was for email and chat applications to tell me that there are unread messages. There does not seem to be a good replacement for that yet. Are there any plans of improving the out-of-the-box situation here?
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.