Categories
user experience

Form Errors – Validating phone numbers and the importance of hand testing

Nothing replaces hand testing forms

I fill out a lot of forms during the day, some on existing sites and others as new internal forms that need review. When testing I have a habit of submitting forms with every error combination possible. I know there are automated tools for this but nothing beats seeing it from the users prospective. It is different to run a command line tool and get a number of fails and successes as it is to spend 2 minutes to fill in a bunch of fields and get some weird screen state, odd colors or wording that doesn’t make sense.

That is exactly what is happening above. I clearly filled out the form to my best understanding and still got an error.

Things I notice about this error:

  1. There is something wrong with these three fields, but it doesn’t point out which one(s)
  2. The wording of the error forces me to look up and then scan down to see where the field is
  3. In my mind I did place the area code in the phone field
  4. There is no explanation of the preferred format for the phone number

After understanding that my method isn’t working and they were not going to automatically transform my format to their preferred format I tried every phone number combination I could think of. In the end none of them worked. Being the curious person I am I ended up digging through their validation javascript and found this regular expression it was validating against:

^((\\(\\d{3}\\) ?)|(\\d{3}[-\\s]))?\\d{3}[-\\s]\\d{4}$

Doing a little more investigation I found that it didn’t work at all. Try every combination you can think of at: http://j.mp/9sIWEn

Good error messages should include:

  1. A summary at the top of the page of all the errors (long forms usually push the user back to the top of the page)
  2. A highlight around each field with an error
  3. An explanation with an example or clear direction where the visitor went wrong
  4. Not be nit-picky about formatting, transform as much as possible automatically

In the end I brought this issue up to Groupon and they fixed it within an hour. The issue was not with their code, but on the survey vendor’s site. It got me thinking about the time and effort the user has gone through to get to this point and end up confronted with a road block. These small things have the potential to be a huge turn off for the average user. Command line tools may be great but nothing replaces what you can learn by testing things by hand.

* Note, that is not my real phone number 😉

Categories
main

Back to basics, focusing on essentials

Old School v New School

So I decided it was time to update the look of my site. I knew I needed more room for content, code snippets just don’t fit in 300 pixels. This update was primarily inspired by my recent decision to move from Palm to Blackberry.

Back to basics, getting rid of the clutter and flare, my site is not here to sell a product but instead teach ideas and present research. One thing the Blackberry does that Palm lacks is the back to basics text driven menus and single application screen and single method of traversing the phone.

The Palm reminds me of Java, over the years it has grown to try to fit everyones needs without realigning or saying no to features which only fit one category of customer. Clunky interfaces and random restarts often happen because of the lack of integration.

In addition to the actual functionality improvements the screen on the BB is a tiny bit smaller but RIM has way better font support and smoothing so making the text quite small increases the amount of text on the screen by 25% over the Palm. I didn’t make my text size any smaller but what I did was increase the space for each entry and went to a fully em controlled layout for more flexibility.

Realigning the content with the right column in my mind was the best decision of the realign, before all my “personal” data was scattered at the top, left and bottom. I decided to concentrate it all on the right column to a clear separation from the article and personal items.

Another thing that bothered me about SimpleLog is that it did not natively validate. The Archives and Search page had some terrible nesting issues. Diving into the core code I changed these to produce a better POSH structured site. Before I was experimenting with the Blueprint CSS framework, well lets just say it was thrown out the window in this version, way too much overhead and not enough benefit.

The design will transform as time goes on as all things but as of right now straightforward is in and I am sticking to it.

Categories
main

Road to validation.

Overseeing the current Wayne State University homepage is like running with a tiny pebble in your shoe. You feel it every step but your going so fast you cannot stop to take it out.

Working with a site so large it can become discouraging but taking one step at a time one can accomplish anything. Yesterday we took our first step, moving the site to a new server in an environment that we are comfortable and flexible in.

The old version of the site was sitting on an NT box, a requirement of the company who built it over 4 years ago. When I started I had a few goals, one was to get the site off that server and get it validated and rewritten in POSH. Well that day has come and we managed to sprinkle in a few other goodies along the way, here are some highlights:

It took some work to get here but we made it. There is still some tweaking to go but all in all its setup. Now its time to concentrate on the content, we are going to be doing a page by page overhaul and adding greater functionality and layout to each child page.

In addition to the content we will also be shrinking the file size and HTTP requests further and further down to the base minimum. Right now we are ~90k depending on the panel that loads and 16 HTTP requests with an empty cache, we hope to cut the size down by a third and get rid of 2-4 requests.

Stay tuned for more progress.

Categories
main

Popular sites and their lack of validation

W3C Twitter InvalidLaunching a new site got me exploring some new code bases and I became disappointed with the disregard large social sites have for html validation of snippets they disburse to their user community.

Since I wanted my site plain and simple to start instead of writing a bunch of code to use common API’s I decided to first go with includes and badges from sites I commonly use. The three that I experienced while creating this site astonished me on their lack of attention to detail. At least they are trying to be compliant but unfortunately they are not fully committed yet.

Twitter HTML Badge

Twitter offers a nice super customizable HTML badge to include on a site. Which is great because it is a basic div, header and unsorted list and style is up to you. Placing the code they supply on your site makes it no longer validate. On their script tag they use an invalid parameter “text”. This looks like a typo and something simple to fix but where is the quality control? Shouldn’t someone test these types of things before they are rolled to production?

<div id="twitter_div">
<h2 class="twitter-title">Twitter Updates</h2>
<ul id="twitter_update_list"></ul></div>
<script type="text/javascript" src...
<script text="text/javascript" src...

Flickr Flash Badge

Flickr offers two types of badges the HTML one does surprisingly well except they do not escape the ampersands in the src of the script tag but that is something that can easily be done by the user.

<div id="flickr_badge_uber_wrapper">...
<script .. src="...?count=3&display=random&size=s&layout=x...
</div></div>

The flash version on the other hand includes an html page into an iframe but unfortunately the code in their html appears to have also been skipped by quality control. It has two main issues. Script and style sheets above the head of the document and non escaped characters in an html string that is outputted via document.write().

<!DOCTYPE ...
<html>
<script type="text/javascript" src="/javascript/fpi.js"></script>
<style type="text/css">
body {margin:0; padding:0; background-color:#fff}
</style>
<head>
<title>Untitled</title>
</head>
<body>
...
...
zg_html = '<OBJECT classid=.../getflashplayer"></EMBED></OBJECT>';
...

SimpleLog Archive Page

SimpleLog Archive NestingRails applications have been known for their agility and standards. It takes more than just a script kiddie to get a rails application into production. So when I installed and started to customize SimpleLog 2.0.2 for my site something stuck out like a soar thumb, the archives page in the default theme did not validate. There are two options for the html, an unsorted list or definition list. Neither of them are nested correctly which makes it almost impossible to apply a consistent style across browsers.

Without re-writing the entire helper for my site I just put some extra li elements in the output and cut it down to just one missing li. I have not had time to checkout the SVN trunk and create a patch.

Final Thoughts

By far the number of pages that do not validate outweigh the ones that do on the web but it is a shame to see small agile companies acting like large corporations when it comes to quality control. One of the benefits of having a small group or an open source application is the amount to time and attention each piece can get before it is released for peer review. It was put best in Jason’s A collection of details post when he quotes Wil Shipley:

“This is all your app is: a collection of tiny details.”

Web standards need to be enforced by the community and it is our job as web professionals to validate our own code and when possible give some helpful hints to other developers or companies who are not taking the appropriate amount of time to validate. I put in a ticket with twitter about the “text” element and in the process of creating a patch for SimpleLog’s archive page. I encourage all developers to run with standards and not be afraid to send an email or two to promote the health of the web. Who knows you could send that one simple email that turns thousands of pages valid.