Oh, yay, this discussion again. It's been done to death many times over. The horse is no longer recognizable.
Let's go point by point, shall we? 1. Usability Yep. Discoverability takes a hit. We know. 2. Ergonomics If you're using focus follows mouse and don't already know about it? Sure. Otherwise, no. You know to fling your mouse to the top (and with acceleration, that's one movement) and bam, there's your menu. No need to hit a strip *somewhere* on the screen. Always at the top. 3. Papercut Yes, it is a papercut. A small thing that affects usability. That's what a papercut it. A fix has been designed, implementation is waiting. I don't know how to code, otherwise I'd do it just to stop the constant comments. Also, how big of an issue this is is not limited to subscribers to a bug. There are more people out there that don't know what launchpad is than do, I'm sure. 4. Dramatics Hyperbole not needed. Please remain rational and try not to overstep your metaphors. It makes it hard to take things seriously. 5. Blacklist Usually, items aren't blacklisted to appease users, it's for implementation issues in the appmenu indicator. And I believe those items are listed in DConf? That's pretty standard. As well, proposing to blacklist selectively is just... weird. Imagine a new user: "hey, if you need menus, they are at the top... except if you're using this... or this. Or that." Work as been done to ensure all defaults work correctly with the appmenu. 6. I have a lot going on. We all do. Same with Canonical devs. They also have a lot of priorities and wants themselves. Obviously, this issue isn't one of their top ones. Before accepting defeat, why not try to make the branch and propose it? At worse, it gets left out and you can say you did try. At best? You get a fix in Unity. I'm sure someone will help with upkeep. Of course you can always just keep using "revamp" and not worry. 7. Burden of Proof http://design.canonical.com/2010/05/menu-bar/ From nearly three years ago. MPT has since admitted this implementation is not exactly as he detailed. No one has ever denied that. But there is a well-thought out rationale from someone in Canonical aside from Mr. Shuttleworth. Canonical also does proper user testing. Can you also make such a claim or are we to speak strictly in anecdote? 8. Alberto Oh, you! :P 9. HUD HUD was put out as a way for people to keep fingers on the keys in a natural way instead of contorting fingers for shortcuts (I assume). And works for that. But I'll come back to this shortly. 10. Intrinisically Easier The current implementation versus an always on? I wouldn't say the former is easier. OK, phew, time to get into the contrarian role. Now, we have this global menu that's hidden. Let's ask why. Is it because menus are slowly being driven out into exile? To the point where default applications basically lack menus? Because they are ugly and an out-dated concept? I'd rather not answer. What I want to point out is the rationale for HUD. http://www.markshuttleworth.com/archives/939 Go ahead and click that, read it, and come back. You see, there's intention in these obtuse actions from a year ago. Our old menu system became the ashes which were reborn into HUD (which is more aligned with the ideas of Unity's then-future, namely, phones/tablets where you CAN'T have menubars and have a proposed voiced HUD feature) So you have this ONE element for interaction for former menus that enables you to use them across all devices. In fact, it would even help to make certain menu systems more robust, hopefully. What's easier? Tell a user to click and search through menus for a function that may or may not be there? OR Tell a user to hit "alt" and type what they want to do and let the system check for them? We didn't get rid of menus, they're still there for the power users. They'll never go away on Linux and having the global menu makes even older applications more on par with newer, non-menued applications visually. In fact, I'd think HUD would be enough reason to expand menus. It may not be ideal, but there's a reason. And this didn't even touch on the whole issue of legacy design support that the current implementation helps with/window controls/app title. Basically, this is the best fix for the situation without requiring devs to fix all existing applications. Maybe once an HIG is in place, changing this may be more in order. But right now you have to accommodate a lot of apps that aren't getting regular updates, could care less about Unity's idiosyncrasies, etc. Not everything is immutable. We need to continue looking forward. Some days, I miss the old ways. But more than that, i think that hiding the menus has been for the better in light of the ideas proposed. It helps get an antiquated thing out of user's faces while maintaining its usefulness and using it to power something even better. And let's not forget the there is a roadmap that was for HUD (if those mock ups weren't the next windicators ;)) http://youtu.be/3Di8djcRZUA On Tue, Jan 29, 2013 at 2:28 PM, Chad M. Germann <cgerm...@gmail.com> wrote: > > > -----Original Message----- > From: unity-design-bounces+cgermann=gmail....@lists.launchpad.net [mailto: > unity-design-bounces+cgermann=gmail....@lists.launchpad.net] On Behalf Of > Conscious User > Sent: Tuesday, January 29, 2013 7:05 AM > To: unity-design@lists.launchpad.net > Subject: Re: [Unity-design] end user ajustable Global menu Blacklist > > > >Chad, I'm not sure what you want to accomplish with this thread. This > comment from Mark: > > >https://bugs.launchpad.net/unity/+bug/682788/comments/261 > > >clearly shows that the problem is not IF, it's WHEN. > > Just Purposing a fix for a key usability issue with unity on desktop > computers. (last I checked the point of this mailing list.) And this is a > Usability and ergonomics issue that is beyond a paper cut it’s a bloody > missing limb and, why it is not a priority just boggles my mind. This one > strange behavior takes using what is otherwise a nice desktop and turns it > into a vacation on the shores of the lovely river Styx. > > This blacklist obviously exists in unity Eclipse is on it. It would be > easy to make this Blacklist an editable planetext file (As it should be > anyway in a Unix-like system) > > Believe me I would gladly dig into this problem myself but, I leave in > march for Basic Combat and, if you are thinking thati should have started > sooner I would have sooner but there was a fix in Unity revamped but > changes were maid to unity mainline that broke Revamp's always on feature. > lastly if I put the effort into this fix there is no guarantee that it > would be added to the mainline and I DEFFINTLY do not have the time to > personally maintain a patched branch of unity. > > > > > > -- > Mailing list: https://launchpad.net/~unity-design > Post to : unity-design@lists.launchpad.net > Unsubscribe : https://launchpad.net/~unity-design > More help : https://help.launchpad.net/ListHelp >
-- Mailing list: https://launchpad.net/~unity-design Post to : unity-design@lists.launchpad.net Unsubscribe : https://launchpad.net/~unity-design More help : https://help.launchpad.net/ListHelp
