Standardized Controls

[Caine]

In the *nix world, just kill -SIGSTOP and kill -SIGCONT.

Right, off course. I didn't think about simply suspending the application (duhhh). That would work and sounds quite doable.

 

[foxblock]

Sounds tricky to set up. The Pandora button press would have to be handled by both the application and the OS, or the application should be able to receive some universal pause signal.

They already do. In the *nix world, just kill -SIGSTOP and kill -SIGCONT. I'm pretty sure this is already happening when you put the Pandora into "sleep" mode: the sleep script greps through the list of running processes and SIGSTOPs all the ones that are started via PND.


Press the Pandora button, SIGSTOP the focused application, start a new application that writes directly to the framebuffer, grab a copy of the framebuffer first, display your options, do the deed. You take a copy of the framebuffer so it can be restored if the user chooses to resume, just in case the application doesn't do a full window refresh often.


At least in theory, anyway. My Pandora is currently totally out of commission and I've no way to test.

Ah that sounds quite doable and much more useful than the current (hacked in - probably due to time constraints, not trying to blame anyone) menu.


Sadly I don't have the time and *nix knowledge (being a Windows guy after all) to create this... :S


Anyway with the changes discussed (and applied in the first post), are there any complaints left about the controls standard or can it go up in the wiki?

 

[Caine]

Anyway with the changes discussed (and applied in the first post), are there any complaints left about the controls standard or can it go up in the wiki?

Yes, wiki it. Scrap the unneeded select mapping and require the application menu to contain a quit/exit option. The standard should also forbid overriding the Pandora button.


[edit]Ah, I see you were still busy editing it. Looks good.[/edit]


[edit2]


Oh wait, do we need to say something explicit about XFCE and XFCE native apps? I read those accept/cancel actions in menus as applying to menus in games, emulators and launchers only.


Start/Select would basically remain Ctrl and Alt and the game controls would remain Home/End/Page Up/Page Dn (which implies that game button B does NOT start an application in the XFCE menu).


In other words, this standard holds when it reasonably applies. If you have a dos game like e.g. an old sierra text adventure, you would utilize the controls in regular keyboard mode instead.


[/edit2]

 

[Christoph.Krn]

Anyway with the changes discussed (and applied in the first post), are there any complaints left about the controls standard or can it go up in the wiki?

I do have some things to add, but did not yet have the time to do so. The following are unfinished thoughts. Please remember that more often than not, doing things right is preferable over getting them done early, and this is especially true for something like a standard that may turn out to be difficult to change in the future (ideally, the standard anticipates possible changes to its fundamental base).


The main problem is not, in fact, that different applications use different control schemes (although huge improvements can, and should, be made here, too). Instead, the actual current problem is confusion, which is a result of these different control schemes. It (the confusion) is, to a great extent, the result of missing hints. Standardized hints are what is required for a significant change that will also outlast (and thus, enable) future changes, and the standard has to be simple and easy to understand for developers.


Since a literally endless number of applications (games) can be imagined, it is not possible to establish a single standard without imposing a creativity restriction on developers (even though the standard would be non-mandatory). For some applications, there are control schemes that differ from a given standard (regardless of what that standard may look like) but are better suited for that particular application. There is no way one can force this situation to be different, and if one wants to encourage people to create unique works, one has to improve the situation itself instead (read: reduce confusion in situations with non-standard controls).


Furthermore, different people are used to different control schemes (compare: PS, SNES). As far as I am aware, and I may very well be wrong here, the SNES as well as the Japanese Playstation use "A"/"CIRCLE" to confirm (equivalent to Pandora's B button) and "B"/"X" (equivalent to Pandora's X button) to cancel ("go back"); whereas outside of Japan, the button's meanings are swapped on the Playstation (so, "X" to confirm, "CIRCLE" to cancel), and these are the two most-widely-accustomed-to control schemes. Enabling the user to switch the meaning of the Pandora's B and X buttons is is within the limits of sane adjustments (which are adjustments that do not change the complete idea; in this case, do not change the idea of a common suggested standard). This choice is a good thing because a person may have her favorite button control scheme burnt into her muscle memory already.


For the aforementioned reasons, I suggest to create a standard way for applications to tell the user what button implements which action, in a way that is aware (again, within the limits of sanity) of the user's preferred button usage (to be precise: B to confirm and X to cancel, or vice versa?) and is integrated with the "overall experience" (it doesn't get more vague than that, huh?). The basic idea I currently have is to integrate this into the Pandora button's function, similar to how it works on the Wii's virtual console "home" menu (I might, and probably will, share more on this as I have the time, but you are of course free to continue on your own, too).


Since you have currently arrived at questioning the desktop controls, I'll give you the following for now. My experience suggests me to assume that on the following, I will also receive too many negative reactions that have no basis in fact, but luckily I sometimes, somehow manage to still believe in people's ability to think before commenting, and am already happily awaiting the huge number of nicely thought-through responses (I currently cannot be sure that I might not be missing some things here).


"Desktop Control Scheme" (for XFCE):


D-Pad: Arrow keys


Left nub: Mouse control


Button "B": Enter key


Button "X": Esc key


(A settings program can be used to swap the meaning of the aforementioned two buttons; the above is default)


Button "A": Left mouse button


Button "Y": Right mouse button


Right nub up/down: Page up / Page down


Right nub left/right: Ctrl + Page down / Ctrl + Page up


(Right nub to scroll through documents quickly and to switch between the tabs of an application or settings dialog.)


Pandora Button: Open user's default "meta-menu". The default meta-menu is the user's preferred application that enables him to at least run applications (and possibly manage them) and is optimized for the Pandora (random examples: minimenu, Panorama). On the top edge of the desktop, a hint tells the user to try pressing the Pandora button.


--

ESC again is also preferred over Select as it's much more obvious and intuitive, but has the problem of being slightly "hidden".

Users are typically not completely stupid, they just don't know. As long as there is a logical and non-confusing way to make them know, it is an extremely good thing to hide things.


While it is often preferable to make something complicated (because you only want those who are seriously interested and reliable to follow, and you want these people to be informed comprehensively), it is important to remember that people, in their role as a consumer, have only so much attention to /pay/. If you do not construct your user interface so that it lets users find out things themselves, you will end up with an interface that has thousands of buttons and, potentially worse, modes, and will thus be inherently difficult to use. The worst you can do with hiding is to create a steep learning curve when required as opposed to an inevitably steep learning curve, which is a win (restriction: in a subset of cases this is only true if you succeed in hiding without restricting functionality).

 

[sebt3]

I'm pretty sure this is already happening when you put the Pandora into "sleep" mode: the sleep script greps through the list of running processes and SIGSTOPs all the ones that are started via PND.

yes it is

 

[Binky]

"Desktop Control Scheme" (for XFCE):


D-Pad: Arrow keys


Left nub: Mouse control


Button "B": Enter key


Button "X": Esc key


(A settings program can be used to swap the meaning of the aforementioned two buttons; the above is default)


Button "A": Left mouse button


Button "Y": Right mouse button


Right nub up/down: Page up / Page down


Right nub left/right: Ctrl + Page down / Ctrl + Page up


(Right nub to scroll through documents quickly and to switch between the tabs of an application or settings dialog.)


Pandora Button: Open user's default "meta-menu". The default meta-menu is the user's preferred application that enables him to at least run applications (and possibly manage them) and is optimized for the Pandora (random examples: minimenu, Panorama). On the top edge of the desktop, a hint tells the user to try pressing the Pandora button.

As long as can have middle mouse button!

 

[FaeMinx]

"Desktop Control Scheme" (for XFCE):


D-Pad: Arrow keys


Left nub: Mouse control


Button "B": Enter key


Button "X": Esc key


(A settings program can be used to swap the meaning of the aforementioned two buttons; the above is default)


Button "A": Left mouse button


Button "Y": Right mouse button


Right nub up/down: Page up / Page down


Right nub left/right: Ctrl + Page down / Ctrl + Page up


(Right nub to scroll through documents quickly and to switch between the tabs of an application or settings dialog.)


Pandora Button: Open user's default "meta-menu". The default meta-menu is the user's preferred application that enables him to at least run applications (and possibly manage them) and is optimized for the Pandora (random examples: minimenu, Panorama). On the top edge of the desktop, a hint tells the user to try pressing the Pandora button.

This gets my vote! I believe it to be far more intuitive and consistent than the current defaults.


+1000 ;3


Sent from my HTC Sensation Z710e using Tapatalk

 

[WizardStan]

As someone who uses the keyboard more than the mouse, changing the nub/game key configurations like that is not something I can agree to. I seem to recall we already had a poll and discussion around that.

 

[Prometheus]

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.

 

[Caine]

"Desktop Control Scheme" (for XFCE):


Button "B": Enter key


Button "X": Esc key


(A settings program can be used to swap the meaning of the aforementioned two buttons; the above is default)


Button "A": Left mouse button


Button "Y": Right mouse button


Right nub up/down: Page up / Page down


Right nub left/right: Ctrl + Page down / Ctrl + Page up


(Right nub to scroll through documents quickly and to switch between the tabs of an application or settings dialog.)

Sorry, but I have to oppose this mapping. You completely eliminate home/end which is totally unacceptable. Next, you introduce redundant mappings (B/enter), X/FN+q. A lot of existing software would need to be changed if the layout is now modified. Fourth, I use home/end/pageup/pagedown a lot more than I use mouse clicks and personally prefer the current layout over what you have proposed.

 

[Ziz]

Since a literally endless number of applications (games) can be imagined, it is not possible to establish a single standard without imposing a creativity restriction on developers (even though the standard would be non-mandatory).

Foxblock was not talking about a Default-Fire or a Default-Jump Button. We are talking about buttons and functions, which nearly EVERY Game/Application uses. For example a Confirm-Button or a Cancel-Button. Furthermore a Standard, that Start always shows a main menu and similar.

Furthermore, different people are used to different control schemes (compare: PS, SNES). [...]

I think, you didn't understand, that the idea is a default mapping in the Pandora OS. That means, that every application supporting the standard (which would be still optional) would change it's behavior if the User changes the system default.

 

[Caine]

That means, that every application supporting the standard (which would be still optional) would change it's behavior if the User changes the system default.

This has not been decided at all. I did suggest creating an API earlier in this thread to make this possible, but it needs to be discussed further.

 

[sebt3]

I seem to recall we already had a poll and discussion around that.

only one ? I recall many of them and none managed to get some fruits.


There are many aspects here that need a good solution :


- mouse focus vs keyboard focus. I cant see a pool save this. There is only one way : having a benevolant dictato that choose for us (like the big company do). But OPT already have done this decision when setting up the OS. Case should be closed. Yet as there are unhappy people, we'll have more of these useless posts to come.


- If we change the default, what can we do for the about 350 PNDs already existing that would be broken by this change ? No one have given a good and valid reply to that.


- Not all the emulated system use the same standard. how to standardize that ?


- Most ported games come from the desktop linux environnement where there is no standard input method. So all these games have their own input rules, it's realy uneasy and sometimes completly impossible to stick to a given standard.


In the end of the day, for the ported apps/games/emu it all depends on the dev. I for one is realy open to change the control scheme of any of my PNDs. I have conducted several discussion about control scheme of my games. and it was already uneasy to get a consensus. I cant believe we ever manage to get one for a system wide (and complete) scheme that will get a consensus.


If we ever manage to get it, I'll stick to it.

 

[EvilDragon]

Well, the idea to have variables which the user can setup in the OS for some controls sounds like the best idea so far.


Old PNDs would just work as before, as they don't use those variables and new ones could use these variables.


