Could Your Forms be Smarter?
Credit Card Type
The type of credit card can be inferred from the first digit of a valid number - so why do most sites still ask the user to select the card type? I think for many sites (certainly the ones I've developed given the budgets I work with) it is a matter of a lack of thought. Thinking about it further though does raise some questions. Without a drop down list of card types, you need to find another mechanism to advise users whether you accept Amex and Discover or just MC and Visa. Users are also habituated to having to select a card type, so a little bit of Javascript to display the appropriate logo after the card number is entered would be a nice visual way to handle that confusion.
I'm tempted to move towards inferring card types with a simple list stating "We accept . . . " with logos before the form, and with one of the logos appearing after the card number for users with Javascript enabled. Any thoughts on other downsides of such an approach? Anyone doing this already? Thoughts? Experiences?
City and State
The next point raised by the article was that the city and state (in the US) can be easily inferred from a ZIP code, so why bother asking for them? One suggestion was that you could then validate the city/state against and ZIP code, although from my experience very few websites do this (try misspelling your city name and see how many sites tell you it doesn't match the zip!). Another issue of course is the confusion it could cause for users who are wondering where to enter their city and state.
Any thoughts on whether this is a good/bad idea?
Other Examples?
What else do we ask for that we don't really need? Any other ideas on improving the utility of common forms?
One of the areas in his PDF presentation talks about primary and secondary actions. Recently, he went into more detail about that on his blog. You can read about it here: http://www.lukew.com/resources/articles/PSactions....
Great resources - thanks! Working through them now. I'd kinda hoped to avoid all this front end stuff, but it's worth taking te time to figure out and implement best practices. Will get there, and then we should speak some more!
As for credit cards, we never prompt the user/customer/visitor/whateveryouwanttocallthem to select a card type - it's pointless and can be inferred from the first digit of the card number if absolutely necessary. We've never found it necessary, so whether that convention holds 100% true I don't know for sure.
Dear lord I need coffee.
@Steve, Good point and one I was thinking of. See:
http://www.pbell.com/index.cfm/2007/9/7/Handling-I...
Any input appreciated (after you've got your coffee of course ->).
I developed a site once where we implemented address 'verification' via UPS. It was a PITA. We got so many calls from clients who were confused when asked to pick a 'correct' address. This was a site that catered to an older crowd. I think you would certainly need to consider your audience when designing outside the 'norm'.
From a development perspective, is it worth the extra time and effort needed to develop your JavaScript solution to dynamically display the logo of the correct card over just having a simple set of radio buttons or a select list? Yes, it would be cool, but is the client paying for cool?
Consider also that it really only takes a few moments to add a CC type selection to the form, and you could go ahead and ignore this data on the server. On the other hand, how much time and money is wasted by the customer service department having to field calls from confused customers who may think that the form is broken or incomplete because fields they expect are missing (and keep in mind someone with JavaScript disabled wouldn't know that the card type had been determined.) The confusion would be even greater for forms that leave off city and state. An important aspect of good design is keeping things user-centric and going along with the user's expectations, even if we happen to think that they are a bit silly.
@Jim, I certainly think that'd be too much. I was just hoping to save the entry of city and state.
@Rob, Processing time might be an issue - very god point. Bear in mind though I'm planning to write once and reuse so the cost to a given client for the feature would be nominal.
@Chuck, VERY good point, although I guess if the city and state were editable, that'd help.
Hmm, does sound like there are some pretty good reasons not to do this . . .
The same applies to typing in credit cards. 16 digits is still 16 digits, whether it has spaces or "-"'s in it.
I agree 100%. I always offer a single box with plenty of space and ReReplace any non-numeric character with "" so I end up with a string of numerics which I can then validate based on length, etc. I then have display rules so if you want to display all phone numbers with (xxx) xxx xxxx or whatever you can set that display rule in one view helper and it uses that site-wide.
@Kurt, Yep. That seems to be the reason to consider the drop down as it is much more explicit that just a list of logos (which you'd think would be more visible, but which lots of users seem to not see). Definitely an interesting balance . . .