Standardized Controls


One "solution" to the missing Home/End keys could be that Home = press D-Pad up + right nub up at the same time, and End = Press D-Pad down and right nub down at the same time. But that's still not quite it (and is still missing the middle mouse button, at the very least).
You may want to rethink your solution. You're making it needlessly complicated. You've got enter on the keyboard twice at the expense of having to use a complicated combo. All combos not related to Fn are complicated; no there is no way to make them not-complicated: imagine if R+Down returned End, any game that was actually bound to R and Down would get only one, and then End, and not the other, and who knows how the release function would work. The alternative in your suggestion would be to rewrite any program that uses Home and End to instead look for the key combination R and Down: every text editor, every video player, every Pickle Launcher program, all would need to be rewritten and that is a huuuuge task to return no real gain, and a great deal of loss in some cases.

I think it would be beneficial if you shared the _exact_ reason for this. Room for interpretation is likely to leave room for serious misunderstandings in this case.
I don't see how it could be misinterpreted. I use the keyboard far more than the mouse, exactly as I said. I write documents, I build spreadsheets, scroll through lists, browse the web, all these things are made faster and easier with PgUp, PgDn, Home, and End keys in a very easy to use location. I tried the nub/mouse swap you suggested when it was originally suggested several months ago and found it incredibly lacking; yes it made the mouse interaction easier, but it made the key interaction equally more difficult.
 
Ok, after 5 Pages I may ask: ARE WE THERE YET? ;)


Because even if the Decission of Controll Standards has been made, it would just be the beginning. Because then you have to convince all the Coders and then you also have to update and adjust the old games and programms that don't fit in the new Controll shemes. I doubt this will happen at all but it would be the right way. ^^"
 
One "solution" to the missing Home/End keys could be that Home = press D-Pad up + right nub up at the same time, and End = Press D-Pad down and right nub down at the same time. But that's still not quite it (and is still missing the middle mouse button, at the very least).
A much better solution to the missing home/end keys would be to scratch a dedicated key combination for Ctrl+PageUp and Ctrl+PageDn and just map home and end to those keys instead.


Another argument in favour of the current mapping is that the nubs are less accurate (i.e. you are more likely to accidentally strike the wrong key). The impact on the state of most programs for clicking the wrong mouse button is a lot smaller than when striking page up/page down. A user can easily lose track of his/her position in a document if this happens a couple of times in a row.


As far as I am concerned, the default keyboard layout is, for the time being, pretty much set in stone. All of the labeled keys can no longer be modified and any changes to the game buttons will break backwards compatibility with a LOT of software. We need a solution which allows a gradual transition into the new situation. The proposed environment variables satisfy this requirement.


As for you suggestion to map ctrl+Pageup to a nub direction, I can just as easily echo your catch-all statement:

It probably would be beneficial if you shared the exact reasons for this. Room for interpretation is likely to leave room for serious misunderstandings in this case.


See also: the Home/End "solution" at the beginning of this post and "First Rule of Usability? Don't Listen to Users".
What a pretentious thing to say. What do you want? A written report outlining the number of times I press home/end vs the number of times I click a mouse button?


Most applications I launch from the start menu using the Pandora button + up/down/left/right home/end/page up/page dn and not using the mouse. If I can get awesome wm on my Pandora then that will be reduced to modifier+r+app-name. My most common use for the mouse nub is to move the mouse pointer off the screen.


I am an emacs users. I type my notes, documents, source, agenda and appointments, etc.. all in my text editor. I use my text editor as media player, file manager, chat client, shell and sometimes even as web browser. I live inside my text editor. Using keyboard combinations to browse through my documents is less comfortable on the Pandora, hence I use those gaming buttons a lot.

I've got to agree with Stan, there. If you've got a lot of PNDs, and you use Xfce, using the game buttons in their current Home/End/PgUp/PgDn configuration becomes VERY useful indeed.
I see what you mean. If I understood you correctly (navigating menus containing many PNDs is easier with the current Home/End/PageUp/PageDown game button configuration - I am probably missing some things here), then I have to note that the problem is in the management of PNDs (more precise: in some interface elements like the current menu implementation), and the control scheme is illogically constructed so as to mitigate that problem. The real solution would be to adjust the menu implementation. Therefore, regardless of whether that adjustment came to fruition, it would be the better practice to re-evaluate the logic behind the current desktop assignment.
Those key bindings are standard for menu navigation on the Linux desktop. XFCE delivers a regular linux desktop experience and it is bound to desktop keybindings and interaction model (this comes from upstream and is for all intents and purposes out of our control). For a more Pandora-optimized experience, we have Minimenu.
 