However, this would most probably only be used for menu navigation in the game. Each game should keep their custom controls. There ARE Jump'n'Runs where it's more comfortable to use A to jump and there are some where it's more comfortable to use X for jump.

 

[Ziz]

That means, that every application supporting the standard (which would be still optional) would change it's behavior if the User changes the system default.

This has not been decided at all. I did suggest creating an API earlier in this thread to make this possible, but it needs to be discussed further.

I made the suggestion to use the Linux Environment Variables. Easy to set, easy to read and every programming language for the pandora has still support. ;-) I think it is very important to discuss the kind of the standard (system wide or just as constant "world" wide) at the beginning, because THEN you know, how necessary it is to discuss every single default button setting. ;-)


@ED: As I said as a response to Christopher K: There is no plan to define default buttons for special functions like jumping or shooting. It is just for meta functions like "okay", "cancel" or "menu".

 

[Caine]

I made the suggestion to use the Linux Environment Variables. Easy to set, easy to read and every programming language for the pandora has still support. ;-)

So you did, I missed that. I support this idea.

 

[foxblock]

I do have some things to add, but did not yet have the time to do so. The following are unfinished thoughts. Please remember that more often than not, doing things right is preferable over getting them done early, and this is especially true for something like a standard that may turn out to be difficult to change in the future (ideally, the standard anticipates possible changes to its fundamental base).

Okay, first of all I have got to say to me your post comes across rather arrogant and condescending.


First you mention that the main problem is _in fact_ something different, then you discuss several parts of the topic based on facts, but also heavily personal experience and empiric knowledge and lastly you assume that you will receive negative messages about your proposal not based on facts, when, in fact, you did make that proposal mostly from assumptions and experience yourself, which is perfectly fine as there is no objective way solely based on facts to create such a standard.


That negative attitude probably was not your intention, but this is how it came across to me.


Anyway...

The main problem is not, in fact, that different applications use different control schemes (although huge improvements can, and should, be made here, too). Instead, the actual current problem is confusion, which is a result of these different control schemes. It (the confusion) is, to a great extent, the result of missing hints. Standardized hints are what is required for a significant change that will also outlast (and thus, enable) future changes, and the standard has to be simple and easy to understand for developers.


Since a literally endless number of applications (games) can be imagined, it is not possible to establish a single standard without imposing a creativity restriction on developers (even though the standard would be non-mandatory). For some applications, there are control schemes that differ from a given standard (regardless of what that standard may look like) but are better suited for that particular application. There is no way one can force this situation to be different, and if one wants to encourage people to create unique works, one has to improve the situation itself instead (read: reduce confusion in situations with non-standard controls).

First of all, I agree that missing hints is part of the problem and I agree that a standardized way how and when to display hints would help there, sadly due to time constraints you don't go much further into that topic in your post (that paragraph is, as you mention, too vague for me).


Then gain, hints are rather unnecessary when all programs control more or less alike or at least the way the user want them to. Now, and I am aware other people have pointed that out, we are only talking about general actions like "menu", "exit", etc. here - no game-specific controls, you may set those as you please, but, obviously, you should also tell the player how you set them up.


Controlling a menu has been almost consistent on the various consoles (as you note in your next paragraph), obviously there have been different standards on different consoles, but you must realize, that we are trying to create a standard for our console. This should not be a total new one and as the Pandora has a similar layout as a Nintendo console (at least the buttons are named the same) we are drawing inspiration from that.


This standard should apply a fixed set of rules how programs/menus should behave and be controlled, without limiting the dev in any way as most menus are probably controlled with two buttons anyway and out setting so far should not be pre-occupied in that case (and as statistics show is the preferred schema on the Pandora).


We ARE setting a fixed set of buttons, but this should be seen as a default setting or for those without access to a (yet to be created) global system configuration.

My experience suggests me to assume that on the following, I will also receive too many negative reactions that have no basis in fact, but luckily I sometimes, somehow manage to still believe in people's ability to think before commenting, and am already happily awaiting the huge number of nicely thought-through responses (I currently cannot be sure that I might not be missing some things here).

