[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-18 20:54:49
Message-ID: 4C6C4899.2050407 () kde ! org
[Download RAW message or body]

On 18/08/2010 08:59, Pedro Lopez-Cabanillas wrote:
> On Wednesday, August 18, 2010, Aurélien Gâteau wrote:
>> I am finally back to this obsession of mine, toggle buttons. I wrote a
>> wiki page for it and would like to get it in the HIG if we all agree.
>> You can find it here:
>>
>> http://techbase.kde.org/User:Agateau/Toggle_Button
> 
> I'm not sure to fully understand your sentence "example: A music player should 
> not use a toggle button to implement a Play/Pause button. It should use a 
> normal button". In kmid [1] (MIDI/karaoke player) there is a normal "play" 
> button and a "pause" toggle action. They are two different actions, 
> and "pause" represents the paused state of the player. Wouldn't this usage be 
> consistent with your proposal, except for the verb label?.

I was referring to players which combine the Play and Pause button into
one. When nothing is playing, the button label is "Play". When you click
it and it starts playing the button label changes to "Pause".

The usage you describe looks a bit odd. If there was a need for separate
Play and Pause buttons, I would personally use two normal buttons,
rather than a normal and a toggle one. Having said that, I don't know
kmid, so maybe it makes sense for this application to use a toggle
button for Pause. I don't see this as misuse of toggle buttons though.

> By the way, kmid uses a lot of toggles. For instance, the "channels" window 
> alone has 48 instances of QToolButton with setCheckable(true). They change 
> the icons when their states are changed, which is against your proposal. They 
> are like check boxes and radio buttons, with a different icon for each state. 

That's really interesting. I stared at the screenshot and kept asking me
"the button icons change, why does it feel OK in this example?". Then I
realized it feels OK because the icon is changed to represent the
*current* state: When the lock button is down, a lock icon is shown.

What I consider wrong is when a toggle button is used, but its icon and
label represent the state *after* you click the button rather than the
*current* state.

Two examples of this can be found in Dragon Player:
1. When you start the Play button is up and says "Play". When you click
it it stays down and its label is changed to "Pause". This button should
either a) keep its current label or b) be turned into a normal button. I
would personally prefer solution b).

2. The Fullscreen button exhibits the same problem: when you start it is
up and says "Fullscreen". When you click it, it stays down and says
"Exit Fullscreen". Again, I would suggest turning this button into a
regular button rather than a toggle button (this is going to be a bit
tricky because this button comes from kdelibs so there are BC issues).

> The labels (column headers in this case) are also verbs (mute, solo, lock) 
> instead of nouns. Would you propose "muted state", "soloed state", "locked 
> state" instead?

I don't think there is a problem here. I think these verbs can be
interpreted as expressing a state rather than an action. The paragraph
about verbs vs nouns need to be reworked to better reflect this idea of
state vs action.

>> Technical note: I noticed while going through the code of KDE
>> applications that unfortunately the KToggleAction class provided by
>> kdelibs makes it quite easy to misuse toggle buttons. I thus started to
>> write an alternative class which I will propose for inclusion in kdelibs
>> to deprecate KToggleAction, assuming we agree on this addition to the HIG.
> 
> It is hard to comment without knowing your proposal in detail. Do you propose 
> a class name change? new/removed methods?

I didn't detail the proposal here because I don't think it's appropriate
for the usability list. When/If this addition to the HIG is validated, I
will propose my new class on kde-core-devel as a way to make it easier
to follow this addition to the HIG. Here is a short description
nevertheless:

The class is named KDualAction (better name wanted). It makes it easy to
create an action whose icon/label change when clicked, but is not
checkable, so it is not represented as a toggle button when added to a
toolbar. I created it because I realized quite a few misuses of toggle
buttons (like the Play/Pause button in Dragon Player) comes from the
fact that they are implemented using KToggleAction (which provide a
handy setCheckedState() to define the checked icon and label).
KToggleAction should be used for situations like lock buttons in KMid,
not for Play/Pause or Fullscreen buttons.

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]