Parentheses format for button labels


Christoph.Krn

Christoph.Krn

Advanced Member
Joined
Mar 17, 2009
Messages
2,119
Location
Germany
----- BEGIN UPDATE 2015-01-04 -----

This post has been found to be misunderstandable.

What I'm suggesting here is to use (A), (Y), ( B) , and (X) as labels *on the physical buttons of the Pyra* (including the parentheses). This is specifically in the hopes that it might increase the chances of future documentation becoming better at separating between keys and buttons (plus of course, these labels are ASCII-compatible, and backwards-compatibile to Pandora-software). Due to my phrasing, this post could easily have been misinterpreted as me suggesting a certain way in which everyone should be referring to gaming buttons from now on, which is _NOT_ the case.

My apologies for the misunderstanding, and a "Thank You" to Saber for the feedback.

-- Christoph "Christoph.Krn" Körner

(Originally announced at http://boards.openpandora.org/topic/17413-parentheses-format-for-button-labels/?p=369351/URL] on 2015-01-04)

----- END UPDATE 2015-01-04 -----

(Introduction: On the Pandora, for each of the button labels "A", "Y", "B", and "X", there are TWO buttons on the device (one gaming button and one keyboard key), which is not a GOOD THING™. There has been a lot of discussion about improved labeling of the Pyra's gaming buttons in the past months, and many suggestions were made, which all have their own benefits and shortcomings. See the end of this post for a list of reading material.)

I'm suggesting yet another kind of gaming button label, the "Parentheses Format". Notably, the parentheses format has the following benefits:

  • It's ASCII-compatible
  • It's backwards-compatible to existing Pandora (and GamePark-device) software
  • It does _not_ equal the usual one-character labels "A", "B", "X", and "Y" traditionally found on many gaming systems
  • It's commonly thought of to be intuitively understandable as referring to gaming buttons (as opposed to possibly being understood as referring to a keyboard key with the same letter) by many people in many situations
With this format I did _not_ attempt to solve a specific subset of problems in a perfect way. Instead, I've turned around the process of finding labels. Instead of trying to come up with "better" button labels first and then figuring out their advantages and disadvantages, I looked around to find out how users of the Pandora are successfully communicating around ambiguity in button labels today. Apart from things such as calling the keyboard keys keys and calling the gaming buttons buttons, there is one practice which stood out because traditionally it has been common and understandable enough that many are not even thinking about it anymore: the practice of enclosing the label character in parentheses ("(" and ")") to indicate that an instruction refers to a gaming button (as opposed to a keyboard key).
Example:

Press (A) to download, press (Y) to reload, press B to reset input mask, and press Q or Esc to Exit.
Click to expand...
So, the parentheses format gaming button labels for the Pyra would look like this (including the parentheses):

( A ) ( Y ) ( B ) ( X )

... and then something roughly along the lines of ( I ) ( II ) for the two new buttons.
Known problems of this format:I welcome anyone to discuss this proposal. If you believe that this matter is not important enough to warrant Yet Another Buttons Thread, then please note that it is known to have caused some problems on the Pandora (Why?). Note also that the Pyra's keyboard labels are about to be finalized/URL] now, and be informed that I value all kinds of feedback, positive and negative.

-----

Additional reading resources (if you think there's something missing in these lists, then please do contact me):

Some earlier discussions involving the gaming buttons:

Additional reading on keyboard layouts for Pyra:
 
Last edited by a moderator:
At the beggining, I was using parenthesis also to label button (for the Pandora), but on the the board, the B button transform itself to  B) so I stopped using () and used {} instead...
 
I'm sure the board software could easily be adjusted to transform (A), ( B) , (x), etc. into pictures of the buttons or just leave them alone. Maybe that B) would need to go...
 
Last edited by a moderator:
LineOf7s said:
One's a button, one's a key.

Press the A button. Press the A key.

Ta-dah.
Click to expand...
Saber said:
LineOf7s solution is a fine one, [...]
Click to expand...
This approach (calling keys keys and calling buttons buttons) is mentioned in the original post.
It's too unreliable an approach in the sense that too few people are actually making this separation. Or, to phrase it differently, if this /was/ a reliable approach, then this aspect of the gaming buttons would never have been considered a problem on the Pandora. It's not possible to just say "Everyone, please write better documentation." and consider the problem solved, because it doesn't work that way.

Saber said:
[...] we've been down this well traveled road before:

http://boards.openpandora.org/topic/15736-action-button-labels/?p=324316
Click to expand...
I know. I'm making another suggestion now because I'm convinced of it. As far as I can tell, this specific suggestion wouldn't really have a negative impact on anything, but would increase the chances that documentation and non-native or ported software would become more usable. Now I'm waiting for anyone to prove me wrong.
 
Last edited by a moderator:
I don't see it as a solution to the problem, for the reasons outlined in the first post.

I do think it works well enough as a documentation convention though, or it would if not for the B) smiley on the boards.

That said I think T4b's suggestion could possibly fix that, by adding a smiley for each button code that substitutes the relevant guihints image. (hopefully with a smiley defined for ( B) , the B) smiley would not be triggered)

- Neelix
 
Neelix said:
I don't see it as a solution to the problem, for the reasons outlined in the first post.

I do think it works well enough as a documentation convention though, or it would if not for the B) smiley on the boards.
Click to expand...
That's kind of the point. With parentheses being on the buttons, chances are that authors of written documentation will actually use this system in a consistent manner, or so I would guess.
But I also do think that with more consistent usage of parentheses, if, for instance, a ported game said something like "Press B to foobarize", it would be more understandable for a majority of users, though this is just an educated guess.

