Re: [Ayatana] Regarding Notify-OSD's Position in Karmic Koala

[Tony Knott]

> The concept involved in volume and brightness gauges is different from
> regular notifications to the point I don't feel confortable in using the
> word "notifications" at all. I can't be "notified" of something I *expect*
> to see. I think "feedback" is a more appropriate world.

Oops, I noticed now that the spec actually uses the terms "notification"
and "confirmation". Forget about this point. The other one stands, though.
  
_
Windows Live Hotmail: Your friends can get your Facebook updates, right from 
Hotmail®.
http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_4:092009___
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] Regarding Notify-OSD's Position in Karmic Koala

[Tony Knott]

> Hey, slightly random, but could I suggest putting synchronous bubbles
> a bit above the bottom edge at the horizontal centre? (Where there
> used to be a popup for adjusting volume and brightness). I think there
> may have been some reason behind that approach :)

Jumping late to the discussion, but that's exactly what I've been thinking
lately. I think perhaps Gnome devs got it right from the beginning.

The concept involved in volume and brightness gauges is different from
regular notifications to the point I don't feel confortable in using the
word "notifications" at all. I can't be "notified" of something I *expect*
to see. I think "feedback" is a more appropriate world.

So I don't think it would be a stretch to think that the appearance and/or
positioning should be different as well.
  
_
Windows Live Hotmail: Your friends can get your Facebook updates, right from 
Hotmail®.
http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_4:092009___
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] Regarding Notify-OSD's Position in Karmic Koala

[Brett Cornwall]

Scott E. Armitage wrote:

  The middle of the screen, or the middle of the screen on the right-hand
side? I maintain that the centre of the screen is still a viable option for
synchronous notifications such as e.g. volume, brightness, etc. -- the user
is actively interfacing with the computer, they should easily see the
effects of that. The should also disappear quicker than async notifications.

Asynchronous notifications that you might not care about -- now /those/ make
a lot more sense to be tucked away in a corner such that they are easily
ignorable if you don't want to pay any attention to them.

I agree that middle of the screen on the right will not fly with anyone :-)

-Scott


  

Naturally, I meant the middle of the screen on the right-hand side.
Having a massive, jutting bar where this composing window just happens
to be opened will be the absolute offender to Notify-OSD and the spark
of a surefire fork. Unless the plan was to make the notification very
small/vertical?
-- 
-Brett Cornwall




___
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] Regarding Notify-OSD's Position in Karmic Koala

[Scott E. Armitage]

On Wed, Nov 11, 2009 at 6:25 PM, Brett Cornwall wrote:
>
> Well, let me save you from some grief: I can promise you, without a doubt,
> that the middle of the screen will not fly for anyone. :).
>
> I know this argument can be said for anything, but I strongly feel that
> this is an item that should be customizable, even if the aim is to try and
> keep the bare minimum going for positive purposes.
>
>
The middle of the screen, or the middle of the screen on the right-hand
side? I maintain that the centre of the screen is still a viable option for
synchronous notifications such as e.g. volume, brightness, etc. -- the user
is actively interfacing with the computer, they should easily see the
effects of that. The should also disappear quicker than async notifications.

Asynchronous notifications that you might not care about -- now /those/ make
a lot more sense to be tucked away in a corner such that they are easily
ignorable if you don't want to pay any attention to them.

I agree that middle of the screen on the right will not fly with anyone :-)

-Scott


-- 
Scott Armitage, B.A.Sc., M.A.Sc. candidate
Space Flight Laboratory
University of Toronto Institute for Aerospace Studies
4925 Dufferin Street, Toronto, Ontario, Canada, M3H 5T6
___
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] Regarding Notify-OSD's Position in Karmic Koala

[Brett Cornwall]

Mark Shuttleworth wrote:

  Hold on a sec. We are not just aimlessly pushing it around. We have a
clear set of tradeoffs and constraints (see a previous mail on this
list). Theory is useful, but it also helps to have actual time spent
(i.e. a few weeks to get used to it) with various options. That's what
we'll do in Lucid, we'll try the bottom right and get some real
experience with it. We may try the centerline again (popular as that was
:-)). And by the end of it we'll make a decision, and stick with it from
then on.

Mark


  

Well, let me save you from some grief: I can promise you, without a
doubt, that the middle of the screen will not fly for anyone. :).

I know this argument can be said for anything, but I strongly feel that
this is an item that should be customizable, even if the aim is to try
and keep the bare minimum going for positive purposes.
-- 
-Brett Cornwall




___
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] Regarding Notify-OSD's Position in Karmic Koala

[Dylan McCall]

> Theory is useful, but it also helps to have actual time spent
> (i.e. a few weeks to get used to it) with various options. That's what
> we'll do in Lucid, we'll try the bottom right and get some real
> experience with it. We may try the centerline again (popular as that was
> :-)). And by the end of it we'll make a decision, and stick with it from
> then on.
>
> Mark
>
>

Hey, slightly random, but could I suggest putting synchronous bubbles
a bit above the bottom edge at the horizontal centre? (Where there
used to be a popup for adjusting volume and brightness). I think there
may have been some reason behind that approach :)

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] Regarding Notify-OSD's Position in Karmic Koala

[Mark Shuttleworth]

Scott E. Armitage wrote:
> It sounds like this is putting the horse before the bit -- there is
> still a lot of turmoil out there regarding NotifyOSD's positioning.
> The "Work for Lucid" section /should/ say something more like
>
> " Positioning: Determine the driving requirements for notification
> bubble positioning and separate them from the 'nice-to-haves'. Perform
> a trade study comparing all possible solutions against the
> requirements to identify those that satisfy requirements."
>
> We can keep moving the notifications around every time Ubuntu is
> released, /or/ we could pin down /what we actually need/ to accomplish
> in notification positioning and get it done. Right. This time.
Hold on a sec. We are not just aimlessly pushing it around. We have a
clear set of tradeoffs and constraints (see a previous mail on this
list). Theory is useful, but it also helps to have actual time spent
(i.e. a few weeks to get used to it) with various options. That's what
we'll do in Lucid, we'll try the bottom right and get some real
experience with it. We may try the centerline again (popular as that was
:-)). And by the end of it we'll make a decision, and stick with it from
then on.

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

Re: [Ayatana] Regarding Notify-OSD's Position in Karmic Koala

[Scott E. Armitage]

It sounds like this is putting the horse before the bit -- there is still a
lot of turmoil out there regarding NotifyOSD's positioning. The "Work for
Lucid" section *should* say something more like

" Positioning: Determine the driving requirements for notification bubble
positioning and separate them from the 'nice-to-haves'. Perform a trade
study comparing all possible solutions against the requirements to identify
those that satisfy requirements."

We can keep moving the notifications around every time Ubuntu is released, *
or* we could pin down *what we actually need* to accomplish in notification
positioning and get it done. Right. This time.

-Scott

On Wed, Nov 11, 2009 at 11:26 AM, mac_v  wrote:

> Hi ,
>
> Recent update in the Lucid specs:
> https://wiki.ubuntu.com/NotifyOSD#Work%20for%20Lucid
>
>  " Change in position: The top of any notification bubble should be
> positioned near the bottom right corner such that if the bubble grows to
> its maximum height, it is snug at the bottom right corner. Confirmation
> bubbles should use a slot immediately above that notification bubble
> slot."
>
>
> On Wed, 2009-11-04 at 16:18 +0200, Alex Lourie wrote:
> > Hi Tony
> >
> > I suggest you read the specification in
> > https://wiki.ubuntu.com/NotifyOSD.
> >
> >
> >
> > I have read it.
> >
> >
> > In short: the notification bubbles are not supposed to be
> > interactive. Not even in the
> > sense of being interactively closed. The bubble fades away
> > when the mouse is over
> > it to make it possible to interact with things below it
> > (see-through and click-through).
> >
> > And all the reaction needs you mentioned are covered by the
> > indicator-applet:
> >
> > https://wiki.ubuntu.com/MessagingMenu
> >
> > Regards,
> > Tony
> >
> >
> > Thanks, that's exactly what I thought.
> >
> > Although I now understand that this works as designed, it still feels
> > strange in real life scenarios.
> >
> >
> >
>
> >
>
> >
> > Al___
> > 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
>



-- 
Scott Armitage, B.A.Sc., M.A.Sc. candidate
Space Flight Laboratory
University of Toronto Institute for Aerospace Studies
4925 Dufferin Street, Toronto, Ontario, Canada, M3H 5T6
___
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] Regarding Notify-OSD's Position in Karmic Koala

[mac_v]

Hi , 

Recent update in the Lucid specs:
https://wiki.ubuntu.com/NotifyOSD#Work%20for%20Lucid

 " Change in position: The top of any notification bubble should be
positioned near the bottom right corner such that if the bubble grows to
its maximum height, it is snug at the bottom right corner. Confirmation
bubbles should use a slot immediately above that notification bubble
slot."


On Wed, 2009-11-04 at 16:18 +0200, Alex Lourie wrote:
> Hi Tony
> 
> I suggest you read the specification in
> https://wiki.ubuntu.com/NotifyOSD.
> 
> 
> 
> I have read it.
> 
>  
> In short: the notification bubbles are not supposed to be
> interactive. Not even in the
> sense of being interactively closed. The bubble fades away
> when the mouse is over
> it to make it possible to interact with things below it
> (see-through and click-through).
> 
> And all the reaction needs you mentioned are covered by the
> indicator-applet:
> 
> https://wiki.ubuntu.com/MessagingMenu
> 
> Regards,
> Tony
> 
> 
> Thanks, that's exactly what I thought.
> 
> Although I now understand that this works as designed, it still feels
> strange in real life scenarios.
> 
> 
> 

> 

> 
> Al___
> 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] Regarding Notify-OSD's Position in Karmic Koala

[Alex Lourie]

Hi Tony

I suggest you read the specification in https://wiki.ubuntu.com/NotifyOSD.
>
>
I have read it.



> In short: the notification bubbles are not supposed to be interactive. Not
> even in the
> sense of being interactively closed. The bubble fades away when the mouse
> is over
> it to make it possible to interact with things below it (see-through and
> click-through).
>
> And all the reaction needs you mentioned are covered by the
> indicator-applet:
>
> https://wiki.ubuntu.com/MessagingMenu
>
> Regards,
> Tony
>

Thanks, that's exactly what I thought.

Although I now understand that this works as designed, it still feels
strange in real life scenarios.

Alex.
___
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] Regarding Notify-OSD's Position in Karmic Koala

[Tony Knott]

> Date: Wed, 4 Nov 2009 08:41:46 +0200
> From: djay...@gmail.com
> To: ayatana@lists.launchpad.net
> CC: brettcornw...@gmail.com; dylanmcc...@gmail.com
> Subject: Re: [Ayatana] Regarding Notify-OSD's Position in Karmic Koala

> I wanted to understand something here, as it feels that I'm getting something 
> wrong.
> (...)

I suggest you read the specification in https://wiki.ubuntu.com/NotifyOSD.



In short: the notification bubbles are not supposed to be interactive. Not even 
in the

sense of being interactively closed. The bubble fades away when the mouse is 
over

it to make it possible to interact with things below it (see-through and 
click-through).



And all the reaction needs you mentioned are covered by the indicator-applet:



https://wiki.ubuntu.com/MessagingMenu



Regards,

Tony
  
_
Windows Live Hotmail: Your friends can get your Facebook updates, right from 
Hotmail®.
http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_4:092009___
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] Regarding Notify-OSD's Position in Karmic Koala

[Alex Lourie]

I wanted to understand something here, as it feels that I'm getting
something wrong.

I'm working on 22" monitor with 1680x1050 resolution, and bubble are coming
at the top
of the screen as expected. So I don't have the problems Dylan had.

