Feeds:
Posts
Comments

Archive for the ‘Validation’ Category

Why is it so easy to find web forms that just don’t work well? Particularly when it comes to what should be simple workflows users are used completing over and over again. There really is no excuse. Here is another example of a simple form gone wrong…

I am submitting a request so the first thing I am being asked for is my contact information:

Contact Form

Scanning the form quickly I see date is already filled in and I am asked to leave it in the field. The rest of the fields are expected information to be asked, and I know this stuff like the back of my hand, so fine with me. Following the instructions, I skip over the date field; enter the rest of the required fields, then hit Submit:

Form with Error Popup

Okie dokie… Why the heck am I getting an error on the one field I was explicitly asked not to edit? Of course, I can no longer see that field since the pop is hiding it, so I am unable to immediately figure why. I decide to move the pop-up window out of the way so I can see what went wrong here:

Error in pre-filled field

Nice! The one field I was not responsible for entering already has an error! The year says 110! So, even though I completed all my data entry correctly, I hit a roadblock. If they wanted me to leave the field untouched, the least they could have done was make sure the pre-entered data was correct!

My Recommendation:

Since they obviously do not want the date changed from today’s date, there is no reason to have the date be a data entry field at all. When a user accesses this screen, the date of request could simply appear (correctly) as uneditable data on the screen. Or better yet, why show it all? Do I need to be reminded that the date of my request is today? I think I know that. If the underlying workflow needs this information it can be added outside of the user’s interaction.

A simple step that could have been removed is instead going to lead to an error for each and every user who doesn’t realize they need to correct the field they were asked to leave alone.

Read Full Post »

One thing I have noticed throughout my time surfing the web is that almost every site that has you register, wants to know the same basic information: my name, address, email, etc. Generally, these are simple text entry boxes with a drop down thrown in here and there. But there is one detail I see asked for over and over where the paradigm used to capture the information can vary tremendously – Date of birth.

After a quick perusal of various sites, I have captured the most common means of data entry for date of birth…Let’s discuss 🙂

Text entry box(es)
The use of text entry boxes generally come in 2 different flavors when capturing date of birth. The first is the single box for entering the entire date:

Single Text Box for DOB entry

From a practical standpoint, this is a pretty easy way to capture someone’s birth date. Most people are used to thinking about their date of birth in this context. Where this model gets a little funky is how exactly I should format my entry. For a January baby, do I enter 1 or 01? Can I use a dash or do I have to use a slash between day/month/year? This example attempts to show me the correct format (MM/DD/YYYY) but also says I can enter a single digit month and day (4/8) – so can I also enter a 2 digit year?

The second flavor of direct text entry is the use of multiple text boxes to break up the segments of one’s date of birth:

Segmented Text Entry Box for DOB

The main impetus for using this model of data entry is to remove the whole dash vs. slash vs. period formatting concern. However, the other formatting questions I mentioned above can still hold true.

What I like about text entry boxes:

  • Text entry boxes fit within the context of how most users think about their date of birth and do not require the user to jump between their keyboard and mouse to access different UI controls.

Things to think about when considering using text entry boxes:

  • If the data being captured could exist in multiple formats, a best practice is to provide a flexible input field that will allow a user to enter the data in any way format they wish. A script can then be used to validate and transform the entry into the appropriate format required within the system.
  • The length of your text entry boxes should match the maximum character length allowed for that field.

Drop down boxes
Another option I see is the use of drop down boxes for each segment of a birth date. Open the first box, scroll down to my month, select it, move on to the next box, open it, scroll to the day, select it, and finally over to pick the year, rinse and repeat. Man, if my birthday was December 31, 1962 I might end up having to do quite a bit more work than I was expecting just to enter a date I seldom need to think about:

Dropdown for DOB entry

Open dropdown for DOB entry

What I like about drop down boxes:

  • A drop down box allows a user to select exactly one choice from two or more mutually exclusive options.
  • Use of a drop down box guarantees date and spelling accuracies and minimizes user-entry errors.
  • Drop down boxes are better than other options for displaying long lists when screen real estate is an issue.

Things to think about when considering using a drop down box:

  • Avoid drop down boxes if possible when the list is really long, especially when people are likely to be familiar with the options – like the state they live in or the year they were born.
  • When using a drop down box, consider allowing the user to manually enter text, auto-filtering the matching drop down entries so the user doesn’t have to scroll through the entire list.
  • Make sure your drop down box is keyboard accessible.

