[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-30 9:10:56
Message-ID: 4C7B75A0.8090809 () kde ! org
[Download RAW message or body]

On 29/08/2010 12:13, Diego Moya wrote:
> 2010/8/20 Aurélien Gâteau wrote:
>>> 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.
>>
> 
> I disagree this is outside the scope. You're proposing a design that
> directly shows the state of the application. If the button isn't enough to
> explain the whole state, the HIG should explain how the button design should
> interact with the rest of the application's state cues. At least it should
> warn that there IS a need to provide a clear cue about the state.

The fact that an application needs to provide a clear cue about its
state is not specific to toggle buttons. Maybe you could start a page
describing what to do and what not to do about providing state
information and submit it for discussion here?

> 
> 
> On 20 August 2010 18:08, Celeste Lyn Paul wrote:
> 
>> 2010/8/20 Aurélien Gâteau wrote:
>>> 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.
>>
>> I agree with Aurelian here. If media needs to cache or load after the
>> Play button is pressed, then there needs to be some type of additional
>> feedback such as a progress spinner. Loading media doesn't change the
>> fact the player is in a Play mode and should be playing media and
>> should be able to be Paused. Also, once the media buttons are made
>> more consistent, questions such as "I wonder what state this is in"
>> should be alleviated by users learning the controls. Learning is
>> supported by consistency. I think a lot of user confusion with
>> controls -- especially with media players -- is from experience with
>> inconsistent interfaces not unintuitive interfaces.
>>
> 
> That's all well and good. I just wanted the HIG to recommend including that
> progress spinner for media players that don't start playing at once, given
> that it's recommending a play/pause action button that would be incomplete
> without the spinner.

It is not explicitly recommending a play/pause button. It says "in this
example of a play/pause button, here is how the *button* should be
implemented and here is how it should not be implemented". It says
nothing about whether this is the recommended way to implement
play/pause in media players and it says nothing about whether this
provides enough information about the player state to the user.

Whether an application provides enough information about its state
depends on the application domain itself, that's why I suggest you start
a separate page if you want to document and provide guidelines in this area.

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]