anthony galvin

Recently I’ve been doing lots of work with voice interfaces. Globally AKQA has been working with clients on VI since it started to go mainstream, and in the UK we’ve helped Jamie Oliver and Arsenal get onto the Amazon Echo platform.

VI is also a lens to use when looking at system or service and figuring out what an MVP really is. By it’s nature VI is a paired back user experience - so if you have an experience that works well for voice users then you probably have a good idea of your core use cases. 

From a technology perspective it also starts to place some new demands on engineers. It forces technical teams to think differently about infrastructure, code and server less at scale. The separation between code and infrastructure can get messy when working with AWS Lambda (and similar services), so it’s extra important to focus on code and build pipelines for anything but the most trivial use cases. 

Developing for voice also highlights something I think is increasingly important for engineers - the ability to bring service design thinking into software / sprint planning. There’s an increasing overlap between writing software that doesn’t have dead ends and handles exceptions well, and managing the user through options and occasions frustrations of voice interfaces.

Test automation, unit and integration tests are even more important than usual (though I’m not sure how much more important you can make these kind of tests!). Manual testing of voice services is slow (you can’t really speed it up), so you need to have good test coverage to have high confidence in your software and for the team to be able to work at a decent velocity.

It’s also important for everyone on the team to spend time using voice services and to understand the emerging design patterns and expectations of regular users. In the early days of television it was apparently common to meet people who appeared on TV shows but refused to own a television set. The same approach won’t work if you’re developing VI. Using an Echo or Google home on a regular basis is the only real way to understand the possibilities and frustrations of voice interfaces.

Most agencies have a Friday drinks routine. At AKQA London there’s a couple of Virgin Atlantic drinks trolleys that do the rounds. Split over 3 large floors, it’s sometimes hard to know exactly when your G&T is going to arrive. To counter this problem we decided to upgrade the drinks trolley.

The CRD team have been adding estimote beacons across the office (15 or so per floor). These give pretty good coverage, more than enough for a drinks trolley tracker. There’s a few ways you could check the location of the trolley, but it made sense to use all those beacons.

To turn the trolley into an IoT device, we used an Intel Edison hooked up to a SparkFun battery pack. The Edison is Intel’s small connected prototyping device. Think an Arduino but with a bit more power and built in WiFi and Bluetooth. 

The Edison runs a version of Linux and you can write apps in a variety of languages including node.js. Using the Bleacon library I wrote a simple script that uses the onboard Bluetooth to scan for beacons.

When the Edison finds a known beacon, it calls a service to let it know which beacon is nearby. To keep things simple we are using AWS API gateway and dynamoDB so there’s no server side code to manage. There’s a second endpoint that returns a list of places the trolley has been. We then use this data to populate a simple website to tell people where the trolley is.

It’s a fairly silly application for IoT, but it shows how you can create a proof of concept without lots of infrastructure. The good news is we now know where the trolley is. The bad news is that it doesn’t make it arrive any sooner.  

Yesterday at AKQA London, Alec Ross took part in a Q&A. Ross is former innovation advisor to Barack Obama and Hillary Clinton. The session was wide ranging covering genetic testing, cyber warfare and the US election. But the topic that got me thinking was when Alec described the skills that people will need in the future to be employable in a more automated world.

Alec’s answer was that people will need to combine excellence in technology, creativity and the humanities (social sciences, psychology, politics etc…). The need for “creativity in the age of automaton” isn’t a new idea. But humanities in the age of automation was a new addition!

Listening to Alec I realised that many of the best developers I’ve encountered in my agency career would already fit this profile. Developers with a background in music or fashion or cartoons or in some other discipline beyond just computer science. Some with a pure computer science background often have a hinterland - a not so hidden passion for triathlon or pickled onions.

This isn’t a plea for developers who don’t know their (pickled) onions. Deep tech knowledge, and a genuine understanding of the fundamentals is mandatory. It’s a recognition of the fact that a well turned out line of code on its own isn’t going to be enough. Solving complex problems requires deep collaboration. Collaboration with people of different disciplines and levels of technical expertise. The most successful agency side developers are not just receptive of input from designers, strategists et al. They are empathetic to the objectives of different disciplines and able to contribute to the process.

We often talk about T-Shaped individuals (especially when hiring). This sometimes masks the reality of an organisational structures and processes that make it hard for such people to succeed.

Finding ‘renaissance’ developers today is one thing. The T-Shaped developers of tomorrow are probably a bigger concern. If Ross’ hypothesis is correct then current trends in UK education policy are a serious concern. Rather than reducing the emphasis on arts and creative subjects, we should be emphasising the importance of these. Not at the expense of STEM subjects, but in conjunction with them. Perhaps I’m biased - I’m Music Tech graduate, who works in technology.