The city that never sleeps (Tech)

Navigation between questions raised a new issue: the “Enter” key or the “Tab” key? How would these two buttons work in the context of Typeforms? At first, we allowed “Tab” and “Enter” to be used interchangeably to move to the next question, but assigning two buttons to do exactly the same thing seemed weird. So, we asked ourselves, what could we learn from what’s been done before?

In every other app or website, the “Tab” key is most commonly used to move between elements. You use it to jump between fields in a traditional form and to move between parts of a Web page. It is a non-committal way to move around. The “Enter” key, on the other hand, is most commonly used to commit to a decision. It’s the button we press to take an action or to submit a traditional form.

So, in learning from those who came before us, we decided to assign “Tab” for jumping between questions without setting off any validation checks. This way, you can move around the form without having to use the mouse. Pressing “Tab” brings the next question into view, ready to be filled out; “Shift” + “Tab,” in the same way, take you back to the previous question; and the arrow keys let you move up and down in the form as you’d expect.

Our next choice in keys was much harder to make: how to use the “Enter” key. It’s widely used in many apps to complete an action, but is also used to add a line break to text. In a form, we feel it’s far more common to need to quickly complete an action than it is to need to write multiple paragraphs of text, so we chose to use the “Enter” key to validate and submit responses. If an answer does not validate, then the user is asked to correct their answer; otherwise, they’ll move onto the next question. Then, we used the common “Shift” + “Enter” shortcut for line breaks when writing multiple paragraphs of text, the same shortcut commonly used in chat apps like Facebook Messenger.

Ideally, though, users shouldn’t have to use “Tab” or manually scroll to navigate forms at all, even though the forms show only one question at a time. That’s why we designed the forms to auto-scroll to the next question as soon as the current question is answered. Most forms require you to scroll through to see all of the questions, or even click to other pages to continue the survey. Our approach keeps respondents focused on the conversation and makes it far quicker to fill in the form.

After deciding on the basics of our UI, we tackled interaction design as the next challenge. Our focus was a computer without a touchscreen, accelerometer, webcam or even a mouse. All that is needed to interact is a keyboard. After all, if you’re just answering questions, what more should you need? Traditionally, a typical form forces you to move back and forth between the mouse and keyboard. You’ll click in a text box to type something in, and then reach for your mouse or squint to tap on your smartphone’s screen to fill in a multiple-choice question. If the form doesn’t already look bad enough, then the rows of tiny bullet points should be enough to get respondents screaming for the hills.