On Wednesday 06 May 2009, Celeste Lyn Paul wrote: > On Sunday 03 May 2009 03:43:42 am Marco Martin wrote: > > On 5/2/09, Celeste Lyn Paul <cele...@kde.org> wrote: > > > Some of you may or may not remember that I've also been working on > > > interruptions and notifications; however as part of a uni project > > > rather than for an open source project. > > > > > > Part of the project is for designing an empirical experiment to > > > explore different features in notifications. I would like to look at > > > features which KDE would find useful to make the study more valuable. > > > > like putting some users in front of different systems and see the > > reactions? or a more theoretical thing? > > Yes, putting users infront of different features to see which ones are > better, etc. More empirical research than usability testing though. > > > > What types of questions do you regarding notifications? I've seen some > > > questions regarding the amount of time a message should be displayed, > > > how long a message history should last, etc. > > > > yeah, interesting questions indeed, also interesting is how much > > screen size they can take up before becoming annoying > > also what is the better way tp display the history? alongside fresh > > notifications? in another interface? > > Right, these are all things I'd eventually like to look into more, but I > can only test a few features at a time without the experimental design > becoming insane. > > > > I'm also thinking about looking at ways we can mediate notifications, > > > that is, instead of immediately displaying a notification, assess the > > > user and the environment and decide if it would be better to postpone > > > the notification for a short time. (For example, if a user currently > > > has a context or window menu open, postpone the notification until the > > > menu is closed or until n seconds) > > > > good idea, even if i don't have a clear idea how to do it technically > > one could push it as far as delaying the notification until there is a > > second without input from the user (or some amount of time passed) > > this suggests also dividing notifications by severity or category: > > changes the delay poicy or even how they are displayed > > One guideline I found was that interruptions were more disruptive when > users were directly interacting with an application (such as an app menu or > context menu). I was trying to find out from the kwin people to see what > type of information is available to the environment. I think we can tell
or simply if the user is using the mouse/keyboard at all? this could be done by quering the info used for screensaver triggering (as is discussed in systray jobs thread here) that would be quite feasible i think > when a user has one of those menus open, and so a "mediated" improvement > would be to postpone an interruption until the user is out of the menu, or > up to n seconds. > > I would like to test a lot of those sorts of guidelines, because then we > can come up with a set of rules for how notifications behave. Even if the > effect is small, those small tweaks make the difference between a Good and > Great system. _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
