GP2X Should Developers Follow Common Design Guidelines

[Titousensei]

I've post a list of Common User Interface Recommendations in the wiki.

I'm wondering if developers and users are interested in this kind of recommendations. Do you generally think it's good to have common development practices, even for homebrew development?

Thanks.

EDIT: Can somebody please edit the poll question and remove the link, it doesn't print properly.

 

[RiX0R]

I think this is a good idea, as one of a few other things that developers should standardize on.

I will look through the proposals now, and hold off voting until I have read them (it'll be option 1 or 2 though ).

I do hope you're not proposing following GPH's current "standard", because I find them... lacking. Most of all, I'd hate to see the START button being adopted as the "kick you out of the game pronto" button.

Start is for game starting and pausing, not quitting.

Edit: First comment under Definitions: I think it'd be clearer if you switched the definitions of may and should (maybe that was what was intended). Right now, "may" is a stronger requirement than "should".

Edit2: Huzzah! I completely agree with the spirit and with the letter!

 

[skeezix]

"Should" depends on how agreed upon they are; its too early for a poll, since if you just made up the document no one has seen to it, agreed to it, modded it etc.

Anyway, some conventions are a good idea, but of course everyone is free to ignore them.

The important thing is "not to go too far" - if you try and nail down too much, the document will not be useful or used.

ie: I wouldnt' go so far as to say "the stick click must do system functions" - no. Stick click may be annoying to a lot of peopel with heavy hands, and it may be used by emus with a lot of things to do so that things can be done..

Stick to basics.

ie:

Start _should_ (not "must".. must is never correct) bring up a main menu or dismiss it. While a menu is up, joystick should be used for navigation. Simple stuff like that.

Dont' go into "stick clicks", since then oyu're way overstepping your bounds.

jeff

 

[RiX0R]

(not "must".. must is never correct)

That depends. If we're after verifiable conformance (viz. the logo), then some "must"s are required, otherwise the spec is void.

Whether we really want CUI-conformant games, with compliance logo and all, is another discussion completely, but I think the idea is ambitious and worth pursuing.

No one is required to follow the spec, so having one around for reference is in no way detrimental; but it might encourage best practices and more thought put into the UI. At the very least, we have the first draft of a spec lying around to discuss and improve. If it's not perfect now, it can be improved with enough developer and user feedback.

How about replacing the stick-click with the R button? Or allow both for system functions? The spec can always be weakened by individual developers.

 

[skeezix]

Why bother with specifying system functions at all?

ie: Spec v1.0 should be to get apps up to a minimum similarity.. but I'd avoid to go overboard since it may alienate apps from getting the buttons they need.

ie: Without thinking ahead at all, I expect to use a lot of buttons in CaSTaway; different operating modes, binding keys to the ST keyboard, handling the mouse and joystick, all sorts of stuff.

So using too many keys up for a spec means the spec will not be used at all; I coudl easily confirm to your basics, since they're spot on with what I planned to do anyway

I don't have my 2x yet, but on the PSP for instance I have START toggle on the main operations menu (which in turns allows for clock settings, display modes, runtime modes etc etc), and SELECT toggles on/off the onscreen ST-keyboard; in various runmodes some buttons may act as keyboard bound keys, joystick directions or buttons, mouse directions or buttons, or magic machine effects; as you can imagine, I want to hold onto a lot of buttons for myself without "losing them" to a spec

jeff

 

[Titousensei]

[...] its too early for a poll, since if you just made up the document no one has seen to it, agreed to it, modded it etc.

In my experience, having a first draft helps a lot focussing on specific issues, as opposed to open-ended discussions on peripheral ones.

The important thing is "not to go too far" - if you try and nail down too much, the document will not be useful or used.

Agreed. I'm not sure what too far is, though, since even the existence of such recommendations seems to be controversial.

ie: I wouldnt' go so far as to say "the stick click must do system functions" - no. Stick click may be annoying to a lot of peopel with heavy hands, and it may be used by emus with a lot of things to do so that things can be done..

I'm taking notes of all the comments and I will add / remove / modify recommendations when there seems to be agreement on a particular topic.

I would certainly welcome more comments about what feels confortable for different sizes of hands, as I have only one to test with myself

On the particular point of Stick click & Start, it was a tentative to get an unintrusive way of accessing global functions (such as exiting the game) while being compatible with native games, emulator and generic applications. It is also quite safe because it cannot be triggered by accident, unlike single-key exit functions.

If you don't need system functions, this recommendation should not bother you because you're not going to implement it. But if you do need system functions, you're going to ask yourself how to present that to the user. You can either reinvent the wheel and implement a new, different, way every time you need such a function. Or you can invent it once and do the same thing again next time you need a similar function.

The CUI is only suggesting that if you need such a feature, you will most of the time follow the same design pattern and reuse what you did before. Adding this recommendation to the CUI will not put any constaint on you, but might very well save you some design time because you will not need to invent something new. Plus, users of your application will already be familiar with the procedure.

Accessing system functions such as exit seems to be a generic enough to have a common recommendation for all applications. I tried a few applications and here's what I've found: the snes emulator (great app, BTW) exits when pressing R, others exit when pressing Start, other exit by pressing B or A, other by pressing L+R. Of all those, my favorite is L+R because I know I' have less risks of exiting the game by mistake.

From a coding standpoint, it's not harder to test for one combination of keys or another: if the function is needed, the test will be implemented in one way or another. A CUI tries to capture the most probable features you'll need to implement and give you one solution that other like the most. It's like looking at source code to learn how other implemented sprite collisions, only for usability.

Best,
Titousensei

 

[Oscaruzzo]

I think this could be useful. I don't know if something should be changed (i actually have never had any console before the gp2x) but some coherence is a MUST.

At the bare minimum, the volume regulation should work, and there should be a common way to quit a program and get back to the gp2x menu.

Of course, the most desirable solution would be configurable controls...

 

[Titousensei]

Answers to a few specific questions:
- the usage of "must", "may" and "should" is consistant the what's used in similar documents such as RFCs and specs in general, AFAIK.
- the logo is not intended for compliance or certification. it can be used to tell the user the app is follwing familiar usage patterns. There will be no such things as CUI certifications! The CUI is just a list of usability examples.
- the CUI will never be a silver bullet for all applications. If a particular recommendation doesn't feel natural for your application or game, do what you think is right, the CUI is not the boss of you! That doesn't mean the CUI is not right for most applications and should be changed. And yes, you can still use the logo if you think you're close enough.

Edit: you're right, the definitions of "may" and "should" should be inverted. I'll edit the page accordingly. Edit2: Done.

 

[skeezix]

I think a good guideline is a good idea; this is certainly a good start, and I do agree it seems best to lay something down to fight over. I do think minimal is better as mentioned above of course

L+R is quite common for exitting an app, rebooting, or at least returning to menus; theres s long history in snes, gba, gp32, among others.

jeff

 

[Guyfawkes]

One thing to point out is that Japan and other countries traditionally use B and X as primary and secondary buttons compared to western countries using X and B. Its especially noticeable in the GP2X as the B button is used as primary in the menu system.

 

[RiX0R]

I think especially the sync issue is an important one.

I've lost a good deal of progress in the Zelda II NES game because my batteries ran out, even though I'd saved regularly.

I think games should give the user a choice to Save or Save Synchronized, if possible.

 

[blinky465]

Whatever the finer details are (which button combinations are used to perform which actions) I think that conforming to some form of consistent approach will be a good thing.

In reply to "....I'm wondering if developers and users are interested in this [sic] kind of recommendations. Do you generally think it's good to have common development practices, even for homebrew development?" I would say yes, very interested, and I hope other developers follow suit.

The GP2X has been designed (it seems) with homebrew developers in mind and if you asked 50 coders the best way to implement an idea, you'd probably get 50 answers! Players should be allowed to expect their console system to behave predictably - and the only real way of achieving this is for us developers to agree on what this predictable behaviour is, and how we're going to implement it.

 

[Morwynd]

I do hope you're not proposing following GPH's current "standard", because I find them... lacking. Most of all, I'd hate to see the START button being adopted as the "kick you out of the game pronto" button.

Start is for game starting and pausing, not quitting.

Another big problem I have with GPH's "conventions" is the use of the Right and Left shoulder buttons as Next/Previous Track buttons. They're too easy to hit accidentally when picking up the unit, thus losing your spot in the current movie or song. GPCinema used the shoulder buttons for Fast Forward/Rewind, and that was perfect.. didn't matter if you bumped them.

But yes, in general I think trying to define some common interface guidelines is worthwhile.

 

[karmacop911]

this is silly. no, i mean, seriously - what's the point. you'd call this, with all those preconceived conventions, "free" development? :rolleyes:

better if you at least call them "suggestions" rather than "guidelines" - and present them as opinion based on some evidence... not "official"...

 

[DaveC]

I've post a list of Common User Interface Recommendations in the wiki.

I'm wondering if developers and users are interested in this kind of recommendations. Do you generally think it's good to have common development practices, even for homebrew development?

Thanks.

EDIT: Can somebody please edit the poll question and remove the link, it doesn't print properly.

​

Could you add joystick bias types to the wiki? I would do it but I don't know how :blink: I have played many games with the default and it seems to want to hit a diagonal when you don't want it. We should suggest that the CASE 2 style be used or an option for emulators which benefit from orthagonal bias.

Case 1 would be good for any native games but also games that used analog or trakballs like Centipede, Missile command, or for emulating mouse movement like in ST/Amiga

Case 2 would be the ideal and recommended one for use in emulators and any game requiring traditional 8-way control. Typical 4-switch, 8-way controllers always were easier to hit the orthagonals (horiz/vertical) than diagonals. This is because it is harder to keep 2 switches closed simultaneously than one. This would include, Atari-2600 type joystick, Nintendo cross pads, PSX pads, MD, SNES etc.

Case 3 would be useful for those isometric oriented games like Desert strike, Zaxxon etc that are mostly diagonal but still use some vertical/horizontal.

Case 4 would be useful if you wan't to get pissed that your character stopped moving and you got killed. You just have to ask yourself, do you feel lucky? Hit the dead zone at the wrong time and well...you're dead. This is for those that think games are too easy and want an extra challenge

Case 5 Horiz/vert 4-way. Useful for 4-way games such as Pac-man Thick purple lines separate directions for visualization. Anything from sw8 to sw1+sw2 would be "UP" and so on. Must be slightly rotated to make all zones even in size. I picked the rotation this way as it folows the arc your thumb would make while playing.

Case 6 Diag 4-way. Useful for 4-way diagonal only games such as Q*Bert. Thick purple lines separate directions for visualization. Must be slightly rotated to make all zones even in size.

Developers should think about these different configs, and include in the menu option screen a choice between a couple. MAME for example would be able to use case 1, 2, 3, 5, 6. Megadrive and most other emus would probably only need case 2. Atari-ST would use case 1 for mouse and then switch to case 2 using joystick mode.

 

[slygamer]

Done. http://wiki.gp2x.org/wiki/Suggested_Joystick_Configurations

 

[RiX0R]

I was under the impression that the joystick only registered 8 directions at the hardware level.

Are there really 16 physical directions to choose from?

 

[Oscaruzzo]

I was under the impression that the joystick only registered 8 directions at the hardware level.

Are there really 16 physical directions to choose from?

​

There are 8 hw "sensors" (N, NE, E, SE, S, SW, W, NW) but they are slightly overlapping, so at some angle you can activate, for example, N + NE which can be considered as an additional direction NNE.

 

[xafier]

Personally I think most of it is pointless, people will follow whatever conventions they like... and for emulators its just plain pointless... for homebrew games it might be ok though...

 

[digitaljez]

Of course it is not pointless. The point is to provide a familiar interface across applications so the end user can get on with using them without having to learn yet another control system. Imagine if every dev for a GUI assigned different functions to the window controls. The end user would never know if they were about to maximise, minimise or close an app. This standard (once finalised) will make the GP2X a more accessible platform and can only be a good thing.
It is obviously not going to ensure a higher quality of software, but the end user will not be frustrated by unfamiliar controls and will be able to judge the app on its functionality rather than its user friendliness.
There is no reason why the interface of an emu could not comply.