Ok, after 5 Pages I may ask: ARE WE THERE YET? ;)
Nope far from it. All we have is guy arguing in a way or an other (aka only seing there own point of view and refusing to understand that others use-case might differ).


May be at a point someone will provide goods solutions _with_ implementation details (aka not high levels dreams). But with the state of the conversation, I'm not seing it coming.
 
Complicated indeed. "In the middle of difficulty lies opportunity."


Pressing D-Pad down (which, when pressed alone, causes "Arrow Down") and right nub down (which, when pressed alone, causes "PageDown") at the same time to get "End" is an idea for desktop use, not game use. There are some drawbacks associated with this: While I do not remember to know of any applications of interpretation of simultaneous presses of PageDown and Down in a desktop application, there definitely are some situations where it matters that if the user wants "Home", the result will likely be that "Up" or "PageUp" will be recognized first. This, however, can be handled by the application, which can choose to revert the first action (or to not support this control scheme at all in more specialized cases where it does not make sense, read on).


The important point however is another, the one that has to do with hints: the current layout does not _have_ to be changed, it can stay exactly the same. As some of you have already implied, the control scheme I proposed can be constructed to apply to only new desktop applications that choose to support it, through a global system. It can also be constructed to apply only if the user chose to enable it manually. These two points solve many problems at once, but also create new problems: little support as well as confusion. To get widespread support for new control schemes such as the one I proposed even though that support is opt-in for both developer and user, hints create incentive for developers to support the global system which provides hints and utilizes environment variables in order to support different control schemes. Hints also create incentive for /users/ to get engaged in the debate. I explained the incentive catalyzing effect in my previous post (search for "Navigating a menu" there). Catalyzing incentive through hints helps all of these usability efforts that have been discussed quite often already to actually come to fruition, with a side effect of reducing confusion.


The control scheme I proposed was meant for Xfce specifically, so, basically, for menus, the settings dialogs (this is what Ctrl+PageUp/PageDown is for), etc., and in addition is logical in a large number of applications. Like every other control scheme, it is not maximally suited for some scenarios, in this case including keyboard-focused handling of applications for writing and spreadsheet building. Once a global system is established, applications can choose which control scheme to use: just as it is useful for games to have different control schemes, it can make sense for applications to be able to choose from a limited set of different control schemes (or in extreme cases to suggest own controls) if the user allows this to happen. Controls that differ between applications can be beneficial as long as there are good hints and a specific set of standards.


I actually wanted to create a hinting system for some time now, as well as some other Pandora related projects, but simply have too many other priorities. Again, I should not have commented in the first place.

It probably would be beneficial if you shared the exact reasons for this. Room for interpretation is likely to leave room for serious misunderstandings in this case.


See also: the Home/End "solution" at the beginning of this post and "First Rule of Usability? Don't Listen to Users".
What a pretentious thing to say. What do you want? A written report outlining the number of times I press home/end vs the number of times I click a mouse button?
Any explanation such as the one from your latest post is likely to turn out to be useful eventually in a usability debate even though reported behavior is typically comparatively inaccurate.


This discussion focuses on the Home/End keys because many of those who take part (including myself) are using them all the time. At the same time, there was no discussion whatsoever about the middle mouse button that I completely failed to integrate, even though binky had already pointed it out and it is of comparable importance to some. There is no way to tell people that they are out of control of what they are doing without offending someone. You might not believe this, but there was no personal judgment implied in what you quoted. It was simply the truth - the non-conscious parts of behavior are very important for usability. ( useit.com is a website by Jakob Nielsen who is well-known for his usability knowledge, if you also meant that.)
 
