The Problem With Buttons

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).


  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. πŸ˜‰

Keyboard Worrier

When the iPhone first arrived, I didn’t get one. I wanted an iPod Touch instead, which was great for music, not so good for calls.

As amazing as it was at the time, the iPhone software was missing something, and it’s something that’s been bugging me ever since. Here’s the on-screen keyboard, as it appears now on my iPhone:

And here’s the landscape variant:

What’s wrong? Well, mainly the absence of beloved keys. Where’s my tab key? Where’s escape? Forward delete? The cursor keys?! Dare I even ask about Command, Option and Control?

Why cannot such buttons at least be put on the landscape mode view, instead of elongating the portrait layout like silly putty?

There is no getting around it: I often feel hamstrung having to use this simple keyboard.

Yes, I do understand the thinking that such keys would just clutter and confuse and that, with a touch-screen, they might also be superfluous.

Well, boo to that with knobs on!

  • Placing the typing caret down between the two letters I want is an exercise in frustration;
  • Tabbing now requires tapping – plus sometimes scrolling – different areas of the screen instead of one key;
  • As for dumbing down for the masses, why not supply two modes with a keyboard, the same as for a calculator: basic and advanced?

For the app developer wanting to reimplement what was lost, the documentation suggests that such missing buttons should be placed (awkwardly) in a row above the other keys. It’s a bit of a hack in my humble opinion, and can look pretty nasty.

So, one of the things I wanted to work on for my software library was a decent keyboard control. If I needed to fit extra keys to my keyboard in portrait mode, I’d clearly need some sort of zoom (I also do for the iPhone keyboard, as I’m always hitting the wrong key at the edges).

Here’s my SuperKeyboard, as it appears on my iPhone:

(the bezel shape was added afterwards by me, since it doesn’t appear in the screenshot!)

Coding your own keyboard has its small challenges, including:

  • dealing with the peculiar way iOS handles rotation (i.e. when it’s rotated landscape but the frame still thinks it’s in portrait mode);
  • the carriage-return key, which has to be drawn separately due to its odd shape;
  • dealing with bezels and safe areas (I would love to be able to access the shape of the screen programmatically; instead I am provided with four margin values).

My layouts are all very simple text files, which are then read into the SuperKeyboard, with the code working out the relative sizes for the keys depending on their types. As such it is now relatively trivial to modify any layout, or create a new one as desired.

Oh, and one last thing I wanted: a smiley keyboard with a spacebar, arrow keys etc.

Shifting does this:

That’s one more control down. πŸ˜‰

Back to Apping, Part III

Now, where was I? Ah, yes: the software library. What’s wrong with the tools we’re given? Well, nothing, really… Well, actually…

I love Apple’s controls. In no time you can cobble something together that looks pretty cool… but, then, so can the next programmer. Worse, the next programmer probably has much more money and resources than you do. And even if they don’t, then there are a thousand more that do.

I need my work to stand out.

If I can create something cooler than the norm, then great. For instance, here’s an Apple slider.

Simple, elegant, does what it says on the tin. But here are my problems with it:

  1. My app might require sub-ticks as well as ticks;
  2. I cannot control a range of values; I’d need multiple sliders… = more scrolling;
  3. The blue is a system-set colour – and would probably look better as a horizontal gradient;
  4. If I have multiple sliders, and one is more important than the others, how can I make it stand out?

In summary, the standard control is too simple, and does not give me enough fine control. Which is absolutely fine for 95% of uses.

Now, here’s my control, in a basic configuration:

Apple’s bar has a subtle 3D-gradient fill; mine has a less subtle horizontal gradient. My drop shadow is also a little different.

Here’s my control again, with some more options added:

Sliders can also be vertical; I’m too lazy to screenshot that but tilt your head to one side and you’ll get the idea!

The coding of such a control (I imaginatively call it a PBGUI_Super_Slider!) does not take long. Maybe a week or two with my time limitations. But I felt I needed to do it to minimize scrolling (did I mention I hate scrolling?) while hopefully not making everything look too cluttered.

One thing that annoys me about Slider controls in general (I don’t think it’s just Apple who are guilty of doing this) is the property numberOfTickMarks. For a scale of 0 to 10 I have to think a beat about whether this should be set to 10 or 11. If I then change the min/max value I also have to change the number of tick marks again. I appreciate that this might seem like a trivial issue but when my tiny brain’s capacity is full, trivial problems lead to easy errors. So my “Super” Slider has an alternative property for setting the value interval. In the above example, I can simply set it to 1 and forget about it.

