Re: [Ayatana] Middle-click on indicators

[Philipp Wendler <ubuntu@xxxxxxxxxxxxxxxxx>]

Hello,

On 15/04/10 07:48, Cody Russell wrote:
> I guess my concern is that we're talking about breaking the concept of
> menus after it was previously decided at a UDS (by Mark, UX and DX
> teams, and community) that indicators should behave like (and be
> implemented based upon) menus.

Honestly, I don't like this decision for the following reasons:

1. Indicators are not menus in the eye of the user, they are quite
different to menus:
a) Menus have text buttons, indicators have icons. The indicators
"menus" are the only menus I know which have no text button. Even the
Application/Places/System menu in the same panel looks like a normal
menu and different from indicators, so why should users expect
indicators to be a menu? Using different styles for the same thing in
the same panel seems not to be the best thing. On the other hand,
indicators look exactly like the application starter icons (aside from
being less colorful), which are in the same panel, too. But indicators
behave not like the starters, which have a default action on left-click
and a popup menu on right click. The latter is IMHO also the most
commonly used user interaction pattern for icons since Windows 95.

b) Menus don't have sliders, checkboxes, progress bars etc. in them.
Perhaps next comes a text field to support changing the away message of
your IM client? Look at the "menu" of indicator-sound, does this really
look like a menu in your eyes?
c) Menus don't react on scrollwheel events, but indicator-sound does.
d) Menus don't appear/disappear and their button does not change
(neither in color nor in content), the only change over time may the
enabling/disabling of some of the menu items. Indicators however are
supposed to change or even disappear if I understood this correctly.

2. Menus are not powerful enough to support all kinds of user
interaction, and they are not meant to be that powerful. For the normal
use of menus this is fine, because they are accompanied by other user
interaction components. Almost all applications with a menu also have a
toolbar which provides one-click shortcuts for the most important
actions, so menus don't need to provide this. Menus also don't need to
provide configuration possibilities through checkboxes, sliders etc.
because there is a configuration dialogue which accomodates these
components. And if they are frequently used (like the volume slider),
there is an additional widget directly in the main window of the
application.
But for indicators, the situation is different. The user expects them to
be shortcuts (the long way would be to open the application window and
do the action there), so they can't require to open a configuration
dialogue to change something simple. And they are not accompanied by a
separate toolbar, which the user could use to invoke single-click
actions, so the indicators need to be used for this.
So in my eyes it appears that plain menus are simply the wrong tool for
the job.

> And from a usability side, I feel like we should minimize differences
> between menus in applications and menus in the panel rather than create
> more.

As I said, this would be ok if the panel would then also support all the
other user interaction ways that applications support. This means having
an additional toolbar with single-click actions, having a additional
sound icon which supports the scrollwheel (like Rhythmbox has) etc. We
can't use one single component which is normally used together with
other components and expect it to be best way to do things if used alone.


Just to make this clear: I'm not against indicators, I really think they
are promising and I think some of the possibilities they provide are
pretty cool. I'm just opposed to restricting them to the small feature
set of menus, they could be much cooler if they support more than menus.
Of course consistency accross different components is a good thing, but
indicators are already (and probably will always be) different than
anything else on the desktop, so adding a few additional user
interaction possibilities will not be significant. For consistency
accross different indicators, a nice solution has already been proposed.
A default action which is contained in the menu but may be activated
through a shortcut would be pretty consistent, especially if the default
action is highlighted in the menu in some way (the Windows Systray is
like this). This concept of default action could also be extended to a
default scroll action: An indicator which contains a slider could mark
this as the default slider which gets changed when the user uses the
scrollwheel over the indicator icon. Then the special case of
indicator-sound would be no special case anymore, so this would even
improve consistency.

Greetings, Philipp