Bugzilla – Bug 12058
Don't reveal "now playing" or "current playlist" when now playing is empty
Last modified: 2009-09-08 09:21:37 UTC
Suggest replacing the word "Nothing" with descriptive text on how to build a playlist. Basically, give the user a direction and not a dead-end.
Discussed this with Dean. The proposed solution (which I very much like): hide the now playing button from touch when now playing is not available/empty (the secondary effect of this is that there would be no way to ever see the current playlist containing "nothing"). If the user presses the "now playing" remote button in this case, then we just trigger a "bump."
So how would a user see what is in the current playlist if he has no way of viewing it? Hit 'Play' and see if any sound comes out of his speakers??? Or maybe you figure that by hiding the buttons everyone will automatically figure out "There's no button, so the playlist must be empty". No way. It will just confuse them. Now Playing buttons on both the touch and IR interfaces should always go the Now Playing screen, not to a 'Nothing' playlist. You're right, it's a dead end. The Now Playing screen also has player controls that are unavailable elsewhere in the touch interface, except buried under Settings: volume, repeat and shuffle. These aren't 'Settings' that you should have to drill through menus to find. You can change them on any Squeezebox using the IR interface, no matter if there's anything in the playlist, so why not also in the touch interface? You would only be creating an unnecessary limitation to the interface. Keep it simple.
"So how would a user see what is in the current playlist if he has no way of viewing it? Hit 'Play' and see if any sound comes out of his speakers???" By definition, there IS nothing in the current playlist in this case. So nothing to see :-). "Or maybe you figure that by hiding the buttons everyone will automatically figure out "There's no button, so the playlist must be empty". No way. It will just confuse them." I respectfully disagree. "Now Playing buttons on both the touch and IR interfaces should always go the Now Playing screen, not to a 'Nothing' playlist. You're right, it's a dead end." I don't understand what you mean. We're not suggesting the user go to a "nothing" playlist - in fact removing this functionality was the original intent for Noah filing the bug. "The Now Playing screen also has player controls that are unavailable elsewhere in the touch interface, except buried under Settings: volume, repeat and shuffle." By definition, those controls either won't work or would be pretty worthless, since no music is playing and the playlist is empty! "These aren't 'Settings' that you should have to drill through menus to find. You can change them on any Squeezebox using the IR interface, no matter if there's anything in the playlist, so why not also in the touch interface? You would only be creating an unnecessary limitation to the interface." I'm not sure if you understand the use case here. THERE IS NOTHING TO PLAY. The playlist is empty. pause, ff, rew won't work. Shuffle and repeat would be pretty worthless and, IIRC, are available in settings. The one area where I might see your argument is on volume control. But again. There is no music. "Keep it simple." Thanks.
(In reply to comment #3) > "So how would a user see what is in the current playlist if he has no way of > viewing it? Hit 'Play' and see if any sound comes out of his speakers???" > > By definition, there IS nothing in the current playlist in this case. So > nothing to see :-). Then SHOW that to the user on the Now Playing screen, rather than just IMPLYING it by either bumping or with disappearing buttons. > "Now Playing buttons on both the touch and IR interfaces should always go the > Now Playing screen, not to a 'Nothing' playlist. You're right, it's a dead > end." > > I don't understand what you mean. We're not suggesting the user go to a > "nothing" playlist - in fact removing this functionality was the original > intent for Noah filing the bug. No, _I'm_ saying this, in agreement with the statement made by ndijulio. The current behavior of displaying an empty playlist makes little sense. NP should always go to NP. > "The Now Playing screen also has player controls that are unavailable elsewhere > in the touch interface, except buried under Settings: volume, repeat and > shuffle." > > By definition, those controls either won't work or would be pretty worthless, > since no music is playing and the playlist is empty! > > "These aren't 'Settings' that you should have to drill through menus > to find. You can change them on any Squeezebox using the IR interface, no > matter if there's anything in the playlist, so why not also in the touch > interface? You would only be creating an unnecessary limitation to the > interface." > > I'm not sure if you understand the use case here. THERE IS NOTHING TO PLAY. > The playlist is empty. pause, ff, rew won't work. Shuffle and repeat would be > pretty worthless and, IIRC, are available in settings. The one area where I > might see your argument is on volume control. But again. There is no music. No. Volume, repeat and shuffle will change the state of the player, even if nothing is playing. If you have Shuffle set, there's a very large difference between turning it off before you add items to a playlist and doing so after. And have you never changed the volume of a stereo with nothing playing? Users will know where they set these in the NP screen. Changing them through Settings is something they may never do and is far more roundabout. I'm trying to figure out what exactly is being avoided here by "not revealing" blah blah blah. You'd think showing a blank Now Playing screen was like showing your dirty underwear in public. It's consistent behavior and that's GOOD.
Consistency is great, but it's not the holy grail (otherwise we'd have no need for contextual menus, different transport controls based on what you're listening to, showing help buttons only when a help screen is available, etc.) Consistency must be balanced against context. This is a silly thing to argue about. Let's implement this solution and see how it performs.
This may be addressed, QA to verify