Flight Recorder

24 Mar 2015 by Maximiliano Pena

Jack flies the airship most of the way to the TET when he decides to listen the recordings of the Odyssey. He presses the play button on the recorder, it makes a beep and an electronic voice says, “Flight recorder playback for the Odyssey mission, 3 May 2017.” Then the playback starts.

First, real flight recorders

Before starting the analysis of the black box in Oblivion I thought it could be helpful to do some research on real-word black boxes. That way I had a reference point, something to compare this to. Oddly enough, there is a lot of information on the internet about the required recording and survival aspects of the device, but not much about means to find it after a crash. Beacons and transmitters are mentioned, but not many requirements to facilitate a person actually spotting it. Anyway, after that research I came up with a list of requirements for the device. It must…

Survive extreme temperature, pressure, and water conditions.
Record both ship and crew´s data on the flight.
Be easy to find in a crash site.
Provide quick access to the stored data.

You can think of modern flight recorders as big and tough hard drives that make digital recordings of both ship data and cockpit voice. Most modern commercial jets use a “quick access recorder” that stores data in a removable memory that can be plugged in to a common computer. And some recorders can also have an USB or Ethernet port for quick access, too. But often the device is damaged by the crash, and the full data needs to be accessed with special equipment.

So it’s against these requirements that we can analyze the real-world design of the flight recorder.

And really, this thing is like a Christmas tree of attention getting lights and sounds in comparison.

Great: Commanding attention

I have to give it to them here, they did a really good job. Aside from the normal design patterns for black boxes, the flight recorder in the movie provides other ways to find the device. The flashing white light can be easily spotted in the dark —and also on the day if bright enough. Even more, flashing is one of the most attention-getting signals that there are, neurologically speaking. And it can be instantly associated with an electronic device, while a fixed flight could be taken as a reflection on some debris.

Irregular flashing is even more powerful: A pattern that is semi random (or stochastic in the literature), with some flashes slightly offset from the main pattern. That difference in the flashing is even more attention getting that a regular one. This too would be really helpful in a crash site where you have an important amount of flashes going on as well: police cars, ambulances and fire cars. In that situation, the randomness of the flashing can help in distinguishing the device from the surroundings.

Julia was wandering through the Odyssey´s wreckage when she heard a soft and repeating sound. She pulled out some wreckage to find the flight recorder. These sound signals help her to locate the device more precisely when at close distance, even when it´s covered by debris if the sound is strong enough.

She takes it out to give it a look, and it´s here when we see the device.

When Julia finds the recorder, she knows that she and Jack need to carry it back to the Tower to better examine it. And as the recorder is kind of heavy, Julia folds out an small handler and uses it to lift up the recorder.

Great: Even better than a flash memory

The recorder in the movie also provides a way to instantly access the voice recordings of the crew. It uses a display and several buttons in a way that is similar to a music player, and building on a known mental model means that anyone looking for the device is going to be able to use it.

Assistive tools for the emergency mode

The recorder in the movie also seems to have two different modes or settings, an “emergency” mode when it has to be found and another mode to play the recordings. As with real flight recorders, the emergency mode could be activated by internal sensors. These could detect the crash via a sudden and/or significant change in velocity, for example. But it ought to have a manual control of some sort to return to normal mode.

When Julia finds the recorder, the device was beeping and using a light as beacon. It also had two status LEDs turned on and the small display was showing a graph curve in red. In contrast, when Jack is hearing the playbacks, the recorder doesn´t show any of those functions. Both the beeping, the lights, and the small screen display are all turned off, and the graph isn´t showing anymore.

What is that red graph supposed to mean anyway?

It´s not very clear what the purpose of the small screen display is. What is it meant to communicate? Additionally the display is oddly placed next to the controls of the recorder, which implies a mapping that doesn’t really seem logical. But mapping is not the only issue, because when the recorder is actually playing, this display is always off.

