Hacker News new | past | comments | ask | show | jobs | submit login
Dear Internet: Take the reset buttons off your damn forms (pin21.com)
181 points by f00li5h on April 13, 2011 | hide | past | favorite | 76 comments

A similar annoyance is writing a well-thought out forum post, pressing submit, and being told in some way that your session has expired.

Some sites you can go back to retrieve your post, others will just present you with a newly empty form.

I've actually been conditioned so thoroughly by flaky forum software to ctrl-a-c on every post before submit that I don't even think about it and sometimes I'm surprised when I paste later and get whacked with a giant forum post.

I also do this. Not just on forums, but on pretty much anything where I write a decent amount of text. I also use a clipboard manager in conjunction with this habit (http://itunes.apple.com/us/app/clipboard-history/id420939835...) that has saved my ass numerous times.

I have dealt with this a number of times, and any time I think I am going to write a comment that is more than a few lines long and has any real significance to me, I do it in a word processor or full text editor where I can easily review it and spell check it before posting.

Or losing half the fields due to a validation error, which then creates other validation errors when you re-submit. "Oops! Your password contains illegal characters. Please select a new password. (submit) Oops! Please select a state from the dropdown menu."

I recently purchased new insurance. One company's site created its own scrolling widget for drop downs. Not sure why, but each page had several of these devil widgets.

If you spun the mouse wheel every single custom scroll widget would rapidly change value! Things like jumping from "Single" to "Divorced." I ended up just dropping them from my comparison because I was so unsure of the data I had provided them.

I really find it annoying that I have to retype my password whenever there is an error with a completely non-related part of the form.

I know that it would be irresponsible for them to send me back my password in plain text, so I guess I can live with it. But it is still annoying.

There are straight forward workarounds for this problem. The password field is typically obscured anyway, so the user doesn't see the characters in the field. When a user submits a form where they are asked for a password and a confirmation, you can temporarily persist that data on the server side, linking it to the user's session. You then send a dummy string to the client that matches the length of their supplied password, so that A) the user doesn't have to re-fill your password & confirmation, and B) the raw password data is not sent back to the client.

Good implementations of this approach also don't persist the password in plain-text in the temporary store. You crypt the password using whatever method you were going to when you stored it in the database and keep that around until you're ready to make the changes permanent.

If filling the password in will result in plain text passwords being sent back, you have already lost, because you just submitted a plain text password over HTTP. Similarly, if you're on SSL, it's plain text in neither direction. In either case, sending it back in the form has not changed the security situation.

I'm assuming this is levelled at HN? It's probably the only forum I use regularly where I get timeout's on submission. And the timeout page isn't even friendly either.

at least the back button works

HN (and trac) handle the situation best: they don't invalidate the page data, so your post will still be there. You CTRL/CMD A+C then get back to your posting with a refreshed cookie/session.

Many other forums basically wipe out your post, which is highly frustrating.

I Ctrl+R and FF refills the form data.

You might be interested in Lazarus:


It's a multi-browser plugin that allows you to recover lost form content.

Disclosure: I know the people behind the company.

i have taken to select-all-copy before submitting anything anywhere for just this reason!

I thought everyone started doing this back in 1997.

Opera did a good job of remembering what I typed in the box quite well, right up until people started adding boxes to the DOM willy-nilly!

There's actually an extension Persistent Text that does this https://addons.opera.com/addons/extensions/details/persisten...

I experience this from time to time. Sometimes(TM), a single undo in the now-empty field makes all the text reappear. I've recovered many an overly long forum post this way. Try it.

As much as these suck, I can tell you from working on corporate sites that this is often done for security compliance. One site we're working on now has about four different conditions that can expire a session earlier than the user might expect; I can only imagine how irritating this must be for them, and how many sales the company will lose because of it.

Expiring the session might be a neccesary evil. But please, at least try to remember the form contents when the user re-logs in.

I think one of the reasons I stopped using Tumblr for general blogging was because it didn't autosave while I was writing my long posts. I think there are a lot of holes in the walls of houses around the world because of this.

That's actually one of the things Tumblr does right. If you close out of a post before you publish it, you'll get a notice on your dashboard to either continue editing it or discard it.

Is this a new feature? I don't recall having that a while back.

Another favorite of mine is the forums that have a 'quick reply' box on a thread with a giant "Post Reply" button just above it and a smaller "post quick reply" button at the bottom right.

Guess which button throws away all of your work.


Never lose content was one of the guidelines (alongside write a CMS, no forms allowed) we used when designing Midgard Create.

Not easy in every case, but generally HTML5 localStorage helps in here:


One of my biggest pet peeves are forms that make you enter your address information, including your "ZIP Code", before asking for your country. Extra annoyance points go to sites that then do a clunky page refresh after selecting a different country and having all of your previous address information disappear into the void.

