Talk:Common User Interface Recommendations

Please add you comments here. I expect comments on the following subjects:

• relevance of the page in general: obviously nobody can force you to follow these recommendation when you code your game, but I think following these rules will make the difference between an amateurish console and a successful platform.
• relevance /adequacy of a particular recommendation: of course we can have different opinions, but we should be able to agree on a minimal common ground.
• missing recommendations: we don't want to make the recommendations too hard to follow or nobody will follow them. Usability should be the the guideline.

Again, these are only recommendation, not rules written in stone. --Titousensei 20:05, 1 December 2005 (GMT)

---

Bringing this up w/o duscussig it with the dev scene itself is just stupid. The wiki is no pace for fancy ideas and things in question to be useful or still in the beginning. If you want to discuss the possibility of a CUI discuss this first somewhere else with the majority of the devs. If it's done come back. DELETE REQUEST

- Synkro 09:19, 2 December 2005 (GMT)

As a a professionnal developer myself I follow this kind of rules, which are part of the best practices recommendations in the industry for coding, as well as for design usability. I will follow similar guidelines for my GP2X development and I wnated to share this with fellow GP2X developers. This wiki seems to be the best place to discuss it. Synkro, namecalling is not necessary, and I'm finding that you're spending a lot of energy criticizing other people's efforts to organize and participate in the GP2X community, and I wish you were as active producing something useful. I'm setting up a poll in http://www.gp32x.com/board/index.php?showforum=45 to bring this to a larger audience.

--Titousensei 19:35, 5 December 2005 (GMT)

The poll has been going for 2 days now, and it seems pretty clear that the CUI initiative is welcome. At the time of this writing, the results are:

 What do you think of the proposed Common User Interface Recommendations?
 Good idea, I hope everybody will follow them for higher quality software               [ 17 ]  [50.00%]
 Interesting, but the proposed recommendations should be changed                         [ 5 ]  [14.71%]
 I might follow the recommendation but I don't think it will improve the games quality   [ 4 ]  [11.76%]
 Useless, I don't think anybody will care                                                [ 6 ]  [17.65%]
 Stupid, nobody will/should follow these rules                                           [ 2 ]   [5.88%]

Total is 34 votes, to compare with 224 registered users in the wiki.

During the poll, people suggested modifications, simplifications and improvements to the CUI. I've captured most of their suggestions in the following list and we can discuss individual topics here.

Please don't edit the article page for now.

--Titousensei 01:26, 7 December 2005 (GMT)

---

skeezix: 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.

• As I answered in the forum, if you don't need to provide access to system functions, this is not a problem for you. But if you do and there is no recommendation, you'll have to invent something new. And the 2nd time you need it, I bet you won't invent a different one: you'll re-use what you invented the 1st time. The CUI is merely capturing that so you have an example of what other people are doing in a similar situation. (Titousensei)

Oscaruzzo: 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.

skeezix: Start _should_ (not "must".. must is never correct) bring up a main menu or dismiss it.

RiX0R: How about replacing the stick-click with the R button? Or allow both for system functions?

• R + Start is hard to punch because it's using the thumb and finger of the same hand. Stick click + any right-hand buttons is more ergonomic. (Titousensei)

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

• I have to disagree on that. With (user, I assume)-configurable controls, it's either having no predicatable behavior, or using the default settings most of the time (which is the the whole point of the CUI: having reasonnable default settings). (Titousensei)

skeezix: 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

• Applications using L and R for something would be forced to find an alternative key combination for exiting, or will make the user's life miserable because the app would exit all the time. (Titousensei)

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.

• FYI: the snes emulator is remounting the SD card in sync in the last version. (Titousensei)

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

Morwynd: 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.

Bender: B or A must be used for the primary action