Last edited by a moderator:
This, however, can be handled by the application, which can choose to revert the first action (or to not support this control scheme at all in more specialized cases where it does not make sense, read on).
Stop, no it cannot. What you propose now requires all of upstream to adapt such modifications. Pandora desktop software consists mostly of ports. To push such a burden onto porters will only mean that the ports won't happen or that the porters won't bother to support the standard. Really, this won't change on the regular desktop and therefore it won't happen on the Pandora. Most such navigational bindings are defaults set by the widget library. To work around that is a hassle and very unlikely to happen.


I don't even think it is a good idea but that's not even relevant here, it is not feasible.


Let's please park this idea in the fridge for now, we can always revisit it later if needed. This thread is now rapidly diverging from consensus and risks dying like all similar discussions before it if we don't turn the tide.

The important point however is another, the one that has to do with hints: the current layout does not _have_ to be changed, it can stay exactly the same.
If I understand this post of yours correctly, then you highlight as main issue the following:


There is confusion amongst users as to which buttons are mapped to which action. This is caused by

  • 1) Lack of standardization causes every application to utilize a different key for a different action.
  • 2) There is no standardized way to communicate this binding to the end-user. You cite the Wii menu as an example.


The topic of this thread was to address issue 1., not issue 2. In the ideal case issue two would be handled by the launcher, e.g. by querying the applications. It is however, from a technical point of view, a totally different challenge which warrants a discussion of its own.


There is nothing wrong with keeping the possibility to solve issue 2 open, but I would prefer to focus on 1.


The proposal so far has placed focus on menu navigation and menu keys. This ensures that every user can at least start/stop an application and explore its options (which in the ideal case contains a custom control mapping). The first post now describes a reasonable concensus regard the accept/cancel/pause/exit/menu and pandora keys. There also seems to be consensus that environment variables are the way to go.


The current description is very suitable for games/emulators, but I am not yet convinced that it should also apply to the desktop and desktop applications (those which rely heavily on Gtk/Qt widgets). If we exclude the desktop from this proposal (a minimized game is not a desktop application), then the standard is fine by me.


This can be the first version of the standard. In a second version I recommend inclusion of environment variables for the other game controls such that we can finally modify our keybindings on the desktop without breaking all the games. Once that is in place, then the next step can be to work on an API between applications and the OS such that we can have global user preferences and hints about how buttons are bound by specific applications.
 
Last edited by a moderator:
Ok, after 5 Pages I may ask: ARE WE THERE YET? ;)
Nope far from it. All we have is guy arguing in a way or an other (aka only seing there own point of view and refusing to understand that others use-case might differ).


May be at a point someone will provide goods solutions _with_ implementation details (aka not high levels dreams). But with the state of the conversation, I'm not seing it coming.
Yeah, it seems that democracy just don't work on the Internet. I bet this thread will go on and on and on without any solution or conclusion. :( Gaaawd! It is not that hard to make a standard control sheme, nobody says it has to include every Button on the Pandora. I just want clear button settings for Start/select and Menu options, Quit an app etc... Is it really THAT hard to do? If I ever make a Handheld I swear I just set a standard control sheme that has to be followed without any discussion. It works since Ages for Nintendo, Sony & Co. and everyone is Happy with it.


It really is essential for Userfriendlyness to have some basic Buttons that always work, in every App. I never want to push L+R+whatever stupid combination again to quit an App or reach a Menu.
 
Last edited by a moderator:
If I ever make a Handheld I swear I just set a standard control sheme that has to be followed without any discussion. It works since Ages for Nintendo, Sony & Co. and everyone is Happy with it.
It works for such companies because developers are not approved to release their software on those platforms if they don't conform to certain standards. ;) It's a bit of a different situation here, no?
 
It leads to standard controls so the situation would be the same at the end. You know in every Nintendo Game pretty quickly, what button does what because it is mainly always the same. Nothing bad at all. I really wish we would go this way on the Pandora, no App without propper controll sheme and valid PXML/PND stuff. Imagine the Pandora sells over 10.000 times, do you want 10.000 Useres spam the Forum with questions about how a game is controlled ? ;) You always should have this in mind, I already think about the Future of the Pandora and we really need more User Friendliness for the wide Masses. :)
 