That was not really necessary, was it.

"Desktop Control Scheme" (for XFCE):


[...]

While I agree with your proposal as it makes more sense to me than the current mapping I must oppose to it for the following reasons:


You cannot simply change the mapping of the buttons, this would instantly break hundreds of PNDs using hard-coded key-codes.


Also this again is a preference thing, one might like it, the other one opposes and making a vast change like that takes much pre-work.


This is why the standard proposal by me does not focus on button mapping, but the functions of those buttons in the individual applications (call it a meta-standard, I dare you). To fully integrate this just as much work is required (you would need to change most existing PNDs), but you don't break any of them by setting it. Also setting functions instead of key-codes allows the user to easily change the underlying key-codes for himself (switch B key to A key for default "accept" action).


How this is done is up for debate, but I fully support the setting of system environment variables mapping a key-code to a VK_ACCEPT, VK_CANCEL, etc.

Users are typically not completely stupid, they just don't know. As long as there is a logical and non-confusing way to make them know, it is an extremely good thing to hide things.


While it is often preferable to make something complicated (because you only want those who are seriously interested and reliable to follow, and you want these people to be informed comprehensively), it is important to remember that people, in their role as a consumer, have only so much attention to /pay/. If you do not construct your user interface so that it lets users find out things themselves, you will end up with an interface that has thousands of buttons and, potentially worse, modes, and will thus be inherently difficult to use. The worst you can do with hiding is to create a steep learning curve when required as opposed to an inevitably steep learning curve, which is a win (restriction: in a subset of cases this is only true if you succeed in hiding without restricting functionality).

I have to strongly disagree, making something deliberately complicated seems utterly stupid to me. A system should not have a "steep" learning curve, most things should be easily accessible, but not get in the user's way if he does not chose so. I like the way it says in B-Zar's signature "Things should be simple by default, customizable by preference and changeable by design."


Things should be as accessible as they can be, but advanced function should be labelled as such and in case of danger should warn the user - they should not be hidden or require complicated actions.


Case in point, the Windows 7 (or Vista) operation system, it does it best to hide several setting from the user, which probably are not of interest to the common user (but probably should be), but many advanced (not that much) ones and changing them requires you to dig through tons of different dialogues one more misleading and confusing than the other (changing the IP address, disabling several window effects, disabling the search indexer for example).


Obviously not all functions should be visible on the front-page, but properly ordered and labelled (but I would not call this "hiding")


(Also the ESC key is not deliberately hidden, but rather because there simply is no space for it to take up a normal key).


---

I made the suggestion to use the Linux Environment Variables. Easy to set, easy to read and every programming language for the pandora has still support. ;-)

So you did, I missed that. I support this idea.

Yes me, too. It seems like the simplest and best way to do it.

 

[Caine]

If we are going to introduce environment variables for the common actions, may I recommend that we also introduce environment variables for each of the gaming controls. This way applications can bind to the gaming controls without having to rely on the user using a specific keyboard mapping.


This will ease keyboard layout changes in the future (e.g. mouse vs keyboard oriented users) without breaking existing applications.

 

[Christoph.Krn]

I'm sorry, publishing my previous post in its current state was a mistake, and I have to apologize for it. It did not get the polish it would have required. There are too many other things that currently have a higher priority for me.


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).


I do understand that this discussion is not about very specific control scheme elements such as default fire buttons or default jump buttons - I am aware that this would not make sense.


By "hints" I mean: to establish a way to tell the user what button does what in any given situation very intuitively through standardization. For instance: Standardized pictographs at the bottom of each screen that has a menu, similar to those typically found on games for commercial gaming systems; a standardized way for the user to get a button function assignment representation in-game through a standardized visualization, which can be integrated for instance into the other Pandora button function(s) so that the user can get the explanation wherever she is in a game with only a press of the button. More information: read on.

