← Back to team overview

unity-design team mailing list archive

Re: Notifications in unity

 

On Thu, Nov 17, 2011 at 11:59 AM, staticd
<staticd.growthecommons@xxxxxxxxx> wrote:
> Jo-Erlend:
>>
>> If you spend three hours a day using your computer, then you will have
>> spent 10.920 hours during the next ten years. Is it more important that a
>> user can use the system without learning anything, or is it more important
>> that the next 10.919 hours are as pleasant as possible?
>>
>> It is folly to believe that people should be able to be masterful computer
>> users without spending even ten minutes learning how to use it.
>>
> I agree completely. However that might be the geek in me responding to the
> geek in you :P
>
> (I)Usage case:
> In the case of my mother, many times she doesn't pick up shortcuts that
> require a little looking around to discover.
> This is because she (and maybe other computer users) are not comfortable or
> interested in experimenting. Things in the corners of the screen may not be
> obvious.
> We must keep in mind, that the less an (average) user has to read a manual,
> the better. ("here, take this CD and become a full time ubuntu user")
> (I)Hence:
> The "notifications are transient", "indicators are persistent and invite
> action" principle might need rethinking either in principle or in practice.
> The ayatana list (IMHO) is the best place to do it.
>
> (II)Usage case:
> 1)When a user is distracted by a notification and wants it to go away, there
> is no means of doing that
> 2)When a (new) user mouses over a notification they may want to interact
> with the associated programme
> (II)Design principles and Constraints:
> a)Notifications must not capture input focus when they appear
> b)Notifications must not suddenly appear below clickable areas, get clicked
> and do something unexpected
> c)Notifications must not be used as a means of acquiring user input/ invite
> action. (barring informing  users about things they may act upon in other
> places)
> (II)Proposal:
> 1)To satisfy Design principles and constraints (a) and (b): the notification
> behaviour remains as it is for the first two seconds,
> 2)A mouse over after the delay will transform the notification to show a
> close and a help button(see attachment)
> 3)Clicking the help button will direct attention to the relevant indicator/
> window/ status( How can this be implemented?)

I agree with the use cases and design principles/constraints you
listed. Thank you for so clearly describing the problem!

Your proposal is interesting, but I am unclear on one point. If the
notification appears under the mouse, does that count as a mouse-over
after two seconds? Or will the user have to mouse away and then back?
Either option seems potentially problematic...

How about this as a sort of counter-proposal (still trying to solve
the same root problems). The notification bubbles are associated with
an indicator menu via a speech-bubble like tail. So an empathy message
would be associated with the messaging indicator. Opening that
indicator would immediately clear the notification. The notifications
remain transient as they currently are.

Thoughts?
Evan



Follow ups

References