Creating a Custom Keyboard
WHAT
TO DO
with
ALL THESE
LETTERS ?!?
When I became Lead Designer for TV apps at Starz, creating consistency was a top priority. We wanted our apps to have a cohesive look and feel, and predictable flows and navigation across all devices. For the television platforms, this initiative presented a number of unique challenges — one of which was the keyboard interface.
When designing for mobile and web, I rarely gave much thought to the keyboards. They were just a built-in part of the device that people already knew how to use. But TV was a completely different story. Historically, our streaming apps relied on the native default keyboards, with the assumption that the user is already accustomed to their device interface, so it's more user friendly to keep it that way. But, native keyboards across various devices and platforms have very inconsistent interaction patterns and aesthetics. So I was tasked with designing a custom keyboard for our television apps. (In retrospect, I could have made good argument for using either native or custom keyboards, but that is a discussion for another time.)
ASSUMPTIONS & ANALYSIS
Keyboards are an integral part of most apps, and are an essential piece of the user flow for features like purchase, login, and search. Because they are so prevalent within interfaces, I figured this would be a relatively straightforward task. (Hah!) I planned to start with a quick competitor analysis, to compile an overview of what others had done with their keyboards, and who had done it well. Unfortunately, a quick survey of keyboards across multiple streaming devices and apps left much to be desired. I present now, for your viewing pleasure …
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 keyboards 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?
In an ideal world, user testing and analytics would come into play here to help us make informed and purposeful decisions. But in reality, budget and resources for user testing and research were extremely limited, so I focused on more informal methods. For this project, that meant relying on examples from competitors who are able to do a lot more research (hi Netflix!), and running informal user tests with coworkers, friends, and family as the users.
And of course … 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 found 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 virtual reality keyboards were probably closest, simply because they weren’t a touchscreen or a physical keyboard, but they was still pretty far off my search for “keyboard design specifically for TV screens + remotes”. Even the UX research masters at 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.
QWERTY OR ALPHA?
Time for a test!
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.
and 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.
and therefore 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 keyboards that I believed were a decent representation of the various layouts. Those were:
I asked users (who were an even mix of coworkers and friends/family) 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 the user made (such as selecting the wrong letter and having to delete)
How long it took the user to correctly complete the entry
It didn’t take long for a pattern to emerge from this simple test.
The Results
Option 1 = 😕
Meh.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 = 😍😍
Winner Winner Chicken Dinner!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 = 😡
Shame. Shame. Shame.This layout was the clear loser. Users had an average of 30% more errors, and took almost twice as long to complete the entry.
Option 3 had, well, a lot of issues. Many users struggled to focus their selector on the desired letter, 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. My guess is that this decision was probably influenced by a number of factors, including :
BTW: if I’m your designer, usability and usefulness will always take priority over visual aesthetics. Even though I love pretty things, I fight for the user. Or, even better, a combination of both aesthetics AND usability.
The presence of a microphone. Maybe they figured there is no need to enter text at all when you can speak to Siri (assuming Siri understands you correctly 😬)
And perhaps that left the folks at Apple feeling more free to design a keyboard that favored design aesthetic over usabiliy (this certainly wouldn't be the first time Apple made something that looked pretty but was difficult to use).
Between Options 1 and 2 there was also much debate, especially since our team mostly expected the Qwerty keyboard (Option 1) to be the clear winner. Lots of people (especially within our IT department) 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. My coworkers were probably already biased towards a Qwerty keyboard because we use them all the time. Overall they are a very tech-savvy group of individuals who do a lot of typing, and I'd guess that each person in our department had an average of 5 different devices on their desk at any given time. Simply put, we know a Qwerty keyboard. And because we are surrounded by people with the same knowledge, we have a natural tendency to assume that other people are also comfortable with a Qwerty keyboard. This is a classic example of confirmation bias. We're so familiar with the Qwerty arrangement that we rarely need to even look at the keyboard while using it.
This 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. We have memorized the 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 hidden 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 something that only the fingers know. In that situation, we know the alphabet much better than the Qwerty arrangement.
Would you be able to fill these in from memory?
Nowadays there are lots of schools that do actually teach kids to memorize the keyboard. So it's quite possible that 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!
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 use of muscle memory, the Qwerty keyboard is 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 the testers themselves 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 significantly 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 like "Space" and "Delete" and 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 context-aware 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 this point, we were definitely planning on at least two different keyboards, so I decided we might as well simplify Search even further. 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 for the Search keyboard.
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.
The Email keyboards were a bit more varied, 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.
Honestly, I still don't quite understand all the variants of ASCII, but eventually made an executive decision to limit “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.
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. For example, I'm still not particularly fond of how the characters are split , and I would have liked to divide the letters equally and put the numbers on a row of their own. But screen space is limited, and the 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.
And that, dear reader, is the end of our study on keyboards. 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 ❉ ❉ ❉