The old Play/Pause toggle

11 Aug 2006 - 2:26pm
8 years ago
16 replies
761 reads
liyazheng
2005

Hi IDs,

I have a design question for you guys. So music players like iTunes have a
play/pause toggle whereby the button displays the available action rather
than its state: when it's playing, you see that you can pause it and vice
versa.

Can anyone point me to sources in which people have done usability studies
of such a behavior in various interfaces, and how effective or not effective
it is?

We are pursuing a similar design and find ourselves putting a label on the
bottom of the big Play button to show that it's "not playing". The product
is not a music player and it's used in a different context, and the context
requires us to be more clear about what is going on with the system because
more is at stake.

I found in About Face 2.0 a reference on page 342 that flip-flop buttons is
a bad idea, our solution seems align with the recommendations in the book
but I wonder if there are other literature or practices out there today that
is breakthrough.

Thank you for your help in advance!

Liya

Comments

11 Aug 2006 - 4:34pm
Michael Holzer
2006

Another paradigm where a "flip" style button is used is the mobile/voice industry. A green phone icon is often switched for a red phone icon. I think this works when there are VERY obvious other cues as to what is happening. For example after clicking the play button the user hears music and see's the song's time count. Likewise when the user clicks the green phone they hear ringing and see the call time counting. IMHO, these other cues are necessary to support the "stateless" button.

Mike

----- Original Message ----
From: liya zheng <liya.zheng at gmail.com>
To: discuss at lists.interactiondesigners.com
Sent: Friday, August 11, 2006 12:26:23 PM
Subject: [IxDA Discuss] The old Play/Pause toggle

[Please voluntarily trim replies to include only relevant quoted material.]

Hi IDs,

I have a design question for you guys. So music players like iTunes have a
play/pause toggle whereby the button displays the available action rather
than its state: when it's playing, you see that you can pause it and vice
versa.

Can anyone point me to sources in which people have done usability studies
of such a behavior in various interfaces, and how effective or not effective
it is?

We are pursuing a similar design and find ourselves putting a label on the
bottom of the big Play button to show that it's "not playing". The product
is not a music player and it's used in a different context, and the context
requires us to be more clear about what is going on with the system because
more is at stake.

I found in About Face 2.0 a reference on page 342 that flip-flop buttons is
a bad idea, our solution seems align with the recommendations in the book
but I wonder if there are other literature or practices out there today that
is breakthrough.

Thank you for your help in advance!

Liya
________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss at ixda.org
List Guidelines ............ http://listguide.ixda.org/
List Help .................. http://listhelp.ixda.org/
(Un)Subscription Options ... http://subscription-options.ixda.org/
Announcements List ......... http://subscribe-announce.ixda.org/
Questions .................. lists at ixda.org
Home ....................... http://ixda.org/
Resource Library ........... http://resources.ixda.org

11 Aug 2006 - 6:00pm
Dave Malouf
2005

> Can anyone point me to sources in which people have done
> usability studies
> of such a behavior in various interfaces, and how effective
> or not effective
> it is?

Ok, I find this question really interesting for 2 reasons.

1) Who publishes their usability studies who work in practice?
A) who has time to publish them
B) this is almost exclusively proprietary information when done in practice
C) if they were not done in real world practice is there enough context for
it to be truly useful?

2) Shouldn't you just test it. Paper prototype it, put it infront of 3-10
people internal or external and see what happens.

As you can see I'm not a big fan of doing user research through other
people's studies. Why? YOUR context is YOUR context and since I know Liya's
product pretty well, I'd have to say that the context you are working in is
VERY specific and not really transferable easily.

Now that being said, I loathe the iTunes single button dual purposes. Wrote
about it awhile ago on my blog. The reason it doesn't work is that it
assumes that the music is always in context to the user's decision making
environment, when it is not. You end up having to translate the label which
indicates what will happen when you push it to its opposite which is what
the current state is. While this binary seems simplistic, after several
years of using iTunes I still see people flub this.

