Comments for Maximus Internet http://www.maximusinternet.com/blog Internet Strategy | Websites | Search | Email Thu, 27 Aug 2009 17:07:04 +0000 http://wordpress.org/?v=2.9.2 hourly 1 Comment on 4 Problems to Avoid with Web-Based Forms by jminder http://www.maximusinternet.com/blog/index.php/2009/08/4-problems-to-avoid-with-web-based-forms/comment-page-1/#comment-18 jminder Thu, 27 Aug 2009 17:07:04 +0000 http://www.maximusinternet.com/blog/?p=29#comment-18 It's important to note that Nielsen's March post is not a blanket endorsement of all drop-downs, only jumbo navigation menus. In this case, that may not apply. It’s important to note that Nielsen’s March post is not a blanket endorsement of all drop-downs, only jumbo navigation menus. In this case, that may not apply.

]]> Comment on 4 Problems to Avoid with Web-Based Forms by socialamigo http://www.maximusinternet.com/blog/index.php/2009/08/4-problems-to-avoid-with-web-based-forms/comment-page-1/#comment-9 socialamigo Fri, 14 Aug 2009 13:34:25 +0000 http://www.maximusinternet.com/blog/?p=29#comment-9 I've done quite a bit of form creation and form redesign in the past two years. Biggest mistake to make is to decide that the development team/ programmers will know what to do. My experience is they simply scrape up a form in their library and drop it into place. As a consequence, I've seen forms returned that include Chad and the Marshall Islands for a company that doesn't ship outside the US under any circumstance. A side issue with these lists is that most websites, not the hyper-global types, reach predominantly local markets - set-up the forms so that things like state-name and country name are already in the box and the user can change it if they need to. Also, most forms suffer remarkably for what they do upon submitting the form - nothing or barely anything - meaning: who among us hasn't submitted a form and waited for the next step only to find a small red line of text appearing within the form somewhere thanking us for submitting the form. Pushing the user to a formalized thank you page is good for SEO/ Analytics, gives the user a sense of execution and success, and, if designed properly, gives the user a chance to continue on by giving them new paths to explore the website. As for the DROP-DOWN MENU question, I'm with all of you: necessary evil, but to be avoided at all cost for SEO-friendly design. But jminder needs to update his archives on Jakob Neilsen's viewpoint on drop-down menus - see this Alertbox article from March 23, 2009 - http://bit.ly/Jakob-does-menus I’ve done quite a bit of form creation and form redesign in the past two years. Biggest mistake to make is to decide that the development team/ programmers will know what to do. My experience is they simply scrape up a form in their library and drop it into place. As a consequence, I’ve seen forms returned that include Chad and the Marshall Islands for a company that doesn’t ship outside the US under any circumstance. A side issue with these lists is that most websites, not the hyper-global types, reach predominantly local markets – set-up the forms so that things like state-name and country name are already in the box and the user can change it if they need to.

Also, most forms suffer remarkably for what they do upon submitting the form – nothing or barely anything – meaning: who among us hasn’t submitted a form and waited for the next step only to find a small red line of text appearing within the form somewhere thanking us for submitting the form. Pushing the user to a formalized thank you page is good for SEO/ Analytics, gives the user a sense of execution and success, and, if designed properly, gives the user a chance to continue on by giving them new paths to explore the website.

As for the DROP-DOWN MENU question, I’m with all of you: necessary evil, but to be avoided at all cost for SEO-friendly design. But jminder needs to update his archives on Jakob Neilsen’s viewpoint on drop-down menus – see this Alertbox article from March 23, 2009 – http://bit.ly/Jakob-does-menus

]]> Comment on 4 Problems to Avoid with Web-Based Forms by jminder http://www.maximusinternet.com/blog/index.php/2009/08/4-problems-to-avoid-with-web-based-forms/comment-page-1/#comment-7 jminder Wed, 12 Aug 2009 16:45:59 +0000 http://www.maximusinternet.com/blog/?p=29#comment-7 I can't agree with the toilet example. This is more along the lines of one intersection in an entire city where the lights go from green to red, with no yellow. I do agree that forms should be easier and in theory, should automatically advance from one field to the next, but it goes against a very entrenched behavior. It's a difficult problem to fix! I can’t agree with the toilet example. This is more along the lines of one intersection in an entire city where the lights go from green to red, with no yellow. I do agree that forms should be easier and in theory, should automatically advance from one field to the next, but it goes against a very entrenched behavior. It’s a difficult problem to fix!

]]> Comment on 4 Problems to Avoid with Web-Based Forms by Kevin Jacobs http://www.maximusinternet.com/blog/index.php/2009/08/4-problems-to-avoid-with-web-based-forms/comment-page-1/#comment-6 Kevin Jacobs Wed, 12 Aug 2009 08:33:44 +0000 http://www.maximusinternet.com/blog/?p=29#comment-6 Just stumbled upon your site. How do I get high search ratings on google? Love the insight on usability. thx. Just stumbled upon your site. How do I get high search ratings on google? Love the insight on usability. thx.

]]> Comment on 4 Problems to Avoid with Web-Based Forms by Jacob Valley http://www.maximusinternet.com/blog/index.php/2009/08/4-problems-to-avoid-with-web-based-forms/comment-page-1/#comment-5 Jacob Valley Wed, 12 Aug 2009 08:18:59 +0000 http://www.maximusinternet.com/blog/?p=29#comment-5 I enjoy the auto-populating forms such as ATT's phone fields. I like it when fields auto populate and advance to the next field. We all need to adapt to change. I was a little nervous when the toilet flushed before I hit the handle, but overall I've grown to get used to it even after 35 years of flushing (bad example but still tech advances) I think technology advances in small bits and if we can't embrace the little changes like auto-populating fields, then we are not embracing technology as a whole. http://www.vb123.com/Toolshed/02_access/lookups.htm I enjoy the auto-populating forms such as ATT’s phone fields. I like it when fields auto populate and advance to the next field. We all need to adapt to change. I was a little nervous when the toilet flushed before I hit the handle, but overall I’ve grown to get used to it even after 35 years of flushing (bad example but still tech advances) I think technology advances in small bits and if we can’t embrace the little changes like auto-populating fields, then we are not embracing technology as a whole.

http://www.vb123.com/Toolshed/02_access/lookups.htm

]]> Comment on 4 Problems to Avoid with Web-Based Forms by Reggie Mastic http://www.maximusinternet.com/blog/index.php/2009/08/4-problems-to-avoid-with-web-based-forms/comment-page-1/#comment-4 Reggie Mastic Wed, 12 Aug 2009 07:30:41 +0000 http://www.maximusinternet.com/blog/?p=29#comment-4 This reminds me of a story from a previous job. The state drop down was actually missing 'Nebraska' and had been missing it since launch (at least a year) before an end user from Nebraska finally notified us... Oops! This reminds me of a story from a previous job.

The state drop down was actually missing ‘Nebraska’ and had been missing it since launch (at least a year) before an end user from Nebraska finally notified us… Oops!

]]> Comment on 4 Problems to Avoid with Web-Based Forms by Steve Green http://www.maximusinternet.com/blog/index.php/2009/08/4-problems-to-avoid-with-web-based-forms/comment-page-1/#comment-3 Steve Green Tue, 11 Aug 2009 18:49:08 +0000 http://www.maximusinternet.com/blog/?p=29#comment-3 Unnecessary data validation rules. For instance why do some websites not let you put spaces in credit card numbers or telephone numbers? They can strip them out server-side if they want, but the ability to enter spaces helps me ensure the data has been entered correctly. Likewise with date fields. Why enforce the use of particular delimiters when you could allow pretty much any symbol - forward slash, backslash, hyphen, space etc. and strip it out or convert it server-side. And why throw an error when the user enters ddmmyy instead of ddmmyyyy or whatever format you want. I've seen a site that allowed UK and US date formats, mm and mmm, yy and yyyy and it just worked out what the date was in the format it needed. It only threw an error if the date was ambiguous. That's a design pattern that everyone should use. Unnecessary data validation rules. For instance why do some websites not let you put spaces in credit card numbers or telephone numbers? They can strip them out server-side if they want, but the ability to enter spaces helps me ensure the data has been entered correctly.

