So, my task was to code a hand: one that could point and tap the index finger.

I suspect that, when large companies are given this task, they just send it over to the 3D graphics departments, whose cheerful minions happily generate a fifty thousand triangle mesh, manipulate it in cutting-edge software, then spit out some beautifully-rendered video files. Which is all well and good if you have that option.

But video files won’t cut it for me. If I’m future-proofing (like I always aim to do), then the number of video files needed would be ridiculous. The digit combinations alone must be 120 or so – and that’s just for opening and closing; still not enough to greet Mr Spock.

So: a 3D mesh. Is it doable? Well, yes, but 3D object construction is not exactly my forte, and it does seem a bit like overkill to add all those triangles for one little hand.

Hello, Hack-imation

Time is always an issue so I decided to do what I do best when faced with thorny coding problems: I cheat. Realizing that I only needed to see the back of the hand, I decided to go 2D. Yes, some of the movements are 3D, but smart animation can compensate for that.

First step: trace my hand on squared paper.

I traced the open hand, and also a a fist, and then tried to work out where the joints were. I like coding in circles, so each point of interest is a circle. I chose a scale such that I could type in ratios. The y-axis goes to 100, which is obviously 1.0f as a ratio, and makes scaling that much easier.

Yes, this will be a glove, which means I don’t have to worry about drawing fingernails!

If I had had the time, I might have chosen to render the hand in Metal. But I picked plain old Quartz for convenience and expediency.

I originally wanted to do the entire outline as one shape, but quickly decided against it, due to fingers and thumb sometimes hiding behind other digits (and the palm). So I draw the thumb, then little, ring, index and middle fingers in that sequence, because that’s usually the z-order.

The main part of the hand has to be drawn twice. Once at the back, and once more without borders, to erase the lines at the base of all the fingers. This is the “hack” part of the hack-imation, along with the right-hand-side, which I decided was most easily simulated with a Bézier curve.

How to draw a finger? Well, if you can work out where the outer tangent lines meet for two circles, that’s most of the job done. After that it’s just straight lines and arcs.

I treated the thumb like a finger, with the same number of joints. Yes, the base joint is just above the wrist!

One funny thing: if (as my picture shows above) you have the wrist curve dipping down, then your hand will quickly resemble a foot with spidery finger-toes! I strongly advise to flip that smile upside-down to avoid that!

Animating in Code

The maths required for animating a finger or thumb is refreshingly simple. Each joint moves from angle A (zero) to angle B in a linear fashion. You can eyeball the end angles. Just a few cos and sin functions required.

There are one or two sticking points, for example when a fingertip passes below a knuckle. That case is simple enough to simulate from a top-down perspective, however: simply, by drawing to the knuckle and no further.

There are always the odd graphical glitches that crop up, but these can be dealt with – either cleanly or with special-case hacks.

Using as a Cursor

When the hand is finished, the next step is to use it with the cursor. This is easy enough to do with your input code in OSX. The trouble (as usual) lies with iOS: there’s still no way of working out where your finger-tip is until it presses the screen.

What you can do is show the cursor when you tap the screen. You can add a small delay to have the hand fade in and then, when you tap-up, the hand can glide serenely away, fading out as it does so. But this is not ideal. I needed the hand to know where I was going to press for the product video.

I had a brainwave to connect a mouse to my iPhone and have a cursor show up at all times. Well, this works nicely on Android but not on iOS. On iOS, you can’t even connect an Apple mouse or trackpad to an iPhone! You can connect a third-party mouse, but nothing further: there’s no cursor.

Yes, I could have simply cheated and used OSX for all my product videos. But I didn’t want to do that. So I had to think again.

Automating

I thought, what if the hand did know where I was going to press? Rather: the hand could be coded to move, click, rotate, fade in and out, and so on. What I needed was a class to automate this.

Then it occurred to me: this wouldn’t just be useful for product videos, but for inline help.

The automation class here goes hand-in-hand with the calling class. At each indexed stage, the calling class should update such details as duration-of-action, hand-state, action-type, alpha, angle etc, and, as necessary, supply destination co-ordinates relative to a view it also supplies.

Finally you get something like this. Still not perfect, but it’ll do. 🙂

Once your masterpiece app is finished, there remain some irritating stumbling blocks on your way to the App Store. One of these is the product video.

A screenshot may tell a thousand words, but a good video can replace a fair few screenshots, and won’t require your potential beloved customers to scroll. Did I mention I hate scrolling?

You might suppose that the only challenge in the creation of a product video is to find software to record your screen. Unfortunately, this is the easy part. The difficult part is finding software that will also record your hand movements while your finger is still hovering above the screen.

Solution 1: use another device to take a video of yourself actually using the app!

This is a messy solution at best. Good luck to you if you want to do this. If you don’t have creepy hands, if you can eliminate reflections, sort out the lighting and background, and if you have good video after-effects software then this might work well enough.

Solution 2: Add a virtual finger (or hand) afterwards with after-effects software!

This may be a bit easier than Solution 1, and it should look neater. I almost researched this idea but decided that, if I were to make dozens of videos, it would take too long. In addition to the potentially prohibitive cost of after-effects software.

Solution 3: Draw the actual finger (or hand) in-app!

This was my favoured solution, because it’s more of a coding challenge. It does not require learning any other skills, or purchasing any other fancy software.

I tried to remember how I solved this problem before, years ago, for my previous apps (which are now lost in time). I had a vague memory of taking a photo of my hand and employing that as a makeshift cursor. Then using the simulator to record everything.

Why didn’t I take a look at my old code? Well, because coders like me really don’t like doing that. Nobody should want to peruse the horrible code of our less-experienced selves. We much prefer writing shiny new code.

But anyway, the first step was to photograph my hand. I wanted two top-down shots of a pointing index finger, with one of them simulating the tap motion.

You won’t believe how wretchedly difficult this is to do. Because, the thing is, I needed to have a background which I could magic away quickly in software. Yet no matter what colour card I had underneath my hand, masking this out in one go proved extremely difficult, due to shadows and skin reflections and weird optical illusions like this one.

In the end, I thought back twenty-five years. My preference back then was never to use photo-manipulation software. It was to use vector software and manually mask out the image, using straight lines and Bézier curves. This is what I did (thanks, Inkscape).

So, coding a hand for a cursor is trivial. It’s not a proper cursor, of course, rather it’s an image that has its origin at the pad of the index finger and follows the mouse around. But here was my new problem:

My hand looked extremely creepy as a cursor.

I had to ask myself: was my hand always this creepy? I know I’m no spring chicken but that thing was like something out of Tales of the Crypt. Does my hand really look like that in real life?!

Well, it wouldn’t do at all, and I didn’t want to go through that whole process again with someone else’s hand. What if their hand turned out to be just as creepy as mine? On the other hand (ahem), what if it looked great and I ended up with a complex about my own general hideousness.

So, my next thought was to draw a cartoon hand. Well, actually, not a hand: a glove. If it’s good enough for Bugs Bunny then it’s good enough for me. Now, I could draw this with pencil on paper and then scan it in and that would surely have been the best solution.

But then (unfortunately) I had another idea, and it was this: I should really draw this hand in code…

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