1 Untitled

Don’t force a format for phone numbers. Autofills get confused. Put a checker in to see if it’s all there it is important.

Don’t make people scroll down a list of all 50 states to find the abbreviation. We know it already. I can type FL or NY or whatever. And autofill will get it right.

I agree particularly about returning the form when errors are made as I filled it out.

posted at 12:31 am on December 20, 2005 by First NotBlank

2 Outlook express causes spam

I actually think it was the web form that got me interested in web design, and later programming. I guess I saw that there was a true art to making a visually pleasing and easy-to-use form online. (Now though, designing a form is about my least favorite thing to do.)

I think we (I know I do for sure) sometimes over-estimate Average Jane’s capabilities and understanding of the web. I try to pay close attention to my friends comments and actions when they use my computer. They probably think it’s freaky the way I study their actions, but it’s useful to me. A lot of times it’s funny—the things they do or say. (Then I realize how dorky I am for giggling at them).

I was checking my email and made a comment about a few spam emails I had received. My friend quipped, sounding as smart as he could, “That’s why I don’t use Outlook Express. It causes too much spam.”

So maybe my tip is to remind yourself, when you’re designing your web forms, that the user possibly thinks Outlook Express causes spam.

Or, perhaps my friend knows something about Outlook Express that I don’t.

posted at 12:57 am on December 20, 2005 by Colin Williams

3 A note about password security

As mentioned in the article, password fields are usually blanked out after posting a form to the server and returning with errors. Although annoying, this is indeed done for your protection. When the form is posted to the server and then redisplayed, the password fields have to be repopulated just like any other field—this means writing the password in clear text to the html source. Password fields are displayed as asterisks, but the source data is written as plain text from the server. In fact, in signing up to ALA to post this remark, I tested the form and found this very issue! (Fill in a password field but leave another required field blank, submit the form, then view source.)

Now, what are the odds that I’ll submit the form, then leave my computer unlocked with the partially-submitted form visible so that someone could or would actually find my password? Probably slim. However, don’t forget that now that it’s been written in clear text to my browser, it’s also sitting in clear text in my browser cache as well (indeed, to verify this, I simply browsed to my browser cache folder, did a quick ‘search in files’ for the term ‘password,’ and voila – there’s my cached ALA form entry with my password as clear as day). Probably not a good thing if someone with this basic knowledge ever compromised my machine, especially since most people use the same password for many sites. For this reason, websites should generally never write passwords back to forms from the server (client-side validation does not have this issue, of course, since no data is ever written back to the form until the form contents leave the client).

posted at 02:52 am on December 20, 2005 by Brian Moeskau

4 Phone numbers & states

Another thing to remember abut phone numbers: Some of us are from outside the US. And it’s not very obvious how to fit an 8-digit phone number a 2-digit country code, preferably prefixed with a ’’, into a standard US phone number format…

Same kind of thing with a state choice: it’s always nice when there is an option for leaving it blank. We don’t have ‘em here ;)

And if the form is supposed to absolutely only cater for USAians, please make that clear from the very, very beginning. I probably can’t count how many times I’ve filled one out only to find three screenfuls later that sorry, this is only valid for citizens of the US. The ‘net is global – so plan for it.

(good advice for full error messages and avoiding re-typing!)

posted at 02:54 am on December 20, 2005 by Ole Madsen

5 Amen

Amen for “opt-ins” over “opt-outs” on email newsletters, but I don’t think that message will be heard soon. In my opinion, email newsletters should be on their way out thanks to RSS, but sadly I know they’ll stick around for quite awhile.

Overall a solid article. I can’t stress enough how important it is to have small forms. Whenever I hit a site with a massive 15+ registration form, I often skip it. I have a friend who won’t register on just about any site. Not due to security concerns, but due to laziness. He’s been using digg.com, slashdot, ESPN for months now and hasn’t bothered to get an account on any. Whenever a form comes up he hits the back button. So the most important question when thinking about a form is “is it really necessary?”

posted at 02:58 am on December 20, 2005 by Rob Goodlatte

7 Watch what you make required

I think that there should only be one phone box, and let the user enter however it should. Not only is this recommended for US users, but even more important for international users, since not everyone has a 10 digit phone number. Also, since the US is not the only country in the world, it shouldn’t limit or require the state box. Or if it requires it, only for US residents. There have been numerous times when I had planned my trips to the US, but felt crippled as to what I could do INSIDE the US because I have to call a 800 number in the States, or the online tickets were good only for residents. I can understand some services (like grocery delivery) being limited, but it shouldn’t be that way for concert tickets or other entertainment sources.

—A disgruntled expat who is frustrated at the lack of internationalization sometimes.

posted at 04:18 am on December 20, 2005 by Frank Fridlund

8 Multi-Select Boxes

The article advises against using these, but they are an important web application interface widget in my opinion (we aren’t all using forms for simple marketing and contact purposes!) How else would one go about allowing the user to select several options from a large list (too large to think about checkboxes)?

posted at 06:03 am on December 20, 2005 by Dan Herd

9 Exception for Yes/No questions

Even though it makes absolutely sense to use a checkbox for a Yes/No question there are reasons to use two radiobuttons in stead. I work for a insurance company where we need the user to actively give an answer, leaving a checkbox unanswered is not an action. Also on top of that almost all our questions are mandatory, a telephone number is one of the very few exceptions to that rule.

posted at 07:58 am on December 20, 2005 by Rob Hofker

10 Untitled

Most of the stuff to look out for is well documented in the article (good job on putting together such an easy to understand piece). It’s good to see it written down (rather than sloshing around in my head).

Instead of supplying those massive long lists of countries to choose from, why not let the user type it in as well as choosing from a select dropdown? What about grouping the “most common” countries into a select dropdown and providing a regular text input for others? That’s certainly more usable for a wider audience.

What really gets me is the decision to require users to fill out a ZIP code. If the user selects USA then by all means provide a ZIP code as mandatory… but we don’t have ZIP codes here… and whilst they are often called Postcodes outside of the USA, they are by no means well known (in all countries) and certainly not used outside of business correspondence (in many countries).

The use of labels, legends, fieldsets and non-mandatory fields are what makes me bother to come back to a site (ok… and great content – thanks ALA).

posted at 08:05 am on December 20, 2005 by Jeff Home

Got something to say?

Discuss this article. We reserve the right to delete flames, trolls, and wood nymphs.

Create a new account or sign in below if you’d like to leave a comment.

Subscribe to this article's comments: RSS (what’s this?)