My Super Slider is not perfect. If I had more time I’d add an extra 3D gradient and some animation. If I had coded it this year not last I’d be using Metal for that little extra sparkle. But, for now, it’ll do for my purposes.

Anyway, that’s one control out of many. I might talk about some of the others next…

The Case of the Useless Valve Adaptor

Warning: the following article is even more boring than this picture

I’ve been rewatching Babylon 5 after 25+ years with my kids. I’m chuffed that they’re enjoying it, that they love G’Kar and also find Marcus intensely irritating. We’re in mid-season 3 where things are getting really interesting… But then arrives an episode like “A Late Delivery From Avalon“, which is needless filler and annoys us for ruining the flow. This post will be a bit like that, so feel free to skip ahead to Back to Apping, Part III, if you can. If you can’t, unfortunately it would appear that you live too much in the present, sorry!

You might recall that, in my previous post, I talked about things that needlessly suck away my time. A good example arrived promptly after I’d written that, and I thought I’d share.

I had to collect my son from school, so I wheeled out my bike and its trailer and, because I was a few minutes early, I foolishly decided to pump up one of the trailer’s tyres before I left. It didn’t really need doing.

(Now, my daughter had “borrowed” my bike pump in the summer, in an attempt to inflate a paddling pool that was never used, because the instant the pool was inflated, it rained for a week and then stayed relatively cold. Somehow she had managed to break one part of the pump, the connector for the very tyre valve that I now needed.)

Instead of adding a bit more pressure to the tyre, all I succeeded in doing was to expel the remaining air from the inner-tube. That’s why my son had to walk home with me.

The pump has two connectors for it, you see, the normal “Presta” one, which every other bike pump in the world has, and one for a “Schrader” valve. It’s the Schrader part I needed, and (of course) that was the one which was broken. I found three other old bike pumps in the shed, and none of them had this connector.

So I spent a while trying (and failing) to fix the broken connector. It wouldn’t lock. I suspect a vital piece was missing, a treat for future archaeologists to gush over when they dig up my lawn in they year 5000.

A normal person wouldn’t have bothered any more with this. They’d buy a new pump. If they were really flash they’d buy a new wheel. And, if they were filthy rich, I don’t think they’d have a bike trailer in the first place; they’d have a solar-powered helicopter or a Hyperloop direct to the school.

But, as others will gladly and maliciously attest, I’m not normal. When faced with a problem, I can’t rest until I’ve solved it – as cheaply as I possibly can. It occurred to me that I could buy an adaptor to turn the Schrader connection to a normal connection, and then use the working connector of my pump with it.

So, off I cycled to my local Hagebaumarkt (which is German for B&Q), and bought an overpriced small bag labelled “bike pump adaptor”, containing three different adaptors, one of which I knew should do the trick. And I cycled back, quietly confident it would work.

It didn’t.

Inflating a Schrader valve is as simple as it can be. There’s no chance to do anything wrong here.

The adaptor screwed on perfectly, the seal was good to my pump. But I couldn’t pump air into the inner-tube. Because, to do this with a Schrader valve, the inner-valve pin thingummy needs to be pushed down in order to let the air in, and the adaptor did nothing to push the inner pin. It merely entombed it.

No, the inner valve would not screw outwards. The adaptor was useless. Like a travel power adaptor with the right holes for your appliances’ plugs but none of the internal copper to conduct electricity from one end to the other.

But I wasn’t finished just yet. If the adaptor wouldn’t push down the inner valve pin, I’d need something else to do it for me. So I rummaged around in the dirt of a nearby flowerbed and found a tiny pebble, and I placed that in the adaptor and screwed it in. The pebble wasn’t so perfectly formed that it would block the air, but it did push down the pin like a charm, and I was finally able to pump up the tyre.

Life’s like that, sometimes. You try to fix something that’s not really broken, and you break it. And then you waste time getting back to Square One. Like your day, for example. I bet it was going just great until you wasted your time here. You didn’t need to read this twaddle. But now you did and you’re going to have to work hard to find a more interesting article to erase this experience from your head… Good luck! πŸ˜€

Back to Apping, Part II

When people find out (I try not to mention) that I’m a programmer, invariably they chirp in with, “Oh! I’ve got a great idea for an app! It’s a doozy!” And (unprompted) they go on to tell me how, for example,

  • it calculates sums of numbers (App already included with every phone), or
  • it makes amusing noises (Apps done to death), or
  • it uses the FBI facial-recognition database to spot disguised celebrities and/or escaped convicts in your local Lidl (App requires discreetly accessing the FBI facial-recognition database), or
  • it’s like Minecraft/Fortnite/GTA X but with way better graphics/gameplay.

