Designing a Custom Keyboard

What to do with all these letters?!?

pexels-photo-373072.jpeg

Seems simple enough.

Right???

When we embarked on our last major redesign project, one of the highest priorities for the STARZ apps redesign was consistency. We wanted our apps to have a cohesive look and feel, and predictable flows and navigation, no matter what device was being used to view them. For the television platforms, this initiative presented a number of unique challenges–one of which was the keyboard interface. As a web or mobile designer, I rarely ever gave much thought to the keyboards . . . they were just a built-in part of the device that people already knew how to use. But on a television, it was a totally different story. Historically, we had mostly relied on the device native default keyboards, and the thinking had always been "the user is already accustomed to that interface, so it's more user friendly to keep it that way". But with our aim set on consistency and cohesion, relying on native keyboards was no longer an option. (Personally, I could have made good argument for either native or custom. I think there are pros and cons to both, but that was beside the point.) So, I was tasked with designing a custom keyboard for our STARZ TV apps.

Keyboards are an integral part of the app design, and are heavily used in Purchase, Login, and Search screens. Because they are so prevalent within interfaces, I figured this would be a relatively easy task (oh how naive I was back then!). I am a firm believer in not reinventing the wheel, so I planned to start with some competitor analysis, thinking "let's see what else is out there, and who else has done this well". Unfortunately, a quick survey of keyboards across a plethora of devices and apps left much to be desired. I present now, for your viewing pleasure, 

a smorgasbord of keyboards . . .

So, my survey of other keyboards produced more questions than answers. There was clearly no "standard" for layouts or letter arrangements. Many devices used the Qwerty style keyboard, but just as many others used an alphabetical arrangement. Some of those had the entire alphabet arranged in a single row, others had the letters split into multiple rows. Some had numbers on the same view, others put numbers on an alternate screen. So, which is best for our purposes?

Ideally, user testing and analytics would come into play here to help us make informed and purposeful decisions. Ideally. But the reality is that our budget and resources for user testing and research is extremely limited, so we have to make do with more informal user testing and research methods. For the STARZ UX team, that means relying on examples from competitors whom we know do a lot more research and analytics than we do (hi Netflix!), and running informal user tests where our "users" are coworkers, friends, and family. And Google, lots of Google. I spent healthy dose of time scouring the internet for any sort of case studies, tutorials, or blog posts on best practices regarding keyboard design for TV. I did find a lot of interesting articles related to the history of the typewriter, the Dvorak keyboard, new keyboards designed specifically for thumbs along with lots of guides on designing keyboards for touch screens, some fascinating stuff on keyboards for virtual reality, and this guy's very specific analysis of two different Windows keyboards. Unfortunately, I didn't find much that was very relevant to my particular design challenge. The VR stuff was probably closest, simply because it wasn't a touchscreen or a physical keyboard, but it was still pretty far off my target: keyboard design specifically for TV screens + remotes. Even the UX research masters, Nielsen Norman, had very little useful information. I was definitely disappointed, but really not too surprised. Design for TV is, after all, a pretty niche corner in the world of UX.

So, QWERTY or Alphabetical?

This question really had to be answered before jumping into design comps . . . it could have a heavy influence on the overall layout of the keyboard. If the Qwerty option was the winner, we could infer that a user's pre-existing familiarity with that kind of keyboard had a major influence on its success. If existing familiarity was a factor, then the keyboard would really need to follow the standard existing Qwerty layout for there to be any benefit to the user. On the other hand, if the alphabetical arrangement proved more successful, the field of design possibilities would be wide open. As long as the letters were in order, I could arrange the keyboard however I wanted. So, I had to find a way to test these options. I started by selecting three different TV screen keyboards that I believe were a decent representation of the various layouts: a standard Qwerty (Option 1, Android TV), an alphabetical grid (Option 2, Amazon Fire TV), and an alphabetical single row (Option 3, Apple TV). I asked users to perform one simple task–enter their email address into the field using each of the three different keyboards. I planned to measure success by two factors: how many errors they made (such as selecting the wrong letter and having to delete), and how long it took them to correctly complete the entry.