Here's the thing though: the bubble is usually very visually distinct, so it
immediately draws my attention. But
when I move a mouse over it, it gets blurred and mouse clicks on it do
nothing. The worst part is that
when the mouse is out of the bubble, the bubble gets again the full opacity
and still draws attention, as if nothing
happened.

I can do this until the world ends, but this behavior seems unnatural for
couple of reasons:

1. If the message means something to react upon (such as Gwibber
notification, email, empathy, etc), it should, indeed, react
to my mouse clicks. For example, by clicking on the bubble with gwibber
notification I expect to get a gwibber
window, and by clicking Empathy notification I expect to get a chat dialog.

2. If the message doesn't need my "response" (such as network reconnect
notification), why does the bubble goes away
when I move a mouse over it? It strongly draws my attention due to its GUI
attributes, but it is not clear what am I suppose to do with it.

Currently, the best way to "use" notifications is just ignore the bubble,
wait until it disappears and then go to its source to see what's going on.
It kinda negates the whole concept, isn't it?

Alex.


One thing I noticed:
>
> The predictable position for notifications works perfectly fine on my
> 1920x1200 monitor. They stick to the top right corner and are nicely out
> of the way.
>
> However, on a netbook, the experience is different. Because the screen
> is about 600 pixels high, the asynchronous bubbles end up about halfway
> down. That _is_ ugly.
>
>
> On a different note, I think the customization debate is silly. It is
> absolutely customizable: you can install notification-daemon and use
> that as default ;)
> Naturally, good design (which includes knowing what should be
> configurable) should make that a very rare desire, but one's choice is
> definitely not being restricted here in any way.
>
>
> Bye,
> Dylan McCall
>
>
> ___
> Mailing list: https://launchpad.net/~ayatana
> Post to : ayatana@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~ayatana
> More help   : https://help.launchpad.net/ListHelp
>
> current one.
___
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] Regarding Notify-OSD's Position in Karmic Koala

[Brett Cornwall]

Here's an interesting quote from a user from the bug report:

"Having
read this head to tail I see that the discussion is becoming repetitive
and not bringing nothing new, I think we should push it into a more
constructive direction. I will summarize the most important points that
have been said and add my 2 cents.


#1. The "old" notify-osd version had no clear rules. It displayed
the messages as they come.
#2. Some people complained that it's obstructing some important
components like the minimize/close buttons and Firefox search bar.
#3. The "new" version choses to have predictable positions for the
synchronous/asynchronous messages so that the synchronous messages
now do not obstruct the above mentioned components.
#4. The "new" version looks bad to some/many (old) users.
#5. The developers says that it's more important that notify-os makes
sense to new users, rather than allowing old users to customize the
desktop.
#6. Users reply that a mature os should do both (make sense to new
users and be pleasing to old users).
#7. Users ask for at least a way to customize the behavior back to the
original behavior.
#8. The developers say that adding more customization is bad.
Ok. My point of view:
#A. I understand the need for #3 and #5 but I don't think that the
current solution is the best solution for #4 and #6. However i cannot
say that I have a better, new one.
#B. I would add that we must understand that the majority of new users
are not all new, but probably had some contact with another OS. In
neither OS that I know a similar solution is used so it probably isn't
that good for them either. At least the old version looked like the
usual Windows notification but in reverse (coming down instead of going
up). This combined with #4 makes the old version better than the
current one.
#C. If indeed the Gnome3 approach is the one presented above, we should
also consider that the transition to that is smooth, not a complete
redefinition.
#D. We need to take into account scalability. The new design makes some
assumptions that are not all in all correct, like: "all sync messages
have a fixed size". Will this solution still fit as new notifications
are added or the granularity of the current one will be increased. We
don't know on what devices will Ubuntu run next and what messages/notifications
will those offer.
#E. We (the users) need to understand that what the developers main
purpose is that "Ubuntu succeeds". Windows and Mac OS have proved that
less configurability works, when many distributions that were driven by
the community have failed. It is in my opinion a good decision to keep
configurability low. However #5 is a very good point. This is open
source. Why add reasons for a fork. Plus, where to place the
notifications is not a life changing decision. My solutions would be:
  - #E.1. Allow configurabilly from a configuration file. The new users
wouldn't be confused by many options and the old/advanced users would
still have the option to configure it to their pleasing.
  - #E.2. Do a vote or better, a research with both old and new users.
Hope this helps bringing the community and the developers to a
consent."


-- 
-Brett Cornwall
brettcornw...@gmail.com
Cell: (352) 474-0415
AIM: BrettCCornwall
Jabber/XMPP: brettcornw...@jabber.org




___
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] Regarding Notify-OSD's Position in Karmic Koala

[mac_v]

On Thu, 2009-10-22 at 09:24 +0100, Luke Benstead wrote:
>  Finally, in the notification bubble we can make the text slide
> up, rather than jump up, and also fiddle with the display time and the
> width of the bubble (so more text fits on a single line). 

The width of the bubbles is probably not going to increase > 
https://bugs.launchpad.net/notify-osd/+bug/336110

The ideal width has been identified and is being used atm.

With scrolling what we also need to consider are , the accessibility
issues. Not everyone can read at the same speed nor does everyone have
good eye co-ordination.[younger individuals can accommodate easier when
the lines jump,  but with age this becomes difficult... similarly with
folks not fluent with the language , they would find it hard to find the
words they were reading once the lines jump.] 

So the smooth scrolling , needs to be slow enough to not allow the lines
to jump and fast enough to not cause the bubbles to stay too long.

This would again need a lot more work/fiddling/testing to identify the
ideal scrolling speed. 

As mentioned earlier ,its easy to throw in an idea ;)

> > What we could do is:
> > - Place the Async bubbles in the lower right, at a height keeping in
> > mind the max[10 lines] allowed for append. So the bubble is in the lower
> > right position but not exactly in the corner. This would make the
> > bubbles not have a problem of scrolling text.
> > - Place the sync bubbles to be in the lower center. At the same height
> > as the async bubbles but centered. [Similar to where the upstream
> > volume/brightness notifications are placed]
> >
> > -OR-
> >
> > - Revert back to the dynamic positioning of the bubbles and place the
> > bubbles in the lower right at the height assuming for 10 lines of text.
> >
> >
> >
> > Then again we might get complaints that the bubbles are not exactly in
> > the corner... ;)
> >
> 
> I think either of those solutions could work. 

What i had suggested was with minimal tweak to the notify-osd, by just
adjusting the position of the notifications.

> The point of my original
> suggestion was that positioning at the bottom of the screen (where
> there are usually fewer screen elements) should not be ruled out just
> because the async bubbles will extend. I actually think Johan's
> mockups look pretty nice :)
> 
> Luke.

The lower position has been suggested earlier too, but it was not used.
*iirc* it was due to the async bubbles, the append feature being tough
to implement when positioned below and making them grow upwards.

I too would like to have such a bubble, if the text scrolls smoothly
without jerks and is readable by all. [it really does sound great, if
done right]   :)


-- 
Cheers,
mac_v


___
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] Regarding Notify-OSD's Position in Karmic Koala

[Luke Benstead]

> In IM clients the text does not disappear , so you can take your time to
> catch up with the text.
> Try this , try reading text in an irc chat room with heavy traffic,[eg:
> #ubuntu]. You'll notice it is not easy to catch up.
>

Thinking about it, I don't believe comparisons with IM or IRC are fair
(I know, it was I who first compared to IM :p )

Both IM and IRC have a major difference in that the scrolling text is
from multiple sources (users) whereas notification bubbles come from
one source. Context switching like this will obviously take longer to
read than text from a single source. Also, the sheer quantity of text
to read in both IM and IRC is far more than your typical notification
bubble. Finally, in the notification bubble we can make the text slide
up, rather than jump up, and also fiddle with the display time and the
width of the bubble (so more text fits on a single line). I'm not
convinced that text scrolling up in the notification bubbles will
actually cause a problem.

> What we could do is:
> - Place the Async bubbles in the lower right, at a height keeping in
> mind the max[10 lines] allowed for append. So the bubble is in the lower
> right position but not exactly in the corner. This would make the
> bubbles not have a problem of scrolling text.
> - Place the sync bubbles to be in the lower center. At the same height
> as the async bubbles but centered. [Similar to where the upstream
> volume/brightness notifications are placed]
>
> -OR-
>
> - Revert back to the dynamic positioning of the bubbles and place the
> bubbles in the lower right at the height assuming for 10 lines of text.
>
>
>
> Then again we might get complaints that the bubbles are not exactly in
> the corner... ;)
>

I think either of those solutions could work. The point of my original
suggestion was that positioning at the bottom of the screen (where
there are usually fewer screen elements) should not be ruled out just
because the async bubbles will extend. I actually think Johan's
mockups look pretty nice :)

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] Regarding Notify-OSD's Position in Karmic Koala

[Alex Launi]

Another interesting idea would be just to flip what we currently have so
that sync notifications are at the bottom right, and then async grow
vertically above them. This would make the async notifications more like it
IM window itself, where new text appears at the bottom and old text scrolls
up, and also keep it all in a consistent, and more likely out of the way
place.

-- 
--Alex Launi
___
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] Regarding Notify-OSD's Position in Karmic Koala

[Matt Wheeler]

2009/10/21 mac_v :



> What we could do is:
> - Place the Async bubbles in the lower right, at a height keeping in
> mind the max[10 lines] allowed for append. So the bubble is in the lower
> right position but not exactly in the corner. This would make the
> bubbles not have a problem of scrolling text.
> - Place the sync bubbles to be in the lower center. At the same height
> as the async bubbles but centered. [Similar to where the upstream
> volume/brightness notifications are placed]
>
> -OR-
>
> - Revert back to the dynamic positioning of the bubbles and place the
> bubbles in the lower right at the height assuming for 10 lines of text.
>
>
> Then again we might get complaints that the bubbles are not exactly in
> the corner... ;)

How about having the async bubble grow smoothly, with the text sliding
upwards and the new text already draw sliding & fading into view, so
it does appear more like a teleprompter. This could possibly enable
the notifications to start of right in the bottom left, and grow
upwards while still being easy to follow.

The sync bubble could either be displayed right in the corner with the
async bubble above it, or alternatively in the top right corner,
meaning both bubbles could be right in the corner, if this is a
concern to people.

Sorry I'm not in a position where I can create a demonstration of this
working at the moment.


-- 
Matt Wheeler
m...@funkyhat.org

___
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] Regarding Notify-OSD's Position in Karmic Koala

[mac_v]

> 2009/10/21 Martin Albisetti :
> > Mark Shuttleworth wrote:
> >>
> >> Johan Euphrosine wrote:
> >>>
> >>> Here is better mockup:
> >>>
> >>> http://bitbucket.org/proppy/clutter-repl/raw/4b8460e1e300/logs/session14.ogv
> >>>
> >>
> >> Let's hear what others think.
> >
> > It feels odd to read from the bottom to the top. I played around with moving
> > things on the screen upwards and downwards, and it's easier to follow them
> > as they go down rather than up.
> >

+1

> On Wed, 2009-10-21 at 21:18 +0100, Luke Benstead wrote:
> It's funny you should say that, because this way it mimics the
> behaviour of IM clients such as Empathy and Pidgin (previous text
> scrolls up, the most recent appears at the bottom).
> 
> Luke.
> 

When the words scroll while the user is reading in the middle , it
becomes difficult to follow the lines. As the line the user is trying to
read has now moved up. Such scrolling is not ideal for reading text in
transient bubbles.

This is because the new append doesnt add itself line by line[slowly] as
teleprompter do. But rather the full length of the new append is added ,
and the line the user has been reading would have now jumped several
lines above.

