Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

On a web form, what should happen when the user presses the ENTER key?

I'm writing a sign-up form - name, email, password, sign-up button: the usual sort of thing. Since I'm using JavaScript, and the page does not use the <form...> tag, I have complete control over what happens with each key press. I can make it change the focus, submit the data to the server, validate the field contents, whatever. But what should it do?

Things I'm wondering: should ENTER take the user to the next field (as per TAB key)? Should pressing ENTER while focus is on the final field submit the form?

share|improve this question

6 Answers 6

up vote 35 down vote accepted

Enter should submit the form. Tab should goto the next field.

Users don't usually appreciate it when the keyboard doesn't do what they think it should.

share|improve this answer
3  
I wonder if that's what users really expect. I quick Google search found me many cases of people trying to disable the default submit-on-enter behaviour. I concur with your zeal for not surprising the user, though; I'm thinking about it. Thanks for your answer. –  David Aug 26 '10 at 1:03
    
I see people disabling the enter button for numerous reasons. Regardless, since the beginning of the form field, enter inside an input element submits that field. For a public facing interface, doing this would be a bad move IMO. However, if you're in a private environment, and say moving people off of Green Screens to a web interface. It might be a good idea to do something their comfortable with. But I'd say 95% of the time. Make the page do what the user expects, and they'll have a better experience. –  Jeff Sheldon Aug 26 '10 at 1:06
1  
I agree here, keep the browser default behaviors as they are. Overriding them will just end up with frustrated users. –  RussellUresti Aug 26 '10 at 2:15
1  
@David - I sympathize; I often accidentally hit enter while filling out a long form. If you have the resources, run a test (then report back here!). –  OverMachoGrande Aug 26 '10 at 3:19
    
Somewhat reluctantly, I'm going with this answer for now. I've taken on board what others have said about user testing, and will attempt to get some feedback ASAP from the eventual users. –  David Aug 26 '10 at 21:59

The built-in browser default is always to submit on enter, hence it has become a de facto standard.

One usually intercepts this and then do validations. If the validations fail, then the submission event is cancelled, and the form is not submitted.

Aside: why are you not using the <form> tag? You really should. It won't preclude any javascript from running and is semantically better.

share|improve this answer
    
Thanks Steve. I don't use a <form> tag because I'm using a GWT event-handling framework that interacts with the server in its own special way. I know that sounds convoluted; but it fits in with the overall application architecture. –  David Aug 26 '10 at 1:25
3  
Actually, I've repented, and now use a GWT FormPanel, which creates a <FORM> element. –  David Aug 26 '10 at 3:14

This question is impossible to answer without a user test. Why? Because what Enter should do depends on who your users are. Look at the answers to this question so far: the top voted one is an interaction designer giving his opinion based on his expertise (which biases him, considering that all he can say is what he's already seen), and then 11 other designers have upvoted that because they've seen similar things and agree with it.

But to truly answer the question, you must user test. If your audience doesn't consist of user interface designers who expect Enter to submit the form, it's hard to tell what they do expect without measuring what they expect. The best way to do that is to get a statistically significant number of people from your audience and see how they behave when using the different designs of the form.

share|improve this answer
    
No offense to Jeff Sheldon btw; I upvoted your answer and then removed the vote after thinking about it. I decided testing is the more responsible thing to do, even though I would be inclined to agree with your call. –  Rahul Aug 26 '10 at 12:04
    
It's hard to argue against the wisdom of knowing one's audience. Since I have yet to release my product, it doesn't have an audience yet. I'd like to know who they'll be, and I'd love to test their reactions without driving them nuts; but in the absence of that opportunity, I'm looking for useful heuristics about web application functionality, knowledge about what works and what doesn't in general. –  David Aug 26 '10 at 14:00
    
Cool! You should consider adding that information to your question. :-) Also, you could still user test it despite not having real users yet. Surely you have an idea of who will be using it? –  Rahul Aug 26 '10 at 14:09
    
+1 for user testing. Any user testing is a whole lot better than no user testing. Having said that, using enter to submit a form does assume knowledge on the part of the user. An explicit 'Send' or 'Submit' button should avoid 99% of accidental submissions, including those that would occur if you used enter to send only after verifying that all fields had been populated. Maybe I made a typo in filling out the form and had not checked it yet when I hit enter? (OK, you can accidentally click the Submit button too, but that's not nearly as easy.) –  mickeyf Aug 26 '10 at 14:24
    
No offense taken. I understand your stance. My point is simply, changing the default behavior of the browser is most likely going to go against what the user expects. Now in this case, it's not volatile, it would simply move to the next field. But then do you do the same on a login form? I'd think not, unless enter on the password submitted the form. But then are you doing different things on different forms? That's kind of annoying. :) –  Jeff Sheldon Aug 26 '10 at 18:55

Just an opinion from someone who didn't grow up with the web (There are a lot of us out there and we pay for stuff.). The Enter key should only post the form when all the required fields are populated; otherwise it should go to the next field.

In a more unique data entry form, I wouldn't recommend going outside what users expect, but login screens are pretty generic, have few fields, and shouldn't cause too much confusion (There are only 3 fields.).

Personally, I hate it when I hit the Enter key out of habit/accident and I wait for the form to load.

share|improve this answer
    
Interestingly, that's how I implemented the page originally; but I grew anxious that maybe I was trying to emulate a desktop application too closely. Certainly, we want to design stuff that meets the user's expectations; and what those expectations are isn't universally understood, it seems. –  David Aug 26 '10 at 13:53
    
I struggle with the new user perspective and learned Ctrl+V isn't universal. –  JeffO Aug 26 '10 at 18:50

My advice - you don't need Enter.

Users are unaware that Enter submits the form. This functionality can be discovered only by experimentation. Users don't experiement, they're scared of doing something wrong, especially in forms.

You can safely remove the Enter functionality from long forms.

Keep it there in very short forms like Login, where advanced users are used to hitting Enter.

share|improve this answer
    
That idea is the most appealing from a programming point of view, since it would involve the least coding for me. Not sure that I like the idea of different forms behaving differently on the same site, though. –  David Aug 26 '10 at 13:55

My heuristic is

  1. If the form is username and password, enter submits the form.
  2. If they are on the very last field of a form or tabbed onto the submit button, enter submits the form
  3. All other scenarios enter goes to the next field.
share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.