(PS: You've mentioned "guihints smileys" before, here's my opinion on guihints smileys again.)
 
Last edited by a moderator:
My original post of this thread has been found to be misunderstandable.

What I'm suggesting is to use (A), (Y), ( B) , and (X) as labels *on the physical buttons of the Pyra* (including the parentheses). This is specifically in the hopes that it might increase the chances of future documentation becoming better at separating between keys and buttons (plus of course, these labels are ASCII-compatible, and backwards-compatibile to Pandora-software). Due to my phrasing in the original post of this thread, it could easily have been misinterpreted as me suggesting a certain way in which everyone should be referring to gaming buttons from now on, which is _NOT_ the case.

My apologies for the misunderstanding, and a "Thank You" to Saber for the feedback.
 
Ascii compatible doesnt mean anything. Nobody (in their right mind) is fixing 1982 software to feature updated mapping, that is all done in 2015 software.

Gamepark and pandora software isnt compatible with armhf debian. Which means you have to do it again anyhow, right or wrong.

I think referring to (A) as the A button is good, i dont think putting ABXY on the gamebuttons is good, because there are two competing standards, (none of which are old gamepark or pandora.)    ABXY    and   BAYX

Lets say there are 10k active users of BAYX, that also use BAYX in BAYX games. Huuuuuuugely inflated number, but for case of argument. Nintendo and Xbox sells that many systems in the scope of an hour, and you can be sure a lot of it is to _those same people_...

And who is buying a pyra, its those same people...!  Now is a perfect time to stop the madness. If you _dont_ continue it, BAYX dies without angering anyone. Nothing relies on BAYX.

Static ABXY inscriptions that adhere to one of the two standards on the buttons doesn't just mean you are wrong half the time, it means its _confusingly_ wrong. That is worse than _no_ marking...   Shapes make way more sense than most things once you get the hang of it.

Also ABXY, for this reason, is hard to learn, and in itself not something that has meaning, or value. Deriving a diamond pattern from an A B pattern stops making sense when its sometimes B A.

It has nothing to do with direction, so you dont know where A is, and if it did (which is classical conditioning) it would be confusing because half of it is directly contrary. A third way of doing the same adds to this confusion.  It is ok for nintendo to do it, because they only run nintendo games. Its ok for sega and everyone else to do it differently, because they dont run nintendo games. It is _not_ ok for the pyra to do it, because it wants to be a jack of all trades. Even computing, which brings us to the next point.

