Re: [Ayatana] Better use of backlight in Unity launcher

[Carl Simpson <cwd.simpson@xxxxxxxxx>]

Sticking with the examples of Banshee and volume, for the sake of argument, we also recognise two sorts of window indicator:

a)  A window indicator that stands alone as functionality dedicated to a particular window.  I call these “window-specific” window indicators.
b)  A window indicator which is a candidate for merger with system indicators under a “collapsing” indicator system, because they encapsulate system-relevant behaviours.  I call these “system-relevant” window indicators.

With the collapsing idea in place, things are like this:

1. Banshee is maximised.
Volume controls (as system-relevant) for Banshee are collapsed into the appropriate system indicator.  Window-specific window indicators for Banshee are present to the left of the system indicators.  No separate window indicator for Banshee's volume is shown.

2. Banshee is not maximised.
Volume controls for Banshee are in a window indicator, situated on Banshee's window decoration.  Volume controls for Banshee in the system indicator are now not present.  Other, window-relevant window indicators for Banshee are present on Banshee's window decoration as well.  System-relevant and window-specific window indicators do not appear distinguishable at this stage.

3. Banshee is minimised.
??????  (Banshee's volume cannot be changed?)

My concern is that the functionality of changing the volume of Banshee moves about quite a bit.  It does this in two ways:
1)  It moves from place to place in the interface- namely between the panel and the window decoration of Banshee.
2)  When in Banshee's window decoration it literally changes place on the screen.
This will be true of all system-relevant window indicators.

Is such a degree of movement of functionality acceptable?

Something also needs to be said about the case of minimisation.  Does the volume control for Banshee end up back in the system indicator, or does it simply become unavailable?  Other window indicator functionality would become unavailable in the case of minimisation, and it might be argued that this is only natural and intuitive.  However, we have two sorts of indicators (window-specific and system-relevant), and we have them for a reason- namely that some of them (system-relevant window indicators) encapsulate system-relevant behaviours.

It is only natural for window-specific behaviours to disappear with the window with which they are associated.  Without the window being at the forefront, its content does not affect us and the behaviours made available by its window-specific window indicators is not important to us.  For that reason, having window-specific window indicators tied to window decorations seems uncontroversial.

Should system-relevant behaviours, however, such as changing the volume of some sound that is playing, be tied to specific windows in this way?  System-relevant behaviours (such as a playing sound) continue to affect us regardless of the position or status of the windows of the applications producing them.

Do we really want users to be unable to change the volume of Banshee (or alter any other system-relevant thing for any application) when it is minimised?

Putting the system-relevant window indicators for minimised applications back in the panel adds yet another occasion on which that functionality moves position.

Looking at things as they are, I do not think that having window-indicators for system relevant behaviours is remotely wise.

If a behaviour is best placed inside a system indicator, my opinion is that it stay there at all times at which it is available at all.  In the context of the example at hand- Banshee's volume would be present in the system indicator when Banshee is running, and available nowhere else at any other time.

2011/2/20 Mark Shuttleworth <mark@xxxxxxxxxx>Oth

We're experimenting with different uses of the backlight. For example,
we'd like to experiment with using that to show focus in the keyboard
navigation case (Alt-F1). I don't think "running" is useful, given we
already have the symbolic pips, and I think there are risks to changing
the "look" of the icon when people are scanning lots of them quickly.

Suggestions welcome :-)

Mark


_______________________________________________
Mailing list: https://launchpad.net/~ayatana
Post to     : ayatana@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp