notifications, again :D

Aaron J. Seigo aseigo at kde.org
Wed Jan 27 00:04:15 CET 2010


On January 26, 2010, Diego Moya wrote:
> 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?

what i said is that showing all the previous notifications and jobs when a new 
notification is shown in the automatic popup is not desirable. this is not the 
same as saying "the latest is the most relevant". 

> In the example that
> isn't true - the most important was the Low Battery, which is not the
> last.

i addressed this elsewhere.


> Grouping by application and hiding after some seconds would prevent
> the screen being littered with alerts. It's still theoretically

can you explain why i should be presented with kopete's last notification when 
it is a notification from kontact that was just made?

> - 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.

this forces user interaction; notifications are often passive. simply showing 
a number and activating the (i) should be enough, as we currently do.

> - 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).

which seems backwards: if i explicitly ask for the notification to be shown, 
i'd like to be saved digging through all the kopete notifications just to find 
the last appointment notification from kontact.

> 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.

jobs could easily be kept separated from notifications.

> 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".

sounds like it could work.

> The list could be optionally ordered by alert priority, if
> notification priorities get implemented.

yes

> - 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).

not the best of ideas, given people's prediliction to double click anything 
and everything.

> - 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.

i don't think the grouping is of any real use here because it will show things 
that have already passed which the user does not care about anymore.

> - 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).

yes

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks


More information about the Plasma-devel mailing list