I can't believe that 16 years after forms first appeard on the web we're still having this discussion.
Using "submit" as your label? So are thousands of other sites. Your users won't be confused.
Using something more descriptive? That's fine too. Maybe it looks a little nicer and less generic. But it's not a usability problem.
Don't worry about this for a second. Instead focus on the real problems, like creating usable and accessible form fields with associated labels. Write easy to follow directions that explain which fields are required and what format you're expecting (or write better error handling techniques to accept a variety of inputs.) Write and make visible appropriate error messages to help your users through the process so they don't make mistakes. Record the mistakes they make so you can use that data to engineer your forms in ways that reduce user errors.
There are so many other things worth your attention.
I totally agree. Using buttons with concise messages is best when they're used to access some functionality, but when submitting data the users have been clicking on submit buttons for more than a decade to do so. I'd even go on and say that in a lot of cases when you're submitting data, it's correct to use either simple actions as 'save', 'send', and 'submit' instead of 'Do the chicken dance when you click on this button'
Instead of worrying about submit buttons, which by the way generally exist a lone entities at the end of a form (which makes it's use even more obvious), worry about the actual usability of your forms and the logic behind the error handling.
tl;dr => In more cases than not it's more correct to use 'submit' as button copy than a more verbose counterpart when submitting forms.
I don't understand why this got down voted. You can't assume that users will have experience with the internet.
I work with a lot of people have little experience with technology and the internet and whose second language is English and they don't understand when they see "submit."
I disagree, and to speak so broadly as to say it's not a usability problem regardless of context or audience is irresponsible at best.
You designed an interaction that requires the user to press a button. Take an additional 30 seconds to describe on its label what the effect of pressing that button is.
The trouble with putting the current task on the submit button is that the user is already doing that task and they might think that the button is a link to start the task over, particularly if they clicked on identical text to get to the form in the first place. I have personally made this mistake while using some sites.
I try to include some context in the submit button but still make it clear that it will submit the form. Short, generic verbs seem to work well, like "Save", "Delete", or "Send".
EDIT: thinking more about this, I think what's important is to use a verb that applies specifically to the form data as opposed to the whole task: You send a reply, you don't reply a reply.
There's possible value is calling out the genericness of getting to the empty form vs the specificness of the submitting the data on a single instance of the form. "Create user" takes you to a form that has potential to be any user (because it's empty), "Create this user" finalizes the action based on the filled-in data on the form.
If you click on a link or button called 'Create a User' that that takes yo to a form, it would be almost universally more usable to have the button at the end say 'Save' instead of 'Create this user'. Verbosity is not always a good thing on the web.
I'm probably in the minority but when I see "save", I assume it's "saving my progress". In a user creation form, even just "create" is clearer than "save".
But then we're back in "is it telling me to create the user again when I already clicked the other button on creating a user on the other page?" territory. I think we should use whatever feels right and A/B test the hell out of it, but spend more time actually solving more substantial problems that the copy on a submit button.
> The trouble with putting the current task on the submit button is that the user is already doing that task and they might think that the button is a link to start the task over
Yup. Another risk is using an ambiguous phrasing, such as on this very web site: in order to post your comment, you have to click on a button that says "Leave comment".
Does this mean the button will post my comment or abandon it because I want to leave?
Everybody already knows what I'm going to say but by golly it is the right answer: test which one performs better for your site. 2 + 2 = 4, in the time it takes two highly paid people to debate "Submit!" versus "Sign up" you can have the A/B test already running and be back doing productive stuff.
A/B tests are only useful when you can gather statistically significant amounts of data from them. For a lot of small websites, or infrequently used features on larger websites, that is not the case.
Without statistically significant data, there is no hope for a statistically significant margin gain in the arena of form submissions. That is, why not just switch up the language? It's a trivial commit and will be an obvious change in conversions or no change. It would have taken less time to test than this comment to be written; just do it -- the parent comment's point.
haha, this sounds like a piece of advice straight out of Starcraft 2. If you're anywhere but in the top 10% of ladder or above, you'll win more games and get better faster by just focusing on building more stuff than your opponent.
Unit composition, racial balance, specific attack/scouting timings, etc. profoundly don't matter if you can't scrape together a hundred food army and an expansion 10-15 mins into a game. If you can, you can start strategerizing.
I think the analogy of "submitting a form" is perfectly reasonable to average folks. It's akin to giving a form to the receptionist at the doctor's office through the window:
1. You get form, and go fill it out
2. You bring back the form and hand it to the receptionist
3. You get a range of responses ranging from nothing to a helpful answer.
Sounds exactly like an HTML form to me.
Is this the sort of parallel you want your users thinking of? Probably not, but it's also not some arcane terminology only programmers use either.
Precisely. Everywhere you go in the real world, someone sends you a form to fill out and they tell you where to "submit" it. This is why Internet forms started off saying "submit" - because it makes sense.
It's still vague and doesn't tell the user what is DONE when you submit. "Save Changes" for settings, "Sign Up Now" for users joining a website, "Log In" to log into a website, "Reply" for replying to a comment ;-) Etc.
ew, no. For me at least "sign up now" implies starting the sign up process. I would think "complete registration" or "create account" or "finish and create account" would be much better than "sign up now" especially if you've previously used "sign up" wording.
Hitting the "Submit" button happens within a context.
The person just filled out a form. That form showed up in their web browser because they navigated to the page the form was on. Much of the time that navigation was the result of clicking on a descriptive link, like "Create an Account". The person filling out the form knows that they are completing a task that they started by filling out the form. Submit, as others have said here, is a perfectly logical name for the button (just like submitting a paper form to a real person).
You could try to make it more descriptive, but you run the risk of confusing the user with things like "Create Account". I agree with others here, that in some contexts, and for some users, rather than clarifying what is happening, you will confuse them into thinking the "Create Account" button starts the process over again at a blank form (rather than submitting the form they just filled out).
Also, it isn't like this is new technology. Anyone who has any significant amount of experience using the web in the last ten years (or more even) has filled out an HTML form, and a high percentage of those forms have submission buttons that read "Submit". Even non-technical users understand it. I can't think of a single case where a person has talked to me because they have been confused by a "Submit" button. And of the few people I can think of that might have trouble with an HTML form, renaming the submit button would do absolutely no good (because they are the type of people who are so afraid that they'll do something wrong on the computer and delete all the information in the known universe :-D )
(laughing to myself as I click the "reply" button -- I missed that part of your comment until after I noticed the button)
It may not be vague for a user who knows the current context, but I still think that using a descriptive verb is better than the generic 'submit'. For "Create Account" even "Create" would give some idea as to what will happen when the user presses the button.
I remember being impressed by the Mac HIG that said all dialogs should have buttons with a verb instead of the typical Windows "Ok"/"Cancel". It informs the user slightly more and, I think, reduces the likelihood of automatically clicking "Ok" as some interfaces effectively 'train' a user to do.
I really don't think that a pop-up window and a form have much in common from a UX perspective.
The fact is that pop-ups interrupt you with a nag, and the user's desire is to get rid of it as soon as possible (regardless of which action they actually want to take). Putting the text on the button itself speeds this process up, and reduces errors.
Submitting a form is a MUCH MUCH slower, and more thoughtful process. You can make a snark about replying quickly to a comment, but have you ever WATCHED a user deal with a message popup they've seen before? Blink and you'll miss the whole thing.
Even more importantly, most forms have only ONE button. I bet you could label it simply "Button" and a ton of your users would never even notice.
I would argue that the "do something" button should focus more on where you are in the process than the process itself. The examples in the page all sound like the "start" step, instead they should reflect that they're finishing or moving the user on to the next step. "Submit" is generic, but at least sounds final.
The reality, though, is that we're all guessing. Unless you go to the effort to A/B test something like that, it's just voodoo.
I received user feedback from a woman who said our submit button was "vile" and "sexist" because the label on it said "Submit". It took me a second to process. I can't imagine the emotions bubbling up inside her every day that she browses the web.
But regardless, we'll be changing the "Submit" button to "Sign In".
Might there be enough people feeling the way she does to warrant browsers providing an option (like setting minimum font size) of specifying what 'type="submit"' fields should display?
Perhaps the woman in question might prefer that they all displayed, "Dominate". [Sorry: it just seems worth the down-votes.]
Also "daemon." I can't remember which, but one of the "Linux distros for Christians" tried to remove references to daemons in the user interface and documentation.
Let her know that you value her feedback submission very highly and apologize for manhandling the situation. Your tech guys will be making a change shortly.
But. Submit has different meanings. I really don't know how she ever connected a submit form button to submit in the sense of a man dominating a woman. People are strange.
I can't remember which dialog it is in Windows, but the most hideous example uses the standard Yes/No/Cancel buttons out of context but explains beforehand what each one does, like this:
-To continue closing the program and save the document, click "Yes"
-To continue working without saving, click "Cancel"
-To save and then continue working click "No"
Which takes you five minutes to read and could have easily been replaced by set of a "Save and Close," "Save and Continue" and "Cancel" buttons.
For poor visual basic coders, it's easier to use standard dialogs than make custom ones. In the old days the Yes/No/Cancel text would be hardcoded into a specific dialog object.
I had a window manager on an old Linux box (I forget which one) that would replace the "OK" text on dialog boxes with random interjections: "Oh, well" or "Damn!" or "Huh..." :-)
It's sometimes worthwhile to use boring, "wrong" default form elements, like when the browser will automatically translate their text labels into the user's preferred (i.e., non-English) language.
People who use the web are used to have some sort of confirmation that their data has been safely squirrelled away somewhere. When I use sites that behave like this, I often find myself going back to the settings page to make sure my new settings have actually been changed, even though I understand the technology behind it.
I expect to see this change to match desktop expectations eventually, but I agree. Connectivity, and web apps themselves, can be unreliable, so it feels safer to see a new page load to confirm that our settings have been saved.
Additionally, many Windows apps still use OK, Cancel, Apply buttons in settings dialogs. The instant saving of settings is more of a Mac thing. Users are going to expect similar things from UI on the web, and the majority are probably new to the idea of no save/cancel choice.
Using "submit" as your label? So are thousands of other sites. Your users won't be confused.
Using something more descriptive? That's fine too. Maybe it looks a little nicer and less generic. But it's not a usability problem.
Don't worry about this for a second. Instead focus on the real problems, like creating usable and accessible form fields with associated labels. Write easy to follow directions that explain which fields are required and what format you're expecting (or write better error handling techniques to accept a variety of inputs.) Write and make visible appropriate error messages to help your users through the process so they don't make mistakes. Record the mistakes they make so you can use that data to engineer your forms in ways that reduce user errors.
There are so many other things worth your attention.