newsintrosystemsbudgetmediadiscussexternal
System A1

Content Loading...
system.a1 August 2002
System A1 tests an idea regarding sound-feedback based interfaces. It is able to be driven by as few as three keys, or preferably through a jog-dial controller.

In an high-risk environment such as driving a car, taking your eyes off the task at hand to see what buttons you're pressing on a control console can lead to serious injury - historically, automobile makers have addressed this issue by providing a multitude of control styles in different locations, with each input device corresponding to a particular function - so when you flick your indicator down, you know you're not honking your horn.

In contrast to this, a general purpose in-car computer can have an unknown number of unknown functions, and so requires a non-specific controller that can be easily understood by someone with no previous exposure to the system. It must also be able to quickly navigate to any specified item, without requiring the user (usually the driver) to take his or her eyes off the road.

While System A1 is built around the concept of being deployed in an automobile environment, it is intended for the resulting system to be used as a wearable computer; the safety and usability issues covered would make for a perfect non-intrusive wearable machine.
For the interface, a tree-based menu system (Figure 1). was chosen, as it could be reduced to a three key system - one key for each of 'next', 'previous' and 'select'. 'Next' and 'previous' move the selection focus within the current tree, 'Select' would either run the current item, or drill up or down through the menu system (it was decided that rather than have a dedicated 'back' button, every menu would have a 'back' item that would return the user to the previous menu). The user would be informed of her/her current position in the menu hierarchy through spoken cues.

Figure 1. Example hierarchical menu as would be used in a car
Several problems are immediately apparent with this approach - the user will have to press a lot of buttons to get where he or she is going, and certain controls (such as volume) could lead to the user having to repeatedly press or hold buttons. Further, the length of time taken to listen to the voice cues cause further delays and frustrations in menu navigations.

It was decided that some sort of 'knob' controller was needed to solve the usability problems - it would allow a user to quickly scroll through a list, and would be perfect for controlling analogue states such as volume. After a brief search, the Griffin Powermate (Figure 2) seemed to be one of the few consumer level products that could be used in this role, as in addition to being twisted, it can be clicked, providing all the required functionality (it also provides 'pressed+twisted' states that would prove useful later).

Figure 2. The Powermate
The second issue (user awareness of menu position) was tackled through adding a 0.5 second item-specific tone before the start of the vocalisation of that item's title. Playback would then be configured to only play one sound at a time. This would lead to a situation where a trained user would instantly be aware of what menu item is currently selected by its tone, allowing them to quickly navigate through the menus. Untrained users would still see benefit if the tones were assigned logically - the further down the current menu, the higher the tone, and so on. The tones of items in different menus would be generated by different instruments, giving an even greater sense of positional awareness. Finally, global menu items (such the 'back' item present at the end of all menus) would be given a standard tone and instrument.
Rather than bog down in continuous refinement of the ideas, we decided to then build the system. As a time-saving measure, only the music-control functionality would be present. Software development took two days (using Python) and no hardware modification was necessary. The final system consisted of a laptop, the Powermate and a pair of headphones (if this system was destined for a car, a cassette-deck adapter would be substituted).

After a minimal period of testing, it became apparent that it was still a pain to navigate through several menus - as a user, it's hard to go from the world of having any functionality available at a single press of a button, to having to manually scroll through menus.

Some of the problems were alleviated by using an additional property of the Powermate - it registered 'push+turn' events, adding the equivalence of two functional keys. This was used in the volume control, where instead of having to click-select volume, scrolling to the desired level then clicking to return, the user could simply highlight volume, click+turn to adjust, and release to return.
While this system never made it into a car, it did find a place as a home-entertainment device; one can control the music playing through playing with the Powermate, proving handy for locations where a keyboard+monitor (such as a living room) would be out of place. However in this situation, some form of text-based display would be desired, as the audio-only feedback could not convey enough information to the user to make the system a viable option.

For this to be usable as a wearable computer, the Powermate would have to be replaced by something much smaller - as it is, it's too bulky to fit in a pocket without attracting undue attention. The ideal device would be a bluetooth watch with a depressable bezel as the controller; the watch's display would also facilitate use of visual feedback as mentioned previously. The development of a wearable machine is covered in System A2...
Source Code
sa1_src_0.1.zip (275kB)

Equipment
Base System:Dell Inspiron 4100 Laptop
Interface:Griffin Powermate
width="120">Software Platform:Windows XP, Python

Key Features:
  • Wheel-driven input hardware.
  • Hierachical menu interface with audio-feedback.
  • Easily expandable.

People Involved
Glen Murphy



back to systems



printable version