Comment 87 for bug 438536

*#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.
*
The first reaction of a college-mate of me (who has always runned KDE) when
I showed him the "new ubuntu" was "*Hey, the notifications are misplaced, is
that a bug in the beta-release?"*. And to be honest, that was my first
reaction too. I only learned there is a difference between "synchronous" and
"asynchronous" notifications when I read about it while trying to file a bug
report about it.

I think we have to look at the notifications in an other way to solve this
issue. We can go in two directions:

#1: No difference is being made between "asynchronous" and "synchronous"
notifications, and they are handled exactly the same way. If the system does
make a difference, it will only be confusing to users.

#2: If we dó make a difference, this difference should immediately be clear
to users. For example by giving them a different layout and/or a compeltely
different location (as some users suggested, put the synchronous ones in the
middle of the screen).

Groeten, David

2009/11/2 cristian.vrabie <email address hidden>

> 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.positions
> #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.
>
> --
> Notifications should show up closer to top right
> https://bugs.launchpad.net/bugs/438536
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>
> Status in One Hundred Paper Cuts: Invalid
> Status in Notify OSD: Triaged
> Status in “notify-osd” package in Ubuntu: Confirmed
>
> Bug description:
> Binary package hint: notify-osd
>
> Currently the notify-osd notifications allot space for the volume
> control/brightness semi-notifications; this is rather jarring when the
> volume/brightness isn't being adjusted, unlike in Jaunty where application
> notifications default to above the volume/brightness.
>
> -------------
> This is a design decision , any comments relating to the position can be
> discussed in the ayatana Mailing list or you can follow the discussion >
> http://<email address hidden>/msg00741.html
>
> Any discussion regarding the position need to be discussed in the mailing
> list.
> --------------
>
> Mark Shuttleworth's comments from the mailing list:
>
> "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"
>
>