there's simply no reason why they can't either a) parse the zip code differently based on country, or b) why country isn't listed first if there are uncrossable chasms. To do neither is simply laziness

HN has this same problem though I suspect for different reasons.

Even better, get rid of your forms entirely, especially long forms with all kind of questions that you really don't need the answer to. Or have fields that are ambigious and improperly validated. Or multipage forms that have no way of going back without losing your filled in data.

Specially annoying is when the "check this if you don't want to receive spam from us" checkbox is unchecked every time the form is shown again after a server-side validation error.

Oh yes, I agree. Or when you mistype the essentially human-unreadable captcha, and have to fill in half of the fields anew.

Here's a quick User Script to get rid of them all:


It should work as an extension in Chrome or with Firefox if you have Greasemonkey installed.

I have a form that can be populated with records from a grid. "reset" allows the user to clear the selected record and input new data.

Wouldn't that better be served by a "new" button?

From user acceptance testing we done, that gives the impression it would create a new record from the populated data.

Edit: we use the wording "Clear" not "Reset" btw.

sounds like a "Please throw away everything I just typed" button to me ...

Your replies have prompted me to rethink the logic. I'm going to add some rules to the "Clear" button:

1, Hide the button whilst no records have been clicked. 2, If a record has been clicked, clicking the button clears the form then hides itself.

Feedback appreciated.

It may be better to not hide the button, but to disable it.

Hiding buttons in response to application state confuses the user.

(Imagine the user searching the screen for the "Clear" button which he or she knows should be there ...)

an [x] button to get rid of the edit form - for don't save, or don't create (ideally with undo, but "are you sure" is good too)? maybe?

I used to think exactly the way the author did. I'd actually get agitated when I had to explain to the IA/Design departments again why this was such a bad idea. I won about half the time, usually with my argument driven solely by my ego. Being vehemently against any use of it under any condition I refused to accept that there was any appropriate use for it.

Then, I actually did some research.

First, there are instances where reset buttons have a place. From Jakob Nielsen's post Reset and Cancel Buttons (http://www.useit.com/alertbox/20000416.html): Reset can be useful for forms that satisfy both of the following criteria:

- the form is filled-in repeatedly by the same user

- the data to be entered differs significantly from one use of the form to the next

For cancel buttons, my "never ever" opinion was flawed because I refused to see the reset or cancel button from the viewpoint of users unlike myself. I spend a lot of time building these things (as most of you do). I know how forms work. After actually sitting down with users that don't, and people that don't spend that much time online, I found another thing to be true: People are afraid that form data will be submitted even if you hit the back button. They want the Cancel button to ensure their data won't be collected against their will.

A point the article makes but then ignores is the button's layout & design. Layout for these buttons is key. If they have to be used, they shouldn't inputs or buttons. I've found that the best design for these is a plain text Reset or Cancel link that's opposite the Submit or Next button. An alert is also key. Using one can instill confidence, assuring the user that their information will be cleared and not submitted.

However, there are a number of reasons these buttons could fade out of use, not limited to the following:

- Users are becoming more familiar with the way the web works. They understand that form data isn't submitted until a submit button is clicked. Because of this, forms are generally a trusted interactive element.

- With the widespread use of AJAX, it's only a matter of time before form data is collected in the user session before a submit button is clicked. It's already being used in some places to track successful conversions & Lead Dropouts (Sitecore OMS is one). If this becomes common, forms will revert to being less trusted. Reset and Cancel buttons won't fix this, though.

The rule I follow is much the same as it's always been: Don't use Cancel or Reset buttons. Though now, I understand the exceptions and plan accordingly. Think about the target audience for each specific form and include the appropriate functionality.

sadly people call you a pendant if you end every sentence with "to the best of my knowledge" and an egotist if you don't ...

I'd still say that the lack of undo and the lack of confirmation in that particular widget makes it a bad idea... although a "get me out of here" link may very well be in order...

the people-who-know-less-about-the-web-than-me seem to crop up a lot ... oh yeah, they're the ones paying me... so generally they get what they ask for even if it does mean i have to come back in a week and remove the "please lose my changes" button...

That's the problem with absolutes. Any time you pre-decide that something is always good/bad, you're going to have to eat your words at some point.

Which is why, couching phrases in neutral terminology is always best:

unproductive) Microsoft on the server sucks!

productive) Microsoft software is expensive and nobody here is an MS-expert, migrating will cost considerable time and money without any real benefit.

Why not add the following rule to your user stylesheet? input[type=reset] {display: none; visibility:hidden;}

That hides them all from view.

Unless someone has "cleverly" created a Javascript-powered reset button. :) But still, good suggestion.

Good example of implementing a feature because it's easy to do, rather than because it has real utility. Why it's part of the HTML form spec I don't know. Was it ever useful?

