flipBX - Gaming buttons (non-)standardization on Pyra

[PokeParadox]

B and X are only used for enter and escape type actions on game consoles because they have limited controlers.  It makes sense for emulators to use those as the consoles they reflect.  

However, it's rather nuts to even consider those restrictive conventions in any software designed for a full keyboard device - let alone a  primary software distribution platform.

You guys are all arguing over X vs B.  They're both wrong.  It's a handheld computer with a full keyboard that can run emulators.  Why should we be pretending that it doesn't have a keyboard?  Unless you're in a game, those buttons are page down and end.

What's nuts is forcing the user to press the keyboard buttons when a "standardised interface" could be used. Your points makes sense in the context of a desktop PC or laptop as you do not know that any gaming controls exist. What many are saying here that a standard button A for accept and B for Back in terms of navigating a menu system make sense in terms of a device when you know it has a specific set of features. Keeping the interface as consistent as possible makes sense to the average user more than "breaking the flow" simply because an application is not a game. It make sense especially in applications written directly for the system as opposed to ports. Again that's not to say that the keyboard cannot also be used... of course it can! Choice is a good thing. So is trying to standardise the interface.

 

[Grench]

I would use page down to scroll the listing of applications down 1 page rather than restricting to single down actions.

Enter to select.  Escape to back out.

It is an application download listing for a computer.  It has always bugged me that it looks and acts like an emulator's rom selection menu.

Please continue. You have defined alternatives for two of the buttons. Six to go (A, Y, start, select, L, R).

OK.

Move cursor with arrow keys.  Check.

B Yes, more, next. Use Enter.

A No, remove cancel.  Use Esc or Backspace.

L Change mode left.  Use home/A.

F1 show help/hints.  Check.

Start/at sync to server.  No - use an Fkey or letter, not a press release of alt modifier.  S would work.

B back.  Silly to have yes and back the same.  Esc or backspace or the 'B' letter key would be potential logical alternatives.

Y install/upgrade.  Why this instead of navigating to confirmation with arrow keys to 'Install' and presting Enter?

R Change mode right.  Use end(B).

Select/ctrl change package sorting. 'C' for change or 'P' for package would work.

What possessed the author to avoid using any key under the Pandora's center line and instead coopting modifiers (alt&ctrl) and moving page left/right navigation (home&end) to shoulders?  It's a long way to go to avoid admitting it's a full keyboard computer.

 

[Christoph.Krn]

B and X are only used for enter and escape type actions on game consoles because they have limited controlers.  It makes sense for emulators to use those as the consoles they reflect.  

However, it's rather nuts to even consider those restrictive conventions in any software designed for a full keyboard device - let alone a  primary software distribution platform.

You guys are all arguing over X vs B.  They're both wrong.  It's a handheld computer with a full keyboard that can run emulators.  Why should we be pretending that it doesn't have a keyboard?  Unless you're in a game, those buttons are page down and end.

...views and opinions aside, PokeParadox already said it, the Pyra won't be a regular computer. It does have physical gaming buttons. The reason that there are numerous non-game PNDs which do use (B) and (X) is that there are many, many people who want it that way.

flipBX is an idea that's based on the reality of how buttons are being used. If you disagree with it, that's fine, nevertheless you're probably not going to be much more happy here in either case, with or without flipBX. The really important aspect is that flipBX is an optional thing, and any software authors who want to use buttons in a more desktop-computer-like fashion in non-gaming applications can do so, but judging from the available Pandora software, not many authors think that that would a sensible thing to do in applications that are specifically made for Pandora(/Pyra). And I agree.

But please don't misinterpret this, I absolutely do understand where you're coming from, I have been talking about the importance of the regular desktop on the Pandora as far as five-ish years or so ago. I agree that there are problems about this aspect still, but while I don't yet have any sensibly good proposals for solutions that would retain flexibility and openness, I don't think that flipBX is going to make any potential future solutions to these problems any more difficult, probably rather the contrary. I will be trying to resolve these remaining problems on the Pyra in the future all the same. Again, for this purpose I'm really interested in hearing a more detailed breakdown of your PNDManager usage (you can also send me PMs about this if you want).

 

Further: I think it makes sense to have some documentation of "de-facto standards" available for developers at launch, which also includes recommendations for other buttons (like some sort of Pyra-Button-sequence to instantly exit a program, ESC as default exit button, a home button, button for emulator menu, etc. - whatever makes sense or is used in many applications). This might be a whole different topic though.

...I'd appreciate your comments on "Escape path key" and "Menu buttons" metadata in DBP as an alternative (preferrably over in that thread or via PM).

 

[levi]

