Options, Options

We had a few simple goals in mind when we set out to create Typefinity Keyboard. We wanted to bring a laptop-style keyboard layout to the iPad, because switching to an iPhone-inspired alternate layout to type a number or punctuation was just painful when working with a keyboard area roughly six times as large as a phone’s. (We later actually brought Typefinity to the phone as well since they have grown much larger since.) We wanted to add arrow keys, because none of the various videogame-like ways Apple had devised to move the cursor around in text were anything but frustrating. And we wanted to allow typing shortcuts like ⌘-c to paste or ctrl-e to go to the end of the line. Just a few things that those who prefer using the keyboard instead of the mouse as much as possible on computers would appreciate.

It turned out that neither the Control nor Command keys were possible, because it never occurred to Apple that an on-screen keyboard might want to provide these keys and therefore they didn’t provide any way for the keyboard to tell iOS that such a key had been pressed. 😐

As an afterthought we did include an option key (⌥) and had it access an alternate layout containing symbols and accented characters. Such a layout comes “out of the box” on every Mac and is often useful for typing names from foreign languages, parts of mathematical equations, and special symbols. Many users are familiar with option-8 to get a bullet for example. Since Typefinity’s philosophy was to bring familiar layout from the laptop to the iPad, we copied this “option layout” straight over, in its own unique form for each language we implemented.

Mac Opt Layout, US English

Mac Opt Layout, US English

We didn’t stop to question where these layouts came from or how useful they really were to users. We assumed they, like the design of the main keyboards themselves (“qwerty” for English, “qwertz” for German, “azerty” for French, etc.), were the result of historical development that had hopefully led to something useful.

Qwertz Layout (German)

Qwertz Layout (German)

Azerty Layout (French)

Azerty Layout (French)

Opt Layout, German

Opt Layout, German

Opt Layout, French

Opt Layout, French

But what you’ll notice is that, besides a smattering of Greek letters, a couple of accent keys, and some common symbols like , ®, , and ©, most other keys are rather useless. Some users called us out on this, but besides having many other priorities such as delivering competent autocorrect, we were reluctant to “innovate” here. Despite the obvious uselessness, we obstinately stuck with our philosophy that the traditional layout must be that way for a reason and we don’t want to mess with it.

Fast forward several years and we finally saw the light and decided to do something for Typefinity 2.0. We started with the sensible goal of providing the useful keys and dropping the useless ones. We also decided to dispense with “dead” accent keys, the ones where you first type the accent and then the character you want accented. This is actually slower than using the onscreen key popups and we couldn’t see any reason to preserve them. (We dropped these from the main layouts that had them as well.) Finally we wanted to make the opt layout uniform across languages so that users who switch between them wouldn’t be thrown off. This last goal proved tricky because users do rely heavily on parts of the existing opt layouts in Europe, where they are needed even to get to “ordinary” symbols like @, /, or [ ]. We ended up compromising by preserving some of these common mappings (which are mainly on the number row) and doing swaps elsewhere to avoid duplicating keys. The results for US English (and largely for other languages as well) were:

Opt Layout, iPhone

Opt Layout, iPad

Shift-Opt Layout, iPhone

Shift-Opt Layout, iPad

The upper left is focused on mathematical symbols, the middle row on the most commonly used Greek letters, and the bottom center/right on quotation marks. Common accented characters in major European languages are available – should the user prefer to type them without popups – on the right. Currency and footnoting symbols occupy the middle of the top row, while the top right side on the phone picks up characters that have their own main layout keys on the more spacious iPad, which uses this space instead to throw in some additional symbol and logical operator keys.

It took quite some time to come up with this design and optimize it, but it was exciting to be designing a keyboard layout from scratch, and we hope our work may even inspire developers of Mac and other operating systems to rethink their option layouts in the future.

Note, there are certainly choices one could quibble with, for example why approximate equals but no ± on the phone, or why not logical and/or / instead of double and single arrows on the iPad? Rather than agonizing endlessly over these choices, we hope users will tell us what they prefer. If you’re reading this and have an opinion, please get in touch via our support web site. We hope to hear from you there – and happy typing!

Intelligent Punctuation, or How Software is 98% Perspiration

Perhaps Thomas Edison’s most enduring legacy after the incandescent bulb (now on its way to join the gas light and the horse carriages in the annals of human history) is the adage, “Genius is 2% inspiration and 98% perspiration.” While this surely applies in many areas of applied science and engineering, it is especially evident in software. We run into this every day when developing Typefinity, our iOS on-screen keyboard app.

The aim of Typefinity is to bring a more laptop-style keyboard layout to iOS, where you can punctuate sentences and type numbers without needing to switch to alternate layouts. In general, it’s more efficient to use for doing more “work-ish” kinds of things, though the smaller keys that the full layout brings means you give up some speed when banging out simple texts. And of course using any on-screen keyboard gives something up compared with using a physical keyboard. Nearly all software keyboards, including ours, implement some simple automation to try to make up for this ergonomic deficiency.

Autocorrect is an example of such automation. So is doing basic things like capitalize your sentences without you needing to hit ‘Shift’, and inserting a period after two spaces since the keyboard can safely assume you wanted to end a sentence. Since Typefinity is about efficiency and also makes some ergonomic sacrifices in the name of the greater good of avoiding extra layouts or “modes” in the keyboard, we’ve naturally implemented these basics, and even included some extras like autocompleting single letters to the most common words in the current language starting with them. (In English, ‘t <space>’ will give you “the”, ‘o’ “of”, ‘f’ “for”, and so on.) But one of our users suggested we could do more by adding a bit more “intelligence” to the keyboard.

He had noticed that punctuation is written with particular patterns of spacing around it. We put space before and after a dash — but only after a comma, or a period. And directional punctuation like (parentheses) and “quotation marks” have spaces before or after depending on their orientation. All of these could be implemented by the keyboard: either automatically inserting spaces after punctuation characters, or before, or even removing space that shouldn’t be there , like if we decide to end a clause or sentence after already inserting a space (or having had one inserted after an autocorrection).

It sounded like a great idea, and doable because iOS provides keyboard apps with the text around where the user is typing. It took us a little while before we could start on this, but once we got rolling on it, we figured all we’d need to do would be to fire up some logic when the user typed a punctuation character to add or delete spaces appropriately. We started by making a list of the punctuation characters that we wanted to act upon. This included comma, period, semicolon, and colon, and we soon determined that any “clause ending” character fell into the category. Then we deleted space before these characters if it was there, and added a space afterward.

This simple implementation worked fairly well in many cases. The first complication we ran into was typing things like dates, times, and numbers. In these cases the rules change – you don’t want any spaces in 3.14 or 12:15 for instance. We worked around this by checking what kind of character lay before the cursor, skipping any action if it were a number. Then we ran into problems when the user wanted to type punctuation characters together, such as in … or --. Additional complications came when parentheses or quotation marks were involved, and handling situations when the user selects offered word suggestions while in the middle of other text and punctuation.

Overall it took several cycles of iteration internally and two external releases until we had it “right”, or at least only rarely causing annoyance. It’s still not perfect and we’re still working up the courage to turn it on by default. But it’s good enough that it leaves us with a feeling of going back to “manual mode” when using a regular computer keyboard and having to insert and delete all those spaces by hand.

The current code involves constants for character classes, and local state variables to track the context while executing multiple detection and conditional statements. It is really a textbook example of software development, where a simple idea and simple implementation become gradually more complex, as new possibilities and wrinkles are discovered in the real-world situations it deals with. The challenge, as always, is not to anticipate all of this from the beginning, but to evolve the design and approach so the code is as simple as possible — but no simpler.