Option 1 =  🤔 

Overall error rate for this keyboard was about the same as Option 2. However, time to complete was an average of 8 to 12 seconds longer when using this keyboard.

Option 2 = 😍  

This was the most successful layout overall. Error rates were about the same as Option 1, but users successfully completed their entry an average of 40% faster.

Option 3 = 😖 

This layout was the clear loser. Users had an average  of 30% more errors, and took almost twice as long to successfully complete the entry. 

When it came to Option 3, many users struggled a great deal to focus their selector on the desired letter on the first attempt, often accidentally scrolling past their target multiple times, which had a large impact on the overall time to complete. These results sparked a lively debate among our team as to why Apple, a darling of the design world, would choose to use such a un-friendly layout. Many theories were put forth. Personally I would guess this decision was probably influenced by a number of factors, including the presence of a microphone (no need to enter text at all when you can speak to Siri), which perhaps left them feeling more free to design a keyboard that favored design aesthetic over usefulness (this certainly wouldn't be the first time Apple made something that looked pretty but was difficult to use). And just in case you're wondering, if it were up to me, usefulness would always take priority over design aesthetic. As much as I love pretty things, I fight for the user . . . or even better, a combination of both!

Between options 1 and 2, there was also much debate, especially since our team mostly expected the Qwerty keyboard to be the clear winner. There were a good number of people (especially among our department) who had better success with the Qwerty keyboard. However, our "friends & family" group of test users that might be classified as more "general public" (and also less tech savvy) clearly did not feel the same. I have a couples theories as to why the preferences were so polarized.

Theory number one: familiarity. Our internal UX team and larger department (which includes all of the developers) is likely rather biased towards a Qwerty keyboard because we use them literally all the time. We are, as a whole, a very tech-savvy group of individuals who do a lot of typing, and use many different devices. I'd guess that on average each person in our department has at least 5 different devices on their desk at any given time. Bottom line: we know a Qwerty keyboard. And that knowledge is so prevalent that we don't even think about it. Because we are surrounded by people with the same knowledge, we naturally tend to assume (subconsciously) that most other people are also comfortable with a Qwerty keyboard–a sort of confirmation bias. We're so familiar with how it works, and which characters are where, that we rarely need to even look at it while using it . . .

Would you be able to fill these in from memory?

Apparently nowadays there are lots of schools that do actually teach kids to memorize the keyboard. It's quite possible the blank keyboard test would have very different results depending on the age of the tester.  When I went to school, they didn't teach that kind of stuff, but who knows, maybe in a couple decades the Qwerty keyboard really will be common knowledge for all people!

. . . Which brings me to the second theory: muscle memory. Those of us who prefer a Qwerty keyboard do so because it's the path of least resistance (that's basically human nature). We have memorized this arrangement of letters so thoroughly that our fingers just know where to go without even having to think about it, and our brain has long since filed that memory away in the dark and dusty corners of our mind–right next to cursive handwriting and the capitals of all 50 United States. However, on a TV interface, the ability to rely on our fingers and a physical keyboard is gone, and suddenly we do have to think about it. Our eyes have to search for the letters on the screen and our brain has to  kick into overdrive to recall what only the fingers know. In that situation, we know the alphabet much better than the Qwerty arrangement. Consider this: if you were given a piece of paper with blank squares arranged in the shape of the Qwerty keyboard, would you be able to fill them in correctly? I know I wouldn't, but I will always know the alphabet. So I came to the conclusion that without the ability to use muscle memory, the Qwerty keyboard is actually more difficult for most people to use.

