[Ayatana] unity and notifications

[dani]

Hi, I wanted to talk about the new unity interface and OSD
notifications.

Until now the upper right side was chosen for the notifications because
it was the least intrusive to the user and the window app. but now there
are many more indicators and  possible windicators in the future. 
therefore it is an area where the view is more often. 
then why not change the site down, for example on down-center, like
gnome-shell position.
We do not have the panel below, now is the least problematic area. what
do you think?


-- 
Daniel Planas.A

 www.lightgraphite.com


___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] unity and notifications

[dani]

I forgot to include a link with a small mockup. as usual, a picture is
worth a thousand words. :)

http://ompldr.org/vNWpzNg

-- 
Daniel Planas.A

 www.lightgraphite.com


___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] unity and notifications

[Mark Curtis]

I'm thinking they should stay where they are BECAUSE there are other things 
like (w)indicators there.  That way the users knows the upper right corner of 
the screen is for notifications of any kind.

> From: daniplana...@gmail.com
> To: ayatana@lists.launchpad.net
> Date: Wed, 15 Sep 2010 17:36:13 +0200
> Subject: Re: [Ayatana] unity and notifications
> 
> 
> I forgot to include a link with a small mockup. as usual, a picture is
> worth a thousand words. :)
> 
> http://ompldr.org/vNWpzNg
> 
> -- 
> Daniel Planas.A
> 
>  www.lightgraphite.com
> 
> 
> ___
> Mailing list: https://launchpad.net/~ayatana
> Post to : ayatana@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~ayatana
> More help   : https://help.launchpad.net/ListHelp
  ___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] unity and notifications

[Conscious User]

I think somewhere in the NotifyOSD guidelines (can't find now), there
was the idea that moving a bubble (and therefore the entire text it
contains) is annoying for the user, so your mockup is not taking into
account the case where a notification grows, because this would
involve moving the bubble upwards.

Since there is a line-limit for each bubble, though, this can be
solved by simply placing the initial position a little bit higher.

Of course, this creates the other problem of leaving a gap between
the bubble and the screen edge for short notifications. And I've not
seen *one single person* who actually likes the gap that the current
incarnation of NOSD leaves between the top edge and the bubble. Yes,
I know it's the space for the confirmation bubbles, but I think it
would be much better if those appeared in another place entirely,
like a bottom corner.


Le mercredi 15 septembre 2010 à 17:36 +0200, dani a écrit :
> I forgot to include a link with a small mockup. as usual, a picture is
> worth a thousand words. :)
> 
> http://ompldr.org/vNWpzNg


___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] unity and notifications

[Greg K Nicholson]

On 15 September 2010 16:54, Conscious User  wrote:
> I know it's the space for the confirmation bubbles, but I think it
> would be much better if those appeared in another place entirely,
> like a bottom corner.

I've suggested before that synchronous notifications (e.g. volume)
should appear horizontally centred. Then the asynchronous
notifications (IM etc.) can appear immediately below the top panel, at
the right.

No-one has come up with any drawback whatsoever to this design—yet ;)
-- 
Greg

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] unity and notifications

[Michael Jonker]

I think everyone is going to have a personally preferred position, but
maintaining a default association with the 'me menu' is probably a good
thing. However, as Dani notes, this can get in the way - especially
considering that many apps, especially on the graphics sides of things,
have their toolbar in that location. I have been caught a few times
where I have had to wait for the notification to fade out before I could
continue working.

What I would like to see is:
1: the notification is interactive - ie. clicking on it brings up the
app which is sending the notification and at the correct 'page' or
message, etc.
2: having a 'dismiss' button on the notification which gets it out of
the way quickly
3: let me drag it to my preferred location (like a widget) and let the
system remember where I want it.

On Wed, 2010-09-15 at 17:36 +0200, dani wrote:

> I forgot to include a link with a small mockup. as usual, a picture is
> worth a thousand words. :)
> 
> http://ompldr.org/vNWpzNg
> 


___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] unity and notifications

[Mario Vukelic]

On Wed, 2010-09-15 at 18:35 +0100, Michael Jonker wrote:
> this can get in the way - especially considering that many apps,
> especially on the graphics sides of things, have their toolbar in that
> location. I have been caught a few times where I have had to wait for
> the notification to fade out before I could continue working.

But Ubuntu notifications fade out as soon as you move the mouse there
(or do I misunderstand you?).

This was /the/ big change in Ubuntu's notifications a few releases ago,
and along with the non-existing close button in the bubble it caused a
lot of controversy initially. I think this worked out pretty great in
the end and diminished the obtrusiveness of bubble notifications.


___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] unity and notifications

[Michael Jonker]

Sorry I wasn't around for the initial discussion :)

Yes it does fade, but is still there. For me, it is still difficult to
work with an app below this faded notification, eg.

1) In Gimp I am working heavily with layers, creating new iterations of
a scene at a workrate of about 1 second per scene. A notification pops
up and obscures the list at the top of the Gimp layers dialogue
sufficiently to make it unusable. I now have to wait about 5 seconds for
it to go away. My point is that a x (close) button would dismiss this
intrusion to my focussed work immediately - or - moving the notification
to a position I can accept will give me the best of both worlds.
re-arranging my gimp dialogues should not have to be an option. 

2) I get a new mail notification. I have 5 different mailboxes. Firstly,
I have to click on the green envelope to get to Evolution. This takes me
a default list of all my accounts where I have to mine down through the
list to get to my new mail. I think it would be great if I click on the
notification it takes me directly to Evolution with the mailbox in which
my new message has arrived already selected.

3) A torrent has just finished downloading and a notification pops up. I
can't do anything with the notification - I have to mine down through a
link somewhere else on the system to get to Transmission. I want to just
click on the notification and Transmission automatically pops up.

To give credit where it is due - another popular and invasive OS does it
very well, albeit the notification is usually about installing some
nefarious piece of software update, and thus annoying by virtue of it's
purpose.  

On Wed, 2010-09-15 at 21:07 +0200, Mario Vukelic wrote:
> On Wed, 2010-09-15 at 18:35 +0100, Michael Jonker wrote:
> > this can get in the way - especially considering that many apps,
> > especially on the graphics sides of things, have their toolbar in that
> > location. I have been caught a few times where I have had to wait for
> > the notification to fade out before I could continue working.
> 
> But Ubuntu notifications fade out as soon as you move the mouse there
> (or do I misunderstand you?).
> 
> This was /the/ big change in Ubuntu's notifications a few releases ago,
> and along with the non-existing close button in the bubble it caused a
> lot of controversy initially. I think this worked out pretty great in
> the end and diminished the obtrusiveness of bubble notifications.
> 
> 
> ___
> Mailing list: https://launchpad.net/~ayatana
> Post to : ayatana@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~ayatana
> More help   : https://help.launchpad.net/ListHelp



___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] unity and notifications

[Conscious User]

> My point is that a x (close) button would dismiss this
> intrusion to my focussed work immediately - or - moving the notification
> to a position I can accept will give me the best of both worlds.

Best of both worlds for your particular use case, but the truth is:
neither option is fully ideal. A close/respond button creates problems
with accidental clicks (a bubble popping up exactly when you are
clicking in something below it), and there is the fact that it feels
wrong to get out of your workflow just to close a notification.

The current NotifyOSD bubbles follow this principle quite well with
respect to the case where you might need to interact with the mouse:
it simply fades away smoothly when you approximate the cursor and
gets out of the way. However, you are absolutely correct when you
say that the bubbles get in the away when you need to *just see*
what is below them, not interact with. Then you need to put the
mouse over them to make them fade, which is almost the same thing
as closing.

So, the question to the Ayatana designers is: how to cover this case
of "just wanting to see what is below" satisfactorily? I remember
hearing that NotifyOSD will be getting some love for Natty, so I'm
particularly curious about it.



___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] unity and notifications

[Luke Benstead]

On 15 September 2010 17:25, Greg K Nicholson  wrote:

> On 15 September 2010 16:54, Conscious User  wrote:
> > I know it's the space for the confirmation bubbles, but I think it
> > would be much better if those appeared in another place entirely,
> > like a bottom corner.
>
> I've suggested before that synchronous notifications (e.g. volume)
> should appear horizontally centred. Then the asynchronous
> notifications (IM etc.) can appear immediately below the top panel, at
> the right.
>
> No-one has come up with any drawback whatsoever to this design—yet ;)
> --
> Greg
>
>
That's definitely the best solution I've heard yet. Why are we not doing
that?

Luke.
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] unity and notifications

[Michael Jonker]

My point is not about wanting "just to see what is below". It is about
the notification (as well advanced as it is) being obtrusive and in the
way for a wide variety of use cases, not just mine.

You make a good point:

"A close/respond button creates problems with accidental clicks (a
bubble popping up exactly when you are clicking in something below it),
and there is the fact that it feels wrong to get out of your workflow
just to close a notification."

In this case a faded, transparent notification makes sense. It can go
opaque when the users mouse departs from that area.

What does not make sense to me:

A notification appears (the mouse cursor is not below the notification).
The user is now notified. When they move their mouse to that area (bear
in mind that they are 'notified' and have no further use for the
graphic) it once again fades away and reappears when the cursor departs.
This, irritatingly hangs around for about 5 seconds.

I know! I am notified! Why are you hanging about cluttering my screen?

In my opinion (unless the notification does something like launching the
relevant app or is dismiss-able by clicking on x) it should simply
vanish when the user moves their mouse cursor over it. 
 

On Thu, 2010-09-16 at 13:47 +0200, Conscious User wrote:
> > My point is that a x (close) button would dismiss this
> > intrusion to my focussed work immediately - or - moving the notification
> > to a position I can accept will give me the best of both worlds.
> 
> Best of both worlds for your particular use case, but the truth is:
> neither option is fully ideal. A close/respond button creates problems
> with accidental clicks (a bubble popping up exactly when you are
> clicking in something below it), and there is the fact that it feels
> wrong to get out of your workflow just to close a notification.
> 
> The current NotifyOSD bubbles follow this principle quite well with
> respect to the case where you might need to interact with the mouse:
> it simply fades away smoothly when you approximate the cursor and
> gets out of the way. However, you are absolutely correct when you
> say that the bubbles get in the away when you need to *just see*
> what is below them, not interact with. Then you need to put the
> mouse over them to make them fade, which is almost the same thing
> as closing.
> 
> So, the question to the Ayatana designers is: how to cover this case
> of "just wanting to see what is below" satisfactorily? I remember
> hearing that NotifyOSD will be getting some love for Natty, so I'm
> particularly curious about it.
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~ayatana
> Post to : ayatana@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~ayatana
> More help   : https://help.launchpad.net/ListHelp