Last edited by a moderator:
This, however, can be handled by the application, which can choose to revert the first action (or to not support this control scheme at all in more specialized cases where it does not make sense, read on).
Then it will be not supported at all. The best way to get a developer to not support a standard is to make it a difficult standard to implement. You want something that is both intuitive and easy to implement. Your proposal is definitely not easy to implement and barely brushes on intuitive, actually running away from it in some cases: I would certain never think to press some key combination involving the nub and arrow keys to get End or Home or PgUp or PgDn or any key for that matter.
 
It leads to standard controls so the situation would be the same at the end.
I believe Prometheus's point is that it won't work because there is no way to prevent someone from releasing their app (regardless of full, partial, or no standards support) in contrast to Nintendo and Sony which have been preventing developers from releasing their games for decades. It's that "Open" part in the name :p
 
HEY EVERYONE, I HAVE A CONTROL SCHEME IDEA!!


Its fairly standard, and most .pnd's seem to follow pretty close already.



Code:
Menu Accept/Foreword = X, RightDpad, or Enter //all do the same thing, only need to pick one, but having all three work is preferred

Menu Deny/Cancel/Back = A, B, LeftDpad, //all do the same thing, only need to pick one, but having all three work is preferred

Menu Up = DpadUp Rshoulder //Rshoulder could be more of a page up

Menu Down = DpadDown Lshoulder //Lshoulder could be more of a page down

Quit = Esc //Quit, with dialog preferably, dialog should preferably be able to be disabled


Pandora button handled specifically by the os, defiantly bringing up some Xbox360 esque overlay with a task manager and a launcher.


Did i miss anything?


Also these shall be customizable with environment variables.
 
It leads to standard controls so the situation would be the same at the end.
I believe Prometheus's point is that it won't work because there is no way to prevent someone from releasing their app (regardless of full, partial, or no standards support) in contrast to Nintendo and Sony which have been preventing developers from releasing their games for decades. It's that "Open" part in the name :p
Yes but as long as the majority follows the Standards, this will not be a Problem. If we HAVE Standards it is much more easy to convince people to use it. ;) The Problem now is that we don't have standards for Controlls. ^^" At the end, it is each coders decission to use or not to use the Controlls like the Standards say.

Did i miss anything?


Also these shall be customizable with environment variables.
Yupp, since A and B should be the confirm buttons and X for Cancel. We are not at the Playstations here. ;) The Pandora Gaming Buttons have the old GP2X Layout and there, B was often used for confirm and X was often used for cancel options. And I like this way also on the Pandora since I can reach the B button much better than the X Button. :D
 
I like X for select and A for cancel, but again, if we go with the configurable setup and just make them virtual keys it won't matter either way, just pick a reasonable default.


The problem I have is that it isn't trivial to implement multiple keys to do the same thing if it wasn't designed that way from the start. If we decide VK_OKAY and VK_CANCEL will be the virtual keys of choice, it's pretty simple to just search and replace VK_END with VK_CANCEL and VK_PGDN with VK_OKAY (or whatever the original developer had in mind) but if you have multiple accept buttons they'd have to replace VK_PGDN with "VK_OKAY1 || VK_OKAY2 || VK_OKAY3" in whatever particular structure they used, and there are a LOT of different ways to check whether a key has been pressed so this could get quite complicated. Alternates could work so long as they're considered optional, and could then be implemented going forward, or not, so long as there is a single VK_OKAY and VK_CANCEL (or whatever is considered most appropriate) that is considered standard.


Could even make it a variable number of alternates, if we wanted. VK_OKAY is always the primary, but if they want to support alternates, the user can setup as many alternates as they want and on program startup those alternates are stored in an array VKS_OKAY (or something more suitable, this is likely to get confused with the single) and the developer iterates through the array.
 
Okay, thanks to Caine we can get back on track now I guess.


I won't comment on the longer posts made, because I feel most points have already been addressed and everything else I have to add would only be unproductive nit-picking of points unrelated to the matter.

I like X for select and A for cancel, but again, if we go with the configurable setup and just make them virtual keys it won't matter either way, just pick a reasonable default.


