'Re: [KDE Usability] Misuse of toggle buttons, continued'

[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-29 10:13:52
Message-ID: AANLkTikHcbQZCVzYiA4CtYJaUOcqRDhLxzqH5zBhxBjP () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]

2010/8/20 Aur=C3=A9lien G=C3=A2teau wrote:

> > On 20/08/2010 11:43, Diego Moya wrote:
> >> I regularly found myself pressing the play/pause icon in online videos=
,
> >> waiting for the movie to begin playing. The problem is more acute in
> >> embedded players, but it can also happen in desktop players if the son=
g
> file
> >> begins with several seconds of silence.
> >
> > 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 shoul=
d
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.

On 20 August 2010 18:08, Celeste Lyn Paul wrote:

> 2010/8/20 Aur=C3=A9lien G=C3=A2teau 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.

[Attachment #5 (text/html)]

<div class="gmail_quote">2010/8/20 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;"><div class="im">&gt; On 20/08/2010 \
11:43, Diego Moya wrote: &gt;&gt; I regularly found myself pressing the \
play/pause icon in online videos, &gt;&gt; waiting for the movie to begin \
playing. The problem is more acute in &gt;&gt; embedded players, but it can also \
happen in desktop players if the song file &gt;&gt; begins with several seconds \
of silence. &gt; 
&gt; I understand your concerns but I think this is a bit outside of the 
&gt; scope of this discussion. It is up to the media player to provide a 
&gt; clear cue about its current state. </div></blockquote> <div>I disagree this \
is outside the scope. You&#39;re proposing a design that directly shows the state of \
the application. If the button isn&#39;t enough to explain the whole state, the HIG \
should explain how the button design should interact with the rest of the \
application&#39;s state cues. At least it should warn that there IS a need to provide \
a clear cue about the state.

<br>  <br>On 20 August 2010 18:08, Celeste Lyn Paul <span \
dir="ltr"></span>wrote:<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">

2010/8/20 Aurélien Gâteau wrote:<br>

&gt; One of my goals with this HIG 
&gt; addition is to have a referenced way to implement combined buttons, so 
&gt; that developers who decided they want one can implement it correctly. 
 
</div>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&#39;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 &quot;I wonder what state this is in&quot; 
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. </blockquote></div> That&#39;s all well and good. I just wanted the \
HIG to recommend including that progress spinner for media players that don&#39;t \
start playing at once, given that it&#39;s recommending a play/pause action button \
that would be incomplete without the spinner.

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