Open porg opened 11 years ago
I'm honestly a little iffy on having this sort of persistent help context. I can understand the appeal, especially when coupled with the kind of UI polish seen in PNDManager, but I'm having a hard time imagining how to integrate the information on screen without making things more muddled/noisy rather than more pleasant.
Perhaps (probably?) a full QT interface ala PNDManager would have been better received in general, but I didn't want to build or use that. ;) I just wanted a simple emulator style selector and menu system for all my games.
Not that I'm actively opposed to this, just iffy.
If the problem statement is "what do I press to do xyz?" then perhaps a help key (maybe '?') bringing up a contextual table of valid keys would do well?
In your rather dense interface, I understand that there's little place for info overlays as desired by FZERO. A "?" in a corner is a good idea (is your app mouse/touch-aware?):
Will go with the showing the help page overlay on '?' for now.
This feature might also pave the way for presenting more verbose contextual help text in the future.
I used a way around the space usage in Pandora Clock : having a small bar at the bottom that you can activate to remind the user if they forgot how the buttons are assigned. That is less intrusive and does the trick.
This is essentially the idea proposed above. Pressing the '?' key would activate a contextual help overlay. Additionally, a persistent, touchable '?' icon/text in the lower left would serve as that "small bar" call-to-action for new users who are lost. Should also be possible to turn this off.
I personnally dont think a touchable "?" is a good idea. Pandafe is a keyboard driven software, it's very confusing if suddenly you have to use your stylus or your finger to do something else with the soft. For that's the opposite of UI consistency.
And mapping "?" is a bad idea too since it;s not directly mapable to a single key press (it's a combination on Pandora). Its better to use the space bar or H or something else.
I agree that the touchable part is inconsistent. I included that because porg proposed it specifically, presumably because folks might try touching it if they were really at that much of a loss.
The only purpose of that on screen '?' (or whatever) is to provide a persistent visual cue that there is help available. If you have to press a certain key to activate it, but a visual cue is not present, then we've not helped much because you have to come armed with knowledge of that key.
The appeal of just '?' (perhaps drawn in a box to look more touchable/actionable) is that it takes up very little screen real estate.
A possible alternative to this approach: add additional screen wide line of text at the bottom of the screen, visually distinct that says something like "Press '?' to display contextual help (and hide this message)."
This would be present on first run and persist across every screen update until the user pressing the key. At that point it will disappear. The user will have learned that they can get help via that key, which should be sufficient.
On next run that help text bar would either:
What do you think of that?
BTW, Space and H are already used (context menu, and dynamic filtering on alpha keys). I don't personally see a problem with needing to press a modifier + key to get help, especially with that help text bar approach and since pressing key modifiers is a pretty regular part of using the Pandora. I also think its intuitive and easy to remember as a way to get at "what do I do here."
OK, in bullet points:
Another observation regarding naviguation. I would advise remapping the naviguation A/B to the digital pad. Because it's natural to have up/down/right/left mapped to the digital pad, and confusing to have A/B acting as left/right directions. I understand the purpose to separate the two but I feel it's counter productive and it caused me several times to press the wrong button or direction because that's just different from what I would naturally think in terms of mapping.
Another thing is that B serves not only as naviguation but as execution when you reach the game you want to launch. This is, again, inconsistent mapping since a single button can act as navigation and execution. If you look at the xfce menu, for example, you can use right left to do deeper into the tree system but you can never execute a program by going right in the end. I believe, here too, that the execution button and browsing down the tree should be separated.
Having a reference when showing the help is better than nothing but in the first place, the confusion comes from mapping issues which are not like other programs. I'm not saying all programs need to be the same, but in this case it would be beneficial to remap things a little.
Regarding the debate of what the best controls mapping is, my solution is to this is to make them customizable (see #6). Further discussion on that topic is more fruitful there.
START/SELECT/Triggers are also already in use.
As far as the best way to make it clear how to get help, at this point I think I'll just try one or more of the proposals we've discussed, choose one that feels pleasant to me, release it and see what people think.
Its going to be a bit before I can get to the actually implementation after all. ;)
I'll have to go to the other topic, but rather than full customization, a good intermediate is always to think about "control schemes" where you let the user device among 3-4 options for controls. :) Think video games, they never provide full customization but usually there's always something one will feel comfortable with among the few mapping proposed.
Customization first, schemes would need to be a subsequent specialization. The mappings also need to be displayed in the help overlay for this issue.
Positive example: PNDManager