The problem I have is that it isn't trivial to implement multiple keys to do the same thing if it wasn't designed that way from the start. If we decide VK_OKAY and VK_CANCEL will be the virtual keys of choice, it's pretty simple to just search and replace VK_END with VK_CANCEL and VK_PGDN with VK_OKAY (or whatever the original developer had in mind) but if you have multiple accept buttons they'd have to replace VK_PGDN with "VK_OKAY1 || VK_OKAY2 || VK_OKAY3" in whatever particular structure they used, and there are a LOT of different ways to check whether a key has been pressed so this could get quite complicated. Alternates could work so long as they're considered optional, and could then be implemented going forward, or not, so long as there is a single VK_OKAY and VK_CANCEL (or whatever is considered most appropriate) that is considered standard.


Could even make it a variable number of alternates, if we wanted. VK_OKAY is always the primary, but if they want to support alternates, the user can setup as many alternates as they want and on program startup those alternates are stored in an array VKS_OKAY (or something more suitable, this is likely to get confused with the single) and the developer iterates through the array.
Yep, a good point you address there, so let's talk implementation. (the standard mapping in the first post seems to be accepted by most people, at least I have not read any structured, direct complaints).


First of all, and I am aware this makes things more complicated for the developer, I would not bind the new functions defined in the standard (aka VK_CONFIRM, VK_CANCEL or whatever) to key-codes of the Pandora's special keys, rather than variable names or identifiers of the Pandora's keys (as well as virtual keys of standard keyboard buttons like VK_RETURN).


For example, taking the current proposed schema (see first post), VK_CONFIRM would be bound to PANDORA_B or something like that.


I don't know whether there are already variables defined describing what key codes action buttons are bound to or whether that's actually feasible, but it would have the advantage of being independent of the user's keyboard mapping (as for example some people have bound the L/R keys to the mouse buttons a standard including those keys would not work for them by default).


So I propose envars to be set for the Pandora keys storing the key code they are mapped to. Those could be named VK_A or VK_PANDORA_A or PK_A (Pandora key) or whatever.


Then a set of variables would be created binding the actions described in the standards (aka VK_CONFIRM, VK_CANCEL, VK_PAUSE, VK_EXIT, VK_EMU_MENU) to the previously mentioned variables (so a resulting var would be VK_CONFIRM=VK_PANDORA_B for example).


What remains is the problem of alternate keys, I am opposed to setting multiple VK_CONFIRM_0..n, rather would store them all in one variable separated by || (for optional keys) or && (for key-combos).


A resulting var could look like



Code:
VK_CONFIRM=VK_PANDORA_B||VK_ENTER


Implementation is slightly trickier as one would have to go through a potential array of keys and also potentially look-up certain variables (VK_PANDORA_A) further, so I guess it's not ideal (especially when you are implementing this in hindsight or ports of software), but maybe a small library could be supplied for easy access (written in C to be easily integrable and portable).
 
Code:
Menu Accept/Foreword = X, RightDpad, or Enter //all do the same thing, only need to pick one, but having all three work is preferred

Menu Deny/Cancel/Back = A, B, LeftDpad, //all do the same thing, only need to pick one, but having all three work is preferred

Menu Up = DpadUp Rshoulder //Rshoulder could be more of a page up

Menu Down = DpadDown Lshoulder //Lshoulder could be more of a page down

Quit = Esc //Quit, with dialog preferably, dialog should preferably be able to be disabled


Pandora button handled specifically by the os, defiantly bringing up some Xbox360 esque overlay with a task manager and a launcher.
As mentioned before, swapping of B and X is preferred. (for comparison see the layout proposed in the very first post).


I like adding Enter as an alternative for "accept", I dislike adding the D-Pad keys as I feel moving through the menu and choosing an item should be separated (although using the D-Pad like that would enable one-handed usage).


Dunno if menu-up/-down need to be included, using the R and L keys for that seems not very intuitive, too.
 
It leads to standard controls so the situation would be the same at the end.
I believe Prometheus's point is that it won't work because there is no way to prevent someone from releasing their app (regardless of full, partial, or no standards support) in contrast to Nintendo and Sony which have been preventing developers from releasing their games for decades. It's that "Open" part in the name :p
Nah, I'm all for the proposal in this thread, and I think it should work fine once it's rolling! My point was simply that the platform-holders who operate approval processes don't just say "Use this" - they can enforce it. ;)


