Still I fail to see what actual problem(s) windicators are meant solve or in what way are they supposed to better UX. To me it seem like it's a solution in of search of a problem to solve.
Mitja
----- Original Message -----
From: "Mark Shuttleworth" <mark@xxxxxxxxxx>
To: "Mitja Pagon" <mitja.pagon@xxxxxxxxxx>
Cc: hello@xxxxxxxxxxxxx, ayatana@xxxxxxxxxxxxxxxxxxx, "Carl Simpson" <cwd.simpson@xxxxxxxxx>
Sent: Monday, February 21, 2011 8:08:53 AM
Subject: Re: [Ayatana] Windicators
On 20/02/11 18:39, Mitja Pagon wrote:
Using the example of volume control mentioned below, am I
the only one who thinks windicators make little sense and are in
fact bad UX.
No, of course you are not the only person, there's lots of dissent,
which is fine and stimulates discussion to get a better result.
Follow my example.
What is the added benefit of having the per-application volume
control as "windicator". Music players already have per
application volume controls in their UIs and space gained by
moving them into the window title is minimal. Are there any
other benefits am missing?
It would not make sense to have volume controls both inside the UI,
and in the title bar as an indicator. But the suggestion of course
was to let apps *move* that functionality to the indicator, not
duplicate the functionality.
Indicators are abstract, logical entities that are exported from the
app. They can thus be useful in more general cases. For example, in
the window spread views, indicators could be rendered at full size,
so their semantic meaning can be scanned in the spread view. They
could even be interactive in those views, allowing one to set the
appropriate volume for multiple windows, quickly, in the volume
example.
On the other hand you are adding visual clutter to the
title bar, introducing confusing behavior, as the same indicator
is sometimes applications specific, other times it system wide,
not to mention you are giving yourself additional technical
problems to solve and thus requiring more resources. All of this
are negative implications of this idea.
Giving technical problems to solve is called "challenging the
engineers" and we rather like to do that, and they rather like it
too, round here ;-) As long as the work feels like it is
foundational and will stick around for a long time and be used,
solving hard problems is worthwhile.
If you apply simple math to this you can conclude
that he negatives of this idea outweigh the positives.
There are some other use cases mentioned, but most of the same
logic applies and as for using windicators for notifying users
there is already notify-osd.
Notify-OSD is purely for momentary events, not status. Indicators
combine status and manipulation of the status, they are entirely
different from notifications.
Mark