13

I develop a music player for a living and I just encountered an interesting scenario.

The scenario is this:

  • 500 songs queued up to play.
  • Song #1 is active and playing.
  • You double-click on song #500. It is now active and begins playing.
  • You then click the '<<' (previous) button on the player.

Do you expect song #499 to be active or song #1?

Arguments for #499:

  • Sequentially, #499 is previous song.

  • If you have your song paused, leave and come back later, and then click previous -- it might be surprising to see the player not go to #499.

  • Spotify goes to #499.

Arguments for #1:

  • Historically, #1 is previous song.

  • You were checking out #500, but instantly decide you want to hear #1 again instead. You have no way of going back to #1, you have to go click it.

Improve this question
3
  • 1
    What do other players do? (I'd expect history -- you don't expect me to have a 500-song playlist memorized, do you? -- but that's personal reaction.)
    – keshlam
    Oct 3, 2014 at 1:11
  • Most players go back to the previously played song in history when in Shuffle mode, so you could still go back the last played song to hear it again even if the songs are being shuffled. But when not in Shuffle mode, these players seem to have no memory of history -- they simply go back and forth in regular playlist order.
    – SNag
    Oct 3, 2014 at 6:32
  • As a Spotify user (and kick-ass ux-designer... But anyway) - This confuses me sometimes. My mental model of how it should work changes from time to time but I can't explain in which scenarios I think the back button should work historically or sequentially.
    – Tony Bolero
    Oct 3, 2014 at 7:09

5 Answers 5

Reset to default
6

I think this hinges on whether the order of the playlist has meaning. On a 10 track CD, the songs are meant to be played in a certain order. But a user constructing a playlist with hundreds of songs is not thinking "I want to play all of these songs in order".

If the latter is what you see as the common use case for your software, I agree with going back based on history.

Improve this answer
1

i would suggest going back to the previously encountered song (#1). it would be something to do research on, especially with your specific app in the case that it differs from others, but I would assume that a user is more interested in going 'back' to what was previously encountered as opposed to going 'back'wards in the sequencing of the playlist, especially if their awareness of the sequence of the playlist is low (whatever the measurement for low is).

so consider measuring what factor is more prominent in the user's mind in their definition of going back: the playlist's structural sequence or what was previously experientially encountered

Improve this answer
1

If you add buttons with arrows that points up and down, those would be the ones that traverses the list (if you are on song #500, one step up would be #499).

The right and left arrows would in that scenario be history buttons - meaning that the right arrow would (almost always) be superfluous.

This would map better to the interface, since the list is(?) vertical.

This needs some thinking and designing, but it can be something to consider.

Improve this answer
0

If a web-site user is viewing the second page from a set of numbered pages and clicks the link for page 6, the user would expect a "previous page" button or link to go to the top of page 5, and would expect the browser's back button to go to whatever area of page 2 was being viewed when the link was clicked. If the user had guessed that the desired information would be somewhere around page six but was slightly off, having to go back to page 2 and then click the page 5 link would be annoying. Conversely, if the user found what was being sought on page 6 and wanted to resume reading page 2, having to manually navigate to that page and the proper place on it would likewise be annoying.

Having separate buttons for visiting the previous page and the previously visited page is considered essential when browsing documents on the web, and I would see no reason not to apply the same principle to a music player. Indeed, on a music player it could be more important since aurally searching for the the most-recently-heard content is often much more difficult and time consuming than visually searching for recently-viewed content.

Improve this answer
0

You could have both a previously-played button and a previous-listed-track button. I'm not sure about how to represent these function as icons, but I imagine a backward (left-pointing) arrow as playing the latter, even when I'm playing a shuffled playlist.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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