adoption curve dot net

[cross-posted from the Headshift blog]

That’s a question I was asked a few days ago by a client.  It’s a fair question, too – there’s no point in building features into systems unless they provide some benefit, so why would you want to spend time and effort doing this?   And for that matter, what exactly IS an API?

The acronym stands for “application programming interface”, which is a typically over-engineered way of saying “means of putting information in and getting information out of your system without having to type it yourself”.   Typically you’ll provide the API with some information, and in return the system will process and spit back some other data.   There’s any number of analogies that you can use, but one of my favourites is the cash machine.   That’s pretty much an API for your bank – you put in your card and enter your PIN, ask the bank for money, and it then dispenses cash.   The information you’re providing is the data on your card and your PIN, while the bank is supplying you with cash and a little paper slip telling you how big your overdraft is.

An “API” for a bank is a good thing if you want to get at your money, but why is it such a big deal for a piece of software?

To start with, very few software systems these days exist in isolation.   If it’s an accounting package, you’ll probably want it to hook up to your bank so you can send and receive payments automatically.  If it’s an ERP system, you’ll find it useful if you could send your purchase orders electronically to your suppliers rather than relying on the steam telephone.   And if you want to tell your customers where your outlets are, you can embed a Google map into your website to plot their locations so that your customers can find you.

All of these are examples of systems using APIs, but it doesn’t stop there.  Increasingly, systems are providing APIs without necessarily having a clear idea of what they’re going to get used for.   In some ways, that’s a violation of my sweeping statement about there being no point building features without having returns – but the point here is that there’s no guarantee that you’re best placed to know *what* those returns might be.

Take Moo, for example.  They print things – stickers, business cards, postcards and so on.   They’ve also got an API.  So what the hell would a printing company do with an API?

The answer is, suprisingly, quite a lot.   Former Headshift colleague Tom Armitage created an application that takes a set of Flickr photographs, calculates their average colours and creates stickers.   They’re very tangible, suprisingly beautiful and almost completely pointless – unless, that is, you’re Moo who make money for every sticker that they print.   Another example is Barcode Sticker-o-Matic that lets you create QR code stickers.   Previously, creating QR codes was a pain, and creating QR code stickers was even more of a pain – but mashing up the two things creates something very much easier and useful.

Another example (and bear with me while I unashamedly pimp some of my own creations) is Twitter.   Their API enables you to create tweets with code, rather than the website.   So I’ve used this to create Twitter bots that tweet the high and low tides of the River Thames; and tweet the values of various stock markets every hour.  The first example is something of a play thing (although as an aside, I actually think you can gain some value to be gained by providing an inanimate object with a “personality”), but the second could conceivably be useful if you needed a peripheral update of how badly the markets were doing.

So much for the entertainment value, but what about the potential business value for providing an API?

There are two things to consider.  The first is that you could potentially make it easier for your customers to deal with you.   If your clients can place orders directly onto your system through your API, that’s going to speed things up.  It’s also going to cut down on errors and duplication, particularly if you can give them information about lead times and stock levels there and then.   And on the assumption that the easier it is to deal with you, the more people will, that should translate through to the bottom line.

The second thing – and to me, the most powerful – is that your customers may want to interact with you in ways that you’d never thought of.   It’s fairly unlikely that Moo realised that they’d end up printing QR codes when they wrote their API, and I’m absolutely sure that Twitter weren’t expecting me to come along and impersonate the River Thames.  And the same probably goes for for huge numbers of other organisations as well.  Imagine if Sainsbury provided an API for their home shopping service.  How long do you think it would be before someone created an iPhone application that allowed you to scan the barcode on the last tin of beans in your cupboard, and automatically add that into your basket, which would then be automatically ordered as soon as the value triggered their free delivery option.  Oh, and interrogated your Google calendar to find the slot when you weren’t planning to be out for evening?   I don’t work for Sainsburys – and they’ve certainly never tried to ask me about what I want from them – but if they provided an API for me to play with, then I’d definitely be having a go at it.

I’m going to make a wild prediction that no corporate software system will ship WITHOUT an API in three years time, and that organisations that can’t provide an interface for their customers are going to find that an increasingly difficult omission to justify.  So the question is not so much, “what’s an API and why do I want one”, as “what’s my API going to do and when can I have it”…

Controversy over whether time spent on social media sites is wasted or productive is nothing new – anyone who’s been around the block for long enough will remember similar discussions around email rollouts.  And no doubt there will have been the same arguments about putting electric telephones on people’s desks.

The problem is often manifested when someone, somewhere, takes the decision to block access to one or other tool.  At best, that reaction is down to a lack of understanding that social tools are becoming increasingly important to the way that people work.   At worst, it’s a symptom of the way IT – particularly in larger organisations – has a tendency to attract a section of the population that can only be described as petty control freaks.  They know who they are…

Going down the blocking route is fraught with problems, though – not least the fact that consistently blocking social media and collaboration tools resembles a game of whack-a-mole.   Block YouTube, and you’ve not stopped Vimeo getting through.  Clamp down on Google Docs, and you’ll still have missed Basecamp.  And so on.   Each different organisation has a different approach, which makes collaborating across organisational boundaries trickier that it otherwise should be.

Steph Gray, who’s the Social Media Manager at the Department for Innovation, Universities and Skills is on the front line of this – it’s pretty damn difficult to innovate if the innovative tools are off-limits.   So he’s come up with the Social Media Test Suite, which runs you rapidly through a selection of common social media service and tests access to each one via your current internet connection.

By aggregating the results across a range of organisations, he’s going to be able to build up a better picture of what’s available from where – and hopefully identify the best and worst of practices.  Although it’s aimed primarily at the public sector, there’s no reason why commercial organisations can’t be involved as well – after all, the need for collaboration and innovation is common regardless of sector.

[cross-posted from the Headshift blog]

Politicians and IT usually go together like fish and bicycles.   The story of public-sector IT in the UK is generally one of grandiose over-budget failures at the top end of the scale, and low-level outsourced inadequacies at the other.  The same is also true in the private sector, of course, but the public sector situation gets a higher profile by the fact that it’s “our” money that’s being wasted and it’s more difficult to sweep the disasters under the carpet.

The litany of disasters is a long one – the Child Support Agency’s IT system was “one of the worst public administration scandals in modern times” according to the Public Accounts Committee, while the NHS’s Connecting For Health project is seven times over-budget and more than two years behind schedule.  And that’s before we start trying to keep track of every email sent and webpage visited in the mother of all surveillance databases.

So why do we keep letting this happen?

Earlier this week, the Conservatives launched the results of a study they commissioned last year from Dr Mark Thompson of the Judge Business School in Cambridge.   The headlines were startling – government could save at least £600m a year, according to the report, and it promises an end to “IT white elephants”.

[The text of the report itself doesn't seem to be available via the Tories' website, but I've got a copy which I can email on if you're interested.]

There’s also some very interesting detail buried away below the headline figures.   One of the key recommendations is that there should be a cap on project size – no contract should be worth more than £100m.   Personally, that seems a fairly arbitrary figure to me – I’m not convinced that knocking a nought of the end of the contract value will make them any easier to deliver – but it does point to an increasingly widely-held belief that the days of huge projects are over.

Of course, a recession is going to make justifying telephone-number budgets very difficult even if big projects were always successful – but history suggests that when projects fail, big projects fail bigger.   I think the trend over the next few years is going to be towards projects on a much, much smaller scale.  Rather than taking years to spend millions on massive systems implementations that attempt to solve every problem simultaneously, instead organisations are going to try smaller-scale point solutions that are focussed on improving the way people *actually* work together.

I’m also beginning to think that there’s actually a finite limit to the size of a project, beyond which it’s impossible to achieve the stated benefits.   Some systems are just too big, and too complex, to be controlled by human brains which have been wired up be evolution to make a series of “can I eat it, or do I run away from it?” decisions.  And many situations just don’t lend themselves to a one-size-fits-all solution, particularly if the solution is being defined in isolation from the actual end-users who will be subjected to it – something that seems to sum up the IT programmes in the Health Service.

Of course, changing the culture of Government IT is going to be a huge job given the massive vested interests at play – the huge suppliers that seem to be a key part of the problem are not going to just walk away from their potential revenues.   Bureaucracies move slowly, and government bureaucracy moves slower than most.   But it’s encouraging to see signs that the status quo is being seriously questioned by a potential future ruling party – and hopefully it might influence the current decision makers in the meanwhile.

(cc-licensed photo by huangjiahui)

I suppose it might just be a convenient excuse to kick the habit, but I really don’t get why it’s necessary for Barack Obama to hand over his Blackberry when he enters the Oval Office:

Lose the BlackBerry? Yes He Can, Maybe

For years, like legions of other professionals, Mr. Obama has been all but addicted to his BlackBerry. The device has rarely been far from his side — on most days, it was fastened to his belt — to provide a singular conduit to the outside world as the bubble around him grew tighter and tighter throughout his campaign.

“How about that?” Mr. Obama replied to a friend’s congratulatory e-mail message on the night of his victory.

But before he arrives at the White House, he will probably be forced to sign off. In addition to concerns about e-mail security, he faces the Presidential Records Act, which puts his correspondence in the official record and ultimately up for public review, and the threat of subpoenas. A decision has not been made on whether he could become the first e-mailing president, but aides said that seemed doubtful.

I can understand the need to ensure that Presidential communications are kept for posterity, but this seems an incredibly heavy-handed way of doing so. Presumably the White House is sufficiently advanced to have moved on from carbon copies to electronic documents – so how is email any different?

This has been kicking around at the back of my subconscious for a while, partly born of frustration with organisation systems like GTD. It’s not that there’s fundamental flaws with them, so much as there are fundamental limitations to how organised I can be. That’s partly why I don’t have a lot of time for 43 Folder-style blogs – the constant striving towards GTD nirvana strikes me as too reminiscent of Catholic attitudes to sin. By any objective standard I seem to be reasonably well-organised, as far as it’s possible to be self-aware of this – but comparison with the true devotees of the One True Way To Organisation just leave me feeling depressed at how slovenly my pile of “stuff to look at” has become.

Then I came across isochrones – geographical maps with a temporal overlay – so they can answer questions such as “how long will it take me to get to point A from point B?” The best examples I’ve seen were produced by MySociety, and were “heatmaps” of travelling time via public transport which you could also overlay housing costs. These enabled you to ask multi-variable questions like “where can I afford to live within an hour of work?”

I started wondering whether there are implied isochrones around daily activities. If you look at someone’s desk – or pretty much any space, for that matter – the more important something is, the closer it’s kept. My iPhone is generally never more than an arm’s length away, because it’s my primary means of communication and access to my email, calendar, contacts, to-do list and the kind of photographs that would in earlier times be kept in a wallet. I might not be able to lay my hands on a pen unless I’m at my desk, because I tend not to physically write anything when I’m not sat down.