I was a little put-off to begin with that I could navigate the XFCE menu using the Pandora button, then the d-pad, but I had to switch to the keyboard area to actually select anything.  For the first week or so of use, I instinctively pressed B, and ended up jumping to the end of the list instead of selecting the app, which was doubly annoying.

I've not had that problem since, but it might be friendlier if the XFCE menu controls could be adapted in the same way.  Only problem is, those game buttons do have keyboard codes which are valid ways to navigate a menu.  I personally would never want to go to the end of a menu listing in a single jump - pressing page down twice would be more than enough for me, but perhaps not everyone has as short menus as I do.

 

[bzar]

Move cursor with arrow keys.  Check.

Check.

B Yes, more, next. Use Enter.

So far so good.

A No, remove cancel.  Use Esc or Backspace.

So backspace for remove and esc for cancel? Kinda iffy when you consider you can filter lists by typing and you need backspace to erase the filter, while it's also entirely possible you can remove something from that list or cancel downloads.

L Change mode left.  Use home/A.

Wait, so now Home isn't Home? If I'm on a list of applications shouldn't Home by your system go to the top of the list or the end of a focused text box? How can it also change modes?

F1 show help/hints.  Check.

Check.

Start/at sync to server.  No - use an Fkey or letter, not a press release of alt modifier.  S would work.

Fkey isn't too bad, though again it puts central functionality behind a modifier. S isn't really possible since you couldn't use it while filtering lists, writing comments or entering search words.

B back.  Silly to have yes and back the same.  Esc or backspace or the 'B' letter key would be potential logical alternatives.

B isn't back. X is back. Unless you have set flipBX in which case they are the other way around. I'll assume you meant X and continue. Again, using letters or backspace isn't really a good option because of previously stated reasons. Esc is fine, though it kinda clashes with what you put in place of A here. X (without flipBX) is a "safe button" that should always be safe to press. A is pretty much the antithesis of a "safe button" as it cancels downloads and removes packages.

Y install/upgrade.  Why this instead of navigating to confirmation with arrow keys to 'Install' and presting Enter?

Because cursor navigation in a touch-oriented interface is pretty much always horrible. Not having to do mental gymnastics to figure out how the focus moves between non-gridded elements is a central theme in this UI. Look at the action you want to accomplish, push the associated button or tap the screen. Very direct and convenient.

R Change mode right.  Use end(B).

Again, shouldn't end go to the end of a list or text box?

Select/ctrl change package sorting. 'C' for change or 'P' for package would work.

Again, using these either adds extra steps to using the functions or clashes with other functionality

What possessed the author to avoid using any key under the Pandora's center line and instead coopting modifiers (alt&ctrl) and moving page left/right navigation (home&end) to shoulders?  It's a long way to go to avoid admitting it's a full keyboard computer.

Convenience of use. The game buttons are at the best possible locations to be used for the most common operations.

 

[_jr_]

XFCE controls can't be adapted to gaming controls in any meaningful way, because one would lose the functions mapped to those keys which are important inside the XFCE environment. As Grench said, it only makes sense for applications that don't have any text field or other navigation at all. PNDManager is a good example because it is somewhat in the middle: it mostly works fine, but it has text fields in the comment editor. Not being able to use shoulders /action buttons as modifiers/navigation keys is quite a tradeoff.

Still I'm in favor of flipBX, because it doesn't make anything worse.

 

[Grench]

Move cursor with arrow keys.  Check.

Check.

B Yes, more, next. Use Enter.

So far so good.

A No, remove cancel.  Use Esc or Backspace.

So backspace for remove and esc for cancel? Kinda iffy when you consider you can filter lists by typing and you need backspace to erase the filter, while it's also entirely possible you can remove something from that list or cancel downloads.

L Change mode left.  Use home/A.

Wait, so now Home isn't Home? If I'm on a list of applications shouldn't Home by your system go to the top of the list or the end of a focused text box? How can it also change modes?

F1 show help/hints.  Check.

Check.

Start/at sync to server.  No - use an Fkey or letter, not a press release of alt modifier.  S would work.

Fkey isn't too bad, though again it puts central functionality behind a modifier. S isn't really possible since you couldn't use it while filtering lists, writing comments or entering search words.

B back.  Silly to have yes and back the same.  Esc or backspace or the 'B' letter key would be potential logical alternatives.

B isn't back. X is back. Unless you have set flipBX in which case they are the other way around. I'll assume you meant X and continue. Again, using letters or backspace isn't really a good option because of previously stated reasons. Esc is fine, though it kinda clashes with what you put in place of A here. X (without flipBX) is a "safe button" that should always be safe to press. A is pretty much the antithesis of a "safe button" as it cancels downloads and removes packages.

Y install/upgrade.  Why this instead of navigating to confirmation with arrow keys to 'Install' and presting Enter?

