Notifications Features

[Marco Martin]

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