June 30th, 2008

usability: Verification of Challenge Question and Challenge Answer

A website I use regularly requires me to verify my contact information annually. Today, I noticed that the last question on the verification page is for my “Challenge Question” — the question/answer combo that I would need to use if ever lost my password.

Here’s a small screenshot showing this question (click it to see a larger screenshot with more context):
What was the name of your first pet? xxxxxxxxxxxxxxxxxx

As you can see, it shows the question that I chose to use, but for the answer it shows “xxxxxxxxxxxxxxxxxx”, and says “Your challenge answer has been hidden for security reasons.” Then, it asks me to check a box saying “Yes, the information above is correct.” How can I confirm that my challenge answer is correct, if I can’t see it? The number of x’s does not even correspond to the number of characters in my first pet’s name.

While I appreciate that they do not display this relatively-sensitive information (since it’s almost like a password), I feel like it’s silly to ask me to verify something that I can’t see. I refused to accept that the answer was correct, and went ahead and selected/entered a new Challenge Question/Challenge Answer combination.

January 24th, 2008

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:
myCIGNA Request ID Card form - Employee Information section

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:
myCIGNA Request ID Card form - family members to request cards for

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:
Please be sure the YEAR of birth is a 4 digit valid century year.

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):
myCIGNA Request ID Card form - Employee Date of Birth with alleged invalid year

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!).

March 1st, 2006

html form tag without the top/bottom padding

This seems like such a simple thing, but I’m really happy to be able to add it to my collection of useful code snippets:

The important part (HTML code snippet):
<form style=”display: inline; margin: 0px;”>

Explanation/history/context:
For years, now, I’ve just accepted (but been annoyed by) the fact that the HTML FORM tag causes some whitespace to display above and below the form contents:

html screenshot
Form outside table:Text above table
<form>
<table border=”1″>
<tr>
<td>table cell</td>
</tr>
</table>
</form>
Text below table


One common way of avoiding that whitespace padding is to stick the FORM tag inside a TABLE tag, floating freely without being inside any particular row/cell, like this:

html screenshot
Form inside table:Text above table
<table border=”1″>
<form>
<tr>
<td>table cell</td>
</tr>
</form>
</table>
Text below table


I’ve never bothered to find a better way, until recently, when I decided that I didn’t like HTML validators complaining about that. So I searched and found a method of avoiding that whitespace that’s simple, seems to work fine in multiple browsers, and passes HTML validation:

html
Form outside table with style:Text above table
<form style=”display: inline; margin: 0px;”>
<table border=”1″>
<tr>
<td>table cell</td>
</tr>
</table>
</form>
Text below table

screenshot