Noah, once you have checked in reference screens and assets into SVN, can you reassign to Ben?

this is an administrative shuffle on priority fields to help make better judgment on the top end of the priority list. P4->P5, P3->P4, and P2->P3.

*** Bug 13669 has been marked as a duplicate of this bug. ***

 == Auto-comment from SVN commit #28473 to the slim repo by bklaas ==
 == https://svn.slimdevices.com/slim?view=revision&revision=28473 ==

Bug: 13896
Bug: 13689
Bug: 8878
Description:  playlist/party mode, a feature that was never fully baked/completed, is in direct conflict with some of the touch-to-play behavior introduced in 7.4. I'm dealing with this issue by removing the Settings->Advanced->Beta Features->Playlist Mode item and explicitly ignoring whatever client pref is set for playlistMode and always returning 'off'. This effectively kills the partial fix for bug 8878, but I believe if we can concentrate on what is laid out in 13689 we may have a better solution.

Voters of bug 8878, I feel your pain. If I had a party I wouldn't hand the controller to anyone for fear of killing the music/destroying the playlist. It stinks, and I will do my best to continue to raise this issue for a better and more full solution.

Reassigning to Weldon (temporarily) to review screen comps (posted to campfire).  

Once they have been approved, I will commit assets to SVN and reassign to engineering.

Reviewed and approved.

love the idea of ability to delete from playlists but unsure at the moment how the finished concept will fit with

... the (aborted) playlist feature
... the change to "+ is more" which
...... increases the likelihood of accidental playlist wiping
...... is inconsistent between IR to SB3, IR to Radio and SBC/Radio

Is there a debate somewhere to refine the required functionality

Have you considered https://bugs-archive.lyrion.org/show_bug.cgi?id=9564 in this context ?