On the device side when a single button does two actions is also
problematic. How many times have you put your iPod in your bag (ear buds
off) and all you want to do is make sure it is turned off. Well w/o looking
at the device or having your ear buds in hitting that one button
(pause/play) doesn't do the trick, for all you know you just turned it on.

Now this design is great b/c it means 1 less button on the screen/device,
but is it enough?

Why would it be so bad to have 2 buttons? Sometimes less is, well, less.

-- dave

11 Aug 2006 - 6:42pm
Robert Hoekman, Jr.
2005

> 1) Who publishes their usability studies who work in practice?
> 2) Shouldn't you just test it. Paper prototype it, put it infront of 3-10
> people internal or external and see what happens.

Isn't the big question really "Why on Earth do we need a usability study on
the Play/Pause paradigm?" (See below.)

As you can see I'm not a big fan of doing user research through other
> people's studies. Why? YOUR context is YOUR context and since I know
> Liya's
> product pretty well, I'd have to say that the context you are working in
> is
> VERY specific and not really transferable easily.

Seriously? We're talking about a toggle switch. Toggles have been used on
everything from watches to cars to light switches to radios for a long, long
time (this thread's subject line, in fact, is "the OLD play/pause toggle").
Translating this in software was not innovative in any way. It was painfully
obvious because it's a pattern that everyone knows. It's even
cross-cultural. It's such an incredibly obvious solution that it's used in
TONS of software.

Seriously - can someone please explain why this question about the usability
of the Play/Pause toggle is even a question?

Beyond that, your last point here, David, is highly debatable. Of *course*
we can dop user research through other people's studies.

-r-

11 Aug 2006 - 7:44pm
Jim Kauffman
2004

> -----Original Message-----
> From: discuss-bounces at lists.interactiondesigners.com
> [mailto:discuss-bounces at lists.interactiondesigners.com] On
> Behalf Of Robert Hoekman, Jr.
> Sent: Friday, August 11, 2006 7:42 PM
> To: David (Heller) Malouf
> Cc: discuss at lists.interactiondesigners.com
> Subject: Re: [IxDA Discuss] The old Play/Pause toggle
>
> Seriously? We're talking about a toggle switch. Toggles have
> been used on everything from watches to cars to light
> switches to radios for a long, long time (this thread's
> subject line, in fact, is "the OLD play/pause toggle").
> Translating this in software was not innovative in any way.
> It was painfully obvious because it's a pattern that everyone
> knows. It's even cross-cultural. It's such an incredibly
> obvious solution that it's used in TONS of software.
>
> Seriously - can someone please explain why this question
> about the usability of the Play/Pause toggle is even a question?

I can only speak for myself, but after all these years I still have trouble
with one particular internationally accepted standard: Is it the circle or the
line on the power switch toggle that means "On"?

My wife has a similar problem with video cameras. The accepted standard for
indicating recording is a red status light (does anyone know why? I don't),
but in her mind red means "stopped/off" and green means "running/on" because
in other aspects of life, red means stop and green means go. As I look at my
computer and monitor right now, I see green lights indicating that the
components are powered on, but the light on my power strip is red.

Just because something is traditional or has become a standard doesn't mean
it's obvious to everyone.

Jim Kauffman

11 Aug 2006 - 8:48pm
Todd Warfel
2003

Neither really. The circle and line come from engineering - input (I)
output (O). I can't recall the actual source from where I read that,
too many books on my shelf. But it was probably either from Cooper or
Norman that I recall surfacing that. Good thing, because for the life
of me, I couldn't ever make sense of that symbol and what it had to
do w/power.

Still doesn't make sense, but at least I know where it came from.

On Aug 11, 2006, at 8:44 PM, Jim Kauffman wrote:

> I can only speak for myself, but after all these years I still have
> trouble
> with one particular internationally accepted standard: Is it the
> circle or the
> line on the power switch toggle that means "On"?

Cheers!

Todd R. Warfel
Partner, Design & Usability Specialist
Messagefirst | designing and usability consulting
--------------------------------------
Contact Info
Voice: (607) 339-9640
Email: todd at messagefirst.com
AIM: twarfel at mac.com
Blog: http://toddwarfel.com
--------------------------------------
In theory, theory and practice are the same.
In practice, they are not.

12 Aug 2006 - 7:52am
Tori Egherman
2005

> > I can only speak for myself, but after all these years I still have
> > trouble
> > with one particular internationally accepted standard: Is it the
> > circle or the
> > line on the power switch toggle that means "On"?
>
I also have this problem and still do not understand the answer is
input "on" then? As in we are inputting electricity? Or is output "on"
as in we are responding to your request?

As for play/pause toggle buttons: they still confuse me. I am
constantly misunderstanding the meaning of the play/pause toggle. On
the other hand, the space bar I get. It makes sense: it doesn't show
me any icons, I tap it once for pause and again for play. Why does the
button continue to confuse me? Hopefully your study will enlighten
me...

And can I just say, thank god this email is not about Israel and Lebanon.

Tori

12 Aug 2006 - 11:35am
Jared M. Spool
2003

My thoughts on this:

At 08:44 PM 8/11/2006, Jim Kauffman wrote:
>I can only speak for myself, but after all these years I still have trouble
>with one particular internationally accepted standard: Is it the circle or the
>line on the power switch toggle that means "On"?

It's the line. The symbol was adopted in the '70s by the ISO standards
committee to solve the problem that devices used in cultures all over the
world had their original terminology, often not understood by the local
culture. The committee adopted a symbol they'd already used for years in
electrical schematic diagrams to represent when a switch is open (circle)
or closed (line). (In electronics, a "closed" switch passes current
through, while an "open" switch prevents power from passing through.)

I remember when I was working at Digital Equipment Corporation, we adopted
the symbology for our products. One day, walking by one of the secretary's
word processing stations, I noticed a typed notice had been taped to the unit:

To turn the power on, press the I/O button to I. Shut it off by changing
the button to O.

The font was serifed, making the I look less like the line in the symbol
and more like the capital letter i. So, Jim's confusion goes back at least
30 years.

To Liya's question:
>Can anyone point me to sources in which people have done usability studies
>of such a behavior in various interfaces, and how effective or not effective
>it is?

Dave (Heller) Malouf wrote:

>Ok, I find this question really interesting for 2 reasons.
>
>1) Who publishes their usability studies who work in practice?
>A) who has time to publish them
>B) this is almost exclusively proprietary information when done in practice
>C) if they were not done in real world practice is there enough context for
>it to be truly useful?
>
>2) Shouldn't you just test it. Paper prototype it, put it infront of 3-10
>people internal or external and see what happens.
>
>As you can see I'm not a big fan of doing user research through other
>people's studies. Why? YOUR context is YOUR context and since I know Liya's
>product pretty well, I'd have to say that the context you are working in is
>VERY specific and not really transferable easily.