Given that It´s only on when Julia finds the recorder and the device is capable of playing the recordings by itself, it might be a way to tell the amount of battery life of the device. Although even then, a graph is something that shows change through time. When you need to know the energy levels at one specific moment, using a common battery indicator, or even a depletion bar would work better.

So maybe the graph is telling us that the device has some way of recharging itself. In that case, the graph could be showing charge and discharge cycles—or energy consumption rates—and by association also telling about some problem with the charging system. Even assuming this is the case, it´s odd that the display is always off during playback so it probably has some control to turn it on and off.

A screen dedicated to sound.

The recorder uses another, bigger display to show a number that indicates some time value, like recording or playback time. The bottom half of the display shows a spectrum analyzer of the recording playing at the moment, but when the recorder is not working this part of the display remains empty. During the movie we see that the recorder plays only sound, i.e. the voice recordings during the mission.

This screen offers some visualization but showing the spectrum analysis of the playback seems like a secondary feature. You know, given that it´s not necessary to actually hear the playback. But the display has a MODE button, so maybe the recorder can also record video to take advantage of the full size of the screen. In that case maybe the crew of the Odyssey just chose to only record audio, be it for privacy or to save storage space for the rest of the mission.

Jack was already in space and closing in to the Tet. And as he has to maintain his cover until he gets inside the Tet with the bomb, he stops the recording of the Odyssey.

After getting permission to dock in the Tet, Jack the returns to the playback. But the recording suddenly stops when the command module of the Odyssey got inside the Tet, then there´s only static and an—end of recording—message.

But again, we never actually see the recorder playing video. And the display has a low resolution, monochrome screen—like some early PDAs. So making sense of any video playing from there would definitely be a challenge.

Sleep Pod—Wake Up Countdown

5 Mar 2015 by Maximiliano Pena

On each of the sleep pods in which the Odyssey crew sleep, there is a display for monitoring the health of the sleeper. It includes some biometric charts, measurements, a body location indicator, and a countdown timer. This post focuses on that timer.

To show the remaining time of until waking Julia, the pod’s display prompts a countdown that shows hours, minutes and seconds. It shows in red the final seconds while also beeping for every second. It pops-up over the monitoring interface.

The thing with pop-ups

We all know how it goes with pop-ups—pop-ups are bad and you should feel bad for using them. Well, in this case it could actually be not that bad.

The viewer

Although the sleep pod display’s main function is to show biometric data of the sleeper, the system prompts a popup to show the remaining time until the sleeper wakes up. And while the display has some degree of redundancy to show the data—i.e. heart rate in graphics and numbers— the design of the countdown brings two downsides for the viewer.

Position: it’s placed right in the middle of the screen.
Size: it’s roughly a quarter of the whole size of the display

Between the two, it partially covers both the pulse graphics and the numbers, which can be vital, i.e. life threatening—information of use to the viewer.

The sleeper

At the same time the display has another user, the sleeper. Since she can’t get back or respond in any way, this display is her only way of communication. As such, the device ought to react at least as well as a person would. So while normally a pop-up should only be used to show important data that the user really must know, this case is different. The pop up is not blindly blocking information, it’s reflecting the user’s priorities at that moment. And it’s for this reason that the timer bears that much visual importance on the screen.

But the display is also a touchscreen, which you can tell from the buttons in the timer. So in case the viewer really needs to see the entire display, it would require putting the timer in a separate mode. But that would require him switch back and forth between modes to get all the data.

When the countdown finishes, the pod slides open. Julia slowly begins to recover consciousness, open her eyes and sits to take a look around the outside.

Rome wasn’t built in 99 hours.

The countdown timer shows the amount of hours, minutes and seconds until the sleeper wakes, counting backwards. We just get to see the timer —and hear it beeping— only when the sleep time is ending, so it’s likely a feature to notify any close witness that the pod is about to open.

But what if the sleeper’s biometrics start to get bad? Well, the timer does leave enough room on the screen to leave the bulk of the biometrics data. The device also has a warning for when the sleeper is in CRITICAL condition, but we don’t get to see any in-between modes. It could be helpful if the timer offered some sound cue when the sleeper has some minor issue as well, even if it isn’t as bad. Even something as simple as changing the tone of the beep could do the trick.

