Almost every day there’s some new buzz, hype and occasional factual statement about self driving cars. The intersection (pun intended) of technology, user experience and transport policy is an interesting place.
From a technology perspective it feels like autonomous vehicles could be the equivalent of the space race for our times. As a side effect of getting people on the moon, NASA is also credited with inventing everything from Nike Air to better dentistry. Whilst the self-driving car industry is still in its infancy, innovations in detailed mapping, artificial intelligence, motion detection, capacity planning, battery technology and machine learning (to name but a few) have already started to have a significant impact on the technology we use everyday.
But transport and mobility matter a lot more than as a way to get a more accurate vacuum cleaner. The relationship people have with cars is complicated. Much of what has been written about vehicle ownership, usage and urban planning doesn’t take into account the irrational choices that people make around transport everyday. How autonomous vehicles fit into real world scenarios is going to be complicated, and based on how politicians handle most rapid technology change, I’m not optimistic about how smoothly the polity will adapt.
In many ways the motor car has been one of the most liberating inventions of the past 150 years. If I was so inclined, tomorrow morning I could pile up the car and drive to the South of France (or more likely the west coast of Scotland) with a level of ease and freedom not possible 100 years or so ago. Yet, despite having a car I don’t really self identify as a driver. It’s something I do, but I’m more likely to say I’m a cyclist or walker. But I’m conscious for many people driving is a very important part of their identify, and for some people the self-driving car represents a challenge to the idea of what it means to be human.
As with most complex technology problems, it’s easier to get to grips with them if you start by trying to build your own version. A self-driving car is a bit of a leap, but the next step for the location aware drinks trolley I build last year is probably autonomy. Even if I don’t get as far as a universal product, a beer wagon that can navigate my office is probably a pretty good place to start.
2017-01-30 22:28:23 GMT permalink
2017-01-15 00:31:58 GMT permalink
2016-08-23 21:03:58 GMT permalink
2016-03-22 13:49:36 GMT permalink
Tools are recursive.
Increasingly the conversations I’m having in the office are about tools - digital tools, scalable tools, technology as a tool. But these conversations quickly get meta. There are as many definitions of a digital tool as there are tools themselves. And many of these tools are really incremental pieces of technology, built on a whole heap of other tools and platforms.
As an example, some people in the office have been using Slack, a collaboration and communication tool that’s been getting some press (and dollars) recently. Slack uses, amongst other things, some Amazon AWS tools. Which are tools that we also use to build tools for our clients. And you can create and integrate other tools with Slack, allowing you to create tools to extend a tool that you use to help a team create tools.
Confused? You probably shouldn’t be. The fact that there are few new ideas and that we are building on the ideas / frameworks / shoulders of others is surely standard operating procedure in the current point of our post-sampler creative and cultural continuum.
But what’s important is not the just the originality of the 1% being added to the collective digital noise, but the story that you tell. The how, what and why matter as much as the code you write. Perhaps story points shouldn’t just be in the backlog.
2014-12-11 21:53:57 GMT permalink
2014-10-27 09:47:23 GMT permalink
2014-09-14 10:55:58 GMT permalink
2014-09-11 20:20:02 GMT permalink
Recently I was asked to take a look at an API as part of an advertising awards entry that we were making. As with most awards entries the assessment I was making wasn’t just about the functional elements such as the available methods, approach to content negotiation and compliance with open standards, but also the way the API was presented. Was there good documentation and tools as well as an active an easy to engage developer community.
All those elements were there, but there was something else less tangible and probably more important that I was really looking for. What did the API really say about the brand? This assessment is more subtle, but gets to the heart of how and why an organisation is choosing to expose services to third-parties.
- How does the sign-up process work
- Can I have a limited number of API calls without having to sign-up, so that I can test if this is for me
- Which programming languages are the code examples available in (the choice of languages can say a huge amount about the brand)
- How often is the API updated, is this a live project
- Is there an easy way to submit bugs or feature requests
- Which developer tools are being used to share code and examples (can I do a pull request on GitHub?)
The most important area to understand is the value that the API is offering to developers and third-parties, and by extension what is the expected return value the business can hope to receive.
Empowering developers though your API is a form of co-development with people you might not know so well. Choosing the playing field (the services) carefully is an important way of shaping the development direction.
There’s clearly an assumption within some organisations that “having an API” (public or private) is enough, but just showing up is no longer a winning strategy. The way companies engage the developer community is a pure expression of branding through doing (show, don’t tell). If done in the right way it empowers others to realise your brand expression through their own art, copy and code. Which seems like something that is worth investing in.
2014-06-18 10:23:00 GMT permalink
2013-10-22 16:11:00 GMT permalink