Murphy’s Last Column
Niall looks at the changes in user interface technology over the past few years and makes a few predictions about application upgrade and cloud connectivity.
Editor's note: Niall Murphy started writing about user interface design for Embedded Systems Programming magazine in 1995. He wrote the column Murphy's Law (archived at www.eetimes.com/4210709/ and at www.panelsoft.com/murphyslaw).
The term dedicated device is used to describe embedded systems that have a sole purpose; it's a term I often found useful for systems I worked on--they aren't general purpose computing devices like a personal computer or a tablet computer but have a sole purpose to fulfill. As with the smart phone, however, the feature set of a lot of devices is expanding to try to cover multiple unrelated areas. The screen in my car can function as a DVD player, a sat-nav, and a display for a reversing camera, as well as giving access to a range of air-conditioning and other comfort controls. In fact, the model presented to me as a user is of a single device capable of running several different unrelated applications. We're used to the concept of running multiple applications on a PC, and this concept has become popular on smart phones, but a combination of forces are making this model attractive on many other systems.
The general population has been exposed to the idea of an app market for phones, and this concept has influenced the way we think about updating the software on our computing devices. The previous way of getting new software onto a dedicated device was an unwieldy flash upgrade that required the user to manage the download usually with the assistance of an Internet-connected PC--and it was typically a complete upgrade with no flexibility to choose which components or applications you wanted.
More powerful processors make it practical to run a full-featured operating system instead of just a real-time kernel. This opens up a lot of potential for integrating existing applications into a product--in many cases the applications are far too large and complex for the manufacturer of the end-product to develop themselves. For example the Linux version of some popular sat-nav products can be integrated into systems like the in-car computer I described. They provide APIs to allow the application to be controlled by the custom hardware of that system and to provide signals to the application when, for example, the ignition starts or stops. Similarly the developer of the in-car system does not want to face the challenges of writing software to play a DVD. This range of applications can come from a diverse set of vendors as long as the platform is based on a well-established operating system.
At the moment, the markets for standalone apps is in the smart phone and tablet market--but now that the population has been seeded with people who understand the model, don't be surprised if your Android-powered in-car computer or set-top box allows you to download apps that have been written for that device. The goal in those cases is not to create a market with tens of thousands of applications, but to provide a software-deployment model that allows the end user the flexibility to include the features they want on their device and to leave out the features that only appeal to others. It also allows the manufacturer the flexibility to deploy more advanced features long after the original hardware has shipped. Flash upgrades never got us to that point for the majority of users, but the flexibility of a file system for storage on a general-purpose operating system combine to make this viable. So my next car will not just have a sat-nav, but will give me a choice of sat-nav applications from different vendors that I can download and use. Upgrading the current sat-nav software will be completely independent of upgrading the DVD player software.
It's all about the screen
Processing power is so cheap that the car manufacturer might have considered dedicating a separate computer to each of the applications above, but the driving force behind the decision to combine them is the display. The cost of the display is a big fraction of the overall cost. And the more money spent on the display, the better the user experience, but for every extra square inch of display, the greater the attraction of channelling more applications through that shared display. And why not put Skype or a weather app or a fuel consumption monitor app onto the display of a connected car.
It's not just the price and quality of the displays where our expectations have evolved. Twenty years ago I worked on a system with a touch screen, and we designed the start up screen to contain a 3D-looking button with the words "Touch Me" on it. Our concern was that the user would not realize that it was possible to touch the screen and would fumble around looking for off-screen buttons or a mouse device. A couple of days ago I handed my six-year-old daughter a digital camera and she was puzzled when the pictures on the display could not be resized with a two-fingered stretch gesture. Expectations have changed.
Who am I
As we become surrounded by more sophisticated displays, one of the biggest challenges is telling those devices who we are. There is a limit to the richness of the experience that the device can deliver without identifying the user. With personal computing devices you can dodge this step since my phone is always logged in as me. Developers of embedded systems often have to design for industrial or medical devices where a different user may start the device each day. In many cases, it's the employer who wants more data about who is using the device, but identifying the user also opens up opportunities to remember the preferences, which are personalized to that user.
If you want to customize the settings on a per-user basis you need to know who that user is. However once you give the user a password, you have to put all the infrastructure in place to allow the password to be changed and to give the user a path they can follow if they forget their password, and this infrastructure is unpleasant for the user. Innovation in this area is going to be driven by a combination of forces. Employers purchasing industrial equipment will want to know more about who was using the equipment and end users will want a customized experience without having to remember a sequence of 6 to 8 characters including one capital and one digit and at least one non-alphanumeric character--Oh rats i have forgotten it again, maybe I will just stick it to a piece of paper in front of the machine !
A key contributor to the personalized experience will be cloud storage. Ten years ago embedded systems designers fastidiously avoided having a server element in their design to avoid forcing the customer to deploy a server to support its devices, or the need for the manufacturer to provide a server somewhere on the internet, which becomes a single point of failure and a maintenance nightmare. Cloud computing has lowered the barrier to entry for this server element. Cloud computing providers such as the Amazon Web Service make it possible to deploy any number of computers on the internet with no hardware outlay or connectivity infrastructure concerns. The number of computers available can grow or shrink with demand. At the other end of the connection, the price of hardware and software to put an embedded system on the internet is constantly dropping, and many of our devices have other design reasons to be already connected, so the incremental cost might be zero.
So what opportunities does this open up? Consider the sat-nav application that I use on my phone. I may have stored favorite routes and destinations, or a history of past journeys. If I now switch to the sat-nav unit built into my car, I would like to have the same journeys and preferences available to me. The fact that I'm using a different physical device is a minor detail--the device should know who I am and present my data. However, a typical design today stores my data locally on the device just used and makes it impossible to synchronize the data with another instance of the application running on another device.
Two steps are required to move to the synchronization scenario described above. The first is that the storage can no longer be local. Instead of recording journeys on the flash drive of the device, it must be stored on a server in some easily discoverable part of the Internet. The second piece is the ability to log in. Once you move to the cloud, you have to identify yourself. But no one wants to type in a password, and so we need better solutions.
This is one area where software alone is not sufficient. Swipe cards and fingerprint detectors are hardware solutions that are more secure than passwords and more user friendly. RFID tags and other near-field devices provide great solutions. If you walk up to a device with an RFID tag in your pocket and the device immediately logs you in, the user effort of logging in vanishes to zero. It's also more secure since the device can detect when that user has walked away and so log them out. This is being used successfully to identify drivers of shared commercial vehicles, and the drivers key-ring is the obvious place to hand the RFID tag.
If I walk into a conference room and start to use the speaker phone to make a phone call, the RFID tag may identify me to the phone and now the phone at the other end can receive my name and number as the caller ID instead of the shared phone number of the conference room. I effectively logged into the speaker phone simply by walking up to it.
There are other interesting login solutions out there. Windows 8 has introduced the concept of a login picture. After you enter your user name, the computer presents a picture that the user previously chose, and, to confirm his identity, the user touches a few positions on the picture. For example, when setting up my password I might decide to use a picture of my favorite car and point to the back door followed by touching the middle of hood followed by touching one of the clouds in the sky behind the car. This doesn't solve the problem of users forgetting their password, but it may make it easier to remember, and it reduces the amount of typing to be done on a device that may not have a dedicated keyboard.
Once we have provided a login solution and cloud connectivity, I think embedded systems designers still face challenges that aren't present in the conventional computing environment. We often need to allow for intermittent internet connectivity since the environment might be mobile--and we don't want to render the device unusable because our vehicle is in a remote area. We also may need to provide the option of anonymous use. If the sat nav in my car does not recognise the driver, maybe it makes the routes personally chosen by the previous driver unavailable to the anonymous driver but allows this anonymous user to request new routes that in turn will be forgotten when the anonymous driver is later replaced by a driver with who validly identifies himself.
The way forward
Many of the steps forward in embedded systems makes them more like their desktop cousins. Personalized cloud storage and user identification will be another progression. Like many such advances, we can learn from having met the same issues on conventional PCs. Adopting these technologies will challenge us in areas like security, but the benefits of moving our data to the cloud where it can be shared across devices will be irresistible in many designs.
Niall Murphy, a software engineer, has been designing user interfaces for 20 years. He is the author of Front Panel: Designing Software for Embedded User Interfaces, has written over 50 magazine articles (many for this magazine), and currently writes the blog Usability Bites (http://embeddedgurus.com/usability-bites/). Murphy teaches and consults on building better user interfaces and has been a frequent speaker at the Embedded Systems Conference. For more information about him, go to www.panelsoft.com. Niall can be reached at email@example.com.
This content is provided courtesy of Embedded.com and Embedded Systems Design magazine.
See more content from Embedded Systems Design and Embedded Systems Programming magazines in the magazine archive.
This material was first printed in May 2012 Embedded Systems Design magazine.
Sign up for subscriptions and newsletters.
Copyright © 2012
UBM--All rights reserved.