[...] as the Pandora has a similar layout as a Nintendo console (at least the buttons are named the same) we are drawing inspiration from that.

I do understand this, and I also agree that it makes sense.


Navigating a menu may be one of the first things that come to mind when thinking about the effects of missing (or, to be more precise: incoherent) standards, but it is not the most prominent. The most prominent, and I guess you see this the same way, is the "meta-problem" that results from switching between different programs with their own control schemes. Control schemes typically have an inner logic, they make sense, but the typical diversity of games, especially homebrew games, increases the likelihood of mistakes as you get used to a number of schemes. The cognitive overhead associated with this is what causes users to fumble and think, and technology-affine people to wonder about the usability of what they are using. And the best solution to confusing controls is to put them in order, right? Human beings have a selective perception which makes them typically incapable of perceiving a precise enough model of reality. It is difficult to realize that attempting to put the controls in order is not enough. If every developer had a strong incentive to put her own control schemes in a global order, then there would already be a standard or two by now. Since on an absolute level there is not enough incentive, it is a good idea to try to establish the standard in a way that does not require incentive for whichever part of the standard that developers are not showing enough incentive for. Create something that can make use use of the standard and is of high quality and well made, and make sure that as many people as possible can see that it is a good thing.


To create a standard != usability. It is a huge usability problem to rely on adopting a Nintendo control scheme but to ignore that Nintendo-A is Pandora-B and Pandora-X has the same position as non-Japan-Playstation-X but the function of Nintendo-B. If Nintendo-A should typically be "confirm" and Nintendo-B should typically be "cancel/back", then doesn't it make sense for them to also do that on the desktop, and if they can't, then shouldn't the user at least be made more confident in using this uncommon control scheme? Problematic details like these create incentive to change something, but are also responsible for cognitive overhead, flawed structure, and the opposite of excitement.

Then gain, hints are rather unnecessary when all programs control more or less alike or at least the way the user want them to. Now, and I am aware other people have pointed that out, we are only talking about general actions like "menu", "exit", etc. here - no game-specific controls, you may set those as you please, but, obviously, you should also tell the player how you set them up.

I think that hints provide an even greater benefit. The standard can only cover the basic menu navigation, and even standardized menu controls do not always make sense, so application of the standard is likely to be either limiting the developer, or limited itself - depending on how the developer decides. Plus, developers, in their role as game playing people, are often likely to prefer one of the well-known standards over others themselves. And this is with the premise that all developers are aware that there even is a standard, which may or may not be the case - the less visible the standard, the less likely that especially novice developers will immediately know about it. For these reasons, it is not a good idea to assume that most developers will default to a simplified "logical searching for and adhering to the standard" mode (even though that can happen) even if that standard only allows the user to set her preferred buttons.


I think that to be able to establish a standard (which is very important for (future) flexibility), hints are important. Because of their high visibility, not only is their standardization quite easy to spot for a novice Pandora developer (as long as the hints are easily recognizable, which requires high quality), but also is their absence from a game likely to be criticized by users /even if only few games are making use of the standardized hints yet/ (and in this context, developers are users, too!), which makes it likely that they will be implemented in more of the games that are yet to come (in effect increasing the likelihood of widespread support for the menu button assignment preference standard and the menu button assignment default setting).


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

Sorry, but I have to oppose this mapping.

No need to say sorry as this is very appreciated. This topic can greatly benefit from a wide insight.

A lot of existing software would need to be changed if the layout is now modified.

As foxblock said, one can not take as granted that one will be able to make old PNDs aware of changed default controls, but new PNDs (more precise: all PNDs which adhere to the new standard) can be made aware that there is a new way available in which they can interpret the old defaults.


But this is not really what a decision should be based on; instead, it is better to think through what /could/ be and to defer any doability evaluation. Everything else forces one's ideas to be average by definition, which means that the results of these ideas are unlikely to be much better than what already exists.

[...] you introduce redundant mappings (B/enter), X/FN+q.