In IM clients the text does not disappear , so you can take your time to
catch up with the text.
Try this , try reading text in an irc chat room with heavy traffic,[eg:
#ubuntu]. You'll notice it is not easy to catch up.


What we could do is:
- Place the Async bubbles in the lower right, at a height keeping in
mind the max[10 lines] allowed for append. So the bubble is in the lower
right position but not exactly in the corner. This would make the
bubbles not have a problem of scrolling text.
- Place the sync bubbles to be in the lower center. At the same height
as the async bubbles but centered. [Similar to where the upstream
volume/brightness notifications are placed]

-OR-

- Revert back to the dynamic positioning of the bubbles and place the
bubbles in the lower right at the height assuming for 10 lines of text.



Then again we might get complaints that the bubbles are not exactly in
the corner... ;)


-- 
Cheers,
mac_v


___
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] Regarding Notify-OSD's Position in Karmic Koala

[Johan Euphrosine]

On Wed, 2009-10-21 at 21:00 +0100, Mark Shuttleworth wrote:
> Can you get rid of the blank line between the lines of text, just to
> tighten it up? And can you make it more real, like put a couple of
> lines in there in one hit, then add a few others with random timing,
> as if it were someone typing at you on IM while you're surfing the
> web?

I gave it a try there:
http://bitbucket.org/proppy/clutter-repl/raw/afd665b2c8fa/logs/session15.ogv

Let me know if it needs more work.

-- 
Johan Euphrosine 
Development and services around Free Software
http://aminche.com/



signature.asc
Description: This is a digitally signed message part
___
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] Regarding Notify-OSD's Position in Karmic Koala

[Luke Benstead]

2009/10/21 Martin Albisetti :
> Mark Shuttleworth wrote:
>>
>> Johan Euphrosine wrote:
>>>
>>> Here is better mockup:
>>>
>>> http://bitbucket.org/proppy/clutter-repl/raw/4b8460e1e300/logs/session14.ogv
>>>
>>
>> Let's hear what others think.
>
> It feels odd to read from the bottom to the top. I played around with moving
> things on the screen upwards and downwards, and it's easier to follow them
> as they go down rather than up.
>

It's funny you should say that, because this way it mimics the
behaviour of IM clients such as Empathy and Pidgin (previous text
scrolls up, the most recent appears at the bottom).

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] Regarding Notify-OSD's Position in Karmic Koala

[Martin Albisetti]

Mark Shuttleworth wrote:

Johan Euphrosine wrote:

Here is better mockup:
http://bitbucket.org/proppy/clutter-repl/raw/4b8460e1e300/logs/session14.ogv
  

Let's hear what others think.


It feels odd to read from the bottom to the top. I played around with moving 
things on the screen upwards and downwards, and it's easier to follow them as 
they go down rather than up.



--
Martin

___
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] Regarding Notify-OSD's Position in Karmic Koala

[Mark Shuttleworth]

Johan Euphrosine wrote:
> Here is better mockup:
> http://bitbucket.org/proppy/clutter-repl/raw/4b8460e1e300/logs/session14.ogv
>   
Can you get rid of the blank line between the lines of text, just to
tighten it up? And can you make it more real, like put a couple of lines
in there in one hit, then add a few others with random timing, as if it
were someone typing at you on IM while you're surfing the web?

Let's hear what others think.

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

Re: [Ayatana] Regarding Notify-OSD's Position in Karmic Koala

[Jim Rorie]

Cody, this is an excellent post.  

It's the best explanation of the project's reasoning, without the hard
edge.  You will still get push back, but now you have a concise,
coherent argument that isn't quite so authoritarian. This really needs
to go in a FAQ.


Jim



On Wed, 2009-10-21 at 13:36 -0500, Cody Russell wrote: 
> On Wed, 2009-10-21 at 13:29 -0400, Jim Rorie wrote:
> > I'm not talking about visible checkboxes or customization
> > applications.
> > Don't go the KDE route.  Give power users/admins access to gconf for a
> > few variables that could have a big impact on user experience.
> 
> As a developer on the DX team doing some of the new desktop stuff, I
> can't help but cringe a little when I read things like this.  There's
> more to worry about than simply cluttering or uncluttering the UIs with
> checkboxes.  When Mark talks about things like having opinionated
> designs and stuff, I think I read that a little differently than some
> people here do.  I read it as well-defined code paths and workflows that
> will lead to faster and more stable software.
> 
> It's really easy to say "I want a boolean gconf value to do X, I don't
> care if there is no UI for it and it won't be part of the default
> install so what harm can come of it?"
> 
> Canonical is trying to make an effort at doing more thorough automated
> testing of software we create.  These type of hidden options may seem
> trivial, but they're almost certainly going to do two things: 1/ they'll
> be a maintenance burden and 2/ either seriously complicate the automated
> testing or they're going to be ignored by the testing software.  I have
> a feeling they're going to be largely ignored, because we are already on
> very tight schedules and we're obviously going to be focusing testing on
> the default UI/workflow/setup that is in the specifications.  If people
> start throwing all kinds of random gconf options into the code to do
> things that aren't in the design vision, I doubt Mark or the design team
> want us spending time expanding unit and functional tests to handle all
> those cases.
> 
> So we skip it and hope for the best.  Then eventually bug reports start
> coming in where the app is misbehaving here or there, but it's not
> misbehaving in our tests.  Who's going to be responsible for fixing
> those bugs?  I know from past experience in upstream projects that it's
> easy for someone to contribute something and then disappear, and it's
> left for the maintainers to deal with fallout.  This is what I mean by a
> maintenance burden.
> 
> So the end of the story is that the developers fall behind schedule,
> can't deliver everything that's asked of them or can't deliver it to the
> level of quality that we're trying to, and then the entire platform is
> not advancing as quickly as it could and should.  This sounds like I'm
> exaggerating probably, but I really don't think I am.  When a single bug
> is filed against an Ayatana app that's not reproducible on a standard
> install, and is caused by some corner case from a gconf key getting set
> in a way that is unspecified then a DX team member switches contexts to
> spend a couple hours debugging it.  That's a couple hours spent on
> something that affects almost nobody, and a couple hours LOST on work
> that could be spent on something that will affect almost everybody.
> 
> / Cody
> 


smime.p7s
Description: S/MIME cryptographic 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] Regarding Notify-OSD's Position in Karmic Koala

[Johan Euphrosine]

On Wed, 2009-10-21 at 20:20 +0100, Matt Wheeler wrote:

> Are you actually suggesting that messages that stay visible for longer
> should bob up and down depending on whether there is a newer message
> beneath it?
> (if that is not the case then perhaps the messages in the video need
> to be numbered rather than just labelled "new" and "old").

Here is better mockup:
http://bitbucket.org/proppy/clutter-repl/raw/4b8460e1e300/logs/session14.ogv


-- 
Johan Euphrosine 
Development and services around Free Software
http://aminche.com/



signature.asc
Description: This is a digitally signed message part
___
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] Regarding Notify-OSD's Position in Karmic Koala

[Mark Shuttleworth]

Johan Euphrosine wrote:
> On Wed, 2009-10-21 at 18:09 +0100, Mark Shuttleworth wrote:
>   
>> That would be worth a flash mockup, or code mockup, to see in
>> practice.
>>
>> 
>
> Hi,
>
> Here is a tentative clutter mockup:
> http://bitbucket.org/proppy/clutter-repl/raw/2f7b36efb1fe/logs/session13.ogv
>   

That's neat. But I'd like to see it be more like the current
lines-of-text-in-IM growth than that, which is more like separate
notifications.

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

Re: [Ayatana] Regarding Notify-OSD's Position in Karmic Koala

[Luke Benstead]

2009/10/21 Matt Wheeler :
> 2009/10/21 Luke Benstead :
>> You legend! Yeah, exactly that kind of thing, I think it would look pretty 
>> cool.
>>
>> Thanks a lot!
>>
>> So, good idea?
>
> Are you actually suggesting that messages that stay visible for longer
> should bob up and down depending on whether there is a newer message
> beneath it?
> (if that is not the case then perhaps the messages in the video need
> to be numbered rather than just labelled "new" and "old").
>
>
>
> --
> Matt Wheeler
> m...@funkyhat.org
>

No. At the moment in the top-right, notify-osd displays sync
notifications above the async versions. Mark said that one of the
reasons why the notifications are at the top of the screen is that
async notifications can grow. At the top of the screen when a new line
is added, the bubble grows downwards. The mockup is to show that you
can move the text upwards and fade in the next text when it grows, so
the bubbles can grow upwards and still look good. At the bottom of the
screen the sync notifications would be below the async so that bubbles
don't move around when the async grows. Make sense? It make sense in
my head at least :p

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] Regarding Notify-OSD's Position in Karmic Koala

[Matt Wheeler]

2009/10/21 Luke Benstead :
> You legend! Yeah, exactly that kind of thing, I think it would look pretty 
> cool.
>
> Thanks a lot!
>
> So, good idea?

Are you actually suggesting that messages that stay visible for longer
should bob up and down depending on whether there is a newer message
beneath it?
(if that is not the case then perhaps the messages in the video need
to be numbered rather than just labelled "new" and "old").



-- 
Matt Wheeler
m...@funkyhat.org

___
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] Regarding Notify-OSD's Position in Karmic Koala

[Luke Benstead]

2009/10/21 Johan Euphrosine :
> On Wed, 2009-10-21 at 18:09 +0100, Mark Shuttleworth wrote:
>> That would be worth a flash mockup, or code mockup, to see in
>> practice.
>>
>
> Hi,
>
> Here is a tentative clutter mockup:
> http://bitbucket.org/proppy/clutter-repl/raw/2f7b36efb1fe/logs/session13.ogv
>
> Luke, let me know if it implements properly the behavior you described.
>
> Hope that helps.
>
> --
> Johan Euphrosine 
> Development and services around Free Software
> http://aminche.com/
>

You legend! Yeah, exactly that kind of thing, I think it would look pretty cool.

Thanks a lot!

So, good idea?

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] Regarding Notify-OSD's Position in Karmic Koala

[Johan Euphrosine]

On Wed, 2009-10-21 at 18:09 +0100, Mark Shuttleworth wrote:
> That would be worth a flash mockup, or code mockup, to see in
> practice.
> 

Hi,

Here is a tentative clutter mockup:
http://bitbucket.org/proppy/clutter-repl/raw/2f7b36efb1fe/logs/session13.ogv

Luke, let me know if it implements properly the behavior you described.

Hope that helps.

-- 
Johan Euphrosine 
Development and services around Free Software
http://aminche.com/



signature.asc
Description: This is a digitally signed message part
___
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] Regarding Notify-OSD's Position in Karmic Koala

[Cody Russell]

On Wed, 2009-10-21 at 13:29 -0400, Jim Rorie wrote:
> I'm not talking about visible checkboxes or customization
> applications.
> Don't go the KDE route.  Give power users/admins access to gconf for a
> few variables that could have a big impact on user experience.

As a developer on the DX team doing some of the new desktop stuff, I
can't help but cringe a little when I read things like this.  There's
more to worry about than simply cluttering or uncluttering the UIs with
checkboxes.  When Mark talks about things like having opinionated
designs and stuff, I think I read that a little differently than some
people here do.  I read it as well-defined code paths and workflows that
will lead to faster and more stable software.

It's really easy to say "I want a boolean gconf value to do X, I don't
care if there is no UI for it and it won't be part of the default
install so what harm can come of it?"

Canonical is trying to make an effort at doing more thorough automated
testing of software we create.  These type of hidden options may seem
trivial, but they're almost certainly going to do two things: 1/ they'll
be a maintenance burden and 2/ either seriously complicate the automated
testing or they're going to be ignored by the testing software.  I have
a feeling they're going to be largely ignored, because we are already on
very tight schedules and we're obviously going to be focusing testing on
the default UI/workflow/setup that is in the specifications.  If people
start throwing all kinds of random gconf options into the code to do
things that aren't in the design vision, I doubt Mark or the design team
want us spending time expanding unit and functional tests to handle all
those cases.

