12

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.

9
  • 7
    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, 2012 at 19:56
  • 1
    @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, 2012 at 1:16
  • @Bevan, can you give details on what might be involved with a proper implementation? Mar 16, 2012 at 2:13
  • 1
    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, 2012 at 2:17
  • 1
    @Bevan: D'oh, sorry, must have been asleep. Mar 17, 2012 at 8:45

6 Answers 6

6

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.

5

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.

1
  • 1
    Making it a user preference is actually a really good idea I hadn't thought of. Thanks! Mar 16, 2012 at 2:10
1

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.

1

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.

1

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.

Example: ------- 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 with 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.

Edit 2017: We later removed our auto-tabbing feature. It was more confusing for our users, and did not provide a big enough advantage compared to not auto-tabbing.

0

One way to help deal with the awkwardness of auto-tabbing, e.g. I typed the whole phone number and then immediately hit tab, only to find that the input already auto tabbed and now I am two fields down instead of one, is to build something to grab the intention of the tab. That is, if the system just auto-tabbed and the user hit the tab button with x time (say 500ms) ignore the users tab as it was most likely not meant to tab one more field farther.

This can help reduce error when auto-tabbing effects a subset of fields that have defined formats that indicate they are complete. However you need to prototype and test the interactions to dial them in and not accidentally include cases where the tab was intentional, e.g. I haven't filled in the field fully or at all and I hit tab. In this case the user is intending to move on manually for whatever reason and you shouldn't cancel the action.

But even with this you still cant get around the issues of you autotabbed because they hit the max number of characters, but the user was not aware of that fact and keeps typing (cause they are looking at their keyboard not the screen) only to realize later that they have the input spread across more than one field.

It would be interesting in the end to test the form with the users in both autotab and regular mode and see how much time not having to hit the tab button saves them and which method is less error prone. My money is on that the auto tab feature increases error rates and does not in fact have a significant savings in time.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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