There are a few Android devices I have respect for: the Amazon Kindle Fire is one, the B&N Nook another, and the Cisco Cius is the third. To a lesser extent, the Sony tablet also fits this category.
I don’t tend to like the Galaxy Tab, the Xoom and similar tablets so much, and most of the phones are lacklustre too. So what’s the difference? Why should some of these products be good and some bad, when they’re all just Android touch screens?
Android is a technology, not a product.
A term that appears in Ars Technica’s review of Ice Cream Sandwich really brings home my argument:
Ice Cream Sandwich is the closest to a “finished” version of Android I’ve ever seen.
Reasoning by inference we can conclude that all versions of Android appear unfinished. And this is the nub of the issue. The products I’ve listed as respectable above—the Kindle Fire, Cius and so on—are not Android tablets. They are eBook readers, business communication tablets, media controllers. The ones I don’t like are Android tablets.
Using Android in a touchscreen device is an extension of using Linux in any other computing scenario: I might like the solution, but I don’t want to see your working. I own countless Linux boxes: a couple of network routers, some eInk readers, a Drobo, that sort of thing. They all have in common that they take Linux and then build something on top of it that solves a problem I have. While all of these devices are successful products that all use Linux, Linux itself as a standalone thing is not successful among the same people who buy Linux routers, Linux NAS and so on.
Indeed even Linux desktop OS distributions have failed to take over the world, but don’t they solve the problem of “I want a desktop OS”? There are two issues here: the first being that no-one has that problem. People have problems like “I want to e-mail my aunt” or “I need to write a report on deforestation in the Amazon”, and it turns out that PCs can support those people, and that a desktop OS can be part of the supporting solution. The second issue is that Linux distributions have traditionally given you all the bits of a desktop OS without helping you put them together: you wanted a sports car, well here’s enough Meccano that you can build one.
Colour in up to the lines
Let’s return to the issue of why the not-so-good Android products are not so good. They are to smartphones or tablets as Linux distros are to PCs: some assembly is required to get a functioning product. By and large, these things give you Android itself, a slathering of “differentiating” interface tweaks and access to the Android Market. Where you go from there is up to you.
Of course, fixing the user interface is a necessary (dear God is it necessary) part of producing a complete Android product, but it’s far from sufficient. Where the respectable products like the Kindle Fire work is that a problem has been identified (for example: I want to be able to read a wide range of books without having to carry a whole library of paper around) and they solve that problem. The engineers use Android to help arrive at that solution, but they colour in all the way up to the lines: they don’t just give you the line drawing and let you buy crayons from the marketplace.
So where are the opportunities?
Well, where are the problems? What is there that can’t be done, and how would you design a product to do it? If the answer involves a touchscreen, then there are a couple of ways to do it: either with an app running on top of a touchscreen platform, or with a touchscreen device. Which is appropriate to the problem you’re looking at?
It seems that in most cases, the app is the better approach. It’s cheaper to engineer and distribute, and allows customers to take advantage of their existing touchscreen products and potentially integrate your app into workflows involving their other applications.
One situation in which an app is not a sufficient solution is where you need hardware capabilities that don’t exist in off-the-shelf touchscreen kit: maybe ambient light sensors, motion sensors, thermometers, robotic arms and the like. In that case it might still be possible to adopt an existing platform to support the software side, and provide a peripheral using USB or Apple’s 30-pin connector for the custom hardware requirements. That could work, but it might not be the best experience, so perhaps a complete integrated hardware+software product is the better option.
A place where you will definitely need to consider building a complete hardware+software product is where the existing software platforms don’t provide the capabilities you need. For example, you require the ability to share data between components in a way that isn’t supported by apps on phones. Of course, the hardware could still be largely off-the-shelf running a custom software platform.
In either of these last two scenarios, building something custom on top of Android is a good solution. Giving your customers Android with the app on top is not a good solution.
These scenarios represent the missed opportunities. Start-ups could be taking Android and using it as the core of some great integrated products: not as the “app for that” but as the “Kindle for that”. A single device that solves the bejeesus out of a particular problem.
Worked example: there’s a Kindle for cars.
Modern cars suffer from a lack of convergence. There’s a whole bunch of electronics that control the car itself, or provide telemetry, and feed back information to either the dashboard or a special connector accessible to service technicians. There’s the sat nav, and then they often also have a separate entertainment system (and possibly even a dock for a separate media player). Then there’s the immobiliser, which may be remotely controllable by something like Viper smart start.
A company decides that they want to exploit this opportunity for an integrated car management system. The central part of the user experience would be a removable touch-screen display that allows drivers to plan routes and mark waypoints when they’re out of the car. They can subscribe to feeds from other organisations that tell them about interesting places, which can all be mashed up in the navigation display. For example, a driver who subscribes to English Heritage in the navigation system can ask where heritage sites within one hour’s drive are. Having seen pictures and descriptions of the sites, she could request a route from the current location to Stonehenge, where the return journey should pass by a service station (locations of which are supplied by her Welcome Break subscription).
The display also integrates with the car’s locking system, so the doors automatically lock when the display is taken outside the car. It must be connected to the car’s power/data port to enable the engine to start. While the car is in motion the display provides navigational information, and allows control of the entertainment system. Where notifications are sufficiently important, for example warnings from the car’s diagnostic system, they are announced over the display and the car’s speakers. Where they’re unimportant they’re left in the background to be reviewed once the journey is finished.
In this situation, we need both custom hardware (the interfaces to the immobiliser and the car telemetry, which for a good user experience should be a single connector that also provides power and sound output to the car speakers) and a custom software experience (the route-planning part, integrating with feeds provided by the third parties which are also available in the viewer “apps”, and the variable-severity notification system that off-the-shelf touchscreen platforms don’t provide).
Getting this product to market quickly would be benefitted by taking Android and customising it to fit the usage scenario, so that the core parts of the touchscreen software platform don’t need to be written from scratch. However providing a vanilla tablet experience with the various components implemented as apps would not make a good product.
Conclusion
Android can be a great part of a whole range of different touchscreen products. However it is not, in itself, a product.