This is not necessarily a bad thing, as long at it can be done in a non-confusing way and does not castrate functionality. In this particular case, it is even likely to allow more people to do more things without having to relocate their fingers to the keyboard or screen (if it can be done right).

[...] I use home/end/pageup/pagedown a lot more than I use mouse clicks and personally prefer the current layout over what you have proposed.

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".


--

As someone who uses the keyboard more than the mouse, changing the nub/game key configurations like that is not something I can agree to.

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.


See also: the Home/End "solution" at the beginning of this post and "First Rule of Usability? Don't Listen to Users".

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.


Thank you for sharing the information.


What exactly is it that makes the current Home/End/PageUp/PageDown configuration so useful for you in comparison to other solutions? For instance, do you typically hold the Pandora in your hands or use it on a table? Are you switching between keyboard and game controls frequently? What other uses do you have for the current configuration? See also: the Home/End "solution" at the beginning of this post and "First Rule of Usability? Don't Listen to Users".


--

Okay, first of all I have got to say to me your post comes across rather arrogant and condescending.


(...)


[...] and lastly you assume that you will receive negative messages about your proposal not based on facts, when, in fact, you did make that proposal mostly from assumptions and experience yourself, which is perfectly fine as there is no objective way solely based on facts to create such a standard.


That negative attitude probably was not your intention, but this is how it came across to me.

First of all, please excuse some ignorant nitpicking: I would like to say that I wrote that I did _not_ assume to get this kind of reaction even though my experience suggested me to do so (which is the truth). However, if you understood it wrong, then I have expressed it in a wrong way, and failing to realize that was an extreme mistake.


Human beings usually aren't aware that, as they reflect on a significant change that has just been proposed, their thoughts typically have already been colored by their emotions on that change, by their past experiences and their low-fidelity memory. This can cause their focus to lock onto specific thought structures that are possibly non-rational (non-logical). What is absolutely required in a usability discussion however is that people attempt to convert those "lower layers" of thinking and acting into a web of facts that, upon being expressed, represents a fuller view on reality than a non-analyzing statement, and thereby enables other people to become more aware of what to do and what not to do.


Attempting to say this the way I did was an extreme mistake that should not have happened, and "basis in fact" was a stupidly chosen term. Replace every instance of "in fact" in my previous post with "in logical analysis", and you get a better idea. You are right that showing a negative attitude was not my intention. That would be highly inefficient.


Thank you for your feedback!


--

Things should be as accessible as they can be, but advanced function should be labelled as such and in case of danger should warn the user - they should not be hidden or require complicated actions.


Case in point, the Windows 7 (or Vista) operation system, it does it best to hide several setting from the user, which probably are not of interest to the common user (but probably should be), but many advanced (not that much) ones and changing them requires you to dig through tons of different dialogues one more misleading and confusing than the other (changing the IP address, disabling several window effects, disabling the search indexer for example).


Obviously not all functions should be visible on the front-page, but properly ordered and labelled (but I would not call this "hiding")

It is indeed stupid that changing the rights of a file sometimes forces the user to skim through the tabs of four dialogs to reach the desired action, and then possibly to close and re-open them. But this is a too narrow interpretation of the topic. Many of Microsofts problems are a result of legacy things that were, for whatever reasons, not done right at first, and this is likely one of these.


Now, I'm aware that was just an example, but an attempt to make things accessible by making many of them more visible is always very likely to decrease usability for novice and advanced users alike (See "Benefits of Progressive Disclosure"). I am not sure if we are thinking the same and just understand the term "hiding" differently (to understand the term "hiding" differently != to have different definitions of "hiding"). My definition of "hiding" is probably more extreme than yours.


--

- mouse focus vs keyboard focus. I cant see a pool save this. There is only one way : having a benevolant dictato that choose for us (like the big company do). But OPT already have done this decision when setting up the OS. Case should be closed. Yet as there are unhappy people, we'll have more of these useless posts to come.

