A great example of a pattern that really requires the application of visible labels is the postal address entry. Postal address entries may easily contain four, five, or more fields to fill out. The many fields often lead to forms that are lengthier than necessary if all the labels are kept on the left. Another disadvantage of the left-label-layout is that it's far off of the layout of postal adresses on envelopes and letters in the real world.
If you make the layout of the address group more compact by mimicking a traditional postal address layout, then it will make the form more compact. More importantly: People will be able to fill you an address information in the same fashion they are used to on a postcard. Almost without looking at the labels.
This doesn't make visible labels completely obsolete though. In the example below, a Dutch address layout is applied. Imagine that you would like to send a nice bouquet of flower to your favorite blogger in The Netherlands. But if you've never lived in The Netherlands, then you're not likely to be familiar to this layout. Hence the use of visible labels will be helpful.
Putting all the labels as superscripts in between the input fields and the term 'Address' as a legend on the left is a great improvement for the layout, but there is an alternative that's even more compact, which I like to call superimposed labels.
Some implementions of this interaction pattern do just pre-fill the values of the input fields with the terms Residence, Street, Postal Code, etc. This is semantically incorrect, because 'Residence' is not a valid value for the field that's called Residence unless there is a place on this planet that is called 'Residence'. A practical issue is that the backend would always receive this value back as a place name, rather than for instance 'Amsterdam'. The backend would have to check whether this field's value is not called "residence" rather than simply checking whether a field was filled out at all for validation purposes. Extra site languages could even further complicate this matter.
The super imposed label solution
The terms street, postal code and son on are labels more than anything else. These labels are positioned in front of the labels by means of CSS and triggered to disappear by a little bit of JavaScript code. The particular feature of these labels is that they disappear upon the click of a mouse. The terms will remain invisible after the user entered text into the field. Would the user move the focus to another element without filling in anything would return the label. It's an elegant pattern that saves space on the screen while labels are properly applied for all the right reasons.
HTML placeholders
The HTML 5 standard has a solution built in for this, but not with the use of labels, but a certain attribute called 'placeholder' instead. The markup looks like this and it works in most modern browsers:
<input type="text" placeholder="residence" />
If this pattern is picked up quickly by screen readers, then it will become an accessible solution. For now, of all major browsers, only Internet Explorer (9) does not support the pattern. The IE problem could be fixed with a bit of JavaScript that fills in the value of the input field based on the value of the placeholder attribute and to erase that just before submitting the form if it hasn't been altered by the user.
Other recent articles:
-
Form follows function and achieving thereof by Cornelis G. A. Kolbach — February 1, 2009
Read more...Forms can be dreadfully tricky to style and structure properly. Several articles that are out there focus on best practises for building forms using HTML en CSS. This article focusses in a non technical fashion on the use of meaningful nomenclature and how form semantics relate to elements that current markup standards have to offer. It may help you recognise structural patterns and to compose forms properly.
-
Gregorian date input diversity by Cornelis G. A. Kolbach — February 1, 2009
One of the most common interaction patterns one can find on forms is the date input group. They appear in all shapes and sizes in various applications and sign up forms on websites. Certain forms of appearance seem to be more popular in certain geographical areas than other. But other than that it is hard to find any pattern or rationale why one website has chosen for model X while the other has chosen model Y. The suspicion would rise that the date input method is often dictated by the way the backend would 'like' it. This is a situation which neither we, as interaction designers and consultants, nor the end user should settle for.
Read more... -
AJAX and the Old World by Cornelis G. A. Kolbach — November 19, 2006
Most of us know that HTML was designed in such a way that it would enable one to (single) click on certain underlined words in a text, that would link to another page. Initially, these hyperlinks were the only clickable items on web pages. Soon enough, besides using hyperlinks in an inline fashion, they would be grouped on pages so they would form a menu which would help people to navigate between pages that belonged to a certain group of pages. The web site was born.
Today, complex layout methods have made it possible to borrow from interaction patterns of desktop applications, including drop down menu bars, expanding trees and tabs. It's this exact inevitable shift of desktop application design patterns to the page metaphor that has more than often led to confusion amongst both web designers and end users. In this era of AJAX and RIAs, the possibilities for user interface designers have become infinite. Hence the question arises: Have all of these developments actually led to an improved user experience?
Read more...