(In reply to comment #7)
> love the idea of ability to delete from playlists but unsure at the moment how
> the finished concept will fit with
> 
> ... the (aborted) playlist feature
> ... the change to "+ is more" which
> ...... increases the likelihood of accidental playlist wiping
> ...... is inconsistent between IR to SB3, IR to Radio and SBC/Radio
> 
> Is there a debate somewhere to refine the required functionality

Actually this feature was specifically devised to accomodate that EXACT list of issues you mention while keeping everyone happy.

Users that commonly edit and modify playlists (especially while listening to them) will be strongly encouraged to start using this feature.

I've read the description of this enhancement several times now, and think I understand how it works when you are seeking to edit a playlist, either in the Web UI or using the Controller (you simply scroll down and choose Edit Playlist).  

Does this mean that the playlist can not be edited any other way?  With respect to the Controller, what happens when you search or browse for a track or album and hit the center button (which right now replaces the playlist with the selection)?

However it is done, in my view the MAIN THING is to allow users to turn off the aggravating, playlist-destroying press-to-play feature. 

That said, I like the ideas in the proposal very much. I would only add a few points.

(1) The "+" button "adds next" feature would have the effect of eliminating any way of getting track info when in Edit Playlist mode, wouldn't it? That doesn't sound good. You want to be able to look at, say, composer info on a track that isn't necessarily in the playlist.

(2) Instead of having the center button function as "add" in Edit Playlist mode, why not use the "+" button? Then the center button would continue to be a drill-down (to the context menu). That seems more consistent to me: the center button is for navigation and the "+" and "->" buttons are for committing actions. But that may be just me. (One problem with this idea is that then you wouldn't want to use the select button to delete items from the playlist in Edit mode. And it seems weird to use the "+" to remove items. So maybe this is already a reason not to take my suggestion here.)

(3) I don't know if the proposed special "+" and "-" symbols at the right of each item are really necessary. I suppose they have the benefit of signaling which mode you are in, but otherwise it would be clear that if you're looking at an item in the playlist, the action would be to remove the item, and if you're looking at it in My Music, the action would be to add it. However, having some visual indication when browsing in My Music that an item is already in the playlist is a great idea. But the proposal calls for doing that anyway, separately from the "+" and "-" symbols.

(4) The press-to-play feature, which is executed on a track, doesn't just play the track! It plays the whole album (starting with the selected track). This is a separate complaint, really. If I wanted to play the whole album, I wouldn't drill down all the way to the track level. Maybe playing an album starting from the track of my choice is supposed to be a feature, but I can't see that there's enough value in it to make that the default behavior. The default behavior when you press Play on a track should be to play the track. Playing the album starting from that track should be what you go to the context menu for, not playing the track.

Sorry about my fourth point above. I now see that it is configurable whether pressing play plays the whole album or the track only.

(In reply to comment #12)
> Sorry about my fourth point above. I now see that it is configurable whether
> pressing play plays the whole album or the track only.

Yes, it is.  But if the setting is to play all tracks, you can play a song by selecting Play from the context menu.

Conversely, if the setting is to only play the selected track, the Play context menu only plays the selected track, and there's no way to play all tracks starting from the selected track.

I think this is potentially a missing context menu action - I think there should be a "Play album at this track" action.

(In reply to comment #11)
> However it is done, in my view the MAIN THING is to allow users to turn off the
> aggravating, playlist-destroying press-to-play feature. 

> (4) The press-to-play feature, which is executed on a track, doesn't just play
> the track! It plays the whole album (starting with the selected track). This is
> a separate complaint, really. If I wanted to play the whole album, I wouldn't
> drill down all the way to the track level. Maybe playing an album starting from
> the track of my choice is supposed to be a feature, but I can't see that
> there's enough value in it to make that the default behavior. The default
> behavior when you press Play on a track should be to play the track. Playing
> the album starting from that track should be what you go to the context menu
> for, not playing the track.


David's first point is the crucial one.
And I agree with his fourth point too.

Ben, it's not clear to me what the next steps are on this bug.  I'm going to temporarily target it for 'Future.'  We can talk about what's left and what the new target should be after the 7.5.0 release.

these are the notes that Tom and I put together before the proverbial matter hit the proverbial wind blowing device.

--------------
First Ask: would we ship the product without this?
just kidding

Edit Playlist Mode:

SC-side

send a "Edit Playlist" choice menu item (if the player is a squeezeplay player) for the end of the current playlist menu

server stores a client setting for which state the player is in, editPlaylistMode on/off
playerstatus response includes info as to which state the player is in

server-side context menu should not return a play item
bonus points if it can replace play with "play now", which is play next + jump to it now

SP-side:

send in the playerstatus subscription a key/value tagged param of something like 'includeEditPlaylist:1'. This is so Joerg et al won't get "polluted" current playlist menus that have an item that effectively does nothing for it. Also, this makes it backwards compatible.

Player.lua immediately stores the state when editPlaylistMode is toggled so it's not necessary to wait for the playerstatus response

when editPlaylistMode changes, change window style of current playlist window accordingly (new window style for edit playlist mode on, with only difference being styling of item_play item to include + sign)

when browsing into slimbrowse menus, change window style if editPlaylistMode is on

play is play next, go is add-to-end

play button does nothing on anything but press-to-play tracks (up for debate, but this is effectively "jukebox mode")

Okay, did your ideas included some way of changing the order of the tracks in the playlist thats being edited ?

And could you choose and edit any of your playlists, not just the ongoing one for the player you are at ?

Future thats sad :-( sbs/sp has really poor playlist creation in general sorry to say that but thats how it is.

Ok where is the bug for getting squeezeboxserver better playlist abilities,I go and vote there too, there is one is it not ? Squeezeboxserver is where you want to do most of your playlist editing. (now you are using other applications and replace the file paths )

Uh, I think we need to stay focused on the central problem this bug is meant to address. I have no problem with the way the controller handles playlists generally, and I'm sure I speak not only for myself but for many users in saying that. (And I really like the new "Play Next" feature. Good idea.)

But I am sick to death of seeing a playlist, often with 10 or 20 items on it, go down the drain inadvertently because I pushed the wrong button. This still happens to me periodically, and obviously I'm thoroughly familiar with using the device. Since 7.4 came out, I can't give my controller to anyone else any more to fiddle with unless I don't care what happens to the playlist. That's too bad, because your device used to sell itself to newcomers.

I don't really care about having a playlist "edit mode." That's gravy. In my view, there should be NO MODE that allows you to destroy the whole playlist without warning by pressing the most-used button on the unit. That's just crackers, and I can't believe it would be some inordinate effort to fix it. 

Pressing the center button once you've drilled down to the track level ought to bring up the context menu for that track, imo (what the + button does). If you want to play it, that's what the Play button is for. How hard would that be?

I was struggling to understand some comments in this report, but think I understand now. It would help if people could be clearer with terminology.

In Comment 18 - you don't mean destroy "a playlist", you mean "accidentally replace the current playlist.  The current playlist may be unnamed (selected by playing items by browsing the library), or a named playlist (selected by playing a saved playlist).

It's very hard to destroy "a playlist"; in the normal mode of operation, it's easy to replace/clear the "current playlist".

I think that bundling the two meanings/types of functionality to the current playlist as an "Edit Playlist" option is confusing.

Changing the mode such that items are added to the end of the current playlist, rather than replacing the current playlist should not be confused with this "Edit Playlist" option.  The "Edit Playlist" action on the current playlist screen should not be considered a setting.  "Save Playlist" and "Clear Playlist" are not settings - they are actions.

"Edit Playlist" on the current playlist screen would to me suggest an option for editing the current playlist for moving songs around, deleting items, etc.  If the current playlist is a named playlist, would Edit Playlist affect that playlist permanently, or only in the current playlist until Save Playlist is pressed?  Would Edit Playlist setting persist if the current playlist was cleared, and a new playlist started?

Furthermore, this action won't be available when there are no tracks in the current playlist (can't get to Now Playing screen), or when there is only one track in the current playlist (due to the silly decision to display a context menu for the 1 item instead).

I think there should instead be an option in the player Settings to enable/disable this mode.  eg something like:

Current Playlist mode: Replace / Add
or
Jukebox mode = Disabled / Enabled

On the Touch interface, what I think would work well, would be for the title bar to act as a way to get to a context menu for the current playlist, whereby Save and Clear actions can be accessed.  It would be clearer that these are actions, rather than settings, and would always be available.  At the moment, it is not possible to get to these actions when the current playlist has only one item, because the playlist button is replaced with a context button for that 1 item.  An action in this context menu to change the playlist mode would then be okay (but I still feel it belongs in player settings).

The context menu for the currently playing item would more logically be on touching the song information (touch the title for song context menu, touch the artist for the artist context menu, touch the album for album context menu).

(In reply to comment #19)
> In Comment 18 - you don't mean destroy "a playlist", you mean "accidentally
> replace the current playlist.  The current playlist may be unnamed (selected by
> playing items by browsing the library), or a named playlist (selected by
> playing a saved playlist).

Yes, exactly. I rarely use saved playlists and didn't think about that. Thanks for clarifying.


(In reply to comment #20)
> I think there should instead be an option in the player Settings to
> enable/disable this mode.  eg something like:
>
> Current Playlist mode: Replace / Add
> or
> Jukebox mode = Disabled / Enabled

Good idea. Alternatively, "Edit Playlist" could still appear on the current playlist screen and what the option in player Settings would do is determine its default setting.

I have to echo the sentiments in Comment 18.  PLEASE don't shelve this bug, at least not that portion that pertains to accidental "replacing"  or wiping of the playlist.  Surely that is the easiest thing to solve, and it is the #1 reason I voted for the bug.  The rest, as was said, is gravy.

I concur with comment 18 and others that now I can no longer have a "Party Mode" where the big pleasure of this ad hoc playlist is letting my friends hand the duet around and keep adding music - as this is no longer intuitive and almost always wipes out the party list - and created a lot of unhappy folks (as well as me) at my last party.
Unfortunately now the team managing the forums have now banned and removed any discussion of party mode off the forums.
You all seems to be so bent on some ipod like orthodoxy that you have ruined one of the most fun parts of my duet.
As a note - I dont see ever going past 7.3.4 - which is what I and many have reverted back to because of this which likely means I wont every buy any device but will only use what I already bought.

(In reply to comment #23)
> I concur with comment 18 and others that now I can no longer have a "Party
> Mode" where the big pleasure of this ad hoc playlist is letting my friends hand
> the duet around and keep adding music - as this is no longer intuitive and
> almost always wipes out the party list - and created a lot of unhappy folks (as
> well as me) at my last party.
> Unfortunately now the team managing the forums have now banned and removed any
> discussion of party mode off the forums.
> You all seems to be so bent on some ipod like orthodoxy that you have ruined
> one of the most fun parts of my duet.
> As a note - I dont see ever going past 7.3.4 - which is what I and many have
> reverted back to because of this which likely means I wont every buy any device
> but will only use what I already bought.

Of course what I meant was - if I was on 7.4x I couldnt pass the duet around. Only because I've reverted - and will stay on 7.3.4 - can I pass the duet around.

Censoring the forums is bad, but there is hope for the party mode. See the comment here but also http://wiki.slimdevices.com/index.php/PlaylistModePartyMode

I am probably too late to the party to comment or suggest an approach but I'll do it anyway.

Personally, I don't think a playlist should ever be replaced unless a user specifically requests to clear a playlist.  I don't even view it as a playlist.  I see it as a squeezebox queue--it can contain tracks selected invidually or it can contain one or more playlists (i.e., a pre-saved collection of tracks).  A playlist is something that has been saved while the "now playing" is really a queue--one that can turn into a playlist if the user selects to save the current queue.

I suspect I will the above argument to make it the defaul behavior, so is there a way to have a setting that will prohibit the queue/playlist from being replaced?  Of course, the action of clearing the playlist will still work but the queue won't be replaced unless the user engages a specific action to replace.

Replacing aside, here are my suggestions for adding tracks to the queue.  The center button should never add a track--ever.  It should be used for navigation only and should never result in a track being added.

What should happen is when I navigate to the lowest level (i.e., track level), a context screen should pop up.  The selections would be play (i.e., play now), play/next, or add to end.  Thus, the center button does nothing to the track, and it takes another action by the user to determine which (or if) track should be added.  Hitting the play button on the controller can be assumed to be play now, and will result in the track being added to the queue and then being immediately played.  Hitting the + button, will bring the same contextual commands (play, play next, add) as well as the other contextual command relating to track info.

The above assumes only single tracks are played.  I don't see the logic of playing all tracks anyway.  If I am at the lowest level (that is, the track level), I am really interested in adding tracks individually.  If I want an album, I'll hit play at the album level (or artist level or any other higher level).  If I do, it play now all tracks from lower levels.  If I hit the + button, it will bring up the same contextual commands (play, play/next, add) and will perform the appropriate command on all tracks from all lower levels.

Isn't this basically how Sonos does it?  Not sure if you want to be compared to them, but they do have an intuitive design.  As it stands now, I have a hard time explaining to my wife how to add a song on our squeezebox.  She doesn't have the same problem with our friend's Sonos.

Forgot to add a couple of thoughts.

One, buttons on the controller that do the same thing should never result in different actions being taken.  In the current setup (7.4.2), for example, the play button results in all tracks for an album being added and replacing the existing playlist.  However, if you select play from the + button, it only adds a single track.  ??.  Play is play, and it should not be different.

Two, the controller and the web interface should more or less act the same.  I realize there will always be some differences (one may have features the other does not) but actions should be consistent.  in the current setup, play in the web interface plays a single song.  ??.

While my frustration is with the current design, a good chunk of it is related to the inconsistency of which button I select, in what order I selecting and the varying results I get.

Since the reorg, it's not clear when we'll have another major UI review.  We do now have a regular review of 'Future' bugs so I am at least confident this won't get lost, especially with 24 votes.  Thanks for voting!

I just had a chat with marketing about this bug.  I think we reached a consensus that the new context ('+') menu has fixed some of the features that this bug originally called for.  

Of the remaining work, the big one is still the ease of destroying a painstakingly-created playlist if your stupid Uncle Larry picks up the remote and plays the Hokey Pokey during your party.

The obvious solution for that part of the bug would be to put up a prompt at that time and say 'Hey, you're about to destroy a quite-complicated playlist.  Are you sure you want to do that?'

We should check if the current playlist was only one song, and if so, NOT prompt the user.

I don't know if there is a more intuitive or elegant solution.  We should certainly get some UI designer input.  Customer comments are also always welcome.  :)

Not sure the solution you outline would be ideal.  What if I want to play a song now but don't want to replace my other 20 songs in the playlist?  That is, I want a particular song to jump in line and be played now but I also want to here the other songs after I listen to the song I just selected.

Why not just have a setting where pressing play or the center button never replaces the current playlist?  I had read somewhere that some people like that feature.  I can't figure why on earth they do, but some people are not grounded in reality.  For the rest of us who are sick of having our collection of songs replaced accidentally, that setting would take care of the main problem this bug centers around.  Everything else, like you said, can be addressed with the context menu.  Basically, hitting play or the center button would be a "play now" command if the setting is set to never replace a playlist (of course, erasing/deleting a playlist via the delete command would always work).  

To me, that would take care of most of the complaints.  Another complaint I have, and one you can chose to ignore because it is less of an issue, is that the center button should never result in an action other than navigating up/down a hierarchy.  It should be used for navigation and navigation only.  If someone comes to the lowest level of a hieracy via the center button, then the context menu should pop up where the user can decided what they want to do next--play, add to end, play next (or play now if you put in a setting never to erase a playlist!).

Just my two cents.

(In reply to comment #29)
> I just had a chat with marketing about this bug.  I think we reached a
> consensus that the new context ('+') menu has fixed some of the features that
> this bug originally called for.  
>
Having a context menu, launched by use of More button is good, but the default actions available within the context menu are limited.  eg. it could offer to play, add next, add to end, for any item that the context menu is invoked from.

My Playlist Manager plugin adds some extra actions like this, plus the ability to add to any other playlist.  You could consider integrating some of the plugin code into the core functionality?

> Of the remaining work, the big one is still the ease of destroying a
> painstakingly-created playlist if your stupid Uncle Larry picks up the remote
> and plays the Hokey Pokey during your party.
> 
> The obvious solution for that part of the bug would be to put up a prompt at
> that time and say 'Hey, you're about to destroy a quite-complicated playlist. 
> Are you sure you want to do that?'
> 
I think that would be really annoying.

I think that performing an action from the context menu shouldn't ever need to ask for confirmation, as it is highly unlikely to be an accidental action.

> We should check if the current playlist was only one song, and if so, NOT
> prompt the user.
> 
Even more irritating; sometimes you get the warning, sometimes not.  A single track is a bit strange to denote "a complex playlist".  That would include a radio station, Last.FM, etc too.  A better check would be if the current playlist was built up in more than one action, but that would be tricky to calculate (probably better to remember what the last action to the current playlist was).  e.g. if a song was played, and then another added, the current playlist is now "complex".  If an album is played, that is a single action.  If a playlist was played, that would be a single action.  Also bear in mind that the current playlist could have been from some days prior, so the user may not remember what is in the current playlist.

Actually, I guess that most people don't often clear the current playlist; they play something and then turn the player off.  They come back the next day and choose something to play, replacing what was in the playlist from the last listening session.

It's not very often that I have a blank playlist (or a single track in it).  I think the only time that happens is if I do a full clean+rescan, so I'd get the warning dialog every time I select to play something :-(

(In reply to comment #29)
> Of the remaining work, the big one is still the ease of destroying a
> painstakingly-created playlist if your stupid Uncle Larry picks up the remote
> and plays the Hokey Pokey during your party.

Right. Of course, I'm often the Uncle Larry. My wife is now scared of the thing
and rarely uses it (not kidding).

> The obvious solution for that part of the bug would be to put up a prompt at
> that time and say 'Hey, you're about to destroy a quite-complicated playlist. 
> Are you sure you want to do that?'

Sounds OK. Note that the Play button wouldn't necessarily have to have the
prompt, only the Go button. After all, the user isn't habituated to pressing
the Play button for navigation. The Play button always plays. So, in the
unlikely event that there are actually some users who are constantly wanting to
interrupt what's currently playing with something new, they could use the Play
button to do that without being bothered by the prompt.

> We should check if the current playlist was only one song, and if so, NOT
> prompt the user.

Of course, you would also want to NOT prompt if the current playlist has NO
songs.

And I have to add: as long as you're presenting a prompt, why not the context
menu? When the Go button is pressed rather than the + button, "Play" could be
the default action instead of "Add to End." Just a thought!

> Customer comments are also always
> welcome.  :)

Believe me, I appreciate your willingness to listen to what your users have to
say.

I think that some people still see merit in having some form of protection for accidental wipe of current playlist when hosting a party.  There's a variety of ideas available for that situation; eg. a player setting to enable/disable the play action (perform an Add action instead, or show brief message that player is in party mode, etc).

The old "Party Mode" was okay in this respect, except the bizarre nature of guessing that it should be automatically turned on when pressing the Add button.  It should have only been a setting that is manually enabled/disabled.


But the new issue we now have is when navigating around whereby the default action at some point now performs a play operation.  Adding a warning/question dialog is attempting to fix the symptom, not the root cause.

As it is the single-most important feature (to play music), it would be really annoying to frequently get question dialogs.  It would be like getting an "Are you sure?" message on your TV when trying to change channel!

To me, a better solution is to ensure that actions are not mixed with navigation actions.  i.e. right-arrow on a song (or centre button with SBC, or touch with Touch UI), should not play the song.  Instead, it could bring up the context menu, where Play is the most prominent menu action at the top of the list, but the user has a choice to do something else, and if he didn't mean to do anything, can back out of the context menu.  That in itself becomes a confirmation of the action, which is more useful than an "Are you sure?" dialog.

Perhaps if the playlist is empty, the default action for a song could be to play it, but if there is something already in the playlist, the context menu is displayed, where the user can choose to play, add, add next, etc.

I think there are some different and good ideas in here.  My take is this.

The big issues folks see are:
--Accidental deletion of playlist by playing a song
--Inconsistent behavior of buttons/commands
--Limited options in the context menu

To me, the following guidelines should be kept in mind when addressing the above problems:
--Make actions consistent. Play, whether from context or from the play button, should always have the same behavior.  Likewise, a confirmation message of "Are you sure you want to delete" appear in certain situations vs. not in others would cause way too much confusion.  Either you allow deletion of a playlist or you do not.  No need for the confirmation message because the user should understand that the same behavior can be expected regardless of the scenario.


--Do not try to anticipate user intent.  Having a confirmation message appear in certain scenarios vs. not appear in others because you can infer user intent only ends up causing more confusion.  All users are different and therefore understanding intent can not be determined regardless of whether a playlist has a single or multiple items or how many actions it took to create a playlist.  As the above states, just be consistent and then users can plan around that.

My final is this.  From my perspective, the two issues I have are accidental deletion of the playlist.  My preference is that that should never happen.  That is, playlists can only get deleted if the user goes to the bottom of the playlist and explicitly says "delete."  The 2nd issue is having to do with buttons.  Be consistent.  The center button is navigation and navigation only (see consistency point above).  It either decends to the next level or it pops up the context menu. And, moreover, play via the play button should be no different than play via the context menu.  Now it is and that is confusing.  Make things consistent so that users can easily predict what bahvior they can expect.

How about a "switch" that, when turned on, causes any action that would currently result in a playlist being deleted to, instead, add the track(s) to the end of the playlist?  I'm not sure it's the ideal situation, but if I accidentally add tracks I didn't really want, I can always scroll down and delete them.  Most of the time "add track" likely was the action I was looking for anyway, although there have been occasions where I was trying to drill down into an album to find a particular track and found myself immediately listening to the entire album instead.

In any event, if it can be done quickly I can live with the warning solution being proposed.  It's better than the current state of affairs, IMO.

(In reply to comment #35)
> How about a "switch" that, when turned on, causes any action that would
> currently result in a playlist being deleted to, instead, add the track(s) to
> the end of the playlist?
>
That is what Playlist/Party mode used to provide (the only weirdness was that the mode was turned on automatically by pressing Add button, and turned off by doing something else with the add button, can't remember the specifics).

(In reply to comment #36)
> (In reply to comment #35)
> > How about a "switch" that, when turned on, causes any action that would
> > currently result in a playlist being deleted to, instead, add the track(s) to
> > the end of the playlist?
> >
> That is what Playlist/Party mode used to provide (the only weirdness was that
> the mode was turned on automatically by pressing Add button, and turned off by
> doing something else with the add button, can't remember the specifics).

The "switch" is exactly what I think is needed.  The only thing I would do differnetly than what you propose is to substitute "play now" functionality rather than adding the track to the end of the list.  If you wanted to add to the end, you can do that right now with no problems.  As it stands now, there is no way to play now without wiping the playlist.

(In reply to comment #37)
> The "switch" is exactly what I think is needed.  The only thing I would do
> differnetly than what you propose is to substitute "play now" functionality
> rather than adding the track to the end of the list.  If you wanted to add to
> the end, you can do that right now with no problems.  As it stands now, there
> is no way to play now without wiping the playlist.

I'm not too keen on this. The "switched" behavior is what I would have on all the time, and I would continue to make the mistake of playing something now, rather than seeing a context menu or further drilling down -- cuz half the time I make this error, I think, it's because I fail to realize/focus on the fact that I've reached the track level. Making the action a nondeleting "play now" would make the error less disastrous than a deleting "play now," but still annoying.

I really don't think, even in "switched" mode, pressing the center button should do anything without confirmation. If it brings up the context menu, from which actions can be selected without confirmation, that's best. The other buttons, "+" and "play", can do things without confirmation (as they do now). They aren't regularly used for navigation and don't lead to the same mistakes as does using the center butter for navigation until, uh oh!, you're at the bottom level and suddenly taking actions without confirmation.

While I'm at it, I should add that although I don't object to having a "switched" mode, I don't think it's the optimum solution. Having the center button take unconfirmed action is just a bad idea. The job here should be to fix regular mode, not add a different mode.

(In reply to comment #38)
> (In reply to comment #37)
> > The "switch" is exactly what I think is needed.  The only thing I would do
> > differnetly than what you propose is to substitute "play now" functionality
> > rather than adding the track to the end of the list.  If you wanted to add to
> > the end, you can do that right now with no problems.  As it stands now, there
> > is no way to play now without wiping the playlist.
> I'm not too keen on this. The "switched" behavior is what I would have on all
> the time, and I would continue to make the mistake of playing something now,
> rather than seeing a context menu or further drilling down -- cuz half the time
> I make this error, I think, it's because I fail to realize/focus on the fact
> that I've reached the track level. Making the action a nondeleting "play now"
> would make the error less disastrous than a deleting "play now," but still
> annoying.
> I really don't think, even in "switched" mode, pressing the center button
> should do anything without confirmation. If it brings up the context menu, from
> which actions can be selected without confirmation, that's best. The other
> buttons, "+" and "play", can do things without confirmation (as they do now).
> They aren't regularly used for navigation and don't lead to the same mistakes
> as does using the center butter for navigation until, uh oh!, you're at the
> bottom level and suddenly taking actions without confirmation.
> While I'm at it, I should add that although I don't object to having a
> "switched" mode, I don't think it's the optimum solution. Having the center
> button take unconfirmed action is just a bad idea. The job here should be to
> fix regular mode, not add a different mode.

Agree with everything you said.  The center button is for navigation and should be for only navigation.  If at the lowest level, bring up the context menu to select which command you want (or don't want).  And I also agree about having the functionality be not switched.  To me, this is how it should be 100% of the time.  Why would I ever want to delete a playlist by simply pressing play (or the center button)?  From what I have seen, however, some people prefer the current behavior.  I don't understand it but everyone has a right to be wrong.