Similarly, ( I ) ( II )   has no distinction as to where ( I ) and ( II ) is.  Thats the whole  start select  or select start all over again.  Also the amount of buttons is limited, so ( I ) and ( II ) should have some kind of combo use. But ( I ) explains nothing that i can connect to function.   Desktop 1, desktop 2?  I dont know, but _have a plan_.
 
Last edited by a moderator:
Christoph's idea is interesting. The (A) for button A notation came about as an ASCII representation of a round button around the inscription 'A' I assume, and it's quite a cute idea to recycle that and actually _print it on the button_.


As noted above, the forum software does blow that two counts against it: that a B followed by a close bracket comes out as B) (so B in brackets appears as ( B) ). To avoid that you can put spaces within the brackets, but then there's a danger the forum will split the brackets across a line break, which personally I can't stand. It doesn't seem to matter if you use upper case or lower case, which is odd for that particular smiley I'd suggest. Monocle?


Using that notation in game software might also pose problems. What was one character now becomes three, so it might break rendering (although half the time, I suspect when porting from PC we might be changing Space or Shift to (A) or (X), so actually it's still shorter).


I dunno, it's still a neat idea I'm generally in favour of. It does nothing to resolve the problems of the layout being not like the systems we're emulating (although since it can't be like playstation *and* SNES *and* Sega at the same time anyway...) and (my own personal bugbear, it seems) that the A button being in a secondary position means the layout explicitly encourages developers to use a secondary button as their primary control - those are tangential problems. And of course, it doesn't apply if we don't end up with characters on buttons in the end.


Here's my refinement to the idea: print lower case letters on the buttons with parentheses: (a), (x), etc. And fix the forum so that (b ) doesn't, without the space, turn up as ( B) . Or print some weird symbols - although it seemed nobody's suggestion for symbols could gain enough support to beat ascii characters.
 
Last edited by a moderator:
Doing  [A] [X] [Y] or some variant thereof to mean physical buttons is something that has merit and has been working well for that purpose. 


 


It is however _not_ something that gives merit to printing  [A] [X] [Y] or some variant thereof on the actual buttons.


 


Imagine if there were two sets of notes in the world, the A G H F  etc notes, and then   G A F H notes. Any musician would, given the total ambiguity of the instructions get annoyed.


 


Because they know how to play, they know both systems, but they can _never_ tell an  A from an A.


 


The best system for learning motorical skill is position, without that, you arent learning anything but a quicker way to decipher with parts of the brain you shouldnt be using.


Which is how bad systems turn people onto learning position.  Because it picks up on something you know something about, and applies it to something you have a harder time learning because of it.


 


Imagine if ←→  was   L  R, it is, and for germans and brits thats ok enough. In norway its V H, still no problem.


 


BAXY layout is that miniscule little country that came along after the others, and developed a word beginning with L for right, and R for left. Just plain old suffering.


 


And even though L for right and R for left is the official standard, the country is riddled with variants, because it never really caught on.


And even though that country changed its system, there is another country, the pandora country that adopted it, and some people seem stuck in the ways of pandora-country, even with the other country now being gone, leaving no legacy behind, just like the pandora country could do now that its going to be the pyra country.   OUYA!
 
comradekingu, I was not implying any specific arrangement, my apologies if it seemed so. I don't see any reasons why the basic order shouldn't be the same as on the Pandora. However, the fact that different manufacturers are using different game button setups, and that in specific situations, the physical location of a specific gaming button is much more important than its label, is a valid problem indeed. If you want to discuss that, then please feel free to join the discussion on guihints (or, of course, to open a separate thread on the issue).