• Changing "B must be used" to "B or A must be used" is changing more than it looks like. The first version says that I know exactly what wil happen if I press B. The second version says that one of A or B, or both, may be handled. With the second version, I can't tell which button I should press. RiX0R proposed to add to the first version something like "A may also be used to to select the highlighted menu item". Or "should be used". Personnaly, I don't have strong emotionnal attachement to either buttons(!), but I care for consistency: GP2X menu is using B, most games I tried are using B also for menu selection. If people want to use A _also_ for menu selection, I'm fine with it, but having at least B handled properly seems unavoidable. Proposing duplicates and shortcuts is fine, but there should always be a consistent default behavior. (Titousensei)

DaveC: Alternate use for volume control: Can be used in vertically oriented games such as MAME games like Donkey Kong, Pac-Man etc. as action buttons. When in this vertical "portrait" mode volume will not be effected.

• That's an excellent suggestion, I'm leaving it in the CUI. (Titousensei)

xafier for emulators its just plain pointless'

• As stated in the CUI, emulators will obviously run whatever game was selected and the buttons behavior will follow. But there's more in the CUI than just key mappings: Self-contained applications and Saving recommendations are also important to give a satisfactory experience for users. With regard to keys mapping, though, I think the recommendations that apply (system functions, for instance) are especially important. For emulator even more so than homebrew games, because common features like reset, bringing up a rom selection menu, debugging screen and exiting the emulator are very common. Many times I've been stuck in an game without knowing how to exit. You try to avoid turning off and on the machine when you have 20+ seconds boot time. (Titousensei)

Early Comments

Having a CUI is very good thing, and I hope that all developers will follow it. As a games developer myself, I have to meet the manufacturers TRCs all the time, and I can tell you that they are a lot more particular and exacting than these recommendations are.

I would recommend adding some references to button usage in menus. For example, B button to select a menu item, and X button to cancel or go back to the previous menu. This is consistent with the gp2xmenu.

Volume control is mentioned twice in the CUI and is inconsistent. Choose one and remove the other. --slygamer 23:21, 1 December 2005 (GMT)

Good points. I merged the two volume control entries into one more consistent. I also added button actions recommendations for menu screens. --Titousensei 23:42, 1 December 2005 (GMT)

---

• Bringing Standards to homebrew failed already a long time ago. I know that it is useful, but for me as dev I just don't care. This will be a waste of time. - Synkro 09:10, 2 December 2005 (GMT)

Synkro, maybe you should care. Think of it this way: these are not constraints but guidelines that will make the user of your program confortable. Unless you think usability doesn't matter at all, this is merely an attempt to all agree on the same usability rules so you don't have to re-invent your own usability model. Again, you're free to develop any way you want, but do you at least agree that a game should start and pause when you press the Start button and not, say, the Y button? --Titousensei 17:43, 2 December 2005 (GMT)

