Tuesday, 21 January 2014

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.

Turtle illlustration from Seepia Games' TetrablokNow 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.

No comments:

Post a Comment