High-Tech Samara

It was the junked Samara that saved us by becoming the chassis of Steering Wheel’s simulator. The Samara is a Russian-made family sedan with a reputation for providing good value for the money in the cheapest category of cars. It is technologically very basic, and the design is plain, even clumsy. The junkyard agreed to saw off the engine compartment and the entire rear from the B pillar back. In the spring of 1999 the Samara carcass was delivered to the brand-new high-tech palace in Ruoholahti, Helsinki, where the Research Center had just moved. The original intention was to install the Samara in the usability team’s offices. The mangled metal, however, bristling with protruding wires, did not conform to the style guidelines of the new information society—not even with the special wax job the junkyard threw in for free. After many acrimonious exchanges, a place for the Samara was found in the deepest recesses of the basement where nobody would catch sight of it—not even accidentally.

Samara was not chosen by coincidence. It suited the purpose because of its design and brand. The Samara dashboard has a very open design. The gauges are relatively small, and the dashboard is close to the window, far from the driver. It was easy to build a new, modifiable dashboard made of cardboard over it without having to completely dismantle the old one. The brand also had significance. While this project was under way, the possibility of future cooperation with the automotive industry was an open question, so we had to choose a brand that was neutral and could not imply a commitment to any manufacturer as a future development partner. Better yet, the Samara was ideally suited for the UI design’s rough and dirty prototyping philosophy: using cheap materials to build a deformed but working simulator. With cutting and delivery, the Samara cost EUR 500.

Researcher and prototype expert Topi Kaaresoja and design apprentice Janne Kouri started modifying the Samara immediately. They removed the center of the steering wheel, the pedals, the gearstick, and other unnecessary elements. The steering wheel axle was then attached to a PlayStation game controller wheel. The pedals were replaced with PlayStation pedals. The original gearstick was swapped out in favor of a new one that connected to the game controller’s gearshifter. The old dashboard supported a new one built of cardboard. It was covered with Velcro tape so that various equipment could be easily attached and relocated. The center of the steering wheel was also replaced with cardboard to house different types of switches.

At last the controls were connected to the game console and the console connected to a video projector placed first on the roof of the Samara, and later on a separate rack. The image was projected onto a wall 4 m in front of the Samara. This distance was deemed to be the shortest possible to allow a driver’s eyes to refocus between the road and the instrument panel on the dashboard. Speakers were installed in the ceiling of the cab to carry game sounds—sound plays an enormous role in creating a genuine experience in a simulator environment. It actually makes the driving experience easier because sound conveys a good sense of the vehicle’s speed and thus helps the driver instinctively respond to acceleration.

Finding a suitable driving game for the simulator was not a trivial task. Gran Tourismo, Monster Track Madness—luckily there were among us selfless researchers who tirelessly tested and compared games, tracks, and simulated vehicles for hours on end. There were games for PlayStation and driving simulators for PCs. Eventually, we settled on the Need for Speed for PlayStation. PC applications crashed, and restarting them was agonizingly slow. In most games, controlling the vehicle was excessively difficult. In Need for Speed, it became easy enough to control the car at slow speeds after practicing for a short while. But new problems arose when testing began: after the driver completed his first lap, the game, assuming that the driver had reached the intended goal, stopped and had to be rebooted. Were that to happen during a usability test session, task performance would be interrupted and test subjects would be distracted, interfering with results. Besides, we couldn’t face starting the game over and over again during each session. Eventually the problem was solved by the expedient of making a U-turn on the track at the start. By driving the track in the opposite direction, the driver eluded the game’s propensity to stop at the end of every lap—a perfectly impressive little innovation.

The next problem emerged during the first live tests. The members of the project group had driven the Samara a lot and were pleased and impressed with the video projector’s big picture. The test subjects, however, surprised us by suffering from motion sickness: Need for Speed routes cross rather hilly terrain with plenty of turns. The wall-sized motion picture captured the mind but, unfortunately, also some stomachs. For the remaining tests, the projector had to be replaced with a TV monitor placed in front of the Samara.

To record the tests a video system with two cameras and a video mixer was built around the Samara. The video system was totally separate from the actual driving simulator. Depending on the test, we recorded the driving performance from the monitor, the operation of the keyboard interface, the display of the user interface, the direction of the driver’s gaze, an overall view of the test situation, or some combination of these.

User interface simulations were captured by two videographics array (VGA)-resolution LCD color displays installed in the Samara—one in the instrument panel and the other on top of the center console. The displays were controlled with an industrial PC. The keys of the simulator and other controls were connected to the PC via a keystroke encoder. The moderator next to the car was equipped with a separate display and a mouse. All simulations were programmed using ToolBook and Delphi software packages.

Creating user interface simulations isn’t a matter of implementing a chain of well-reasoned concepts. Instead, plans progress according to the prototyping. Prototyping always begins on the basis of an indefinite description; you can’t expect to begin at the most natural starting point because that characteristic might not have been determined yet. While the plan is fluid, it will be impossible to hunt down the right components or to design the optimal software because anything can change. One interesting, new component can redefine the concept. From a designer’s standpoint, the prototype isn’t likely to change much, but all the work done to implement it might be wasted. Making a prototype is a continuous tradeoff of what can be frozen and what must be capable of adjustment. This kind of work is extremely stressful and frustrating. The unfinished prototype must constantly be available for testing and for different demonstration purposes. There is no time for applying finishing touches—at least not until the night before the test.

Because there is no time to spare, nothing can be built properly in a prototype. The solutions are made to function reasonably well and to be relatively durable. Everything in the Samara withstood the design team’s tests very well. The first test user steered a little harder than anyone in the design team, and the garden hose connecting the steering axle and the game controller couldn’t take it. Our response was to equip the axle with stoppers to prevent oversteering. Tests were put on hold for that.

One challenge of car UI design is to offer direct control to several functions, but in such a way that the user interface seems simple. A possible solution to this problem is to use multifunctional switches whereby one element can directly control many parameters. When we examined the usage logics of various solutions, five functional switches proved interesting. Sony car radios had such a switch—in the middle is a push button surrounded by a freely rotating ring, and a lever switch sits just outside the ring. The size of the element makes it easy to operate. All its parts are easy to adjust individually, but the totality looks clear and simple. The switch was not quite what we were looking for, but it was the closest ready-made element we were able to find. We purchased a car radio, disassembled it, and built the control element that we needed from the switch. Basing our calculations on those for the first element, we sized the control element’s connection onto the panel of our finished prototype. The concept required four similar elements, so we bought three more radios. After disassembling them we noticed that parts that appeared identical actually had internal dimensions different from those of the first one. There was no time to make a new panel, and since we had sawed the front panel into pieces, we doubted that the radios could be returned to the store. So we threw budgets to the wind and purchased new radios, this time being more careful to check the model markings. Our shelf now held eight functionally totally useless radios. The Samara was now ready for the track (Figs. 9.1 to 9.3).

Figure 9.1: Modified Navi-key-style UI controls on the gearshift knob.

Figure 9.2: The Samara is ready for the track.