People are hard to predict. There is no telling what they might do when they start interacting with your product. They might use your application exactly as you expected when you ran your test cases, or they might mistake the close window icon for a copy command and then end up pounding the keyboard in frustration.
To make a system’s Human Machine Interface (HMI) as intuitive as possible and to save time, many designers build their HMI on top of a well-known operating system (OS) like Microsoft Windows. Most people have grown up with Windows, and they understand the basic operations of using a mouse, minimizing windows, and launching applications.
When you utilize Windows as the face of your application, the learning curve for your application goes down dramatically, (hopefully) reducing user frustration and error. Until recently, the choices were small for OSs that both users and developers had experience with, and Windows became a common HMI choice for system designers.
Yet with the rise of smart phones, users and interface designers have quickly become accustomed to a different type of interface, one that is simpler and purpose-built for the device it manages. For example, Android phones are enormously popular despite having a completely different HMI experience than people have while using a computer.
Mobile platforms have benefitted from being built to accomplish much less in a more efficient way for the user, while taking advantage of emerging technologies like touchscreens. But does this mean that teams designing cars, heavy machinery, or point of sale systems should start considering Android for their HMI requirements?
Amazon’s Kindle Fire is an example of what is possible with Android when it is used outside of a smart-phone environment (see the figure). Amazon has leveraged the years of Android development supplied by Google to launch a tablet device with a highly intuitive HMI, based on Android and services catering to its customers.
The Fire is not and does not need to be a certified Google Android device. It cannot access the Android marketplace or Google Maps. Without Android, Amazon would have been limited to trying to create its own OS or using products that were made for powering a PC rather than a specialized computer.
Can any team follow in Amazon’s footsteps? Yes, but only if the team is making a device that doesn’t act exactly like a smart phone. Google provides Android as an open-source OS for anyone to download, modify, compile, and use.
If a vendor wants to utilize specific Google applications like Maps and the Android Marketplace, then Google must approve that vendor’s release of Android. The approval process can be lengthy and resource intensive, but it is not required if the standard Google services won’t be utilized.
Should every team follow in Amazon’s footsteps? Not necessarily. If a design calls for third-party hardware, drivers will have to be developed for Android. To let users benefit from the familiarity of the Android interface, touch is critical and some applications aren’t appropriate for touch interactions.
Yet just as smart-phone vendors were limited to a few good options before Android and iOS emerged, many system designers have been stuck trying to shove their HMI applications into Microsoft Windows when something a little more specialized would have been appropriate.
It’s too early to tell if the availability of an open-source OS with the popularity of Android will be as enabling to the device market outside of smart phones. But if I made cash registers, industrial automation systems, or other specialty devices, the combination of a mature OS backed by Google, no licensing costs or restrictions, and the rising familiarity of the interface to users and developers alike would be enough to make me pause for a moment and imagine the possibilities.
What do you think? Why wouldn’t Android be suitable for your HMI application?