GNOME Bugzilla – Bug 677216
Don't time out banners when the user is inactive
Last modified: 2012-08-23 11:01:22 UTC
Notification banners hide after a short delay. While this is necessary, it means that it is easy to miss a notification if you are not interacting with the machine, even if you just look away for a moment. This problem can be avoided if we only time out the banners when the user is inactive (ie. there is no keyboard or pointer input). See http://www.youtube.com/watch?v=14z4wdgNF9g#t=0m16s This bug is part of the message tray design update effort: https://live.gnome.org/GnomeShell/Design/Guidelines/MessageTray/#A3.6_Refresh_Proposal
> Don't time out banners when the user is inactive OK. We do that now, though. Marina implemented that. > This problem can be avoided if we only time out the banners when the user is inactive uhhh... Which is it?
(In reply to comment #1) > > Don't time out banners when the user is inactive > > OK. We do that now, though. Marina implemented that. No we don't. If a banner pops up and I don't interact with the system, it will disappear on its own accord. This proposal is to make it stick around until I become active. > > This problem can be avoided if we only time out the banners when the user is inactive > > uhhh... Sorry, typo there. Should have read "This problem can be avoided if we only time out the banners when the user is active".
(In reply to comment #1) > > Don't time out banners when the user is inactive > > OK. We do that now, though. Marina implemented that. > > > This problem can be avoided if we only time out the banners when the user is inactive > > uhhh... > > Which is it? What we currently do is not time them out if they show up when the user is idle. Alan proposes not to start the timeout until the there has been any user interaction after showing the notification (i.e you did not hit the idle timeout yet but you aren't doing anything). Which is of course somehow annoying in specific cases ... Lets say I am watching a movie ... I don't want to have to to randomly move the mouse or press buttons from time to time just to make notifications go away.
I guess I don't understand the difference between the two behaviours? I'm also wondering if we can piggyback on screensaver inhibit in some way.
(In reply to comment #4) > I guess I don't understand the difference between the two behaviours? Current: When you don't do anything for a specific period your session status changes to idle. When a notification pops up in that case the timeout isn't run unless you come back from idle (interact with the system). Proposed: When a notifications pops up the timeout should not start unless the user interacts with the system (moves the mouse or presses a button) regardless of idle state. Ex: You are reading a page in Firefox (and your status is not idle yet) and a notification shows up it should stay there unless you move your mouse or press a button. > I'm also wondering if we can piggyback on screensaver inhibit in some way. We do that with the current idle behavior as it is tied with the session state.
(In reply to comment #5) > Current: > > When you don't do anything for a specific period your session status changes to > idle. When a notification pops up in that case the timeout isn't run unless you > come back from idle (interact with the system). Nope. https://bugzilla.gnome.org/show_bug.cgi?id=643014 http://git.gnome.org/browse/gnome-shell/commit/?id=30ca25e9782f278b1d6ae8051dc83f2c7a4e0465 There's an idle monitor that happens on the span of seconds, now: + if (this._idleMonitorWatchId == 0) + this._idleMonitorWatchId = this.idleMonitor.add_watch(1000, + Lang.bind(this, this._onIdleMonitorWatch));
The current idle behavior is to show the summary when the user becomes active. This bug requests that banners (read: notifications themselves) don't time out while the user is inactive.
Gah, I forgot that it only showed the summary.
Anyway, that solution won't work if we change the message tray to be 48px. I still don't understand the 48px. That seems way too large, especially when you have a small netbook screen that's like 1000x760. The lack of text labels isn't nice either.
This has no relation to the message tray changes. This is about banner showing up. The size of the message tray is irrelevant. Banners do not show inside the message tray.
The current behavior as I understand it is to: - Time the banner out as normally - because the user might be reading or watching a movie - Show the message tray when returning from idle to let the user know that something happened (a 3.4 addition) The other thing that would have to be handled if we started just sticking messages while the user is idle would be queueing - if a bunch of messages came in when the user came idle, how do you show that series of messages without being annoying to the user?
(In reply to comment #11) > The current behavior as I understand it is to: > > - Time the banner out as normally - because the user might be reading or > watching a movie Allan's proposal would work fine provided we take idle inhibit into account (for apps written for GNOME). > - Show the message tray when returning from idle to let the user know that > something happened (a 3.4 addition) Instead of expecting the original messages to be missed and then reviewed, the proposal is to not miss them in the first place. I think this is probably better and more consistent with how notifications are usually seen. > The other thing that would have to be handled if we started just sticking > messages while the user is idle would be queueing - if a bunch of messages came > in when the user came idle, how do you show that series of messages without > being annoying to the user? One form of idle is when the screen guard / lock is in place and we'd like to show selected messages there immediately (optionally). Then when the guard is lifted we could show all the remaining queued notifications in sequence (that weren't displayed on the guard). Another form of idle is where the screen is on, unblanked, and unguarded. Typically a shorter period of inactivity. Going to the bathroom, working on another computer, etc. For this I think there maybe be multiple strategies. Sound and vibration may be useful to alert you when you are nearby and simply looking away. The banner mode is designed to be minimally distracting. This is not an important consideration when the user is idle. Furthermore, if the user is working nearby within sight of the computer it is annoying to have to return to explicitly touch a banner to expand and read it. Better might be to expand the banner by default in this case. This also allows us to show queued messages using the peek. Queuing/peek is partly addressed by bug 677217. We can supplement that behavior with the ability to short cut through the queued messages and bring up the summary / tray when you press against the bottom of the screen with more pressure than what is required to just bring up the next queued message. Hopefully this will help it to not be annoying when there are very many queued messages. This should just work since the design already has this behavior.
Created attachment 219943 [details] [review] messageTray: don't time out banners when the user is inactive This will ensure that the user doesn't miss notifications.
Seems like this has been fixed.