unity-design team mailing list archive

[Mark Shuttleworth <mark.shuttleworth@xxxxxxxxxxxxx>]

On 15/04/10 07:42, Chow Loong Jin wrote:
> 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.

Agreed.

The question is not really one of principle, it's one of taste.

> 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.
>   

I don't fault your logic. But I can disagree with your taste. I think it
would be crass if we encouraged every app indicator to have a secret
bunch of behaviours associated with specific clicks. I know that opening
up a possibility like this results in a mess - an unusuable mishmash of
secrets.

We *will* have some hidden treasures, like the scrollwheel-on-volume.
But they will be few and far between, and they will be on systemic
indicators rather than app indicators, for the moment.

Mark

Attachment: signature.asc
Description: OpenPGP digital signature