___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] unity and notifications

[Conscious User]

> A notification appears (the mouse cursor is not below the notification).
> The user is now notified. When they move their mouse to that area (bear
> in mind that they are 'notified' and have no further use for the
> graphic) it once again fades away and reappears when the cursor departs.
> This, irritatingly hangs around for about 5 seconds.
> 
> I know! I am notified! Why are you hanging about cluttering my screen?

Because hovering your mouse over the notification does not necessarily
mean that you have already read it. It could also mean that what you
wanted to click on was more urgent than reading the notification or
that you were already in the process of going there to click something
and didn't want to stop (or simply couldn't stop, as a lot of actions
we do in the desktop are repetitive and become automatic and lightning
quick after a while).

At least for me, both of those cases are not rare.

> In my opinion (unless the notification does something like launching the
> relevant app or is dismiss-able by clicking on x) it should simply
> vanish when the user moves their mouse cursor over it. 

That would probably cause a lot of accidental dismissals.

Believe me, I'm the first in line to complain that NotifyOSD is *far*
from being perfect, but as you can see it is not exactly trivial to
come up with fixes that do not cause other, significative, problems.
There are a lot of different cases to consider.



___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] unity and notifications

[Conscious User]

Le jeudi 16 septembre 2010 à 13:29 +0100, Luke Benstead a écrit :
> 
> 
> On 15 September 2010 17:25, Greg K Nicholson  wrote:
> On 15 September 2010 16:54, Conscious User
>  wrote:
> > I know it's the space for the confirmation bubbles, but I
> think it
> > would be much better if those appeared in another place
> entirely,
> > like a bottom corner.
> 
> 
> I've suggested before that synchronous notifications (e.g.
> volume)
> should appear horizontally centred. Then the asynchronous
> notifications (IM etc.) can appear immediately below the top
> panel, at
> the right.
> 
> No-one has come up with any drawback whatsoever to this design
> —yet ;)
> --
> Greg
> 
> 
> 
> 
> That's definitely the best solution I've heard yet. Why are we not
> doing that?
> 
> Luke.

As a matter of fact, because the confirmation bubbles have a fixed
size, they can be placed pretty much anywhere with little issues.

If I were to guess the reason of the current placement, is that the
designers believe that giving the user two different places from
which bubbles can come from is confusing. Can someone confirm?



___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] unity and notifications

[Michael Jonker]

With specific reference to Unity and the notification:

We need to get ready for the touchscreen market. The present logic of
the notification is mouse-centric and will need to be overhauled for
touch screen. 

In this situation, the mouse cursor causing the notification to fade
will not be available and the notification will simply take up real
estate for a length of time the user cannot control.


On Thu, 2010-09-16 at 13:47 +0200, Conscious User wrote:
> > My point is that a x (close) button would dismiss this
> > intrusion to my focussed work immediately - or - moving the notification
> > to a position I can accept will give me the best of both worlds.
> 
> Best of both worlds for your particular use case, but the truth is:
> neither option is fully ideal. A close/respond button creates problems
> with accidental clicks (a bubble popping up exactly when you are
> clicking in something below it), and there is the fact that it feels
> wrong to get out of your workflow just to close a notification.
> 
> The current NotifyOSD bubbles follow this principle quite well with
> respect to the case where you might need to interact with the mouse:
> it simply fades away smoothly when you approximate the cursor and
> gets out of the way. However, you are absolutely correct when you
> say that the bubbles get in the away when you need to *just see*
> what is below them, not interact with. Then you need to put the
> mouse over them to make them fade, which is almost the same thing
> as closing.
> 
> So, the question to the Ayatana designers is: how to cover this case
> of "just wanting to see what is below" satisfactorily? I remember
> hearing that NotifyOSD will be getting some love for Natty, so I'm
> particularly curious about it.
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~ayatana
> Post to : ayatana@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~ayatana
> More help   : https://help.launchpad.net/ListHelp



___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] unity and notifications

[Conscious User]

Le jeudi 16 septembre 2010 à 16:22 +0100, Michael Jonker a écrit :
> With specific reference to Unity and the notification:
> 
> We need to get ready for the touchscreen market. The present logic of
> the notification is mouse-centric and will need to be overhauled for
> touch screen. 
> 
> In this situation, the mouse cursor causing the notification to fade
> will not be available and the notification will simply take up real
> estate for a length of time the user cannot control.

An idea would be placing the notifications in a place dedicated to
it, which won't be clicked regardless of the situation. In high
resolutions, an excellent candidate is the (currently wasted)
space in the middle of the top panel. For low resolutions the
problem is a little bit more hairy, methinks...



___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] unity and notifications

[Michael Jonker]

Indeed,

And to start brainstorming potential solutions:

1) Maybe there is a minimum 'appearance' time for the notification of
maybe about 0.75 seconds to prevent involuntary dismissal. The ideal
timing may involve some investment in research.

2) The notification dismisses to a small, flashing icon in the top panel
which hangs around for about 5 seconds so that the user can retrieve a
lost notification. I think in 99.9% of cases the user will be aware that
they have accidentally dismissed something. The button could potentially
bring up a drop down list - just in case multiple notifications have
happened in short succession. 

On Thu, 2010-09-16 at 17:19 +0200, Conscious User wrote:
> > A notification appears (the mouse cursor is not below the notification).
> > The user is now notified. When they move their mouse to that area (bear
> > in mind that they are 'notified' and have no further use for the
> > graphic) it once again fades away and reappears when the cursor departs.
> > This, irritatingly hangs around for about 5 seconds.
> > 
> > I know! I am notified! Why are you hanging about cluttering my screen?
> 
> Because hovering your mouse over the notification does not necessarily
> mean that you have already read it. It could also mean that what you
> wanted to click on was more urgent than reading the notification or
> that you were already in the process of going there to click something
> and didn't want to stop (or simply couldn't stop, as a lot of actions
> we do in the desktop are repetitive and become automatic and lightning
> quick after a while).
> 
> At least for me, both of those cases are not rare.
> 
> > In my opinion (unless the notification does something like launching the
> > relevant app or is dismiss-able by clicking on x) it should simply
> > vanish when the user moves their mouse cursor over it. 
> 
> That would probably cause a lot of accidental dismissals.
> 
> Believe me, I'm the first in line to complain that NotifyOSD is *far*
> from being perfect, but as you can see it is not exactly trivial to
> come up with fixes that do not cause other, significative, problems.
> There are a lot of different cases to consider.
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~ayatana
> Post to : ayatana@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~ayatana
> More help   : https://help.launchpad.net/ListHelp



___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] unity and notifications

[Diego Moya]

On 16 September 2010 17:19, Conscious User wrote:

>
> > A notification appears (the mouse cursor is not below the notification).
> > The user is now notified. When they move their mouse to that area (bear
> > in mind that they are 'notified' and have no further use for the
> > graphic) it once again fades away and reappears when the cursor departs.
> > This, irritatingly hangs around for about 5 seconds.
> >
> > I know! I am notified! Why are you hanging about cluttering my screen?
>
> Because hovering your mouse over the notification does not necessarily
> mean that you have already read it. It could also mean that what you
> wanted to click on was more urgent than reading the notification or
> that you were already in the process of going there to click something
> and didn't want to stop (or simply couldn't stop, as a lot of actions
> we do in the desktop are repetitive and become automatic and lightning
> quick after a while).
>

I thought the current OSD design was based on the idea that it doesn't
matter if you miss one notification. ;-)  So what would be wrong if the
notification was simply discarded in that case? It collided with a much more
important action, so it's only natural that it would yield priority.



>
> At least for me, both of those cases are not rare.
>
>
Then, that's a big problem with the design.



> Believe me, I'm the first in line to complain that NotifyOSD is *far*
> from being perfect, but as you can see it is not exactly trivial to
> come up with fixes that do not cause other, significative, problems.
> There are a lot of different cases to consider.
>
>
IMHO much of those problems are due to the NotifyOSD giving itself too much
airs. If it truly accepted its role of being secondary to everything else,
and just disappeared when it's unwanted,  it would be a lot less intrusive.

Actually there's a really simple fix that would solve both your problem and
the one of obscuring graphical applications, and it's this: don't ever show
a notification while the user is working on something else. The way to
detect the user work must be heuristic, but there are some good clues to it:

- never show the notification while the user is actively providing input.
Typing, moving the cursor, drag gestures.
- After heavy user actions (pressing keys, clicking) wait at leas 5 seconds
before showing a notification.
- If the user is working at a fast pace and the notification remains hidden
for this reason for longer than its useful lifetime, simply discard it
forever.

These small additions would prevent a notification getting in the way. In
these cases the user wouldn't have noticed or wanted to read it anyway, so
nothing of value is lost.
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] unity and notifications

[Mario Vukelic]

On Thu, 2010-09-16 at 17:19 +0200, Conscious User wrote:
> Because hovering your mouse over the notification does not necessarily
> mean that you have already read it. It could also mean that what you
> wanted to click on was more urgent than reading the notification or
> that you were already in the process of going there to click something
> and didn't want to stop (or simply couldn't stop, as a lot of actions
> we do in the desktop are repetitive and become automatic and lightning
> quick after a while).
> 
> At least for me, both of those cases are not rare. 

It always has and still appears to me that the notifications should not
be completely ephemeral, or rather, not all notifications should be.
Instead there should be a log of some kind where I can look up what
happened while I was away. Maybe notifications need to come in various
levels of seriousness for this to work, though, because I would indeed
not be interested to read a log of a hundred IM status changes.

But, for example, the Back in Time backup tool (easily the best desktop
PC backup tool in Ubuntu for GUI users) uses notification bubbles to
notify the user about the backup disk not being found. Which basically
forced me to set it to hourly snapshots when I installed it for a casual
user I support, because with daily snapshots the user would probably
never see the information that his USB backup disk is not mounted, which
happens.

Maybe Back in Time uses notification bubbles for something they were not
intended, though - but is there even a better way?


___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] unity and notifications

[Apoorva Sharma]

> In high
> resolutions, an excellent candidate is the (currently wasted)
> space in the middle of the top panel. For low resolutions the
> problem is a little bit more hairy, methinks...
>

That is just what I was thinking. How about an android-esque model, where
the entire panel contents fade out, the notification appears, and then the
panel fades back to its normal state. If, while the notification is showing,
the user moves the cursor to the panel, the notification fades out
automatically, showing the normal panel contents. This would work similarly
to the current NotifyOSD system. There could be a button on the panel that
would make the panel slide down, showing recent notifications, with their
related actions.

In order to indicate where the notification can be acted upon, the text
could be right-aligned.

Another idea would be to only have messages fade in place of the right half
of the panel, thus leaving the unrelated Applications Places System menu
unchanged.

