I’d like to emphasise a point that Emma Mulqueeny has alluded to in her seven principles for digital engagement and which I also made in passing in my previous article on building local news mashups.

The web is rife with discrimination of the most insidious and socially-destructive kind. It largely goes unnoticed as those that are well-served by the web care little for the plight of those that are not.

I’m talking about the web’s widespread discrimination against machines.

Conventional thinking about “websites” focuses almost wholly on human users. In the best-case scenario, people turn up to a website, find the information they want or do the thing they want to do, then go away again. If the website is useful and provides that information or service, and if it’s usable and accessible, people can do what they want to do with a minimum of fuss and effort and be satisfied.

Many websites are a long, long way from being able to provide a good experience for human users but I doubt many don’t have it as their goal, however ineptly they may deliver on the details.

By contrast, providing for machine users mostly happens either as an afterthought or not at all.

Machine users are other programs, websites or software systems that could interact with your website by extracting data, inputting data, or both.

The simplest example is an RSS feed fetching a list of news articles or job vacancies. By providing an RSS feed, a website makes it easy for other programs to capture that information and re-use it in any way possible. They might republish that information largely as-is, combine it with information from other sources in a mashup or even derive statistical information from it. Or all of these things.

More generally an API allows information to be read from or posted into another system. Can humans search your website? Then provide a search API for machines. Can people place orders and make payments online? Then provide an ordering and payment API. Every form on your website should have an API that makes provision for machine users to post in data and get a machine-readable response. Every sequential collection of information should be available as a feed.

Providing for machine users by building APIs and serving feeds is ultimately about serving human needs. Until machines achieve some kind of consciousness they will neither know nor care about accessing information on other systems. Every program is written by and provides information for people.

APIs make it possible for people to write programs to use your information and services in ways that suit them, in ways that you can’t anticipate, in ways that you don’t have the resources to provide, through systems that you won’t have to maintain. Many organisations won’t like this. It means the creation of infinite new layers of intermediaries, third-party services that provide new interfaces to your information and services or whole new applications that combine your services with others’. If you think you can provide the best interface to your services for every conceivable context you’re a fool. If you think you should be the sole gatekeeper of your services then prepare to lose your customers to other businesses or see your citizens disappear to third-party services implemented through any means necessary.

Let’s snap out of abstractions for a moment and look at an example.

As an activist with Living Streets I’m always on the lookout for maintenance issues and faults on the street, particularly where they affect pedestrians. I can report street faults directly to my local council or I can use FixMyStreet, a national service that ostensibly does the same thing.

I always use FixMyStreet. Why?

• It’s easier. The user interface is better.
• It’s geographically agnostic. I can report a fault anywhere in the country without having to know which authority is responsible for it.
• It’s public. There’s a lot of value for me in being able to see other people’s street reports as I’m interested in looking at the wider issue of urban design and maintenance, not just getting a specific fault that bothers me fixed. I can browse other fault reports and see statistics for each borough.
• It’s flexible. I can get reports sent to me by email or through an RSS feed. I can file a report on an iPhone and soon through many other mobile clients.

Overall it’s just better, and better in so many ways that my council and most other councils will not be able to emulate.

Smart councils would realise this and most probably abandon their local street fault reporting systems. They could put their resources into developing a clean API between their own faults database and FixMyStreet (or any other similar application). They could actually invest in FixMyStreet itself. It’s open source, so why not? It’s not going to disappear, and if it gets superseded by another, better, open-source system, no-one loses.

It’s APIs (and often, ersatz, hacky APIs) that make this kind of thing possible. It leads to better services, greater participation, and more flexibility, diversity. We need to put machine users on parity with human users so that people can be best served.

If you’re building any kind of website or online service, serve a feed for every stream and an API for every form. Let this be your mantra: DDAM, DDAM, DDAM. Don’t discriminate against machines.

Like this? Follow me on Twitter or subscribe to my RSS feed.