notifications, again :D

[Diego Moya]

2010/1/26 Aaron J. Seigo wrote:
> On January 26, 2010, Diego Moya wrote:
> for when the user specifically calls up the notifications (e.g. by expanding
> the popup or by clicking on the (i) icon), this will be great.
>
> for notifications that are auto-popped, it suffers from the issue of showing
> all existing notifications when really only the latest one is relevant.
>

Why do you assume the latest is the relevant one? In the example that
isn't true - the most important was the Low Battery, which is not the
last.


>> Simpler than a priority scheduler, ain't it?
>
> my proposal didn't actually have a priority scheduler in it other than
> "critical notifications should get precedence", which is likely needed no
> matter what we do (stacking vs queueing).

OK, establishing priorities would help in having the Low Battery
warning noticed instead of the Kopete ones. But then you need to find
a way to inform the user there are new warnings available, even if
they are being queued until you dismiss the important one.

And there's also the need to support a use case to which I don't know
whether you're paying enough attention: the "away from keyboard". The
user should be able to go for a walk, or talk to a person besides her
for some minutes without looking at the screen, and later tell if new
unseen messages have appeared while away.


So what do you think of the following flow, which tries to take the
best parts of the previous suggestions in this thread?

- As soon as a notification arrives, show a popup for it. Group
several alerts from the same application, to keep badly behaved apps
in check; every time a second message arrives from the same app
already shown, make a "one-second yellow flash" animation to show that
it has been updated, and replace the old content with the new one.

- Have each popup disappear after a few seconds, on a FIFO basis (each
popup having its own timer). Every time one is hidden, do a flashing
animation of the (i) icon to show where it went. This solves the
problem of "I think the current job has finished because the popup
went away".

Grouping by application and hiding after some seconds would prevent
the screen being littered with alerts. It's still theoretically
possible to have the screen covered with warnings, but this would only
happen if many applications show alerts at the same time - and this is
a valid reason to show all them at once, since they are generating a
lot of background activity that could degrade performance or be a
symptom of a system problem.


- The first time a popup disappears, the (i) icon activates into a
subtle spinning or fading animation, to show that there are recent
notifications on which the user has not acknowledged their existence
(she might have missed them). The animation will only stop when the
user clicks on the (i). This is how the user confirms that she has
seen everything which has been briefly shown in the transient popups.

- Clicking on the (i) once shows a panel with a scrollable list shows
all notifications in the current session (or the current day, whatever
lasts longer), ordered by time, latest on top. Notifications will not
be grouped by application here. This allows the user to review
everything notified recently, and to stop reading as soon as she
recognizes already viewed notices (i.e. a familiar "blog" model).

Running jobs would keep flowing to the top of this panel as they are
always the latest notification, because they're working (and thus
adding new data) right now. As they come to an end, they will get
placed relative to other notes at the precise moment they finished.

New alerts arrived while the user is reviewing the panel would be
placed at the top, outside the scrolling panel, and would also
disappear after a few seconds to be placed at the top of the "blog".

The list could be optionally ordered by alert priority, if
notification priorities get implemented. This would make easier
looking for "all important notifications in the current session".

- Double-clicking the (i) stops the animaiton without showing the
panel (same effect than clicking once, viewing the panel, and clicking
a second time to close it).

In summary, you have two simple related ways to show notifications:

- a temporary sequential list showing new messages (and only them),
that doesn't require any user interaction. It doesn't use much screen
real estate because of grouping and auto-hiding.
- a (semi)persistent sequential list that only requires user
interaction to dismiss a "new messages available" subtle animation,
and that allows reviewing older messages (either already seen or not).
It doesn't require much screen real state because of the scroll list,
and it's hidden when the user finishes using it (but can be retrieved
any number of times).