Anyway, foxblock, sorry for the off-topic there, again - I just wanted to clarify what I meant, lest anyone think I was against this (or think it won't work out), which I'm absolutely not. :p
 
Last edited by a moderator:
I'd avoid putting || in an environment variable. It can make make setting and using it less than trivial. Space separated and it automatically becomes parseable in pretty much everything



Code:
export VK_CONFIRM="VK_PANDORA_B VK_ENTER"

for KEY in $VK_CONFIRM

do

  echo $KEY

done
 
If we are to allow multiple keys, then I agree with WizardStan to use a space-separated list.


Ok. So let's define which keys we all need. Here is my first take on this.


Virtual keys (these might need a prefix/suffix to make them unique):

  • Meta keys
    - VK_QUIT = ESC
    - VK_MENU = ALT_L # start
    - VK_EMU_MENU = space
    - VK_ACCEPT = end
    - VK_CANCEL = page down
  • Game buttons:
    - VK_ACT_A = home
    - VK_ACT_B = end
    - VK_ACT_X = page down
    - VK_ACT_Y = page up
    - VK_START = ALT_L
    - VK_SELECT = Control_L
    - VK_L1 = Shift_R
    - VK_R1 = Control_R
  • D-pad (might be useful if you connect an external keyboard and want WASD)
    - VK_UP = up
    - VK_RT = right
    - VK_DN = down
    - VK_LT = left



Standard:

  • Only bind game buttons through their virtual keys, not their actual mapping
  • Use VK_QUIT to terminate the application (preferably with confirmation dialogue)
  • Use VK_MENU to pause a game and open the game menu. It is highly recommended that this game menu also contains a quit option.
  • Use VK_ACCEPT to accept a menu choice, confirm (in popup dialogues, etc..)
  • Use VK_CANCEL to go back in a layered menu, cancel (in popup dialogues, etc..)
  • For emulated or virtualized games use VK_MENU for the game menu and VK_EMU_MENU for the menu of the emulator or runtime environment.
  • The Pandora key is reserved by the OS and should NOT be bound by applications.
  • Be aware that the meta keys can (and typically are) overlapping with the game buttons.
    Use them where appropriate. E.g.
    Within a menu or emulator menu, use VK_ACCEPT and VK_CANCEL and not the equivalent game button virtual keys (VK_B, VK_X by default).
  • Don't bind jump to e.g. VK_CANCEL but use VK_X instead.
  • Only open the menu through VK_MENU and don't use VK_MENU for other actions. E.g. starting a game from the title screen or skipping a cutscene would bind to VK_START and not VK_MENU (this assumes that in those contexts the menu is not available).
 
Last edited by a moderator:
Let's please park this idea (the Xfce control scheme, remark) in the fridge for now, [...]
Yes, that's the best thing to do. Some of the ideas I have are difficult to express and a LOT of work, which is why I wanted to do an implementation myself. I will focus on a limited set of thoughts now and, again, have to apologize for the initial confusion I caused.


------------------------------------------------------------------------

If I understand this post of yours correctly, then you highlight as main issue the following:


There is confusion amongst users as to which buttons are mapped to which action. This is caused by

  • 1) Lack of standardization causes every application to utilize a different key for a different action.
  • 2) There is no standardized way to communicate this binding to the end-user. You cite the Wii menu as an example.