and Robert Hoekman, Jr. replied:

>Seriously - can someone please explain why this question about the usability
>of the Play/Pause toggle is even a question?
>
>Beyond that, your last point here, David, is highly debatable. Of *course*
>we can dop user research through other people's studies.

To me, this is why design patterns [1] are so interesting right now. A
design pattern library, when done well [2], not only stores the design
solution, but the contexts where the solution has worked and the results of
findings, such as usability studies, so designers can deduce if it will
continue to work in other contexts.

Robert is correct in that we shouldn't have to test every design element
out each time, as if nobody has ever looked at them before. Yet, David is
correct that if the context is different, more testing is likely to be needed.

This is a major reason why we're advocating that our clients create their
own private pattern libraries, complete with historical and contextual
descriptions, instead of trying to rely on off-the-shelf libraries, such as
the Yahoo! Public Design Pattern library [3] or Jenifer Tidwell's pattern
library. Both of those are well done and can serve as a nice starting
point, but quickly need to be co-opted by the design team to describe that
team's own experience and needs.

[1] http://www.uie.com/articles/design_patterns/
[2] http://www.uie.com/articles/elements_of_a_design_pattern/
[3] http://developer.yahoo.com/ypatterns/index.php
[4] http://designinginterfaces.com/

Jared

Jared M. Spool, Founding Principal, User Interface Engineering
510 Turnpike Street, Suite 102, North Andover, MA 01845
978 327-5561 jspool at uie.com http://www.uie.com
Blog: http://www.uie.com/brainsparks

