I have a problem with buttons (small b, it’s not about the pantomime character, so sorry if you thought it was). To “click” (or, as the youngsters among us say, “tap”) on a standard button, you have to be accurate. If three buttons are side-by-side and you want the middle one, and you hit one of the buttons on the side, you’ve failed. Go straight to Jail. Or, rather: you now have to slide your finger away and try again.

Using a mouse, this isn’t a problem. Mice are accurate beasties. With a touch-screen, though, especially when your screen is small, it becomes an issue.

The standard solution for an iPhone? Make your buttons much bigger.

Needless to say, I hate this solution:

• the app now looks less like Technic Lego, more like Duplo;
• it takes valuable screen-space away from other things.

So, how do I deal with it?

I allow the user to slide from one button to the next. If buttons are adjoining, that is then one control, not many. In the input_down code, work out which button you’ve hit. In the dragging code, calculate again. The input_up code is what matters for the “click”.

Additionally, if there’s a natural margin around the buttons, register a hit on this margin as a hit on the button (the margin also becomes a part of your control).

If you want to keep your buttons small, there’s one more problem to deal with: the user’s fingers. How do they know which button they’re over if their whopping-great sausage finger is obscuring their view of the screen? Well, standard keyboard displays do this with a pop-up key display. This works fine for a keyboard but won’t be much good it your button is at the top of the screen.

Once upon a time, a status bar at the bottom of the screen would be the solution. 9 times out of 10 this is all that’s needed. But, um, what if the keyboard is being displayed?

Well, in addition to a status bar (which I still think is very useful) alongside a replacement (or reframed standard) keyboard, the solution I favour is to use the middle of the screen. OSX often uses what I imaginatively call a “grey square control”, which is semi-transparent, non-interactive and fades away by itself before it wears out its welcome.

Is there a problem with using the middle of the screen? What if I were to have a button there? Well, no, that’s actually a silly place to put a cluster of small buttons!

So, to sum up: for frustration-free small buttons, you might feel you need to:

1. code a multi-button control & handle the input and drawing yourself (the easy part);
2. code a status bar;
3. deal with the on-screen keyboard (or code your own) to accommodate said status bar;
4. code a grey square control (because, if nothing else, they look cool).

Alternatively:

1. be lazy, save yourself a fair bit of time, and use big buttons.

I don’t blame you if you opt for big buttons. Because it’s not just buttons, it’s lots of controls. They’re simply not designed to work well with one another when they’re in proximity. As soon as there are multiple views involved, the standard input process fails. To fix this one problem, you’ll soon find yourself fixing similarly-irritating other ones. It’s less of a rabbit-hole, more like those caves in The Descent. And that’s where I’ve been, thankfully with the American ending and not the UK one. 😉