unity-design team mailing list archive

[Chow Loong Jin <hyperair@xxxxxxxxxx>]

On Thursday 15,April,2010 01:24 PM, Cody Russell wrote:
> On Thu, 2010-04-15 at 11:09 +0800, Chow Loong Jin wrote:
>> Frankly speaking, I'm quite tired of this reasoning. "Menus don't do
>> this",
>> "Menus don't do that". Did you also realize that menus don't have
>> icons as
>> buttons? They have *text* buttons.
> 
> It's never been common for menus to be used from icons, true, but we're
> not the first.  Chrome does it.  I've seen it in some other random
> places as well but I can't think of specific examples right now.
> Indicators can be designed based on either text or icons, just like
> menus can be.

Chrome and even Internet Explorer do it, yes. But do you notice something? Those
menus are actually menus that come from toolbar buttons that have tooltips to
describe their icons, but that's another whole different issue that deserves a
thread of its own.

> Regardless, using menus as a model was the original decision, and
> implementation-wise that's what we're doing.  It's a little late to try
> to change course.  If you think that was a bad decision, that's a
> different conversation.  But here we're talking about adding new
> features to specific instances of menus.. if middle-click corresponds to
> a particular action in an indicator menu, shouldn't the same thing be
> possible in all menus?

You are missing my point. I am not disputing the decision to use menus as a
model (like you said, that is for a different discussion). I am saying that we
should not keep ourselves locked to menus and menus alone, rejecting all other
features for the sole purpose of being a menu.

An indicator is not a menu, no matter how much you may attempt to model it after
a menu, and it serves a different purpose from that of the menus you are talking
about.

For example, a normal menu has many actions, out of which only a small subset of
which are very frequently used. These would be abstracted out into toolbar icons
(one-click access), e.g. Back, Forward, Refresh, New Tab, etc, and/or given
keyboard accelerators, which can then be triggered as long as the window the
menu belongs to has focus.

Now take a look at our application indicators. Each application indicator has
many actions, and most of them will have *one* frequently used one, i.e.
"Show/Hide Application".

We cannot assign these actions keyboard shortcuts, because the "window" that
owns these menus is the panel, and it does not make sense to have to focus the
panel in order to trigger these keyboard shortcuts. An alternative would be to
use global keyboard shortcuts, but I do not foresee that ending well.

We do not have a toolbar to abstract these actions out into. But wait! These
application indicators are *already* icons. They look and act more like toolbar
buttons that have menus (much like the Back/Forward history dropdown menu in
Firefox) than actual traditional text-based menus that you see at the top of
each window. So, why would it not make sense to provide one-click access to the
aforementioned frequently used action?

The following point has probably been raised before and beaten to death before,
but the time taken to aim for one application indicator icon, click for menu to
open, then aim *again* for the menu item needed is significantly more than the
time it takes to aim for the application indicator icon and click *once*. I
would say that the former case would result in slightly less than twice the
time, and approximately twice the effort taken compared to the latter case.

-- 
Kind regards,
Chow Loong Jin (GPG: 0x8F02A411)
Ubuntu Developer

Attachment: signature.asc
Description: OpenPGP digital signature