Feeds:
Posts
Comments

Archive for the ‘Required Fields’ Category

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 »

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 »