Notifications should stay on screen longer when there is a lot of text

[ASDFASDF]

Sometimes there is a lot of text in the notification bubble, but it disappeares in a few (5?) seconds, which is barley enough to read it if you pay attention and you are a fast reader. There are people who can't read as fast (visualy impared, dyslexic), so I think notifications with a lot of text should stay on the screen a few seconds longer, maybe some algorithm that takes number of characters in consideration or something (but lets say bubble should never last less than 5 or more than 10 seconds).

That said, I do understand that notifications shouldn't be "novels", and that they should be non-critical, and that consistency is important for the "feel" of the system, but I needed to point this out to see the community feedback.

[Mark Shuttleworth (sabdfl)]

The spec should say:

 - there's a wrapping and scrolling provision for notifications > 12 lines
 - longer notifications should stay on screen for longer.

I'll leave it up to MPT to say whether the spec DOES say that, and Mirco
to say whether or not it's implemented yet :-)

Mark

[Mirco Müller (macslow)]

The spec (https://wiki.ubuntu.com/NotifyOSD#Animations%20and%20durations) states that the on-screen time for a notification should be extended according to the amount of text/lines (5000 ms + line-count * 250ms) displayed. This is just not yet implemented. BTW, upper limit of the title/summary is 3 lines of text ... upper limit for the body is 10 lines of text.

[Luchostein (luchostein)]

Notifications time persistance should be customizable. Maybe consider:
- Minimum enforceable display time.
- Maximum enforceable display time.
- Optional time proportion regarding to text length.
- Notification history! (plus clear-history button).
- Auto-hide Notifications icon after some customizable time.

[Lightbreeze (nedhoy-gmail)]

> There are people who can't read as fast (visualy impared, dyslexic)
Would an accessibility option to show notifications for longer be worth considering?

[Dan Näsman (dan-naesman)]

It is not just about time. You might be have focus on something else but the screen and maybe only seeing a disappearing notification.

The notification should leave a trace so that you could recall it when coming back to the screen.

[Radoslav Georgiev (valsodarg)]

#1. Or an area where the user can hover over to bring back the notification from blurred and stop the timer.
#2. A key sequence to bring back last notification (shortcut)
#3. A manager to display all the notifications logged

[Stefan Hammer (j-4-deactivatedaccount)]

I just found out where notifications were locked.

~/.cache/notify-osd.log

Who wants to build a small GUI?
Or we can implement it into Log File Viewer!

Good ideas, Valsodarg! (https://bugs.launchpad.net/hundredpapercuts/+bug/340996/comments/6)

[Jordan Hall (jordan-hall)]

I made some modifications to notify-osd for my own use a while ago. I've since written about these change and released the source code and a Debian package on my site. Note that this is more a temporary work around, which increases the display time to 10 seconds from 5, than a proper patch.

http://divineomega.co.uk/ubuntu/modifications-to-the-notification-system-of-ubuntu-904/

I agree that the notifications should stay on screen longer dependant upon the number of lines displayed in the notification, as per the original Notify-OSD specification on the Ubuntu wiki.

[Dan Näsman (dan-naesman)]

I usually google do to get further explanation or a solution to a problem. Why not have a google (or preferred search engine) button that searches the Internet with a unique "notification id"?
That would save typing in significant words from the notification in a google search.

[Steve Love (stevelove)]

I hope it's not too late to add a comment on this.

First, I love the notifications and I'm glad they're getting some paper cut treatment. That said:

Whenever I see a notification that has more text than I have time to read, my reaction is to move my mouse over it to stop the timer and make it stay visible until I've had time to read it. I do this 100% of the time even though I already know it's not how these notifications work (yet?).

I'm not sure I understand why the notifications become transparent on mouseover when no other interface that I know of works this way. If I move my mouse over an object on the screen, it's because I want to focus my attention on that object and possibly even interact with it. For example, I should be able to click a new mail notification and go to my inbox.

It's the same sort of thing that frustrates me when I hover over the Banshee tray icon and I see that currently playing slider. No matter how badly I want to use it as a convenient way to skip through the track, it's only there to taunt me; look but never, ever touch.

Thanks for any consideration this gets. :)

[Vish (vish)]

@Steve Love :
The banshee tooltips issue , Kindly file a seperate bug , and assign it to both papaercuts and banshee.
That needs to be fixed.
If the bug is already present , assign the existing bug to papercuts too, by selecting "Also affects project"

[Steve Love (stevelove)]

@mac_v:
Regarding the Banshee tooltip, I only mentioned it to say that the same frustration is caused by not being able to interact with the notifications. I realize it's a separate issue and I apologize for the confusion. (And I will file a separate bug if it doesn't already exist. Thank you.)

[Mirco Müller (macslow)]

This does not apply to the requirements of a papercut, as the needed work on notify-osd is anything but tiny or quickly implementable. While it is still on the schedule for Karmic, listing it under papercuts is wrong.

[David Siegel (djsiegel-deactivatedaccount)]

Mirco mentions that this is not paper cut-sized.

[Ongion (benpy2k)]

Seeing as this didn't make it into Karmic, will this promised feature be present in Lucid?

[Jon Elofson (jon-elofson)]

Personally, I think when the mouse goes over the notification, it should stay visible, rather than blur.