As for ASCII compatibility, even if we assumed that ASCII compatibility wasn't relevant to software authors in terms of how the user interface of a software is being implemented, then we would still have to take into account a desire for writing robust documentation. (That being said though, it's not unusual for certain types of games to have a surprisingly limited set of characters. Everything else can make things surprisingly cumbersome, especially for single developers, at least for certain types of games. Then again, I have not spent a significant amount of time on game development for quite a few years now, so anyone please correct me if I'm mistaken.)

Levi said:
[...] the forum software does blow that two counts against it: that a B followed by a close bracket comes out as B) [as an image file that depicts a "Sunglasses" smiley, remark Christoph.Krn] (so B in brackets appears as ( B) ). [...]
Click to expand...
That shouldn't be a showstopper. Invision Power are claiming that "Flexibility & Choice" is one of their four aims for their board software. If there not already is some way of configuring this behavior on a more general level, then I can not imagine that they wouldn't add a configuration option.
 
Last edited by a moderator:
Indeed. Did you note my suggestion? :

Here's my refinement to the idea: print lower case letters on the buttons with parentheses: (a), (x), etc. And fix the forum so that (b ) doesn't, without the space, turn up as ( B) .
Click to expand...
To my mind, it doesn't make sense for 'b )' to appear as the sunglasses smiley. But 'B )' has been the sunglasses smiley for a good few years, even before graphical emoticons, so ideally that should remain the case. By making the letters lower case we can keep 'B )' to mean sunglasses while leaving '( b )' to be printed on the buttons and referred to as such.
 
Are we seriously letting a smiley decide the way the game button is printed now?

Having an official way to display game buttons within the ascii charset seems like a sane idea, especially considering spritefonts in games often not supporting even anything else than that, but in most cases definitely no rarely used unicode symbol for a button.
On the boards however, this is not an issue. Special smileys can be set up for that if really needed or the  B) could be changed to : B) :, as many other smileys are set up on these boards already.

I personally don't even like it when fine looking text smileys get replaced by images automatically as opposed to having special character sequences as placeholders which won't be typed in so much (most who expect graphical smileys use button in the post editor anyways). But that's just me, I guess.
 
Sorry about that, but how did being able to represent in ASCII mean that ABXY was a good idea? There seems to be a disconnect there. There are uglier things that cant be solved with the prospect of using ABXY.

There are plenty of other options that can be represented in basic writing too.
 
Last edited by a moderator:
comradekingu said:
Sorry about that, but how did being able to represent in ASCII mean that ABXY was a good idea?
Click to expand...
This way, any software and documentation that was originally written with the Pandora in mind will be compatible to the new layout.
May I ask, do you think that that's not so important?

elvissteinjr said:
I personally don't even like it when fine looking text smileys get replaced by images automatically as opposed to having special character sequences as placeholders which won't be typed in so much (most who expect graphical smileys use button in the post editor anyways). But that's just me, I guess.
Click to expand...
That's the way I personally prefer it, too, but of course that doesn't necessarily mean anything either.
 
New year, new button layout thread? I don't think, it is vaid without any poll. ;)

No, serious: The idea is interesting, but quite hacky. Printing parentheses on the buttons looks a bit like "We weren't able to print anything except ASCII, so we used this work around". Sounds quite cheap.

I doubt EvilDragon would do such a thing. Generally I don't think EvilDragon will have a look in all these threads at all and just do, what his stomages tells him in the end... (I guess Pandora layout + 2 random latin letters).

Just my 2 cents. Keep on discussing!
 
You must log in or register to reply here.

Similar threads

_wb_
Action button labels, again
14 15 16
Replies
314
Views
39K
Urben
Urben
ptitSeb
Automatic smiley conversion
Replies
13
Views
1K
Christoph.Krn
Christoph.Krn
_wb_
  • Poll
Action button labels: poll
8 9 10
Replies
182
Views
22K
WizardStan
WizardStan
_wb_
Action button labels
40 41 42
Replies
824
Views
82K
comradekingu
comradekingu
Caine
Pyra keyboard layout - requirement analysis
2 3
Replies
56
Views
15K
levi
levi
Back
Top