Technology Blog »

Software tools that even your manager can use?

“digitalghost” writes: Wikipedia, The Semantic Web and That Damned Peter Norvig

It appears that anyone that wants to build a ‘Semantic Web’ needs to get past Peter Norvig’s 2006 assertion:

What I get a lot is: ‘Why are you against the Semantic Web?’ I am not against the Semantic Web. But from Google’s point of view, there are a few things you need to overcome, incompetence being the first,” Norvig said. Norvig clarified that it was not Berners-Lee or his group that he was referring to as incompetent, but the general user.

“We deal with millions of Web masters who can’t configure a server, can’t write HTML. It’s hard for them to go to the next step.”

The competence (or otherwise) of the average user is at the heart of a related question, one I’ve been pondering on for some years: how to build software tools for ordinary users. It’s a hot one. Every so often some smart developer will announce that their brilliant new technology or technique is so easy to understand that ordinary people will be able to make their own applications with it. And they are (almost) always wrong.

The first example of this misplaced optimism was probably COBOL. When it first appeared in 1959 many believed that it was so straightforward and its syntax so close to natural language that business people would be able to write programs themselves, without employing specialists. That hope was soon squashed, and by the late seventies practically every large organisation had its own army of programmers who did nothing else but churn out COBOL code. I was once one such drone, dear readers.

In the early 1980s, there appeared the arrogantly named (and justly forgotten) “The Last One”, which allowed the user to generate code from interactively created flowcharts. Although it failed to set the world alight it was part of a general trend towards so-called Fourth Generation Languages (4GLs for short). 4GLs, like COBOL, have proved too tricky for the average user though they can be very time-saving in skilled hands.

Lately there has been a certain amount of hype around Business Rules Engines, the idea being that business users will be enabled to manage the way their applications operate for themselves. But some types of change lend themselves to this approach whereas others don’t, and I worry that this represents as much as anything a new opportunity for cock-ups. There’ll still be a need for formal change management and testing: the value in the business rules initiative is I think mainly in assisting communication between managers and implementors. Will busy managers take the time to learn the special cut-down natural language employed by these tools? I wonder.

When looking for examples of software tools that have been embraced by ordinary users, there is one notable instance that comes to mind: the spreadsheet. It’s true that spreadsheets created by untrained individuals are notoriously poorly-designed but that doesn’t detract from the fact that non-technicians have taken to them in a way they never have with any of the other examples I’ve talked about.

Why should that be? To my mind the answer is a very simple one. Most software tools demand that the user must start by taking an abstract view of the problem, whereas with a spreadsheet you can simply open it up and start plugging in real data. Once you have some data then you can add formulae, but since you are almost always dealing directly with real numbers it’s relatively easy to spot when things go wrong. It’s this working in the realm of the concrete that in my view has led to the ubiquity of spreadsheets.

So what does this mean for developers who want to build tools that will be widely adopted? Let users enter data first and add meaning to it later, would be my recommendation. Remove barriers to experimentation, let them get things wrong, let them learn through doing. Above all, when it comes to designing user interfaces, don’t think like a programmer!