[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:       Celeste Lyn Paul <celeste () kde ! org>
Date:       2010-08-30 11:47:53
Message-ID: AANLkTikum6_9av-WoMAWT7zNbzykkymtkC-zYgUebzSp () mail ! gmail ! com
[Download RAW message or body]

2010/8/30 Diego Moya <turingt@gmail.com>:
> 2010/8/30 Aurélien Gâteau wrote:
>>
>> 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?
>
> Good idea. What level of abstraction should have pages in the HIG? I'm
> afraid I would tend to create a page with advice that is too general (for
> example "don't use modal dialogs to represent non-blocking errors"), but on
> the other side giving rules to represent state for each kind of widget or
> control might be too specific.

It ought to be high-level enough that a single pattern or guideline
can apply to more than one example or context, but low-enough level
that it can actually be applied and isn't some fluffy thing that isnt
practical.

>
>
>>
>> > 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.
>>
>
> My fault then, as I wouldn't read it that way. I interpreted the explicit
> "should" as the HIG mandating a particular design for media players, not
> seeing it as limited to an illustrative example. I'm afraid others will make
> the same error.

Perhaps we need a specific "media" guidelines page that has to do with
media controls only. My impression is that Aurelian's page has to do
with *all* toggle buttons (and not all media controls) and happened to
use playback as an example.

Also, it seems like there could also be a "feedback" page that
describes all the times that applications ought to provide feedback
and the manners in which they can do that.

> I think that your intention would be clearer if you changed the redaction to
> "It could instead use a normal button and adjust the icon and label to
> represent the action", to suggest that this is but one possibility.

I think that works as a clarification on the language.


-- 
Celeste Lyn Paul
KDE Usability Project
KDE e.V. Board of Directors
www.kde.org
_______________________________________________
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]