Sorry for the somewhat incohesive email - I'm just writing as I think.
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] unity and notifications

[David Hamm]

"Another idea would be to only have messages fade in place of the right half
of the panel, thus leaving the unrelated Applications Places System menu
unchanged."

I like this, touching would close/restore the top right. If it was an
important event it could be reopened from the calendar app.
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] unity and notifications

[Conscious User]

> I thought the current OSD design was based on the idea that it doesn't
> matter if you miss one notification. ;-)  So what would be wrong if
> the notification was simply discarded in that case? It collided with a
> much more important action, so it's only natural that it would yield
> priority.

Like I said, it's not necessarily a "much more important action". It
could be a very mundane action, but whose movement you couldn't stop
by reflex.

Furthermore, it is one thing to miss one notification because you were
away or not paying attention. It is another, and much more annoying,
thing to know *something* has happened and never knowing *what*.

> IMHO much of those problems are due to the NotifyOSD giving itself too
> much airs. If it truly accepted its role of being secondary to
> everything else, and just disappeared when it's unwanted,  it would be
> a lot less intrusive.
>  
> Actually there's a really simple fix that would solve both your
> problem and the one of obscuring graphical applications, and it's
> this: don't ever show a notification while the user is working on
> something else. The way to detect the user work must be heuristic, but
> there are some good clues to it:
> 
> - never show the notification while the user is actively providing
> input. Typing, moving the cursor, drag gestures.
> - After heavy user actions (pressing keys, clicking) wait at leas 5
> seconds before showing a notification.
> - If the user is working at a fast pace and the notification remains
> hidden for this reason for longer than its useful lifetime, simply
> discard it forever.
> 
> These small additions would prevent a notification getting in the way.
> In these cases the user wouldn't have noticed or wanted to read it
> anyway, so nothing of value is lost.

I can be typing very fast... to copy a recipe of cake my grandmother
sent me. I can be constantly moving the cursor... to play a flash
game. I can be working at a fast pace... because I had one coffee
too many, not necessarily because the task is important.

I think you are proposing a *very simple* heuristic to guess *very
complex* thoughts.



___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] unity and notifications

[Conscious User]

> It always has and still appears to me that the notifications should not
> be completely ephemeral, or rather, not all notifications should be.
> Instead there should be a log of some kind where I can look up what
> happened while I was away. Maybe notifications need to come in various
> levels of seriousness for this to work, though, because I would indeed
> not be interested to read a log of a hundred IM status changes.

Actually, a lot of this is implemented already. Logging missed
notifications that require not-necessarily-immediate response is
what the Messaging Menu does. And in Lucid notifications have
priority levels. Low priority bubbles are not shown when Totem
is playing, for example.



___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] unity and notifications

[Mario Vukelic]

On Fri, 2010-09-17 at 05:26 +0200, Conscious User wrote:
> Actually, a lot of this is implemented already. Logging missed
> notifications that require not-necessarily-immediate response is
> what the Messaging Menu does. And in Lucid notifications have
> priority levels. Low priority bubbles are not shown when Totem
> is playing, for example.

I see, thanks, cool. I guess I ignored the existence of the messaging
menu because it does nothing for me. I don't use chats, broadcasts, etc.
on this machine, and my mail gets filtered so that there rarely is a new
one in the inbox. Therefore, the menu consists more or less of "set up
chat", a few mail options that I don't use, and "set up broadcast
account". If this menu is to be used for important notifications, it
would be nice if I could hide all that clutter - but I guess this must
have been discussed already :)


___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] unity and notifications

[Diego Moya]

On 17 September 2010 05:21, Conscious User wrote:
>
> Like I said, it's not necessarily a "much more important action". It
> could be a very mundane action, but whose movement you couldn't stop
> by reflex.
>
> Furthermore, it is one thing to miss one notification because you were
> away or not paying attention. It is another, and much more annoying,
> thing to know *something* has happened and never knowing *what*.
>

Au contraire, they are exactly the same thing. Why should it matter if I
miss a notification because I'm reading a webpage, or because I'm reading a
physical written manual on my physical desk? Or what if I'm away and come
back to see it just in the last half second?

The reason why NotifyOSD does not keeps a log of notifications is because
you will always have a different way to know what happened. Notifications
can be ethereal because they are redundant. If there's no way to know what
happened without reading it in the available 5 seconds, then you really
should keep a log to recover previous notifications.

Also, with my heuristic you wouldn't know something has happened while
you're active, the notification would wait until you made a small pause in
your work - right when you're ready to read it. That's much more humane than
interrupting what you're doing.



>
> I think you are proposing a *very simple* heuristic to guess *very
> complex* thoughts.
>
> Those are the best heuristics! :-)  The important thing is that it provides
a consistent, predictable behavior to notifications.

You won't be afraid that a bubble will appear right over your target on the
screen, which was your original worry. The heuristic doesn't need to
second-guess whether your intentions were important or trivial, it works
well in both cases.



>
> > Actually there's a really simple fix that would solve both your
> > problem and the one of obscuring graphical applications, and it's
> > this: don't ever show a notification while the user is working on
> > something else. The way to detect the user work must be heuristic, but
> > there are some good clues to it:
> >
> I can be typing very fast... to copy a recipe of cake my grandmother
> sent me. I can be constantly moving the cursor... to play a flash
> game. I can be working at a fast pace... because I had one coffee
> too many, not necessarily because the task is important.
>

I though we already established that notifications are even less important
than the least important of the user tasks? That's the only possible
justification for them being ethereal.

I think it was Jef Raskin who said that you should treat user input as
sacred. I concur, and that can be extended to the user focus of attention.

If the notification is important enough to interrupt the user flow then a
transient bubble notification is not the place for it, it should create a
persistent warning in the panel.

In the examples you mention there's not a single reason to show a
notification that couldn't be better  placed as a state change in the menus.
As I said, you're treating notifications as more important that they really
are, and that's creating problems to the design because it conflicts with
the 'ethereal' goal.
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] unity and notifications

[Conscious User]

> I though we already established that notifications are even less
> important than the least important of the user tasks? That's the only
> possible justification for them being ethereal.


To be more clear, I think this goal is *already* being achieved quite
nicely by NotifyOSD *when mouse interaction is involved*. The problem
is when one of the two following cases happen:

a) The user is typing something in a text field right behind the
bubble. Your heuristic works in this case, but it's a little bit of
an overkill. I certainly don't mind receiving notifications
when I'm writing something completely far away from the bubble area.

b) The user wants to just read something covered by the bubble. This
is more difficult for your heuristic to cover because he might not be
actually interacting at that moment. In fact, in the case of long
texts he might not be interacting for several seconds.




___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] unity and notifications

[Diego Moya]

On 17 September 2010 09:03, Conscious User wrote:

> To be more clear, I think this goal is *already* being achieved quite
> nicely by NotifyOSD *when mouse interaction is involved*. The problem
> is when one of the two following cases happen:
>
> a) The user is typing something in a text field right behind the
> bubble. Your heuristic works in this case, but it's a little bit of
> an overkill. I certainly don't mind receiving notifications
> when I'm writing something completely far away from the bubble area.
>

Maybe the heuristic can be refined to not block notifications while typing
unless in that case. But then you get the second problem also while
writing...


> b) The user wants to just read something covered by the bubble. This
> is more difficult for your heuristic to cover because he might not be
> actually interacting at that moment. In fact, in the case of long
> texts he might not be interacting for several seconds.
>
> I actually support having a quick way to close a notification. I don't
think it's the traditional 'X' icon, though, but something more radical:
hide the notification if the mouse hovers it, and *don't show it again even
if the mouse moves away*. The notification should act as a real bubble,
disappearing on touch.

As I said, the user moving the mouse over the notifiacion region means that
the content was more important at that moment than the notice, so there's no
problem in closing it. The information in it should be already in the panels
anyway; the user has already taken notice that there existed a bubble, and
can go to the appropriate menu to read it.

Combined with my heuristic, there's no problem that an involuntary mouse
movement would close the bubble before the user notices it.
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] unity and notifications

[Greg K Nicholson]

I like this idea, fwiw.

Another point: currently, if when the bubble appears the pointer is already
in its vicinity, i.e. the area where fading would occur, the bubble won't
fade at all until the user moves away and back.

This is in the spec, but seems contrary to the whole point of bubbles fading
on hover.

I suggest that instead, all asynchronous notifications should be queued
until the pointer moves away (similar to a suggestion above).

As an exception, high priority (urgent) notices could be shown anyway after
x (~30) seconds even if the pointer's still there.

As a bonus (though not a goal), this design would enable users who really
care to deliberately queue notices while they're away.

-- 
Greg K Nicholson

On 17 Sep 2010 09:12, "Diego Moya"  wrote:

On 17 September 2010 09:03, Conscious User wrote:
>
> To be more clear, I think this goal is *alread...

Maybe the heuristic can be refined to not block notifications while typing
unless in that case. But then you get the second problem also while
writing...

>
> b) The user wants to just read something covered by the bubble. This
> is more difficult for you...
I actually support having a quick way to close a notification. I don't think
it's the traditional 'X' icon, though, but something more radical: hide the
notification if the mouse hovers it, and *don't show it again even if the
mouse moves away*. The notification should act as a real bubble,
disappearing on touch.

As I said, the user moving the mouse over the notifiacion region means that
the content was more important at that moment than the notice, so there's no
problem in closing it. The information in it should be already in the panels
anyway; the user has already taken notice that there existed a bubble, and
can go to the appropriate menu to read it.

Combined with my heuristic, there's no problem that an involuntary mouse
movement would close the bubble before the user notices it.

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] unity and notifications

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Diego Moya wrote on 17/09/10 07:10:
>...
> I though we already established that notifications are even less
> important than the least important of the user tasks? That's the only
> possible justification for them being ethereal.
> 
> I think it was Jef Raskin who said that you should treat user input as
> sacred. I concur, and that can be extended to the user focus of
> attention. 

Well, Jef had some odd ideas about user input and focus of attention. He
thought, for example, that error messages should behave rather like
Notify OSD bubbles, undismissable and gradually fading, but that there
should be a keyboard command to adjust their transparency ("The humane
interface", pp116-117 ). And he thought it would
make sense to insert incoming e-mail messages into whatever document you
were editing at the time (p176 ).

> If the notification is important enough to interrupt the user flow then
> a transient bubble notification is not the place for it, it should
> create a persistent warning in the panel.
>...

Persistent warning, yes. In the panel, usually not. :-)


- -- 
Matthew Paul Thomas
http://mpt.net.nz/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkyTXI0ACgkQ6PUxNfU6ecoNhACglP+fTUF03wV8dqJI6eFYRRpa
/NEAn00pUlyVyIQCA7C+F/g8qsjNezC8
=Sl2v
-END PGP SIGNATURE-

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] unity and notifications

