Android会是未来人机界面系统的选择吗？

    人总是很难预料的，谁也说不准他们将如何与产品将交互。也许跟你预料的一样，人们会采用与测试时候相同的方法操作应用程序，也有可能把关闭窗口的按钮错认为是拷贝的按钮，最终沮丧地不停敲着键盘。

    为了把系统的人机界面（Human Machine Interface，HMI）做的尽可能直观并节省用户的时间，很多设计师基于知名的操作系统如微软的Windows设计人机界面。Windows伴随着很多人长大，他们了解如何操作鼠标操、、最小化窗口和启动程序。

    当采用Windows作为应用的外观的时候，这个应用的学习曲线会显著下降，用户操作不顺利或错误的情况也很可能会减少。而直到最近，用户和开发者都熟悉的操作系统都还很少，Windows当然也就成了系统设计师的普遍选择。

    但随着智能手机的兴起，用户和界面设计师迅速适应了这类全然不同的界面：更简单，更为设备优化。例如，Android手机非常受欢迎，即使它的人机界面和人们在计算机上的操作完全不同。

    移动平台得益于其让用户更高效完成特定任务的设计，同时利用了最新的技术如触摸屏。但这是否意味着，设计汽车、重型设备或POS系统的团队就应该考虑用Android来满足他们的人机界面需求呢？

亚马逊的策略

    亚马逊的Kindle Fire展现了Android在智能手机环境以外领域的可能性。亚马逊将Google在Android上的数年开发经验加以利用，推出了一款拥有高度直观的人机界面的平板设备，通过Android的基础和亚马逊的服务满足客户。

    Kindle Fire不是，也不需要成为Google Android的授权设备。它无法接入Android市场和Google地图。没有Android，亚马逊就会受到很大限制，它必须想办法创建一套自己的操作系统，或者采用PC而非定制化电脑所采用的系统。

    能有团队跟随亚马逊的脚步吗？是的，但团队必须也做和智能手机完全不同的产品。Google为Android系统开放了源代码，每个人都可以下载、更改、编译和使用。

    如果有厂商想要利用特定的Google应用例如地图和Android市场，Google就必须批准厂商的Android版本。批准的流程可能很长且很耗资源，但如果不是用标准的Google服务就不一定要获得批准。

    是不是每个团队都应该追随亚马逊的脚步？ 不见得。如果设计需要第三方硬件，就必须为Android写驱动程序。为了让用户从他们熟悉的Android界面获益，触摸非常关键，而一些程序并不适合触摸界面。

    正如在Android和iOS出现之前，智能手机厂商的操作系统选择并不多，当更需要合适且定制化的设计时，很多系统设计师就很难让他们的人机界面适应微软的Windows。

    流行的开源操作系统能否成为智能手机以外其他设备的系统选择还很难说，但如果要做收银系统、工业自动化系统或其他的特殊设备，Google的成熟操作系统、没有授权费用或限制、用户和开发者对界面更加熟悉等这些因素综合起来，就值得想想它的可能性。

你认为呢？ Android怎么会不适合用于人机界面呢？

下一页原文参考:Is Android The OS Of Choice For HMI In The Future?

文章来源:Electronic DesignIs Android The OS Of Choice For HMI In The Future?

Josh Neland

    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 Strategy

    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?