Entries from June 2006 ↓

Your Forms Are Killing Me

Note: I have no particular dislike of the website in question, in fact I read it on a regular basis, but what I’m about to talk about is a travesty. Although it does tie in rather nicely with a previous post of mine: Bloated Forms.

I was browsing one of my regular watering holes (water of knowledge, of course!) - The Server Side.Net - and I felt the overwhelming urge to make a reply in the forum. Registration was required, of course, so off to register I went. What followed was purely horrible on so many levels.

Step One

First Form

I was first presented with the rather humble request of entering my e-mail address, nothing un-expected here and to be honest, quite refreshing in its simplicity. I thought I may just receive an e-mail with a pre-generated password and that’d be it… but it wasn’t to be.

Step Two

Second Form

Next was a list of ten check boxes for various newsletters I could subscribe to. I don’t know how many people actually use these “features” of registration forms, but I just wanted to register. If I wanted to receive newsletters I would opt-in from within my account once registered. In their defense, the checkboxes did at least default to false!

On a side note, how is it not understood that you should give the user as little to deal with as possible? Especially when you’re trying to get them to sign-up to your services, you should get them in as quickly as possible, no fuss, no mess and people won’t lose interest.

Step Three

Third Form

This one is a whopper, scarily so. Baring in mind that all I want to do is make one post on their forum, this seems a tad excessive.

Firstly they want my first and last name, fair enough but I’d say even just my name, singular, would suffice. Next are my Company Name and my Title at said company, followed by my full address, postal code, telephone number and fax number. These are a bit odd, especially considering I might be unemployed and/or unwilling to disclose such information.

Based on what the next sections were, The Server Side are seriously interested in my company. They’re asking such in-depth questions as what my IT budget is, how many employees are at the company, how many of those are developers, the purchasing scope and the industry of my organisation. Woah. Who even knows that stuff? Never mind wants to disclose it.

Finally I get to choose which technologies are relevant to me, via another big list of checkboxes.

As if that huge list wasn’t bad enough, to put the proverbial icing on the cake, 90% of the fields are mandatory! Yes, even the IT Budget and Purchasing Scope. Absolute madness!

Step Four

Fourth Form

Yes, there’s more. This is merely a finalisation of my e-mail and a password. Nothing fancy.

The End

When I encountered step three, all I thought of was targeted advertising; something I definitely do not want to be a part of. I’m shocked to be honest, it’s a sad state of affairs when so much information needs to be gathered just to allow simple forum/comment posting.

I didn’t make it past the form - The Server Side has lost my gems of wisdom.

Amusing “Recommend a Friend” usage

We’ve been sending out a (rather successful) e-mail campaign for Swift over the past few days, a good experience and definitely an eye opener. Something that amused me over the course of the project was the way people were using the “Recommend a Friend” feature of the e-mail.

If you’re presented by a form, which asks for your friends name, e-mail address and some form of comment from yourself, what would you put in the name field? Common sense says that you should put their full name in, as generally that’s what people want; not these people though! Over 50% of the recommendations were supplied with first names only or nicknames - the most wonderful being “MUM”; yes, block capitals too.

So we have a nice collection of recommendations along the lines of:

  1. George
  2. Sally
  3. Geoff
  4. liz
  5. MUM

How very helpful.

They’ll love the targeted e-mails they’re bound to receive too; “Dear MUM, we think…”.

Bloated forms

I don’t know what it is, but there seems to be an inherent urge of web developers (or designers, managers or whomever) to create forms that are hugely bloated and pointless, even for simple things such as sending a contact e-mail.

This fascination with bloated forms is incomprehensible to me, I just can’t understand why anybody would want to know the gender or official title of somebody who’s simply trying to say “Hello”; it’s irrelevant, all I personally care about is what they’ve got to say. Is it supposed to portray the company in an intelligent, professional manner? (These people want my title, they obviously mean business!) I don’t know, but it needs to stop.

I personally am a lot less inclined to fill out a form if it feels like an interrogation. Contact forms should consist of me entering my name, some form of contact information and my brain-dump - nothing else!

Fairly standard form

Suggested form

I know which one I’d prefer.

Using Internet Explorer’s conditional comments for targeted JavaScript

The demise of CSS hacks, something which has been covered elsewhere to no end, definitely a good thing, but not what I’m covering here - not directly anyway. I’ve been wondering if we can take advantage of this new age of “hack segregation”.

The way I see it is we’re already breaking the rule of separation by using conditional comments in the structure, so why don’t we cease this opportunity to save our friends (users of Firefox, Safari, Opera etc…) some bandwidth by providing IE specific JavaScript in the same way too?

For those wondering what I could mean by “IE specific JavaScript”, an example would be simulating the CSS focus pseudo class on form elements - something highly recommended for an accessible and usable form - which aren’t implemented in the market standard versions of Internet Explorer (6 and below).

I don’t think users of compliant browsers should be punished by downloading extraneous scripts, loading events into the queue and then spending time evaluating code that doesn’t even apply to them.

I’m proposing that we devote a section of the page head tag to Internet Explorer, that’s simply a conditional comment section that contains any style sheets and script blocks that only apply to IE.

Example 1 (what we are doing)

<!--[if lt IE 7]>
<link rel="stylesheet" type="text/css" href="/css/ie-specific.css" />
<![endif]-->
<script type="text/javascript" src="/js/ie-specific.js"></script>
<script type="text/javascript">
    addEvent(window, 'load', function() { if (document.all) { doIEStuff(); });
</script>

Example 2 (what we could be doing)

<!--[if lt IE 7]>
<link rel="stylesheet" type="text/css" href="/css/ie-specific.css" />
<script type="text/javascript" src="/js/ie-specific.js"></script>
<script type="text/javascript">
    addEvent(window, 'load', doIEStuff);
</script>
<![endif]-->

In Example 1 only Internet Explorer (prior to version 7) will download the stylesheet, but all browsers download the “ie-specific.js” JavaScript file and evaluate the addEvent code block. However if we follow Example 2, Internet Explorer will download the JavaScript and CSS just like normal, but other browsers simply see the whole section as a standard html comment and thus won’t download anything or evaluate the code block.

Wonderful, eh? I feel more comfortable with this approach than using questionable browser detection methods in JavaScript and it also reinforces (by just a tiny little bit) that compliant browsers are faster than their non-compliant brethren.