User Experience Stack Exchange is a question and answer site for user experience researchers and experts. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I work in an environment that makes heavy use of mainframe systems. These systems are costly to maintain, so a decision was made years ago to replace the mainframe with web based systems.

As more people move off the mainframe to the web, a common request is that we implement autotabbing (i.e. automatically move the cursor to the next field once the current field has been filled in). I am generally opposed to autotabbing, but have no data to support my position.

Are there any quantifiable arguments for or against autotabbing? Specific research in this area would be much appreciated.

share|improve this question
My case? Enter something into a field, get auto-tabbed. Realize I screwed it up. Click back into field to try and edit, get auto-tabbed. Grr. Click back into field, get auto-tabbed. Argh! Click back into field, get auto-tabbed. RAGE!!!! – Karen Mar 15 '12 at 19:56
@Karen - a great example of a naive implementation of autotab ("move to the next field if full"). A proper implementation is a lot more complex, but can be worthwhile. – Bevan Mar 16 '12 at 1:16
@Bevan, can you give details on what might be involved with a proper implementation? – superduperfly Mar 16 '12 at 2:13
I think the issue is generally that autotabbing is implemented poorly. The fault is not with autotabbing itself but with most implementations (e.g. if you implement autotabbing, you may wish to "swallow" the next tab press if it's entered directly following an auto-tab, and you need to support backspacing over multiple fields). – Kit Grose Mar 16 '12 at 2:17
@Bevan: D'oh, sorry, must have been asleep. – Marjan Venema Mar 17 '12 at 8:45
up vote 5 down vote accepted

I've had my fair share of mainframe -> web refactoring projects over the years, and auto-tabbing topic comes up once in awhile.

As long as you are consistent in how you apply auto-tabbing, it can be a really good time-saving feature for data-entry intensive tasks.

For example, set up tabbing rules, and follow them rigidly for ALL fields.

  1. Make sure all INPUT fields have fixed-width font like Courier/mono-space applied.
  2. Make sure all INPUT fields have appropriate 'size' and 'max-length' attributes applied.
  3. Auto-tab when user has exhausted all the space in input field.

The first two are important because it lets user accurately gauge when the system will auto-tab. If we didn't use fixed-width font, then "iiiii" and "WWWWW" would take up different amount of space in input field, and users wouldn't be able to tell how many characters they have left until auto-tab kicks in, since they do not have the benefit of the character count hyphen "_ _ _ _ _" of mainframe.

I sympathize with OP, because when you are working with small and defined set of users who become expert of their application, conventional usability guidelines that are geared towards consumer-centric apps can be a tough sell.

share|improve this answer

It's a matter of expectations. Normally on web forms, a person isn't expecting the cursor to automatically jump around the place and would want to be in control of tabbing back and forth as they desire.

Your application may be very niche or have a very specific user base, however, and maybe it makes sense in that situation.

One suggestion would be to consider making it a user preference that individuals could enable if the so desired.

share|improve this answer
Making it a user preference is actually a really good idea I hadn't thought of. Thanks! – superduperfly Mar 16 '12 at 2:10

Okay, so the first question is... why don't you like autotabbing? Answering that will give you your case against applying it.

Autotabbing is an unusual behaviour on the web, and it doesn't work well unless users will only ever submit data to a field of a particular length and format. Applying autotabbing to specific tabs only is going to mean unexpected and inconsistent behaviour unless there's always a clear rationale to the user, or if your users are already exposed to the concept through tools they already use in the domain. A user who incorrectly expects autotabbing is going to stumble, which erodes their confidence in their ability to grok the way your application works, and a user who doesn't expect it is going to be similarly surprised - and if other messages appear when the new field takes focus, I would expect users to assume that they'd accidentally triggered an event of some kind.

So that means that autotabbing is going to have to be applied throughout at least a particular class of forms, and that's going to apply a rather strict constraint. Constraints are kryptonite to software development because, as we all know, requirements change, and the reasonable constraint of yesterday becomes a point of crisis tomorrow.

That being said, if your biggest issue with autotabbing is that you can't update existing software, you have far bigger problems than UX. Applications should encapsulate their view logic well enough to stop this being a problem. Then again, it sounds like you've inherited some legacy software, so the horse may have already bolted on this one.

share|improve this answer

I think another thing to consider is what works for your users- if they're requesting it, do some quick tests to see if it really works well in your app or not. The same behavior might be awesome for some people and frustrating for others.

share|improve this answer

I had this discussion several times, and we use it on date fields only.

Our solution auto-tabs after all spaces are used in the field, but only if its validated.


Year, inserted 3000 (outside possible range), background turns red, and will not yump to next field.

Year, inserted 2010 (inside), background flashes green to show that it is saved, and jumps to next field.

Month, inserted 04, (...)saved and jumps to next field

Month, inserted 13, (outside possible range), background turns red, and will not yump to next field.

Possible issues:

Month, inserts 4, will not jump because does not fill the input (2 letters). We do have labels showing MM below the input, so users should understand the required input. Even though we accept a single 4 as a month, but the users has to tab themselves.

This is still a discussed feature whit us, and feedback from users are both pro/con. I think the only way to decide if this works or not for your specific case, is to follow Kit Grose and Jung Lee's answer and start a thorough usability test in your environment.

share|improve this answer

Your Answer


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.