This is neat. Holmes is The CSS Markup Detective:

Holmes is stand-alone diagnostic CSS stylesheet that can highlight potentially invalid, inaccessible or erroneous HTML(5) markup by adding one class.

I like this because it’s in a way passive, but really useful. When I was really getting into Web Standards, I had a number of Firefox Add-ons that would light up, blink, and cause a bit of chaos when things were invalid or errors were present. I’ve outgrown that to an extent, but I like the idea of this. I’ll be keeping an eye on it, keeping yourself in check is still important.

Advertise here with BSA

Forms have been viewed as an area of Web design which has much room to improve. From the markup itself to general design guidelines, there are some trends which have evolved surrounding their implementation. Forms may be something you view as a smaller aspect of your overall design, but I’ve got to be honest when I say that seeing a well designed form is not something I often come across. When I do see a form which has been very well implemented, I try to take some notes to keep in mind for future projects. It’s difficult for me to express in words what it is that impresses me about well designed forms, but it’s quite a different story for me to jot down a few things which I find irritating.

Poor choices for field defaults

Providing a field default is, in my opinion, usually something that should be avoided. There are certain circumstances where it’s a necessity, such as using the input itself to reflect what would otherwise be represented by a label. Including a default input value is a significant annoyance if not implemented properly. Always keep in mind that if you are going to provide a field default, make sure you add it with progressive enhancement in mind. I say that because more important is making sure your default is cleared out upon input focus. I can’t count the times I’ve gone to enter data in a field with a default value and ended up typing within the default string itself. It’s a show-stopping event.

Field defaults are in no way limited to text inputs or textareas. A peeve of mine which has developed over the past few months is finding a default entry in a select. For example, stumbling across a form which has a select for the state in which I live. This particular select has a default value of “(Choose One)”. Why? The widget itself is designed visually to communicate that there are a number of values to choose from. A select is not an uncommon interaction with a form, why is it necessary? If nothing else, it requires you to apply otherwise unneeded validation on the element. I can possibly understand that it may be used as a method for ensuring the reader has taken the time to choose a value from the select, but to me that’s a stretch. What’s worse is seeing “(Choose One)” as the default entry with “Other” or “No answer” as the bottom choice. For selects without required data, why not make “No answer” the default?

At the end of the day, if the select is required data, you’re creating extra work for all parties involved by trying to hook an answer with “(Please Choose)”. From the start, you’re going to need to validate that field. Continuing, if a reader is maliciously trying to submit bunk data, when notified of the required field, an entry will simply be chosen at random, which now looks like a more legitimate answer than “Other”.

Another issue I’d like to bring up with form defaults is one that has to do with radio buttons. Interaction here is very similar to that of selects but in this case, my annoyance happens to be an absence of a default value. The purpose of a series of radio buttons is to have a reader choose one of the available choices. Why leave this section of your form without a default?

Validation issues

Form validation is an art form. There are some really fantastic ways to validate forms which not only benefits your server, but also the user experience as well. With the widespread arrival of unobtrusive JavaScript, form validation on the client side has been improved exponentially, but there are still some pitfalls which can result in a very frustrating process for your readers.

Most importantly is being upfront about what data is required when filling out your form. On top of that, you should provide relevant information regarding any syntax required for entering data. Information such as phone numbers, credit card numbers, and dates come to mind. Readers are likely to follow instructions on formatting, and be much happier doing so as opposed to seeing they entered a date wrong because you failed to provide syntax.

A huge peeve of mine when it comes to form validation can only stem from laziness on the part of the developer. It doesn’t take much to check whether each field was populated already on a page load, so be sure to include the submitted data as a ‘default’ value when exercising validation. There’s nothing worse than taking time to fill out a form only to have the page reload saying I forgot a digit in my phone number, but the rest of my data is missing.

Finally, on the side of form validation, make sure your error notice copy is up to snuff. Ensure the notice is contextual and you’re not taking the easy way out by dumping the errors at the top of the page, leaving the reader to hunt for information to correct. Make sure each error description is accurate and easy to interpret. If a credit card number was entered incorrectly, do more than classify the data as “invalid”. Explain, using syntax if applicable, why the entry does not validate.

Avoiding general frustrations

There are number of other issues to consider when designing forms. Something I continue to run into time after time is the classic case of recursive selects. I will despise this implementation until the end of time. I can understand that it may be a way to de-clutter the UI a bit, but at a serious cost to usability.

Another frustration that often surfaces is poor use of tabindex. Browsers are quite good at figuring out a logical order for tabindex if the developer hasn’t implemented one, but they’re not perfect. There are many (high profile) websites with terrible implementations of tabindex, dragging readers here & there in a very disorienting manner. Issues with form jumping can be easily avoided with a quick implementation of a logical tabindex.

I know I’m not alone when I say I’ve got a few annoyances when interacting with forms on a daily basis. What is it that truly bothers you about poor form design? What tricks do you have up your sleeve which have worked out really well in practice?

Advertise here with BSA

Validation zealots

I’ve written my fair share on markup validation, and I do think it’s important to validate your code. I’d like to be explicit in saying that when I speak of my OCD only stretches to my own work. There is an abundance of invalid code sprawled across the Internet.

Jeff Croft recently wrote Your Markup Validator, an article focused on this exact issue. He’s got a few choice words for those who feel obliged to publicly note the ‘inferiority’ of invalid code. While I’ve incorporated validation into my workflow, that’s as far as it goes. Reflecting on my past work in Web development, including an initial learning phase, I don’t believe I’ve ever tried to validate the markup of a document I didn’t create (save for glancing at the HTML Validator Firefox extension).

I simply don’t see a need for validating the work of others. I’m not sure why anyone would take the time to do such a thing, let alone bring it up in any type of public fashion. The important thing is to realize the benefit of validation for yourself, and the impact invalid markup has on a document. When you’ve gained this knowledge, you’ll compensate your workflow to make any adjustments necessary. Public mockery of invalid markup is unacceptable.

As Jeff states, validators are debugging tools used to help you better your markup as you see fit. Validators are not a scale to live up to, and they’re certainly not a scale to measure the work of someone else.

A successor to divitis?

In an interesting observatory post by Mike Cherim, some abuse of list elements is exposed. Mike took the time to analyze some specific recurring examples of list misuse and after reading the piece, I had to admit that I’ve noticed a similar trend. While it may appear that I’m contradicting my stance on validation zealotry noted above, like Mike, unless directed at myself, I don’t go around calling people out on something I may feel is an oversight. Mike fears that lists are becoming the new tables and we may be facing a mutation of divitis.

Continuing, Mike’s first example of list abuse is associated with forms. Using lists to structure a form has been a long-standing discussion among many developers. I’ve never used a list to mark up a form, as I don’t see data entry in this way as something that fits within a list. I feel you’re marking up a form and you’ve got a number of elements to work with. Using fieldsets & legends alone give your form some semantic structure, and incorporating some choice separation elements (such as a div or two) can produce great result. As raised in the comments there could be some circumstances where a list may be applicable within a particular form, but I agree with Mike in that a list shouldn’t be a structural foundation.

Misusing specific elements in a way not intended, especially for presentational purposes, while creative and admirable on many levels, simply isn’t right.

- Mike Cherim

Mike continues by exposing more circumstances in which lists are becoming increasingly abused, each with a bit of opinion regarding why it can be looked at as misuse. I was glad to see that Mike and I share an opinion surrounding effective calendar markup. I’d like to suggest that you take a few minutes to read Mike’s piece and check out the comments for a bit of back-and-forth.

Advertise here with BSA