Interface fundamental proposition.
This seems to be a point I find myself arguing more often than I'd like, so I'd like to bring up some discussion of it here so that maybe some more abstracted decisions can be made (both for moving forward and for revising some existing targets). In my opinion it's very important that certain fundamentals of the user interface remain consistent across targets so that users of Rockbox can migrate to any target easily, and learn it very quickly, as well as keeping things somewhat consistent for supporting targets that the supported is not wholly familiar with, and writing and maintaining documentations. Essentially, in my opinion, a new user of player X, who's used Rockbox before, can pick up a new player and say Ah, this is the menu button, this is the select button...etc and after having identified the buttons in one screen have a reasonable expectation as to what each of those buttons will do in the rest of core Rockbox. To me this means defining some control consistencies. For example currently on many of our targets the Select button is paired with Context Menu on long press, the Menu action is paired with the Quick Menu on long press, and Stop is paired with Power off on long press. Even on the iPods where there is no Stop/Power button, long press is stop and longer press is power, somewhat preserving the relationship. I think it would be beneficial to define some of these interface consistencies so that future buttonmaps make use of them. I have no objection to new players which have more buttons finding uses for them, and for players with limited buttons (iPods, and I hear some of the Archoses I don't have access to yet) to double up or come up with cleverer solutions, but I think that a consistent input method is quite valuable. To me there are some fundamental keys (inputs / actions / as you will) that each player has, in terms of buttons. These are: Play/Pause List Advance (Down) List Backward (Up) FFWD (Right) REW (Left) Power Menu Select Basically, four directions, Play, Power, Menu, Select. The iPods are short one of these. I think there would be a value to making at least these buttons the 'fundamental' Rockbox buttons. If a button moves down in the list, it should lower the volume in the WPS. If a button moves right or left in the menu structure, it should serve as FF/RW and next/prev in the WPS. The button that is used to select songs should banish the WPS, and a long press should be used for context menus. I know I'm a bit contentious on this point, and I apologize, but I feel very strongly that a consistency of interface among Rockbox targets is a more valuable benefit to users of the software than preserving habits of the original software. When a user moves to a new software, they expect to learn a new interface. When a user moves to the same software, with an equal set of buttons bearing most, if not all, of the same symbols, they expect the buttons to continue working between screens as they did before. I've placed a patch in the tracker for implementing some of this consistency on the Sansa (it is apparently not so popular already), but there are still some changes the Gigabeat could experience to bring it into line with this ideal (and in all honesty, the Archos Recorder too).
Re: Interface fundamental proposition.
I agree, however, I think it should be a higher priority to have the button do what it says, which is exactly the reason the REC button does nothing on most targets yet. Most users would have one rockbox target, so why do they care if the buttons are no consistant with a different target? The only people this affects are the people with more than one target which are vastly different, and even then, it doesnt take long for the brain to remember the combos for the different targets.
Re: Interface fundamental proposition.
I assume you're talking about the Power/Menu button on the Sansa. It has two labels, Power, and Menu. I suggest we use it as the Power button is used on other targets, because there's also a second Menu button on the Sansa that serves the purpose of the Menu button on other targets perfectly well. This results in a consistent interface among targets, and the only thing we ignore is that the button had a dual purpose in the original firmware. The menu-only button is the closest match to the Menu abstraction, and the Power/Menu button is closest to the Power/Stop abstraction. yes, but If what you want to do happens, the power/menu button (which is probably the easiest button on the thing to press) becomes almost never used. I agree that some consistancy should be there, but I dont think that making one target less user friendly for the sake of this is a good idea.
Re: Interface fundamental proposition.
I think a very, very minor inconvenience (as I think this is) is not a high cost for actual consistency of the interface. I find it much, much easier to operate the device with just my thumb now relative to how it was before, and I think a right-handed person will find it only very very slightly less convenient. Meanwhile, with the old layout my thumb had to bend at a somewhat uncomfortable angle. So, by your own argument, my way is better, at least for convenience for all users (rather than to one group). So it increases user friendliness overall by making it usable to a group that had a hard time before, at a minimal cost to the other group. But even moreso, as I said, it offers consistency of interface. Learn once and you're done. If we only had one menu, rather than two, I find it likely the main menu would go on the bottom button rather than leaving that button empty, but because we have two, the main menu has gone to the power button, and a secondary menu goes on the larger, more central button.
Re: Interface fundamental proposition.
Paul Louden wrote: I think a very, very minor inconvenience (as I think this is) is not a high cost for actual consistency of the interface. If you only own one Rockboxed device, you couldn't care less if it is consistent with other Rockbox targets. You want it to work in the best and most convenient way possible on the target you use. Linus
Re: Interface fundamental proposition.
My brother recently got a Sansa and I put Rockbox on it for him this weekend. There are some different things that I find inconsistent with other targets, but it is not a bad choice of use for the buttons. I expected the context menu on a long press of Select, too. But the Sansa has a second menu button (the ON button is the first). It is very convenient to have the context menu on a short press, I could adapt to this quite fast. The quickmenu on the other hand doesn't feel right to me. I agree with Llorean that there should be a core of buttons that is the same on every target. But for me the core is only cursor movement, menu, select, play. It is possible to use (almost) every feature of Rockbox with only these buttons. Everything else should be mapped to buttons that feel natural for a certain target. When there are buttons with a function in the original firmware that we can use for the same purpose, then we should do this, but only if it makes sense in the context of Rockbox. A good example is the Sansa context menu button. An example where we don't want the original button use is the A-B button on the IRivers. My position on the Rec button is clear, I don't want to repeat it here. Only one addition: The use we find for the Rec button in the Iriver could (and should, imho) be applied to the Sansa, too. -- Rincewind