Also, I'm not aware of any standard attempt to homebrew development, even a long time ago. Even if there was failed standard attempts, maybe they were not done right, that doesn't mean standard for homebrew is not a good idea. This is a matter of choice: if you want high-quality finished games for the GP2X, following some sort of CUI is important (and since it's homebrew, without much time for QA and bugfix releases, opening the sources is probably important too). On the other hand, if you're happy with barely playable, proof of concept games made by one guy on his free time, that's fine too, you don't have to join the effort to put more polish on homebrew games. --Titousensei 18:01, 2 December 2005 (GMT)

Sync

using the sync() system call would be better than system("sync").

-rhk

Or just remount the filesystem in sync mode before starting your app. I wonder why this isn't done anyway. (no_skill)

The filesystem is mounted in async by default for a reason, I believe: flash memory has a limited number of writing access, and sync uses it too fast, so all writes are buffered and done in one shot just before unmounting the device to make the flash last longer. Always mounting it in sync would possibly reduce the lifespan of the SD. However, when JFFS2 devices are mounted in async, the data is not written until umount or sync, which is a problem in a portable device where power can be turned off at any time. That's why I was asking if anybody has experience with flash and portable devices and what they recommend in our case. --Titousensei 18:21, 5 December 2005 (GMT)

Hm... my sd card comes with a lifetime warranty (my lifetime, not the cards), so i guess rewrites isn't such an issue. in a device that can be turned of at any time the syncing is a huge issue (as i usually neither unmount my sd card nor even exit the emulator after saving), so i guess setting it to always on is the only reasonable thing.

didn't the gp32 do the same? (no_skill

I think using a sync is the better of the two. IMO any apps should interfere as little as possible with the underlying linux system. Even though it's unlikely but what happens when the user is running another program alongside your app that is either accessing the sd card so you can't remount or is accessing the sd card in such a way that using sync mode effects performance? Xyz

no_skill: Jup! and another thing less to consider when porting. Btw: I just killed my saves in SNES by switching off after saving and playing a bit. damn!

I've read (relating to automounting of USB devices) that sync is not supported for FAT filesystems in Linux - so it's a moot point. Apps ought to call sync themselves at appropriate times, anyway - it's not that hard. --Gfoot 03:41, 23 December 2005 (GMT)

---

Default Button Behaviour

Using the default button behaviour (ie: left button accepts, bottom button cancels) would benefit usability as people are accustomed to this from other consoles (SNES/NES/...) (no_skill).

Did you mean to say right button accepts? (out-most button) --Titousensei 18:21, 5 December 2005 (GMT)

No, I meant: (looking at my gp2x): A = YES / GO / START. X = NO / BACK / EXIT

I see. The GP2X menus and applications uses B for action and X for cancel. A and Y are not used. Also, I find A harder to reach than B with the GP2X layout: with the GP2X button layout, the equivalent of A(GP32) would be B, and the equilent of B(GP32) would be X, in terms of buttons position. This is consistent with the proposed behavior. --Titousensei 20:02, 5 December 2005 (GMT)

What? (no_skill)

Maybe this will make more sens: (Titousensei)

Since the CUI leaves the A button for menu's unspecified, you can simply opt to bind both the A and B button to select. That way, the interface is still CUI compliant but also intuitive for users with previous conventions. It should be allowed to weaken the contract. Also, although I've been using B to select because of GPH's menu, I find the A is easier to hit, with less strain on my thumb. (RiX0R)

That's definitely a possibilty for menus. (Titousensei)

hmm... taking a look at a snes controller [1] i'm baffled. i remember it... different. somehow for me the most left button was always accept and the down button was cancel. weird. how is it with modern controllers (ie: ps2, xbox?)

---

The "other consoles" argument is moot. There are so many other consoles and they all have different default buttons. For example, for the PS2 the default is cross (bottom) for select and triangle (top) for back, and for Xbox it is A (green, bottom) for select and B (red, right) for back. GPH have set a precedent in gp2xmenu by using B (right) for select and X (bottom) for back. So everyone who uses the GP2X knows that behaviour. For original applications, try to use the defacto GPH buttons. For emulated applications, go ahead and use whatever was the default for that system. I'm using the GPH (and current CUI) behaviour in my original applications. --slygamer 03:18, 6 December 2005 (GMT)

As the button naming may be ambiguous the layout is not (ie: top left button accepts etc). at least i think so.

---

Controls Help Button? I admit, I'm not usually a console programmer. Still, is there a way that we could specify that the 'select' or some other button bring up a list of the buttons and controls actually in use for this game? What about some common code snippets to make it easy to link into a game. Even just a guideline that the controls be somewhere in the game would be good. Gizbot 14:04, 4 February 2006 (PST)

This is what Start & Select is proposing. --Titousensei 12:12, 5 February 2006 (PST)

Using externally accessible savegames

Wouldn't it be more useful to have a standard for "externally accessible" saved data (as in the Sony Playstation or Sony PSP)? By "externally accessible" I mean savegames that can be managed (copied and/or deleted) by an external application either on the GP2X itself or on a computer (again, see Playstation/PS2/PSP firmwares for more examples of this).

Also a centralized language chooser for games with different localizations would be nice, wouldn't it? (And it would be as simple as "echo it_IT > /etc/UserPreferences/PreferredLocale", with games reading the PreferredLocale file to know what language to use without having to ask.)

An ugly proposal can be found in the (ugly, stub-ish) GP2X Filesystem 'Standards' article - l0ne

CUI compatible logo

Just drew a few variations on Titousensi's logo, I attempted to make a smaller one, not really a success though:

(1: 42x12; 2: 33x9 without shadow; 3: 27x6; 4: 20x6.)

--Taras 19:25, 19 December 2005 (GMT)

Existing Key Combinations

One thing I've noticed that's lacking from the recommendations is a mapping to the default functionality on the system. For example:

• Start returns you to the start menu of the system
• Y causes an "in application" menu to appear (cf the video & music player) whilst the system is running. This is modal and allows to change behaviour. I'd prefer this to be "select" though.
• Left trigger/button is uniformly "previous track/video", right trigger/button is "next track/video/picture".

I'm not saying these are ideal, but they're what we've got as a starting point. (NB, I'm coming at this from the perspective of someone using this for not just games. For in-game usage, IMO completely different recommendations could apply)

