Pains of UI design, part deux - (dis)similarities

There is one more topic I want to touch on briefly before going into specific UI issues. Are game UIs different from “regular UIs”, i.e. user interfaces in non-game, productivity or entertainment applications? I gave a short lecture on game UIs a while back and this was something I brought up then.

I believe that the key differences are:

• In game UIs, you can occasionally justify putting aesthetics before function
• Games often require rapid user response
• Even turn-based games usually limit the time available to a player
• Psychologically, the fact that games you usually volunteer to play probably makes a difference

Tetrablok sea UI draft

As for the third point, I am sure there are a great deal of productivity applications people volunteer to use. Still, I believe that when you fire up your favourite game, your mindset is somewhat different compared to say, editing holiday photographs (which, I am sure, can be a lot of fun. Photoshopping your mother-in-law into all sorts of hilarious scenarios… we’ve all done it). Even if you occasionally stray from your goal (removing those pesky red eyes), the task itself is far more goal oriented. Gamers, in the main, play to entertain themselves. I am, of course, aware that some gamers are goal-oriented achievers who resolutely work towards a set goal; however, I shan’t digress into the domain of games psychology and player types now. Instead, consider this a preamble for my next point:

It is my firm belief that when designing game UIs you can, occasionally, put aesthetics before function. Emphasis on the word occasionally. Your UI should be designed to, first and foremost, be functional. Frustrating but pretty UIs are just – here comes the pun – pretty frustrating. It comes down to, or so I believe, to psychology. In games, you occasionally expect fireworks and you are more likely to forgive slight usability issues in favour of aesthetically pleasing presentation. Microsoft Excel (okay, pre-ribbon Excel anyway) is a great tool with a pretty slick UI and yet most people would agree that they expect something different from games. In a game, I can often justify placing a button in a sub-optimal position to make room for pretty pictures. Often, you will choose to display numerical attributes in non-numeric form (e.g. progress bar, pie chart) just because it looks prettier. Occasionally the graphical presentation adds value and makes the attribute easier to comprehend. Sometimes it just looks better. I could go on.

The second point, which I’ve strangely decided to elaborate on last, is probably the most self-evident. Many games require fast reflexes and in-a-fraction-of-a-second decision making. Please, allow me to put aside the whole topic of game controllers. Also allow me to ignore the very extremes of fast-pacedness – FPSs and the likes. Controlling your character in FPS games is more about the controller than the UI. Ditto for most games where shortcut keys are the primary interaction method. Game controllers are a fascinating topic but I will stick to UIs for now.

Now that I have conveniently (if somewhat cravenly) narrowed down the gamut of game UIs to consider, we can pit games against productivity apps. If I am permitted to rule out a few games more, let’s assume there is a time constraint of some type embedded in the game mechanics. In Seepia Games’ games, the constraint is usually time per turn. The time constraint has a number of functions: it forces the player to work his brain more intensely, it can be used to control the maximum duration of a match and, perhaps most importantly, it protects the opposing player from dissatisfactory ennui. This sort of artificial time constraint rarely exists in the realm of productivity apps. High pass-through rate (completion of a form, process etc.) is desirable but I cannot think of many scenarios where it would make sense to impose a time limit on the user. Such limit could even backfire causing stress and lowering productivity.

The question then becomes, are games and productivity apps different after all in this sense? Prompt, precise response is the desired user interaction either way. Games simply add a “sweat factor” – the time limit. Therefore, I am happy to accept that the chasm between the two is not that wide after all.

So, I posit that a good game UI looks good but still follows the usual principles of good UX design: it works with the user, not against him; it stays out of the user’s way and lets the user focus on the fun parts; and finally, it excites the senses and tingles the bits of your brain that appreciate aesthetics.

There is one more aspect to this I have not discussed now but to which I may return in future – learning curve. A topic for future post, perhaps.

The pains of user interface design

Designing good user interfaces is hard work. That is a given. Designing good user interfaces for multiplatform games doubly so. For us, multiplatform means everything from mobile phones to web browsers. This, together with limited resources, makes user interface design a real challenge. This blog post will start a series where I alight on a number of issues we have faced in terms of UI design. In this first post, I will not delve too deep into any specific UI issues. I will instead give you an overview of where we are coming from and how it affects our UI choices.

In the web design world, one of the biggest contemporary trends is response design. In summary, it is a change of mindset from “we need a desktop site, a browser-optimized version and a mobile app” towards “we need a website that works across all devices”. This is achieved using fluid layouts and a number of other techniques (see Wikipedia). Responsive design makes content a first-class citizen, a position it rightly deserves. As a bonus, this tends to lead to far less crippled mobile services (go find a handful of news websites. Now, visit their mobile sites and see if their comments functionality is still there).

The reason I mention responsive web design is simple: it has made the web far less device-oriented. There are other positives but for the purposes of this post, the moving away from designing for particular devices is sufficient.

In our minds, simply porting your game to another platform does not make it “multiplatform”. We see multiplayer games as games that do not build barriers between players just because they happen to play on a different platform. Games, where you can transition from one device to another, using one account. Games, where the device is really just an access point into the game.

We believe this “access point” thinking is the future of serious mobile games. Unfortunately, it also makes user interface design a far greater challenge than it would otherwise be. Now, if we had the time and resources to design the interface separately for each “access point” (desktop browser, tablets, mobile phones etc.), life would be easy. Alas, we cannot. We have to design UIs which work on the entire range of devices our games support. We must be mindful of available screen estate and make sure everything is readable even in the smallest displays. We cannot rely on hover effects because of all the touch devices. We must take note of platform specific features (e.g. the availability or absence of a hardware back button). Good thing we don't mind challenging undertakings.

In the next post, I will talk about some UI designs we have chosen and I will also go over some specific issues we still need to tackle.