Bill Buxton: Respect The Skills Acquired By Your Users

Take 30 minutes and watch his keynote appearance: http://live.visitmix.com/MIX10/Sessions/KEY02 (he’s introduced at the 2:13 mark). Its worthwhile.

If you notice the title, you’ll see that it’s slightly different to what Bill Buxton actually said. Bill is a UI designer. UI design is the natural application of his design paradigm.

But it goes deeper than simple UI design.

You see, Bill’s paradigm is that User Interfaces must respect the skill that has been acquired by the user. Since the acquiring of skill is on thing that we all have in common.

Bill gives this wonderful example of a violin. The violin itself may be worth millions of dollars (if I remember correctly, Joshua Bell paid $4.5 million for his Stradivarius). The bow of the violin for any first violinist in any symphony orchestra is never less than $10,000. Remember these are musicians. They make a pittance. So as a proportion of income, it’s a fortune. But it’s worth it. Why? Because it’s worthy of the skills that those musicians been acquired over decades.

Bill was taking purely in terms of User Interfaces. But the application of this paradigm is rather broad.

For instance, lets take developers.

Developers typically end up working with libraries and API’s. We rarely rewrite what Joel Spolsky affectionately calls duct tape code. Like date comparisons and string builders. It’s a brutally Darwinian process in which the libraries and API’s that are most easily used rise to prominence.

Personally, when I write any code, whether it’s an API used by some other code to do processing, or some plumbing for my UI, or even a class definition with functions and parameters, I always think of the way in which this code is going to be consumed. Since the consumer typically dictates what it needs to get out of that API/function/class. At this point, simple abstraction takes over: how can I abstract away processing code such that my consumer code is much easier and cleaner. In this case the User Interface is not pixels on a screen. No, it’s functions and parameters. The consumer code is and should be treated as a fully fledged user of that code.

The premise this blog post started off with was that user interfaces should respect the skill that has been acquired by the user. Of course, code has no appreciation of skill, whether the code is elegant or not has no meaning to the compiler. But you, as the programmer are consuming the service, the function or the API. You have skill. A skilled programmer writes elegant code. He or she draws on a vast reserve of skill and talent even in the most simplest of tasks.

My point is that when you write your API, when you write your function, when you define you class. You want to ask: "How can I help the programmer that programs against this service write elegant code, how can I write an interface that respects the skills acquired"?

let make some practical application of this:

Typically, I find Web services frustrating. I find it frustrating because I can’t just point Visual Studio at a URL and say "this API lives here and I want to use it". WSDL files, where available, make this so much easier because Visual studio will generate either a web or a service reference.

Why do I say this? For me as a programmer, it does not respect my skills to spend hours each day parsing SOAP or XML or JSON results when what I should actually be doing is writing program code. And yes, some of you will say that it takes all the fun out of life. But I want to be able to go off and write code. Program code. Not low level plumbing, specially plumbing that should be automatically generated for me here in 2010.

That’s one of the things that blew me away about Microsoft’s OData protocol. Here’s a URL and BOOM you have data and are ready to program. You don’t even need a WSDL (whether we need yet another data protocol to have this functionality is another question altogether). It respects the skills of the user, namely me, the programmer. It allows me to immediately get on with the business of practising my chosen craft.

It should be noted that I’m not arguing that we never get our hands dirty in the plumbing. Someone has got to do it. And it is essential training for anyone interested in programming, let alone web services.

In some ways writing an interface that respects the skills I have acquired is a meta-function. The better the interface/class/API is, the better my code is going to be: it’s writing code to write code.

Let’s take another aspect. PowerPoint presentations.

This mornings lecture borrowed a slide deck from TechEd 2009. It was about the BizTalk 2009 ESB Toolkit. Now the slides had no relevance to us as programmers. At all. No respect to the skills we have acquired over years or training and practise. Just a lot of SmartArt. (Id argue that BizTalk as a whole shows little or no respect for our skills as programmers). As a result I discovered what talented doodlers there are in my class, and that nobody snores.

But when was the last time you watched a Scott Hanselman presentation? He uses little or no slides. The majority of his talks involve coding in visual studio. Seriously, how much more respect can you have for the skills your audience has acquired? As a result people sit up and pay attention (and that has absolutely nothing to do with Scott’s various attempts at humour).

Want to see what I mean? See this video: Creating NerdDinner.com with Microsoft ASP.NET Model View Controller (MVC) or this one from Mix10:

BEYOND FILE | NEW COMPANY: FROM CHEESY SAMPLE TO SOCIAL PLATFORM

Talking of Scott Hanselman, have you seen his BabySmash WPF app? It’s written for babies. Babies smash your keyboard very much at random. The app takes this input and turns it into colourful animated shapes that move about the screen. Once again, the User Interface shows respect to the skills the user has (or in this case hasn’t) acquired.

Do not misconstrue this as me banging my drum about ease of use. The easiest point and click UI is the one Smith and Wesson developed many years ago. Yet that UI shows absolutely no respect to the skills developed by its users. And BabySmash may be easy to use, but it shows no respect for my skills as a developer.

As it has been said many times, software is hard. It will always be hard. There will always be challenges. But if we respect the skills of the code ninjas that come forth to complete those challenges, we all benefit.