And then they suggest I code that for them. “We can be partners!”

Well, “app ideas” was never the problem. I already have a list as long as my arm for app ideas. The problem is always Time. And lack thereof. Yesterday, I read through Apple’s app review guidelines, which is enough to make anyone’s eyes bleed. And that’s just reading it.

I need to introduce you to one of my laws. I call it “Philip’s First Law of Coding” because I’m Mr Vain. Here it is:

Coding will always take at least three times as long to do as you say it will, even (or especially) when you try to take into account Philip’s First Law of Coding.

Philip’s First Law of Coding, (c) PBG circa 2015

Star Trek’s Scotty knew just how long it would take to repair something, multiplied that time by a factor of four in his estimations and then everyone was mightily impressed when he managed it in a quarter of the time he said it would. Scotty’s a git! If I think something will take a month, I might decide to say that it’ll take three, and then it’ll actually take nine. Yes, it can be extraordinarily tricky to guesstimate how long even a simple project can take, especially when I am confined to two-to-three hours a day to work. There are all sorts of things which crop up:

  • unexpected and mysterious memory bugs that the debugger can’t handle;
  • new OSX/iOS/XCode (old code suddenly stops working, or works differently);
  • new code A requires recoding old code B, and then B affects C, D & E, which need adapting and testing, and then D dominoes into the rest of the Roman alphabet and threatens the Cyrillic;
  • hardware problems (failing hard disks is #1);
  • problems due to stupid initial decisions (mostly from severely underestimating complexities);
  • real-life emergencies, illnesses of all flavours, mood-swings and depressions, weather too hot or too cold, rain-patter too loud against the ceiling window, and so on.

This isn’t just a problem for coders. Please do take a moment to read up on the history of the upcoming Game of Thrones book, The Winds of Winter. In case you didn‘t just do that, here’s that link again. I did say please! I am pretty sure that Mr Martin is not a slacker and that he was being entirely honest with all of his completion estimations. Finishing even a simple project is tricky and takes times to do right. I know, because I’ve been spending many, many years writing my own software library, in order to code an app that will change the world.

More about that in Part III. πŸ™‚

Back to Apping (Was Napping), Part I

Portrait of a Coding Dinosaur

I’m a coding dinosaur. I grew up with writing databases in BASIC on the ZX Spectrum 48K. I’m so old, computing was an optional afternoon hobby at my secondary school. There were no laptops there, just a dozen big beige boxes in one room hidden away from all the others. Cutting edge tech was a VGA monitor and a greyscale scanner you had to roll over a picture at just the right snail speed for it to work. My mates & I were wowed by Windows 3.0 and spent our days wrangling with autoexec.bat and config.sys in order to free enough DOS memory to play Origin games. (No, new kids, not the same Origin you know).

So I stumbled into software engineering after university, doing my best to muck up their statistics by not landing my first job till a year after my 1st-class-honours Maths degree. I went to work in an international bank making graph software for Value Added Risk (which is as much as you would probably ever want to know about that).

Then, at the turn of the new millennium, I tried to ride the wave of the Dot Com revolution. I journeyed to America, helped make a website for buying/selling sports cards. It was called thePit and, amazingly enough, I see that it’s still going. But I learnt then that you can’t ride a wave that’s actually a bubble that had already burst.

After that I learnt C++ in order to code my first computer game. It was a vector-based space shooter called Surrounded! and it was awesome, but I can’t market and can’t afford marketing and consequently nobody ever really played it. Except me and a marvellous chap called Saturn.

What was the next “Big Thing”? Well, it was the iPhone so that seemed like a good opportunity for me to find a bigger audience with its built-in App Store. I enjoyed extremely modest success there. Looking back I joined a bit too late, the same as with the Dot Com thing. Matters were further muddied by my move to Germany and having to juggle my new family life, an impossible new language, six years of lost sleep and an idiopathic chronic illness. I can cobble together more silly excuses but the truth of it probably was that my apps simply weren’t good enough to pass serious muster. When the whole tax situation became too thorny (as my dev account fed my UK bank account for my UK company, but I was in Germany), I decided it was simpler to take my apps off the store.

(And I’m breaking up this story because you surely have better things to do than read articles which are too long. Another bite-sized piece of my story coming soon!)