Did you notice that the timer has two digits to display hours? That means it can display 99 hours of remaining time. That’s a long time. I’m guessing that the display doesn’t show the countdown with that much time in advance. But in that case, when does it show the timer? If the timer looks to give a hint when a sleeper is about to wake up, you don’t really need to know the amount of hours left. A few minutes’ advance notice is enough.

Kind-of setting the timer.

Although the crew of the Odyssey could probably handle the delta sleep from the onboard computer, the display also offers some functions to control that time. It has three buttons that control the timer:

a START button
a RESET button
a CLEAR button

The timer has two small half-circles both at the top and bottom of the clock. There is a play button. The timer needs to have a way to enter a given duration, and from the mapping of those symbols I’m guessing they could work as adding and subtracting buttons —you know, press the top button to add an hour, press the bottom button to reduce an hour. But at the same time the buttons don’t have any labels to convey that—they lack either a plus symbol on the top or a minus symbol on the bottom. For what it’s worth, the only label they offer is the time magnitude of any pair of digits—hours, minutes and seconds—on the circles at the bottom. So yeah, I’m close to calling these fuidgets.

The text buttons need some consideration as well. The first two are pretty straightforward if we envision the scenario where the clock timer can be set to any given time. In that case START will start the clock and RESET will put it back to zero, as with any common timer. The odd bit is that there is still a START button while the clock is ticking. In many common timers that same button has two modes that switch according to the state of the timer: starting it when it’s paused and pausing it when it it’s playing. But the missing pause mode or button could have a purpose, perhaps waking the sleeper requires a gradual biological process that can’t be stop once it has began.

There are other problems with the third one, the CLEAR button. Although the label is somewhat misleading, the button probably acts as a way to close the pop-up of the countdown, removing it from the screen. But the real issue is what happens after that. If the user press CLEAR and the pop-up closes, there is no way of knowing if the timer keeps running in the background or if it resets back to zero. This is a major problem.

Anyhow, even if the timer did run in the background it doesn’t have much of a point in this case. I mean, there was no one around to check on Julia while she was in sleep.

A little ramble on Industrial Design

Another interesting aspect of the design of the pods is the way they open. Instead of opening or sliding the cover to one side, as more common doors and hatches, the cover of the pods is divided in the middle like a double-leaf bascule drawbridge. These covers on the pod have a hinge both at the top and bottom, so they turn outside and up of the pod when opening.

Although it may seem like an overly complicated design, it really shows its advantages when you set it in context. On the Odyssey the sleep pods are placed side by side, alongside the walls of a tube like compartment. There, the area around the center has hatches that lead to other compartments.

Within a space of those characteristics, a cover that opens or slides to the side would bring some problems. As the cover slides, when opening a pod you would be blocking the one next to it. To improve that, you could have a cover that opens up from the top or the bottom. With that you could have more than one pod closing and opening at the same time, but it also comes with drawbacks. Given the length of the pods those doors will probably cover much of the transit area around the compartments of the ship, becoming an obstacle for the movement of the crew.

This is a solution for both problems. The divided doors give plenty of space for the crew to pass through, and as the doors open up they also give room to opening or closing the pods next to each other at the same time.

Homing Beacon

3 Mar 2015 by Maximiliano Pena

After following a beacon signal, Jack makes his way through an abandoned building, tracking the source. At one point he stops by a box on the wall, as he sees a couple of cables coming out from the inside of it, and cautiously opens it.

The repeater

I can’t talk much about interactions on this one given that he does not do much with it. But I guess readers might be interested to know about the actual prop used in the movie, so after zooming in on a screen capture and a bit of help from Google I found the actual radio.

The desktop interface

Although this sequence centers around the transmission from the repeater, most of the interactions take place on Vika’s desktop interface. A modal window on the display shows her two slightly different waveforms that overlap one another. But it’s not clear at all why the display shows two signals instead of just one, let aside what the second signal means.

