Skip to content

UI Design: How to lose yourself to scroll arrow.

July 5, 2012

This is the most boring post I have ever written.

When you use an iPhone, or click the scroll bar on the side of your browser do you ever stop to think about the design of the action you are performing? Unless you are a software developer, probably not, it just works, and seems like the obvious thing to do.

What follows is a typical design problem, and how I went about fixing it. I thought it might be interesting for some of you if I try to explain a little about the kind of thing that I do with my days. Making games isn’t just about getting people’s heads to explode in a gore shower or working out whether you want to set your game on Mars or Jupiter…most of it is a lot of it is a lot less glamorous.

So Nuclien has a level select screen that looks like a strand of spinning DNA. Here it is:

So before I made this screen, I planned it out, I was standing in the shower and I thought to myself that a game about DNA should have DNA make up its menus. It would look cool, and it would be clear that you had to drag the DNA strand up and down to select the level you wanted to play, because there would be a small linking line between the play button to the selected DNA blob (no doubt DNA Blob isn’t the scientific term for it…).

Once I got it working in a way I was happy with (which included it auto aligning itself, and having a nice set of musical notes play as you drag it to make it feel more like a toy) I gave it to some folks to try, some people got it straight away and were doing exactly what I expected, but some people weren’t. Those (far less intelligent – might I say stupid) people were simply tapping play and replaying the same level over and over like monkeys, and asking me why my game was so repetitive.

So yes this is an example of focus testing, and actually they weren’t stupid I was for even half expecting the screen to work first time. So first things first I realised it would help if the DNA automatically moved to the last unlocked or unlockable level when you enter the DNA screen. This should also help players know that the DNA strand can move. Success! Now people were at least playing the correct level, but they still didn’t know they could drag the DNA strand up and down…so in reality, it was partial success, mostly still a fail.

Next I realised even with my new fancy autoscroll that if the player finished all the levels in the world, the chain would always scroll to the last level, which is pointless seeing as the player wouldn’t want to replay the last level over and over again, so the next bit of logic checked to see if all the levels were complete, if they were then it autoscrolls to the first level that doesn’t have the 3star (perfect) ranking.

The third bit of auto scroll logic came in from players not playing the last unlocked level. If you finish the last level and a new one unlocks it makes sense for the game to take you to that new level, however let’s say you have 4 levels unlocked, and you are playing the second one, when you fail / quit / complete the level it makes sense for the menu to not autoscroll you up to the new one, because clearly you were trying to play level two for a reason so constantly scrolling you away from that is just annoying.

What if you scroll up to the top of the DNA chain and tap play on a locked level? well then it displays a polite message telling you the level is locked, once you click OK, it auto scrolls you back to the last unlocked level, putting you back to where you probably want to be.

Essentially for people who didn’t know how to drag the strand, and for general ease of use I was trying to make the level select automagically work. I am trying to figure out the most likely thing the player wants to do and then make the menu do it for them. This is always dangerous because you never can fully second guess the users intentions, but that said the people who couldn’t scroll now could at least play the game. I felt that the autoscroll was a success, although it didn’t fully address the core problem that people weren’t dragging the bar and moving it up and down.

Like a lot of game design stuff, the autoscroll is one of those things that has a lot of thought put in to, and in the end people won’t even notice that it’s there, but without it, people would get a little annoyed.


I had lunch with my friend Chris, who also didn’t realise he could drag, he said I should put arrows in to help make it clearer, even though it means more stuff on an already cluttered screen I realised it made sense, so yes here are the arrows (they are pretty subtle, but they animate a bit helping you see them betterin the game):

So now I can see the pretty arrows they tell me I can drag my fingers up and down right? Well that’s what they do for me, but what about you? No doubt some of you think they look a bit like like buttons….Uh-Oh!

So to fix this, I made them into buttons, so you can tap on them and the bar will move a chunk, if you hold your finger on them the bar will move one chunk every 0.5 seconds, getting faster the longer you hold. When the DNA reaches the maximum scroll I deactivate and hide the no longer valid button to keep things clear and nice….

The problem is I now have two functional interactions on top of each other, each designed to serve a different persons perception of how the interface should work. This is where it gets tricky, they are going to cause conflicts. If I drag but I move my finger over the button what happens? If I tap the button but my finger moves a bit what happens? Essentially I had to put even more convoluted logic in place to fix this!