[Michael Jonker]

It seems that, under the subject of 1)Unity  2)and notifications, the
most discussion is concerning the 'Notification Bubble' (Thanks Matthew
for pointing to the spec)

2) Yes - the current implementation of the bubble is functional. It
notifies the user, it does fade when the mouse cursor is over it and you
can work below it. Many people feel though that it hangs around too long
and is visually invasive. How do we make it get out of the way
intuatively and quickly without being accidentally dismissed?
Suggestions so far:

-A heuristic approach
-It does not reappear after a 'fade'
-It stays in panel (against design guidelines)
-It briefly goes to panel as a fading button after dismissal
-A combination of above
-Apologies if I missed any suggestions

1) The topic of the original post - how does this work in Unity. More
trickily - how does it work on touchscreen?
In my opinion, if we can solve this elegantly the rest will follow.

The starting point i feel is: You touch it and it goes away.

Michael

On Fri, 2010-09-17 at 13:18 +0100, Matthew Paul Thomas wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Diego Moya wrote on 17/09/10 07:10:
> >...
> > I though we already established that notifications are even less
> > important than the least important of the user tasks? That's the only
> > possible justification for them being ethereal.
> > 
> > I think it was Jef Raskin who said that you should treat user input as
> > sacred. I concur, and that can be extended to the user focus of
> > attention. 
> 
> Well, Jef had some odd ideas about user input and focus of attention. He
> thought, for example, that error messages should behave rather like
> Notify OSD bubbles, undismissable and gradually fading, but that there
> should be a keyboard command to adjust their transparency ("The humane
> interface", pp116-117 ). And he thought it would
> make sense to insert incoming e-mail messages into whatever document you
> were editing at the time (p176 ).
> 
> > If the notification is important enough to interrupt the user flow then
> > a transient bubble notification is not the place for it, it should
> > create a persistent warning in the panel.
> >...
> 
> Persistent warning, yes. In the panel, usually not. :-)
> 
> 
> - -- 
> Matthew Paul Thomas
> http://mpt.net.nz/
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAkyTXI0ACgkQ6PUxNfU6ecoNhACglP+fTUF03wV8dqJI6eFYRRpa
> /NEAn00pUlyVyIQCA7C+F/g8qsjNezC8
> =Sl2v
> -END PGP SIGNATURE-
> 
> ___
> Mailing list: https://launchpad.net/~ayatana
> Post to : ayatana@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~ayatana
> More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] unity and notifications

[Diego Moya]

On 17 September 2010 14:18, Matthew Paul Thomas wrote:

> Diego Moya wrote on 17/09/10 07:10:
> > I think it was Jef Raskin who said that you should treat user input as
> > sacred. I concur, and that can be extended to the user focus of
> > attention.
>
> Well, Jef had some odd ideas about user input and focus of attention. He
> thought, for example, that error messages should behave rather like
> Notify OSD bubbles, undismissable and gradually fading, but that there
> should be a keyboard command to adjust their transparency ("The humane
> interface", pp116-117 ). And he thought it would
> make sense to insert incoming e-mail messages into whatever document you
> were editing at the time (p176 ).
>
> Yes, those bubbles are actually quite similar to what NotifyOSD tries to
do. But look how Jef required a way for the user to take control of how
bubbles are presented. He also thought that "a document that stores all
messages for later retrieval is essential". The Ayatana notification design
took the original idea and then changed it to its opposite by removing every
safeguard feature to put user in control and keep it humane.

The current design for OSD notifications is heavily modal - it blocks access
to the visible area until the bubble disappears, and it doesn't give the
user a way to claim that blocked area. The provided workaround to reach the
blocked screen area requires a complex interaction (the repeated fading out
and in as the mouse moves away) that can be quite distracting and doesn't
work if the user needs the cursor elsewhere. That's why I support a way to
interact directly with the notification, either by pricking the bubble or
allowing the user to place it somewhere else. Turning the bubble into an
object by allowing direct manipulation would make it not blocking, and thus
non modal.


As for the curious mail receptions in Jef's book, this was for a system
where the whole stored information was a few strokes away through instant
search, so moving it to an archive would be as trivial as cut-n-paste. Also
have in mind that this design was probably tested on the Canon Cat, in an
era way before the Eternal September and spam.


> If the notification is important enough to interrupt the user flow then
> > a transient bubble notification is not the place for it, it should
> > create a persistent warning in the panel.
> >...
>
> Persistent warning, yes. In the panel, usually not. :-)
> 
>
> Ok, I was thinking of applications that log their notifications to the
information menus.
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] unity and notifications

[Michael Jonker]

Here is a quick idea that struck me after I hit send on the last post:

1)The bubble notification makes it's appearance @ bottom right of the
screen (unfaded)

2)It moves along a path to the top of the screen (fading away as it
goes)

3)It lands in the 'Me menu'. At this point is is completely off screen,
not visible.

4)The 'Me menu' changes colour subtly, alerting the user
non-obtrusively, that the system has something to say.

5)in the 'Me Menu' is a new call out entry called 'notifications', with
a history of maybe the last 10 events. Clicking on any notification
takes you to the relevant email, message, app etc.

This has the advantage of:

If the user is at the screen, they are immediately notified that
something has happened. It is no longer NB that they take time out to
read exactly what that is.

If the user was away for a cup of tea, they can immediately see there
were events while they were away and can access them unobtrusively.

The visual disturbance of the moving notification bubble is minimal
(maybe 2 seconds) and not concentrated on 1 area of the screen where the
user may be working.

Touchscreen compatible.



Heading away for Hols, but if you guys think this idea is worth
investigating I can make a video mock up when I am back.



On Fri, 2010-09-17 at 13:58 +0100, Michael Jonker wrote:

> It seems that, under the subject of 1)Unity  2)and notifications, the
> most discussion is concerning the 'Notification Bubble' (Thanks
> Matthew for pointing to the spec)
> 
> 2) Yes - the current implementation of the bubble is functional. It
> notifies the user, it does fade when the mouse cursor is over it and
> you can work below it. Many people feel though that it hangs around
> too long and is visually invasive. How do we make it get out of the
> way intuatively and quickly without being accidentally dismissed?
> Suggestions so far:
> 
> -A heuristic approach
> -It does not reappear after a 'fade'
> -It stays in panel (against design guidelines)
> -It briefly goes to panel as a fading button after dismissal
> -A combination of above
> -Apologies if I missed any suggestions
> 
> 1) The topic of the original post - how does this work in Unity. More
> trickily - how does it work on touchscreen?
> In my opinion, if we can solve this elegantly the rest will follow.
> 
> The starting point i feel is: You touch it and it goes away.
> 
> Michael
> 
> On Fri, 2010-09-17 at 13:18 +0100, Matthew Paul Thomas wrote: 
> 
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> > 
> > Diego Moya wrote on 17/09/10 07:10:
> > >...
> > > I though we already established that notifications are even less
> > > important than the least important of the user tasks? That's the only
> > > possible justification for them being ethereal.
> > > 
> > > I think it was Jef Raskin who said that you should treat user input as
> > > sacred. I concur, and that can be extended to the user focus of
> > > attention. 
> > 
> > Well, Jef had some odd ideas about user input and focus of attention. He
> > thought, for example, that error messages should behave rather like
> > Notify OSD bubbles, undismissable and gradually fading, but that there
> > should be a keyboard command to adjust their transparency ("The humane
> > interface", pp116-117 ). And he thought it would
> > make sense to insert incoming e-mail messages into whatever document you
> > were editing at the time (p176 ).
> > 
> > > If the notification is important enough to interrupt the user flow then
> > > a transient bubble notification is not the place for it, it should
> > > create a persistent warning in the panel.
> > >...
> > 
> > Persistent warning, yes. In the panel, usually not. :-)
> > 
> > 
> > - -- 
> > Matthew Paul Thomas
> > http://mpt.net.nz/
> > -BEGIN PGP SIGNATURE-
> > Version: GnuPG v1.4.10 (GNU/Linux)
> > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> > 
> > iEYEARECAAYFAkyTXI0ACgkQ6PUxNfU6ecoNhACglP+fTUF03wV8dqJI6eFYRRpa
> > /NEAn00pUlyVyIQCA7C+F/g8qsjNezC8
> > =Sl2v
> > -END PGP SIGNATURE-
> > 
> > ___
> > Mailing list: https://launchpad.net/~ayatana
> > Post to : ayatana@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~ayatana
> > More help   : https://help.launchpad.net/ListHelp
> 
> 


___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] unity and notifications

[Walter Wittel]

I like it alot. I've grown quite fond of the Android notifications and
feel they solve the notification problem better than both Windows and
the current Notify OSD bubbles (which have none the less made great
progress in unifying notifications on Ubuntu).

I'll assume that once the notification text fades there is a menu
indicator that can retrieve (at least some) past messages, and launch
the app used to view them. Going along Android lines a click on the
indicator could bring up a full-screen notification window (at the
user's convenience) and be easily dismissed or used to launch an email
or IM application for instance.

I believe this indicator would work great both for a mouse (click the
indicator) or with a touch gesture from the top of the screen (as on
Android).

For any notification that was truely not worth keeping around it could
"fade" from the collapsed notification window after 5 seconds or so
(never to be seen again or missed) or be clicked to dismiss if the
user is curious and opens the notification window shortly after the
notification to see what they missed. Apps would either tag their
notifications to persist for long periods or to fade almost
immediately (and of course the notification your gif illustrates fades
the same way as the current Notify OSD bubbles).

On Fri, Sep 17, 2010 at 2:24 PM, Apoorva Sharma  wrote:
> I went ahead and made a mockup of my "notification in the panel" idea,
> borrowing heavily from what android does. I've attached an animated gif
> showing a basic notification popping up.
>
> I want to make it clear that the entire panel does not fade out, but simply
> the indicator-menus and notification applet, and like notify-osd, fades out
> if the user brings the pointer over it, trying  This keeps all windows
> visible, and all panel icons visible.
>
> Another failure of the mockup is that the message indicator should light up
> after the notification.
>
> What do you think?
>
> ___
> Mailing list: https://launchpad.net/~ayatana
> Post to     : ayatana@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~ayatana
> More help   : https://help.launchpad.net/ListHelp
>
>

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] unity and notifications

[Dylan McCall]

