Card sorting is an easy way to help organize larger quantities of content into a meaningful structure. The right time to do it is when you’re ready to start organizing the information. The objective is to discover an intuitive and meaningful classification for topics by asking some prospective users of the system — in our intranet example, this would be a group of company employees — to organize the information in a manner that makes sense to them. We do this by writing the name of each topic onto a card, shuffling the deck, and then asking a user or a group of users to sort the cards into groups according to broad subject areas. As the users sort the cards, you observe, ask questions, and take notes.

Card sorting tests can be broadly organized into two types: in an open card sorting exercise, your users will invent their own groups, give them a name, and sort cards into each. In a closed exercise, you specify the groups for them and the users sort the cards. If you’re fairly sure of the groupings you’d like to use on the site, or if your client has already specified a broad set of topics, a closed test is the right choice for you. If you’re unsure, perhaps an open test is better.

Running a card sorting exercise is quite fun, and it’s probably easier than you think. Let’s look at how to run your own card sorting exercise.

Step 1: Identify Your Topics

You’ll first need to identify what’s going to be part of your site. If you’re working on a site that already exists, it’s a matter of pulling out the pages that you have and listing each; if the site is new, list each page that you plan to include. If your site is quite large or very detailed, try to stick to higher-level topics for now. There’s no sense overwhelming your poor test subjects with five hundred cards! You can always run more card sorting tests later for subsections of your site.

Step 2: Make Some Cards

Each topic needs a card. It’s easy to do this on a computer: simply fire up your favorite word processor, look into the templates section for a business card or mailing label format, and fill in a series of cards with the name of each topic. Then, print the cards on card stock and chop them up with scissors. Feeling more lo-fi? Grab a stack of small index cards or a pad of sticky notes, and pull out your favorite marker. (You should probably stick to the computer if you have messy handwriting!)

If you plan to run a closed test, make some cards for each broad grouping. It can help to make these bigger or in a different color so that they’re distinct from the other cards. It’s a good idea to cut out some blank cards, too. During the test, a user might think of a topic that ought to be included.

Step 3: Find Some Test Participants

You’ll need to find some people to sort the cards. In our intranet example, we’re using company employees: I’d ask their managers for a bit of their time, and maybe put on a small afternoon tea as a treat for the participants afterwards. For a public web site, you might like to recruit some strangers with the promise of a free coffee or a voucher for a juice. Try asking about at a nearby library, university, or coffee shop for volunteers, or even put the word out on Twitter for nearby tweeters.

While it’s possible to run a card sorting exercise with individuals, you might also like to try it in pairs or threes. When people work together to organize cards, you can observe the kinds of discussions they’re having while they’re trying to decide which cards belong where. Individuals, on the other hand, will probably keep that information to themselves, and you’ll have to ask them to think out loud.

How many participants do you need? Jakob Nielsen suggests you ought to have at least 15 individual participants, while Donna Spencer and Todd Warfel suggest just five tests with groups of three. Bearing in mind that this is a quick-and-dirty method, I’d be inclined to pick the latter — it’s a good trade-off in terms of time and numbers.

By now, you’ll have an idea of where you plan to run the test. You should have access to a reasonably quiet room that’s well-lit, with a large table and enough seating for you and your participants. This is probably easy if you or your clients have an office; otherwise, perhaps that cafe has a quieter side room you could use.

When you invite your participants, be sure to let them know how long you suspect it will take, and explain what the activity will be like.

Step 4: Run the Test

Let’s do it!

Mix up your deck of cards and put them on the table. If you’re using a closed test, put the topic cards out onto the table as well, along with the blank cards and pens. Grab some water or juice, a pen and paper for you, and sit down with the participants. Explain the goal of the exercise — it’s good to remind them that it’s not a test or an assessment of their ability, just an exercise to help you make your web site better. Let them know that you’ll be taking notes throughout, and invite them to ask questions during the process if they have them. Then, hand them the cards and let them have at it!

If you’re working with a pair or group of people, keep an eye out for individuals who like to dominate the conversation or those who stay quiet, and try to ensure that everyone has a say; it’s as easy as saying, “Bob, what do you think?”. If you’re working with a lone participant, encourage them to discuss their decisions out loud with you. This is tricky, as most of us try to avoid mumbling to ourselves, but it’s worth the effort as you’ll gain some great insights into why that participant makes those decisions.

Take note of interesting ideas people discuss throughout the test. It’s unnecessary to jot down every card as it goes into the pile (we’ll do that later), but it’s good to note any places where the participants might have become stuck or confused.

If a participant thinks that there’s a missing topic or a better name for a topic, use one of your blank cards to add it into the mix. It’s probably a good idea to use a different-colored pen or mark it somehow so that you remember it’s a new suggestion.

Step 5: After the Test

Fire up your favorite spreadsheet application and mark down each of the cards that went into each pile (tedious, but worth it!). I like to make a column for each grouping and list each card name underneath; it’s also good to use a new sheet in a workbook for each test. Add any notes that you might have taken during the test. When you’ve copied each pile into its own column, shuffle the cards again, set up your table, and test your next set of participants.

Step 6: Interpret the Results

Just by observing your participants, you should already have some ideas about the way your pages ought to be organized, but it’s also worth examining each of your spreadsheets to look for patterns and similarities. Unambiguous topics will almost certainly have been placed in the same pile by each participant; some more difficult topics may have appeared in different groups, or users might have suggested better names.

If you really need to be able to point to percentages and hard statistics, try this free spreadsheet by Donna Spencer; by following the instructions that come with the template, you’ll be able to see patterns emerge at a glance.

The More You Know

By now, you should have a fairly good idea of what topic groupings your users will find to be intuitive. Use this data while you’re designing your information architecture, and live happy in the knowledge that you have a more solid idea of what your users really need!

Web-based Card-sorting Tools

In a big hurry? No time for cards and Sharpies? Try online services like WebSort or OptimalSort. While this lacks the hands-on, personal feel of seeing these users work on your cards in person, it’s quite a bit less effort.

And if you want to run a test in person but still save the trees, try this jQuery-driven web-based card sorter. Using this template, add categories and cards that suit your topic, pull it up on your trusty laptop, and allow your participants to drag the cards around. This one is an extremely bare-bones affair, but it’s easy to add your own CSS to make it prettier!

Last week Rich Gossweiler, Maryam Kamvar and Shumeet Baluja from Google research published their latest ideas on the subject entitled ‘Socially Adjusted CAPTCHAs‘.

A white paper explains the idea in detail but the concept is simple enough. Users are shown a circular-cut picture that is rotated to random, non-standard angle. They are then asked to rotate the image back to it’s correct orientation.

As humans who have evolved to quickly process visual information on the real world, we’re all born with very good software for determining which way is up. Computers, however, are currently nowhere near as skilled at making sense of a potentially wildly varying array of images. You only have to look at the comparatively plodding movements of Honda’s Asimo robot or robot soccer to understand just how taxing a task this can be for a machine.

Obviously the method shares some characteristics with other image-based CAPTCHA methods (i.e. such as the ‘How many kittens do you see?’ method) but has one major advantage. Where other methods require humans to write new tests (i.e. ‘How many .. um.. goldfish?..’), fresh Socially Adjusted CAPTCHA tests can be easily automatically generated by a machine, but not as easily solved by one.

If you consider classic alphanumeric CAPTCHA methodology, a bot only has try to match around 40 characters to any given glyph — albeit a distorted glyph. Image orientation is powered by an almost limitless pool of feeder images, taken from wildly varying subject matter, aspects and angles. Sure, writing a bot that searches for horizons and perpendicular lines would be reasonable start but it will only get you so far (as the examples show).

Now, this is certainly no home run. It’s no improvement for the vision-impaired. Similarly, motor-impaired users may well know which way they’d like to orientate the image, but may struggle with the physical process of re-orientating the image. Perhaps great interface design can negate this problem.

There has also been some criticism that the method offers no protection against spammers who employ cheap human labor to crack CAPTCHAs.

However, as I see it, this is an unfair call as it falls outside of CAPTCHA’s working brief — to sort the humans from the bots. Sorting good users from mischievous users is an entirely different class of problem.

So, what do you think? Would you be tempted to replace your alphanumeric CAPTCHAs with something like this?

Yesterday I clicked through to an anti-Twitter rant on MISAustralia.com (ironically via a retweet). While you can make your own call on the content, the thing that really caught my eye was the body font. Why on earth would a large, professional content site choose to display their content in an ugly, unreadable monospaced font?

Absented-mindedly I drag-selected some of the text and got another surprise — a pretty, checkerboard pattern on the selection area.

Hmmm… interesting. What’s going on here?…

Viewing the source, my jaw nearly hit the desk.

The insane scientists at MISAustralia appear to have built a content management system that automatically shuffles each paragraph into two piles, letter by letter.

Each pile is then dumped into its own DIV and padded out with non-breaking spaces, before they are precisely overlayed with each other to make them readable again.

Of course, this means copy-and-pasting the text ONLY touches the uppermost DIV, and explains both the zebra patterning and their choice of mono-spaced font.

Clearly their motivation is Digital Rights Management (DRM) by making it more difficult to copy-and-paste or screen scrape their content. In fact, their HTML source commenting refers to it as a ‘DRM Viewer’.

This seems astonishing to me on so many levels.

1. Firstly it makes their content present as utter gobbledygook to screen readers and other assistive technologies. I am not a lawyer, but I’d suspect there’s the basis of a robust discrimination law suit in there.
2. Secondly, it makes their content unreadable in any RSS reader and prevents them even offering an RSS feed.
3. Thirdly, it necessitates the use of font that further erodes the value of their content.
4. Finally, and most importantly, it makes their body copy (i.e. the heart and soul of their site and business) completely invisible to Google, Yahoo and every other search engine on the planet.

That last point is mindboggling to me.

An entire industry (SEO) has evolved for no other reason than to ensure Google sees and values your content. Companies live or die on their ability to make their content visible. Here is a company going to great time, effort and expense to actively obscure their work from the web’s largest traffic provider.

As far as Google is concerned, this isn’t just lowly rated content, it is ‘non-content’. It simply doesn’t exist. It was never written.

As a quick example, take this recent article Nine loses EPG battle.

Search Google for the non-DRMed article title and it comes up first. Perfect! Google clearly knows and visits them.

However, let’s step inside the article and search for a highly specific phrase, “Ice TV general manager Matt Kossatz said the ruling was timely”.

Result: Nothing. Blip. Nothing to see here, people, move along.

Of course that’s no surprise. How WOULD Google know what it was looking at?

I’m not even going to start with the huge accessibility issues for fear of turning this into a 10 page post.

The Final Irony

Now, if this was a foolproof solution to their copyright dilemmas it’s still highly debatable whether it’s worthwhile inconveniencing 99.99% of your everyday readers to stop the .01% of your visitors that are infringers.

Unfortunately this DRM is anything but foolproof.

Anyone running Greasemonkey and the MISaustralia text selector userscript (Hats off to Gustav Axelsson) can not only cut-and-paste their little hearts out, but they get to read it in a comparatively luxurious Verdana, Arial, or Helvetica typeface.

In fact, if you’re a Firefox user who reads this site, you’d be almost silly NOT to use this script, just for readability reasons.

Equally, writing an application that automatically parsed and republished every new article elsewhere would be just as trivial. And the cool bit is they don’t even have to compete with the original authors. They would ‘own’ that content as far as Google was concerned.

Now these guys are part of a large, generally, tech-savvy company (Fairfax).

Is this nuts?

This situation is all too common, and the root cause often lies in the basics. Even a very small component of the site can have a dramatic effect on the user experience!

For example, if the login process itself is delivering a poor experience, then people will be reluctant to use it, and all of those killer features you added will be in vain. In the worst case, it could be discouraging people from logging back into the site at all, which means no community, no repeat sales … all of this adds up to a failed site.

So What Went Wrong?

Most of the time the problems in a web site or web application are very simple things. Still, even small problems can equate to a negative experience. And you really don’t want any negative experience if you can help it. Users are sensitive, you know!

It’s true that some people will buckle down and try to work around any usability issues they’re encountering—we all love problem solving, right? It’s in our nature. But don’t forget that as the Web becomes easier to use, people are becoming less tolerant of bad interaction design and will often seek out an alternative service if it offers a better experience, depending on how much they have invested in your site.

It’s Simple … Yet It’s Not

Login interaction design is simple on the surface. There are, however, quite a number of elements that contribute to the final design considerations for a user login page. When they’re all combined, things can quickly get complicated. Here’s a sample of the factors to consider:

• Security
• Previous user experience
• Site legacy procedures
• Internal business processes
• Page interface design
• Audience platform considerations

You can probably think of a few more factors to add to that list. Regardless, there are still some simple things that we can focus on to ensure that the experience is a good one. Here’s my list of tips for making sure your users keep coming back and logging in.

1. Use email addresses for usernames

Studies have shown that people have enough trouble remembering their passwords, without them having to recall a username as well. Using a string that people are more likely to remember, like an email address, reduces the chance of the user forgetting their login details even further.

The convention for a web site’s username to take the form of an email address nominated by the user is becoming more and more established. Sure, there can be issues with the approach of using an email address as a username, such as:

• Some service providers recycling email addresses
• Users changing their name, and their email address as a result
• Email addresses taking different formats

However, none of these issues are insurmountable—just be sure to allow (and test) for the different scenarios listed above.

The common alternative of forcing users to log in using a membership number (or some other username that is allocated to them) does not help at all. If you must use something other than an email address for your web site’s usernames, at least let your users personalise their account somewhat by creating their own username to use on your site.

2. Let Your Users Use Long Passwords

In this new age, we are constantly being reminded to use passwords that are secure. You know the drill—the longer the better; the more special characters the better …

With the advent of password-memorising plugins and browsers that automatically fill in usernames and passwords, one might expect that the average length of a password fields on today’s web applications would be getting longer and able to accept passwords that are 64, 128, even 256 characters long. One might even hope that the days of eight-character passwords were rapidly disappearing!

And indeed this shift to accepting long passwords is occurring. However we’re not there yet, and seem to be in a transition period.

Note that there can be problems when the text field for accepting a username or password is not the same length as the corresponding database field in which it is stored. This can result in the truncation of the password that the user entered, or even worse, in the entire record being completely unaccessible. If you offer long passwords, be sure to test them!

As an interesting side note, banks in general refrain from allowing passwords that contain special characters or passwords that are over 12 characters in length. This limitation is usually due to the limitations of the legacy systems with which they interact, not their web services. Most web services are not bound by such restraints—don’t follow the old model.

The solution is simple—plan to allow long passwords from the start. By getting it right in the design documentation, ensuring you define the length of the passwords, and testing for this upper limit, you should be able avoid any hurdles related to your password length.

Also be sure to inform user, at least during the registration process, exactly what the minimum and maximum password length is that your system allows. This should be implemented using a text message located next to the field in question. Users will not be aware of details like this unless you tell them about it!

3. Add some Ajax to your Form Validation

We are not all perfect—sometimes we mistype usernames and passwords. So do our users.

Of course, a password entered by a user needs to match exactly before we grant that user access, for security reasons.

However, let’s ease up a bit on the usernames. For instance, if the username was an email address, it would be nice as a user to know if I’ve accidentally typed “.con” instead of “.com”. It would even be nicer if this warning was provided before the form was submitted!

In this situation, a little Ajax-style validation can go a long way. Checking the username to determine whether it is unique or in the right format makes things a little easier.

Another factor to consider when it comes to validation is what might happen should the user enter an extra space or two after their username. You see, this whitespace is not going to be obvious on the screen to the user, but in reality they have entered an invalid username, as it contains extra spaces at the end.

This hurdle is simple to overcome—just trim the username field. You can perform this trim either on the client side or the server side (both is better). The important thing is to build some intelligence into your form validation, and make some simple, educated guesses at what the user intended their username to be.

4. Maintain Persistent Logins

There used to be a time when you could log in to a web application and remain logged in until you logged out! Remember those days? Isn’t that what the “Remember me” or “Keep me signed in” checkboxes were for? Sure, those web apps that offered this feature were not critical services like online banking or share trading sites. But boy was it convenient!

That feature seems to have gone out the window lately. These days the “Remember me” checkbox only means “remember me for a short period of time”. There is a distinct trend developing lately whereby web applications require you to log in again after one week, two weeks, or some other arbitrary time period.

These time-limited persistent logins are of course a security measure, but they only apply to the computer being used. So if the computer is in fact located in a secure environment, the time-limitation offers no benefit to the user, and is inconvenient. It becomes annoying having to login again and again to a web application that you‘d rather use seamlessly.

Informing users how long their login will last for certainly helps manage expectations in this situation, but it doesn’t make the process of having to log in again every two weeks any less convenient.

A better approach would be to allow the user to control the period of time that the persistent login is good for. By giving the user control over this setting, we can keep everyone happy. A user who only ever access the web site from their home computer might set their login to “forever”, whereas another user who accesses the same service from a library or internet café might set it to “never”. After all, the login details belong to the user (as does the data that they access with it), so surely our users are intelligent enough to make this decision?

5. Keep your Text Fields Close Together

Placing a username field and its associated password field on a separate page is a practice that I encourage—having a dedicated “login” page is much less confusing than integrating the login process into another page, especially if that page contains other forms and text fields.

But how should our username and password fields be aligned? There are two main schools of thought—side-by-side and on top of each other.

The important thing is to ensure that the two fields are within close proximity of each other—remember, they are related in terms of information and functionality, after all. They should therefore be related spatially as well.

Login pages can be problematic when the username and password are not located next to each other on the screen (believe it or not, I’ve seen this happen by up to a third of the page!) The area between a username field and a password field is no place for a big banner ad! Keep these two fields next to each other to reduce confusion.

It’s a minor problem, but making your user hunt around for the fields they need to use to log in, and raising doubts in their mind over whether they’ve entered their login information into the correct field—especially if they’re already further down the page—doesn’t really fill a user with much confidence about the web application.

6. Keep your Login Link at the Top

Just as users have come to expect that clicking a web site’s logo will lead them back to home page of the site, many users these days expect to see a link to the login page located at the top of the page (often on the right hand side).

Placing your login link elsewhere can result in visitors playing the “hunt for the login” game, which won’t help your cause. Sure, users of your application will become accustomed to where it is. however, when a new user is most vulnerable to frustrations (and will often make a lasting opinion of your site) is based on their first few experiences with your site, before they learn where various features reside. You only have a short window, so you want these experiences to be positive.

7. Label your Login Links

As you may have noticed, there are many established conventions when it comes to the login process, and the login label is no exception. The exact text that many visitors are likely to be looking for is either “login” or “sign in”. There are multiple variations, but these two words are almost universally understood, so are pretty safe options to use.

Unfortunately, there are web sites out there today (not naming any names!) that see fit to use unique labels to mean “log in”. In the worst cases, the link is given a label like “opportunity” or “recommendations” or even “new features”—none of which have anything to do with logging in. When users see a link in the location where they expect the login to be they begin questioning whether the link is an advert, and what the page behind that link might be selling.

It can be difficult arguing the case when the marketing department are insisting that the login link be labelled something new or different. If you can’t win that battle, one compromise might be to add the marketing link in addition to a more standard login link. The confusion created by two links pointing to the same page is going to be less than that created by messing with a more standard link that visitors are expecting to find.

8. Let users retrieve forgotten usernames and passwords

Another convention that has become standard to provide a link for users to reset or recover a forgotten password, and to list this functionality on the same page as the login form.

However it can be a little distracting displaying this feature on the login page before a user has entered any information at all. It’s almost like taunting them by saying “Come on—I just know you’re going to make an error!”
It’s easy to fix—only display the link to your password recovery solution after a user makes an error logging in.. A little JavaScript that alters the text-indent property of the paragraph containing this link is all that is needed.
Another scenario to account for is when a user can’t even recall the email address that they used as a username. What should you do in this case?

This is easy enough to deal with—you already have that information available already, via your forgotten password functionality.

The error message displayed by the password recovery process is usually sufficient information for the user to determine whether he has entered the right username or not. For example, if the error reads, “No users have registered with that email address,” then your user will immediately know that the email he entered was not the right one.

There are, of course, other fallbacks that you can offer—secret questions, personal information about the user, and more. However, for most sites, a simple password recovery process is sufficient.

9. Display Helpful Error Messages

Error messages are notoriously problematic on the web—and in software in general. Yes, it’s important to inform your users when an error has occurred, but there’s no need to bamboozle them with technical jargon (nor should you be giving away more information than is necessary, in case the person reading the error message is a malicious hacker attempting to compromise your system).

Of course, there is the other end of the spectrum too—not giving the user enough information. Suppose you just wanted to log in to your favourite social bookmarking service. It’s not Fort Knox—people are not going to live or die based on your user knowing that they entered their email address incorrectly, so let them know. They’ll appreciate it much more than a terse message that tells them nothing and leaves them in the dark.

There is an art to writing helpful error messages—it sounds like I’m stating the obvious, but make them as clear as possible. Depending on the content delivery style, and the amount of freedom you have with the brand, you should try and engage with the user on a personal level.

For example, “Invalid authorisation” is robotic and confusing. “You seem to have typed in the wrong password” is a much more friendly way of saying the same thing.

For non-mission critical, low volume applications, you might even consider improving the user experience by going the extra mile and letting the user know which part of the username/password pair they entered incorrectly.
Finally (and this is really Usability 101), don’t insult people. Matthew Magain wrote about this on SitePoint previously, in relation to Reddit’s error messages. Remember: users aren’t stupid, they’re just human. Just like you and me, they make mistakes, and they’re often in a hurry. Allow for that the human errors that will inevitably occur.

10. Use Extra Questions with Caution

Including an additional question to authenticate a web user has become a popular method for applications that require higher levels of security, such as internet banking sites.

The question of whether this extra level of authentication is really necessary must be asked though—it may be possible to obtain this degree of confidence in the user’s authenticity another way (using an approach that requires additional server-side development).

Some examples include SMS code conformation, smart tokens and smart card confirmation (for extranet connections), enforcement of a stricter password policy, or the activation of extra questions only when an account is being accessed from a different computer to the user’s designated machine.

If you must ask your users additional questions, please consider using a question/answer format that is accessibile via a keyboard (i.e. doesn’t rely solely on a mouse).

Which brings me to CAPTCHAs. There is no shortage of people with personal hatreds for CAPTCHA systems. If you must use a CAPTCHA, do everything you can to make it as accessible as possible. CAPTCHAs are the exception to the rule in that they are better off located on the same page as the username and password fields.

11. Keep your Page Weight Down

Does your web application login page really need to have all those buttons and graphics that exist across the rest of your site? Think about it—the core function of your login page is as a transition to the main site. Your user wants to make use of the page, and then move away from it again as quickly as possible. Adding anything but the very basics in navigation and branding is going to slow the page down for your users.

Remember, not everyone is using a T1 connection to surf the Web. If a page simply takes too long to load, the user will start to ask questions like “Should I just do this later?” or “Is this worth doing at all?” If that user has a similar experience several times then she’ll start looking for alternative sites to visit instead.

Reducing page weight can often be very simple to do (just don’t tell the marketing guys!) Look at the page, and identify what can be classified as core to the use of the page on the site and still makes the page looks like it belongs. Remove the rest—sometimes this may even include part of the extended navigation system.
Of course this advice is irrelevant if your login process uses a JavaScript popup window.

12. A Word on OpenID

Hang on—what’s with this Number 12? Well, kids, think of it as a Christmas bonus for the holidays. Seriously though, the topic of logins would be incomplete without a little discussion on OpenID.
Many of you have no doubt been thinking while reading through this list that a good deal of these issues could be solved by using OpenID.

Now a debate about OpenID is off topic, but basically my point of view is that OpenID is just too hard for the non-tech community to use.

There I said it. It’s out. Whew, that feels better!

The paradigm of using a URL for a login is just too far removed from the expected behaviour experienced bv the general majority of people. Given a choice, most folks will fall back on the traditional method of providing a username/password pair—even if it does meaning that they will have more logins.

This will change over time. My hope is that one day OpenID will indeed become mainstream. But until some of the bigger players jump on board and allow interchangeable OpenID use, I would recommend against making OpenID the only way that users can access your web application.

Keep it Simple

Improving the login experience comes down to making the entire process simple for the user. Granted, achieving this goal means more work for the design specification, implementation and development of your web application. But what is building web sites really all about? The sweat and tears of the design/development team, or the satisfaction of the customer?

At the end of the day, it’s the customer who is paying the bills.

Never, ever, insult your users.

Unless your web site revolves around insults, and every error message consists of a purposefully engineered insult for humorous reasons, treating your users with disdain or disrespect is a huge no-no.

Earlier today I decided to sign up for reddit, the popular social bookmarking service. My experience has turned me right off the service. Here’s my rant:

1. The CAPTCHA

First, I clicked Submit Link, and was presented with an option to register.

I’m personally not a huge fan of CAPTCHAs, for many reasons (there are alternatives, but there’s no panacea), but I do empathise with why people put them in place. Unlike someone who has poor eyesight, I can usually read the letters, and it’s usually only once that I need to type them in, so we’ll let that slide for now. And at least the letters in reddit’s CAPTCHA are relatively easy to decipher compared with others that I’ve seen in use … right?

Wrong.

2. The Insult

Here’s what I was presented with after clicking the Create Account button:

Apparently those letters weren’t as easy to decipher as I thought! Here’s the clincher though — not only was my attempt at passing the CAPTCHA unsuccessful, but I was insulted for my trouble!

3. The Déjà vu

Once I’d managed to endure a second CAPTCHA and finally registered, I thought that would be the end of it. But no! I was immediately presented with another CAPTCHA that I needed to pass in order to actually submit a link.

After having already been insulted, this made me really grumpy. Proving that I’m a human is annoying and somewhat degrading, so getting me to jump through that hoop a second time is downright rude. But, like I said, at least the letters displayed in the CAPTCHA were reasonable easy to decipher, right? (Ahem!)

At this stage my only thought is “If I’m going to be asked to do this every time I submit a link, I’m going to be turned off the service pretty quickly … especially if I’m going to be insulted some more every time I get it wrong.”

4. The false accusation

Hooray, so I passed the CAPTCHA. But wait — I’ve been presented with another hurdle!

This infuriated me. Too fast? What does that mean? This was the first link I’d ever submitted. Was I meant to type more slowly or something?

I’m assuming this is a bug, and should only be presented if a user tries to submit too many links in a given period (which I didn’t). But that aside, even if this had been my second link, why should I be prevented from submitting something within a certain period if I’ve already proven I’m human?

Thoroughly peeved, I went off to lunch and left the submission page in my browser, to tackle when I got back. If I could be bothered.

5. More Insults

Back from lunch, and I’ve tried again — only to receive more insults for my trouble (note the CAPTCHA image changed after it rejected my attempt, hence the discrepancy below).

Argh! Apparently I still can’t read (cos you know, it’s clearly my fault … honestly, can anyone tell me what I’m missing with these damn CAPTCHAs?).

At this point, I decided to pack up and leave. I’d experienced enough friction (and been insulted and falsely accused too many times) to decide that reddit was not worth my trouble.

Am I being too harsh? Is it reasonable to pick on one site when no doubt there are plenty of usability issues that need addressing with our own site? (although we certainly don’t insult any of our customers!) Should I have approached reddit privately first before posting in a public forum about it? Maybe. I figured they’re big enough that they can probably take it.

To be honest, though, I’m more interested in hearing your horror stories with signup processes and CAPTCHAs … does it get any worse?

reddit have just announced that they’re open sourcing their code. Good news, I guess — now anyone can try to fix this terrible state of affairs for them…

Sifting through the notes I took last Friday, here are some snippets that I jotted down from another speaker whose talk I got a lot out of — Steve Baty, who spoke about Analysing User Research Data.

Steve managed to introduce a number of quite scary and complex looking statistical formulae, without having his audience drift off to sleep or turn and run for the exit. Being passionate about his chosen field and a charismatic presenter certainly helped matters. Perhaps it’s just because, with his glasses off, he looks like Charlie (David Krumholtz) from Numb3rs, which probably reinforced his credibility in my mind.

The takeaway that I got from Steve’s talk is that user research data is useless unless you do something with it, and that “something” needs to be well-defined before you collect it. He advocated

• defining the level of precision that you’ll be measuring up front
• taking into account the mean, variance and standard deviation of your sample data, and
• taking dual sets of data, so that you can compare them to determine whether deviations in your data are because of the design you’re testing, or because of the differences between users in your test group

Steve recommended approaches when interpreting data from A/B testing, task completion rates, time-to-completion and page view data, and his heavily scientific approach to usability testing reinforced the term “user science” (most of us are probably guilty of taking an approach that is more indicative of “user art”).

The podcasts and slides from both Web Directions UX and Web Directions Government will be appearing on the conference site’s blog soon. Go check them out!

It was a chilly start to the day with the temperature hovering just above zero degrees as we waited in the dining area of Old Parliament House, cups of coffee in hand, listening to people who’d attended the breakfast session tell us how good Jason Ryan’s presentation had been. Jason is currently Communications Manager at the State Services Commission in New Zealand and presented on “Government 2.0: The public management challenge”. Unfortunately I didn’t get a chance to meet Jason however I did talk with one of his colleagues at the State Services Commission Rowan Smith who is involved with the New Zealand Government Web Standards project.

At 9:00am John Allsopp opened the conference and talked about how the focus of these conferences has expanded and is no longer about accessibility and other technical low-level issues. Although these are still as relevant and important now as 5 years ago the adoption and integration of best practice in those areas has reached a point where can move onto the next big thing, which for this conference was eGovernment: how government communications and collaborates online internally, with other agencies and with the public and citizens as well as the delivery of services online. He emphasised that we, the participants and active members in the web industry, are key in driving that change and moving towards having two-way communication between the government and the citizens that government serves.

José Manuel Alonso from the W3C on eGovernment standards

The first presenter for the day was José Manuel Alonso, eGovernment Lead at the Worldwide Web Consortium (W3C), working out of the W3C’s office in Spain. José covered in detail many aspects of the technical challenges with deploying government services and information over the web. He quoted research that stated 29% of people would prefer to communicate with the government via the Internet but that more needs to be done, including improving the content and design of government websites.

José talked about the interoperability framework, open standards and the fact that even transferring data between systems using XML even if using similar or identical schema models may not be enough. He explained that in Europe there are some interlingual issues with differences of meaning and interpretation of words so even if organisations in separate countries agreed on a single XML schema that there may still be confusion or differences of interpretation of shared information.

He then discredited the idea of one-stop shops and cited a report that in 2007 searches for five top news stories in Google rated blogs higher than the New York Times, showing the change in how people find and access information. José also quoted Brian Humphrey and Ron Myers of the Los Angeles Fire Department (LAFD) who said “We can no longer afford to work at the speed of government. We have responsibilities to the public to move the information as quickly as possible so that they can make key decisions”. If you can’t do something useful with your data and information, put it somewhere where someone else can! He then listed a few examples of both organisation collaboration with third parties as well as third parties transforming and mashing up data and information, including the Library of Congress’ project with flickr, USPOT’s Peer Reviewed Prior Art project, FixMyStreet, Follow the Money, MapLight, OpenCongress, GovTrack and TheyWorkForYou (after José’s presentation I went and let him know that Australia now has a soon-to-be-launched version of TheyWorkForYou called OpenAustralia).

He finished off his presentation by looking at some of the challenges and opportunities with mash-ups and sharing data such as privacy and security, semantic technologies, linked data such as RSS and RDF and the importance of ensuring and guaranteeing the authority of data, and don’t forget about developing for the mobile platform!

The W3C has an eGovernment proposal out to its membership for review, which concluded today — the results of that review should be known within a couple of weeks and if (as is expected) the W3C membership give the green light to the W3C’s eGovernment initiative then an Interest Group will be set up shortly to start looking at this in more detail and look at establish standards around eGovernment.

Finally, José stated that eventually the “e” should be removed from eGovernment — once web services become an integral part of government and no longer treated as an optional add-on but a core component of how government operates, communicates and provides services. That’s what we’re aiming for.

Jenny Telford the Australian Bureau of Statistics on opening government data

The next presentation was by Jenny Telford, Director of Products and Services from the Australian Bureau of Statistics (ABS) who went through in some detail the work that the Bureau has done over the last few years and the transition from (can you believe it) charging people to access Census data online to the situation today where they have a number of tools, reports and data formats available with some quite powerful data extraction configuration capabilities.

One of the reporting functions available allows advanced users to access and aggregate individual “units” of Census data. Although no names and addresses are exposed the ability to aggregate data and compare with other sources could potentially allow people to get access to private information so they’ve had to employ some advanced algorithms to protect people’s privacy.

She admitted the Bureau still has a way to go with further opening data, increasing geospatial reporting capabilities and looking at their copyright and intellectual property (IP) protection policy. Currently there is a 500 cell limit on some reports as a rudimentary means of preventing large-scale collection of data — a measure she admits needs to be looked at.

Some of the questions asked after Jenny’s presentation included the culture shift of Generation Y and growing indifference about the disclosure of personal information and how this might be reflected in future Censuses, as well as questions about utilising communities to validate and augment information in the Bureau’s databases.

Ralph Douglas from GovDex

Ralph was next with a brief 25 minute presentation on GovDex (which I missed half of as I was talking to Amit from the W3C Canberra office about getting involved in the Consortium’s eGovernment Interest Group). GovDex is a government-run secure (classified as IN-CONFIDENCE, with plans to have a PROTECTED version by the end of the year) online collaboration tool which allows internal, cross-departmental and government-community groups to connect and share ideas online using a wiki facility and a member registration/information database. Unfortunately the presentation was a bit light-on and dry; I didn’t get much out of it, although the application looked like it could be useful.

Lisa Herrod from Scenario Seven on usability

Lisa Herrod’s presented on usability “More than skin deep” — a presentation I’d seen before at last year’s Web Directions South conference in Sydney, but nonetheless just as good the second time around with practical ideas on how to take a holistic approach to usability, how it ties into the code and accessibility, how automated accessibility compliance checks are not enough and the idea of an Accessibility User Profile as part of your persona development. Considering people with disabilities as a primary user group ensures their requirements are considered throughout the development of a website rather than a feeble and rushed attempt to retrofit a finished site for WCAG compliance at the end of the project.

Matthew Hodgson from SMSMT on social computing

Matthew was up next to talk about social computing in government, a really good presentation that started with a story of a project he was involved with some time ago to introduce a wiki in an unnamed government department. The aim was to enable collaboration between different sections within the department with an aim to address serious knowledge sharing and efficiency issues that the wiki implementation group he was involved with had identified. Unfortunately once senior management found out about the wiki and that sections of the department weren’t going through the proper channels to have information approved and signed-off for dissemination (even just internally) the wiki was shut down.

He likened some organisations to Darth Vader — the need for control, to lock down everything. Why would average people know what information they want? He also provided an interesting statistic: that 100 million hours of knowledge have gone into Wikipedia … the same number of hours that Americans collectively spend watching TV commercials every weekend! If only people put their time to better use in contributing to global knowledge through collaboration projects like Wikipedia or productive and problem-solving projects like Appropedia, the sustainability wiki.

People are social creatures — they need to have that social need met and there are ways of meeting that need in a work context (Matthew referred to Maslow’s Hierarchy of Needs) — it’s not about wasting time socialising with friends. Communities and networks aren’t necessarily geographic — if they were then you would communicate face-to-face with those in your network (like we were at the conference). However for people who’s networks are based around an interest or otherwise then the fact that those networks function online doesn’t take away the fact there still needs to be a social element to those interactions.

Robert Hoekman Jr. from Miskeeto on usability and minimalist design

The final presentation for the day was by Robert Hoekman Jr. all the way from Phoenix, Arizona, who opened with a declaration that there are still a lot of awful sites out on the web — sites that make users feel dumb, unable to quickly and intuitively figure out how to use a web interface and how sites have all these features crammed into them that doesn’t make them better, it just makes them more complicated to use and learn.

His classic line was “Understand users, then ignore them” — going on to explain that you need to understand users’ needs but that people don’t always know what they want or say things that don’t truly represent how they might use something in a real-life situation. He used an example of a fast food chain that introduced a lo-carb cheeseburger which during user research sounded like it would be quite popular but when put on the menu didn’t do to well at all. Sites need to support an activity or range of activities, not the audience types. Your user research should determine the essential requirements of your users but not over-scrutinise your users and attempt to cater for the needs of every single possible user type.

Robert then talked about minimalist design — building only what is absolutely necessary: “Once you start putting real glass windows in your tree house, you’ve lost the point of what a tree house is meant to be”. Ever get sick of using a hammer? A hammer has a well-defined purpose and you are unlikely to pick up a hammer expecting it to do something else, which also means the hammer never disappoints because it does exactly what it was designed to do — and nothing more.

He referred to a couple of case studies including the WordPress home page and Squidoo website and how changes to the page design to make it simpler and more obvious had real, measurable effects on site usage.

He gave some further good one-liners of advice including “Turn beginners into intermediates. Immediately” (referring to how sites should be intuitive to use and immediately empower the user), “Design for uniformity, consistency and meaning” and “Reduce, reduce, reduce and refine” … including only what elements are necessary and having conscious decisions behind the placement of every aspect and feature on a page.

Finally …

John then took the stage to wrap up the conference, again thanking the sponsors of Web Directions South Government 2008 including SitePoint and the presenters. I asked a few people for their thoughts on the conference and the response was positive, although several said they were expecting more of a government focus — an opinion I shared, although it was hard to get out of anybody exactly what being more government focussed might entail. Afterwards I discussed this further with Maxine (one of the conference organisers) and concluded that people want more emphasis on the context of government; the particular and peculiar challenges of working in a strong hierarchy with decades of embedded top-heavy culture, procedure and culture, the wariness of innovation and especially social computing. This could be incorporated into the conference through more case studies of government projects and more presentations by people who actually have experience working inside government who can relate to the pain felt by those “on the inside” trying to do good work, building accessible and usable websites, applying best practice in design, user research and testing.

Of the four presentations I missed out on I had a chance to speak with Scott Gledhill and David Hayward afterwards to get a synopsis of their presentations. Scott’s was a follow-on from the article he had published in the Digital Web Magazine on Corporate Web Standards and the sad reality (or interesting challenge) of implementing web standards in an environment where time and efficiency are the priority. David presented on exploiting geospatial data, using a case study of the development of the NSW Government’s Spatial Information eXchange SIX Gateway site.

All in all though, another great Web Directions conference organised and run by John, Maxine and the crew which will inspire me (and I hope others) for many days to come.

For more information about the conference, program and speakers go to the Web Directions South Government 2008 website.

The core message of Andy’s presentation was that other industries have long understood the importance of a positive user experience, and the Web can learn a lot from this.

His presentation gave lots of tips, with plenty of rich examples:

1. First impressions count: Hoteliers understand this, hence good hotels offer smiling greeters in the lobby, chocolates and written notes on your pillow.
2. Attention to detail gets noticed: Apple are a company that realize the difference that attention to detail can make — consider the effort that has been put into the packaging of their products, which results in customers actually photographing the unboxing of their iPod. From the sound of the door closing on a new BMW to the rubbish bins at Disney theme parks being themed, people notice this stuff.
3. Personalisation and customisation matters: Starbucks allows its customers to customise their coffees, and the Nintendo Wii and other games let users create their own characters. Second life takes this to a new level to accommodate people’s needs to assert their individuality. For web developers, something as simple as welcoming people by using their first name can have an enormously positive impact on their experience on your site.
4. Dripfeed your information: Andy reference computer games as a huge source of inspiration for him, and showed a video of a combat game that taught players how to perform tasks incrementally. By gradually releasing information about how to perform tasks in digestable chunks, you can avoid overwhelming them. As an example, Basecamp displays optional videos for new features, and the Yahoo! site utilised a lightbox to explain new features when they launched their redesign last year.
5. Take care of the mundane: Andy referenced the hospitality industry heavily when making this point — the doorman hailing you a cab, the waiter filling your glass when you don’t notice, and the barmaid remembering your drink are all great examples of what makes a positive user experience in one moment, which can carry the user through to a positive experience throughout their entire visit. Web analogies include taking care of unnecessary tasks for users by prefilling them with intelligent defaults.
6. Make it fun: Andy showed an example of a drink package that had the text “Stop looking at my bottom” on the underside of the container. Little touches like this obviously require the right context and a bit of thought to do properly, but when they work they can make your users smile for the rest of the day. Another example was a personalized email from MOO, which read “Hi, I’m little MOO, the software that will be managing your order…” A banking site might not get away with being this cute, but it’s definitely possibly to be playful without being unprofessional.
7. Feedback is important: Poker machines are feedback-heavy — they emit a “bling” sound, and the cleverly crafted “ding” of coin as it hits the metal tray causes other punters to take notice, sit down and try using a machine themselves. Likewise, a button always lights up in an elevator — if it doesn’t then you might wonder whether the lift is broken or not! Status bars and other indicators to let a user know where in the process they are presently located help manage expectations and keep the user engaged.
8. Recommendations are powerful: last.fm is a good example of how recommending music to a user is a terrific service that really adds value. If you can provide contextual information to your users that taps into the knowledge that the entire user base has created, then your users will pay attention.
9. Users love competitions: By offering a competitive element — whether that be through scores and a leaderboard, or just by letting people “collect” things — badges, blog posts etc — your userbase will have an additional reason to return to your site and engage with your data. Leaderboards can have a negative effect too, of course — the digg leaderboard stopped being a useful indicator when those users at the top started posting quality over quantity, in order to maintain their position on the leaderboard.

These experiences can be plotted as a user experience curve — an actual graph that, while subjective, shows a user’s positive and negative experience over time. Andy mentioned Maslow’s hierarchy of needs as applied to the Web. The items in the hierarchy were:

1. functional
2. reliable
3. usable
4. convenient
5. pleasurable
6. meaningful

I agree with Andy’s comment that it is very rare that a user experience on the Web meets those levels of experience at the top of the hierarchy (pleasurable, meaningful experiences). He encouraged attendees to look to other industries, and other areas in the offline world for inspiration to bring positive user experiences to the Web.

Three members of Team SitePoint are wandering around at the conference, so feel free to come up and say hi!

Photo credit: Dave Shea

I’m not here to do that. The news is 5 days old and I have no intention of clogging up your RSS by regurgitating the same content… as important as it is.

What I do want to highlight is that there are a number of WCAG 2 requirements at risk.

It is important to note that some WCAG 2.0 requirements are at risk; that is, they may not be included if there are not sufficient implementations [By 30 June 2008].
- Web Accessibility Initiative Interest Group mail list

Get Involved

I would urge you to take a look at each of the At Risk requirements to see if there are any relevant to your area of expertise that you are able to implement over the next couple of months. Alternatively, there may be someone with complementary skills that requires your assistance in implementing one of the at risk requirements.

The primary purpose of this CR stage is for developers and designers to “test drive” WCAG 2.0 to demonstrate that WCAG 2.0 can be implemented in Web sites. WAI encourages a broad range of Web sites and Web applications to use WCAG 2.0 at this stage, and share implementation experience.
- Web Accessibility Initiative Interest Group mail list

As an example, I plan to submit an implementation for success criteria 1.2.6 Sign Language, I have expertise in this area but average video editing skills. In order to implement this effectively by the due date, I’ve had to find someone with video editing skills.

My plan is to provide and record Auslan interpreting at a couple of my upcoming conference presentations and then upload them to my site. Hopefully other local Deaf organisations will do the same.

Important Dates

So if you’re interested in a little bit of grass roots people power, jot down these dates, blog about it and see if you can get involved too.

23 May 2008 - Register your intent to provide implementations of WCAG 2 requirements.
30 June 2008 - Provide implementation experience to the WAI and/or comments on barrier to adoption of requirements.

Relevant Links

And finally, if you want to get involved, you may find these links helpful:

• Instructions for Implementors
• WCAG 2 Candidate Recommendation Implementation form
• Implementation Information Form

Let us know if you submit and implementation to WAI and we’ll talk about it some more here.

For the most part seminars and industry nights hosted by the Mobile Monday guys or AIMIA focus on marketing, advertising, gaming and identifying ways of further monetising the mobile industry. BORING. I’ve even stopped attending the Mobile Monday events because they appear to have such little interest in promoting any discussion around best practices or mobile accessibility.

Given that these are the two most prominent Australian industry groups hosting discussions on mobile technology at the moment, it seems pretty obvious that there’s little interest in this area for either group. Even the Web Standards Group has had very few mobile related events.

Mobile Means Mobility

Mobile use is at an all time high globally and it offers affordable access to the web for a huge proportion of people including many users with disabilities. It’s time for industry groups to get back on track and deliver informative sessions on how we can produce accessible, usable web content.

The W3C WAI Mobile pages provide links to a couple of documents that deal with mobile web accessibility and how we can better design and develop mobile sites for users with disabilities:

• The Web Content Accessibility Guidelines (WCAG) is a guide for making a Web site accessible to people with disabilities.
• The Mobile Web Best Practices (MWBP) is a guide for making a Web site usable from a mobile device.

There is also a great deal of information over at the Mobile Web Initiative Best Practices Working Group blog (MWI BPWG).

The Open Letter Initiative

This morning via my RSS I came across an article on a favourite blog of mine by iheni on The Open Letter Initiative (you may also know Henny from the Web Access Centre blog). The Open Letter Initiative, which commenced in November 2007, was spurred by Google’s announcement of the open mobile platform Android. The letter reads:

This open letter is addressed to companies from the mobile technologie (sic) sector, developers, research scientists, organisations, politicians and all kinds of disseminators (sic)as well. The open letter informs about the perfect mobile device for blind persons, screen reader software for mobile platforms, mobile internet access, satellite navigation for blind pedestrians, mobile access to map data, accuracy of GPS receivers, self-help, commonalities of blindness and dyslexia/illiteracy, accessibility, corporate responsibility, proposals for Nokia’s and Google’s public relations and the importance of free software and affordable cell phones for the many blind people from developing or newly industrializing countries.

What Do We Want? Discussion! When Do We Want It? Now!

What I’d really like to see is a lot more information presented by web community groups and industry nights that focus on accessibility issues for the mobile web. I don’t give a toss about what the latest Nokia is, or what cool data plan 3 is offering at the moment. I want presentations, discussions and tutorials. I want to hear real people talking about their experiences and I want us to do it now.

Of course the groups I’ve mentioned here are all Australian, and this is not an issue specific to us. Are other countries addressing this better than we are? I’d say so… but how?

Getting Started

Being from Australia means that I’m most aware of the local Australian industry groups you might contact here. But there are no doubt many more in your local area too. For those of you outside Australia, what are the best industry groups to contact? Let us know.

If you’re in Australia, you can contact any of the following organisations and tell them you want to see more discussion around mobile web accessibility:

• AIMIA
• Australian Web Industry Association
• Mobile Monday Local chapters listing
• WIPA
• WSG

All it takes is for us, the community, to speak more loudly. Contact the industry groups you’re involved with and tell them you want to know more. Better still, put something together and present it yourself. But don’t forget to let me know… I want to come along and see it!