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…