TRP: Google recently unveiled its smartwatch OS, Android Wear. Why didn't it stick with full Android?
NH: It's encouraging that software communities and OS companies are looking at how to better engineer software for different use cases. Android Wear is an example of this.
Many of the smartwatches today are running full Android, but only driving a display of a limited resolution. As such, there are elements of Android as it is today that are too big and bloated for what you need to do, meaning there's lots you can strip away while still delivering the experience that the consumer wants.
That bloat results in inefficiency as you burn power by running software of limited value. Or, if the software stacks are too complex, you burn power that way.
When I've got a use case that says "the screen size is this, these are the sensors, and this is the type of environment and performance level I need," I can strip away a lot of complexity and try to hone it down to the most efficient software and hardware for that purpose.
TRP: Wear also deeply integrates Google's contextual services. Do you think we'll see more of this kind of thing?
NH: I don't have have any specific comment on it as it was only recently announced, but certainly a large part of wearables is about augmenting reality - that's Google Glass's whole concept. Similarly, Android Wear is tying together data and cloud services alongside a hardware platform on the body.
Ecosystem shock
TRP: Apps will likely drive adoption of smartwatches, but how important will APIs be in allowing developers to create ecosystems around them?
NH: I think if you're thinking of launching a wearable device you really need to be thinking about not just the hardware, but also how you're going to deliver and build an ecosystem around it.
It's about how you're going to encourage developers to write apps for your hardware, because I think you'll have a better chance of success by engaging with the many creative software developers out there, and that comes back to APIs. Then there's the tools and the framework.
It almost harks to the analogies in which the way games consoles came to market in that you launch an initial application and then over time you want developers to bring out new applications for your platform.
When you look at things like Pebble, they've done that very well. I think others that have tried to make it very closed are missing an opportunity to engage with developers and consumers. They should aim to build a level of enthusiasm around the platform.
TRP: If a platform takes off with developers, it can have pretty powerful results...
NH: Absolutely. A few years ago there was a fantastic device that was ingenious in that all its creators did was take a ball with a motor and a Bluetooth radio chip in it and a few coloured LEDs, before opening up an API for it.
It's amazing how many developers wrote iPhone or Android apps just to play games by controlling the ball, allowing it to do things like move around a maze.
From a hardware perspective it was really simple. Just by writing an API they could change the colour of the ball and write games based upon how you control it. They could've just done a ball that came with one app, but by opening up the API they were able to have lots of games revolve around a simple thing.
TRP: In that sense, will putting more sensors in wearables allow developers to do more with them?
NH: Yes - I'm certainly in the camp or more rather than fewer sensors as I think that will foster creation and innovation. Couple that with open APIs and app stores and i think you'll get the creativity, which will keep the interest of the consumer.
