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.
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.
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 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.
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.
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.
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
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.
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...
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.
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'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 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.
> 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.
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.
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
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?
Some sites you can go back to retrieve your post, others will just present you with a newly empty form.