Sansa e200/e200R: Keymap change.

[Llorean]

To give warning, I'll be committing this patch (in its original form) this coming weekend: http://www.rockbox.org/tracker/task/7232

It makes a few changes to the Sansa keymap which allow more functions to be accessed with less finger movement, increases the consistency between screens on-target, and increases cross-target consistency.

The mapping may feel slightly awkward to those of you used to the original firmware. but it conforms better to some UI aspects that tend to be preserved between Rockbox targets. If there are any problems with this patch (other than "I don't like it", as I'm looking for objective objections) feel free to post here or in the task before I commit it.

[zajacattack]

Here's my two sense:

(1) I like how Play/Pause stops playback. To me, logically, play starts and pause stops.

(2) The menu button and context menu button could be swapped easily; not a big deal to me.

(3) Select does have a function. While playing music, pushing it will return you to the last menu you were at. I do, however, think this should be changed to the menu button (bottom).

[Llorean]

To address your points:

1) Stop is DIFFERENT from Pause. Play/Pause will still Pause. The presence of a "Stop" button is important to clear the playlist, as well as to allow voice playback to function while music is stopped (it cannot function while Paused currently, only while Playing or Stopped)

2) Okay

3) I never said "Select" doesn't have a function. Long Select (holding it down) currently doesn't, but will with the patch.

As I've said, many times and in many places, please TRY the patch before commenting. Point 3 would've been apparent to you, and probably point 1 as well had you tried it out.

[zajacattack]

OK, I'm very sorry, I did not understand. Now, I think I see the purpose of this patch, and I'll try it out later today when I update (it was committed).

[zwaldowski]

While I understand that Rockbox is a multiplatform project, and it should be consistent on those platforms, shouldn't the buttons that have meaning printed on the case be used?  What I mean is, why shouldn't "play" mean "play" and power/menu take you to the menu and power it off.  It's not just a matter of those used to the OF, but rather those who can see their actual case.  To tell you the truth, I'm upset about it, but I guess we'll see.

[AlexP]

As someone who has multiple rockbox targets, in my opinion what is important is that the same button performs all the same actions within rockbox between different platforms.  Which button that is is not important.

I'll try and explain like this:

If on platform 1, button A performs action W in WPS and action X in the menu, and button B performs action Y in WPS and action Z in the menu, then on platform 2 the same should be true.

It is unimportant which physical button is A or B.

Where problems come is when on platform 2, button A performs action W in WPS and action Z in the menu, and button B performs action Y in WPS and action X in the menu.

All I should have to learn is which physical button is button A and which is B, not that button A and B change their function across platforms depending on what screen you are in.

