How game designers can help application developers : Part 2

Last week I discussed how application developers often forget to think about the user in ways that would seem farcical in game development. If you didn't read it, go back here first and have a read! This week, I'll go into more detail about how the lessons learned from developing games (or even playing them!) can help you create better web applications. There is a great presentation by Dan Saffer here which I think is well worth a read. He speaks in some more depth about some of the topics I will brush over here. The crux of the problem for application developers is that an application is developed with an end result in mind and the experience of how the user gets there is secondary. In game development the process is obviously the other way round. The objective in a game is generally secondary to the experience. Often a game has NO objective other than the experience itself. So, going back to my example from last week of an RTS with an impending onslaught of enemy forces. In a poorly developed game, it may be possible to build the structures and forces you need to fend off the enemy, but it may not be enjoyable. If a game isn't enjoyable no one will play it. In application development we all to often say, "yeah it may be clunky...but it works". Just "working" isn't acceptable any more, if it ever was. Your application needs to engage, excite and promote word of mouth. Particularly if you're a startup, and particularly if you don't have a big marketing team to get out there and spruik the value of your software. As discussed by Dan in his presentation, we need to focus on making the user happy. In particular we need to make sure we aren't requiring too much of our user's: a) time b) effort c) attention In our RTS if we require too much from the user of any one of these things, the game will cease to be enjoyable. Things which take too long to do, are too hard to do, or require too much focus aren't fun. This is as true for applications as it is for games. Whilst our application may never be "fun", it should at least be enjoyable. Is your app too time consuming? Think of how annoying games can be with long load times before every level. Think of how bad it looks when an in-game menu stalls before loading. Think of how frustrating it is when you need to perform an action in the game and you lose simply because the action took too long for the game to complete.
  • Look for interfaces which are used frequently, or systems that involve repetition.
  • Can you cut down on page reloads? Perhaps look at AJAX to load sections of data rather than reloading the entire page. If you're using .NET do your controls NEED to do a postback??
  • When asking the user to add multiple items can you get them to add them into a list and then hit enter instead of "click add - type - click ok, click add - type - click ok, click add - type - click ok".
  • If you're building a web app, make sure you're pages aren't huge! Make sure you load your JS and CSS files effeciently. Reduce image size where possible.
Does your app take too much effort? Think about how annoying games are which require you to open 3 menus to use a spell and have no assignable hotkeys. Think about games which make you walk back to town to sell items instead of just opening a portal. Does the game become too difficult to manage with many controllable units on the screen?
  • Look for cumbersome interfaces, or non-obvious controls.
  • If you use drag and drop or right-clicks, is it obvious to the user?
  • If the page loads a lot of data, does it become a hassle to use? Scrollbars, "next" and "prev" buttons all add to the effort required to complete a task.
  • Make sure your users only have to fill out data that they MUST fill out. Don't ask for information you don't need to complete the job.
  • Is your navigation easy to use? User's should be able to get anywhere within 1 or 2 clicks.
Does your application require too much attention? Think of a SIM game that presents the user with individual salary data for every SIM in the game when all we really want is the unemployment rate. Think of a game with 20 active quests but no way to see what they are. Think of an adventure game with no mini-map or that requires you to remember where your next objective is.
  • Your application should ideally only show information relevant to the task at hand.
  • Banner ads are evil (Animated ones in particular!). Is the money you make of them really worth distracting your user?
  • Are frequently used items more visible than the less frequently used ones?
  • Is it always clear what the user needs to do next, or do they need to guess?
Hopefully this will give you some food for thought when you design your next interface. Once you stop thinking about your application in a goal oriented way and start thinking in terms of the user experience, you'll already be on the way to designing better applications. This week we talked about how application interfaces can be improved by thinking like game developers. Next week we'll discuss making applications fun to use by bringing a little bit of game to your application!

What's next?

Truly successful interaction design relies on continuously asking yourself that question, so your users don't have to. Early on in the redesign of Five Second Test we focused a lot of our attention on how users created tests. We removed the need to register, we reduced the number of steps to the bare essentials, and eliminated all but one test type. What we had failed to do however, was to ask ourselves what we needed to do once a test was created. As it turned out, our users, having gone through the painless test creation process would wind up looking at their test results screen. This had made perfect sense to us from an application point of view, the only problem was there were no results to look at. To make matters even worse the most prominent button on the page was the one allowing users to export their non-existent results. Had we more carefully considered what our next action should be we would have realized that getting people to run a test needed to happen prior to viewing any results. It's seems like a laughable oversight but it's a surprisingly easy one to make when you're focusing on application state instead of the needs of the user.

How game designers can help application developers : Part 1

