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 _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