14 Aug 2006 - 3:05am
Andrei Sedelnikov
2004

Hi all,

"The Toggle Question" was bothering me once in the context of iPod and
I think a have found a serous explanation for that case. I have
applied the principles in the Raskin's Book, "The Humane Interface".
According to Raskin, a toggle button is modal and thus bad, because
the same gesture - pressing a button - produces different results
depending on state of the button.

Assuming that iPod designers are wise people and observing that in
most cases, I have no problems with this button on iPod, there is a
question: why it does generally work and why sometimes I trigger a
wrong action?

The answer in in the precise description of the modality:

""An human-machine interface is modal with respect to a given gesture
when (1) the current state of the interface is not the user's locus of
attention and (2) the interface will execute one among several
different responses to the gesture, depending on the syste,'s current
state." Page.42

and additional definition

„… state of the system … is the user's locus of attention and is
visible to user or is in the user's short-term memory …" Page. 50

So in order the interface to be modal one, both conditions (1) & (2)
should be true. But in case of iPod, the (1) is not true, because the
state of the system is either visible (iPod display) or hearable or in
the short-memory (a user has just taken a device and knows it's not
playing anything yet).

Now I can also understand, when I have troubles with the toggle
button: when a song is playing but the user looks for another one, the
current system's state can go out of the user's locus of attention.

The moral: as David mentioned, the context is important. In the given
context you can apply basic cognitive principles and get a solution
for your case.

Andrej Sedelnikov
http://usabilist.de

On 8/11/06, liya zheng <liya.zheng at gmail.com> wrote:
> [Please voluntarily trim replies to include only relevant quoted material.]
>
> Hi IDs,
>
> I have a design question for you guys. So music players like iTunes have a
> play/pause toggle whereby the button displays the available action rather
> than its state: when it's playing, you see that you can pause it and vice
> versa.
>
> Can anyone point me to sources in which people have done usability studies
> of such a behavior in various interfaces, and how effective or not effective
> it is?
>
> We are pursuing a similar design and find ourselves putting a label on the
> bottom of the big Play button to show that it's "not playing". The product
> is not a music player and it's used in a different context, and the context
> requires us to be more clear about what is going on with the system because
> more is at stake.
>
> I found in About Face 2.0 a reference on page 342 that flip-flop buttons is
> a bad idea, our solution seems align with the recommendations in the book
> but I wonder if there are other literature or practices out there today that
> is breakthrough.
>
> Thank you for your help in advance!
>
> Liya
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://listguide.ixda.org/
> List Help .................. http://listhelp.ixda.org/
> (Un)Subscription Options ... http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists at ixda.org
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org
>

--
Andrei Sedelnikov
http://usabilist.de/

19 Aug 2006 - 2:09am
Adam Korman
2004

There is no good answer. Some people are confused by and/or hate the
toggle and some people are confused by and/or hate separate buttons.
For software media players, the truth is that neither solution
(toggle or separate buttons) is good for all situations these
applications try to handle.

This is not just a casual observation, but my experience in watching
real users interact with media player applications as they struggle
with both approaches. My guess is that a significant factor in
peoples' success/preference is what they have habituated to in other
contexts (controls on cassette players & VCRs, CD & DVD players, MP3
players, remote controls, etc.). Unfortunately, there is no standard
for how physical products handle these controls, so borrowing from an
established real-world pattern isn't possible, even if you wanted to
do that.

Regards, Adam

On Aug 11, 2006, at 12:26 PM, liya zheng wrote:
> So music players like iTunes have a
> play/pause toggle whereby the button displays the available action
> rather
> than its state: when it's playing, you see that you can pause it
> and vice
> versa.
>
> I found in About Face 2.0 a reference on page 342 that flip-flop
> buttons is
> a bad idea, our solution seems align with the recommendations in
> the book
> but I wonder if there are other literature or practices out there
> today that
> is breakthrough.