I'm a gamer. Our house has an Xbox 360, PS3 (the new slim variety) a Wii, an old xbox, an old ps2, a Gamecube, 2 Nintendo DSs and even a Gameboy Micro, plus the PC and a pair of iPhone 3GSs. Most of these get a fairly regular workout, except for perhaps the Micro and the Gamecube. Suffice to say, we're a gaming house. My wife is a Nintendo nut, and I'm more into PC and Xbox gaming. The PS3 is a blu-ray player.... What's this got to do with application design? More than you'd think! Usability, in application design, is often an afterthought. Not only in terms of interface design, but in terms of the user experience or user journey. This is mostly true for developer driven application design. The sort of design that evolves at the hands of a developer only to be "spruced up" by a designer later (if we're lucky). We consider how things work, but not really how they will be experienced. You can spot these apps a mile away. I know, because I've built plenty of them in my time. You don't realise how bad they are until you see someone trying to actually use your application in a real world environment, something many developers never ever witness and as a result never learn. Some typical examples, if I may:
  • Features that were clearly important at the start of development, remain visually prominent well after the feature has been demoted in importance or the focus of the application has changed.
  • Repetitive tasks use interfaces which are too cumbersome and time consuming to work, often as a result of a developer building an interface in isolation rather than as part of a work-flow.
  • Building a data interface which requires pre-existing data but with no way to add it, requiring the user to leave their current process to add the prerequisite data somewhere else.
  • Interface elements which are either non-obvious in their function or "tricky" to use for the inexperienced.
  • The worst offender, inconsistent design and implementation. When a developer is left to their own devices, they will often come  up with different solutions to the same problem. There is nothing worse than using an application which implements the same process two different ways in two different areas!
I'll be honest, you'll see a few of these issues in our own But we're working on addressing these... I promise! Whilst most of these issues could be easily addressed by a better pre-build process or even just some rudimentary user testing, this is often something that is out of the hands of the developer. Often in a small team, these tasks fall into the hands of the dev, something which, let's face it, we're all ill equipped to deal with. Not only that, but often the entire build process is focused on getting the job done quickly, rather than having a good product at the end. So, back to the games.... Imagine you're playing an RTS like Command and Conquer, Age of Empires or Starcraft. The enemy is approaching and you're in dire trouble. You need to build a wall, some defence towers and at least 20 units to fend off the attack. If all that isn't enough, you have only about 5 minutes in which to do it. The pressure is on! If the game is well designed, you will have enough time to fend off the horde. If the game is well designed, you will be able to achieve it all with a minimal amount of effort (time pressure aside!). Finally, if the game is well designed, there will be minimal interference from unrelated factors whilst you attempt to achieve your goals. Let's think about that more for a moment. If it takes too long for us to complete our task, we will be overrun by the Zerg Swarm and lose the game. If it is too difficult to complete the task, we will most likely give up and go play something else. If the game interrupts us constantly by notifying us that our citizens are unhappy, that another player wants to trade with us and that we should consider building more farms, we will get annoyed at the game and blame it for making us lose. Game developers spend crazy amounts of time considering these issues to ensure their game is fun to play, and yet in reality the same issues face us as application developers. We may not expect our users to have fun, but we still want them to be able to achieve their goals, and hopefully enjoying it enough to come back again next time! Come back next week for Part 2 of, "How game designers can help application developers"

Of stacks and faces

I have recently been considering the issues involved in using fonts of varying x-heights in my font stacks. As Andy Clarke explains:
...there’s the problem with CSS, right there. Different typefaces, even common ones, that have been designed with different x-heights, need different amounts of line-height. Calibri less than Verdana and different again to Arial or Helvetica. But CSS does not provide the facility to specify a varying line-height if a font in the stack is not installed, as it retains the same set line-height value for all typefaces specified in the font-stack.
One possible way of addressing this issue is to detect which fonts a user has installed via font detection scripts like this or this. Using this method a script could automatically adjust the font size at runtime to ensure a consistent layout. However, a lot of people worked really hard to ensure the content, presentation and behaviour of our websites remain seperate and we don't want to be pissing on their parade. The answer to this problem potentially lies in the newly adopted @font-face declaration in CSS3. The @font-face declaration to those unfamiliar allows designers to reference a font for embedding inside a page. The syntax looks like this:
@font-face {
  font-family: <a-remote-font-name>;
  src: <source> [,<source>]*;
  [font-weight: <weight>];
  [font-style: <style>];
The syntax currently has support specifying a font's weight and style, this is because they act as constraints on the actual embedding and therefore reduce how much of the font needs to be downloaded. What I would like to see is the addition of the font-size property so that designers would have a greater degree of control over their typography. Below is how you would potentially normalise the x-heights of your font stack using @font-face:
@font-face {
  font-family: L-Calibri;
  src: local(Calibri);
  font-size: 115%;
@font-face {
  font-family: S-Verdana;
  src: local(Verdana);
  font-size: 85%;
body {
  font-family: L-Calibri, S-Verdana, Arial, sans-serif;
I'd be quite keen to hear other people's thoughts on this, and to see if anyone else has any ideas on how to move typography forward on the web.