As it happens (although I don't have a Sansa), it looks like these changes also improve the ability to operate one handed.  I would strongly urge you to try the new keymap before getting upset.

[Llorean]

The ONLY conflict with what's printed on (or in this case "near") the buttons is that the Power/Menu button is used solely for power, while the OTHER menu-ish button (it has no text, but several lines that could represent any sort of list) is used for the menu now.

The play button still performs the Play/Pause function just fine.

And yes, this does take a step toward what BigBambi described, though it's not going to be the first priority in any changes, it's in my clear opinion a goal when you have a choice between subjectively equal maps. (In this case, I feel there are also objective advantages to this map.)

[Rincewind]

Obviously it is too late now to complain  

Anyway. I liked the previous keymap better, because I am not a fan of holding buttons to get actions. It slows things down.
This means another small patch in my personal build to revert this change. If anyone is interested, I can put it on flyspray. But I don't think it's needed, a diff can be obtained through svn.

[zwaldowski]

Fair enough, I'll try it.  I bet I'll end up liking it, but I'll only like it fully when I don't have to remember how to use the OF at all.  

However, I disagree with this statement:

It is unimportant which physical button is A or B.

There are two ways in which you are wrong:
- The "other user" factor.  Imagine a family member asks to use your PlayStation.  The screen says, "Press X to jump," but triangle in fact is the jump function.  That does not make sense; either the software or the hardware should change.  In other words, I'm asking you to look at this from a user viewpoint, not a power user/developer point:  How do I know what to press?  I won't look at the manual, so I'll just see what's on the case.
- The button problem.  You say it is important to have similar buttons no matter the target, however, unless you're using a similar line of products, the buttons will be different no matter what you use.  I know for a fact the Sansa e200's menu button is nowhere similar to the one on the iPod Nano, nor as on the iRiver.

So, active like Joe User, and you don't know what the buttons do, what else do you look to?  The buttons themselves.  You wouldn't click on the picture of a globe and expect your word processor to open; it's all about the metaphor.

All in all though, it doesn't look like too much of a problem now that it's been enumerated entirely, I'll check it out.

[Llorean]

What he means is that if a button is labeled "A" on the gigabeat, and "weird lines" on the sansa (note: these buttons serve different functions in SVN, this is just a hypothetical), if we chose "A" to go to the menu on the gigabeat, and "weird lines" to go to the menu on the Sansa, then what they both do once you're IN the menu should probably also be the same.

If you pick up ANY mouse, once you learn which button is "left click" and which button is "right click" (even if they're not on the left or right, in the case of odd input devices) you know what they'll do everywhere, because left click is consistent across the whole OS.

While this isn't possible on every player, everywhere, where it doesn't *impair* use, following this philosophy is beneficial, because it creates a sort of internal consistency. You can tell someone, when giving support, "press the button that resumes playback" and have a reasonable expectation of it working even if you have no idea what the physical layout of the device is, because you know that hopefully someone picked a reasonable button to resume playback, and the button that resumes playback also generally serves this other functionality they were asking about.

So, I think what he means by "it doesn't matter which physical button is A or B" means "They can pick whichever button is most appropriate to be A or B by player, but once they have, it should STAY A or B between screens, rather than in some screens being A and some screens being B, *unless* there is reason why staying consistent across screens impairs use."

@Rincewind: I announced it in the mailing list and here in the forums a week before committing, and there was lots of time to complain. Honestly, the only new thing that needs held down to access is the context menu, and for some people having it there improves usability (in my case vastly), so it's purely a subjective thing. As for posting it on the tracker, please don't. As has been said, many times, the tracker is for things that should be candidates for inclusion.

[AlexP]

Llorean:  Yep, that is exactly what I meant.

[scharkalvin]

Not all players have the same number of controls so some doubling up is required on some players to get the needed number of 'inputs'.

For example the ipods and the sansa have 5 buttons and a scroll wheel, but the sansa adds a power button.  This gives the sansa two extra inputs (press power and hold power).  The Gigabeat has 5 buttons on the front, 3 on the side (menu, power, "A") but no scroll wheel (though it DOES have the volume up/down).  Some of these buttons are duplicated by the wired remote control with actually works under rockbox!

I think the idea of mapping the player controls in a similar manor has it's merits and I support the idea.  The Sansa and Gigabeat players are similar enough, the iPods are the problem having fewer mappable inputs.

[AlexP]

Not all players have the same number of controls so some doubling up is required on some players to get the needed number of 'inputs'.

I'm aware of this, and yes the iPod are a problem.  The gigabeat, iriver H1x0, H3x0, Sansa etc are fine.  However where physically possible, consistency between targets should be maintained (IMHO).

Some of these buttons are duplicated by the wired remote control with actually works under rockbox!

What do you mean, actually working like you are surprised?     The LCD remote, screen and all, on my H140 has been working in rockbox for years!

[scharkalvin]

What do you mean, actually working like you are surprised?  Grin   The LCD remote, screen and all, on my H140 has been working in rockbox for years!

My first impression of the Gigabeat remote hardware was that it must have used an undocumented serial protocol and I did not expect it to work with rockbox.   (compared to the H140 isn't the Gigabeat a newcomer?)   Also, only the F40 and F60 were shipped with this gizmo, I would have assumed that most of the rockbox porting work would have been done on the F10 and F20 units (as they were probably more available at the time).

[GodEater]

Also, only the F40 and F60 were shipped with this gizmo, I would have assumed that most of the rockbox porting work would have been done on the F10 and F20 units (as they were probably more available at the time).

Our experience has been that the F40 is way more prolific than any other model...