[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 22:25:18
Message-ID: 4C6C5DCE.2080805 () kde ! org
[Download RAW message or body]

I just updated the page to reflect these changes.

On 18/08/2010 22:54, Aurélien Gâteau wrote:
> 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

_______________________________________________
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]