Usability Notes - by Chris Baker

CAPTCHAs

CAPTCHAs are "Completely Automated Turing Test To Tell Computers and Humans Apart" - an automated test that humans should be able to pass but 'bots will struggle with. A common example is registration systems that require you to type out words that you see in distorted form in a box, like this example (generated by the reCaptcha program). I've been wondering what those were called....

reCaptcha have a website that provides a good introduction to captchas.

There's an obvious accessibility issue caused by these (if you can't see the distorted text, you can't complete the test of typing it out). In reCatcha's case, there is an alternative test as an attempt to deal with this - click the loudspeaker button to hear a sequence of numbers read out against some background noises, thereby creating an auditory equivalent of the "type these words captcha". You can also click the "refresh" icon on reCaptcha's interfacve to get new words, if the ones you see are too distorted. That would also help with my personal cause of stress when filling out these - being presented with words that have become ambiguous (e.g is it a 1 or an l? a 0 or an O? Is that letter upper- or lower-case? If i get the captcha wrong will I spend many minutes re-doing the data I have typed into the web page?).

The "stop spam read books" tag line in reCaptcha's UI refers to an interesting feature - the distorted words come from scanned literature (sensible because you presumably need such a large selection of words that the captcha can't be solved by guessing words or throwing a dictionary at it). reCaptcha use the typed user input not only for solving the captcha but to quality check the scans they have made of the literature, as part of an project to digitize it.

Sam Michael, who moderates an excellent set of email discussion lists from chinwag.com, has recently summarized a discussion about captchas, and added his own experiences, including this humorous "captcha gotcha", consequence of using words randomly culled from literature (for anyone unable to see the captcha, it came up with a couple of rude or unfortunate words...)

Sam's post about captchas also contains some other ideas about making it easier to tell whether a human or computer has submitted a web page:

• have an invisible field - humans won't see it and fill it out, but an automated script will. My thought about this is that you ought ot think about whether screen readers will see the field and prompt any blind users to fill it in, however
• require the web page to be open for a minimum time before submission, thereby foiling automated scripts that fill the page out much more quickly than a human could.

Cyclic Redundancy Check

Handling large files that arrive on CD, I have discovered that the error message from Windows:
Cannot copy example.zip: Data error (cyclic redundancy check)
...means fingerprints etc. on the disc.

My problems have been fixed by cleaning the disc

web colours

[In which I tell how I was caught out by an old "gotcha" and then go on to list useful resources  about choosing colours for websites.]

Yesterday I saw something I have not seen for a little while. We were sat around a monitor reviewing pages of a website. The design uses tinted background boxes to help break the pages into logical groups of controls and input fields, but these boxes were not showing up at all.

Our first thought was that recent changes to the stylesheet had broken this bit, but when we found that we COULD see the tints on another monitor we realized that the stylesheet was not to blame at all; it was the choice of background colour, whcih some monitors coudl not render.

Back in the past (the 1990s, say), we saw this kind of thing much more. Computer monitors could only manage a few colours, and a consensual set of 216 of them was created, called the web safe colors. (This article from W3C schools outlines the basics of web safe colors, gives some history, and is a good introduction.)  This limited palette  of web safe colours is still the safest bet for a website - pretty much any monitor will display them, showing them pretty much how you wanted (though with some difference in brilliance etc. due to the manufacture of different monitors, their age, the environment in which the monitor site and so on, let alone variations in customer's vision).

These days, of course, most monitors can display millions of different colours. So you would expect that a much wider range of colours would be OK (or most probably OK) to use. As far as I know, though, there is no updated guide to the colours that can be considered safe, and (as I found yesterday) you can still get a surprise if the designer has chosen a non web safe color and you look at the site on a different monitor.

In this case, we had not been so silly as to rely completely on the background tint to make the page make sense (among other things that would have been very poor accessibility), but the page without the tint was missing a useful visual cue. We've changed to a web safe color now, which is probably what we should have done in the first place.

This is probably a good place to introduce some sites I find useful when dealing with colours:

• The Visibone webmaster's color lab is the site I like for picking web safe colors.
• Aim media have a flash-based equivalent, which lets you see color schemes building up, and lets you enter Pantone colours (simply type in the pms code into the boxes labeled "RGB" or "Hex").
• A very useful colo(u)r scheme generator from wellstyled allows you to try out some different combinations of colours.
• This site from British Telecom has useful information about designing colour schemes that are usable by customers with various kinds of colour blindness or colour-deficient vision. Since about a twelfth of men have some kind  of colour-deficient vision and may struggle with your use of some colour schemes to re-inforce meaning, you ignore this stuff at your peril.
   
• Similarly, Visibone has simulations of how the web safe colors look to colour-blind people.

I did have links to sites that let you convert the pantone colour that your print colleagues  want into the nearest websafe color, but these sites are gone now (suggestions of a good one are welcome!). Being able to match to pantone is useful if you want to have the same colours in your websites and printed materials.

One final thought, which comes from an article on the pantone site called graphics - dare to go beyond web-safe colors. From the title, you can guess the author's stance on the issue. I'm not sure I agree with his idea that web safe colours are only relevant to those few customers who are still running a 256-colour monitor. But I like his idea of testing the colour scheme by taking your monitor and reducing the colour settings as much as you can*. Then check how your site looks. I doubt this is foolproof, but would expect it to be useful enough to be worth the few minutes it takes. Wish I'd thuoght of that.

While you have the control panel open, you might also want to try changing your screen resolution to experience the web site design at different screen sizes - that can be a shock too!

*To change color settings in Windows XP, find the Control Panel from the start menu; click Display; click the Settings tab and find the control that controls the number of colours. Make a note of how it is set at present so that you can put it back when done, then lower it as far as it can go (to "256 colors" if your monitor does this - my monitor won't go that low).

Lost pages - 404s

Recently I was working on a new new look for a website. Despite assurances that all the old pages would be redirected nicely, things went a little bit wrong it would seem, leaving us with a nice new website with some pages that were "404s" (404 is the code that  HTTP returns when a page does not exist, and often the customer will see a message in their browser that includes "404").  Obviously it is very bad news indeed if customers and search engines can't find your pages. All was sorted by the boys in the server room fairly quickly, but I did learn a few things:
Rather than have customers see a default 404 page provided by their browser, we quickly put in a  special page - this apologises for the inconvenience, and offers some navigation options that we hope will be helpful - the primary navigation tabs of the site are there and if this particular site had site search that would be there too. There are a couple of gotchas in doing this: It is important to return a true 404 to any visiting browser or search engine bot, so that any pages that really have been discontinued drop out of the search engine results. It seems like a good idea at first to redirect customers straight to, say the home page or the site map but this is not a good idea - if it is the site map or home page that is broken, customers go round and round in a loop.
Recently I saw an interesting refinement on this, when I got a 404 page from the Roxio site - not only do they offer an apology, but they also give you a code you can use to get a 10% discount on your next purchase.

 

It was interesting to see what different sites' 404 pages look like - if you want to see one, type a URL that cannot possibly be there like http://www.amazon.com/dontworryIjustwantto see your 404page

Obviously, I wanted to check we'd addressed all the broken links. A useful tool for doing this was Xenu's Link Sleuth This is a free piece of software (the author invites users to make a donation to his favourite cause). Given the URL of your home page, it follows all the links and reports on whether they work or have gone bad. It produces a useful report that you can also use to build a site map.

Phew, so after a while harmony restored and we were back where we thought we would be on launch day.