Archive for the ‘Forms and Data Entry’ 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 »

I know I typically share user experiences that I feel are lacking in the whole ‘understanding your users’ department, but today I actually have an interaction that I think goes above and beyond from the UX perspective. A collective round of applause please!

I was checking out a site that offers wire framing and prototyping products:

Site with a Feedback Link

This is a nice intuitive, streamlined UI. But the thing that really caught my eye was the little ‘Give Feedback’ image in the upper right hand column.

Feedback widget

Curiosity killed that cat, so I had to click on it, and I was presented with one of the most well designed Contact forms I have ever encountered:
Feedback form with category selection

What makes this so special you say? Well the first thing I noticed is that they seem genuinely interested in my feedback as opposed to who I am and what my contact information is. Instead of immediately asking me for that type of information, their first question is ‘what kind of feedback might that be’ – and rather than presenting it via a sterile dropdown as so often is the case, they instead make it a little more fun by putting the most common types of feedback right out in the open as buttons where I can simply click the one I want. None of the specific categories match? That’s okay too; there is an Other Feedback option. I also want to point out that the entire interaction is keyboard accessible.

I pick the type of feedback I’d like to give and:
Feedback form text entry

A text box appears, highlighted and focus is already in the text box for me. All I need to do is to start typing my comments. And all of the other feedback categories are still front and center in case I decide that a different subject would be more appropriate. I type in my comments and hit Send…
Feedback form with contact info optional

The only piece of personal information being asked for from me is my email address, and I only need to give it if I want to ensure someone follows up with me. How awesome is that?!

It’s funny, but when I blog about my negative user experiences I feel it necessary to protect the offenders and blur out identifying information. But when I encounter an experience as positive as this, I want to yell the site/company names from the mountaintop! This interaction shows that Kampyle has made good use of their time and energy to ensure that the product they were creating was going to meet the needs of both the sites that purchase it and the users who would actually be sending the feedback. Kudos to Kampyle!

Read Full Post »

I was reading an article about ways to increase traffic to your blog, because who doesn’t want more folks coming their site and realizing the wisdom in their words. 🙂

Anyway, the article mentioned submitting your site to a multitude of free blog directories, so I figured I’d give it try. Site after site asked for the same basic information. Here I am on about the fourth site:
Blank Registration Form

Piece of cake, I’d already filled out this same basic stuff 3 times before. The one thing I didn’t want to do was put reciprocal links on my blog, which according to the terms was fine, so I just left that field blank each time. I finished filling out this form, hit submit, and got this:
Registration Form with unseen error

Hmmmm….did it submit? My guess is no…but if not why didn’t it? I start inspecting the screen, field by field, until notice this:
Unobvious Error Message

Suddenly the reciprocal link field has become required (yes, scroll up to the first screenshot if you don’t believe me!) – or maybe they are using the exact same image for their error notation?! I have no clue. And even more interesting the error message (in the exact same font color and size as everything else on the screen) states that I entered an Invalid URL – can the lack of a URL actually make it invalid?

I was basically stuck at this point, I wasn’t going to go down the whole reciprocal link path, so I abandoned the task. I guess this is one blog directory you won’t find LiveUX in…

My Recommendation:

If a user makes an error in a workflow you want to direct them right to the source of the error so they can fix it quickly and easily.

  • The error message itself can appear either at the top of screen (indicating the specific field that is in error) or placing it in close proximity to the field itself (usually to the right or below the field).
  • Use an indicator to highlight the invalid field (for example a red X to the right of the field). Do not use an image that has more than one meaning.
  • The error message should by styled to stand out from the rest of the text on the screen. The norm is to use red text.
  • The error message should accurately describe the error that was made. It is also best to include the step(s) a user can take to correct it.

Okay, that’s about it for me today…I’m going to register LiveUX with a few more directories…wish me luck!

Read Full Post »

Entry hints in web forms and text entry fields are handy little things. They give a user more context about what they might want to enter in a text field. For example, if I was filling out a registration form where I need to enter my date of birth, an entry hint of mm/dd/yyyy gives me the valid format I should enter it in. In giving me this simple hint, I have been saved from wasting my valuable time trying to guess what the appropriate format might be. I like not having my time wasted. 🙂

So how could one go wrong using entry hints? Let’s take look…
Search field and button with search for blog entry hint

I am browsing a particular site’s blog directory and notice the Search capability. It’s even telling me (with an entry hint) that this search is specifically for finding registered blogs. Great! I want to know if my blog is registered, so I’ll simply type in ‘LiveUX’, hit search, and see if my blog shows up in the search results…
No results found message

Huh? All I typed in was LiveUX! How did I get this mishmash of words in my search? Well, it turns out that maybe this entry hint wasn’t as helpful as it could have been. When I retrace my steps, here is what I discover:
Entry hint remains in field on focus

When I put focus on the field (by clicking within it) to begin typing my search criteria, the entry hint does not disappear.
It is up to me as the user to clear out all of the entry hint text before I am able to enter my search criteria. So much for not having my time wasted…

My Recommendation:

Entry hints area great tool that can make a site more user friendly when it comes to completing forms. However, when incorporating an entry hint, it needs to be done correctly. When a user puts focus on the field, the entry hint should disappear, making way for the true data to be entered.

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.

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 »