After Jack identifies it as a repeater and asks her to decrypt the signal, Vika touches a DECODE button on her screen. With a flourish of orange and white, the display changes to reveal a new panel of information, providing a LATITUDE INPUT and LONGITUDE INPUT, which eventually resolve to 41.146576 -73.975739. (Which, for the curious, resolves to Stelfer Trading Company in Fairfield, Connecticut here on Earth. Hi, M. Stelfer!) Vika says, “It’s a set of coordinates. Grid 17. It’s a goddamn homing beacon.”

DECODE_15FPS — At the control tower Vika was already tracking the signal through her desktop interface. As she hears Jack’s request, she presses the decrypt button at the top of the signal window to start the process.

When you look at the display, the decrypt button is already there for her to press. So either the computer already knows there is an encryption going on, or the user can press the decrypt button at any time, regardless of whether the signal is encrypted or not. In both cases, it’s bad interaction design.

An issue of agentive tech

If the computer already knows that the signal is encrypted, why doesn’t it tell her that? It should automatically handle the decryption, alert her that it was decrypted, and show the lat/long results on the screen. If it’s wrong, she can dismiss it. But let’s not rely on her consultation of a stoic guru just to find out. (It doesn’t even make sense from the TET’s perspective.) In this way you simplify the interface—as you no longer need a “decrypt” button—and help Vika and Jack with their goals more effectively.

Needs more states

From the sequence you can tell that the decrypt button has only two states , OFF and ON. To improve the interface, we’d want to have a few more states, indicating CONFIDENCE, PROCESSING, and of course if it’s wrong, the opportunity to DISMISS. Each of these would need specific designing for microinteractions, but these two states aren’t enough.

What if those weren’t coordinates?

When Vika presses the decrypt button we can see it expands the bottom part of the window, adding some encryption-related info. And way at the very bottom the interface there are a couple of labels that read LONGITUDE INPUT and LATITUDE INPUT. Not the best name though since it’s easy to mistake these for the coordinates of the signal source rather than the message itself. The numbers there start to change as the computer seems to be decoding the signal from the repeater, and making the correction on the data on real time.

But the strange bit are those same coordinate inputs. It seems as if the computer already knows—before it finishes decrypting—that the signal is transmitting a set of longitude and latitude coordinates. I mean, what if the encrypted data wasn’t coordinates at all…say, an entry code to some scav station? It’s possible that there is some metadata in the signal that conveys this information, but if that was immediately available, again, the system should have told them.

Finally, there is no feedback whatsoever about the time needed to complete the decryption. It doesn’t do much harm here as it’s pretty fast, but I’m guessing that more complex transmissions might pass the threshold of attention it would become an issue.

What is out there?

This is the first thing Jacks asks once he knows about the encrypted coordinates. And the interface designers thought about that one too, and place a small button next to the coordinate labels. That button leads to another window with the map display but not only that, if you look closely you can see that the button label also changes. While at first it reads MAP, after a few seconds the labels changes to GRID followed later by the number 17. And it keeps looping between those last two.

The changing labels are a way to add more info on the same screen real estate. If Vika happens to know the surroundings of sector 17 she could have told Jack there was nothing there without even looking at the map. In the next sequence we see Vika scrolling around the map view—hopefully it opened right at those coordinates, but even if she’s scrolling around to see if there’s anything of interest there, I’ll note that the location does not have a drop pin to let her re-orient.

Losing the signal

Just as Jack is cutting one of the wires from the repeater to shut down the transmission we get a view of the desktop interface again. The modal window that Vika was using to track and decode the signal suddenly closes. This is a nice use of affordances, as the animation itself shows Vika that the signal was interrupted from the source. A more common trope is a big “no signal” label, so this is nice to see.

After Vika finishes the decryption of the coordinates from the signal, Jacks takes his pliers to cut the wires going from the repeater to the building structure to shut down the transmission.