On Fri, Sep 17, 2010 at 2:24 PM, Apoorva Sharma  wrote:
> I went ahead and made a mockup of my "notification in the panel" idea,
> borrowing heavily from what android does. I've attached an animated gif
> showing a basic notification popping up.
>
> I want to make it clear that the entire panel does not fade out, but simply
> the indicator-menus and notification applet, and like notify-osd, fades out
> if the user brings the pointer over it, trying  This keeps all windows
> visible, and all panel icons visible.
>
> Another failure of the mockup is that the message indicator should light up
> after the notification.
>
> What do you think?


Looks really great to me, but on a lower level I think this is
stretching the current components pretty far.

I think it demonstrates a big pain point for the message indicator,
really. So, we get this nice, big message in the panel and then it
shrinks down to a menu item inside a little icon surrounded by other
little icons. Let's say there are a few different indicators lit up
for different reasons, too. There is lots of noise there, and the
message which was just given so much importance has been pressed into
a tiny corner.
We're forcing the user to hunt for something we were just dangling in
front of his or her eyes.

Here's what I love and respect about Android's arrangement:

 * Quick, momentary notification bubbles (like NotifyOSD provides) are
entirely their own thing and everyone agrees on that point.
 * Long-lasting notifications (of all sorts) are created under a
different interface and appear in the message tray. Again, very
specific kind of design. (What libnotify + notification-daemon should
have been). There's only one way these can be interacted with
(clicking them), but there are lots of possibilities for how they are
displayed.

For Android's title bar, consider that it doesn't hide messages behind
categories. If an application is saying something, Android assumes
it's of importance to the user and presents it very clearly.

So, that is a beautiful mockup and it's close to the first bit of
Android's nice title bar messages, but I think the rest is important,
too :)


Dylan

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] unity and notifications

[Conscious User]

> I think it demonstrates a big pain point for the message indicator,
> really. So, we get this nice, big message in the panel and then it
> shrinks down to a menu item inside a little icon surrounded by other
> little icons. Let's say there are a few different indicators lit up
> for different reasons, too. There is lots of noise there, and the
> message which was just given so much importance has been pressed into
> a tiny corner.
> We're forcing the user to hunt for something we were just dangling in
> front of his or her eyes.

Not exactly a solution, but it's interesting to remember that the
original mockups for NotifyOSD included a subtle minimizing
animation which made very evident that the notification went to
the messaging menu.

http://www.markshuttleworth.com/archives/253



___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] unity and notifications

[zekopeko]

IIRC the main problem with that approach is the movement being
distracting to the user.

On Sat, Sep 18, 2010 at 4:51 PM, Conscious User  wrote:
>
>> I think it demonstrates a big pain point for the message indicator,
>> really. So, we get this nice, big message in the panel and then it
>> shrinks down to a menu item inside a little icon surrounded by other
>> little icons. Let's say there are a few different indicators lit up
>> for different reasons, too. There is lots of noise there, and the
>> message which was just given so much importance has been pressed into
>> a tiny corner.
>> We're forcing the user to hunt for something we were just dangling in
>> front of his or her eyes.
>
> Not exactly a solution, but it's interesting to remember that the
> original mockups for NotifyOSD included a subtle minimizing
> animation which made very evident that the notification went to
> the messaging menu.
>
> http://www.markshuttleworth.com/archives/253
>
>
>
> ___
> Mailing list: https://launchpad.net/~ayatana
> Post to     : ayatana@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~ayatana
> More help   : https://help.launchpad.net/ListHelp
>

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] unity and notifications

[Conscious User]

Le samedi 18 septembre 2010 à 16:57 +0200, zekopeko a écrit :
> IIRC the main problem with that approach is the movement being
> distracting to the user.

It can be argued, however, that such distraction is much lower
if the notifications are given in the panel, like the previous
mockup proposes.


> On Sat, Sep 18, 2010 at 4:51 PM, Conscious User  wrote:
> >
> >> I think it demonstrates a big pain point for the message indicator,
> >> really. So, we get this nice, big message in the panel and then it
> >> shrinks down to a menu item inside a little icon surrounded by other
> >> little icons. Let's say there are a few different indicators lit up
> >> for different reasons, too. There is lots of noise there, and the
> >> message which was just given so much importance has been pressed into
> >> a tiny corner.
> >> We're forcing the user to hunt for something we were just dangling in
> >> front of his or her eyes.
> >
> > Not exactly a solution, but it's interesting to remember that the
> > original mockups for NotifyOSD included a subtle minimizing
> > animation which made very evident that the notification went to
> > the messaging menu.
> >
> > http://www.markshuttleworth.com/archives/253



___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] unity and notifications

[Conscious User]

Le vendredi 17 septembre 2010 à 16:24 -0500, Apoorva Sharma a écrit :
> I went ahead and made a mockup of my "notification in the panel" idea,
> borrowing heavily from what android does. I've attached an animated
> gif showing a basic notification popping up.
> 
> I want to make it clear that the entire panel does not fade out, but
> simply the indicator-menus and notification applet, and like
> notify-osd, fades out if the user brings the pointer over it, trying
> This keeps all windows visible, and all panel icons visible.
> 
> Another failure of the mockup is that the message indicator should
> light up after the notification.
> 
> What do you think?

You know what I absolutely *love* about this mockup? It fits
remarkably well with the fact that all indicators are menus.

Let's suppose that the user was in process of interacting
with one of the indicators. Then a notification appears.
He does not interrupt the action, thus fading the notification
when the cursor goes over it.

Here's the catch: the cursor will not stay there for more
than a split second! Because indicators are menus, whatever
the user wanted to do will involve him moving the mouse
downwards, to the adequate menu item, right after clicking!
Then the notification will be free to fade in again.

(ok, this is not exactly true for all cases... the indicator
might be clicked just for the user to read info on some of
the itens, but this sounds much less frequent)

The only thing I think this mockup does not cover is the
case of merging notifications, which I think is a very nice
feature of OSD.



___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] unity and notifications

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Michael Jonker wrote on 17/09/10 13:58:
>
> It seems that, under the subject of 1)Unity  2)and notifications, the
> most discussion is concerning the 'Notification Bubble' (Thanks Matthew
> for pointing to the spec)

The specification is a separate document.


> 2) Yes - the current implementation of the bubble is functional. It
> notifies the user, it does fade when the mouse cursor is over it and
> you can work below it. Many people feel though that it hangs around
> too long

Often it does hang around too long, because length-based duration has
not been implemented yet. 

>  and is visually invasive.

Yes. Its current appearance makes it look clickable when it is not, and
does not suit any theme other than Ambiance (not even Radiance).

>How do we make it get out of the way
> intuatively and quickly without being accidentally dismissed?
> Suggestions so far:
> 
> -A heuristic approach
> -It does not reappear after a 'fade'
> -It stays in panel (against design guidelines)
> -It briefly goes to panel as a fading button after dismissal
> -A combination of above
> -Apologies if I missed any suggestions
> 
> 1) The topic of the original post - how does this work in Unity. More
> trickily - how does it work on touchscreen?
> In my opinion, if we can solve this elegantly the rest will follow.

When we designed Notify OSD, we did not have touch screens in mind.

> The starting point i feel is: You touch it and it goes away.
>...

So, how would you avoid touching it by accident just after it appears?

- -- 
Matthew Paul Thomas
http://mpt.net.nz/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkyXQDUACgkQ6PUxNfU6ecrMuQCgwsJWy6Ss2URx1x6nyJNuM/Yn
5DgAn3omx69i4Y3/4CCxAKM0QB6UG+Gs
=Yab0
-END PGP SIGNATURE-

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] unity and notifications

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Diego Moya wrote on 17/09/10 13:59:
> 
> On 17 September 2010 14:18, Matthew Paul Thomas wrote:
>...
>> Well, Jef had some odd ideas about user input and focus of attention.
>> He thought, for example, that error messages should behave rather like
>> Notify OSD bubbles, undismissable and gradually fading, but that there
>> should be a keyboard command to adjust their transparency ("The humane
>> interface", pp116-117 ). And he thought it would
>> make sense to insert incoming e-mail messages into whatever document
>> you were editing at the time (p176 ).
> 
> Yes, those bubbles are actually quite similar to what NotifyOSD tries
> to do. But look how Jef required a way for the user to take control of
> how bubbles are presented.

Which was unrealistic. By the time you had remembered, and then typed,
the command to reduce the opacity, the error would have faded away by
itself anyway.

> He also thought that "a document that stores all messages for later
> retrieval is essential".

That was for error messages, and it was also unrealistic -- because it
didn't address the problem of how, when returning to the computer, you
would tell that the task had failed in the first place.

>  The Ayatana notification design took the
> original idea and then changed it to its opposite by removing every
> safeguard feature to put user in control and keep it humane.

That is not true. I had read the book years ago, and seen that idea, and
thought it was crack (mainly because the mockup was obviously rigged to
ensure the error text didn't overlap the background text). But by 2008
I'd forgotten about it.

> The current design for OSD notifications is heavily modal - it blocks
> access to the visible area until the bubble disappears, and it doesn't
> give the user a way to claim that blocked area. The provided workaround
> to reach the blocked screen area requires a complex interaction (the
> repeated fading out and in as the mouse moves away) that can be quite
> distracting and doesn't work if the user needs the cursor elsewhere.
>...

We could do better with the fading, but I find myself unable to imagine
a situation where someone simultaneously (a) needs to see what's under a
notification bubble and (b) "needs the cursor elsewhere". Can you give
an example?

- -- 
Matthew Paul Thomas
http://mpt.net.nz/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkyXRcoACgkQ6PUxNfU6ecqwmwCfR1HtHw+bHCf5H1iAmiwOjpgu
o3wAoLQoMlsHSAKgzXtx+yDu2xocyAVP
=igas
-END PGP SIGNATURE-

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] unity and notifications

[Diego Moya]

I support the NotifyOSD goal to create not intrusive messages, but I think
the current design falls short of that goal. Now that it has been in the
wild and used in real contexts, some of the initial controversial decisions
that were boldly supported should now be reconsidered, in particular the
zero-configuration and no-dismissable bubbles.

In my opinion some kind of lightweigh configurability would help tailoring
the tool and making it useful for frindge cases, avoiding the
one-size-fits-all problems. For example, allowing dragging the bubble to
persistently change the placement of notifications would put users back in
control to fine-tune their experience.

Said that, I like the mockup that places notifications at the indicator
menus area. At least in that case the only information obscured is system
state, never user content.



On 20 September 2010 13:30, Matthew Paul Thomas wrote:

>
> > 2) Yes - the current implementation of the bubble is functional. It
> > notifies the user, it does fade when the mouse cursor is over it and
> > you can work below it. Many people feel though that it hangs around
> > too long
>
> Often it does hang around too long, because length-based duration has
> not been implemented yet. 
>

Length-based duration wouldn't help in cases were the user didn't want to
see the notification but the content below it. In those cases only closing
or moving the bubble would relieve the feeling that the notification is
being obstructive.


