notifications, again :D

[Diego Moya]

Arriving late to the discussion, so just my 2 cents:

2010/1/26 Aaron J. Seigo <aseigo at kde.org>:
> On January 26, 2010, Ivan Čukić wrote:
>> On Tuesday, 26. January 2010. 11.57.36 Riccardo Iaconelli wrote:
>> > On Monday 25 January 2010 13:20:56 Marco Martin wrote:
>> > > opinions? comments?
>> > > would like to hear some feedback before implementing anything since
>> > > each solution would lead to a different total screwing of the current
>> > > implementation :p
>>
>> What about having something like Facebook does - one small notification
>> popup at a time, and when the user clicks the 'show notifications' he/she
>> gets the list of notifications.
>>
>> We don't need to go for the list as well, but since the user clicked the
>> 'show notifications' button we don't have the problem of contextual
>> information covering a large part of the screen - it is what the user
>> wanted.
>
> the problem is when we have 10 notifications from one app and 1 from another
> plus a few running jobs.

There's an easy solution for that: group notifications by application
when showing them for the first time. Say you have Kopete throw in 5
notifications, then the important Low Battery shows, then Kopete
rapid-fire 20 notifications more.

Final result? Two alerts on screen, on of them is Low Battery - the
other is a pile of 20 Kopete notes, latest on top. This solves the
problem of bad-behaved applications, they will not spam the screen
even when they are the only player in town. When you really want to
see what it had to say, you can expand that pile of 25 notes (and
maybe even regroup them later).

Simpler than a priority scheduler, ain't it? Maybe you could even
explain to Aunt Tillie how it works! ;-)


2010/1/26 J Janz wrote:
> Having notifications queued (by showing just 1 at a time) seems like a good
> idea to clean up the desktop but it could bring more trouble than just that
> inconvenience.
> 2010/1/26 Marco Martin:
>> if the mouse is already somewhere over a notification any new notification
>> should be queued and not displayed until the mouse leaves
>
> Yeah but, see, if you have one notification at a time, this totally ruins
> the purpose of battery (or whatever else)'s urgency on telling you your
> power is going away.

If the mouse is over a notification, we can safely assume the user is
paying attention to notifications. Having the user attention makes
many notifications turn from "clutter" to "information". So the
original motivation for limiting the number of shown alerts is not
present while the user is reading them - additional alert groups could
be shown in that case, but be limited to one (or two, or three) group
otherwise. This has the benefit over a "show me everything" persistent
state that it only fills the screen when the user is looking for it,
avoiding the "kopete noise in the backgroung".

It's true that when the mouse is over a notification it should NEVER,
EVER change to a different one (that's an important thing, guys!) but
the solution is not hiding new information, is placing it somewhere
else.

In the example, say I get a new mail notification. I hover the mouse
over it to read the mail's subject, and the battery notification runs.
What's the best thing to do? Not to hide my mail note, not to hide the
low battery note. Guess it? Just show the new battery alert below (or
above) the user-selected mail alert!