As an information architect, I’m always trying to check my analysis with a simple but powerful mantra: keep it simple. In my opinion, simplicity without sacrificing power is the holy grail of interaction and information design. Why? Because if it’s simple, people will more easily understand it and interact with it. In other words, the “barrier to entry” is lower.
I think a lot of the same ideas applied to information design also apply to technologies that are introduced to the development world for adoption. A great example of this is web services. SOAP has got to be one of the most enthusiastically trumpeted technologies ever. The promise of web services is not a con job. The benefits are very real and tangible. Nevertheless, adoption has been slow. Why? I’d argue it’s because the barrier to entry is so high. For all its promised elegance, SOAP (along with WSDL) are not simple to learn and implement.
Then came REST. It’s hardly even a technology. It’s just pages of data that rely on URL’s for handling requests and parameters. Mind you, REST doesn’t work for everything, but it sure works for a lot of things. A couple of years ago, Tim O’Reilly pointed out that when Amazon’s web services introduced REST as an alternative API, it blew past SOAP as the preferred method for developers – such that 85% of their usage is on the REST interface.
Even beyond REST, you can lower the barrier even more by relying upon already understood schemas to deliver web services. Bloglines does a great job of this with their API. It’s REST, but it’s also using some very familiar XML structures. Pulling up someone’s feeds with folders? It’s just an OPML file. Pulling up an actual feed’s entries? It’s just an RSS file. The barrier can’t get much lower than that.
I think there’s a moral to all this silliness: keep it simple and accessible. Whether you’re dealing with users or developers, people don’t like the idea of cozying up to a 300 page manual to get some things done. They’d rather just hit the ground running.