Whilst all recommendations are just that, recommendations, I suspect they have greater success of people picking up on them if they match usage :)

If I'm blind though and just plain missed an existing page, that's fine. If it isn't there though and people think it's a good idea, I'll happily document the existing behaviour.

- Zathras 11:27, 20 December 2005 (GMT)

I believe this is covered:

• Stick click & Start must be used to exit the application, meaning: go back to the start menu of the system
• Start must be used to start and pause the application; when paused, the application should display an application menu, in the case of a music player, for instance, the music can keep playing, but in a movie player, it probably makes sens to pause the movie when displaying a menu
• L and R may be used for actions related with 'left' and 'right' concepts and orientation in general, this is also valid for previous and next

I totally agree that the recommendation should not try to change people usage, but rahter to list the most common practices. The only recommendation for which it's not the case is precisely for system functionnality, because I couldn't find a common pattern in existing games and applications for this. An added difficulty is to always use the same keys without conflicts with the application/game controls. This is why I proposed a Stick click & key combination: this is the most unintrusive and secure way of invoking system command, and it's still fairly intuitive when you know that the Stcik click is for system commands.

--Titousensei 18:08, 20 December 2005 (GMT)

Pausing

Is how to pause specified?

I would suggest the select button. Which would either pause, or go into help mode... which pauses the game.

Should pausing pause the music as well? Should it turn off the screen, and reduce the cpu frequency/turn off all the chips it can to go into power saving mode?

It all depends on your game... I remember when I was younger I used to record game music by plugging a cable into the headphones port, and in order to avoid having sound effects in the track I used to pause the game before starting the recorder :). So for me it was important to have the music running while the "pause" button was on. But as it is a portable console, it might make sense to save battery time when the user is not actively present in front of the thing.

One thing though: never turn off the screen. The user might think it has crashed and will just reboot the console. Zig 05:39, 28 April 2006 (PDT)

More flexibility?

Personally, I think these recommendations are great, but at the same time they might restrict/deter some developers. At the cost of complicating the issue, perhaps "grades" of conformancy would be a good approach.

My idea would be to expand the scope of the recommendations (which is already beginning to happen) to include more than just UI stuff and to grade each recommendation. If you confirm to all of grade E (assuming 5 grades), you can use a grade E image. If you confirm to all of grade E and D, a grade D image (etc).

That might not explain it too well, but what I'm thinking is that some of the points (localisation, etc) are hard/time-consuming and may cause a developer to not bother with the rest of the recommendations, while others (self-contained application, common exit key-combo, etc) are less time-consuming and it would be great to see all the GP2X apps adopting them, where possible.

