796319 - [music] When selecting a song already playing, don't restart the song, just go to viewing the song

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::Music, defect)

Description

[GH to BZ]

[GitHub issue by jds2501 on 2012-09-28T23:07:05Z, https://github.com/mozilla-b2g/gaia/issues/5478]
## Build

* Device: Otoro
* Date: 9/24 (can't test on today's build, given that playing mp3 files is broken)

## Steps

1. Open the music app with one mp3 file loaded on your sdcard
2. Start playing the song
3. Exit the music app
4. Open the music app and reselect that same song

## Expected

The music player should load with that song already playing.

## Actual

The music player restarts that song. This is differing behavior than most music players I've worked with.

Comment 1

[Dominic Kuo [:dkuo]]

Casey, which behaviour does our music app should have?

Comment 3

[Adam Alldredge [:AdamA][Inactive]]

This issue is still occurring on latest 2.2 flame Master build.

Environmental Variables:
Device: Flame 2.2 Master (319mb)(Kitkat Base)(Full Flash)
BuildID: 20141219040202
Gaia: deb90229734e5397cda806fb11f2e001fba83399
Gecko: 021b09e92d30
Gonk: e5c6b275d77ca95fb0f2051c3d2242e6e0d0e442
Version: 37.0a1 (2.2 Master)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Result:
Selecting currently playing song restarts the song instead of bringing user to it.

Comment 4

[Parul Mathur [:pragmatic] - out of office - please ni? [:bajaj] instead]

:dkuo, do you think we can get this bug fixed? It's more "polish" than "critical" but the fix will make the music app more enjoyable to use.

Comment 5

[Dominic Kuo [:dkuo]]

I can fix this and just need ux to confirm it's a expected behavior, though I think this should be a minor ux polish. Jacqueline, would you please comment on this? thanks!

Comment 6

[Jacqueline Savory [:jsavory] UX]

I agree with the expected behaviour here. When the song is already playing, the music app should return to the playing song, rather than restarting it. If the user wants to restart the song, they can still choose to restart it separately.

Comment 7

[Dietrich Ayala (:dietrich)]

Hi Dominic, are you still working on this? If not, can you unassign yourself and put yourself as mentor? Then someone else could fix it :)

Comment 8

[Dominic Kuo [:dkuo]]

I am not working on this I am happy to mentor someone to fix this!

Comment 9

[Michael Kohler [:mkohler]]

Assigning to Asma for the the Mozilla Weekend in Berlin

Comment 10

[André Fiedler]

@Asma Can you continue to work on this? Would be great! :)

Comment 11

[assma.saidi]

(In reply to André Fiedler from comment #10)
> @Asma Can you continue to work on this? Would be great! :)
Yes sure André I will finish correcting this bug

Comment 12

[Tiffanie Shakespeare [:tif]]

Hello! Reviewing polish bugs today - is this still in progress? Is there something the UX team can help with?

Thanks!

Comment 13

[GitHub Autolander Bot]

Attachment: [gaia] justindarc:bug796319 > mozilla-b2g:master

Comment 14

[Justin D'Arcangelo [:justindarc]]

Comment on attachment 8668767 [details] [review]
[gaia] justindarc:bug796319 > mozilla-b2g:master

One-liner :-)

Comment 15

[Hubert Figuiere [:hub]]

We should be able to test this in the integration tests.

Comment 16

[Jim Porter (:squib)]

I think we actually need to decide exactly how this should work before we patch it. For instance, what should happen if you're playing an *album* and then tap that album again? Should we just go to the player view? Should we restart the album? The current patch seems like it would restart the album, but only if you're on the 2nd track or later.

This gets even weirder if we consider playlists whose first track is the same as the currently-playing track. It could be quite confusing to not hear the beginning of the song in that case; my first guess would be that something broke.

I'm of the opinion that tapping on any playable thing should start playing that *from the beginning* because that's the simplest behavior, and the one that's easiest for users to grasp. It means that, no matter the current state of the player, tapping an item always does the same thing.

Comment 17

[Jim Porter (:squib)]

Comment on attachment 8668767 [details] [review]
[gaia] justindarc:bug796319 > mozilla-b2g:master

Clearing review until my question above is answered by UX.

Comment 18

[Jacqueline Savory [:jsavory] UX]

Hey Jim, I'm not sure I understand what you mean you say a user taps on an album and then it restarts? If a user taps on an album, they should be brought to the list of songs within the album but no action should occur on the currently playing song. 

If you are referring to the play button in an album or playlist, this should restart the song since you are "playing the album again" (however I think this button is more confusing than helpful and will hopefully be removed at some point.) 

I think the expected behaviour when tapping on a specific song should be that it does not restart, the only exception for this should be if the user is tapping on the same song but through a different album or playlist. For example, if the user is playing a song through all songs, but then goes into its album and taps it from there, the song should restart.

Hopefully I answered your question but I'm not sure I did, feel free to ni? me again if I didnt :)

Comment 19

[Justin D'Arcangelo [:justindarc]]

(In reply to Jacqueline Savory [:jsavory] UX from comment #18)
> I think the expected behaviour when tapping on a specific song should be
> that it does not restart, the only exception for this should be if the user
> is tapping on the same song but through a different album or playlist. For
> example, if the user is playing a song through all songs, but then goes into
> its album and taps it from there, the song should restart.

Jacqueline: Its going to be difficult (maybe impossible?) to determine *how* the user started the currently-playing song until we migrate away from MediaDB in v3.

Comment 20

[Jim Porter (:squib)]

(In reply to Jacqueline Savory [:jsavory] UX from comment #18)
> Hey Jim, I'm not sure I understand what you mean you say a user taps on an
> album and then it restarts? If a user taps on an album, they should be
> brought to the list of songs within the album but no action should occur on
> the currently playing song. 

In the tiles view, tapping an album starts playing the whole album without going to the song list. You can also play a full album by tapping on the first song in the listing for a single album.

> I think the expected behaviour when tapping on a specific song should be
> that it does not restart, the only exception for this should be if the user
> is tapping on the same song but through a different album or playlist. For
> example, if the user is playing a song through all songs, but then goes into
> its album and taps it from there, the song should restart.

My issue with this is that we're defining a UX that does different things depending on the current state of the rest of the app (in ways that aren't strictly necessary). Since tapping a song normally plays that song from the beginning, I think it makes the most sense for it to do that *all the time*. Then, the UX description doesn't need to be "it does X, except when Y, in which case it does Z"; instead, it's just "it does X".

Also, as Justin says, there's no real way to determine where the current playlist came from, and I have ideas for the music app that will make that even harder to figure out. I don't think we can make an exception as you suggest.

Comment 21

[Jacqueline Savory [:jsavory] UX]

Essentially, whenever you click on a song, or tile, it will play the song. The only exception is if the song is the currently playing song in the current playlist, album, etc. Also, this exception can be seen in both Android and iPhone music players, this seems to be typical behaviour, not something new that we have created. 

I think this is the best experience from the user's perspective. If we technically cannot accomplish this for the current release, then your solution is best for now (to always restart), however, it should be changed later on if we can.

Comment 22

[Justin D'Arcangelo [:justindarc]]

Un-assigning this from myself since we won't be dealing with this in v2.5.

Comment 23

[BMO Automation]

Firefox OS is not being worked on