Agreed.  This IR interface behavior should not change from that used with past devices.

I understand where you're coming from, but this is new behavior that will be applied to all devices with context menus (fab4, controller, anything new from here on out)

In user testing, overwhelming feedback from new users has told us that users expect tracks to play when they are selected, not to be taken into yet another menu.  This is pretty much standard behavior on almost any digital device that plays music, including cellphones, mp3 players, desktop media player applications, etc.

This is part of the point of the new context menu feature (giving us a place to put items that currently sit in that menu).

Matt, thanks for your reply. I'm just seeking clarification in this note:

1) What will the behavior be on Boom and SB3? Both have IR remotes that feature Add/More and Play buttons. Will pressing Right on an SB3 remote act just like pressing Right on a SBT remote, triggering playback of the highlighted/selected track? 

2) What will Boom knob behavior be? Will tapping the knob while looking at a track title be equivalent to Play and SBT arrow Right?

Thanks.

This is the silliest thing I've ever experienced with Squeezebox behavioural changes.

I'm not as bothered about new hardware/interfaces.

You are radically changing the interface that many have been using for many years (and I don't recall seeing any posts whinging about that functionality - only praise), for the sake of a handful of new users who won't even be buying the classic devices because they are going to be discontinued, seems harsh.

Many existing users I'm sure will be confused/unhappy when upgrading to find that right-arrow doesn't always navigate, that they may accidentally wipe their playlist and that their add button doesn't add, add-next, remove, zap track (as appropriate) anymore.

If you are going to break current functionality, I'll just make a custom map that restores the functionality (or hack the source code myself).

What I don't understand is that it has been said that accidentally wiping a playlist by accidentally playing a track is a blocker that would prevent the new release from going live.  So, as this functionality seems to be promoting that behaviour, what *is* the final functionality going to do?

(In reply to comment #4)
> This is the silliest thing I've ever experienced with Squeezebox behavioural
> changes.
> 
> I'm not as bothered about new hardware/interfaces.
> 
> You are radically changing the interface that many have been using for many
> years (and I don't recall seeing any posts whinging about that functionality -
> only praise), for the sake of a handful of new users who won't even be buying
> the classic devices because they are going to be discontinued, seems harsh.
> 

First of all, referring to the number of first-time users we are going to have starting this fall (and over the coming years) as a "handful" is simply incorrect.  

Second, this feature was not considered lightly or arbitrarily.  It was discussed literally for months before the decision was made.

We did an extensive user study last fall (which wasn't focused on this at all, but ended up giving us very good feedback about certain interactions, including this one) and took a long hard look at typical behavior of a very wide range of mp3 players, cell phones, and desktop media player software, studying how music browsing and playback typically works.

The simple truth is that, in a typical music-playing interface, when someone navigates to a song and selects it, the expectation is for that song to play, not for another menu to pop up.  There are several reasons for this, but the most important are A) since most systems work this way, it's become a convention; B) it's simply more efficient.  When I select a song, the percentage of the time I'm doing so in order to, say, view the song metadata or add the track to a favorites list or playlist, vs. the percentage of the time I'm intending to ultimately just play the song, indicates that song playback should be the primary behavior.  This is simply the law of averages.

Third, we have, for a long time, wanted to add a "context menu" (CM) feature to our system.  Not having the CM has prevented us from gracefully handling certain features, such as menu customization and many others.  The good news is that the CM allows us to put things like "add to favorites," "buy on amazon" etc in such a menu, rather than forcing everyone to go through a menu of these items each time they want to play a song.

> Many existing users I'm sure will be confused/unhappy when upgrading to find
> that right-arrow doesn't always navigate, 

This already happens in a way - If I "navigate" into the "play song" option, the music starts playing.  All we're changing is the place where the "play" behavior happens.

that they may accidentally wipe their
> playlist and that their add button doesn't add, add-next, remove, zap track (as
> appropriate) anymore.
> 

This is already an issue today (without the new behavior) - you can still destroy an edited playlist accidentally by pressing "play."  The new behavior is making this problem more glaring, but it didn't create the problem.

We are having some very passionate discussions internally about how to deal with this issue, and we're going to test a couple types of behavior to see if we can solve this problem. 

> If you are going to break current functionality, I'll just make a custom map
> that restores the functionality (or hack the source code myself).
> 

Go for it (though, respectfully, we're not "breaking" anything here - we are introducing a new feature).  One of the great features of our system is the high level of user customization we have :-).

> What I don't understand is that it has been said that accidentally wiping a
> playlist by accidentally playing a track is a blocker that would prevent the
> new release from going live.  So, as this functionality seems to be promoting
> that behaviour, what *is* the final functionality going to do?

Please see above.

Matt, thank you for the detailed explanation.

I think the sooner you put this behavior change for pre-Touch players in the trunk for 7.4, the better. Let folks outside the Touch beta see the new behavior with their older gear and give additional feedback. Clearly a number of us SBT testers would prefer that this behavior be configurable; having additional feedback from "normal" customers could help you decide if giving an option is worth the cost. 

As for the software's "high level of user customization", that really doesn't apply well to SqueezePlay & the Touch firmware. The LPSL means that some changes require a relatively high level of computer development experience, especially with the non-trivial work required to set up a build environment (compare Poky to Visual Studio and NetBeans). Without Logitech adding a config option, users who really want the old behavior will face a hardware chasm: the slim IP3K gear will do what they want, but the new fat ARM stuff won't. It will be a disincentive to upgrading hardware.

Another related UI note: it would be helpful to add a "play triangle" icon to any line when "selecting" that line with the IR remote would trigger playback. A visual indicator like that on the VFDs, and perhaps also the SBT 10' UI, could help us old timers get used to the new behavior. 

Thanks.

>First of all, referring to the number of first-time users we are going to have
>starting this fall (and over the coming years) as a "handful" is simply
>incorrect.  
>
Ah, I didn't mean handful of new users - I meant the handful of new users that were present in your focus group.  Sorry - I realise you expect to get more than a handful of new users when the product is released!

>Second, this feature was not considered lightly or arbitrarily.  It was
>discussed literally for months before the decision was made.
Indicating that existing functionality wasn't obviously a mistake.

>The simple truth is that, in a typical music-playing interface, when someone
>navigates to a song and selects it, the expectation is for that song to play,
>not for another menu to pop up.
>
For new users, perhaps that is true - the first time they try to use the device.  But do they really really object to it?  Does it prevent them from buying the product?  Do they not quickly/easily learn and understand the benefits?

It is the unique interface that sets Squeezebox products above others.  Many media playback devices don't have a current playlist (eg. iPod) - are you intending to drop that functionality because new users will find it confusing too?  Degrading the experience for existing users is not a way to win new business - recommendations from existing users is worth a lot.  Lose existing users, and you will lose recommendations, which will lose new trade.

In a typical music-playing interface, there are usually dedicated action buttons for playing the chosen item (album, song, radio station, playlist, etc).

Again, I understand the reasoning for new interfaces where there are no dedicated play buttons, but not for existing interfaces where there are buttons for this purpose.

>When I select a song, the percentage of the time I'm doing so in order to, >say, view the song metadata or add the track to a favorites list or playlist, >vs. the percentage of the time I'm intending to ultimately just play the song, >indicates that song playback should be the primary behavior.  This is simply >the law of averages.
>
But how many people select to play a single song, wait for it to finish, and then select to play another song?  It just doesn't happen like that in my experience.  Typically, Add song to playlist happens much more often than play a single track.

And in the context of the current playlist, how often is it that the user will want to play the currently playing song, or find extra details about the current song?  Clicking the middle button on the currently playing track on an iPod displays song details instead of playing the track again.

>Third, we have, for a long time, wanted to add a "context menu" (CM) feature to
>our system.
>
Existing users have called for a context menu for some time.  It's a sensible move.  Possibly not so sensible to change existing classic players such that the button called +/Add brings up the context menu though.  Better would be to bind to right-arrow.hold.

It would be sensible to have a way to customise the default behaviour of right-arrow, as several existing users have already commented on, such as how iPeng achieves this.

>> Many existing users I'm sure will be confused/unhappy when upgrading to find
>> that right-arrow doesn't always navigate, 
>This already happens in a way - If I "navigate" into the "play song" option,
>the music starts playing.  All we're changing is the place where the "play"
>behavior happens.
>
There is a difference.  Currently, the screen indicates when the right-arrow will perform an action.  Play does play, Add does add.  And those actions in the song info menu are generally superfluous as the dedicated play/add buttons can be used anyway.

There is no indication what right-arrow will do on a song title, and the functionality is changing.  At the moment when browsing music, one can drill through many layers of artist, album, song, year, genre to find something that they want to play.

>This is already an issue today (without the new behavior) - you can still
>destroy an edited playlist accidentally by pressing "play."
But there is an obvious indication that pressing play would replace what is currently playing.  There isn't an obvious indication that selecting a track will wipe what is currently playing.

>We are having some very passionate discussions internally about how to deal
>with this issue, and we're going to test a couple types of behavior to see if
>we can solve this problem. 
The existing issue has already been addressed by providing a playlist/party mode where play doesn't wipe the playlist but instead adds to it, if the user wants the device to act that way - i.e. it is optional/configurable what a play action will do.

I wouldn't want any other additional behaviour to "fix" an issue that isn't an issue for me.  If I intend to play something different, I would expect the current playlist to be wiped.  I don't want any confirmation screens, etc.

By introducing the problem of accidental playback of a single track, there may now be an additional issue to fix.

Wifi links are not all that reliable; SC may be slow if it is scanning a library, etc, so additional keypresses can occur.  e.g. A user with a dodgy wifi link presses right-arrow on an album name and nothing happens, so presses right-arrow again, they may now accidentally play a song as they didn't intend the second right-arrow effect.

I have on occasion right-arrowed too many times when navigating music, but no harm done because all I've done is navigate into an item, so all I need to do to recover is to go back with left-arrow navigation.

>Go for it (though, respectfully, we're not "breaking" anything here - we are
>introducing a new feature).
You are breaking ease of navigation.