unity-design team mailing list archive
Mailing list archive
Re: end user ajustable Global menu Blacklist
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?
Yep. Discoverability takes a hit. We know.
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.
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,
Hyperbole not needed. Please remain rational and try not to overstep your
metaphors. It makes it hard to take things seriously.
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?
Oh, you! :P
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
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
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.
Tell a user to click and search through menus for a function that may or
may not be there?
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 <cgermann@xxxxxxxxx> wrote:
> -----Original Message-----
> From: unity-design-bounces+cgermann=gmail.com@xxxxxxxxxxxxxxxxxxx [mailto:
> unity-design-bounces+cgermann=gmail.com@xxxxxxxxxxxxxxxxxxx] On Behalf Of
> Conscious User
> Sent: Tuesday, January 29, 2013 7:05 AM
> To: unity-design@xxxxxxxxxxxxxxxxxxx
> 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:
> >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@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~unity-design
> More help : https://help.launchpad.net/ListHelp