And when it comes to work, the same patterns apply. Working materials are directly in front of us, and the more useful the article the more likely that it’ll be within easy reach. That also applies to the tchozkes that we surround ourselves with, too – photos of the kids are usually pinned up in clear view. [I can't find the reference at the moment, but when the UK's Department of Work and Pensions embarked on a pointy-haired programme of "efficiency improvements" by enforcing at HR-driven-disciplinary-point a "clear desk policy", the thing that *really* upset people wasn't the fact that they were being told to keep their pencils in a drawer. Instead, it was the insistence on tidying away the kind of personal items that soften the right angles of work environments - the photos, the monitor pets, the post-it notes with shopping list-type scribbles. Oh, and being told where the right place to keep a banana was.]

Unimportant stuff gets pushed away. If you suddenly need to find something that you’ve not used or thought about in weeks, the chances are it’s going to be *under* something. In fact, if it’s in clear view, the chances are you’re going to overlook it, because we’re almost conditioned to expect finding something lost to be more complicated than it turns out to be. Reference materials are filed, if you’re lucky and organised. But either way, immediate personal space is populated by the important and relevant.

All of which is a (very) roundabout way of wondering if we could take this one stage further, and use proximity as a metaphor for urgency in an organisational tool. What if you could use physical – or virtual – distance as a means of organisation? Imagine a system where tasks existed in a (probably pseudo) three-dimensional, and gradually encroached as the urgency became greater. The larger something loomed, the more important it is – and reprioritisation would be done by “pushing” items away, back into the future as it were.

I suppose that categorisation could probably be overlaid, as well – imagine work tasks raining down from above, while personal stuff sneaked in from left field. Switching context from one to the other could be as simple as moving your head to the side, to bring a new context into view. And if physical location could be tied into this somehow, you’d have a situation where the context of tasks could be directly related to where you were at that moment – so work tasks would only rain down in work, and the list of things you were supposed to pick up from the shops would only appear when some kind of near-field trigger alerted the system to the fact that you were entering the mall.

Would it work? I’m not sure – three-dimensional interfaces haven’t exactly been a roaring success outside of the games industry. And interacting with the physical environment would be dependent on the sensor infrastructure being in place, which seems unlikely any time soon – at least not until Jacqui Smith turns the UK into Minority Report. It would be fun trying, though.

I’ve been playing around with making things Twitter again, inspired by Tower Bridge and my previous efforts with the Shipping Forecast. The bridge has been very “successful”, at least judged by the off-Twitter attention that it got – I’m not completely happy with the Shipping Forecast though, because I think I’m trying to push too much information into 140 characters.

So my latest attempts are four stock market indexes – the FTSE-100, the DAX-30, the Dow Jones Industrial Average and the Nikkei 225. They tweet every hour while the relevant exchanges are open, so don’t manage your portfolios with them – but I liked the idea of having the doom and despondency of the markets flit past every hour in my peripheral vision.

I also thought it was quite important that they’re twittering in the first person, and have some national characteristics (or should that be stereotypes?) Follow them here (FTSE), here (DAX), here (DJIA) and here (Nikkei).

One of the things that I try and emphasise when talking to clients is that a website is much more than it first appears. It’s better to think of a site as an application in its own right, in the same way as you’d think of a web browser, or an inventory management system, or (if you really, really have to) a spreadsheet.

On a technical level, that means using REST techniques when building the site. It’s too big a subject to go into detail about here, but the basic idea is that you have a very simple set of common actions that you can perform on the objects in your system – create, read, update and delete – and you “expose” those actions through a consistent set of site addresses. So an address of “http://something/1″ that arrives at the server is automagically assumed to be a “read” action that’s aimed at the object 1. That’s a drastic simplification, but it’s good enough to get the basic drift.

That’s important because it provides consistency – if it works for object 1, it’ll also work for 2 and 3 and beyond. And that makes interfacing other sites with yours very much easier.

It’s also important because it makes your site extensible – which means that you can hook other systems into it at a later stage, and you’re not necessarily going to need us to do it for you. Anyone who knows about the basic principles of REST will be able to figure it out.

While it’s clever at a geeky level, it’s also a bit arcane if you’re thinking in “website” terms – and particularly if only you’re thinking about interacting with a site in a browser. This makes explaining it – and justifying why it will make building your site slightly more expensive in the short-term, but a much better investment in the long-term – a bit tricky at times.

A conversation earlier today reinforced this – there’s a potential client who are looking to redevelop their website – but they seem to be struggling to think of it as anything beyond a simple electronic brochure.

So I got quite excited when I stumbled across something the Guardian are doing with their RSS feeds, because it’s a tangible application of exactly these principles. They’ve taken the same REST approach and applied it to their feeds, but done it in a way that makes sense in the browser or RSS reader.

For the Guardian, it starts with a consistent addressing structure – so the UK news section is accessible via a simple “www.guardian.co.uk/uk” URL.

Then the same applies to getting at the associated RSS feed – tack “/rss” on the end, and you’ll find the same (and full) content but formatted for consumption in an RSS reader.

That’s an example of a “destination”, but there’s also the option to do the same thing by “theme” – so content that’s about politics will show up at “/politics“.

And this gets remixed further with the actual topic, so political news about Labour will show up at “/politics/labour”. Again, if you want this in RSS form, just tack on “/rss” to the end.

This is very, very clever, and got me rather excited at the simplicity of it all – but it doesn’t stop there. You can start to combine various topics together SIMPLY BY CHANGING THE URL – if you want to see everything that’s related to Labour and the environment, change the URL to “politics/labour+environment/climatechange” and the results are now a mash up of the two topics. Tack “/rss” on the end, and you’ve got a machine-readable format.

So why is this so interesting, and why should you care if you’re not an RSS geek like me?

Well, simply that the Guardian has just given ME the ability to create a customised feed of news to fit my requirements. They don’t know me, and they’ve got no way of knowing what my specific requirements are – nor for that matter are they likely to have the resources to satisfy them if they did. But that doesn’t matter – if I can figure out the options that they’ve exposed, I can create something bespoke for myself – which greatly increases the value of their service to me, and makes it far more likely that I’ll stick around.

The crucial point here is that they’ve gone beyond thinking of the website simply as a publication, and are thinking of it in terms of being a service or application in its own right. They’ve got no way of predicting exactly how people are going to use it, and to a certain extent they’ve got little control. But what they ARE doing is making their core service much more useful to me, which massively increases its potential value to them.

Now instead of thinking in terms of news content, think cinema listings, or train times. Or imagine exposing your product information and inventory in this way – “tell me about the specifications of all the blue left-handed widgets”, but done through a simple web address. You start to get a glimpse of the possibilities that might be out there if more sites worked this way. It might make the initial build slightly more expensive, but the long-term possibilities are greatly increased.