Build the right UI for your complex embedded system


November 11, 2007

Colin WallsGeoff.Kendall,-November 11, 2007

The tradeoffs involved in building a UI can be many. Making the right choices can make or break your system.

The implementation of a sophisticated user interface (UI) brings a number of interesting challenges. It often leads to tradeoffs between the cost and difficulty of implementation versus the quality of the user experience. In the consumer space, the UI can make or break a product and have a lasting impact on a vendor's product line.

Let's first look at the different types of facilities and mechanisms found on today's typical UI. Processing a user's interactions with buttons and switches is quite straightforward. It's simply a matter of polling an interface frequently enough or responding to an interrupt. There are a few subtleties to keep in mind. For example, a switch or a button being pressed may be seen as a transition from "1" to "0," not vice versa as might be expected. Also, switch contacts have a tendency to bounce and without care, can be interpreted as a sequence of actuations.

Lamps are equally as simple. They're typically illuminated by setting a bit in a device register. This has a small challenge: registers are typically "write only" so the software can't read back the current state (a shadow copy of the data must be kept in RAM and used with care). Flashing lamps require some type of timing mechanism. This might be handled by a simple clock interrupt service routine, or a real-time operating system (RTOS) may be employed for the main application, which can accommodate the timing requirements. Simple alphanumeric displays are handled in much the same way as lamps.

Network interfaces
If a device has a network interface (typically wireless or Ethernet), an opportunity exists for the embedded software to communicate with users through other computers on the network, using all the flexibility the computer's GUI affords. A specific UI can be written to do this, or it can be handled by implementing an HTTP server (a Web server) in the device. The latter approach is flexible, as it lets the UI be defined with a series of hyperlinked HTML (Web) pages. You can also make the pages "smart" with scripting (like JavaScript) or even the Java language. An HTTP server requires an RTOS environment in which to run.

On devices with graphical screens--either full size, like a TV, or small, like a cell phone--the functionality may be defined quite precisely. Also, some common features may be leveraged. Although all of these mechanisms are found on today's UI and may seem simple in many respects, nonetheless developers must face some serious challenges when working at the application level.

The complexities of today's devices typically feature a wide range of functionality, often implemented in a number of different applications. A feature-rich cell phone, for example, will have Web browser, messaging, media playback, and address book along with the traditional phone functionality. It's not uncommon for each application to be developed separately, possibly by different companies. The result is that each application has its own UI, yet in every application, the UI is doing much the same work as the others, but in slightly different ways and often with a different look and feel. Unfortunately, this results in more development work (creating lots of UIs), and the user experience is compromised because the UIs aren't consistent.

Another challenge at the application level is the fact that the UI takes significant programming skill and effort to implement and, furthermore, to maintain and adapt to future needs.

< Previous
Page 1 of 3
Next >

Loading comments...