Notifications Features

[Celeste Lyn Paul]

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

-- 
Celeste Lyn Paul
KDE Usability Project
usability.kde.org