Thread by @benskuhn

I just finished *Creative Selection* by Ken Kocienda, which is largely the story of how he came to build the iPhone keyboard.

It’s a great example of how many twists and turns it can take to come up with something that seems so incredibly normal!

v1 started out looking like...

some wacko phone-keypad variant, because the developers were super worried about touch targets being small. The input method for this was: tap to get the top letter, swipe left/right to get the bottom letters.

Except instead of the letters being organized like a phone keyboard, they’re jumbled up. (Presumably to make sure that common letters were taps, not swipes? But that plus the gestures seems impossible to learn.)

The first key idea for v2 was realizing that you could make it tap-only by using a dictionary to figure out which of the 3^n possible things you might have meant was actually a word. (The “T9” feature phone autocorrect software already did this, iirc.)

The second key idea was realizing that you could arrange it like a traditional QWERTY keyboard, but still group keys into larger buttons. This made it way, way easier to learn because people had QWERTY in muscle memory already.

Apparently the way they settled on this approach was by having a competition where a whole team of 5-10 people each built their own keyboard ideas. I guess that makes sense as a thing to do when you’re limited by idea quality and not execution speed!

Anyway, after the competition people loved this, but some problems came up in dogfooding: typing words that weren’t in the dictionary was too hard, and if you zoned out during a long word, you had no cues to remind you what letter came next. (Example from T9.)

The author got stuck on this until, during a demo where he explained why this was an inevitable consequence of multi-letter keys + dictionary, someone yelled at him to just go back to single letter keys, and he realized that autocorrect was now good enough for that to work.

Breaking up the keys led to a design that was pretty close to the final product.

Autocorrect was good enough to make this design workable, but still rough, so they spent most of the rest of the time improving it further.

Finally, it got good enough that they could simplify again by killing the suggestion bar, because the first option was almost always right.

So in retrospect, what it looks like happened is that they started out with a totally wacky design, which was the best they could do with crappy autocorrect. Then, as autocorrect improved, they progressively removed the weird/complex bits until ending up with something “normal.”

One thing I found super surprising is that when Apple committed to no hardware keyboard, they were still at the “totally wacky” stage. Seems like an amazing leap of faith to bet the iPhone on the assumption that they’d come up with something that worked well!

Another thing that surprised me is that the author spent ~0 time trying to do the text prediction in the “principled”/“optimal” way. He got people to explain Markov chains to him, but the math went over his head so he homebrewed his own prediction algorithm. Worked fine anyway!

I thought the stage in the middle with the QWERTY layout but big keys was interesting. It reminded me of similar things I’ve seen on a smaller scale that we’ve had at Wave—a design that checks all the boxes, but my reaction to it is still “huh, seems kinda weird but ok.”

Almost always in these cases, we later discover some problem with the design, fix it, and the fixed version doesn’t trigger my “seems kinda weird” intuition. Unfortunately I’m still really bad at turning “seems weird” into actual critiques though!

Anyway, mostly I thought this was a really instructive example of how many twists, turns, false starts, and rabbit holes it can take to get to a product design that seems obvious in retrospect—even for the pros :)