Diego Moya wrote on 17/09/10 13:59:

> > Yes, those bubbles are actually quite similar to what NotifyOSD tries
> > to do. But look how Jef required a way for the user to take control of
> > how bubbles are presented.
>
> Which was unrealistic. By the time you had remembered, and then typed,
> the command to reduce the opacity, the error would have faded away by
> itself anyway.
>

I think it was meant to configure the default opacity to a level at which
the user feels comfortable. The Ayatana design dismissed the idea to let
users configure notifications to their needs, and I never got the reason for
that.



> > The Ayatana notification design took the
> > original idea and then changed it to its opposite by removing every
> > safeguard feature to put user in control and keep it humane.
>
> That is not true. I had read the book years ago, and seen that idea, and
> thought it was crack (mainly because the mockup was obviously rigged to
> ensure the error text didn't overlap the background text). But by 2008
> I'd forgotten about it.
>

And then you went designing a notification system based on translucent,
non-dismissible bubbles? I didn't mean using a similar design was a
deliberate decision, but surely it had some influence?



>
> > The current design for OSD notifications is heavily modal - it blocks
> > access to the visible area until the bubble disappears, and it doesn't
> > give the user a way to claim that blocked area. The provided workaround
> > to reach the blocked screen area requires a complex interaction (the
> > repeated fading out and in as the mouse moves away) that can be quite
> > distracting and doesn't work if the user needs the cursor elsewhere.
> >...
>
> We could do better with the fading, but I find myself unable to imagine
> a situation where someone simultaneously (a) needs to see what's under a
> notification bubble and (b) "needs the cursor elsewhere". Can you give
> an example?
>
>
I think Michael Jonker already provided one at this very thread; that's why
I elaborated on it. When working with the Gimp, he needed to see the layers
panel while working on the scene, and it was obscured by the bubble.

This will happen in general whenever the top-right corner of the application
contains an information panel, which is intended to contain readable data
that can be read with a glance while working on the main interface. This is
quite usual in IDEs and design tools.


>When we designed Notify OSD, we did not have touch screens in mind.
Does that mean they will not be supported, ever? Or are suggestions welcome
to also support touch screens, even if it implies changing the original
design?


>> The starting point i feel is: You touch it and it goes away.
>>...
>
>So, how would you avoid touching it by accident just after it appears?

Several viable options to avoid the problem:
- Touching it don't dismiss it for the first 0.5 second, enough for the user
to notice it.
- Don't show notifications if there has been user interaction in the
previous 5 seconds.
- Even if the bubble is closed, allow the user to reopen it from the Me
menu.
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] unity and notifications

[Luke Benstead]

>
>> We could do better with the fading, but I find myself unable to imagine
>> a situation where someone simultaneously (a) needs to see what's under a
>> notification bubble and (b) "needs the cursor elsewhere". Can you give
>> an example?
>>
>>
> I think Michael Jonker already provided one at this very thread; that's why
> I elaborated on it. When working with the Gimp, he needed to see the layers
> panel while working on the scene, and it was obscured by the bubble.
>
> This will happen in general whenever the top-right corner of the
> application contains an information panel, which is intended to
> contain readable data that can be read with a glance while working on the
> main interface. This is quite usual in IDEs and design tools.
>
>
Also of course, the Google search box in FF which I find regularly
obstructed while typing (unless that's been fixed in Maverick or by
"cursor", MPT meant cursor or caret).

Luke.
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] unity and notifications

[Mark Curtis]

Trying to find an area of the screen that won't obscure all applications is 
fruitless. There is no single location that won't end up obscuring SOME 
application's interface.
Popular applications such as GIMP (right and left), Inkscape (bottom and left) 
and Firefox (top) total to using all sides of the screen. OpenOffice.org 
Impress alone uses every side of the screen and is an application included by 
default.

Date: Mon, 20 Sep 2010 16:10:35 +0100
From: kaz...@gmail.com
To: turi...@gmail.com
CC: ayatana@lists.launchpad.net
Subject: Re: [Ayatana] unity and notifications






We could do better with the fading, but I find myself unable to imagine

a situation where someone simultaneously (a) needs to see what's under a

notification bubble and (b) "needs the cursor elsewhere". Can you give

an example?



I think Michael Jonker already provided one at this very thread; that's why I 
elaborated on it. When working with the Gimp, he needed to see the layers panel 
while working on the scene, and it was obscured by the bubble.




This will happen in general whenever the top-right corner of the application 
contains an information panel, which is intended to contain readable data that 
can be read with a glance while working on the main interface. This is quite 
usual in IDEs and design tools.


Also of course, the Google search box in FF which I find regularly obstructed 
while typing (unless that's been fixed in Maverick or by "cursor", MPT meant 
cursor or caret).


Luke. 


___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp   
  ___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] unity and notifications

[Luke Benstead]

On 20 September 2010 16:55, Mark Curtis  wrote:

>  Trying to find an area of the screen that won't obscure all applications
> is fruitless. There is no single location that won't end up obscuring SOME
> application's interface.
> Popular applications such as GIMP (right and left), Inkscape (bottom and
> left) and Firefox (top) total to using all sides of the screen.
> OpenOffice.org Impress alone uses every side of the screen and is an
> application included by default.
>
>
I can only think of two options to display notifications while trying not to
obscure a user's workspace:

a.) Don't display notifications in the working area (e.g. display them in
the panel, Android-style)
b.) Resize the working area to allow the notification to display (e.g. slide
up from the bottom resizing all open windows - potentially jarring)

If we are accepting we must obscure the user's working area (which isn't
really ideal) we should allow the user to either configure the notifications
so they don't interrupt their specific workflow, allow them to be closed
(still not ideal; interrupting flow), or just be a little arrogant about it
and if they don't like it they can remove them (current approach).

Luke.
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] unity and notifications

[Diego Moya]

On 20 September 2010 18:25, Luke Benstead wrote:

>
> I can only think of two options to display notifications while trying not
> to obscure a user's workspace:
>
> a.) Don't display notifications in the working area (e.g. display them in
> the panel, Android-style)
> b.) Resize the working area to allow the notification to display (e.g.
> slide up from the bottom resizing all open windows - potentially jarring)
>
> If we are accepting we must obscure the user's working area (which isn't
> really ideal) we should allow the user to either configure the notifications
> so they don't interrupt their specific workflow, allow them to be closed
> (still not ideal; interrupting flow), or just be a little arrogant about it
> and if they don't like it they can remove them (current approach).
>
> Luke.
>
>
+1 all you said.

The last option (current approach) makes it an all-or-nothing proposition
i.e. users that don't find the default design will not benefit at all from
notifications, being forced to disable them. Being a bit more flexible
should make notifications useful to more people and a smoother experience to
those who can use them.
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] unity and notifications

[Apoorva Sharma]

On Mon, Sep 20, 2010 at 10:55 AM, Mark Curtis  wrote:

>  Trying to find an area of the screen that won't obscure all applications
> is fruitless. There is no single location that won't end up obscuring SOME
> application's interface.
> Popular applications such as GIMP (right and left), Inkscape (bottom and
> left) and Firefox (top) total to using all sides of the screen.
> OpenOffice.org Impress alone uses every side of the screen and is an
> application included by default.
>
>
The panel?
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] unity and notifications

[Mark Curtis]

Wouldn't that block EVERY application's "File Edit, etc" menu? I'm referring 
specifically Unity here as the subject is "Unity and notifications".

Date: Mon, 20 Sep 2010 15:28:00 -0500
Subject: Re: [Ayatana] unity and notifications
From: appi2...@gmail.com
To: merkin...@hotmail.com
CC: ayatana@lists.launchpad.net



On Mon, Sep 20, 2010 at 10:55 AM, Mark Curtis  wrote:






Trying to find an area of the screen that won't obscure all applications is 
fruitless. There is no single location that won't end up obscuring SOME 
application's interface.
Popular applications such as GIMP (right and left), Inkscape (bottom and left) 
and Firefox (top) total to using all sides of the screen. OpenOffice.org 
Impress alone uses every side of the screen and is an application included by 
default.



The panel?
  ___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] unity and notifications

[Apoorva Sharma]

On Mon, Sep 20, 2010 at 3:31 PM, Mark Curtis  wrote:

>  Wouldn't that block EVERY application's "File Edit, etc" menu? I'm
> referring specifically Unity here as the subject is "Unity and
> notifications".
>
>
I meant just the indicator icons part, since those only display system
status, and since the messages display system status, putting those in the
same spot wouldn't obstruct nearly as much, and also make more sense.
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] unity and notifications

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Diego Moya wrote on 20/09/10 15:59:
>...
> Diego Moya wrote on 17/09/10 13:59:
>>
>>> Yes, those bubbles are actually quite similar to what NotifyOSD tries
>>> to do. But look how Jef required a way for the user to take control
>>> of how bubbles are presented.
>>
>> Which was unrealistic. By the time you had remembered, and then typed,
>> the command to reduce the opacity, the error would have faded away by
>> itself anyway.
>
> I think it was meant to configure the default opacity to a level at
> which the user feels comfortable. The Ayatana design dismissed the idea
> to let users configure notifications to their needs, and I never got
> the reason for that.

For the same reason operating systems don't have visible controls for
configuring the appearance of tooltips. If they're designed right, they
should be below the threshold of triviality. If a substantial proportion
of users want to configure them, there's something wrong that we need to
fix.

>>> The Ayatana notification design took the
>>> original idea and then changed it to its opposite by removing every
>>> safeguard feature to put user in control and keep it humane.
>>
>> That is not true. I had read the book years ago, and seen that idea,
>> and thought it was crack (mainly because the mockup was obviously
>> rigged to ensure the error text didn't overlap the background text).
>> But by 2008 I'd forgotten about it.
>
> And then you went designing a notification system based on translucent,
> non-dismissible bubbles? I didn't mean using a similar design was a
> deliberate decision, but surely it had some influence?

No, not at all. When I say "I'd forgotten about it", I mean, I'd
forgotten about it. :-)

>...
>> We could do better with the fading, but I find myself unable to
>> imagine a situation where someone simultaneously (a) needs to see
>> what's under a notification bubble and (b) "needs the cursor
>> elsewhere". Can you give an example?
>
> I think Michael Jonker already provided one at this very thread; that's
> why I elaborated on it. When working with the Gimp, he needed to see
> the layers panel while working on the scene, and it was obscured by the
> bubble.

As Mark Curtis said, that's a potential problem no matter where the
bubble appears. And any interaction to move or dismiss the bubble would
be just as much of an interruption as moving to fade it.

