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

[Dylan McCall <dylanmccall@xxxxxxxxx>]

On Mon, 2009-11-02 at 13:57 -0500, Brett Cornwall wrote:
> 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.

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