Combining mouse and keyboard into an emergent system that is immediately logical and non-confusing is the best practice default (as long as it's of high quality). There doesn't have to be any emphasis on either mouse or keyboard, they can be combined.


For instance, it doesn't make sense for the Pandora button to open the menu in Xfce because the menu is located in the corner by default where it is extremely easy to reach using the mouse. One could argue that using the mouse still requires more effort than pressing the Pandora button, or that some people prefer pushing the button over using the mouse, which is both true, but being able to assign another function to the Pandora button that adds a completely different benefit can be more important if the rest can be consolidated into a useful system.


No matter what your personal preference is, there are both people who prefer the mouse AND people who prefer the keyboard. Both have to be taken into account, and even if there was a semi-magical standard that managed to maximize the benefits for both groups, it would probably be bloat. The default configuration should make sense and be non-confusing, if possible while creating emergent benefits. Mouse-focus vs. keyboard-focus has to be be a user-configurable preference for the advanced (which it already is).

- Not all the emulated system use the same standard. how to standardize that ?

Since the original game experience is typically increased by preserving the originally intended control scheme, it does not make sense to standardize controls for emulated games. But if the developer succeeds in making this clear to the user, then he (the user) will likely understand, and any remaining additional frustration or confusion is likely to almost vaporize over time. The user might even start to appreciate the missing standardization in case he did not already do so.


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

A system should not have a "steep" learning curve, most things should be easily accessible, but not get in the user's way if he does not chose so. I like the way it says in B-Zar's signature "Things should be simple by default, customizable by preference and changeable by design."

That's probably because his signature is right.


It was "steep when required" (in other words: "flat unless you want it to be steep") vs. "inevitably steep". I should have made that more clear, sorry.

(Also the ESC key is not deliberately hidden, but rather because there simply is no space for it to take up a normal key).

I meant that the Esc key is typically a hidden function since the typical Pandora user interface has no hint to its function (which is a good thing as long as there are other visible means to quit the application that make sense).

[...] making something deliberately complicated seems utterly stupid to me.

This applies to situations where people /create/ as opposed to /consume/; "complicated" in the sense of comprehensive. It was not meant to be related to the rest of the usability discussion.


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


This post may contain nuts, make you go nuts, or be nuts so important after all.

 

[Prometheus]

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).

I really don't know what to say to this idea other than "Are you joking?". I'm really sorry, I honestly cannot see this working - it doesn't sound even remotely usable. :mellow: Would you mind explaining how this is superior to being able to quickly press one button (which as it is, doesn't have overlap with any existing keys), so as to facilitate those who want duplicated keys in positions that make no sense, please?

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.


Thank you for sharing the information.


What exactly is it that makes the current Home/End/PageUp/PageDown configuration so useful for you in comparison to other solutions? For instance, do you typically hold the Pandora in your hands or use it on a table? Are you switching between keyboard and game controls frequently? What other uses do you have for the current configuration? See also: the Home/End "solution" at the beginning of this post and "First Rule of Usability? Don't Listen to Users".

You didn't understand me correctly. The menu-navigation was just an example, as that was what Stan had mentioned.


However, I should point something out: Aside from being a seamstress, I do a lot of writing (when writing on my Pandora, I thumb-type, ridiculously quickly at that, and I make heavy use of Home/End/PgUp/PgDn when navigating works in progress, though this is the same on the *extremely* rare occasions when I use it on a table, too). Change that configuration in Xfce (which I understand would affect the whole of the environment - I use Xfce daily and I seriously don't know of any way that it wouldn't), and I can no longer work efficiently and the Pandora becomes an infinitely less useful tool. Your suggestion of holding d-pad directions (already mapped to the arrow keys) in combination with what I assume would have to be perfectly-timed nub movements doesn't sound at all suitable to me - it doesn't sound logical at all, compared to having Home/End/PgUp/PgDn in a quite intuitive diamond configuration opposing the arrow (navigation) keys.