Jacks decides to shut down the transmission from the repeater. As he does so, the desktop closes the window that Vika was using to track the signal, emphasizing the action with a short sound warning.

The only issue I can see is that in some cases Vika would end up opening the modal window again immediately if she was in the middle of work. The computer should stores the signal in memory and switch automatically from LIVE FEED to CACHE so she could continue.

Mostly useable

So the desktop interface definitely has its issues, but at the same time some few well considered details. The main challenge is its withholding the encryption from Vika. It shouldn’t. On the other hand, the interfaces have some clever information design, such as the space-saving labels and the animation which embodies the facts about the signal.

Contact!

18 Feb 2015 by Maximiliano Pena

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.

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.

Although Vika yells about something coming from the left side, by looking at the screen you can kind of tell that it’s more to his back—his 6 or 7 o’ clock—than left. We’re seeing it with time to spare here, and the satellite image is very low-res, so we can cut her some slack. But given all the sensors at its command, the interface would ideally which way Jack is facing and which way the threat approaches, so she can convey correct and useful information quickly.

“Contact, at your 6, Jack!”

That’s much more precise and actionable for Jack.

Don’t cover information

It might be useful to put the ALERT overlay somewhere other than on top of Jack, since it might obscure some useful information. Perhaps the “chrome” of the interface could turn red? Not as instantly readable for the audience, but if we’re designing for Vika…

Provide specifics

Another issue is that neither the satellite image nor the interface help Vika to identify what ends up being just a dog. Even when Jack manages to stay cool through the little scare jump, adding at least some information about the object would go a long way to make Vika and the situation less tense.

Jack’s encounter with the TET gives clear evidence that the TET has sophisticated computer vision, so the interface could help Vika a bit by “guessing” what any questionable object might be. It doesn’t need to be exact (and it probably couldn’t be with that kind of video feed) but the computer could give its educated guess just by analyzing the context, shape, and motion compared against things in the database. So instead of telling there is an 87% chance of being a dog or a 76% chance of being a fox, the interface could just predict unknown animal (see below).

Share off-screen information

Fast viewers saw the unknown object before the warning. During a split of a second while the object is entering the screen, it remains blue. So the computer does keep track of any movement, even if it’s not a threat. In that case the issue is that the computer seems to be tracking movement far beyond the visible area of the screen but it doesn’t let Vika know something’s coming from off-screen. The display doesn’t need to zoom out to reach the contact—that could distract Vika from following Jack—but at least it could show some kind of signal pointing at the incoming contact.

What of multiple contacts?

I’m cautious to talk about what ifs, since most of it is just guesswork—but bear with me. On the sequence the interface keeps track of just one contact, but how it would behave if there were more than one? If the computer does track of contacts beyond the camera display Vika is watching, then just marking them is not enough. If Vika needs to inform Jack on the number of contacts she’s getting on the screen, then you need some sort of overview. Pointing at the direction of the contact is useful, but it does mean you have to sweep all the screen to know how many of them are. But that can be easily fixed by adding a list of all the current contacts.

Show trending

Pausing the film a bit and looking closely, it seems that the only difference between all-is-fine and contact! with the dog is about a meter long. And what is more, by the time the interface triggers the warning the dog is really close to Jack. If that was feral dog and it was to attack him, the warning to Jack would come very late.

In such mission-critical monitoring, it’s not enough to show changes of state. Change the state subtly to indicate as things are trending—as in, this dog is likely to continue its intercept course and getting closer.

We got this

So to wrap up, the interface does a well enough job, but it could certainly benefit from some design changes. The issues are ones that any designer might have to face when working with a monitoring interface, so worth summarizing.

Share all the information that is at hand
Give the user the information in the form they might pass it along
Assign an easy-to-distinguish hierarchy: information, suspicion, warning
Provide best-guesses as to the nature of problems with as much specificity as you can
Provide unobtrusive but clear signals about the mode
Anticipate and show trending dangers

Sci-fi interfaces

Stop watching sci-fi. Start using it.

Author Archives: Maximiliano Pena