High Tech Binoculars

In Johnny Mnemonic we see two different types of binoculars with augmented reality overlays and other enhancements: Yakuz-oculars, and LoTek-oculars.

Yakuz-oculars

The Yakuza are the last to be seen but also the simpler of the two. They look just like a pair of current day binoculars, but this is the view when the leader surveys the LoTek bridge.

jm-25-yakuza-binocs-adjusted

I assume that the characters here are Japanese? Anyone?

In the centre is a fixed-size green reticule. At the bottom right is what looks like the magnification factor. At the top left and bottom left are numbers, using Western digits, that change as the binoculars move. Without knowing what the labels are I can only guess that they could be azimuth and elevation angles, or distance and height to the centre of the reticule. (The latter implies some sort of rangefinder.) Continue reading

Airport Security

After fleeing the Yakuza in the hotel, Johnny arrives in the Free City of Newark, and has to go through immigration control. This process appears to be entirely automated, starting with an electronic passport reader.

jm-9-customs-b

After that there is a security scanner, which is reminiscent of HAL from the film 2001: A Space Odyssey.

jm-9-customs-f

The green light runs over Johnny from top to bottom. Continue reading

Motion Detector

Johnny, with newly upgraded memory, goes straight to the hotel room where he meets the client’s scientists. Before the data upload, he quickly installs a motion detector on the hotel suite door. This is a black box that he carries clipped to his belt. He uses his thumb to activate it as he takes hold and two glowing red status lights appear.

jm-5-motion-detector-a-adjusted

Once placed on the door, there is just one glowing light. We don’t see exactly how Johnny controls the device, but for something this simple just one touch button would be sufficient.

jm-5-motion-detector-b-adjusted

A little later, after the brain upload (discussed in the next post), the motion detector goes off when four heavily armed Yakuza arrive outside the door. The single light starts blinking, and there’s a high pitched beep similar to a smoke alarm, but quieter. Continue reading

Perimeter Fences

Jurassic_Park_Perimeter_Fences01Each of the dinosaur paddocks in Jurassic Park is surrounded by a large electric fence on a dedicated power circuit that is controlled from the Central Control Room. The fences have regular signage warning of danger…

Jurassic_Park_Perimeter_Fences04…and large lamps at the top of many towers with amber and blue lights indicating the status of the fence.

Jurassic_Park_Perimeter_Fences02 Continue reading

Contact!

image04

Jack lands in a ruined stadium to do some repairs on a fallen drone. After he’s done, the drone takes a while to reboot, so while he waits, Jack’s mind drifts to the stadium and the memories he has of it.

Present information as it might be shared

Vika was in comms with Jack when she notices the alarm signal from the desktop interface. Her screen displays an all-caps red overlay reading ALERT, and a diamond overlaying the unidentified object careening toward him. She yells, “Contact! Left contact!” at Jack.

image02

As Jack hears Vika’s warning, he turns to look drawing his pistol reflexively as he crouches. While the weapon is loading he notices that the cause of the warning was just a small, not-so-hostile dog. Continue reading

Little boxes on the interface

StarshipT-undocking01

After recklessly undocking we see Ibanez using an interface of…an indeterminate nature.

Through the front viewport Ibanez can see the cables and some small portion of the docking station. That’s not enough for her backup maneuver. To help her with that, she uses the display in front of her…or at least I think she does.

Undocking_stabilization

The display is a yellow wireframe box that moves “backwards” as the vessel moves backwards. It’s almost as if the screen displayed a giant wireframe airduct through which they moved. That might be useful for understanding the vessel’s movement when visual data is scarce, such as navigating in empty space with nothing but distant stars for reckoning. But here she has more than enough visual cues to understand the motion of the ship: If the massive space dock was not enough, there’s that giant moon thing just beyond. So I think understanding the vessel’s basic motion in space isn’t priority while undocking. More important is to help her understand the position of collision threats, and I cannot explain how this interface does that in any but the feeblest of ways.