The actual button isn’t particularly useful but the DOM interface is. Firefox (and other browsers?) cache DOM entries in certain situations. This is useful if you refresh the page accidentally with a half completed comment in a text box, but less useful if you’re building a complicated webapp that assumes an initial state. A simple document.forms[0].reset() at the top of your code works wonders.

Oh wow, I never thought to use this this way.

This seems to ignore the case where a form is pre-filled with previously inputed info or some defaults. It feels more natural to clear the form and write all fields with new infos than to overwrite everying field by field.

now it's a long time I haven't seen a useful reset button.

I'd use form placeholders, not values for that.


i'm pretty sure your browser's edit boxes support some kind of undo command... one that will only reset the contents of that field, rather than the whole form ...

I don't think I've seen a reset button in a while. Does anyone still use them?

I only experience them on government and bank websites.

I can see how some naïve users might want the extra-confirmation that they are cancelling this action – but I there's not reason for them to be visually similar and positioned almost next to each other.

a commonly used ticketing system has them, as does a particular bank i know of ...

you'd be surprised to hear that i had a need to use both of them in the same day and they both got me with it...

Anyone giving "wizards" as an example of good UI design instantly loses all credibility with me.

There's only one thing worse than having a Reset button: putting it next to the Save button


The most sad thing there is that "Start Over" is, by Fitt's Law, a "larger" button in the sense that it's occupying an edge.

It's like a poorly designed roadway section that just happens to cause more accidents. Bad Engineering.

A good point, one that needs paying attention to.

> There are lots of guides on website usability, go and find one for yourself.

... some of which should tell you that having an automatically scrolling display right next to something you (supposedly) want people to read, is a bad idea.

though quite useful for 'advanced search' forms

Reset buttons can be useful in CRUD applications when you want to "clear all changes" in an existing record - everything gets reverted to the field values in the HTML.

Admittedly, I don't use them much, usually going with a "Cancel/Close" link that takes the user out of the record-editing view.

Isn't this more of a "revert changes"?

They still exist and I've pressed them just before thumping the desk.

Is there a greasemonkey script to get the browser to ignore them; are there extensions for any browser to do this without greasemonkey?

or with a user stylesheet?

input[.reset]{display:none;} what is the right css? I haven't used it in a while?

The following should work in browsers with decent CSS2 support [1]:

    input[type=reset] { display: none; }
You might need a !important in there immediately before the semicolon if your user stylesheets aren't getting priority otherwise.

[1] http://www.w3.org/TR/CSS2/selector.html#attribute-selectors

input[type="reset"] { display: none }

Should do it on most browsers.

In Messaging on the Facebook app on Android, you have Send on the left and Clear on the right. Gets me far too often, and it's just not even necessary. If I don't want to send what I started writing, I simply hit back. Hate it.

What in the interface tells you that navigating away from the page will not submit the data?

Perhaps instead of reset a "do not submit" button is required. But then if I changed my mind about what I'm writing but still want to send a message things get a little lame.

How can you tell for example that going back doesn't instead save the comment as a draft (like the SMS interface on my [pretty old] Sony Ericcson phone).

I disagree with the article, I think there is a place for a reset/clear function.

The expected behaviour is that navigating away will not submit the data. That's pretty much consistent across all interfaces I know, with the exception of saving as draft, which still does not "submit" the data to the human recipient on the other end.

However, I do agree that clearing the message can have its uses, but as it's a secondary action, it deserves a far less prominent position for the button (e.g. maybe as an option on the long-touch menu, but at least not where you'd expect the Send button to be). On this app, it's in the primary action space and doesn't ask confirmation before wiping your message.

browsers don't save things by default. that's how they are.

the thing in the interface that tells you that you're looking at a browser is up to you... in my mind, the address at the top, starting with http:// is the part of the UI that says my changes will be thrown away...

this is kinda why i'm miffed that there is an explicit "throw my changes away" button, when that's the default behaviour

>"browsers don't save things by default."

// Depends on your browser.

when "submit form" and "save" are the same action, it doesn't depend on browser...

keeping it in cache/locally/whatever is not "saving".

Am I the only one who would love to somehow switch the "submit" and "reset" buttons on this guy on some random website just to see what sort of anger you could incite? Imagine that blog post...

Dear Cats on the internet, please spellcheck your posts and proofread them before you post your rants to the internet. Otherwise some people might think they are unpleasant to read and possibly wont take them serious.

If you have a "related reading" section you might want to also use it to post some links to those guides. We are here to help each other, aren't we?

And: No, I don't use reset buttons.

unpleasant to read and possibly wont take them serious

Don't you mean, "won't" and "seriously"?

Glass houses, stones, etc., etc.

I appreciate useful feedback

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact