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