If you watch the motion of the screen, it stays perfectly still even as you can see the vessel moving and turning. (In that animated gif I steadied the camera motion.) So What’s it describing? The ideal maneuver? Why doesn’t it show her a visual signal of how well she’s doing against that goal? (Video games have nailed this. The “driving line” in Gran Turismo 6 comes to mind.)

Gran Turismo driving line

If it’s not helping her avoid collisions, the high-contrast motion of the “airduct” is a great deal of visual distraction for very little payoff. That wouldn’t be interaction so much as a neurological distraction from the task at hand. So I even have to dispense with my usual New Criticism stance of accepting it as if it was perfect. Because if this was the intention of the interface, it would be encouraging disaster.

StarshipT-undocking17

The ship does have some environmental sensors, since when it is 5 meters from the “object,” i.e. the dock, a voiceover states this fact to everyone in the bridge. Note that it’s not panicked, even though that’s relatively like being a peach-skin away from a hull breach of bajillions of credits of damage. No, the voice just says it, like it was remarking about a penny it happened to see on the sidewalk. “Three meters from object,” is said with the same dispassion moments later, even though that’s a loss of 40% of the prior distance. “Clear” is spoken with the same dispassion, even though it should be saying, “Court Martial in process…” Even the tiny little rill of an “alarm” that plays under the scene sounds more like your sister hasn’t responded to her Radio Shack alarm clock in the next room rather than—as it should be—a throbbing alert.

StarshipT-undocking24

Since the interface does not help her, actively distracts her, and underplays the severity of the danger, is there any apology for this?

1. Better: A viewscreen

Starship Troopers happened before the popularization of augmented reality, so we can forgive the film for not adopting that technology, even though it might have been useful. AR might have been a lot for the film to explain to a 1997 audience. But the movie was made long after the popularization of the viewscreen forward display in Star Trek. Of course it’s embracing a unique aesthetic, but focusing on utility: Replace the glass in front of her with a similar viewscreen, and you can even virtually shift her view to the back of the Rodger Young. If she is distracted by the “feeling” of the thrusters, perhaps a second screen behind her will let her swivel around to pilot “backwards.” With this viewscreen she’s got some (virtual) visual information about collision threats coming her way. Plus, you could augment that view with precise proximity warnings, and yes, if you want, air duct animations showing the ideal path (similar to what they did in Alien).

2. VP

The viewscreen solution still puts some burden on her as a pilot to translate 2D information on the viewscreen to 3D reality. Sure, that’s often the job of a pilot, but can we make that part of the job easier? Note that Starship Troopers was also created after the popularization of volumetric projections in Star Wars, so that might have been a candidate, too, with some third person display nearby that showed her the 3D information in an augmented way that is fast and easy for her to interpret.

3. Autopilot or docking tug-drones

Yes, this scene is about her character, but if you were designing for the real world, this is a maneuver that an agentive interface can handle. Let the autopilot handle it, or adorable little “tug-boat” drones.

StarshipT-undocking25

The Lifeboat Controls

WallE-Lifeboat05

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.

WallE-Lifeboat04

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.

WallE-Lifeboat08

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.

WallE-Lifeboat07

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

WallE-Lifeboat03

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.

WallE-Lifeboat02

Dust Storm Alert

WallE-DustStorm04

While preparing for his night cycle, Wall-E is standing at the back of his transport/home. On the back drop door of the transport, he is cleaning out his collection cooler. In the middle of this ritual, an alert sounds from his external speakers. Concerned by the sound, Wall-E looks up to see a dust storm approaching. After seeing this, he hurries to finish cleaning his cooler and seal the door of the transport.

A Well Practiced Design

The Dust Storm Alert appears to override Wall-E’s main window into the world: his eyes. This is done to warn him of a very serious event that could damage him or permanently shut him down. What is interesting is that he doesn’t appear to register a visual response first. Instead, we first hear the audio alert, then Wall-E’s eye-view shows the visual alert afterward.

Given the order of the two parts of the alert, the audible part was considered the most important piece of information by Wall-E’s designers. It comes first, is unidirectional as well as loud enough for everyone to hear, and is followed by more explicit information.

WallE-DustStorm01

Equal Opportunity Alerts

By having the audible alert first, all Wall-E units, other robots, and people in the area would be alerted of a major event. Then, the Wall-E units would be given the additional information like range and direction that they need to act. Either because of training or pre-programmed instructions, Wall-E’s vision does not actually tell him what the alert is for, or what action he should take to be safe. This could also be similar to tornado sirens, where each individual is expected to know where they are and what the safest nearby location is.

For humans interacting alongside Wall-E units each person should have their own heads-up display, likely similar to a Google-glass device. When a Wall-E unit gets a dust storm alert, the human could then receive a sympathetic alert and guidance to the nearest safe area. Combined with regular training and storm drills, people in the wastelands of Earth would then know exactly what to do.

Why Not Network It?

Whether by luck or proper programming, the alert is triggered with just enough time for Wall-E to get back to his shelter before the worst of the storm hits. Given that the alert didn’t trigger until Wall-E was able to see the dust cloud for himself, this feels like very short notice. Too short notice. A good improvement to the system would be a connection up to a weather satellite in orbit, or a weather broadcast in the city. This would allow him to be pre-warned and take shelter well before any of the storm hits, protecting him and his solar collectors.

Other than this, the alert system is effective. It warns Wall-E of the approaching storm in time to act, and it also warns everyone in the local vicinity of the same issue. While the alert doesn’t inform everyone of what is happening, at least one actor (Wall-E) knows what it means and knows how to react. As with any storm warning system, having a connection that can provide forecasts of potentially dangerous weather would be a huge plus.

Nucleolab Progress Indicator

FifthE-nucleolab-009

As the nucleolab is reconstructing Leeloo, the screen on the control panel provides update, detailing the process. For the most part this update is a wireframe version of what everyone can see with their eyes.

FifthE-nucleolab-029

FifthE-nucleolab-015

The only time it describes something we can’t see with our own eyes is when Leeloo’s skin is being “baked” by an ultraviolet light under a metal cover. Of course we know this is a narrative device to heighten the power of the big reveal, but it’s also an opportunity for the interface to actually do something useful. It has a green countdown clock, and visualizes something that’s hidden from view.

FifthE-nucleolab-020

As far as a progress indicator goes, it’s mostly useful. Mactilburgh presumably knows roughly how long things take and even the order of operations. All he needs is confirmation that his system is doing what it’s supposed to be, and the absence of an error is enough for him. The timer helps, too, since he’s like a kid waiting for an Easy Bake Oven…of science.

But Munro doesn’t know what the heck is going on. Sure he knows some of the basics of biology. There’s going to be a skeleton, some muscle, some nerves. But beyond that, he’s got a job to do, and that’s to take this thing out the minute it goes pear-shaped. So he needs to know: Is everything going OK? Should I pop the top on a tall boy of Big Red Button? It might be that the interface has some kind of Dire Warning mode for when things go off the rails, but that doesn’t help during the good times. Giving Munro some small indicator that things are going well would remove any ambiguity and set him at ease.

An argument could be made that you don’t want Munro at ease, but a false positive might kill Leeloo and risk the world. A false negative (or a late negative) just risks her escape. Which happens anyway. Fortunately for us.

FifthE-nucleolab-024

Taxi navigation

FifthE-attackdetection-001

The taxi has a screen on the passenger’s side dashboard that faces the driver. This display does two things. First, it warns the driver when the taxi is about to be attacked. Secondly, it helps him navigate the complexities of New York circa 2163.

Warning system

After Korben decides to help Leeloo escape the police, they send a squadron of cop cars to apprehend them. And by apprehend I mean blow to smithereens. The moment Korben’s taxi is in sights, they don’t try to detain or disable the vehicle, but to blast it to bits with bullets and more bullets. It seems this is a common enough thing to have happen that Korben’s on-board computer can detect it in advance and provide a big, flashing, noisemaking warning to this effect.

FifthE-attackdetection-008

In many cases I object to the Big Label, but not here. In fact, for such a life-threatening issue, more of the taxi’s interface should highlight the seriousness. My life’s in danger? Go full red alert, car. Change the lights to crimson. Dim non-essential things. You’ve got an “automatic” button there. Does that include evasive maneuvering? If so, make that thing opt-out rather than opt-in. Help a brother out.

Navigation aid

At other times during the chase scene, Korben can glance at the screen to see a wireframe of the local surroundings. This interface has a lot of problems.

1. This would work much, much more safely and efficiently for Korben if it was a heads-up display on the windshield. Let’s shrink that feedback loop. Every time a driver glances down he risks a crash and in this case, Korben risks the entire world. If HUD tech isn’t a part of the diegesis, audio cues might be some small help that don’t require him to take his eyes of the “road.”

2. How does the wireframe style help? It’s future-y of course, but it adds a lot of noise to what he’s got to process. He doesn’t need to understand tesselations of surfaces. He needs to understand the shapes and velocities of things around him so he can lose the tail.

FifthE-attackdetection-006

(Exercise for the reader: Provide a solid diegetic explanation for why this screen appeared in the film flipped horizontally.)

FifthE-attackdetection-010

3. There’s some missing information. If the onboard computer can do some real-time calculations and make a recommendation on the best next step, why not do it? We see above that the police have the same information that Korben does. So even better might be information on what the tail is likely to do so Korben can do the opposite. Or maneuvers that Korben can execute that the cop car can’t. If it’s possible to show places he should definitely not go, like dead ends or right into the path, say, of a firing squad of police cars, that would be useful to know, too.

FifthE-attackdetection-002

FifthE-attackdetection-004

4. What are those icons in the lower right meant to do? They’re not suggestions as they appear after Korben performs his maneuvers, and sometimes appear along with warnings instead of maneuvers.

Even if they are suggestions, what are they directions to? His original destination? He didn’t have one. Some new destination? When did he provide it? Simple, goal-aware directions to safety? Whatever the information, these icons add a lot cognitive weight and visual work. Surely there’s some more direct way to provide cues, like being superimposed on the 3D so he can see the information rather than read and interpret it.

If they’re something else other than suggestions, they’re just noise. In a pursuit scenario, you’d want to strip that stuff out of the interface.

FifthE-attackdetection-003

5. What is that color gradient on the left meant to tell him? All the walls in this corridor are 350…what? The screen shot above hints that it represents simple height from the ground, but the 2D map has these colors as well, and height cues wouldn’t make sense there. If it is height, this information might help Korben quickly build a 3D mental map of the information he’s seeing. But using arbitrary colors forces him to remember what each color means. Better would be to use something with a natural order to it like the visible spectrum or black-body spectrum. Or, since people already have lots of experience with monocular distance cues and lighting from above, maybe a simple rendering as if the shapes were sunlit would be fastest to process. Taking advantage of any of these perceptual faculties would let him build a 3D model quickly so he can focus on what he’s going to do with the information.

Side note: Density might actually make a great deal more sense to the readout, knowing that Korben has a penchant for ramming his taxi through things. If this was the information being conveyed, varying degrees of transparency might have served him better to know what he can smash through safely, and even what to expect on the other side.

6. Having the 2D map helps a bit to understand the current level of the city from a top-down view. Having it be small in the upper right is a sound placement, since that’s a less-important subset of the information he really needs. It has some color coding but as mentioned above it doesn’t seem to relate to what’s colored in the 3D portion, which could make for an interpretation disaster. In any case, Korben shouldn’t have to read this information in the tiny map. It’s a mode, a distraction. While he’s navigating the alleys and tunnels of the city, he’s thinking in a kind of 3D node-graph. Respect that kind of thinking with a HUD that puts information on the “edges” of the graph, i.e., the holes in the surfaces around him that he’s looking at. That’s his locus of attention. That’s where he’s thinking. Augment that.

So, you know…bad

Fortunately, given that the interface has so many problems, Korben only really glances at this once during the chase, and that’s at the warning sound. But if the younger Korben was meant to use this at all, there’s a lot of work to make this useful rather than dangerous.