This is an article discussion thread for discussing the SitePoint article, "7 Steps to Useable Forms"
| SitePoint Sponsor |
This is an article discussion thread for discussing the SitePoint article, "7 Steps to Useable Forms"
This article gives tips for both developers and Testers. really good
the disappearing text trick from Add Help Information doesnt seem to work at all. am i doing something wrong?
edit: ahh, ok. the name of the filed must be specified as the same name in the onclick field. maybe that could be changed? its confusing at first.
I really disagree with tip 4 of this article. I believe that all websites should be getting built using CSS an valid XHTML in order to produce more usable and accessible sites. However, using tables in a webiste, aside for that which they were intended for (tabular data) is not the way forward.
I take issue with a few of the points presented in the article too:
- Auto-focusing to an input on page load is frustrating to me, and to quite a few other users I've chatted with. I expect focus to stay on the address bar when a page loads, and nothing's more frustrating than seeing half a URL in a search box on the page when you're trying to get to another page.
- The status bar tricks are okay, but seem unnecessary. HTML has the title attribute for supplemental information, and that can be used on any element including form fields. This also has the benefit of not requiring scripting or altering the status bar (which a lot of power users disable thanks to fine-grained script permissions in browsers like Opera and Mozilla).
- The tables for form layout item is something I only slightly disagree with. For simple forms it's probably best not to use a table to lay out the form fields, but for a more complex form I could see a use for it.
Seeing that this article was written in 2001 though, I definitely see why I disagree with what's mentioned here. 4 years ago there was far less choice in what could be done to make forms more usable, especially given the state of browsers web designers supported back then versus what they support now.
isn't that article old?
i remember reading it and getting mixed up
I can see a problem with the second code example under number three. If you give your input a * onClick = "document.forms[0].first_name.value='' *, then after a user fills in that input, if they click it again for any reason, their text is GONE. Particularly annoying with textareas, which hold a lot.
@hgilbert: sure it's old. Tags and attributes wirtten in upper case, unquoted attribute, tables for layout... That's sooo 2000 ;) *scnr
Yep, HOTMAIL is a good example! I type a "To" address and next thing i know i'm in the main text editor!Originally Posted by vgarcia
The problem with item #2 is that it is not nice to have if the page loads more slowly than I can type. I'm already typing in the 2nd or 3rd field, the page completes loading, and suddenly I'm back in the 1st field. This is a potential security risk if the field I'm typing into is a password field, as the password gets all or partially exposed in the 1st (focused) field.
The logic would better be to place the focus in the first field if and only if the focus is not already in a form field.
One problem with autofocus is that it is not friendly to blind site visitors using screen readers. They will find themselves in the first form field without any context for why they are there.
yes I hate that one too, I must have typed over a thousand of half email adresses in the main text editorYep, HOTMAIL is a good example! I type a "To" address and next thing i know i'm in the main text editor!
The problem with #3 is that the info text is also submitted if the user omits to enter information. How do you make sure that the info text is not submitted or that you can filter it out?
While it may be considered to fall into the realm of accessibility, use of the label tag can make forms more useable.
What about positioning of the buttons, such as Back, Next, Cancel? What is the recommended standard arrangement? For example, if the options are Back, Next, Finish, and Cancel, would it be more intuative to have them be arranged as
Cancel | Back | Next | Finish
with the more likely buttons the user would click positioned to the left, or would it be better to position them as:
Back | Next | Finish | Cancel
with them being placed "positive to negative"?
Thank you.
I don't know about the other buttons, but I've had it suggested to me that there not even be a Cancel button as it is too easy to wipe out your work by mistake. I've certainly done that.
Posting Permissions
Bookmarks