(After reading this idea, perhaps "grades" isn't such a good one because "GP2X Compliant Grade E", or whatever, looks like it failed. Perhaps a star system, like hotels, is better?)

I'd be interested to hear other developers thoughts on this. - Wite Noiz 08:33, 15 June 2006 (PDT)

The CUI is not intended to be a conformance check list, it's a list of methods commonly used by other applications or games: if you want to add a feature to your game, and you're not sure how you should do it, look at the list to see if others recommend a particular method.

Nobody is required to follow any of these recommendations: developers can choose to use the CUI, or choose to ignore it completely, or he can choose to use only the few recommendations he likes.

If the developer chooses to use the CUI and uses the CUI logo to tell the users, he will face different situations:

1. the recommendation does not apply: the developer can ignore the recommendation.

2. the recommendation applies, and is refered to as a "must": the developer has to implement the feature per the recommendation. If he does not (for instance because it's a very complicated feature and it would be very time consuming to follow the recommendation), this should be treated as a bug or as an enhencement request. (Your Example: Localization. It can be very time consuming to implement a framework just to prepare for localization, even before doing actual translations. It's OK to hardcode all the strings, claim CUI compliance and consider localization a low priority bug. Don't expect a lot of American or European users if your game is entirely in Korean, though. Hopefully somebody will share a tiny localization library that other can use with minimum efforts)

3. the recommendation applies, and is refered to as a "should" or a "may": the developer can implement the feature or not, but if he does, it's better to implement it per the recommendation. (Example: "Select should be used to open an in-game menu, such as an inventory"; I can choose not to implement an inventory if I don't want to; I should not use Select for another action such as switching weapons; If I choose to do an inventory, I should not use another key than Select)

4. there is a recommendation for the feature I want, but it seems impractical for my particular application: don't follow the recommendation, do what's the most logical for the user. It is possible that some of the curent recommendations prove impractical in most situation. In this case, the recommendation is wrong and we should change it.

5. there is a recommendation for the feature I want, I see other applications following it, but I personnaly don't like it and I prefer a different solution. No problem, maybe you're right. However, please consider this: if there is several recommendations you choose not to follow, it may be misleading to the user to use the CUI logo; if you feel strongly about this recommendation, please post a comment in this talk page and tell us about it, maybe we'll like your solution better; if several users contact you to tell you they would prefer if you followed the recommendation, please consider the users needs.

--Titousensei 11:21, 15 June 2006 (PDT)

Virtual Keyboards

I think that there should be some recommendations on virtual keyboards. I have used NetHack, STerm and OutCast and everyone have some kind of virtual board. Everyone of these also behaves little different and sometimes it's hard to remember what buttons do something on different apps.

--Mikeful 06:51, 9 August 2006 (PDT)

This is a real problem

I got to test drive my brother's GP2X yesterday. The hardware is quite solid and in overall the system is quite exciting, but I have to say that the lack of consistency between applications is a major problem for the system. All the instructions he gave me had to be qualified with "usually". Despite having owned the console for several weeks he still wasn't sure how to quit any particular application. Sometimes an attempt to quit would cause something highly undesirable to happen (e.g. save the game state and overwrite the previous saved state).

I think the idea of finding a common ground and coming up with a set of recommendations is a very important one. However, this document seems to have had only modest impact. Here is my guess of the reasons:

• Improper framing. Many people got the impression that this document was an attempt by a small clique to dictate rules, not a first cut that would be refined by a community process.

• Lack of motivation. The document doesn't spend enough time discussing the importance of having and following guidelines. Some scenarios would be useful.

• Doesn't leverage existing conventions. (?) For example, it seems that Stick + L + R is a common combination for quitting, holding down Select is another. Stick + Start is a certainly an another logical choice, but are its benefits worth of encouraging everyone to change?

• Little evangelism. This sort of effort needs to be actively promoted to make any progress. People should be encouraged to get involved.

Having a logo to indicate compliancy is a nice idea. Ideally there would also be a button to display on a website. However, it would make more sense to first discuss and create a near-immutable specification, i.e. "CUI 1", so that developers would not need to hit a moving target and it could be ensured that the recommendation has some level of common acceptance. When the specification starts to lose its relevance, a new version could be created.

This was my impression and first thoughts on this issue as a user interface designer. Please forgive me for not necessarily fully knowing the current state of affairs. Aapo Laitinen 13:23, 24 December 2006 (PST)