So we skip it and hope for the best.  Then eventually bug reports start
coming in where the app is misbehaving here or there, but it's not
misbehaving in our tests.  Who's going to be responsible for fixing
those bugs?  I know from past experience in upstream projects that it's
easy for someone to contribute something and then disappear, and it's
left for the maintainers to deal with fallout.  This is what I mean by a
maintenance burden.

So the end of the story is that the developers fall behind schedule,
can't deliver everything that's asked of them or can't deliver it to the
level of quality that we're trying to, and then the entire platform is
not advancing as quickly as it could and should.  This sounds like I'm
exaggerating probably, but I really don't think I am.  When a single bug
is filed against an Ayatana app that's not reproducible on a standard
install, and is caused by some corner case from a gconf key getting set
in a way that is unspecified then a DX team member switches contexts to
spend a couple hours debugging it.  That's a couple hours spent on
something that affects almost nobody, and a couple hours LOST on work
that could be spent on something that will affect almost everybody.

/ Cody


___
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] Regarding Notify-OSD's Position in Karmic Koala

[Luke Benstead]

2009/10/21 Mark Shuttleworth :
> Luke Benstead wrote:
>
> The only thing against that is what Mark said about the async
> notifications growing upwards, but I still don't see why that's a
> problem (it would look pretty cool if the existing text moved up, then
> the new line faded in below).
>
> That would be worth a flash mockup, or code mockup, to see in practice.
>

Err.. ok... anyone any good with Flash? Or could someone point me at
an OSS app that makes Flash animations?

Thanks,

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] Regarding Notify-OSD's Position in Karmic Koala

[Mark Shuttleworth]

Jim Rorie wrote:
>>> I notice that you don't insist upon one application per
>>> function available in the repositories or launchpad PPAs.
>>>   
>>>   
>> Of course not. Nor would I resist there being many branches of
>> notify-osd. But I will resist calls for "this should be an option".
>> 
>
> And if notify-osd branches fifty times because Canonical has a iron
> fisted vision, then you've caused the community to waste resources on a
> problem that had a simple fix.
>   
Well, if any one of those fifty branches is better, it will get merged
in, and the default will get better for everyone.

It would be silly to be attached to a bad idea even in the face of much
better ideas. Occasionally we might do that, but it's not likely to be
the modus operandi of winners, is it. So hopefully, when confronted by
genuinely better ideas, we will embrace them and merge them in. What we
WON'T do is merge in everybody's favourite option with a preference or
gconf setting ;-)

The downside is, we have to work harder to find the good stuff that gets
merged in. Lots of branches may not go anywhere. But hey, the upside is,
when you propose something and it IS included, it's more rewarding!

> No one is arguing for that.  But design with an iron fist is what mac
> and MS do.  It's part of what drove us to Linux to begin with.
>   
I'm not here to take away your freedom. I'm not here to take away
anybody else's freedom either. And it's an iron fist that can punch for
your ideas too, if you participate here and come up with something great
and congruent.

> Is a gconf entry override for the position such a heinous perversion of
> the Ayatana vision?  The ordinary user will never be affected.  Isn't
> the power user part of the Ayatana vision?
>   
Options cause code bloat which causes bitrot which causes bugs which
slows us down. So, yes. In some cases they are warranted, but the cost
is much, much higher than people usually realise. And clearly, from what
you say, higher than you realise.


>>> I believe it will drive people away, hurt
>>> upstreams, a number of side streams and limited sections of downstream.
>>>   
>>>   
>> What does that mean exactly? I think you're mouthing off because you
>> don't like the idea of having to go with something you don't
>> personally like occasionally.
>> 
>
> Martin is looking at the big picture.  He's concerned that you are going
> down a path that will cause a fork or general disruption.  I agree.
> Linux is at a fragile state.  It is posed to make a significant mark in
> the desktop/portable market in the next couple of years.  This kind of
> derailment could destroy the momentum.
>   
I doubt it. I think Linux is resilient. If we're wrong, we're wrong. If
you think we're wrong, put your energy in somewhere else where you think
folks have got a clue. That's the sensible approach.

I don't mind losing participation - I want us to whittle the group down
to a group that works productively and well together. Arguing about
whether options are a sensible way to resolve differences of opinion
holds less and less attraction in that regard.

>>> But I have no data on that, that's just from my own principles of
>>> inclusion and experience in trying to do the hard job of bringing
>>> together conflicting ideas.
>>>   
>>>   
>> If you have deep experience of that you'll understand what I mean when
>> I say you cannot always include everybody if you want a decisive and
>> exciting result. You can aim to include everyone if you are
>> comfortable taking a very long time to produce something that is hard
>> to use and ultimately not exciting.
>> 
>
> But if you refuse to offer any customization, you tick off the very
> people you need to survive.
>   
Of course we don't "refuse to offer any customization". We just push
back in it really, really hard, because we think the cost is much higher
than people realise. It's cheap to throw an idea out on a list. It's
expensive to maintain the code, and expensive to users time to have them
make decisions they often don't need to have been presented with.

So, sometimes we do offer customisation, when the cost is worth paying.

In this case it is not, is the view, for the moment.

 In Ayatana, we'll take an opinionated stance, and we'll apply some
 common principles to the design process,
 
 
>>> This principle isn't common,
>>>   
>> This willingness to be decisive isn't common, no. By common principles
>> I meant that we will focus on specific areas of the experience, bring 
>> some specific principles to bear, and live with the results.
>> 
>
> "Live with the results"  This really scares me.  I've looked forward to
> your guidance to the community with regard to big picture concepts like
> cadence and collaboration.  
>
> This statement looks like your account has been hijacked and you're in
> Hawaii. =0
>   
For some people, the cadence idea has the same scary overtones :-)



>> Whether or not n

Re: [Ayatana] Regarding Notify-OSD's Position in Karmic Koala

[Jim Rorie]

On Wed, 2009-10-21 at 17:31 +0200, Alex Lourie wrote:

> 
> 
> 
> Ok, hold on a second. How come the presence or absence of options in
> some
> quite experimental software DESTROYS moment of Linux Desktop??? I
> can't understand
> how is it that after so many work being put into the operating system,
> and specifically Ubuntu Linux,
> everything would depend on some specific implementation of some
> specific idea?
> 

As I stated in my previous post.  I don't care about the location of
OSD.  I'm fine with it.  I also think the idea of an algorithm to judge
placement is a great idea.   This algorithm goes beyond desktop
specification. You are trying to interpret how the user uses the
desktop.  That's AI territory.  I seriously doubt you get one that works
all the time and probably have some serious corner cases. IMHO, you are
going to need a contingency plan.  I could be wrong, but it's irrelevant
to the argument.

Again, my concern and is not the options itself, it's our new
understanding of the Ayatana Unique Vision(TM).  We understand what you
need. Everyone.  From Mom and Dad at home to the Proteomics Researcher
at MIT. :/

IIRC, Ubuntu is about 30% of the installed desktop base(if I'm wrong,
correct me).  The desktop is the most visible aspect of Linux.  Enough
disagreements causes a fork.  The fork causes disruption to 30% of the
desktop base.  Momentum is disrupted since we are now divided.   The
stance being taken is pretty antagonistic to some Linux power users.
Just the kind that causes forks. And they are part of the marketing
muscle for Ubuntu.  Are they the majority users?  I don't want to find
out this way.  

Current events: Karmic is coming out.  Verizon, a major carrier, is
releasing an competitive Android phone. Windows 7 is coming out after
Vista's failure and MS wants $$$.  IBM/Canonical Windows-Free desktop
initiative is afoot.

All now.  Timing is half the battle.  It's an excellent chance to gain
Linux mindshare.  


> 
> And what if other distributions decide not to use Notify-OSD? Is
> complete Linux OS will be suddenly doomed?

They aren't forks.  They are existing distros.  If they join in, we are
stronger.  Without them we are where we are.



> 
> I don't believe that. I do believe that when the Notify-OSD will be
> release in official 9.10, many
> developers and otherwise technically inclined people will have
> absolutely great time to create
> exciting applications with it. I do believe that there's a lot of
> place for creativity here.

Again, I'm not focused on the Notify-OSD.  I think a majority of the
people will be happy with it.  Mozilla appears to still be on the fence,
which troubles me.  I feel like the entire spec isn't flushed out.  But,
it looks like the gnome shell people have seen the problem and are
working on it. Whether we include it appears to be an open question now.
This is a whole separate thread.

More importantly, I'm concerned about the desktop vision. And I think
that concern is valid. If you want proof, check the mailing list stats.
This has generated the most mail of any thread in quite a while, even
Mark's post about closing the list.  The people on this list are
passionate supporters of Ubuntu.  And again, they are the marketing
muscle behind it's success.


> 
> 
> 
> Uhm, why is it so hard to include "let do this and change that" into
> "live with the
> results"? It's no an MS process, where the decision is made, it never
> gets reviewed
> and nobody cares what users think. 

"Live with the results", at least when interpreted by a U.S. reader,
appears to mean that we make a decision and don't change no matter the
consequences, even if the idea is really, really dumb.  This could just
be semantics.  As it sits, it unnerves me.

BTW, MS does care what users think.  They pay big money on focus groups.
They've just made some really astronomically bad decisions based on
legacy support and corporate interests.  And they are hamstrung by a
really bad architecture.  

In short, they didn't let outside input deflect them from their Unique
Vision(TM)


> We have an interactive process, where something
> is released (soon to be in this case too), then it gets feedback, and
> then new iteration cycle
> begins. But to produce great product it is imperative to have focus.
> You can't have focus with
> too much stuff on your hands, so in some cases (and this is one of
> them) the choices will
> be made that may seem too harsh to some people. That's just life.


Focus has a flip side.  Tunnel vision. History is my guide.  A single
monolith with significant market share makes a decision based on their
Unique Vision(TM).  It's not always right.  I'm not sure the average age
of the list but I remember a time when IBM was god almighty ruler of the
PC universe  They decided that MicroChannel architecture was the way to
go. If you wanted it, you had to go IBM otherwise try another
manufacturer.  Everyone one did, and now they sell JBOSS.

If you're t

Re: [Ayatana] Regarding Notify-OSD's Position in Karmic Koala

[Mark Shuttleworth]

Luke Benstead wrote:
> The only thing against that is what Mark said about the async
> notifications growing upwards, but I still don't see why that's a
> problem (it would look pretty cool if the existing text moved up, then
> the new line faded in below).
That would be worth a flash mockup, or code mockup, to see in practice.

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

Re: [Ayatana] Regarding Notify-OSD's Position in Karmic Koala

[Lance]

I just realized that I mistakenly posted the following directly to Mark 
Shuttleworth yesterday in error (mistakes abound when you can't see well), and 
felt that it should be shared with all:

"I'd like to clarify something and make a possible suggestion that may
or may not even be possible or viable. I certainly respect your opinion
and IMHO this is not a "show stopper". There are other options
available.

In my case the position of notify-osd is not a matter
of preferability nor is position the only concern. Since I am legally
blind the matter of " default time displayed" is just as important as
the position if not more so. Quite simply if I don't have time to
change my focus to the notifications I have no idea what I was notified
of.

Anyway, I wonder if this might be something that could be
explored in Assistive Technologies. I've always been impressed with the
same in Ubuntu but I've not explored that option at all and have no
idea how to approach such an effort or where to begin but thought I'd
throw the thought out there.

I should also mention there are already downstream efforts at "hacking" 
notify-osd:
http://launchpadlibrarian.net/31954532/gravity-options.patch

I haven't had time to try it. It's hardly a priority. So far I just revert to 
notification-daemon."

Apologies for getting it wrong the first time.

___
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] Regarding Notify-OSD's Position in Karmic Koala