Because cursor navigation in a touch-oriented interface is pretty much always horrible. Not having to do mental gymnastics to figure out how the focus moves between non-gridded elements is a central theme in this UI. Look at the action you want to accomplish, push the associated button or tap the screen. Very direct and convenient.

R Change mode right.  Use end(B).

Again, shouldn't end go to the end of a list or text box?

Select/ctrl change package sorting. 'C' for change or 'P' for package would work.

Again, using these either adds extra steps to using the functions or clashes with other functionality

What possessed the author to avoid using any key under the Pandora's center line and instead coopting modifiers (alt&ctrl) and moving page left/right navigation (home&end) to shoulders?  It's a long way to go to avoid admitting it's a full keyboard computer.

Convenience of use. The game buttons are at the best possible locations to be used for the most common operations.

Home is beginning of line OR page left if already at the start of a line in a 2d page grid.  Just as End is end of line OR page right.  To coopt those keys and then remap their functions to the shoulders is silly.

See PND Manager startup screen.  The (B) game key is listed exactly as I stated above with two seemingly conflicting purposes.

Don't get me wrong,  I really do like the application and it's functional capabilities.  I use it as an example in the (B) vs (X) discussion as it is the only application I am aware of that has built in ability to flip them.  The issue that I have is that there is a silly tendency to treat the Pandora interface as if it were an old Nintendo controller.

Proprly set up witwith enter or 's' to select 'search' and enter to submit the string, there is no conflict.

The appliction designers have license to configure as they see fit.  However, unless the application is emulating the function of a limited key gaming controller and console, why go there?  At a Pandora/Pyra application level, it IS a computer with a fully capable keyboard and should follow those conventions.

 

[Christoph.Krn]

PrimaryMenuButton or MenuOKButton with possible values "B" and "X" seem self-explanatory to me. It has the added benefit of being somewhat clear on which actually is the primary button. FlipBX naming in PNDManager was short-sighted . I assume the default value (when no value is present) is "let application decide"?

Those names would be neat to use in code, but compared to "flipBX" they're not as clear about the underlying idea/concept, which might be bad. Ideally, the name should fulfill both of these requirements. (Plus, of course, the requirement that it should be evident that this is only for menus).

When no value is present, it's whichever of the two "flips" is the software author's preference. For all applications where the author preference for menu controls is a different set of buttons, and not on (B) and (X), flipBX support was advised against in the first place.

 

[bzar]

Home is beginning of line OR page left if already at the start of a line in a 2d page grid.  Just as End is end of line OR page right.  To coopt those keys and then remap their functions to the shoulders is silly.

So to move to the next tab, you first need to move to the end of a package list? That's... not very intuitive nor practical.

See PND Manager startup screen.  The (B) game key is listed exactly as I stated above with two seemingly conflicting purposes.

I'll check, but unless you have set flipBX I can't recall where it would be used like that.

Don't get me wrong,  I really do like the application and it's functional capabilities.  I use it as an example in the (B) vs (X) discussion as it is the only application I am aware of that has built in ability to flip them.  The issue that I have is that there is a silly tendency to treat the Pandora interface as if it were an old Nintendo controller.

Yes, I added the option pretty much to function as a base for this conversation. It's a widely used application and if it found use there it could be a good idea to make the setting global.

Proprly set up witwith enter or 's' to select 'search' and enter to submit the string, there is no conflict.

You're adding state to the UI where none is needed. Making every action more and more key presses to achieve.

The appliction designers have license to configure as they see fit.  However, unless the application is emulating the function of a limited key gaming controller and console, why go there?  At a Pandora/Pyra application level, it IS a computer with a fully capable keyboard and should follow those conventions.

Because it gets you where you want to be in the least amount of input using the controls most comfortably reachable by your fingers. It's pretty much why vim works so well too; the difference is what controls are the most naturally available to your fingers. When you give someone a Pandora to hold, they don't- in my experience -rest their thumbs on the keyboard. They rest them on the game controls. This is natural because of the weight distribution and obvious ergonomic considerations.

 

[Christoph.Krn]

As far as a more self-explaining name is concerned, how about "menuBXIsFlipped"?

 

[Christoph.Krn]

If nobody has any objections, this will then be either (or none) of these lines:

menuBXButtonsPreference=kyoto

menuBXButtonsPreference=tokio-western

...in approximately the following file as discussed previously (please make sure to use $XDG_CONFIG_HOME correctly) (Also note https://pyra-handheld.com/boards/th...dardization-on-pyra.75863/page-2#post-1340793 ):

~/.config/pyra/input

 

[levi]

Ah, after about the third reading of this, I think I understand what you mean now. I'd have gone for Nintendo vs. Sega, but I can see why you wouldn't use that