[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-usability
Subject:    Re: [KDE Usability] Misuse of toggle buttons, continued
From:       Aurélien Gâteau <agateau () kde ! org>
Date:       2010-08-20 15:53:51
Message-ID: 4C6EA50F.20706 () kde ! org
[Download RAW message or body]

On 20/08/2010 11:43, Diego Moya wrote:
> I have a problem with the HIG actually *encouraging* a single play/pause
> button for media players, since this is a frequent source of irritation for
> me.
> 
> While I agree that a separate KDualAction is a good idea, the HIG should
> warn that these class of buttons have a BIG problem when the action does not
> provide instant feedback of the application state.
> 
> In the particular case of play buttons, this happens when the media doesn't
> start as soon as the button is pressed. In that case it's impossible to tell
> whether the Pause icon means that the media is paused or that it will be
> paused as an action.
> 
> I regularly found myself pressing the play/pause icon in online videos,
> waiting for the movie to begin playing. The problem is more acute in
> embedded players, but it can also happen in desktop players if the song file
> begins with several seconds of silence.

I understand your concerns but I think this is a bit outside of the
scope of this discussion. It is up to the media player to provide a
clear cue about its current state. One of my goals with this HIG
addition is to have a referenced way to implement combined buttons, so
that developers who decided they want one can implement it correctly.

Maybe another example could be used, do you have any suggestion?

> I particularly like kmid's design better that play and pause as normal
> buttons. It allows for the usual behavior to play/pause without moving the
> mouse, while avoiding the "what's the current state?" problem I stated
> above.

To me it looks quite unusual compared to any other media player. The
case of a media player is a bit difficult because people are very used
to a certain user interface.

> Also note that the policy is now encouraging opposite naming schemes for
> toggle buttons (text=state) and regular buttons that change their labels
> (text=action). I don't think the visual distinction of toggle buttons is
> enough to overcome this mismatch.

The distinction should not rely on the button border, this would not
work because the border of a normal button and the border of a toggle
button in up state are the same.

Distinction should come from the label (and when possible, from the
icon). The label of a toggle button should not convey an action meaning:
if the label of a button is "Locked", it represents the current state.
If it says "Lock", then clicking the button is going to lock something,
which is right now unlocked.

Maybe this can be made more explicit in the document?

> In my opinion the HIG should discourage having buttons that change labels at
> all, and promote either toggle buttons labeled with a state or pairs of
> regular buttons for opposite actions. For the rare case where a regular
> button needs to change its label, make it HIG policy that the application's
> state change must be instant.

Problem is that pair of buttons (especially with labels) take a lot of
horizontal space. If you look at Dragon, having Play and Pause buttons
would shrink the progress slider a lot, especially on netbooks.

Aurélien
_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability

[prev in list] [next in list] [prev in thread] [next in thread]