[Alex Lourie]

>
>
>
> > > I believe it will drive people away, hurt
> > > upstreams, a number of side streams and limited sections of downstream.
> > >
> > What does that mean exactly? I think you're mouthing off because you
> > don't like the idea of having to go with something you don't
> > personally like occasionally.
>
> Martin is looking at the big picture.  He's concerned that you are going
> down a path that will cause a fork or general disruption.  I agree.
> Linux is at a fragile state.  It is posed to make a significant mark in
> the desktop/portable market in the next couple of years.  This kind of
> derailment could destroy the momentum.
>
>
>
Ok, hold on a second. How come the presence or absence of options in some
quite experimental software DESTROYS moment of Linux Desktop??? I can't
understand
how is it that after so many work being put into the operating system, and
specifically Ubuntu Linux,
everything would depend on some specific implementation of some specific
idea?

And what if other distributions decide not to use Notify-OSD? Is complete
Linux OS will be suddenly doomed?


> >
> > > But I have no data on that, that's just from my own principles of
> > > inclusion and experience in trying to do the hard job of bringing
> > > together conflicting ideas.
> > >
> > If you have deep experience of that you'll understand what I mean when
> > I say you cannot always include everybody if you want a decisive and
> > exciting result. You can aim to include everyone if you are
> > comfortable taking a very long time to produce something that is hard
> > to use and ultimately not exciting.
>
> But if you refuse to offer any customization, you tick off the very
> people you need to survive.
>
>
>
I don't believe that. I do believe that when the Notify-OSD will be release
in official 9.10, many
developers and otherwise technically inclined people will have absolutely
great time to create
exciting applications with it. I do believe that there's a lot of place for
creativity here.



> > > > In Ayatana, we'll take an opinionated stance, and we'll apply some
> > > > common principles to the design process,
> > > >
> > >
> > > This principle isn't common,
> > This willingness to be decisive isn't common, no. By common principles
> > I meant that we will focus on specific areas of the experience, bring
> > some specific principles to bear, and live with the results.
>
> "Live with the results"  This really scares me.  I've looked forward to
> your guidance to the community with regard to big picture concepts like
> cadence and collaboration.
>
> This statement looks like your account has been hijacked and you're in
> Hawaii. =0
>
>
Uhm, why is it so hard to include "let do this and change that" into "live
with the
results"? It's no an MS process, where the decision is made, it never gets
reviewed
and nobody cares what users think. We have an interactive process, where
something
is released (soon to be in this case too), then it gets feedback, and then
new iteration cycle
begins. But to produce great product it is imperative to have focus. You
can't have focus with
too much stuff on your hands, so in some cases (and this is one of them) the
choices will
be made that may seem too harsh to some people. That's just life.



> > Whether or not non-computer-specialist people continue to embrace and
> > enjoy Ubuntu. And whether computer specialists continue to do the
> > same.
>
> It's the second group that you are in danger of alienating. :/
>
>
Hardly so. I don't believe that technically savvy people will stop using
Ubuntu
because they can't change the default position of Notify-OSD.


> >
>
> Don't think that Ubuntu is built on equality of the producers. It is
> > not. It's built on empowering the best people to lead and take
> > decisions.
>
> And a huge amount of community support.  The human resources around
> Debian and Ubuntu dwarf any capital investments thus far.
>
> Remember that you stand on the shoulders of giants. And they are fickle.
>

Indeed so.


>
> >
> > You don't have to look very far to find projects with similar goals to
> > Ubuntu that don't have the guts or the willpower to take the same
> > approach. You can see for yourself the consequences - paralysis,
> > indecisiveness, slowness, complexity.
> >
> > If you're reacting to the fact that right now I'm a driving force in
> > this, understand that the role will shift onto the shoulders of others
> > as that capability in Ubuntu and Canonical matures. It's been that way
> > with many things.
>
> I don't think that anyone has a problem with you.  You've made
> tremendous contributions to the Linux desktop.
>
> BTW, I could care less about the position of the box.  This problem is
> bigger picture.
>
> We see a dark path.  We see you walking down it.  You don't seem to see
> it even with your experience in open source.  It's contradictory and
> disturbing.
>
>
Please Jim, get some proportion here. How come one application, albeit at
the core
of the s

Re: [Ayatana] Regarding Notify-OSD's Position in Karmic Koala

[Jim Rorie]

On Wed, 2009-10-21 at 13:02 +0100, Mark Shuttleworth wrote:

> Sometimes folks actually want to push their own ideas, and think
> that's collaboration. That's not going to work here, because we have a
> core driver already.

There is a difference between push and contribute.  It's typically in
the eye of the beholder.  If you don't agree with it, then it's pushing.


> 
> There is lots to be done around that core, and this list is one way
> people can participate in that.
> 
> > There are people who will give up their personal visions
> > for yours without lots of hard data, but most of those are called
> > employees...
> >   
> Not really. Employees aren't serfs. But it's true that we have more
> opportunity to reach a common understanding in areas where we have
> higher-bandwidth interaction.

And they also understand that truly rocking the boat is not in their
long term career interests.  They wont hold their ground even if they
think you are dead wrong.  Or you might not hire them.  Same result.

Group Think...  It causes wars and bank failures.


> 
> > > We found this with Ubuntu itself - we reduced the default application
> > > install set to a single app for each major function
> > > 
> > 
> > The key here is 'distribution default'. I will congratulate you on the
> > decision to prevent choice paralysis in normal users, insisting upon a
> > single application per function at distribution time is the right
> > choice. But this is development, this is upstream, that logic may not be
> > relevant.
>
> Ah, right, the old "WE are above the default, WE are smarter, WE can
> have it any way we want". Sure you can. Just not here ;-)

You have a default, but you provide options.  Example:  Empathy is now
the default.  That's fine for most people, but you have one serious
regression. The IRC crowd.  IRC handling is scandalously bad, admitted
by the empathy folks themselves.  Who does this effect? US. The power
users that take time out of our busy schedule to participate in
something that is important to us.  

HOWEVER, I can still load Pidgin and I run both.  Pidgin for IRC and
Empathy for most everything else.  Do I expect that in the default
install.  No.  But I can adapt.  Give me an option and I will be happy.



> > I notice that you don't insist upon one application per
> > function available in the repositories or launchpad PPAs.
> >   
> Of course not. Nor would I resist there being many branches of
> notify-osd. But I will resist calls for "this should be an option".

And if notify-osd branches fifty times because Canonical has a iron
fisted vision, then you've caused the community to waste resources on a
problem that had a simple fix.

> I've done it before on this list, and will do it again, because it's a
> common meme in open source. Creating an option is a way of avoiding
> social tension - "we don't have to either agree or consent, we can
> just create an option". It's a figleaf for a failure either to reach
> consensus or to accept that someone may take a decision that has
> detractors.
> Of course, that's not ALWAYS true. But it is generally the case, and
> in this case it REALLY is the case.

Compromise is a valid path, and in politics it avoids or ends wars.  The
point that needs to be discussed is how to provide options without
destroying your vision of the desktop.  There are solutions.


> > > One of the great failings of the community approach is that it
> > > attracts folks who like to customise the environment to the point
> > > where it is "perfect for them", at which point they stop caring about
> > > the environment that the typical user sees.
> > > 
> > 
> > Why is the consumer grade user more important to design development than
> > creative experimental people? This fight against the creative ecosystem
> > can only be destructive.
> Why is this a fight against creative, experimental people? There is
> still lots of room for experimentation and creativity. But we will not
> ship an obtuse, anything goes, highly configurable experience.

No one is arguing for that.  But design with an iron fist is what mac
and MS do.  It's part of what drove us to Linux to begin with.

Is a gconf entry override for the position such a heinous perversion of
the Ayatana vision?  The ordinary user will never be affected.  Isn't
the power user part of the Ayatana vision?


> > I believe it will drive people away, hurt
> > upstreams, a number of side streams and limited sections of downstream.
> >   
> What does that mean exactly? I think you're mouthing off because you
> don't like the idea of having to go with something you don't
> personally like occasionally.

Martin is looking at the big picture.  He's concerned that you are going
down a path that will cause a fork or general disruption.  I agree.
Linux is at a fragile state.  It is posed to make a significant mark in
the desktop/portable market in the next couple of years.  This kind of
derailment could destroy the momentum.


> 
> > B

Re: [Ayatana] Regarding Notify-OSD's Position in Karmic Koala

[Luke Benstead]

>
> So, probably, the solution is rather to find some clever algorithm that
> places them dynamically based on the current desktop conditions, but we
> won't be motivated to search for this algorithm if we resort to creating
> more options as soon as someone complaints.

Heh, OK you've almost won me over, the thing is, allowing overriding
of the default position would be a solution that could happen right
now, and would please people until this algorithm comes about. But I
do see your point.

Personally, somewhere along the bottom would solve all the issues I
can think of (window decorations, firefox search bar/box etc.) - the
only thing against that is what Mark said about the async
notifications growing upwards, but I still don't see why that's a
problem (it would look pretty cool if the existing text moved up, then
the new line faded in below).

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] Regarding Notify-OSD's Position in Karmic Koala

[Martín Soto]

On Wed, Oct 21, 2009 at 3:16 PM, Luke Benstead  wrote:

> [...] I think the reason that notify-osd's positioning is a particular
> sticking point with many people is that it is something where no
> default location will suit the majority of people. Users with visual
> problems, non-default layouts, applications that have elements right
> where the notification pops up all would like, perhaps need, some way
> to move them out of the way. And the real reason that it causes such
> an issue with people is it's a bloody good idea and they want to be
> able to use it.
>

This is a good point.


> I understand fully what you are saying about both sensible defaults,
> and how too much configuration is a bad thing, (I'm a programmer, I
> know how much more work it adds to make something configurable) but
> sometimes you need to allow some kind of override switch.
>

>From reading this paragraph, though, I get the impression that you see
configuration options as the only, or, at least, the better solution in this
case. Are you really sure? Suppose you go to a user and ask "how would you
like your notifications, top-right corner, middle-right side or lower-right
corner?" Most people, even those technically minded, wouldn't be able to
answer. Actually, they would have to try each option for a while, and it may
turn out that all three are equally disrupting, except that the particular
conditions in which they happen to cause disruption may vary from one to the
next.

So, probably, the solution is rather to find some clever algorithm that
places them dynamically based on the current desktop conditions, but we
won't be motivated to search for this algorithm if we resort to creating
more options as soon as someone complaints.

It is not that problems shouldn't be addressed. They should. The point is,
however, that customization is almost never the right way to address them.

Best wishes,

Martín
___
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] Regarding Notify-OSD's Position in Karmic Koala

[Martín Soto]

2009/10/21 Paulo J. S. Silva 

> In my humble opinion this is one of best ways to end a conversation:
> takes your "opponent" point of view and turn it into a caricature that
> make it sound unreasonable.
>