Likewise with date fields. Why enforce the use of particular delimiters when you could allow pretty much any symbol – forward slash, backslash, hyphen, space etc. and strip it out or convert it server-side.

And why throw an error when the user enters ddmmyy instead of ddmmyyyy or whatever format you want. I’ve seen a site that allowed UK and US date formats, mm and mmm, yy and yyyy and it just worked out what the date was in the format it needed. It only threw an error if the date was ambiguous. That’s a design pattern that everyone should use.

]]> Comment on 4 Problems to Avoid with Web-Based Forms by jminder http://www.maximusinternet.com/blog/index.php/2009/08/4-problems-to-avoid-with-web-based-forms/comment-page-1/#comment-2 jminder Tue, 11 Aug 2009 06:21:42 +0000 http://www.maximusinternet.com/blog/?p=29#comment-2 Great technical points. I will say that I have implemented type-in state fields on websites that have not had significant accuracy problems. I would argue that a user is more likely to make an error entering their street address than a two letter state code, so it is always wise to run USPS address verification if your website can support it. Great technical points. I will say that I have implemented type-in state fields on websites that have not had significant accuracy problems. I would argue that a user is more likely to make an error entering their street address than a two letter state code, so it is always wise to run USPS address verification if your website can support it.

]]> Comment on 4 Problems to Avoid with Web-Based Forms by Shannon Maas http://www.maximusinternet.com/blog/index.php/2009/08/4-problems-to-avoid-with-web-based-forms/comment-page-1/#comment-1 Shannon Maas Tue, 11 Aug 2009 05:26:48 +0000 http://www.maximusinternet.com/blog/?p=29#comment-1 DropDowns: Unfortunately these are a necessary evil. Users are unpredictable and unfortunately it is often necessary to design against bad data. Data is often transferred between many integrated systems and must be in the expected format. The most efficient way to guarantee this is drop down menus. Example: When you enter your billing address into an ecommerce site that address is likely stored at the site itself, it is also passed onto the credit card processing company and usually also passed onto third party tax software. Each of these locations expect your state to be VALID and in the appropriate format. It is much more efficient to offer a drop down of valid choices rather than allow an end user to enter their state as "AA" or some other bogus abbreviate. Yes, it is possible to take the invalid value of "AA" and validate it against the internal database of valid state codes but this scenario will incur a round trip to the server and a call to the database which is resource intensive. Therefore it is cleaner and more resource efficient to hit the database and server once on page load, populate a dropdown and skip a later validation step. Additionally have you seen the devastation that can be caused by user entered data on sites that do not have the budget to manage security but still have excellent services to offer? Can you say “Drop Table”? SQL injection is quite nasty. DropDowns: Unfortunately these are a necessary evil. Users are unpredictable and unfortunately it is often necessary to design against bad data. Data is often transferred between many integrated systems and must be in the expected format. The most efficient way to guarantee this is drop down menus. Example: When you enter your billing address into an ecommerce site that address is likely stored at the site itself, it is also passed onto the credit card processing company and usually also passed onto third party tax software. Each of these locations expect your state to be VALID and in the appropriate format. It is much more efficient to offer a drop down of valid choices rather than allow an end user to enter their state as “AA” or some other bogus abbreviate. Yes, it is possible to take the invalid value of “AA” and validate it against the internal database of valid state codes but this scenario will incur a round trip to the server and a call to the database which is resource intensive. Therefore it is cleaner and more resource efficient to hit the database and server once on page load, populate a dropdown and skip a later validation step. Additionally have you seen the devastation that can be caused by user entered data on sites that do not have the budget to manage security but still have excellent services to offer? Can you say “Drop Table”? SQL injection is quite nasty.

]]>