Of course, this was a rather simple test, (and I definitely don't claim to be an expert when it comes to user testing) so it's likely that others would get different results. But there was some evidence to support my theories. A good portion of testers expected the Qwerty keyboard to win, but when tested, they performed better overall on the alphabetical. Additionally, our sampling of competitor keyboards revealed a vast majority of our our direct competitors used alphabetical keyboards (Netflix, Amazon, and HBO, to name a few). And since we already know that Netflix, for one, does way more analytics and has tons more data than we do, we tend to assume that their research does influence the design of their apps. Of course, many of our developers still complain about the custom keyboards we use and insist that a Qwerty keyboard would be better, but they aren't really our "average user".

How many rows?  and what about !@#$%^&{}?

Once the decision was made to use an alphabetical grid arrangement for our custom keyboard, the next step was to decide how to arrange it. Along with the letters, we wanted to include the number keys, and also a couple of other commonly used and necessary buttons. "Space" and "Delete" needed to be included everywhere, and we also definitely wanted to include an option for "Clear All" on the Search screens (similar to the iOS use of an "x" to clear search fields). We also liked how Apple presented "smart" keyboards based on the type of form field: email entry keyboards include things like ".com" and @, which contribute a great deal to overall ease-of-use for an email field, but are pretty unnecessary for something like Search. At that point, we were definitely planning on at least two different keyboards, so we might as well simplify Search even further. Yay for simplicity! Since our Search results are not case sensitive, there was no need for a separate set of upper and lowercase letters (and therefore no need for a "shift" key). Special characters like "#" and "$" would not produce useful results from our current Search algorithms, so those could be eliminated as well. In the end, we settled on just letters, numbers, Space, Delete, and Clear All on the Search keyboard, for a total of 39 buttons.

Thirty nine boxes meant a lot of potential options for the grid arrangement, and I would have loved to test them out as well, but deadlines were pressing. I had a personal preference for Netflix's short and easily-digestible rows of 6 (with Space and Delete spanning multiple columns), but the layout of the rest of our Search screen (where and how results would be displayed), prevented us from doing this. To maintain a nice grid, I had to keep the rows even, which meant I could only split up the characters at certain intervals, but there was some flexibility to span columns with the other buttons like Netflix did. After many rounds of comps, the final decision was made to use two rows of characters, and a third row for Space, Delete, and Clear. 

STARZ custom Search keyboard - the final result.

So here is the end result of a project which I assumed would be quick and simple, but ended up lasting weeks and being much more complicated than I ever expected. Of course, no designer is ever satisfied with their own work, and I am no exception. I'm still not particularly fond of how the characters are split here–I would have liked to divide the letters equally and put the numbers on a row of their own. But our screen real estate is limited, and our kitchen has many cooks. So I made my peace with it and moved on, content with the fact that I learned a lot in the process, and gained a huge appreciation for all the keyboard makers of the world. 

But wait . . . what about the email keyboard? On those, I did get to separate the numbers from the letters. With the Search keyboard as a starting point, I added the "convenience" buttons that are specific to email (.com, .net, .edu), and toggles to switch to uppercase characters and special characters. Taking a cue from some of the other keyboards we had already seen, this one would have three different states: lowercase, uppercase, and "special characters" (things like punctuation marks, currency symbols, etc). We had another lively debate on which special characters would be included, this time even sparking the interest of the development team. Oh man, if you ever want to see a group of developers get fired up about something, ask them to define "special characters" and which ones they think a should be allowed in form fields! Or, if you're an intrepid reader and have already gotten this far, click here to read an awesome chat we had in Slack over ASCII, Unicode, UTF-8 and emojis. Honestly, I still don't quite get it, but eventually made a bit of an executive decision to limit the special characters to those that are available using shift+key on a computer, and a few extras from the iOS keyboards, which I figured would cover the vast majority of user needs.  After spending quite a bit of time fiddling with placement and spacing, I ended up re-using some characters on multiple states of the keyboard, mostly for the sake of filling in the boxes so it didn't look weird. Hey, not every design decision has research and analytics to back it up . . . that's life. The special characters board still ended up with some blank spaces, which trigger my designer OCD every time I see it, but I dare not re-open the special characters debate at this point. So, here they are in all their glory:

And that, dear reader, is the end of our study on keyboards. They may not be perfect, but when it comes to keyboards, I think there are lot of good potential solutions. The creation of these keyboards taught me many interesting and valuable lessons, which have helped to shape my ideas and hone my skills as a designer. And maybe, just maybe, if you've made it this far, you've learned something too.

❉ ❉ ❉     The End     ❉ ❉ ❉