[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 12:47:25
Message-ID: AANLkTi=HH8RQQwTCZjHQFGk19Z-yWM=XJfUNpJCfB957 () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On 30 August 2010 13:47, Celeste Lyn Paul <celeste@kde.org> wrote:
> 2010/8/30 Diego Moya <turingt@gmail.com>:
> > 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 (f=
or
> > example "don't use modal dialogs to represent non-blocking errors"), bu=
t
> 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 includi=
ng
> >> > 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 thi=
s
> >> 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 explic=
it
> > "should" as the HIG mandating a particular design for media players, no=
t
> > 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 redacti=
on
> 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
>
[Attachment #5 (text/html)]
<br><br><div class="gmail_quote">On 30 August 2010 13:47, Celeste Lyn Paul <span \
dir="ltr"><<a href="mailto:celeste@kde.org">celeste@kde.org</a>></span> \
wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex;">
2010/8/30 Diego Moya <<a \
href="mailto:turingt@gmail.com">turingt@gmail.com</a>>:<br> <div class="im">> \
2010/8/30 Aurélien Gâteau wrote:<br> >><br>
>> 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>
><br>
> Good idea. What level of abstraction should have pages in the HIG? I'm<br>
> afraid I would tend to create a page with advice that is too general (for<br>
> example "don't use modal dialogs to represent non-blocking \
errors"), but on<br> > the other side giving rules to represent state for \
each kind of widget or<br> > control might be too specific.<br>
<br>
</div>It ought to be high-level enough that a single pattern or guideline<br>
can apply to more than one example or context, but low-enough level<br>
that it can actually be applied and isn't some fluffy thing that isnt<br>
practical.<br>
<div class="im"><br>
><br>
><br>
>><br>
>> > That's all well and good. I just wanted the HIG to recommend \
including<br> >> > that<br>
>> > progress spinner for media players that don't start playing at \
once,<br> >> > given<br>
>> > that it's recommending a play/pause action button that would be<br>
>> > incomplete<br>
>> > without the spinner.<br>
>><br>
>> 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>
><br>
> My fault then, as I wouldn't read it that way. I interpreted the \
explicit<br> > "should" as the HIG mandating a particular design for \
media players, not<br> > seeing it as limited to an illustrative example. I'm \
afraid others will make<br> > the same error.<br>
<br>
</div>Perhaps we need a specific "media" guidelines page that has to do \
with<br> media controls only. My impression is that Aurelian's page has to do<br>
with *all* toggle buttons (and not all media controls) and happened to<br>
use playback as an example.<br>
<br>
Also, it seems like there could also be a "feedback" page that<br>
describes all the times that applications ought to provide feedback<br>
and the manners in which they can do that.<br>
<div class="im"><br>
> I think that your intention would be clearer if you changed the redaction to<br>
> "It could instead use a normal button and adjust the icon and label to<br>
> represent the action", to suggest that this is but one possibility.<br>
<br>
</div>I think that works as a clarification on the language.<br>
<div class="im"><br>
<br>
--<br>
Celeste Lyn Paul<br>
KDE Usability Project<br>
KDE e.V. Board of Directors<br>
<a href="http://www.kde.org" target="_blank">www.kde.org</a><br>
_______________________________________________<br>
</div><div><div></div><div class="h5">kde-usability mailing list<br>
<a href="mailto:kde-usability@kde.org">kde-usability@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/kde-usability" \
target="_blank">https://mail.kde.org/mailman/listinfo/kde-usability</a><br> \
</div></div></blockquote></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