Past Project: Tomahawk Cruise Missile

After the MMWS project wrapped up, our team was then tasked to look at improving the user interface for the Tomahawk Cruise missile. The current system is quite odd. The entire process is broken into two major steps. There are two sets of two consoles each, with some interesting hand off between them. The officers themselves don’t have consoles.

This project was very different in a lot of ways. The biggest difference was the nature of the tasks. In the Air Defense project, each task is considered a point task. You do it and it is done. In the cruise missile world, tasks are MUCH longer (averaging 1-2 hours). Without giving away ’secrets’, to launch a cruise missile, there are several steps along the way: get the target, plan the routes, power the missile, launch it, monitor it, and do post attack assessment. The process also can skip back to previous steps.

The UI was heavily based on the Air Defense work, so nothing too earth-shaking. One change was the reduction of the number screens from 4 to 2.

The development team doubled in size for this project. I was joined by a great programmer, Rob Adams. He handled most of the mapping issues. There was a modest amount of missile route displays stuff to handle. It was nice to hand these tasks off, while I focused on creating an engine that would mimic the processes of a cruise missile system.

The development cycle followed the same cycle as the task, so we started at the first task, and moved forward from there, in a nice orderly sequence. After each step, we would run a series of user testing, folding the improvements back into the design, then move on to the next step.

From a development point of view, one of the coolest things was the under-the-hood code that I wrote. It was uber-geeky, but made the whole process very sweet. The engine turned out to be nice OOP based timer system with a robust callback system. To give a sense of scope, each missile would have its own set of timing for each step. A group of missiles would be clustered into packages. The entire package had to complete a step, before the next step in the sequence could move forward. Since the user could drill down into each step and see the status for each missile, all this had to be exposed.

It was a fun challenge. All told, this project was lighter than the ADW, at just 30,000 lines of Lingo. I never did get to see a real launch. Once 9/11 occurred and we saw the number of Tomahawks strike Afghanistan (@ $750,000 per missile), we knew that the R&D budget was going to take a hit.

Past Project: Multi-Modal Watch Station

The Multi-Modal Watch Station was an effort funded by the Office of Naval Research(ONR) and was an AEGIS Cruiser Air-Defense Simulation of a Combat Information Center team, performing air defense for a U.S. Navy battle group. Our teams of developers and designers were investigating how various HCIs could be used to reduce workload and improve performance. I was hired to lead the rapid prototyping effort, while a team of JAVA programmers worked on a ‘real’ version. Our first system was a beast! We had 6 Wacom 800×600 touch screens wired together, and there was also a seventh display in the form of a Head Mounted display. The HMD was further enhanced with a head tracker. The first prototypes were very ‘golden path’-only designs. Demos were a lot of fun, since we only had two projectors, so while we were running through the script, it was my job to toggle the various AV switches. For the second version, the screens were greatly improved. The new console now had 3 1280×1024 LCDs with touch and a fourth 1024×768. A custom console had also been built.

The Console

After we had redesigned the interfaces to the larger displays, we began rebuilding the prototype to allow more freedom for the user. The effort now also changed focus, as we needed to validate the designs against the actual AEGIS user interface. So, an actual scenario was chosen, and the team began building out the screens and user tasks needed for the scenario.

The Task Manager Displays

One of the driving concepts behind this effort was task management. Current systems require the sailors to ‘hunt and peck’ on tracks (airplanes, ships, etc) and then figure out what tasks they need to perform. Our system automated a lot of this effort. Track status reports were auto-generated and logged. The user still reviewed the data gathered by the system, but it became a lot easier to manage. We even introduced a text to speech engine, so they no longer had to issue the verbal reports themselves. This system even had a priority system, so important reports were issued first. I kept banging away, and the lines of Lingo kept piling up. The whole system was huge set of Movies In A Window.

A large display sample

Each of the large displays had the same basic setup, but based on the type of task the operator was doing, various components would change out. One universal truth about dealing with sailors, they all want MORE MAP! The other modules on the right are various Close Control Read Outs (CCROs). They inform the sailor of various pieces of data about the task or track. Along the bottom is a list of outstanding tasks. Throughout the development, we were conducting a variety of usability tests about the UI. A data logger was added to the code. I suspect that the data may still be used by some of the researchers at SPAWAR Systems Center, San Diego. The JAVA team had been tasked with developing two versions: a basic MMWS and an advanced MMWS, while I kept in front validating designs before they rebuilt them. The idea was by doing two versions, we could measure which enhancements offered more improvements against their cost to develop. However, they were running into a variety of issues (connecting to the actual training simulators, etc.). Since the prototype was in fact the advanced UI version, we committed to completing that UI for the usability studies. So now, I had to scale this prototype from a single user, to a multi-user real time system. Leveraging the now defunct Multi User System (see the article I wrote on Multi User System at Director-Online), and with help from a great intern, we were able to encode the entire 2 hour scenario. Previously we had only run the first 30 minutes, in case we had to use the participant again. The intern also served as my QA. Finally, we had fully networked MMWS. There were five primary consoles, and six stations for various role players. In the end, there were about 80,000 lines of Lingo running the system. Tests went fine. Both systems did really well in the study. Sadly, various issues ended the program, but it was a lot of fun to develop. The project evolved into the Tomahawk Cruise Missile Project.