Well, I thing exposing the weaknesses in other people's argumentation is at
the core of any real debate. I'm not trying to say that he's completely
unreasonable (he isn't indeed!), I'm only implying that his argument is not
as community-oriented as he may like to make it sound.


> As far as I can see Owens point is that we don't need such a radical
> "one size fits it all" minding set because that is not really possible
> in all cases. One size does not fit it all always. I don't think that
> everybody else that asked for customizations wanted
> "my-customized-to-the-last-pixel-way-or-the-highway". Usually we ( I
> have already asked for customization in this list) want a way-out from
> what we consider bad UI decisions that are really making our life
> worse when using Ubuntu.
>

While it is true that one size cannot fit everyone, when dealing with UI, it
is surprising how certain sizes can actually fit incredibly large numbers of
people. Almost by principle, customization detracts from finding such a
sweet spot. This is why good designers try their best to avoid it.


>
> For example in the osd-notify positioning, adding the possibility of
> selecting one of the corners would be enough. It would be certainly
> enough also to hide such option requiring gconf-editor to change it.
>

This would be enough for you, of course, because you would just fire
gconf-editor, change the option, and never think of the problem again. I
think Mark's point was to avoid precisely this, and I agree with that
entirely. By adding the option, we're just dodging the problem, not solving
it.


> Can't we just see that in some cases it is *really hard* if not
> impossible to find a default setting that would not step on many
> peoples toes and add a gconf-entry to select it? If an UI decision,
> for example, generates a bug reports with hundreds of comments it may
> be a good indication that the decision is not good for a very large
> number of people even if it is good for most of the people. Then we
> can work really hard to find the best default setting without really
> left part of our community behind.
>

Changes to a user interface almost always cause some irritation at the
beginning. Most users just live with that, because they don't have another
option, but we computer experts know better. We can fiddle with the
computer, so our tendency is to look for the option that lets us put the
thing back where it used to be and forget about it.

I bet that most of the people who are complaining now are reacting precisely
like this. They see the change, sort of don't like it, look for the
give-me-back-my-old-environment option, and become pretty much upset when
they don't find it. Their next step is to log into Launchpad as quickly as
their fingers permit. I bet that most people who aren't computer experts
wouldn't bother at all about notifications slightly changing their position.
Actually, most of them won't even notice the change.

Now, that said, you are right in that options may be the right solution in
some cases, but such cases are rarer than you think. Finding a proper
solution is hard, and, in this case, it may take several further attempts to
find something that works really well. It is just too early for giving up.

Cheers,

M. S.
___
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] Regarding Notify-OSD's Position in Karmic Koala

[Alex Lourie]

> Look at it this way, every decision you make when designing software,
> you weigh up the pros and cons of all the options before you make it.
> When neither option has any concrete benefit over the other, that's
> when it's down to personal preference and that (I would argue) is when
> you make it configurable and then, only then when it's worth the extra
> work. I would say that notify-osd's positioning is one of those
> occasions.
>
> Luke.
>
>
And that's where the problem begins. How many options would you make
configurable? In worst case you'd
have it with as much options as you have different opinions. And this can
quickly become unmanageable.

Noone takes options away from users in Ubuntu. Anyone can replace the
application provided by the distribution for anything
of their choice.

In case of Notify-OSD location, it seems that the argument here is for
something that most of its users haven't even seen yet. I find it
interesting that such a debate can be around something that is not even
officially released. I would say, let the main group of target users use it
first for some time. If the need for options will become obvious, I think
that Mark and all the people working on it would also agree with that, and
options will appear - they are not an enemy after all.

Alex.
___
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] Regarding Notify-OSD's Position in Karmic Koala

[Luke Benstead]

> In general, no. If the ideas they express are better, but the metrics we can
> bring to bear (including the view of the people to whom the design
> leadership has been given) then those patches can be included without
> options, the default behaviour will be improved for all. If they just create
> options for options sake, no. That creates complexity and cruft in code. Go
> and look at the consequences of that, it's all around you. Poor testing,
> poor quality, poor consistency.

I think the reason that notify-osd's positioning is a particular
sticking point with many people is that it is something where no
default location will suit the majority of people. Users with visual
problems, non-default layouts, applications that have elements right
where the notification pops up all would like, perhaps need, some way
to move them out of the way. And the real reason that it causes such
an issue with people is it's a bloody good idea and they want to be
able to use it.

I understand fully what you are saying about both sensible defaults,
and how too much configuration is a bad thing, (I'm a programmer, I
know how much more work it adds to make something configurable) but
sometimes you need to allow some kind of override switch.

Look at it this way, every decision you make when designing software,
you weigh up the pros and cons of all the options before you make it.
When neither option has any concrete benefit over the other, that's
when it's down to personal preference and that (I would argue) is when
you make it configurable and then, only then when it's worth the extra
work. I would say that notify-osd's positioning is one of those
occasions.

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] Regarding Notify-OSD's Position in Karmic Koala

[Brett Cornwall]

Mark Shuttleworth wrote:

  A guiding principle in Ayatana is to *reduce* customisation, not
increase it.

  

Then I am afraid that you are going to lose a lot of interest from lots
of people. I really do understand your intentions, and I think they are
wonderful, but there is a happy medium. Microsoft has demonstrated
that. MacOS has very poor customization, and my Mac friends suffer from
it. My Windows friends are pretty happy with their ability to do basic
customization, such as moving the start bar, changing colors, and other
pretty neat things. My mac friends that have been experiencing Ubuntu
are bothered by the inability to configure Notify-OSD, but they deal
with it just like they deal with every other disappointment in
customization for Mac. My Windows friends, on the other hand, think
it's a monstrosity. Abhor it. Some have even removed it in favor of the
older, uglier, less effective way. Of all my friends trying Ubuntu,
only one is semi-proficient in computers.

There's certainly a point in which you should stop just giving SO MANY
OPTIONS to the users (this is why I do not use KDE), but this really is
something that I think matters quite a bit. This is something that
people are going to have to notice tens of times a day. If they don't
like it, each bubble will just make them less and less happy. That's
been happening to myself when I bug hunt for Karmic.

  
First, we get much better collaboration and communication, and much
better testing, if everyone is looking at the same experience. We found
this with Ubuntu itself - we reduced the default application install set
to a single app for each major function: one browser, one mail client,
one word processor. That was controversial at the time - most
distributions were competing on HOW MANY apps they could install in one go.

  

And this is why I use Ubuntu - they care about quality, not potential
quality. Fedora is always introducing these new and wonderful things,
and they laugh at poor old Ubuntu for not being up to date, but when
their massive kernel panics begin from a hasty adoption of Plymouth and
KMS, it makes me grateful that there's an OS with head on shoulders.
Thank you.

  One of the great failings of the community approach is that it attracts
folks who like to customise the environment to the point where it is
"perfect for them", at which point they stop caring about the
environment that the typical user sees. They run "the latest code from
CVS" so they don't care about bugs in the stable version. They swap out
components for things that are more interesting and then they have no
visibility AT ALL on the pieces a new user sees.
  

Look at Firefox - The view is very customizable and flexible, yet
remains an asset to the entire networking world, now. If someone
doesn't like how it looks, you change it through the "view"
preferences. You can do more with addons. But for those that just want
to browse the web, you just click on the FF icon and start browsing.
Notify-OSD's position is hardly something that could go massively wrong
and start wreaking godzilla-havoc on the computer. Once the Preferences
and Administration menu clutter gets better organized, then it'd hardly
be a huge problem to have two preferences for Notify-OSD in a section
below other display preferences. This is, after all, something the
users have to look at a lot! It's like having no choice in the matter
for what wrist you wear your watch, or what pocket you put your phone
in.

  
We will not make that mistake.

In Ayatana, we'll take an opinionated stance, and we'll apply some
common principles to the design process, and we'll live with the results.

I have no interest whatsoever in making it possible for anybody to have
any environment they want - we already have that. I'm interested in
driving forwards to build a default out of the box experience which is
as good as we can make it for the new, consumer user. Most people on
this list are NOT a new, consumer user, so I'm afraid you will have to
work hard to think from that perspective if you want your ideas to
resonate here.
  


That's a very strong statement. I guess I can see your viewpoint, and I
think (though I hate it) that may be a reason that Apple has such a
solid product - they only have ONE WAY.

but, you know you can customize Growl ;)

  
Mark

  


-- 
-Brett Cornwall




___
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] Regarding Notify-OSD's Position in Karmic Koala

[Paulo J. S. Silva]

>It certainly doesn't sound like "I am because of my community", it
>   sounds like "I am because of what Mark likes to see". Scary in a way.


>This can also work the other way around. I could say that your
> my-customized-to-the-last-pixel-way-or-the-highway stance is a pretty selfish 
> one, and
> that someone who is willing to sacrifice >some of his own very personal needs 
> and
> desires in order to work on what the large majority of
> people actually need and can use is a much better community member.
> What do you think about this?

In my humble opinion this is one of best ways to end a conversation:
takes your "opponent" point of view and turn it into a caricature that
make it sound unreasonable.

As far as I can see Owens point is that we don't need such a radical
"one size fits it all" minding set because that is not really possible
in all cases. One size does not fit it all always. I don't think that
everybody else that asked for customizations wanted
"my-customized-to-the-last-pixel-way-or-the-highway". Usually we ( I
have already asked for customization in this list) want a way-out from
what we consider bad UI decisions that are really making our life
worse when using Ubuntu.

For example in the osd-notify positioning, adding the possibility of
selecting one of the corners would be enough. It would be certainly
enough also to hide such option requiring gconf-editor to change it.

Can't we just see that in some cases it is *really hard* if not
impossible to find a default setting that would not step on many
peoples toes and add a gconf-entry to select it? If an UI decision,
for example, generates a bug reports with hundreds of comments it may
be a good indication that the decision is not good for a very large
number of people even if it is good for most of the people. Then we
can work really hard to find the best default setting without really
left part of our community behind.

best,

Paulo

Obs: I want to make one point clear. I am not defending that we should
add hidden options for everything. However I am defending we should be
open to the feedback and see that in some cases not having an option
is a bad decision. I have been reading this list for some months now
and up to now I could only see two cases where an option would be
clearly beneficial. The notifications position is one of 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] Regarding Notify-OSD's Position in Karmic Koala

[Mark Shuttleworth]

Martin Owens wrote:
> Hello Mark,
>
> On Wed, 2009-10-21 at 11:09 +0100, Mark Shuttleworth wrote:
>   
>> First, we get much better collaboration and communication,
>> 
>
> Do we? The first thing I've noticed from this experimental opinionated
> stance is a tendency to alienate and frustrate people who want to
> collaborate.

Yes and no.

Sometimes folks actually want to push their own ideas, and think that's
collaboration. That's not going to work here, because we have a core
driver already.

There is lots to be done around that core, and this list is one way
people can participate in that.

>  There are people who will give up their personal visions
> for yours without lots of hard data, but most of those are called
> employees...
>   
Not really. Employees aren't serfs. But it's true that we have more
opportunity to reach a common understanding in areas where we have
higher-bandwidth interaction.

>> and much better testing, if everyone is looking at the same
>> experience.
>> 
>
> Testing and experience can be brought about by standardisation of
> configuration at testing time.
>   
The famous "many eyes" do their testing all day, every day, on the
system they are running. They don't generally setup and run default
configurations to test just for fun.


>> We found this with Ubuntu itself - we reduced the default application
>> install set to a single app for each major function
>> 
>
> The key here is 'distribution default'. I will congratulate you on the
> decision to prevent choice paralysis in normal users, insisting upon a
> single application per function at distribution time is the right
> choice. But this is development, this is upstream, that logic may not be
> relevant.

Ah, right, the old "WE are above the default, WE are smarter, WE can
have it any way we want". Sure you can. Just not here ;-)

>  I notice that you don't insist upon one application per
> function available in the repositories or launchpad PPAs.
>   
Of course not. Nor would I resist there being many branches of
notify-osd. But I will resist calls for "this should be an option".

I've done it before on this list, and will do it again, because it's a
common meme in open source. Creating an option is a way of avoiding
social tension - "we don't have to either agree or consent, we can just
create an option". It's a figleaf for a failure either to reach
consensus or to accept that someone may take a decision that has detractors.

Of course, that's not ALWAYS true. But it is generally the case, and in
this case it REALLY is the case.

