Form usability problem on myCIGNA Request ID Card page
Ugh! I just wanted to request some replacement health insurance ID cards for my family, this morning, but the web form for that has issues. :(
First of all, they’ve got that annoying “feature” where it automatically tabs to the next field when you finish entering characters in the current field. This is something I’ve seen many times, over the years, particularly for phone number entry. In this form, it’s on all the Date of Birth fields.
For example, to enter the fictitious date ‘12/12/1234′, I only have to type ‘12121234′. After I enter the ‘12′ in the month field, it automatically advances to the day field. After I enter ‘12′ in the day field, it takes me to the year field, and after I enter ‘1234′ in the year field, it takes me to the next form input.
This behavior is mildly amusing, as long as I don’t make a mistake. If I need to go back and fix something, though, I have to fight with it because while I’m trying to backspace or use my left/right arrow keys to move the cursor to the digit I need to fix, the automatic tab “feature” is trying to advance me to the next form field.
Here’s a video showing me trying to correct a mistake in the year field:
Even though I know that the automatic tab “feature” is active, I still find myself trying to use arrow keys to get to the right position in the form field. I also usually press shift-tab to go up to the previous form field, but on this form, the automatic tab advances me out of the field as soon as I get back to it. How annoying!Now, in case you didn’t notice, there’s another problem with those Date of Birth form fields. Here’s a screenshot of the Employee Information section of the Request ID Card form:
In the screenshot, if you look at the Employee Date of Birth fields, you can see where I’ve entered that fictitious date I previously spoke of, ‘12/12/1234′. You’d never know it, from looking at the page, though. It looks like I only entered ‘1/1/123′. I figured it had to be either a font size problem, or a form input size problem. When I did a ‘View Source’ on the page, I saw that it’s the latter:
<td align="left"><font color="#ff0000">* </font>Employee Date of Birth:</td>
<td><input name="EDOB_MM" size=”1″ tabindex=”14″ onKeyUp=”AutomaticTab(this.value,eval(’document.idcard.EDOB_DD’),2)” maxlength=”2″ onFocus=”window.status=’Please enter the month of birth.’;select(this)”> /
<input name=”EDOB_DD” size=”1″ tabindex=”15″ onKeyUp=”AutomaticTab(this.value,eval(’document.idcard.EDOB_YYYY’),2)” maxlength=”2″ onFocus=”window.status=’Please enter the date of birth.’;select(this)”> /
<input name=”EDOB_YYYY” size=”3″ tabindex=”16″ onKeyUp=”AutomaticTab(this.value,eval(’document.idcard.Member_first_name1′),4)” maxlength=”4″ onFocus=”window.status=’Please enter the year of birth.’;select(this)”><input type=”hidden” name=”EDOB” id=”EDOB” value=”"> mm / dd / yyyy</td>
The maxlength attributes are correct, but size attributes, which control how big the viewable text input is on the page, are all too small. Why the hell would someone make a form that hides one character from each date field?
You can also see the javascript calls to the annoying AutomaticTab “feature” in that code, above. Here’s the source for their AutomaticTab function:
function AutomaticTab(CurrentLocation,
Destination,CurrentFieldLength)
{
var fieldlength;
fieldlength = CurrentLocation.length;
if( fieldlength == CurrentFieldLength)
Destination.focus();
}
Evil. Pure evil. Seriously, I can hit tab my damn self! I don’t need this dumb javascript to help me get from one field to another, especially when I need to use the cursor keys to move left/right within the fields, because not all the digits can be seen on these fields, thanks to the size/maxlength mismatch.
I’d like to think they only screwed up this one set of form fields on this page. Unfortunately, when I tried request cards for 4 family members, I ran into it again:
Yes, 4 more sets of date fields with annoying AutomaticTab calls and size/maxlength mismatches. *sigh*
These things were annoying, but did not stop me from completing the form. However, when I tried to submit it, I got this:
It focused and selected the Employee Date of Birth : Year field, but that looked fine (as far as I could tell, since only 3 digits were visible):
Since I knew the AutomaticTab function would get in the way if I tried to use the cursor keys within the year field, to verify all 4 digits, I disabled it by entering this in my address bar:
javascript:void(AutomaticTab=function(){})
Then, I was able to determine that the year field was fine. It contained ‘1234′, which is what I intended (for the purpose of this blog entry. I entered my real DOB info originally).
So, I looked at the page’s source code again, and found the place where that error message came from. It was in a function called “check_date”. Since I knew my date was valid, I disabled the date validation by putting this in my location bar:
javascript:void(check_date=function(){return true;})
This allowed me to submit the form. This is also a good example of why it’s important to not rely solely on client-side validation (javascript) when writing web applications. Javascript validation code can be viewed, modified, and even disabled. I could have submitted any year value I wanted, since I disabled their javascript date validation function. Hopefully, they have server-side validation as well, but I did not care to find out. I’m not interested in breaking my health insurance provider’s website (they’re pretty good at that, themselves!).
subscribe to entries feed
January 24th, 2008 at 4:18 pm
Dude.
1) Highlight character you want to replace with mouse so that it is highlighted (I italicize this because in the video, it looks like you are moving the cursor, but not highlighting anything.
2) Type character.
As much as keyboards are vastly superior to a mouse as an input device, it is silly to ignore when a mouse is the quickest way to do something.
Need to move a block of text to another section? highlight it, and drag it there. If you have a precise mouse hand, and your hand is already on the mouse, this is way faster than control-arrowing to the start of your selection, shift-moving to the end, ^C, move around again, ^V. There no way you’d be able to beat someone who could drag from start to top and then drag over — Serge probably could have done it in a half second. Which brings to mind another example: FPS games.
Sometimes the mouse is just faster.
This was one of those times.
That feature is a good thing because it saves keystrokes for people who use it correctly.
Actually, it saves picking up the mouse for people who don’t know about the TAB key — since you seem to not like to pick up the mouse, you should like this feature, because every one of those people now has to pick up their mouse 2 less times.
It only compounds mistakes for people who mess up typing their dates and refuse to pick up their mouse :) I venture to say that is a smaller demographic than Mac users who use Firefox and are furries.
I agree with everything else, though. Fields 1 too small SUCK, it’s not like the extra character is costing anybody anything. And changing form elements and re-submitting things in ways they aren’t supposed to be is definitely fun :)
January 24th, 2008 at 4:28 pm
))))))))))
January 25th, 2008 at 2:36 pm
Yeah, I realize I could have used the mouse to highlight the parts that I wanted to correct. If the field has been a larger text input, or a textarea, then I would certainly consider using the mouse to highlight or at least to position the cursor where I wanted it.
But, for a 2-4 character text input, I should not have to move the mouse and try and highlight a single character in a tiny little field, just to correct one mistake.
In this case, without the AutomaticTab thing, I could have just hit shift-tab [return to year field], left-arrow [position cursor after a wrong digit], backspace [delete wrong digit], 3 [correct digit], tab [go to next form field again].
Those 5 keypresses/combos would normally take me a fraction of a second. Instead, I started doing those steps, was foiled by the stupid AutomaticTab function, and THEN had to resort to either mouse selection (select one character from an improperly sized tiny form input) or javascript function disabling (more time-consuming, but also much more fun/fulfilling).
Anyways, I agree with you about block selection/moving text with the mouse being faster, but I only agree when it’s a large amount of text, or if the position of the text is such that selection via keyboard would take way too many keystrokes. For most form inputs, I can get through things faster (including correcting mistakes) using just the keyboard.
January 25th, 2008 at 5:43 pm
Hehe, I kinda figured you knew that, and I feel your pain, having been in similar situations. You should get them to pay you to fix their site, hehe :)