[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: Diego Moya <turingt () gmail ! com>
Date: 2010-08-30 11:29:15
Message-ID: AANLkTim01+-qGVgq8-qRjvbotrZYoh9EUjFBSB9TWo3m () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
2010/8/30 Aur=C3=A9lien G=C3=A2teau 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.
> > 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 mak=
e
the same error.
I think that your intention would be clearer if you changed the redaction t=
o
"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.
[Attachment #5 (text/html)]
<div class="gmail_quote">2010/8/30 Aurélien Gâteau wrote:<br><blockquote \
class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, \
204, 204); padding-left: 1ex;">The fact that an application needs to provide a clear \
cue about its<br>
state is not specific to toggle buttons. Maybe you could start a page<br>
describing what to do and what not to do about providing state<br>
information and submit it for discussion here?<br></blockquote><div><br>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.<br>
<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; \
border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im">> \
That's all well and good. I just wanted the HIG to recommend including that<br>
> progress spinner for media players that don't start playing at once, \
given<br> > that it's recommending a play/pause action button that would be \
incomplete<br> > without the spinner.<br>
<br>
</div>It is not explicitly recommending a play/pause button. It says "in \
this<br> example of a play/pause button, here is how the *button* should be<br>
implemented and here is how it should not be implemented". It says<br>
nothing about whether this is the recommended way to implement<br>
play/pause in media players and it says nothing about whether this<br>
provides enough information about the player state to the user.<br>
<br></blockquote><div><br>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.<br>
<br>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.</div>
</div><br>
_______________________________________________
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]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic