To make it easier for those users to use an OpenID, JanRain — the company behind the OpenID libraries for different platforms — created a widget called ID Selector, where the users have to choose their OpenID provider and enter the user name part of their OpenID. So they do not have to remember the complete URL. Here a screenshot of how it looks like:

You can see it in action on https://www.idselector.com/user/login.

The integration of the widget into a login form is easy: insert the provided JavaScript snippet into your code and set the id of the input field for the OpenID to “openid_identifier”. That’s it.

A “disadvantage” of ID Selector is that there will be ads (even though I haven’t seen any while testing), something you may not want…

The usual approach is to have a drop-down box filled with all countries. That’s easily implemented: get a list of all countries from somewhere and put them into the drop-down box. To select a country with this solution, the user has to select the drop-down box and either scroll to the country or enter the first letters of the country, e.g. for Switzerland you would have to enter “s”, “w”, and “i”. That means it often requires more effort to select a country than entering directly the ISO 3166-1 country code into a two-character input field…

The previous solution can be improved without much effort by putting the most used countries at the top of the drop-down box. Which countries that are depends on the focus of your site (and your site statistics). If you have for example a german site, most of your users will be from Germany, Austria, and Switzerland. By putting those countries at the top of the list you will make the country selection easier for the majority of your users.

The best solution would be, of course, a “convention over configuration” approach where the site automatically selects the correct country (at least in most cases). The implementation of such a solution requires a bit more effort on the side of the programmer as you have to determine the country somehow (e.g. by using a web service like hostip.info), but on the other hand it will make the life of most of your users a little bit easier :)

That’s when I realized it could be a usability issue. And that the “user interface” of the component is simply not understood by the users… Anyway, this post is not about possible problems of the Auth component.

What I want to talk about is, as the title says, usability-driven development. If you hear “usability”, you probably associate it with user interfaces and how people interact with them. And so usability-driven development will probably deal with making better user interfaces. That’s correct. But it is not about user interfaces like web pages, it is about “user interfaces” of code components.

I know, it sounds a bit strange. But on an abstract level you can look at the public attributes and methods plus the comments as the user interface of a code component. And the programmer, who uses the component, interacts with this user interface. You may imagine a component as a beverage vending machine: methods are buttons, method names are the button labels, and comments are descriptions of the buttons. I know, this thought model is a bit inaccurate, as parameters and attributes are missing. But it shouldn’t matter.

By doing some thought experiments with our imaginary beverage vending machine we can come up with the following conclusions:

• too many descriptions suck as nobody likes to read much before he can use something
• good button labels help to avoid unnecessary descriptions
• too many buttons suck as it makes it harder to find the desired button
• the order of buttons matters as it is faster to find the desired button when the buttons are ordered
• as it is a beverage vending machine it shouldn’t provide food

These conclusions can be easily translated back to code. By doing this we will see that a lot of code is not optimal from a usability point of view…

To get more concrete results (e.g. whether two methods without parameters are better than a single method with a parameter) we could introduce some metrics into our thought model, e.g. the time it takes to accomplish something.

Ok, what can you do to improve the usability of your code?

I think the most important point is to get a mindset that your code components are user interfaces for others and that you want to provide a good user experience to them. So you will design your components differently (compare it with the iPod vs. traditional MP3 players).

It is also a good idea to follow good coding practices like testing and refactoring.

And last, but not least, you could do usability tests. Give your component to someone else who never used it and let him accomplish a task while you watch. It may give you some good insights into what sucks with your component ;-)

Ok, I hope it was not too confusing. And maybe you will now look differently at your code ;-)

I have one of those lists you will find in almost every application which lists the items the user entered. Now it should be possible to move these items to two different categories. How could this be solved?

The easiest solution would be to add two links to the end of each row. But how do you name those links? “Move to Category A” and “Move to Category B”? Hm, that takes too much space and it looks ugly if you have to repeat it on all rows.

The next idea is to use icons instead of text. But this causes a similar problem as above. How should the icons look so people understand them?

Another idea is to put a checkbox in front of each row and to have a select box with the possible actions at the top and/or the bottom of the list. The problem here is that the user has to click at least three times to move an item.

What about a drag and drop solution? Well, drag and drop is not very intuitive, and it is difficult to visualize that an object is draggable.

Maybe we could add a select box to the end of each row? Well, it is still two clicks for the user. Can we reduce it somehow to a one-click action?

We could add a link to the end of each row and then on a mouse over event we show the possible actions. So with only one click the user can move a list item to the desired category. With that I have found the solution for the problem described at the beginning of this post. Here the visualization of this idea which I called “expandable link”:

The first image shows simply a link, and the second shows what happens on a mouse over event on this link.

Up to now I didn’t test this solution in the wild so I cannot say how it will be accepted by the users, but if they are like me, they will find it cool ;-)