How to lose form data and alienate people

On poor form

By stef

Backspace as navigation needs to die. I was writing something late last night, happily typing away in a text box in a browser. A notification popped up so I went over to my twitter app, replied, and then went back to my browser.

Not realising that the text area I was typing in had lost focus, meaning that the window was now receiving keyboard events rather than the text box (bear with me, if that sounds confusing), I went to delete the last word I had written. 

Bang. I was suddenly on the previous page. By pressing backspace, my browser had navigated back instead of editing the text

I held my breath and pressed the forward button. And I'm sure you're familiar with the feeling of arriving on a page hoping that your text is still there, only to find a blank text area and your work lost. 

It’s 2013. Why do we still tolerate this kind of stuff? How is it possible that so many people are working on building web-apps, that still rely on the humble web form, yet the base experience still feels like it’s held together with string?

If you think through what happened there are several quite abstract concepts going on, that even I as someone who makes things on the web, find hard to explain. The average web user must be baffled and frustrated by this stuff. 

Defocus is opaque

The idea of “focus’ requires an understanding of “where you currently are sending text events” which is pretty hard to grasp. Focus is based on the idea that if you’re “in” a window, and click on a place that lets you type text, or interact in other ways, then the thing you’ve clicked on is “given focus". 

If I open a new window, go back, or do something that the designer of a web page/app didn’t originally envisage, what will happen? The thing is, until you try it, you’re never quite sure, and everyone from time to time experiences “loss of focus”. That’s not usually too bad, because you just click on the place you want to type and on you go.

The backspace key to go back. What?

Except, for some reason, the designers of various web browsers, in my case Chrome, decided that because there is a button at the top right of your keyboard that looks like an arrow pointing left, that they should make it so that if you press it on a web page, it should navigate back. 

I know that some people use this feature. The same people that probably use “swipe to go back”. That got me a few times too, until I disabled it. Lost work or progress because of an accidental trackpad gesture!

Personally, I think that overloading the meaning of the “delete the last thing I typed” button with “accidentally throw away my work by going back” is harmful.

Forms are fragile

As we move to an increasingly mobile web audience, and become more reliant on web-apps and forms to do things, the more important it is that we instil trust in the people who use the things we make. At the moment, my default is not to trust a form. I think that needs to change.

I've observed my own behaviour when it comes to fill in in a form:

“Oh, I see a text area here” → Open a text editor window (Sublime Text keeps my unsave work even if it crashes) → Write it there → Go back to the web page → Paste the bits in → Do all the drop downs and small text boxes → Submit the form.

Not everyone knows to defend against lost work by writing elsewhere. They shouldn’t need to either! There are several scenarios where that could happen:

Expiring sessions

Let’s say it’s a long form. You fill it out, maybe go and make a cup of tea or get distracted by something. I am often amazed that when I press submit I get some kind of “your session has expired” message and whatever I have spent time filling in has gone.

Connection dropout

Increasingly we use mobiles to do things, and there’s often a time when you’re trying to do something on your phone, you submit, wait for ages, get that sinking feeling and are presented with “connection timeout”, “your request could not be completed” or similar. If you’re lucky you can try to repeatedly resubmit the form, but if you don’t know what you’re doing, you press back, and bam. Blank canvas.

Server errors

Sometimes, it’s just down to bad code. You submit a form, it causes an error and you get a “sorry, something went wrong” page. That’s even worse because often the page doesn’t contain what you wrote, and there’s no way around it but to start again from scratch.

How can we make this better?

I’d like to suggest the following principle for those of us who make web forms:

If the page I am making requires people to add lots of text I must defend against losing their work

It sounds simple, but is surprisingly difficult to stick to. Here are a few ideas for us web-form makers:

Always validate before submission

There are many approaches to form validation, but in general you shouldn’t rely on the server for basic validation. Validate on the fly before the person clicks “submit” and you reduce the potential for failure. Oh, and while I’m at it. Don’t have a password format with maximum character limits and disallowed characters. A minimum length is okay, I guess.

Disable "backspace for back"

Yes it's opinionated. If someone really wants to go back whilst editing a long form there is a back button they can use. The idea is that all backspace key presses are captured by the page unless focus is in a textarea or contenteditable region. And then it does nothing. 

You're leaving the page

Another approach I’ve seen is to pop up a message that says “you have unsaved changes”, which is probably wise to defend against accidental window close events. It feels a little old-school, though, so perhaps there’s something elegant you can do in your interface using a “flash” or a modal.

Save-as-you-go

The ultimate is that the entire contents of the form are serialized somewhere while the person fills it out. “Save” is really just “put it somewhere while it’s in transit”. So you could serialize the form every few seconds to localStorage, or even to the server if you’re that way inclined.

Recover from a failed form submission

If you’ve been using the “save-as-you-go” approach (something that Medium seems to tackle well, if you’re looking for an example) and there was a failed submission, you could display a flash to say “do you want to recover your unsaved changes?” or even automatically recover the form state. With many of the modern javascript frameworks you get a lot of this for free, as long as you’re serializing to localStorage.

Make sure sessions don’t expire

You’re probably not a bank. So you should probably just not make sessions expire unless the user closes the window or logs out.

Do as I say, not as I don’t

When you’re building web things, it’s hard to justify the additional expense (time and money) of doing things the best way, which is why we end up with just the bare minimum. I’m going to make it an aim for us at Makeshift that we try to come up with some standard patterns and code components for forms. It’ll no doubt be painful, but I suspect it’s the kind of thing we’ll open source. 

If you have any suggestions for other approaches to improve the form-filling experience, let me know on Twitter and I’ll update this article.