[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Ayatana] Windicators



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