The Calendar widget
A nifty pop-up UI control that allows me to scan through a realistic looking calendar to select my specific date. Calendar widgets are cool. They are much more exciting than looking at another text box when entering my basic information:

Calendar widget for DOB entry

Until I actually have to start using one to enter my date of birth. Let’s see, it’s now 2010 and I was born a few decades ago, so what’s a girl to do? Spend the next few minutes clicking those cursed arrows to get back to the month and year of my birth! 520 clicks worth to enter just to get to my birth month! Using keystroke level modeling, that comes out to an additional 104.2 seconds to enter my date of birth. That’s almost 2 minutes of my life I can never get back.

Most calendar widgets now include the capability to scroll through years as well as months, which would definitely save me clicks, but it doesn’t make it any more fun when I have to enter date farther in the past.

What I like about calendar widgets:

  • A calendar widget provides a visual display for users who may find it easier to select a date or dates using a familiar metaphor over other interface elements such as dropdowns and/or text entry fields.
  • Use of a calendar widget guarantees date and spelling accuracies and minimizes user-entry errors.

Things to think about when considering using a calendar widget:

  • The use of a calendar widget is optimal when the target date is close to the actual date. Date of birth most often is not the proper place to be using a calendar widget.
  • A user should not be required to use the calendar functionality; instead, they should have the option of clicking within a text entry box and entering the date.
  • Make sure your calendar widget is keyboard accessible.

Hybrid
The use of a hybrid model for capturing date of birth is fairly new and usually involves the combination of drop down boxes and text entry fields:

Hybrid DOB entry fields

This scenario allows me to use the drop down box for the shortest list of options (month) saving me from the possibility of scrolling through long lists for both my day and year of birth. It does not however completely remove the formatting issues we see with segmented text boxes as mentioned above. And this version offers me no hint so I am on my own to figure out what the valid format might be (hopefully they took my advice above and allow all valid formats).

So…Have we learned anything? There are various ways to capture date of birth, but is there a RIGHT way to do it? Personally, I advocate for the straight text entry, allowing a user to enter their information in whatever format they prefer and letting the system do the transformation into its desired format. But this actually seems to be the least utilized scenario out there. Instead folks are told to use only the system’s allowed formats or they are subjected to extra time and clicks to ensure life is made easier for those who want our data as opposed to us as the customer. Next time you’re asking for someone’s date of birth think about that. 🙂

Read Full Post »

So, I wanted to leave a comment on the “Rating…Ranking…it’s all the same…” post. Cool.

I click the “Leave a comment” link, provide my name and a snarky comment, then click the “Submit Comment” button.

surprise-data-entry

Um, FAIL?

surprise-data-entry-fail

So, what’s up WordPress? Why am I surprised?

I had no idea there were required fields.

If this were a more elaborate submission, I might not be able to remember what’s required.

Solution:

Use a simple “Mandatory Form Fields” pattern to save the user from themselves, and reduce frustration. Example: Required Form Fields.

I have to look at the address bar to figure out where I am.

Really? On the “Error” page, all I’m presented with is a box containing error verbiage on a blank, white page. There’s no branding or navigation that assures me I’m still at the same site. My only option is the browser’s back button. Oh, and I know to use the back button because I am not blind. A screen reader would not have informed a blind user on how to proceed.

Solution:

Personally, I prefer inline validation on the page containing the form fields. Instructions can be grouped with the form fields section, and can refer to fields by their labels. Fancy styles can be applied to fields that fail validation. And, you know where you are because the branding and navigation has not changed.

I had to wait a few seconds for the surprise to be revealed.

Clicking the “Submit Comment” button results in a trip to the server. Server code may have to determine a bunch of things such as user authentication/authorization, form data validation, and where the user goes next. Depending on how your system is designed, the user can be waiting 1 to n seconds before they are told to “Please Try Again.”

Solution:

Again, inline validation on the page containing the form fields. This approach allows for client-side validation, preventing unnecessary form submissions. Avoiding a trip to the server can eliminate wait time and decrease frustration. Client side validation is fast, efficient, and almost instantly gratifying. The jQuery Validation Plugin is excellent for this purpose. If jQuery is not an option, JavaScript Form Validation works just fine.

What do you think?

Read Full Post »