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