James Wilding's Weblog

I just read “Progress in Usability: Fast or Slow?” by Jakob Nielsen, and absolutely loved how he focused on the purpose of usability studies: finding out how easy it is for users to do what they want to do.

I’ve actually taken part in a few usability studies — as a participant, rather than a researcher — and what struck me looking back is how the tests focused on finding out whether users could easily do what the researchers wanted them to do. Basically, the researchers would make a list of the things they wanted a user to accomplish — making a booking, finding a contact form, performing a search — and would then test how easy it was for the participants in the test to perform those actions.

This is completely wrong.

What those researchers should have been doing is asking test participants what they wanted to do: usability tests should be framed in terms of “what do you want to do here”, not “how easily can you do what we want you to do here”. This makes tests much more open ended, but in the businesses in the real world don’t decide how people use their websites, and that sort of decision shouldn’t be made in usability tests either. Let the users decide; let the design follow.

Every so often, I read about how the internet is massively changing the way businesses and customers interact. Today I read a Guardian book review that explained how

“Networked markets are beginning to self-organise [...] People in networked markets have figured out that they get far better information and support from one another than from vendors.”

A lot of people think that the internet creates new forms of customer behaviour. I disagree: I think the internet primarily gives more emphasis to existing forms of behaviour.

Anyone who’s ever worked with small businesses will know that word of mouth is extremely important, and that customers will naturally organise themselves into ad-hoc groups which support individuals and offer a way for newcomers to get information on what the Guardian calls “vendors”.

If that sounds too theoretical, think about restaurants. You probably know a few friends who can offer restauarant reviews or suggest a new place to eat — even explain wine lingo if you’re new to that side of things. There’s your self-organising community: all the information and support you need.

Here’s the important point: you don’t have to go online for any of this. These customer communities have existed for hundreds of years: do we really believe that before the world went online, everyone just called up their local restaurant and said, “Hi. Are you good at cooking?”…?

The power of the internet is that it supports and encourages these communities, and in some cases makes them possible where they wouldn’t have been before. But the communties themselves aren’t new phenomena: there’s no magic here, just progress — old things appearing in new ways.

We really should be cautious about claims that the internet is changing the basic nature of business: it’s not. What’s happening is closer to evolution than revolution, and those who tell you otherwise are probably trying to sell books.

A quote from Labour’s Douglas Alexander, on consulting with the US Democrats about Labour’s election campaign:

“[We expected them to tell us] modern campaigning begins and ends with the internet. Actually, they said this is about peer-to-peer communication — the internet just gives you new ways of having that conversation.”

The internet really is just a communication tool: one day (soon) it will be as all-pervasive, and as universally accepted, as the telephone.

Go read A List Apart. This is one of the premier websites for informing, educating, and inspiring people who design and develop websites; its pages are full of articles on user science, usability, information architecture, accessibility — all things which, when done well, makes websites simpler and/or easier to use. This is a good thing.

I suspect that most people who love web standards and usability are probably geeks at heart: we like nice clean systems and we love it when things fit together in a clean, coherent whole. We don’t like mess, we don’t like complexity.

This is also a good thing.

Trouble is, we forget why we do this stuff. We forget that usability is about, you know, making things easier to use, and make it instead about following rules, evangelising, doing the “right thing”. We criticise websites which don’t properly use web standards without remembering why those standards are important — this isn’t a competition to see who can best conform to the HTML specs; it’s a chance to make sites which work better for normal people.

Yes, normal people. Because we’re not normal. In comparison to the majority of people who operate online, we are different, because we understand how the system works! If you’ve every watched your mother, or grandmother, use the web, you’ll know what I mean.

These — your mother, your grandmother, the non-techies — are the people who web standards, usability, and all those other disciplines are made to help. The most important thing is this: when used well, these disciplines should not be apparent to website users. Those users don’t care how good websites are implemented; they just care that they’re good.

Take a look at the progress of other technology: Apple’s iPhone is easy to use, intuitive, simple. Do normal users care that it’s running HTML5 with offline storage? Do they care that its browser is one of the most forward-thinking when it comes to web standards? Do they care that it uses a custom operating system? Of course not. These things are all great, but they’re great because they help make the iPhone easier to use.

When you get down to it, what is the web? It’s a way for humans to communicate. Whether you’re buying a book, booking a holiday, subscribing to a mailing list, or developing an application, the web should be made for human beings — it was created to help human communication and (unless we’re going to get all sci-fi) that’s what it will always be for.

Next time you’re knocking some poor young HTML student for using <b> instead of <strong>, or droning on about usability like everyone should give a damn, take some time to put things in perspective. Our primary aim on the web should be to help other humans; everything else is a waste of time.

Update: you should read this more recent article for an explanation of how to use Paperclip with the latest beta release of Rails 3.

I got Paperclip working on Rails 3 today. Here’s how.

First, I found (by accident) a branch in the Paperclip repository on Github called “Rails 3″. Call me crazy but I thought that might be worth a try.

Normally you’d install Rails 3 plugins using rails plugin install, but in this case I used git submodule:

These two commands checkout the rails3 branch of Paperclip into vendor/plugins/paperclip, as a Git submodule. If you don’t understand Git submodules, you can read about them here.

I also found that Paperclip wasn’t properly handling image styles; the ‘Paperclip’ section of this post explains how I fixed this (a word of warning: it’s a simple one-line edit which solved my problem but is untested with regard to the rest of Paperclip).

As always, feel free to post questions or feedback in the comments. Good luck!

So it’s Sunday, and rather than go to church I decided to take Rails 3 for a test drive. As you do. How did it go? In the main, very smoothly — a couple of bugs, which you Googlers might find it useful to know about, and some nice new stuff.

Bug: the rails command

Failed completely :) Rails my_app fails with “no value provided for required arguments ‘app_path’”. The solution to this is easy, though: first, get a local copy of Rails 3 (I cloned the Rails repo: git clone git://github.com/rails/rails.git) and then use this command instead:

The rubygems require is necessary for Rails 3 to load all the gems it needs to run.

Thoughts

The Rails command

In Rails 3, the rails command replaces script/console, script/server, etc. This is nice: commands are more meaningful (run the rails server with “rails server”), and easier to type.

ActiveRecord’s new finder syntax

ActiveRecord’s new finder syntax is lovely, and has some nice performance gains which you can read about on other blogs. Named scopes look good:

I’m going to write more about this soon.

Speed

Call me crazy but Rails 3 seems faster. Maybe this has something to do with the fact that it uses Erubis instead of ERB, or maybe I’m just easily impressed :)

Paperclip (tiny bug)

Paperclip has a branch called Rails3: I went out on a limb and guessed that was for Rails 3. It almost just worked, except for one thing: custom attachment styles weren’t being created.

If you’ve used paperclip, you’ll know you can do this:

Well, those :medium, :wide, and :small variations weren’t being created. I didn’t have time to investigate properly but this seemed to have something to do with Paperclip’s callbacks (which were returning false even when they shouldn’t be): my one line hack/fix for this:

I freely admit that this might break other parts of Paperclip, but it works for me.

Conclusions

Overall, Rails 3 feels very nice. As you’d expect from a beta it almost just works, and I’ve made a working app with it in a day. Super easy! Next up: deploying to Heroku.