Stuck in table/form hell!

May 29, 2006 3:48 PM

Tell me what web-forms really, really impress you. I'm stuck in "form-developer" block mode, and after muddling through mountains and mountains of layouts and best practises sites, I think I'm about to explode.

The forms should be CSS only (no tables, unless there is tabular data involved) and valid XHTML (transitional is fine). Columnar, vertical, horizontal are all fine. Accessibility would be appreciated, but not necessary.

My current site is heavily form-based and currently using tables in order to get the column layout down. Unfortunately, the XHTML involved is messy as hell and very difficult to style consistently across the site.

I'm been trying to implement table-less forms for a few weeks now and it's been painful. I just need some inspiration (and, possibly, reasons to re-think the overall site layout). So, please send me some links to sites that really impress you (your own is fine).

(Obviously, ethics dictate that if I borrow any ideas/elements from these sites I will request permission from the developers. I would post links to my own site, but it's intranet only and not accessible to the outside world.)

Any assistance would be appreciated. Thanks.

posted by purephase to computers & internet (13 comments total)

If I was trying to make a complex form I would just give in and use tables. As long as you don't end up with 42 layers of nested tables, maintainability isn't that bad. Lots of sites that use table-less XHTML only need the simplest of forms (e.g.) - I can't off the top of my head remember seeing any complex table-less forms.

Aside from using the fieldset tag if you're not already, I don't have much more advice; arranging form elements using table-less XHTML/CSS really is a nightmare.
posted by matthewr at 4:05 PM on May 29, 2006

Simply Accessible has some good pointers on form layout, and the Wufoo demo may also give you some ideas. Richard Rutter wrote up some ntoes on using definition lists, a technique of which I'm rather fond. There are a couple of articles at A List Apart which touch on form layout as well.

Another good set of examples is here at Maxdesign.

Let me know if you need more.
posted by ubernostrum at 4:08 PM on May 29, 2006

I can't think of a site that does this, but I have always thought it would be a great idea to use a freeform input box, at least for standard name/address info.

For example, a texarea not unlike this one on mefi with the instructions "Type your Name and address here, just like you'd write it on a letter:" feels much more pleasant than the typical 'separate boxes for first-middle-last-address1-address2-city-state-zip-etc'

After submitting, the verify step can show it split into the separate parts for confirmation, or perhaps client-side logic shows the split-up version appearing as it is parsed -- a form-ified version of live preview.
posted by SpookyFish at 4:19 PM on May 29, 2006

Why are you trying to go tableless? I still find CSS frustrating for many kinds of layout tasks. Tables are just simpler. Get the job done and working, and then come back later and redo the HTML to go fully CSS if you run out of things to do (which I doubt).
posted by fcain at 4:36 PM on May 29, 2006

SpookyFish, interpreting freeform input is a massive pain. Many times, it flat out cannot be done, especially if the user's input is truly freeform and doesn't match up with anything your program has seen. Not to mention processing strange input could easily put a heavier load on the system, & would make a very nice DOS attack.
posted by devilsbrigade at 5:02 PM on May 29, 2006

First off, use labels.

Now that's out of the way, there are three main schools of thought:

• Label Above
  Label goes above field.
• Label Beside: Label goes next to field.
• Label inside (Can't show on MeFi, but pretty self-explanatory.)

You can accomplish a CSS-only design if you choose label above. If you choose label-beside, tables really are the best way to do it, because you can right align your labels to the input elements and still have them all line up, but without having to hard-code widths for your labels (the Achilles Heel of any label-beside, table-less method). Label-inside is just too cutesy for my tastes, and only works on input boxes (not checkboxes, not radio buttons, not select boxes, and not lists... basically useless).

Next, define standard widths for your input fields. There's nothing uglier than a bunch of input boxes that are either willy-nilly widths, or worse, all max-horizontal width available. "What's wrong with using max-horizontal?" you might ask. Take a look at STATE input boxes and ask me again.

I usually predefine four main widths for input/select boxes (.full, .threeqtr, .half & .qtr). That way I have options, but the widths will still look basically consistent with each other.

Make sure your input boxes are styled with a wide sans-serif font (e.g., anything but Arial). I like Verdana for input fields because it's easy to tell the difference between I's and 1's, 0's and O's.

On-hover routines are an easy way of showing what field has the focus. Generally the onfocus element has a white background, an off-focus element is slightly (slightly) darker. You can get fancy and define a "required" class for your elements that will wrap a red border around required field elements, but traditionally an asterisk in front of the field name is the way to go--or combine both. Just be sure to appropriately inform the user of this (* Required field at the top of a form group is straightforward enough).

Finally, and this is the tricky part, provide a cancel button. Not a back button. A real, working cancel button that reverts all the elements back to their default state. If the form is empty by default, don't worry about this, but on the form's I've developed, they're usually pre-filled in.

Also, if the form fields are pre-filled-in, and you're giving the user the ability to edit the fields, you must, must, must disable the form elements until a edit button has been clicked. The user has to be forced to decide, "Yes, I wish to edit this." Again, if these are default-empty fields, don't worry about this.
posted by Civil_Disobedient at 5:07 PM on May 29, 2006 [1 favorite]

Also, if the form fields are pre-filled-in, and you're giving the user the ability to edit the fields, you must, must, must disable the form elements until a edit button has been clicked. The user has to be forced to decide, "Yes, I wish to edit this."

Please explain why. I've never seen this anywhere before.
posted by matthewr at 5:15 PM on May 29, 2006

fcain writes "Get the job done and working, and then come back later and redo the HTML to go fully CSS if you run out of things to do (which I doubt)."

That's what I'm in the process of doing. The site is already up and running, and working, but I'm fairly sure that a lot of the user related issues I hear about are due to the fact that the forms are sometimes columnar, sometimes vertical, sometimes horizontal (for nav/footer). I'm trying to get away from table layouts, but as CD mentioned, when you're doing the the columnar approach (Label: Input) the input elements don't align properly.

I think the...
Label Above
Label goes above field.

... approach is the best but due to my current page layout it doesn't really jive. I'm beginning to think that I might need to overall the overall layout.

ubernostrum, thanks for the WuFuu link. I was trying to remember the name of the site earlier. Looking forward to when they're out of beta. The clagnut article was a blast from the past, I remember reading that article a year-or-so ago.
posted by purephase at 5:55 PM on May 29, 2006

It depends on the importance of the data, your trust of the users, and the purpose of the form fields. The financial institution that I work with cannot afford to have data erroneously changed, therefor it was asked that there be some mechanism that "made the user think before commiting." There are a number of possible solutions to this: pop up a warning message a-la Microsoft's "Are you sure?" "Positive?" "One last chance!" etc.

The other issue is that many times form fields perform double-duty: first is for viewing data, second is for editing data. If you just want to peruse an account's details, there's no reason to offer editing capabilities. So forms are "overloaded." You see this all the time: users viewing data where it's just too easy to change it. Thus, the edit function.

Like I said, though, if your form fields are default-empty, or you implicitly trust your users not to be knuckleheads, or you don't mind pop-ups, you can ignore the suggestion.
posted by Civil_Disobedient at 5:58 PM on May 29, 2006

(Sorry, that was meant to be a response to matthewr's question.)
posted by Civil_Disobedient at 5:59 PM on May 29, 2006

Not technical info as such, but please, whatever you do, leave out that bit of the web-form that asks you to enter a "title". Nothing is more frustrating and demeaning than being forced to choose between Miss, Mrs and Ms when you don't want a title at all.
posted by azuma at 1:15 AM on May 30, 2006

Accessibility: the LABEL element mentioned above is great for blind people, and can be employed whatever layout approach (tables/CSS) or design (above/below/right/left) you choose. It's very simple to use.
posted by alasdair at 4:59 AM on May 30, 2006

ive always avoided putting a "cancel" button in forms. Its a bit too easy to click it by mistake and wipe everything you just typed.

if people change their mind, they'll click back, or just overwrite what they entered before.
posted by lemonfridge at 3:20 PM on May 30, 2006