Rockbox General > Announcements

Sansa e200/e200R: Keymap change.

<< < (2/9) > >>

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.

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.)

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.

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:

--- Quote from: BigBambi on November 04, 2007, 05:13:13 PM ---It is unimportant which physical button is A or B.

--- End quote ---

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.

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.


[0] Message Index

[#] Next page

[*] Previous page

Go to full version