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.
