unity-design team mailing list archive

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