22 Aug 2006 - 3:27am
stauciuc
2006

Great thread to read!

Jim Said:
My wife has a similar problem with video cameras. The accepted standard for
indicating recording is a red status light (does anyone know why? I don't),
but in her mind red means "stopped/off" and green means "running/on" because
in other aspects of life, red means stop and green means go.

Great observation! A lot of cameras (if not all) use a red light for
recording (maybe it's because the Rec button is red, as opposed to the green
Play button).

I had a different issue with my battery charger: it has a red light to
indicate it is charging. And I kept waiting for it to turn green so I could
plug it out. But it never did. Seems like it doesn't indicate when the
batteries are charged...

As to the 'Play/Pause' button on Mp3-players, I have a simple player that
uses cds. The screen indicates state, and so does the music playing or not.
The button indicates action. It never confused me personally. I'll have to
buy a ITunes and see the problem there for myself .

--
Sergiu Sebastian Tauciuc
http://www.sergiutauciuc.ro/en/

22 Aug 2006 - 4:56pm
cfmdesigns
2004

>From: Sebi Tauciuc <stauciuc at gmail.com>
>
>Jim Said:
>My wife has a similar problem with video cameras. The accepted standard for
>indicating recording is a red status light (does anyone know why? I don't),
>but in her mind red means "stopped/off" and green means "running/on" because
>in other aspects of life, red means stop and green means go.
>
>Great observation! A lot of cameras (if not all) use a red light for
>recording (maybe it's because the Rec button is red, as opposed to the green
>Play button).

I've always assumed a connection to the "On Air" signs outside a radio studio, which are red. Or the red light traditionally outside a darkroom when it's in use. Or the red light visible on the TV camera when it is on. The clear meaning in all these contexts is "Pay attention to what's going on!"

In that context, a red stoplight is the same thing.

-- Jim (but a different Jim)

22 Aug 2006 - 6:07pm
Jim Kauffman
2004

> -----Original Message-----
> From: discuss-bounces at lists.interactiondesigners.com
> [mailto:discuss-bounces at lists.interactiondesigners.com] On
> Behalf Of Jim Drew
> Sent: Tuesday, August 22, 2006 5:57 PM
> To: discuss at ixda.org
> Subject: Re: [IxDA Discuss] The old Play/Pause toggle
>
> I've always assumed a connection to the "On Air" signs
> outside a radio studio, which are red. Or the red light
> traditionally outside a darkroom when it's in use. Or the
> red light visible on the TV camera when it is on. The clear
> meaning in all these contexts is "Pay attention to what's going on!"

I agree about the origin of the use of the red light, but in those early days
red still meant "Stop"--as in "Stop, don't open the studio door because we're
recording". The problem is that the convention didn't change as its use
changed.

Jim K.

23 Aug 2006 - 12:46pm
mtumi
2004

>
> Seriously - can someone please explain why this question about the
> usability
> of the Play/Pause toggle is even a question?

I think the basic problem is that it is unclear whether it displays
the current state (I am playing) or the action that the button will
trigger (click to play).

IMO, Mark Holtzer hits a (or maybe the) key consideration - whether
there are other cues or not. If I can see a progress bar moving, or a
counter counting, and hear audio at nearly all times that it is in
play mode (or all 3), the toggle is a more viable solution.

Just my two cents. If you don't like this answer, please pick from
the following:

A. do your own testing
B. it depends

MT

6 Sep 2006 - 12:37am
sudhindra
2004

Interesting thread !!

>>I think the basic problem is that it is unclear whether it displays
the current state (I am playing) or the action >>that the button will
trigger (click to play).

In the iPod, the play or pause indicates the "current state" whereas in
the iTunes, it indicates the action the button will trigger. It is
quite confusing in the context of the iPod/iTunes because they are
inter-related hardware/software. A person using iPod invariably uses
iTunes and this contradiction is bound to cause confusion. I am not even
sure if the other mp3 players such as Creative follow the same
convention.

Personally, I could understand the iPod's pause and play as current
status indicator and could remember it much better than I anticipated
but when using iTunes, the button still makes me think whether it
indicates "action" or "current status", though it's a standard across
all music players.

<my 2 cents>

Best Regards
Sudhindra

-----Original Message-----
From: discuss-bounces at lists.interactiondesigners.com
[mailto:discuss-bounces at lists.interactiondesigners.com]
Sent: 23 August 2006 21:47
To: ixda
Subject: Re: [IxDA Discuss] The old Play/Pause toggle

[Please voluntarily trim replies to include only relevant quoted
material.]

>
> Seriously - can someone please explain why this question about the
> usability of the Play/Pause toggle is even a question?

I think the basic problem is that it is unclear whether it displays the
current state (I am playing) or the action that the button will trigger
(click to play).

IMO, Mark Holtzer hits a (or maybe the) key consideration - whether
there are other cues or not. If I can see a progress bar moving, or a
counter counting, and hear audio at nearly all times that it is in play
mode (or all 3), the toggle is a more viable solution.

Just my two cents. If you don't like this answer, please pick from
the following:

A. do your own testing
B. it depends

MT

________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss at ixda.org List Guidelines
............ http://listguide.ixda.org/ List Help ..................
http://listhelp.ixda.org/ (Un)Subscription Options ...
http://subscription-options.ixda.org/
Announcements List ......... http://subscribe-announce.ixda.org/
Questions .................. lists at ixda.org Home .......................
http://ixda.org/ Resource Library ........... http://resources.ixda.org

12 Sep 2006 - 1:26am
cfmdesigns
2004

From: "Sudhindra Venkatesha Murthy" <TC00081 at emirates.com>

>>I think the basic problem is that it is unclear whether it displays
the current state (I am playing) or the action >>that the button will
trigger (click to play).

In the iPod, the play or pause indicates the "current state" whereas in
the iTunes, it indicates the action the button will trigger. It is
quite confusing in the context of the iPod/iTunes because they are
inter-related hardware/software. A person using iPod invariably uses
iTunes and this contradiction is bound to cause confusion.

I would say it's confusing because we don't pay attention.

In iTunes, there is a single button with an icon that changes such
that the icon means "push here to do this". That is exactly the
other buttons do there as well, indicate what a click will do. The
state is not indicated by the button, but by the icon next to the
playing song (with sound waves or without), plus motion in the "now
playing" box.

On the iPod, there is a single button with two icons on it such that
the icon means "push here to do whichever of these things in
appropriate". That is exactly the other buttons do there as well,
indicate what a click will do. The state is not indicated by the
button, but by the icon in the screen (arrowhead or double line),
plus motion in the screen.

They are being pretty consistent between the two, but we tend to not
want to "listen".

Jim Drew
cfmdesigns at earthlink.net

12 Sep 2006 - 1:27am
cfmdesigns
2004

I have a design question for you guys. So music players like iTunes
have a
play/pause toggle whereby the button displays the available action
rather
than its state: when it's playing, you see that you can pause it and
vice
versa.

There is an inherent problem with a two-button system. Either the
two buttons are really one actions accessed in two places -- press
either one to do the appropriate action -- or they end up being
distinct actions with three or four states rather than two.

I regularly use two stereo systems which have separate play and pause
buttons, which are of the separate actions model. The states are
Playing (play on, pause off), Cued (play on, pause on), and two Stop
states (play off [which is done with the Stop button, not the Play
one], either setting for pause); actually, one uses Go and Set rather
than Play and Pause, as I recall. This causes no end of confusion,
because there is no clear indicator on either system that Pause is
on. So you press Play and hover over the things, thinking "Is it
starting? Or is Pause on? What did I press to stop it last time?"
More than 50% of the time, multiple semi-random button presses are
needed to get it to play.

A single button is much better than that.

Jim Drew
cfmdesigns at earthlink.net

Syndicate content Get the feed