Smartphones like the iPhone and those powered by Android have presented an alternative way for people to interact with a huge range of embedded computing devices. Devices that require on-the-spot interaction have traditionally had their own specific hardware interfaces - their switches, buttons, displays and touch panels. Devices that can be controlled remotely have either required investing in a purpose built hardware interface (the remote control), using a program on a computer or connecting to a built-in web interface.
But with the availability of smartphones, large numbers of people are effectively carrying around their own general-purpose interactive interface hardware. Thanks to apps, these phones can quickly provide a very focused and task specific interface to an embedded device. Of course more than just providing an alternative interface with a similar level of interaction, apps on phones allow for a whole lot of extra goodness like familiar UI paradigms, personalization and connection with online services.
So assuming most people will end up owning a smartphone, will device-specific hardware interfaces disappear? Will we control and interact with all the devices around us (well, at least those that require interaction) through our phone? While there are definitely a number of product categories where this is already happening, how far can this be taken? What are the issues?
Immediacy
While specific hardware interfaces for embedded devices basically just sit there ready and waiting to be used and therefore can (should) provide instant interaction, that's not the case with a mobile phone app. The person has to pull out their phone, activate and unlock it, find and start the app, and then wait for it to connect to the device. While it's not a great length of time, the concentrated effort required does create a definite break in the core interaction flow of whatever task the person is using the embedded device for. Depending on the device type this could create an unacceptable overall experience.
So the key question is whether or not the time and effort it takes for a person to get their phone ready to interact with the embedded device is reasonable for the product type. For devices that are naturally controlled remotely or require a greater degree of interaction, the longer get-ready time is more likely to be acceptable. But for embedded devices that could otherwise be quickly and easily controlled, for example with a simple switch, it is hard to see how a mobile phone app would be a suitable replacement. It would have provide some pretty significant extra value in some form - perhaps some kind of stored personalization.
This immediacy issue could well be alleviated to a good extent if smartphone platforms gained support for some degree of automatic app starting based on location or proximity to an embedded device.
Dependency
The use of mobile phone apps as an interface to embedded devices creates two dependency issues, one for those using the product and one for those providing it.
The obvious potential problem for the user is the need to have their phone (with the app installed and set up ready to use) on them whenever they want to interact with the device. Depending on the device type this could definitely be a major drawback, so it's important to consider the overall interaction model of the embedded device.
The dependency issue for those providing the embedded device product is that by relying on a mobile phone app for the interface, to a certain extent the product becomes dependent on the phone vendors. Issues ranging from dealing with varying phone hardware types to having the app accepted for distribution on the platform (app store) could cause real problems and really need be taken into account.
Ongoing Support
Related to the problem of dependency on mobile phone vendors is the long term issue of providing ongoing app support on a changing platform.
Smartphones aren't a fixed hardware platform - the device hardware and their operating systems are continuously updated. This is of course both natural and positive. However users will reasonably expect the apps they use to keep up with this progress, and doing this well is a challenge that vendors of embedded products need to put some thought into.
Embedded device vendors will potentially need to update their apps for the following changes for the length of time they want to actively support the product.
- New devices (with different specs and new functionality)
- New operating system versions (which require work to maintain compatibility and to make use of new features)
- Security related changes
- Whole new mobile phone platforms
Apps Only?
Even if a mobile phone app will provide the best interface, should it be the only interface? Taking the above issues into account, thought really needs to be given to additional possibilities.
Should an alternative interface (like a basic attached hardware interface, an embedded web app or an optional detached hardware interface) also be included?
Should the networking interface used by the app to communicate with the embedded device be standards based or have a public specification to allow others to support it? Should this be encouraged?
Doing it Right
The decision on what interface to provide for an embedded device needs to be based on providing the best user experience over the useful life of the product.
No doubt the best experience will often involve including a mix of both a specific (attached) hardware interface and a mobile app. In these cases the two interfaces should be complimentary. I think a good standard approach to this will be to have the attached hardware interface providing control of critical core functionality, with the app providing more advanced (personalized, detailed and connected) interaction. A great example of this (and a personal favorite despite not actually having the chance to use it) is the Nest.
For embedded devices suited to remote control and with no need for on-the-spot interaction, a mobile app has got to be a serious contender for the primary interface. However, the issue of needing to provide ongoing support for the app over the useful life of the product needs to be considered, with thorough thought towards a possible optional detached hardware interface and support for others to make use of the device's networking interface.
While mobile phone apps aren't (on their own) always going to be the right choice, they definitely have a lot going for them. Even if a well executed specific hardware interface would actually provide a better experience, the cost of developing this will have to be weighed against the fact that most people already have a great piece of general purpose interactive hardware in their pocket.
I think that with a powerful and common hardware platform already there thanks to smartphones, the fact that all it takes is an app to provide an interface for control and interaction is encouraging the development of new types of products. Network ready controllers are being embedded in places we haven't really seen before - like WiFi enabled multi-color LED light bulbs that you control with your iPhone or Android.