>> One of the great failings of the community approach is that it
>> attracts folks who like to customise the environment to the point
>> where it is "perfect for them", at which point they stop caring about
>> the environment that the typical user sees.
>> 
>
> Why is the consumer grade user more important to design development than
> creative experimental people? This fight against the creative ecosystem
> can only be destructive.
Why is this a fight against creative, experimental people? There is
still lots of room for experimentation and creativity. But we will not
ship an obtuse, anything goes, highly configurable experience.

>  I believe it will drive people away, hurt
> upstreams, a number of side streams and limited sections of downstream.
>   
What does that mean exactly? I think you're mouthing off because you
don't like the idea of having to go with something you don't personally
like occasionally.

> But I have no data on that, that's just from my own principles of
> inclusion and experience in trying to do the hard job of bringing
> together conflicting ideas.
>   
If you have deep experience of that you'll understand what I mean when I
say you cannot always include everybody if you want a decisive and
exciting result. You can aim to include everyone if you are comfortable
taking a very long time to produce something that is hard to use and
ultimately not exciting.

>> In Ayatana, we'll take an opinionated stance, and we'll apply some
>> common principles to the design process,
>> 
>
> This principle isn't common,
This willingness to be decisive isn't common, no. By common principles I
meant that we will focus on specific areas of the experience, bring some
specific principles to bear, and live with the results.

>  it's something I haven't seen in any other
> projects, even the ones that I would aspire to with regards to design
> and vision.
>   
Such as?

> Can you tell me what the metrics that you'll be using to see the
> results?
>   
Whether or not non-computer-specialist people continue to embrace and
enjoy Ubuntu. And whether computer specialists continue to do the same.

>> I have no interest whatsoever in making it possible for anybody to
>> have any environment they want - we already have that.
>> 
>
> Hmm, I can't actually believe you would say that. It sounds so,
> authoritarian. To dictate what is in the best interest of the masses and
> removing th

Re: [Ayatana] Regarding Notify-OSD's Position in Karmic Koala

[Martín Soto]

On Wed, Oct 21, 2009 at 1:13 PM, Martin Owens  wrote:

> [...] The first thing I've noticed from this experimental opinionated
> stance is a tendency to alienate and frustrate people who want to
> collaborate. There are people who will give up their personal visions
> for yours without lots of hard data, but most of those are called
> employees...
>

It is impossible for a single product to encompass the personal design
visions of a random group of people, who come from different backgrounds,
have various levels of experience with UI design, and are targeting diverse
sets of requirements. If you want to achieve something, you need a common
vision.

As for giving up personal visions, I don't think anyone is being asked to do
that. You can share Ayatana's (or, if you will, Mark's) vision and try to
contribute accordingly, or you may not, in which case you can fork the code,
or start a new UI project, or simply not do anything at all. In any case,
this is not an attempt to exclude you or anyone else. Is just an attempt of
a certain group of people to concentrate their efforts on a particular set
of clearly defined goals so that they can be more productive and actually
achieve something.

[...] The key here is 'distribution default'. I will congratulate you on the
> decision to prevent choice paralysis in normal users, insisting upon a
> single application per function at distribution time is the right
> choice. But this is development, this is upstream, that logic may not be
> relevant. I notice that you don't insist upon one application per
> function available in the repositories or launchpad PPAs.
>

And if you or anyone else were to create a different UI, I don't think it
would be excluded from those repositories either. It is only that the
resources of the Ayatana project wouldn't be dedicated to it.

>
> > In Ayatana, we'll take an opinionated stance, and we'll apply some
> > common principles to the design process,
>
> This principle isn't common, it's something I haven't seen in any other
> projects, even the ones that I would aspire to with regards to design
> and vision.
>

This principle is very common. Indeed, I'd say it lies behind every single
successful free software project. Let's make a little Gedankenexperiment:
Imagine you find an interesting free software project with an active and
dedicated community. When you look into it in some more detail, however, you
find quite a number of things you don't like. The code is not organized
according to you liking, and the set of features offered doesn't appear
quite right to you. Being such a good programmer as you are, you proceed
with no further delay to rewrite 80% of the code in order to fix these
issues, and send a patch back to the community. Now, back to reality, what
would be the likelihood of this patch to be accepted?

I would say, almost none. Why? Because this community formed around a
particular vision of what their program should be. The vision was probably
set by the original program creator. It was also probably never clearly
expressed in words, but it was expressed through the code. For these
reasons, when you contribute a patch to an already established project, you
are expected to play by the rules of that project. If you don't want to, you
are always free to fork the project or start a competing one, but you
shouldn't claim that they are excluding you just because the don't want to
adapt their vision to yours.


>
> > I have no interest whatsoever in making it possible for anybody to
> > have any environment they want - we already have that.
>
>
> Hmm, I can't actually believe you would say that. It sounds so,
> authoritarian. To dictate what is in the best interest of the masses and
> removing the choices of those who aren't believers in the one true
> vision.
>

It seems to me you're concentrating too much on the "I have no interest
whatsoever..." part of Mark's quote, while deliberately ignoring the "we
already have that" part.


>
> It certainly doesn't sound like "I am because of my community", it
> sounds like "I am because of what Mark likes to see". Scary in a way.
>

This can also work the other way around. I could say that your
my-customized-to-the-last-pixel-way-or-the-highway stance is a pretty
selfish one, and that someone who is willing to sacrifice some of his own
very personal needs and desires in order to work on what the large majority
of people actually need and can use is a much better community member. What
do you think about this?


>
> Principled Regards, Martin Owens
>

Ditto,

Martín
___
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] Regarding Notify-OSD's Position in Karmic Koala

[Martin Owens]

On Wed, 2009-10-21 at 13:37 +0200, Victor wrote:
> I quote Mark from earlier in this list:

> There's always a temptation, when two smart and well-meaning people
> can't agree, to add an option so they can both get what they want. It
> "costs nothing" to add the checkbox, and it creates the illusion of
> consensus because "we can each have what we want" which makes it "easy
> to collaborate". This dynamic drives a lot of UI - especially in open
> source, where the consequence of a refusal to reach a compromise might
> result in the loss of a contributor.

Thanks Victor,

Something I missed. I need to be clear about what configuration at the
distribution level and configuration shown to the user running a default
installation.

I mean distribution level. Users should have as few options as practical
by default, but developers should have the option to develop at their
user's request, an optional addition to express optional options as
optional dialogs in a hypothetical optional way.

Sorry if I confused what I was saying by not being clear enough.

Regards, Martin


___
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] Regarding Notify-OSD's Position in Karmic Koala

[Victor]

I quote Mark from earlier in this list:

There's always a temptation, when two smart and well-meaning people can't
agree, to add an option so they can both get what they want. It "costs
nothing" to add the checkbox, and it creates the illusion of consensus
because "we can each have what we want" which makes it "easy to
collaborate". This dynamic drives a lot of UI - especially in open source,
where the consequence of a refusal to reach a compromise might result in the
loss of a contributor.

But options, choices, checkboxes actually DO cost a lot. My first job was at
a newspaper, and the thing I learned there was that 90% of people will read
the headline, 30% will read the first paragraph, and 1% will read the last
paragraph of any article. Attention is precious. Also, I learned that the
10% of people who do not read the headline are actually skipping the WHOLE
PAGE. Why? Because nothing on the page jumped out of the noise for them.
Every checkbox or option or knob we add, raises the noise level, and
increases the chance that the user disengages completely. Also, every
checkbox or option results in additional code paths, all of which generate
more bugs and require more QA and more tests in the test suite. So, while
"agreeing to add an option" seems like a low-cost way to avoid having to
make a decision, it's an illusory solution. Collaboration is hard, but most
meaningful between people who see the world differently but find a way to
accept the same thing. A checkbox is an attempt to avoid that collaboration,
not a mark of it.

In this initiative, I want us to take a different approach. We will strip
away non-essential decisions from the user experience, at the cost of
flexibility in the final product. For me, that's not a bug, it's a feature,
though I accept that others feel differently. I'd like to build a community
that is aligned with that goal - here on the Ayatana list.


We can now see the "repercussions" of this principal.

The problem is that there is no perfect solution, whether for
technical/design reasons or user opinion.
When users file bugs because they do not like the default behaviour of
notify-osd then the "tough, get used to it" attitude sounds allot like Apple
speaking.

The users need to be given the chance to change how notify-osd works. You
could make it really difficult to change the default settings, but they
should at least be available.

Like Martin Owens, I don't really care about when and where I get notified,
but a lot of people do, and they don't agree.

2009/10/21 Martin Owens 

> Hello Mark,
>
> On Wed, 2009-10-21 at 11:09 +0100, Mark Shuttleworth wrote:
> > First, we get much better collaboration and communication,
>
> Do we? The first thing I've noticed from this experimental opinionated
> stance is a tendency to alienate and frustrate people who want to
> collaborate. There are people who will give up their personal visions
> for yours without lots of hard data, but most of those are called
> employees...
>
> > and much better testing, if everyone is looking at the same
> > experience.
>
> Testing and experience can be brought about by standardisation of
> configuration at testing time.
>
> > We found this with Ubuntu itself - we reduced the default application
> > install set to a single app for each major function
>
> The key here is 'distribution default'. I will congratulate you on the
> decision to prevent choice paralysis in normal users, insisting upon a
> single application per function at distribution time is the right
> choice. But this is development, this is upstream, that logic may not be
> relevant. I notice that you don't insist upon one application per
> function available in the repositories or launchpad PPAs.
>
> > One of the great failings of the community approach is that it
> > attracts folks who like to customise the environment to the point
> > where it is "perfect for them", at which point they stop caring about
> > the environment that the typical user sees.
>
> Why is the consumer grade user more important to design development than
> creative experimental people? This fight against the creative ecosystem
> can only be destructive. I believe it will drive people away, hurt
> upstreams, a number of side streams and limited sections of downstream.
>
> But I have no data on that, that's just from my own principles of
> inclusion and experience in trying to do the hard job of bringing
> together conflicting ideas.
>
> > In Ayatana, we'll take an opinionated stance, and we'll apply some
> > common principles to the design process,
>
> This principle isn't common, it's something I haven't seen in any other
> projects, even the ones that I would aspire to with regards to design
> and vision.
>
> > and we'll live with the results.
>
> Can you tell me what the metrics that you'll be using to see the
> results?
>
> > I have no interest whatsoever in making it possible for anybody to
> > have any environment they want - we already have that.
>
> Hmm, I can'

Re: [Ayatana] Regarding Notify-OSD's Position in Karmic Koala

[Martin Owens]

Hello Mark,

On Wed, 2009-10-21 at 11:09 +0100, Mark Shuttleworth wrote:
> First, we get much better collaboration and communication,

Do we? The first thing I've noticed from this experimental opinionated
stance is a tendency to alienate and frustrate people who want to
collaborate. There are people who will give up their personal visions
for yours without lots of hard data, but most of those are called
employees...

> and much better testing, if everyone is looking at the same
> experience.

Testing and experience can be brought about by standardisation of
configuration at testing time.

> We found this with Ubuntu itself - we reduced the default application
> install set to a single app for each major function

The key here is 'distribution default'. I will congratulate you on the
decision to prevent choice paralysis in normal users, insisting upon a
single application per function at distribution time is the right
choice. But this is development, this is upstream, that logic may not be
relevant. I notice that you don't insist upon one application per
function available in the repositories or launchpad PPAs.

> One of the great failings of the community approach is that it
> attracts folks who like to customise the environment to the point
> where it is "perfect for them", at which point they stop caring about
> the environment that the typical user sees.

Why is the consumer grade user more important to design development than
creative experimental people? This fight against the creative ecosystem
can only be destructive. I believe it will drive people away, hurt
upstreams, a number of side streams and limited sections of downstream.

But I have no data on that, that's just from my own principles of
inclusion and experience in trying to do the hard job of bringing
together conflicting ideas.

> In Ayatana, we'll take an opinionated stance, and we'll apply some
> common principles to the design process,