>...
>> When we designed Notify OSD, we did not have touch screens in mind.
>
> Does that mean they will not be supported, ever?

They're "supported" right now.

>  Or are suggestions
> welcome to also support touch screens, even if it implies changing the
> original design?

That too.

>>> The starting point i feel is: You touch it and it goes away.
>...
>> So, how would you avoid touching it by accident just after it appears?
>
> Several viable options to avoid the problem:
> - Touching it don't dismiss it for the first 0.5 second, enough for the
> user to notice it.

That's a possibility, but we would need to define more carefully what
"don't dismiss it" means. If I clicked on the part of a bubble above a
window's close button, 0.45 seconds after the bubble appeared, would it
close the window, or do nothing at all?

> - Don't show notifications if there has been user interaction in the
> previous 5 seconds.

Interesting idea, though it might result in a long queue.

> - Even if the bubble is closed, allow the user to reopen it from the Me
> menu.

Many if not most notification bubbles have nothing to do with social
networks or instant messaging, so that would be a poor fit.

- -- 
Matthew Paul Thomas
http://mpt.net.nz/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkyYueAACgkQ6PUxNfU6ecrnmACgqwtxbKPfsmpNHIOr7Zx/T2y1
WSMAoMXnuisj7UuaWm1tZKFfSXRz8iFx
=7zXZ
-END PGP SIGNATURE-

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] unity and notifications

[Diego Moya]

On 21 September 2010 15:57, Matthew Paul Thomas wrote:

> Diego Moya wrote on 20/09/10 15:59:
> > I think it was meant to configure the default opacity to a level at
> > which the user feels comfortable. The Ayatana design dismissed the idea
> > to let users configure notifications to their needs, and I never got
> > the reason for that.
>
> For the same reason operating systems don't have visible controls for
> configuring the appearance of tooltips. If they're designed right, they
> should be below the threshold of triviality. If a substantial proportion
> of users want to configure them, there's something wrong that we need to
> fix.
>

Both situations are not really comparable. Notifications have proven to be a
more difficult problem than tooltips, which are basically local to a single
widget each time (and notifications are unrelated to the content below
them). Notifications are global to the system, so you should ultimately take
the whole system into account to get it right. The smallest misappreciation
could produce a less-than-optimal solution. You should be omniscient to
create your "right design"!

That scorched earth approach of zero-configuration ("if it ain't perfect,
disable it!") means that until you get it right some people will suffer in
the meantime without a way to fix it, even assuming that the perfect design
exists.

Also think that "configuration" doesn't need to be "panel with check boxes".
Allowing direct manipulation of bubbles (for example to reposition them)
would potentially fix with a one-time drag-and-drop any problem of obscured
content, without being a burden to the user.




> > I think Michael Jonker already provided one at this very thread; that's
> > why I elaborated on it. When working with the Gimp, he needed to see
> > the layers panel while working on the scene, and it was obscured by the
> > bubble.
>
> As Mark Curtis said, that's a potential problem no matter where the
> bubble appears. And any interaction to move or dismiss the bubble would
> be just as much of an interruption as moving to fade it.
>

But less severe than having to wait 5 seconds. Also it usually should be
done just once, while obscured content can be annoying every time.



> >>> The starting point i feel is: You touch it and it goes away.
> >...
> >> So, how would you avoid touching it by accident just after it appears?
> >
> > Several viable options to avoid the problem:
> > - Touching it don't dismiss it for the first 0.5 second, enough for the
> > user to notice it.
>
> That's a possibility, but we would need to define more carefully what
> "don't dismiss it" means. If I clicked on the part of a bubble above a
> window's close button, 0.45 seconds after the bubble appeared, would it
> close the window, or do nothing at all?
>

It should do nothing, because the meaning of the click would be ambiguous.
This counts as a mode error, but it's less severe than the alternative which
is a misplaced command.

This is a personal preference, but I really don't like the idea that
clicking on a widget hidden below the notification should have some effect.
The whole "click-transparent notification" idea in the current design is
disturbing to me, it always felt weird and uncertain on what would be the
result.



>
> > - Don't show notifications if there has been user interaction in the
> > previous 5 seconds.
>
> Interesting idea, though it might result in a long queue.
>

Only in cases of really heavy user interaction, in which notifications
wouldn't be noticed anyway. Most user flow (except for typing long
paragraphs) is made in small bursts of short interaction, wait, evaluate UI
feedback, more interaction.

The 5 seconds could be fine-tuned through some user testing, maybe 2 or 3
seconds would be enough. Also, notifications queued for more than one minute
could be safely discarded as irrelevant, just as if the user was away.

In my suggestions I'm relying heavily on the notion that missing a
notification is not a big deal - I think that was one of the design
guidelines. I'm just pushing it to the extreme in order to reduce
interruptions to the user flow while working with application content.



>
> > - Even if the bubble is closed, allow the user to reopen it from the Me
> > menu.
>
> Many if not most notification bubbles have nothing to do with social
> networks or instant messaging, so that would be a poor fit.
>

... or somewhere else, where logging that class of notifications was
appropriate. If there isn't a sensible place where to log the message in a
particular bubble, it wasn't that important to begin with.
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] unity and notifications

[Diego Moya]

On 21 September 2010 15:57, Matthew Paul Thomas wrote:

>
>> For the same reason operating systems don't have visible controls for
>> configuring the appearance of tooltips. If they're designed right, they
>> should be below the threshold of triviality. If a substantial proportion
>> of users want to configure them, there's something wrong that we need to
>> fix.
>>
>
>
Moreover: not even a design as simple as tooltips can be got right once and
for all. For example Microsoft did a complete overhaul of their tooltips
engine for Office 2007, enabling giant tooltips that contain snippets of the
help files. The new tooltips work much better than the old ones in that
context (a giant software suite full of obscure features) thus proving that
even a simple, general design can be enhanced for particular use cases.

(And for the curious, yes, the Office tooltips allow for some configuration,
if only for nostalgics to select the old behavior).
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] unity and notifications

[frederik.nn...@gmail.com]

On Mon, Sep 20, 2010 at 19:00, Diego Moya  wrote:

>
> On 20 September 2010 18:25, Luke Benstead wrote:
>
>>
>> I can only think of two options to display notifications while trying not
>> to obscure a user's workspace:
>>
>> a.) Don't display notifications in the working area (e.g. display them in
>> the panel, Android-style)
>> b.) Resize the working area to allow the notification to display (e.g.
>> slide up from the bottom resizing all open windows - potentially jarring)
>>
>> If we are accepting we must obscure the user's working area (which isn't
>> really ideal) we should allow the user to either configure the notifications
>> so they don't interrupt their specific workflow, allow them to be closed
>> (still not ideal; interrupting flow), or just be a little arrogant about it
>> and if they don't like it they can remove them (current approach).
>>
>
>> Luke.
>>
>>
> +1 all you said.
>
> The last option (current approach) makes it an all-or-nothing proposition
> i.e. users that don't find the default design will not benefit at all from
> notifications, being forced to disable them. Being a bit more flexible
> should make notifications useful to more people and a smoother experience to
> those who can use them.
>

The need for flexibility in such a straightforward application would be a
clear trait of poor design or poor implementation.

I think the design of our pretty bubbles is good, implementation not yet
complete and i have only one flaw to comment on:
Notify only!
ATM the bubbles don't only notify, they also relay complete IM messages..
that is an abuse by Empathy, which must be stopped IMO.
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] unity and notifications

[Mark Russell]

On 09/22/2010 06:16 AM, frederik.nn...@gmail.com wrote:
> I think the design of our pretty bubbles is good, implementation not yet
> complete and i have only one flaw to comment on:
> Notify only!
> ATM the bubbles don't only notify, they also relay complete IM messages..
> that is an abuse by Empathy, which must be stopped IMO.

+1.  When people minimize their chat window it's often because they
don't want others reading the IMs over their shoulder.  The current
behavior is precisely what shouldn't happen.

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] unity and notifications

[Diego Moya]

On 22 September 2010 12:16, frederik.nn...@gmail.com wrote:

> On Mon, Sep 20, 2010 at 19:00, Diego Moya wrote:
>
>> The last option (current approach) makes it an all-or-nothing proposition
>> i.e. users that don't find the default design will not benefit at all from
>> notifications, being forced to disable them. Being a bit more flexible
>> should make notifications useful to more people and a smoother experience to
>> those who can use them.
>>
>
> The need for flexibility in such a straightforward application would be a
> clear trait of poor design or poor implementation.
>

There seems to be this idea that allowing user control is poor design.

*Requiring* flexibility (i.e. forcing users to configure the tool for common
cases) would be bad design. But enabling users to harness the software tool
for usages not predicted by the designer, can only be advantageous for both
the user and the tool.

Concerning the matter at hand, the need for flexibility to reposition
notifications follows from bubbles obscuring user content, which is a
potential problem and a flaw in the design. The current "make translucent on
mouse over" is at best an awkward workaround for the initial problem, as
well as a distracting interaction.

Apoorva Sharma proposed in this trhead a mockup that wouldn't need
configuration as it only obscures system information, which IMHO is a better
design because it avoids the basic flaw of bubbles.
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] unity and notifications

[Conscious User]

Le mercredi 22 septembre 2010 à 11:01 -0400, Mark Russell a écrit :
> On 09/22/2010 06:16 AM, frederik.nn...@gmail.com wrote:
> > I think the design of our pretty bubbles is good, implementation not yet
> > complete and i have only one flaw to comment on:
> > Notify only!
> > ATM the bubbles don't only notify, they also relay complete IM messages..
> > that is an abuse by Empathy, which must be stopped IMO.
> 
> +1.  When people minimize their chat window it's often because they
> don't want others reading the IMs over their shoulder.  The current
> behavior is precisely what shouldn't happen.

This is an interesting point but beyond the scope of this list. The
problem exists regardless if the user is using NotifyOSD or the
vanilla notification-daemon.

It is something to be discussed with the Empathy devs (and Pidgin
devs, and Gajim devs, and aMSN devs, and Emesene devs, etc.)



___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] unity and notifications

[Conscious User]

> There seems to be this idea that allowing user control is poor design.


To be more accurate, the idea is that allowing user control is often a
way to sweep problems under the rug instead of actually solving them.

Or, to put in another way, configurability is an option that makes
people stop thinking too soon about a problem.

Take the current discussion, for example. If everyone agreed from the
beginning that repositioning the bubble was the way to go, Apoorva
might have never proposed his mockup.

Sometimes configurability *is* the best option, but rarely this
conclusion is reached in an honest way.



___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] unity and notifications

[David Hamm]

"To be more accurate, the idea is that allowing user control is often a
way to sweep problems under the rug instead of actually solving them."

Hear Hear