The topic of this thread was to address issue 1., not issue 2. In the ideal case issue two would be handled by the launcher, e.g. by querying the applications. It is however, from a technical point of view, a totally different challenge which warrants a discussion of its own.
Yes except that 2) is more like a tool chest for developers, plus there is something else to these two points.

  • The definition of "confusion" I use here is a very specific one. It means conscious confusion that is caused by an increased overhead of /non-conscious/ processing. The non-conscious nature of this overhead makes it difficult to see.
  • "games" refers to most full-screen applications, including things like Minimenu or Rockbox.
  • 2) should not be implemented through something like the Wii home menu, but rather:
    a) In-menu hints through standardized graphics (much like in this screenshot of Mario Party 5). Some games already have these (random examples: PandoraPanic! and Panorama) but do not always use them consistently, and the graphics often do not make much sense, mainly because of the similarities between the game buttons of the Pandora, the SNES, and the PlayStation. A standardized set of in-game hint graphics of high quality that are easy to put into an application would be very useful. (Any standard on how these graphics should be used can prevent their use and should be created later - developers cannot be forced to adhere to it anyway.)
  • B) A Visual one-screen overview (much like in one of the screenshots at http://www.videogamesblogger.com/2009/10/06/metroid-prime-review-samus-returns-to-gaming-in-glorious-3d-from-an-all-new-perspective.htm , search for "layout" there, or in the screenshots at http://forza.norm302.com/fm/features8.html ). As a first step, this does not necessarily have to be implemented by the launcher so that developers just hand the button assignments over and the user can access it whenever hints are not available with a single press of the Pandora button, where the overview is integrated along the other functions of that launcher screen. As a first step, the developers can hardwire this overview into their games and make it accessible through a button that they hint to at some point (e.g. in the Start/Pause menu). This does mean that these games will not automatically use newer standardized graphics, but this is not avoidable anyway because of the in-menu hints that can not automatically update either (it does not make sense for them to do; this might break something in some games and at the very least alters the game experience). In case this will ever be handled by the launchers, developers can remove the legacy hardwired overview and, if necessary, replace it with a hint to the new function. This is still better than the current nothing.


[*]In the context of 2), it is important to know that design is not what it looks and feels like, it's how it works. Every part that plays into design in its various definitions is potentially of importance when trying to make sure that 1) will succeed in reducing confusion.


[*]The impact of the menu navigation standards as proposed here (the "common denominator") is more limited than one might think. There are many reasons for this, but probably most importantly, the menus typically used most frequently are likely to use remaining buttons for random other tasks, thereby causing cognitive overload (==confusion) regardless of the standard. If more buttons are standardized in an effort to mitigate this problem, then the menus that had used the previously remaining free buttons will now have to either break standard compliance, or somehow put the functions somewhere else. If more button _functions_ (environment variables) are being introduced, they will lead to disharmony between people and thus greatly decrease the chance that any further efforts will succeed. If no more button standards or functions are added, then the cognitive overload remains.


[*]There are many reasons control standardization efforts in general can fail in an open ecosystem, and many of them are not controllable. A developer might not support 1) because it does not make sense for her application, or simply because she prefers something else, or for a large number of other reasons. The more immersive 1), the worse these effects; the less immersive 1), the less sure it is that it will manage to keep cognitive overload down without a little help from 2).


[*]All of the suggestions that were made to the very basic "common denominator" standard share a very limited number of some extremely basic concepts, like B to accept, X to cancel, Start to pause. However, even the discussion about all other parts of the suggestions, like "Select to exit?" or "RShoulder==DPadUp?", indicates how much of a non-conscious "experience" these other parts are that people might not realize.


-> _Example:_ Space as an overlay menu standard is mainly helpful to those who /already know that there is an overlay menu and who already know that they have to press space to open it up/. It makes sense to those that create the standard, but not to those who are lost in an emulated game, do not know how to get out, and maybe do not even know that there is an overlay menu. One might say that "Novice users first have to learn that there is an overlay menu, the standard is not there to teach them", but that's not true. The user might not even be a novice user at all - he's not stupid, he just doesn't know. The confusion from that situation is not very different from the one experienced when a PND's developer failed to communicate how to quit his application, and it is similar to the confusion one experiences in a foreign menu (there will always be situations like these since `1)' is very limited). The more logical (==less confusing) solution for an emulator overlay menu would be to _put_the_overlay_menu_on_Esc_ and to provide some hint to the Esc key's function, with a "quit" option in that menu. This would make sense and in turn incite other developers to do the same, which is exactly what is required. (A developer who did this would break compatibility to the currently proposed standard!) Again, this is just an example.


[*]2) is very /visible/ to the user, who is a human being and as such typically uses vision as his primary means to get information from the world. This increases general awareness of 1) through the existence of 2). The result is, hopefully, an increased incentive to support and help improve 1) (as well as `2)') on both the side of the developers as well as the side of the users. This incentive is crucial in this open development environment.





There are many loose ends that come together.


1) is unlikely to be very helpful in an open environment such as the Pandoras, but 2) can be used to reduce remaining problems and make 1) successful anyway. I hope this makes a little more sense. It splits the potential success of this standardized controls effort here into standardization, graphic design, software design, and psychology, (all part of usability) and might still be difficult to understand. Please tell me if something is unclear.
 
Last edited by a moderator:
Back
Top