This principle isn't common, it's something I haven't seen in any other
projects, even the ones that I would aspire to with regards to design
and vision.

> and we'll live with the results.

Can you tell me what the metrics that you'll be using to see the
results?

> I have no interest whatsoever in making it possible for anybody to
> have any environment they want - we already have that.

Hmm, I can't actually believe you would say that. It sounds so,
authoritarian. To dictate what is in the best interest of the masses and
removing the choices of those who aren't believers in the one true
vision.

It certainly doesn't sound like "I am because of my community", it
sounds like "I am because of what Mark likes to see". Scary in a way.

> I'm interested in driving forwards to build a default out of the box
> experience which is as good as we can make it for the new, consumer
> user. 

So am I, Fixing Bug #1 is top priority. End users (not just customers)
are where my empathy has always been.

> Most people on this list are NOT a new, consumer user, so I'm afraid
> you will have to work hard to think from that perspective if you want
> your ideas to resonate here.

I have no technical or design problems with notify-osd, it's perfect for
me and for the hoards of people I teach Ubuntu to every week on the
ground. The discussions I've read here have been boring in a way,
because notifications aren't that interesting to me. Oh look,
information pops up; ok, move on to more important designs.

The problem I have is with the stated principles. I can't agree that
limiting choice in development is worthwhile. I think it's a confusion
between being a distribution downstream, where that is useful, and being
a project community upstream, where the same principle is a mistake.

If representatives of Fedora or Debian were to come here and provide
upstream patches to express the options they wanted to include in their
distributions default configuration; Would the project accept them with
the stated principle?

Principled Regards, Martin Owens


___
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] Regarding Notify-OSD's Position in Karmic Koala

[Mark Shuttleworth]

Brett Cornwall wrote:
> It all boils down to customization. I really feel that the way to make
> everyone happy is to have reasonable configuration for notify-OSD.
> Being able to choose the position easily and whether the policy is
> fixed or dynamic would allow peace to any that are dissatisfied. The
> rest that still don't like it are still free to just remove the package.

A guiding principle in Ayatana is to *reduce* customisation, not
increase it.

Why?

First, we get much better collaboration and communication, and much
better testing, if everyone is looking at the same experience. We found
this with Ubuntu itself - we reduced the default application install set
to a single app for each major function: one browser, one mail client,
one word processor. That was controversial at the time - most
distributions were competing on HOW MANY apps they could install in one go.

One of the great failings of the community approach is that it attracts
folks who like to customise the environment to the point where it is
"perfect for them", at which point they stop caring about the
environment that the typical user sees. They run "the latest code from
CVS" so they don't care about bugs in the stable version. They swap out
components for things that are more interesting and then they have no
visibility AT ALL on the pieces a new user sees.

We will not make that mistake.

In Ayatana, we'll take an opinionated stance, and we'll apply some
common principles to the design process, and we'll live with the results.

I have no interest whatsoever in making it possible for anybody to have
any environment they want - we already have that. I'm interested in
driving forwards to build a default out of the box experience which is
as good as we can make it for the new, consumer user. Most people on
this list are NOT a new, consumer user, so I'm afraid you will have to
work hard to think from that perspective if you want your ideas to
resonate here.

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

Re: [Ayatana] Regarding Notify-OSD's Position in Karmic Koala

[Alex Launi]

On Tue, Oct 20, 2009 at 5:38 PM, Christian Hudon wrote:

>
> I personally think it'd be really nice (and useful) if something like the
> previous email from Mark was made available for every large UI change that
> Ubuntu makes. (I don't know... I'm thinking of something similar to the
> Python PEPs... Maybe even with links from the html version of the release
> notes, like the PEPs.) That way people who are not entirely happy about a
> change to the UI can understand the constraints under which said change was
> made, and then make more informed and constructive criticism at the very
> least.


https://wiki.ubuntu.com/NotifyOSD
The wiki page is pretty comprehensive imo.



-- 
--Alex Launi
___
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] Regarding Notify-OSD's Position in Karmic Koala

[Christian Hudon]

Mark Shuttleworth wrote:
The position is final for 9.10 but can certainly be reconsidered for 
Lucid.


The factors that need to be considered are:

 * fitting things into the corner is most aesthetically pleasing

 * the "synchronous" notifications (like brightness and volume) are 
fixed in size


 * the async notifications (IM's etc, things that happen elsewhere, 
not in response to a keypress) are variable sized and can grow vertically


 * sliding things around when something else grows is really bad, it 
is unpredictable and frustrating for a user trying to look at the 
thing that suddenly moves, so:
 - synchronous should not be below async (so that it does not have 
to slide down)
 - the bottom right corner doesn't work (because then async has to 
grow "upwards")

[snip more explanatory awesomeness]

Hello.

Lurker here, but this is too good to pass up, and even ties in with the 
"closed design list" discussion. Am I the only person who thinks that 
reading the previous email from Mark listing the factors, contraints and 
things that were tried makes the decisions that were reached and end 
result (in this case for the Notify-OSD for karmic) *much* more 
understandable?


I personally think it'd be really nice (and useful) if something like 
the previous email from Mark was made available for every large UI 
change that Ubuntu makes. (I don't know... I'm thinking of something 
similar to the Python PEPs... Maybe even with links from the html 
version of the release notes, like the PEPs.) That way people who are 
not entirely happy about a change to the UI can understand the 
constraints under which said change was made, and then make more 
informed and constructive criticism at the very least.


 Christian


___
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] Regarding Notify-OSD's Position in Karmic Koala

[lord metroid]

The problem with the middle right in my opinion is that the are is usually 
occupied with data from other applications such as text one is reading or in 
the middle of media playback. Making that position more disruptive than in a 
corner. I don't see why bottom right would be a problem, I don't think growing 
upward would pose a problem in the least.

Best regards
Nicklas W Bjurman


- Original Message 
From: Luke Benstead 
To: Mark Shuttleworth 
Cc: Brett Cornwall ; ayatana@lists.launchpad.net; 
Mirco Müller 
Sent: Tue, October 20, 2009 3:03:33 PM
Subject: Re: [Ayatana] Regarding Notify-OSD's Position in Karmic Koala

> That's where we settled for 9.10. For 10.04 I would like to revisit the
> midpoint of the right hand side. I would not want to rehash old territory,
> so please factor in the above in proposing new ideas. I'm of the view that
> this decision involves at least one ugly compromise no matter which way it
> goes, and am happy to make the call so far (i.e. happy to be the one with
> the thick skin).
>
> If there is an implementation which avoids the issues and is sane, I'd love
> to include it.
>
> Mark
>
> ___
> Mailing list: https://launchpad.net/~ayatana
> Post to : ayatana@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~ayatana
> More help   : https://help.launchpad.net/ListHelp
>
>

Is having async notifications grow upwards really a problem? I think
that would actually look pretty good with sync notifications at the
bottom, and async slightly above showing a kind of scrolling effect as
more text comes in.  As there would be nothing above the async bubbles
they won't be moving any other screen decoration. If that was the
case, then there isn't much along the bottom of the screen in most
applications that could be disrupted. People read down the page so if
the bubbles were bottom-centre I don't think they'd get in the way so
much, they could also then be wider and shorter.

I still think the most awesome solution would be to allow the
notifications to be dragged around the screen to where the use prefers
though. ;)

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] Regarding Notify-OSD's Position in Karmic Koala

[Luke Benstead]

> That's where we settled for 9.10. For 10.04 I would like to revisit the
> midpoint of the right hand side. I would not want to rehash old territory,
> so please factor in the above in proposing new ideas. I'm of the view that
> this decision involves at least one ugly compromise no matter which way it
> goes, and am happy to make the call so far (i.e. happy to be the one with
> the thick skin).
>
> If there is an implementation which avoids the issues and is sane, I'd love
> to include it.
>
> Mark
>
> ___
> Mailing list: https://launchpad.net/~ayatana
> Post to     : ayatana@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~ayatana
> More help   : https://help.launchpad.net/ListHelp
>
>

Is having async notifications grow upwards really a problem? I think
that would actually look pretty good with sync notifications at the
bottom, and async slightly above showing a kind of scrolling effect as
more text comes in.  As there would be nothing above the async bubbles
they won't be moving any other screen decoration. If that was the
case, then there isn't much along the bottom of the screen in most
applications that could be disrupted. People read down the page so if
the bubbles were bottom-centre I don't think they'd get in the way so
much, they could also then be wider and shorter.

I still think the most awesome solution would be to allow the
notifications to be dragged around the screen to where the use prefers
though. ;)

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] Regarding Notify-OSD's Position in Karmic Koala

[Mark Shuttleworth]

Brett Cornwall wrote:
> Hello, I'm bringing attention to the mailing list that there's a fair
> amount of displeasure at the newly designated spot for notify-osd. You
> may read the entire bug report/thread here:
>
> https://bugs.launchpad.net/ubuntu/+source/notify-osd/+bug/438536
>
> In a nutshell, quite a lot of users found that Jaunty's behavior was
> stellar enough, and that this idea of reserving the top part for
> things like volume control are a bit too extreme. We can understand
> your motives, but we feel like it just doesn't work. We kindly ask you
> all to reconsider this.

The position is final for 9.10 but can certainly be reconsidered for Lucid.

The factors that need to be considered are:

 * fitting things into the corner is most aesthetically pleasing

 * the "synchronous" notifications (like brightness and volume) are
fixed in size

 * the async notifications (IM's etc, things that happen elsewhere, not
in response to a keypress) are variable sized and can grow vertically

 * sliding things around when something else grows is really bad, it is
unpredictable and frustrating for a user trying to look at the thing
that suddenly moves, so:
 - synchronous should not be below async (so that it does not have
to slide down)
 - the bottom right corner doesn't work (because then async has to
grow "upwards")

 * the top right corner has a lot of stuff there - window decorations,
tabs, tab controls (new tab, close tab etc) and in many apps, a search
input. So even though the look-through and click-through is *cool*, it's
still better not to put async right into the top right corner

For 9.10, two positions were considered and tried:

In both cases, we put sync above and async below, to avoid sliding
problems. We put them on the right hand side of the screen, as that's a
less-used area.

In the first case, we used the midpoint of the right side of the screen
and placed the notifications there, with sync above and async below. It
seems slightly odd to have them "hanging in space", but they conflict
with far less content there. This was the plan for 9.10. However, when
it landed, there were a lot of complaints saying that folks didn't like
it "out of a corner".

As a compromise, we moved to plan b, which was to put them in the top
right, with sync above. That means that the common case, with async
notifications, appears to leave a "gap". But it also avoids the worst
overlaps with things like window and tab controls, and usually also the
search bar.

That's where we settled for 9.10. For 10.04 I would like to revisit the
midpoint of the right hand side. I would not want to rehash old
territory, so please factor in the above in proposing new ideas. I'm of
the view that this decision involves at least one ugly compromise no
matter which way it goes, and am happy to make the call so far (i.e.
happy to be the one with the thick skin).

If there is an implementation which avoids the issues and is sane, I'd
love to include it.

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

[Ayatana] Regarding Notify-OSD's Position in Karmic Koala

[Brett Cornwall]

Hello, I'm bringing attention to the mailing list that there's a fair 
amount of displeasure at the newly designated spot for notify-osd. You 
may read the entire bug report/thread here:


https://bugs.launchpad.net/ubuntu/+source/notify-osd/+bug/438536

In a nutshell, quite a lot of users found that Jaunty's behavior was 
stellar enough, and that this idea of reserving the top part for things 
like volume control are a bit too extreme. We can understand your 
motives, but we feel like it just doesn't work. We kindly ask you all to 
reconsider this.


Thank you :).

--
-Brett Cornwall
brettcornw...@gmail.com
Jabber: brettcornw...@jabber.org


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