*slams водка mug on table*
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] unity and notifications

[Walter Wittel]

On Wed, Sep 22, 2010 at 2:52 PM, David Hamm  wrote:
> "To be more accurate, the idea is that allowing user control is often a
> way to sweep problems under the rug instead of actually solving them."
> Hear Hear

And this further reinforces Diego's statement:
"Apoorva Sharma proposed in this trhead a mockup that wouldn't need
configuration as it only obscures system information, which IMHO is a
better design because it avoids the basic flaw of bubbles"

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] unity and notifications

[ubu...@kitterman.com]

"David Hamm"  wrote:

>"To be more accurate, the idea is that allowing user control is often a
>way to sweep problems under the rug instead of actually solving them."
>
>Hear Hear
>
>*slams водка mug on table*

Yes, but extremism about this is equally dangerous. It results in a design that 
is well suited for a single,  possibly narrow, use case and useless for 
anything else.  

That's great if one is designing for a dedicated system like a cable TV set top 
box. For an operating system, not so much.

Scott K

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] unity and notifications

[frederik.nn...@gmail.com]

On Thu, Sep 23, 2010 at 00:34, ubu...@kitterman.com wrote:

>
>
> "David Hamm"  wrote:
>
> >"To be more accurate, the idea is that allowing user control is often a
> >way to sweep problems under the rug instead of actually solving them."
> >
> >Hear Hear
> >
> >*slams водка mug on table*
>
> Yes, but extremism about this is equally dangerous. It results in a design
> that is well suited for a single,  possibly narrow, use case and useless for
> anything else.
>

+1

everything should be either intelligently adaptive or individually
adjustable.. yet more important than that is the comfort of control. If a
control option in Targetuserland is not comfortable to use or to understand,
it doesn't deserve to be visible -> gconf.

The easiest types of comfortable control are themes. We already have them
for audio, for chrome and for single apps, now i suggest introducing
NotifyOSD support into the themes Radiance and Ambiance..
That way, we could manipulate as much as the theming interface affords.
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] unity and notifications

[Apoorva Sharma]

On Wed, Sep 22, 2010 at 5:01 PM, Walter Wittel  wrote:

> And this further reinforces Diego's statement:
> "Apoorva Sharma proposed in this trhead a mockup that wouldn't need
> configuration as it only obscures system information, which IMHO is a
> better design because it avoids the basic flaw of bubbles"
>

Thanks for your approval of my design!

I went ahead and made an interactive mockup with HTML, CSS, and JavaScript.
Since it uses CSS3, it only works with Firefox 4, Chrome, and Epiphany. (In
Maverick)

Here's the link: http://dl.dropbox.com/u/510407/Test/index.html

What do you think?
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] unity and notifications

[Diego Moya]

On 23 September 2010 03:00, Apoorva Sharma wrote:

>
> Thanks for your approval of my design!
>
> I went ahead and made an interactive mockup with HTML, CSS, and JavaScript.
> Since it uses CSS3, it only works with Firefox 4, Chrome, and Epiphany. (In
> Maverick)
>
> Here's the link: http://dl.dropbox.com/u/510407/Test/index.html
>
> What do you think?
>

Smooth!

Can you give more contrast to the notification? Make it reverse video (black
on white), or at least a lighter brown background. This way it will be
easier to spot when a message arrives. I'm not sure whether the animation
alone will be enough to catch the user attention.

Also shouldn't it open to the right and cover the calendar and clock area?
At least in my browser it's opening to the left of the mail indicator, which
is covering the space dedicated to the taskbar.
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] unity and notifications

[frederik.nn...@gmail.com]

Hi Appi,

On Thu, Sep 23, 2010 at 10:21, Diego Moya  wrote:

>
>
> On 23 September 2010 03:00, Apoorva Sharma wrote:
>
>>
>> Thanks for your approval of my design!
>>
>> I went ahead and made an interactive mockup with HTML, CSS, and
>> JavaScript.
>> Since it uses CSS3, it only works with Firefox 4, Chrome, and Epiphany.
>> (In Maverick)
>>
>> Here's the link: http://dl.dropbox.com/u/510407/Test/index.html
>>
>> What do you think?
>>
>
>
> Also shouldn't it open to the right and cover the calendar and clock area?
> At least in my browser it's opening to the left of the mail indicator, which
> is covering the space dedicated to the taskbar.
>

i still suggest morphing out the info text field from the bottom of the
indicator array..
Replacing the indicators with a notification is also a good idea, but seems
to me to be more of a fancy theme for our notification bubbles, the default
imo should be near the indicators yet should not obscure them. Remember: the
indicator menus are for interaction, this area of the panel is for
interaction, the indicators are not only control LEDs to monitor the state
of a service..

obscuring a group of special menu buttons would be too obtrusive.. Also
remember that you are consciously adding constraint to the already spartan
design up there, this should only happen when your use case's affordance
character strongly depends on adding this constraint. Constraint per se has
no function other than to limit, prevent, secure or protect.
Only critical system alerts would in this case be valid for your design, as
great as it is, still..

Thanks for an incredible addition to the markup-based interaction designs..
i hope we will continue to see those css3 mockups here.. :D
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] unity and notifications

[Conscious User]

> i still suggest morphing out the info text field from the bottom of
> the indicator array..
> Replacing the indicators with a notification is also a good idea, but
> seems to me to be more of a fancy theme for our notification bubbles,
> the default imo should be near the indicators yet should not obscure
> them. Remember: the indicator menus are for interaction, this area of
> the panel is for interaction, the indicators are not only control LEDs
> to monitor the state of a service..
> 
> obscuring a group of special menu buttons would be too obtrusive..


I made a previous point about this, which unfortunately was completely
ignored: the indicators are *menus*, which means that interacting with
them involves clicking on them and *immediately after* moving the
cursor down, thus freeing the notification to reappear.

There might be situations when the user has no reason to move the
cursor afterwards (ex: he clicked on indicator-datetime just to
see the calendar), but in those he also has no strong reason to
stand still either.




___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] unity and notifications

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Diego Moya wrote on 21/09/10 16:48:
> 
> On 21 September 2010 15:57, Matthew Paul Thomas wrote:
>...
>> For the same reason operating systems don't have visible controls for
>> configuring the appearance of tooltips. If they're designed right,
>> they should be below the threshold of triviality. If a substantial
>> proportion of users want to configure them, there's something wrong
>> that we need to fix.
> 
> Both situations are not really comparable. Notifications have proven to
> be a more difficult problem than tooltips, which are basically local to
> a single widget each time (and notifications are unrelated to the
> content below them). Notifications are global to the system, so you
> should ultimately take the whole system into account to get it right.

Perhaps scrollbars are a better example, then. Scrollbars as we know
them are deceptively complex, and took about three years to get right
. But pretty
much the only configuration you can make to them now is changing their
width in Windows, and their arrow button positions in Mac OS X.

> The smallest misappreciation could produce a less-than-optimal
> solution. You should be omniscient to create your "right design"!

Not omniscient, just following a standard design process.

> That scorched earth approach of zero-configuration ("if it ain't
> perfect, disable it!") means that until you get it right some people
> will suffer in the meantime without a way to fix it, even assuming that
> the perfect design exists.

There's nothing "disabled" as far as I know. But every added option
would make it harder to implement and to test.

> Also think that "configuration" doesn't need to be "panel with check
> boxes". Allowing direct manipulation of bubbles (for example to
> reposition them) would potentially fix with a one-time drag-and-drop
> any problem of obscured content, without being a burden to the user.
>...
> This is a personal preference, but I really don't like the idea that
> clicking on a widget hidden below the notification should have some
> effect. The whole "click-transparent notification" idea in the current
> design is disturbing to me, it always felt weird and uncertain on what
> would be the result.

Maybe, then, it would make sense for the bubble to bob out of the way
(e.g. down a bit) when you go to the corner, and stay there. No clicking
required.

>>> - Don't show notifications if there has been user interaction in the
>>> previous 5 seconds.
>...
> In my suggestions I'm relying heavily on the notion that missing a
> notification is not a big deal - I think that was one of the design
> guidelines. I'm just pushing it to the extreme in order to reduce
> interruptions to the user flow while working with application content.
> 
>>> - Even if the bubble is closed, allow the user to reopen it from
>>> the Me menu.
>> 
>> Many if not most notification bubbles have nothing to do with social
>> networks or instant messaging, so that would be a poor fit.
> 
> ... or somewhere else, where logging that class of notifications was
> appropriate. If there isn't a sensible place where to log the message
> in a particular bubble, it wasn't that important to begin with.

These points seem to contradict each other a bit. Our current approach
is that yes, missing a notification is not a big deal, and *therefore*
it's not important enough to have a global notification log. One reason
it might not be a big deal is because there is an application-specific
log, e.g. an IM chat.

- -- 
Matthew Paul Thomas
http://mpt.net.nz/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkykmS0ACgkQ6PUxNfU6ecqlgwCghxfvj+l/oR2Bpo7NEv8M+P2I
FIcAoJKfR6fy9MuOoUzho7Bjx74EMEj2
=uoVA
-END PGP SIGNATURE-

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] unity and notifications

[Mark Shuttleworth]

On 16/09/10 16:25, Conscious User wrote:
> Le jeudi 16 septembre 2010 à 13:29 +0100, Luke Benstead a écrit :
>>
>> On 15 September 2010 17:25, Greg K Nicholson  wrote:
>> On 15 September 2010 16:54, Conscious User
>>  wrote:
>> > I know it's the space for the confirmation bubbles, but I
>> think it
>> > would be much better if those appeared in another place
>> entirely,
>> > like a bottom corner.
>> 
>> 
>> I've suggested before that synchronous notifications (e.g.
>> volume)
>> should appear horizontally centred. Then the asynchronous
>> notifications (IM etc.) can appear immediately below the top
>> panel, at
>> the right.
>> 
>> No-one has come up with any drawback whatsoever to this design
>> —yet ;)
>> --
>> Greg
>> 
>> 
>> 
>>
>> That's definitely the best solution I've heard yet. Why are we not
>> doing that?
>>
>> Luke.
> As a matter of fact, because the confirmation bubbles have a fixed
> size, they can be placed pretty much anywhere with little issues.
>
> If I were to guess the reason of the current placement, is that the
> designers believe that giving the user two different places from
> which bubbles can come from is confusing. Can someone confirm?

We want to keep notifications and indicators in relatively close
proximity. Synchronous (keyboard-response, user-generated,
self-overwriting) notifications like volume-up and -down are on top,
because that area has more precious content (firefox search, for
example) than the area just below it, and because they are fixed-size,
where the async ones are variable-size.

Mark



signature.asc
Description: OpenPGP digital signature
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp