Escape pod and insertion windows

11 Dec 2014 by Christopher Noessel

When the Rodger Young is destroyed by fire from the Plasma Bugs on Planet P, Ibanez and Barcalow luckily find a functional escape pod and jettison. Though this pod’s interface stays off camera for almost the whole scene, the pod is knocked and buffeted by collisions in the debris cloud outside the ship, and in one jolt we see the interface for a fraction of a second. If it looks familiar, it is not from anything in Starship Troopers.

The interface features a red wireframe image of the planet below, outlined by a screen-green outline, oriented to match the planet’s appearance out the viewport. Overlaid on this is a set of screen-green rectangles, twisting as they extend in space (and time) towards the planet. These convey the ideal path for the ship to take as it approaches the planet.

I’ve looked through all the screen grabs I’ve made for this movie, and there no other twisting-rectangle interfaces that I can find. (There’s this, but it’s a status-indicator.) It does, however, bear an uncanny resemblance to an interface from a different movie made 18 years earlier: Alien. Compare the shot above to the shot below, which is the interface Ash uses to pilot the dropship from the Nostromo to LV-426.

It’s certainly not the same interface, the most obvious aspect of which is the blue chrome and data, absent from Ibanez’ screen. But the wireframe planet and twisting rectangles of Starship Troopers are so reminiscent of Alien that it must be at least an homage.

Planet P, we have a problem

Whether homage, theft, or coincidence, each of these has a problem as far as the interaction design. The rectangles certainly show the pilot an ideal path in a way that can instantly be understood even by us non-pilots. At a glance we understand that Ibanez should roll her pod to the right. Ash will need to roll his to the left. But how are they actually doing against this ideal? How is the pilot doing compared to that goal at the moment? How is she trending? It’s as if they were driving a car and being told “stay in the center of the middle lane” without being told how close to either edge they were actually driving.

Rectangle to rectangle?

The system could use the current alignment of the frame of the screen itself to the foremost rectangle in the graphic, but I don’t think that’s what happening. The rectangles don’t match the ratio of the frame. Additionally, the foremost rectangle is not given any highlight to draw the pilot’s attention to it as the next task, which you’d expect. Finally that’s a level of abstraction that wouldn’t fit the narrative as well, to immediately convey the purpose of the interface.

Show me me

Ash may see some of that comparison-to-ideal information in blue, but the edge of the screen is the wrong place for it. His attention would be split amongst three loci of attention: the viewport, the graphic display, and the text display. That’s too many. You want users to see information first, and read it secondarily if they need more detail. If we wanted a single locus of attention, you could put ideal, current state, and trends all as a a heads-up display augmenting the viewport (as I recommended for the Rodger Young earlier).

If that broke the diegesis too much, you can at least add to the screen interface an avatar of the ship, in a third-person overhead view. That would give the pilot an immediate sense of where their ship currently is in relation to the ideal. A projection line could show the way the ship is trending in the future, highlighting whether things are on a good or not so good path. Numerical details could augment these overlays.

By showing the pilot themselves in the interface—like the common 3rd person view in modern racing video games—pilots would not just have the ideal path described, but the information they need to keep their vessels on track.

The Lifeboat Controls

2 Jan 2014 by claytonbeese

After Wall-E and Eve return to the Axiom, Otto steals the Earth plant and has his security bot place it on a lifeboat for removal from the ship. Wall-E follows the plant onboard the pod, and is launched from the Axiom when the security bot remotely activates the pod. The Pod has an autopilot function (labeled an auto-lock, and not obviously sentient), and a Self-Destruct function, both of which the security bot activates at launch. Wall-E first tries to turn the auto-pilot off by pushing the large red button on the control panel. This doesn’t work.

Wall-E then desperately tries to turn off the auto-destruct by randomly pushing buttons on the pod’s control panel. He quickly gives up as the destruct continues counting down and he makes no progress on turning it off. In desperation, Wall-E grabs a fire extinguisher and pulls the emergency exit handle on the main door of the pod to escape.

The Auto-Destruct

There are two phases of display on the controls for the Auto-Destruct system: off and countdown. In its off mode, the area of the display dedicated to the destruct countdown is plain and blue, with no label or number. The large physical button in the center is unlit and hidden, flush with the console. There is no indication of which sequence of keypresses activates the auto-destruct.

