Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

I'm developing a music streaming app. All's good, except I'm hung up on what to do when the music is playing and the network connection fails causing the stream to buffer.

Should I keep the button as a pause button or switch it to a play button (it's one button that changes state)?

My technical mind is telling me that it should switch to a play button as the music isn't really playing. On the other hand, a user seeing this will click the play button expecting the music to play but it won't because it's buffering and so it would flick back to a pause button(greatly annoying the user).

What are your thoughts on the matter?

share|improve this question

3 Answers 3

up vote 1 down vote accepted

Let's think about this possible scenario: you are running down the park jamming to the latest pop hit and all the sudden your 4G starts to fail. Instead of completely failing, it intermittently fails in rapid succession: connect, disconnect, connect, disconnect, connect, disconnect. While this madness is going on, your play/pause button is going schizophrenic swapping from pause to play to pause to play to pause in a very silly way. I say, just stay on the pause button to avoid this.

On the other hand, avoid confusion by looking at similar services. What does YouTube do? Most users are conditioned by YouTube in their media streaming habits. Think about big services that do similar things and replicated. Although imitation might seem a little cheap, there is nothing that I like more than an app that behaves just the way I think it should (aka: the way I have been conditioned by years of using other apps)

EDIT: Let me add more to my answer... If the connection is lost for an extended period of time (like 5 seconds), you could go back to the play button (this is SIMILAR to the behavior of Spotify on the phone).

share|improve this answer
    
I guess this makes sense, you're definitely right about users preferring behaviour they're used to - even if it means a little less originality –  roarster Jul 3 '13 at 16:30

The cause of pause should be understandable for user. So it's better to show message with small description and progress bar displaying buffer loading. Then autohide the message and continue playing. The play button while buffering still display playing mode (i.e. pause symbol).

It's important that the play/pause button not only command button, it also displays the mode, which is controlled by user.

At the same time you can implement a little smarter app behaviour. If the connection becomes very unstable, low-speed or breaks at all, you could auto-change the mode to pause and display error message.

Resume is: short connection problem -- don't change mode, long one -- change mode to pause/stop.

share|improve this answer

Toggling anything without the user's express interaction can lead to a frustrating experience. With that in mind, I tend to agree with Alexey regarding a "smart" app behavior.

Thinking about a use case, when I start to run in to buffering issues, it is my instinct to "pause" playback to let the video / audio cache a little bit. By the way, youTube does NOT let you toggle while it is buffering and this is frustrating to me.

Keeping the play button active will let the user know that the music will resume playing when the the song is available, but giving the user the ability to pause at anytime is a good idea.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.