*#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 protected]> > 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://www.mail-archive.com/[email protected]/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" > > -- Notifications should show up closer to top right https://bugs.launchpad.net/bugs/438536 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
