Bugzilla – Bug 9164
Rationalisation of the Now Playing screen and screensaver
Last modified: 2009-10-25 03:08:58 UTC
Regarding: SlimCenter & player display/remote functionality The Now Playing functionality has recently been improved by making the "Now Playing (Jump back on Wake)" screensaver the default screensaver when playing (and by renaming it to simply Now Playing). However, the core problem with the Now Playing functionality remains unaddressed. This problem stems from having a seperate Now Playing screensaver and Now Playing screen that look virtually the indistiguishable but that have different functionality tied to them Here's a small practical illustration (in this particular case whilst using the remote to play/navigate with Last.fm Loved Tracks radio stations): Once I'd chosen a neighbours Loved Tracks radio I wanted to see what track was playing and so had two options: 1) Wait minute (or in my case 30 seconds) until the Now Playing screensaver kicked in 2) Hit the Now Playing button on the remote to see the details instantly Disadvantage of 1) is the wait Disadvantage of 2) is being taken back to the top item in my home menu when I hit the left hand arrow key (when expecting and wanting to be taken back to the screen I was last on). This means that every time I choose to see a track's details I had navigate back to the Last.fm LoveTracks section to get back to the screen I was in previously (and after having to do this ten times I was getting very fed up indeed!). The Now Playing functionaliy is one of the most important and most-used parts of the player UI. I (as a long-time Slim user) am very conversant with the UI and am all too aware that the Now Playing screen/screensaver are different things and have different functionality applied to them. New users aren't, and so to them the UI can *immediately* appear confusing, eccentric and be quite frustrating to use (as I have very often seen with the friends who use my remote from time to time). I think a simple solution for the SB2/SB3/Transporter might be that the Now Playing screen be done away with entirely and that the Now Playing button on the remote be mapped to the Now Playing screensaver. However, there are most likely consequences of messing about with the Now Playing functionality which have entirely escaped me.
(In reply to comment #0) > I think a simple solution for the SB2/SB3/Transporter might be that the Now > Playing screen be done away with entirely and that the Now Playing button on > the remote be mapped to the Now Playing screensaver. > > However, there are most likely consequences of messing about with the Now > Playing functionality which have entirely escaped me. I think the main problem could be that the Now Playing screensaver may not necessarily be Now Playing. It can be set to any screensaver that the user has installed. At which point the Now Playing info would be nowhere to be found. Have you tried simply using a lower screensaver timeout? I find 30 seconds to be far longer than necessary. Who takes 30 seconds between button presses while they're navigating menus via the remote? With 'jump back' functionality it doesn't matter if the screensaver kicks in while you're in the middle of doing something - you maintain your place.
Hmm could adding some "jump back to where i was" function be added to now playing screen instead, just my 2c . Include this with the controller interface too ! When choosing "now playing screen" your at top off the meny, and have to browse your way back to where you was in the for example album view.
Jim. 30 seconds is still too slow for me to read some stuff.. any shorter would be even more frustrating. Anyway, in common with the rest of the UI the screen required should be able to be called up immediately... not after some pre-determined wait, however short. Any wait is frustrating and unnecessary. Michael. I think what you are requesting is exactly what I am requesting (with the addition that I would also like to have the Now Playing item completely removed from the default top level menu, as it seems entirely redundant. I removed the item for all my players menus a long time ago).
Isn't an even simpler solution to make the 'now playing' button toggle between 'now playing' and the previous menu position? One of the fundamental issues I have with the 'now playing jump back on wake' screensaver (which is now the default), is that you can press the play button (and the other transport buttons too) and get an entirely unexpected result because they act on the previous menu which can be a plugin that uses those key functions!
Keeping open for discussion and voting.
(In reply to comment #4) > Isn't an even simpler solution to make the 'now playing' button toggle between > 'now playing' and the previous menu position? That might be a very good idea. > One of the fundamental issues I have with the 'now playing jump back on wake' > screensaver (which is now the default), is that you can press the play button > (and the other transport buttons too) and get an entirely unexpected result > because they act on the previous menu which can be a plugin that uses those key > functions! I agree, there are some usability issues with the current implementation of 'jump back on wake'. I thought the first keypress of waking up a screensaver should always be thrown away, but that doesn't seem to be the case. If you were browsing the library and you've timed out into the Now Playing screensaver and you happen to press Play it _will_ play whatever you were last looking at. That seems like a bug to me, certainly a usability problem. Seems that some keys are thrown away, while others aren't. Another thing I notice is that I often get a brief flash of the Date/Time screensaver (configured as screensaver for stopped and off states) on wake. I don't know why going from the Now Playing screensaver 'back' to wherever you were should go through another screensaver, but it sometimes does.
(In reply to comment #4) > Isn't an even simpler solution to make the 'now playing' button toggle between > 'now playing' and the previous menu position? I think this is a very good proposal, however I would also ask that the current implementation of Now Playing/Left key Press/Top of Home menu (this is in the PlayerUI) is maintained. For example, I have promoted the Last.fm account change menu item to the top of the Home menu as a kind of shortcut, so I can always get to this quickly (normally when I am scrobbling my Latin pop or cheesy house to the wrong account).
> Isn't an even simpler solution to make the 'now playing' button toggle between > 'now playing' and the previous menu position? That's been how I've wished it worked for at least a couple years..
meant to CC myself..
We now have five votes for this from experienced users. Is that enough to get it implemented? > Make the 'now playing' button toggle between > 'now playing' and the previous menu position. If this bug could be sorted out at the same time, https://bugs-archive.lyrion.org/show_bug.cgi?id=3992 the usability of the Now Playing area would have been greatly improved.
Note that the controller doesn't have a Now Playing button. There is a home button which toggles between home menu and now playing! I have no completely good solution - but for me it's most important that the Now Playing screen saver followed by the controller button get me to the playlist, no matter what was happening when the screen saver kicked in. So, for the controller, what I would like when the screensaver kicks in is: 1. Full now playing screen, including status bar. 2. Button takes me to playlist, as it does from the "real" now playing. 3. Back key takes me to where I was then it kicked in. (Jump back on wake, with button consumed). 4. Home key takes me to home menu.