When it’s on, the area turns bright red, with a pulsing countdown in large numbers, a large ‘Auto-Destruct’ label on the left. The giant red pushbutton in the center is elevated above the console, surrounded by hazard striping, and lit from within.

The odd part is that when the button in the center gets pushed down, nothing happens. This is the first thing Wall-E does to turn the system off, and it’s has every affordance for being a button to stop the auto-destruct panel in which it sits. It’s possible that this center button is really just a pop-up alert light to add immediacy to the audible and other visual cues of impending destruction.

If so, the pod’s controls are seriously inadequate.

Wall-E wants to shut the system off, and the button is the most obvious choice for that action. Self-destruction is an irreversible process. If accidentally activated, it is something that needs to be immediately shut off. It is also something that would cause panicked decision making in the escape pod’s users.

The blinking button in the center of the control area is the best and most obvious target to “SHUT IT OFF NOW!”

Of course this is just part of the fish-out-of-water humor of the scene, but is there a real reason it’s not responding like it obviously should? One possibility is that the pod is running an authority scan of all the occupants (much like the Gatekeeper for the bridge or what I suggested for Eve’s gun), and is deciding that Wall-E isn’t cleared to use that control. If so, that kind of biometric scanning should be disabled for a control like the Anti-Auto-Destruct. None of the other controls (up to and including the airlock door exit) are disabled in the same way, which causes serious cognitive dissonance for Wall-E.

The Axiom is able to defend itself from anyone interested in taking advantage of this system through the use of weapons like Eve’s gun and the Security robots’ force fields.

Anything that causes such a serious effect should have an undo or an off switch. The duration of the countdown gives Wall-E plenty of time to react, but the pod should accept that panicked response as a request to turn the destruct off, especially as a fail-safe in case its biometric scan isn’t functioning properly, and there might be lives in the balance.

The Other Controls

No Labels.

Seriously?

This escape pod is meant to be used in an emergency, and so the automatic systems should degrade as gracefully as possible.

While beautiful, extremely well grouped by apparent function, and incredibly responsive to touch inputs, labels would have made the control panel usable for even a moderately skilled crewmember in the pilot seat. Labels would also provide reinforcement of a crew member’s training in a panic-driven situation.

Buy-N-Large: Beautifully Designed Dystopia

A design should empower the people using it, and provide reinforcement to expert training in a situation where memory can be strained because of panic. The escape-pod has many benefits: clear seating positions, several emergency launch controls, and an effective auto-pilot. Adding extra backups to provide context for a panicked human pilot would add to the pod’s safety and help crew and passengers understand their options in an emergency.

Fhloston evacuation

23 May 2013 by Christopher Noessel

When Fhloston Paradise’s bomb alarms finally go off (a full 15:06 after Zorg’s bomb actually starts. WTH, Fhloston?) four shipwide systems help evacuate the ship.

First, a klaxon is heard on a public address system across the ship. A recorded female voice calmly announces that…

This is a type A alert. For security reasons the hotel must be evacuated. Please proceed calmly to the lifeboats located in the main hallways.

This voice continues to speak a warning countdown, repeating the remaining time every minute, and then when there’s less than a minute at 15 second intervals, and each of the last 10 seconds.

Second, in the main hallway, small, rows of red beacon lights emerge out of the floor and begin flashing and blinking. They repeatedly flash in order to point the direction of the lifeboats.

Third, in the main hallway large arrows on the floor and “LIFEBOAT” lettering illuminate green to point travelers towards ingress points for individual lifeboats.

Fourth, the lifeboats themselves eject from the ship to get the passengers far from danger.

Awesome

The voice warning is a trope, but a trope for a reason. For visually impaired guests and people whose attention is focused on, you know, escape, the audio will still help them keep tabs on the time they have left.
The racing lights provide a nice directionality (a similar interface would have helped Prometheus).
The arrows and beacons require no language skills to comprehend.

Awful

The voice warning and the “LIFEBOAT” signs do require language to comprehend. They couldn’t have used Running Man?
You know when’s a crappy time to add trip hazards to the floor? When a herd of panicked humans are going to be running over it. Seriously. There is no excuse for this.
The beacons and the arrows should be the same color. Green is the ISO standard for exit, so while we’re moving the beacon lights to the ceiling where they belong, we can swap them out for some #33cc00 beacons.
The green arrows at first seem badly placed as it’s difficult to see when there’s a crowd of people, but then you realize that when the room is empty, people will see and follow them. People in a crowd will just follow whatever direction the horde is currently going, and seeing the arrows is unnecessary. But in a light crowd, people will get a glimpse of the arrow and become stressed out over an occluded, potentially life-saving signal or worse, get trampled to death trying to stop and read it to make sure everyone is going the right way, so ultimately awful. Put that up on the ceiling or high on the walls, too. Because people genuinely panic.

Escape Pod

29 Jan 2013 by Christopher Noessel

When Vickers realizes Janek is really mutinying and going to ram the alien ship with the Prometheus, she has only 40 seconds to flee to an escape pod. She races to the escape room and slams her hand on a waist-high box mounted on the wall next to one of the pods. The clear, protective door over the pod lifts. She hurriedly dons her environment suit and throws herself into one of the coffin-shaped alcoves. She reaches to her right and on a pad we can’t see, she presses five buttons in sequence, shouting, “Come on!” The pod is sealed and shot away from the ship to land on the planet below.

The transparent cover gives a clear view into the pod. That’s great, since if there were multiple people trying to escape, it would be easier to target an empty one. The the shape inside is unmistakeable. That’s great because at a glance even an untrained passenger could figure out what this is. The bright orange stripes are appropriately intense and attention-getting as well.

Viewers might have questions about the placement of the back-lit button panels inside the pod, seeing as how they’re in a very awkward place for Vickers to see and operate. I presume she has some other interface facing her, and the panels we see in the scene are for operating when the pod is resting on the planet’s surface and its lid opened. From that position, these buttons make more sense.

I think that’s where the greatness ends. The main consideration for an escape pod is that it is used in dire emergencies. Fractions of a second might mean the difference between safety and disintegration, and so though the cinematic tension in the scene is built up by these designed-in delays, an ideal system shouldn’t work the same way. How could it be improved? There are three delays, and each of them could be improved or removed.

Delay 1: Opening a pod

Why should she have to open the pod with a button or handprint reader or whatever that thing is? The pods should be open at all times.

If pods had to be sealed for some biological or mechanical reason, then a pod should open up for her immediately when she enters the room. Simple motion detectors are all that is needed.

If she has to authorize for some dystopian, only-certain-people-can-be-saved corporate reason, then a voice print could work, allowing her to shout in the hallway as she runs for the pod.

Some passive recognition would be even better since it wouldn’t cost her even the time of shouting: Face-recognition or fast retinal scan through cameras mounted in the room or the pod. Run a quick laser line across her face and she’s authorized.

Delay 2: Suiting Up

Can she put on the environment suit in the pod? Yes, the pod is cramped, but that’s the biggest delay she experiences. Increase the size of the pod slightly to allow for that kind of maneuvering, and then she can just grab the suit as she’s running by and put it on in the pod’s relative safety.

Even cooler would be if the pod was the environment suit: All she would have to do is throw herself in the pod, activate it, and the minute she landed on LV223, the capsule transformed, Autobot-style, into an exosuit, giving her more protection and more enhancement for survival on an alien planet. Plus, you can imagine the awesomeness of letting Vickers fight the zombified Weyland Ripley-style.

Delay 3: Activation

This is one delay that I’m pretty sure can’t be either automatic or passive. The cost of making a mistake is too dire. Accidentally pressed a button? Sorry, you’re now being shot away from the mother ship faster than it can travel. Still, why does she have to hit a series of buttons here? Is it a (shudder) password, as a corporate cost-control measure? Yes, that spells dystopia, but it should be faster and more intuitive, and we’ve already authorized her, above.

Fortunately this doesn’t need much rethinking. Since we’ve already seen a great interaction used for an emergency procedure, i.e. the 5-finger touch-twist used for emergency decontamination on the MedPod, I’d suggest using that. Crew would only have to be trained once.

The total interaction, then, should be that Vickers:

Runs to the escape room
Is identified passively (and notified of it by voice)
Grabs a suit (this is optional if you go with the awesome exosuit idea)
Throws herself into an open pod
Performs a simple gesture on a touch pad
Is shot away from the soon-to-explode ship

Bam! You have saved massive amounts of time, a crewmember removed from the immediate danger, and you have the setup for an awesome ending where Vickers in her exosuit can just punch the falling alien spaceship out of the the way rather than running from it like a moron.

Sci-fi interfaces

Stop watching sci-fi. Start using it.

Tag Archives: escape pod