If I start dragging anywhere but on the buttons, the buttons will be deactivated until I remove my finger from the screen.

If I tap the button, and then drag my finger the drag action will take over, nullifying the button once again.

However I have to put some tolerance in this, because if you tap the screen your finger will probably move a bit naturally, so if I tap / hold the button but only move my finger around within the area of the button the button remains active and the drag does not kick in. – Success!

So as you can see, nothing in touchscreen design is as easy as it seems, in the good old days you just had a button on a keyboard or a gamepad, there isn’t really much you can do with that other than press it (well – tap or hold). But now with touch screens it’s all a lot more complex.

How could I have made my life easier? Perhaps I should have used a more traditional interface similar to Apples own, so people would know what to do instantly. However that would have meant making my menu look a bit less cool.

Is my solution perfect? No if you begin dragging on the button the DNA strand will hop the other way for one blob before moving in the direction of the drag….it is so fast you barely notice, but I could maybe fix this with some kind of interface that learns what the player does and then makes that the default action…or adding a slight delay on the button action (neither of those ideas are actually good though, they both introduce yet more problems)

What is wrong withow I approached this whole thing? What was supposed to be a simple task snowballed in complexity, I just carried on patching the design holes to a point that I am mostly happy, but it is far from elegant, and simple things are always best from both a user perspective and an implementation perspective. while I think my work on this menu was a pretty good example of how designers are expected to solve problems, it’s also perhaps an example of something I should have thrown away and given a rethink to before I got in so deep, the thing took me somewhere between 2 and 3 days to do, which in the end I think is way too long to spend on a damnedscroll button!!!

So yeah there you go, sometimes game design is like that, I still find it fun, because it’s problem solving, and when you get down to it all game design is problem solving. It isn’t about saying “wouldn’t it be cool if there were zombies and stuff” it’s actually more about working out what isn’t working and using an analytical approach to solving it, I think a big part of what makes games fun is that they are a collection of logical choices brought together to a point where nothing is annoying, and everything sits well together. When designing a game or scenario I spend a fraction of the time thinking about the exciting stuff (story / setting / weapons etc) and most of the time trying to make sure those crazy ideas (and simple ones) work together and in a way that players understand. Contrary to popular belief there is no magical pixie dust in games, just clear thought, concise explanation to those around you, and enough time to fix the bits that don’t work.

Boring blog post over (can you tell I don’t want to get back to bug fixing?!)

From → Uncategorized

  1. Melody permalink

    i think that the autoscroll part that you finally implemented was probably the best solution. but arrows? i do think that you could have done without them and saved yourself the trouble of the whole chunk of arrow problems that came with them. it IS way cooler than conventional menus anyway, and people gotta use their brains someday =P

  2. Yeah, I really hated the idea of putting those arrows in (and they have created new bugs!)…tonight I will get some folks to play it, and see what happens, if it still doesn’t work then I will need to re-evaluate, one idea I have is to move the arrows so they are small buttons above and below the play button…also, perhaps the DNA needs to flash when it’s a new level or something….damn I wish this screen would just be done!!

  3. Karl permalink

    “in the end people won’t even notice that it’s there, but without it, people would get a little annoyed.”

    Good design is often said to be invisible – at the very least, it is noticeable by its absence.

    Don’t be worried if people fail to comment on the good design of the menu- be heartened that they get can on with the game, and you design out obstructions to their enjoyment.

    Sometimes, you don’t find out this stuff until you do a little user testing.

    Great article.

  4. Luigi permalink

    Another option is to maybe look at the highlight visual on the selected strand. I wonder if it should be a different colour to the rest but also – maybe the ‘arrows’ could go on the highlight? Some nice, subtle points at either end would indicate nicely that it can be moved up and down and then you wouldn’t have two sets of interactive functionality? (One slight problem – the pointers would need to move around the DNA to point in the correct direction – they would need to face the next sphere at all times).

    On a side note – I really like the fact that you’re trying to implement a different way of level selection other than the ‘Angry Birds’ system which is now being used in 99% of all IOS and Android games!

    • Hi Luigi! thanks for reading the blog (I have been reading yours too). Yeah I think that could work, although when you dragged the DNA the one under your finger would instantly become unselected, which might be weird…it would be the button you press moving somewhere else the instant you press it..but I like the idea of little arrows moving round the balls…

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: