Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
EE Times-Asia > Controls/MCUs

Design interfaces for device partners

Posted: 02 Jul 2007 ?? ?Print Version ?Bookmark and Share

Keywords:user interface design? wireless communications? graphics interface?

Making the user interface for a single device easy, slick, fun and fast is a challenge. If you have multiple devices that need to cooperate, the challenge increases dramatically. As wired and wireless communications hardware gets cheaper, the design opportunities for communicating devices become more common. For example, a Java applet on my cellphone can control my home security system. This pair of devices provides two user interfaces, and those user interfaces must combine to provide a rational final system.

Early adopters will be happy to fiddle with settings that ensure that all of their gadgets talk to one another. More mainstream users will want to minimize the number of times they have to think that they're controlling more than one device. The classic living room problem is having three remote controls, each of which can control volume, yet only one works on each system. This issue replicates itself in many other areas where a combination of devices must cooperate.

These scenarios provide two different user interfaces on two different devices. The designer must try to ensure that the two (or possibly more) devices present a coherent final system to the user. If you're designing both devices, you want to make the feel of both devices similar.

Primary, secondary
In some cases, one interface will provide all of the functionality available on the system, and the second interface will only provide a subset. For example, a Bluetooth-enabled watch from Fossil provides a secondary interface to a cellphone. The watch displays caller ID and lets the user hang up a call, but doesn't attempt to provide the full functionality on the cellphone.

When designing a secondary interface, consider whether you want all functionality in that interface or just a subset. Implementing a subset simplifies the secondary interface for both the users and designers. Users will understand why one of the interfaces provides fewer features. It may be because it's physically smaller or because it's expected to be used less often, or because the natural home of certain features is on the other interface.

Device talk
If your system works with many partner devices, the user may have to configure your system to enable it to communicate with the partner device in use. Consider the case where a serial link can be used to connect to a cellphone. The first device must know what RS-232 settings to use to communicate. Many cellphone makers sell cables that allow the serial port of the cellphone to be brought out to a DB9 connector that can then allow the phone to be used as a modem or to send text messages.

Speed and handshaking settings may vary from phone to phone, so the primary device must be able to configure the port. One approach is to let the user enter the Baud rate, parity options etc. to fully configure the serial port. This manual configuration might alienate novice users who have to scour their user manuals for serial port setting.

A second approach is to let the user enter the phone's make and model, and the primary device could then derive the serial port settings from an internal database. This multiple-choice approach is easier for the user, but may fail in cases of an incomplete table of phone models. If a new phone comes out next year, it won't be in the table. If the primary device is Internet-enabled, this problem could be solved by periodically downloading a new list of compatible devices.

The third option is automatic identification. The primary device can attempt a number of settings until one works and then issue commands that ask the cellphone to identify itself.

There are other scenarios where these three approaches apply. In some cases, more than one option is made available. So if the multiple choice option fails because a device isn't in the list, the user could have the option of manually configuring the interface.

If the device interacting with the user must communicate with a second device, this always introduces some delay. In many cases, the communications is very fast compared with the speed of the human interaction that the user doesn't notice the delay. But there are exceptions. If the communications is over the Internet, the speed might vary considerably.

Graphically speaking
Having a graphical interface can allow much larger variation in the interface being presented to the user. Some universal remote controls have a graphical display that can present an image that looks like the model of the remote being emulated. This means that all names and symbols can match the terminology and iconology used by the original remote control.

Graphics can allow the displayed user interface elements to be defined by either of the devices involved in the communications. In a menu-driven system, the set of items might be predefined, or they might be generated at runtime by one device and sent to the other device for display. This can raise interesting issues if the user interface must function in other languages besides English. It will be important that the language can be specified on the protocol between the two devices, as the menu items will need to be generated in the appropriate language.

- Niall Murphy
Embedded Systems Design

Article Comments - Design interfaces for device partner...
*? You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.

Back to Top