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.

Ghost in the Shell: Home viewing

23 Mar 2015 by Christopher Noessel

San Francisco Bay Area folks may have been wondering what was up with the Ghost in the Shell 20th anniversary movie night. Well, some bad news.

There weren’t enough pre-sales to rent the cinema. We might have just run it as a public showing, but the cinema could not find a way to secure the rights for a public showing despite best efforts and the use of Google Translate on promising Japanese sites. You might think in that case that you could just show it anyway, but the owners cited a story in which independent filmmakers once had to fork over a cool $8000 for an unauthorized showing of a film, even when the normal licensing was only $200. So, without licensing, no public showing. But that doesn’t have to stop us. We have technology.

A synchronozed home viewing of Ghost in the Shell

I’m watching Ghost in the Shell on Saturday, 28 March 2015, starting at 20:30 PDT. I may have a few friends over. Want to join? Well, my couch will likely be full, but get a copy of the movie yourself on Blu-Ray, or Amazon instant video, or Netflix DVD (not available at this time streaming through Netflix), and we can live tweet the event. I’ve just launched the twitter handle @SFImovienight, where

I will announce upcoming movie nights
I will track movie night requests
I will live tweet movies as we’re watching
Anyone else watching along can join in

The hashtag for this viewing will be #gits20.

Yes a contest

Since this won’t be a live event, let’s shake the contest up a bit. No trivia. Whatever tweet that:

Includes #gits20
Tags @SFImovienight
Gets the most retweets

…between now and 28 March 2015 23:00 PDT will win an Adobe Creative Cloud license for 1 year, a $600 value, as an offer by in-kind sponsor Adobe.

Has anyone tried this before? Have suggestions?

Odyssey Navigation

19 Mar 2015 by claytonbeese

When the Odyssey needs to reverse thrust to try and counter a descent towards the TET, Jack calls for a full OMS (Orbital Maneuvering System) burn. We do not see what information he looks at to determine how fast he is approaching the TET, or how he knows that the OMS system will provide enough thrust.

We do see 4 motor systems on board the Odyssey

The Main Engines (which appear to be Ion Engines)
The OMS system (4 large chemical thrusters up front)
A secondary set of thrusters (similar and larger than the OMS system) on the sleep module
Tiny chemical thrusters like those used to change current spacecraft yaw/pitch/roll (the shuttle’s RCS).

After Jack calls out for an OMS burn, Vika punches in a series of numbers on her keypad, and jack flips two switches under the keypad. After flipping the switches ‘up’, Jack calls out “Gimbals Set” and Vika says “System Active”.

Finally, Jack pulls back on a silver thrust lever to activate the OMS.

Why A Reverse Lever?

Typically, throttles are pushed forward to increase thrust. Why is this reversed? On current NASA spacecraft, the flight stick is set up like an airplane’s control, i.e., back pitches up, forward pitches down, left/right rolls the same. Note that the pilot moves the stick in the direction he wants the craft to move. In this case, the OMS control works the same way: Jack wants the ship to thrust backwards, so he moves the control backwards. This is a semi-direct mapping of control to actuator. (It might be improved if it moved not in an arc but in a straight forward-and-backward motion like the THC control, below. But you also want controls to feel different for instant differentiation, so it’s not a clear cut case.)

Source: NASA

What is interesting is that, in NASA craft, the control that would work the main thrusters forward is the same control used for lateral, longitudinal, and vertical controls:

Source: NASA

Why are those controls different in the Odyssey? My guess is that, because the OMS thrusters are so much more powerful than the smaller RCS thrusters, the RCS thrusters are on a separate controller much like the Space Shuttle’s (shown above).

And, look! We see evidence of just such a control, here:

Separating the massive OMS thrusters from the more delicate RCS controls makes sense here because the control would have such different effects—and have different fuel costs—in one direction than in any other. Jack knows that by grabbing the RCS knob he is making small tweaks to the Odyssey’s flight path, while the OMS handle will make large changes in only one direction.

The “Targets” Screen

When Jack is about to make the final burn to slow the Odyssey down and hold position 50km away from the TET, he briefly looks at this screen and says that the “targets look good”.

It is not immediately obvious what he is looking at here.

Typically, NASA uses oval patterns like this to detail orbits. The top of the pattern would be the closest distance to an object, while the further line would indicate the furthest point. If that still holds true here, we see that Jack is at the closest he is going to get to the TET, and in another orbit he would be on a path to travel away from the TET at an escape velocity.

Alternatively, this plot shows the Odyssey’s entire voyage. In that case, the red dotted line shows the Odyssey’s previous positions. It would have entered range of the TET, made a deceleration burn, then dropped in close.

Either way, this is a far less useful or obvious interface than others we see in the Odyssey.

The bars on the right-hand panel do not change, and might indicate fuel or power reserves for various thruster banks aboard the Odyssey.

Why is Jack the only person operating the ship during the burn?

This is the final burn, and if Jack makes a mistake then the Odyssey won’t be on target and will require much more complicated math and piloting to fix its position relative to the TET. These burns would have been calculated back on Earth, double-checked by supercomputers, and monitored all the way out.

A second observer would be needed to confirm that Jack is following procedure and gets his timing right. NASA missions have one person (typically the co-pilot) reading from the checklist, and the Commander carrying out the procedure. This two-person check confirms that both people are on the same page and following procedure. It isn’t perfect, but it is far more effective than having a single person completing a task from memory.

Likely, this falls under the same situation as the Odyssey’s controls: there is a powerful computer on board checking Jack’s progress and procedure. If so, then only one person would be required on the command deck during the burn, and he or she would merely be making sure that the computer was honest.

This argument is strengthened by the lack of specificity in Jack’s motions. He doesn’t take time to confirm the length of the burn required, or double-check his burn’s start time.

If the computer was doing all that for him, and he was merely pushing the right button at the indicated time, the system could be very robust.

This also allows Vika to focus on making sure that the rest of the crew is still alive and healthy in suspended animation. It lowers the active flight crew requirement on the Odyssey, and frees up berths and sleep pods for more scientific-minded crew members.

Help your users

Detail-oriented tasks, like a deceleration burn, are important but let’s face it, boring. These kinds of tasks require a lot of memory on the part of users, and pinpoint precision in timing. Neither of those are things humans are good at.

If you can have your software take care of these tasks for your users, you can save on the cost of labor (one user instead of two or three), increase reliability, and decrease mistakes.

Just make sure that your computer works, and that your users have a backup method in case it fails.

Odyssey Controls

17 Mar 2015 by claytonbeese

Interior view of a spaceship cockpit with multiple control panels and screens, showing a dark space environment. Two seats are visible, with one pilot engaged in operating the controls.

The Odyssey is a large spaceship (larger than the NASA Space Shuttle) that is largely automated and capable of holding its crew in suspended animation. As the Odyssey gets closer to the unknown object (the TET), Jack and Vika wake up to take manual control of the ship.

Two crew members in a spacecraft cockpit, focused and engaged, with control panels in the background.

Jack and Vika—commander and co-pilot, respectively—sit in a standard command deck position close to the front of the ship. They have twin chairs, and mirror-image controls. This is an almost identical functional set up to the Space Shuttle’s command deck.

Interior view of a spacecraft cockpit featuring multiple control panels, screens displaying flight data, and pilot seats. — The cockpit for the *Endeavor*. Source: NASA

Several glass panels on the dash serve as moving displays of information, but a significant amount of the control space is given over to physical buttons and switches. NASA standard components make up a large number of these physical controls, including the numeric keypad and OMS (Orbital Maneuvering System) thrust stick.

A close-up of a hand gripping a control joystick in a spacecraft cockpit, with various buttons and displays visible in the background.

An interesting note here is just how sparse the Odyssey’s command deck is compared to NASA’s Endeavour (the complicated-looking picture above). Since the space shuttle is intended to be flown by human hands if necessary, it has controls for every action possible. (Minimizing modality and allowing the control to be optimized for the task.) In contrast, the Odyssey’s control setup is evidence that most functions on the ship are largely automated.

With most of the controls under automation, the only controls left would be those vital to manual flight operations, such as orbital maneuvers, and controls that activated pre-planned modes in the automated systems.

Close-up of hands operating a control panel with illuminated buttons.

Even in a critical and unplanned situation, e.g. uncontrolled descent towards the TET without communications back to Earth, Jack and Vika are efficient and confident with their motions. This implies excellent training on the equipment, a solidly laid-out control scheme, and proper differentiation of roles between Commander and Co-pilot.

The Odyssey is not a small feat of design, planning, and engineering.

A special mention should be made here for the ship’s interior airlock doors. The doors have large grab surfaces, easy-shut hinges, and a simple circular sealing mechanism. Jack is able to seal the door and confirm that the door is sealed simply by rotating the main handle. When the handle is in the proper place there is a visual and auditory confirmation of sealing. He is able to do this quickly and without error, just before the Odyssey is swallowed by the TET.

Focus on the workflow

The Odyssey does not reinvent spacecraft controls, it simply makes it easier for a two-person crew to control the ship while far away from any help. By focusing only on what Jack and Vika need in their command interface, and letting proven technology handle the rest, the Odyssey’s designers were able to strip away most of the complexity in the command deck but leave vital controls for the crew.

As we see at the very end of Oblivion, the effective design of the Odyssey’s control deck not only saved most of the Odyssey’s crew, but probably saved Humanity as well.

Odyssey Communications

12 Mar 2015 by claytonbeese

A close-up of a control panel displaying a video feed of a woman speaking, with NASA logos visible in the background.

The TET is far enough away from Earth that the crew goes into suspended animation for the initial travel to it. This initial travel is either automated or controlled from Earth. After waking up, the crew speak conversationally with their mission controller Sally.

This conversation between Jack, Vika, and [actual human] Sally happens over a small 2d video communication system. The panel in the middle of the Odyssey’s control panel shows Sally and a small section of Mission Control, presumably back on Earth. Sally confirms with Jack that the readings Earth is getting from the Odyssey remotely are what is actually happening on site.

Interior view of a futuristic spaceship cockpit, featuring numerous control panels, screens, and empty pilot seats.

Soon after, mission control is able to respond immediately to Jack’s initial OMS burn and let him know that he is over-stressing the ship trying to escape the TET. Jack is then able to make adjustments (cut thrust) before the stress damages the Odyssey.

FTL Communication

Communication between Odyssey and the Earth happens in real-time. When you look at the science of it all, this is more than a little surprising.

Vika tells Sally that the Odyssey was traveling for at least 39 days in suspended animation. We see in the same scene that the Odyssey’s engines are thrusting that whole time. Even the low thrust of an ion engine would send the Odyssey a long way out into the Solar System in 39 days.

Current communication technology in space relies on radio communication for voice and video. NASA is testing out laser-based signaling, which would provide higher bandwidth but doesn’t travel faster than the speed of light. Time lag is a constant in both technologies.

In space, real-time communication and measurable distance do not go together at all. There should be a lag, especially at the distances implied by the story.

How Far?

The engines on the Odyssey look a lot like NASA’s prototype ion engines. This would fit nicely with the compact nuclear reactor on board, which would be the perfect size for generating living power and engine power for low-thrust ion engines.

Ion engines don’t have the same thrust capacity as our current rockets, but have the advantage of constant thrust over long distances that chemical rockets can’t match. NASA’s Dawn probe has an acceleration of about 0.22m/s/s (very, very rough math). A quick run through a calculator at (http://www.cthreepo.com/lab/math1/) says that over 39 days (Odyssey’s travel time), they would go about 8 astronomical units (AUs). That is 8x the distance from the Earth to the Sun just with Dawn’s level of thrust. That is a low end calculation, and doesn’t factor in any thrust from a more traditional rocket on the Earth end, or any slingshot maneuvers to add speed.

8 AUs would be more than an hour of light speed lag. That means that the Odyssey should take almost two hours to complete a single back-and-forth of a conversation.

If the compact nuclear reactor was actually able to produce thrust (unlikely, but possible), then in 39 days the Odyssey could have traveled even further.

At any distance beyond the Moon’s orbit, light-speed communication would become increasingly delayed. If the TET was even in a Mars orbit, it could take between 4 and 24 minutes for radio and video signals to go back and forth between Earth and the Odyssey. Further distances increase the lag time significantly.

This means that Humanity has…gasp…developed Faster-than-Light communications technologies by the time Oblivion occurs (and, yes, even before the TET could have provided the advanced alien tech to make it happen).

Close-up of a control panel displaying a distorted screen with horizontal lines and static.

Despite this FTL comm system, as the Odyssey approaches, the TET is able to disrupt the comm signal and cut off Earth from Odyssey. Jack looks concerned by this (as well as Sally’s order to cut his thrust), and stops trying to fight being drawn into the TET.

An unanswerable question here is: what kind of technology from the TET would be able to disrupt an FTL signal? Wouldn’t that require them to be time travelers? Wouldn’t this be a different movie, then?

Don’t Trust New Technology

Neither Jack nor Vika interact with the communication system during the flight that we see besides talking to it. When the signal cuts out, neither of them rushes to check settings or flip switches to try and get the signal back. Instead, they go to a backup plan and focus on what they are able to do without help from Earth. The screen that held Sally’s image cuts over to a secondary information display as soon as it detects that the signal is gone.

Close-up of a digital display panel showing numerical data, indicators, and system information related to a launch control interface.

This implies two things:

The crew were trained to not rely on the communication system
The communications system is a ‘black box’ to Jack and Vika: it either works or it doesn’t.

Given the previous realization that the comm system is built around an FTL link, both of these make sense. It is unlikely that a single person (or even two people) would be able to understand the equipment behind a new FTL system well enough to maintain it or fix it in an emergency. Similarly, the early Astronauts of NASA weren’t expected to maintain the advanced computers (for the time) on their ships.

If the FTL system was recently invented, and rushed through testing for this mission, it also makes sense that Jack and Vika don’t rely on it. NASA now is very careful about testing equipment to make sure that they will always work, or at least work well enough that they can be constantly relied on. (see the Kepler mission http://en.wikipedia.org/wiki/Kepler_(spacecraft) for what happens when a well-tested and critical component fails).

Jack and Vika reveal their training during the emergency situation: They have no time to think, so they fall back on memorized actions. The lack of interaction with the communications system implies that there was no training around trying to make it work.

Have a Backup Plan

Designers planning to introduce new and advanced technology into important situations should always be sure they have a backup plan for when that advanced technology fails. Likewise, if a highly efficient workflow has advanced technology introduced to improve that efficiency, make sure that failures in the new technology won’t make the workflow slower than before.

Technology should assist and improve, never impede users. And if it’s valuable enough to warrant the risk, give users a backup plan.

TETVision

10 Mar 2015 by Aleatha Singleton

The TETVision display is the only display Vika is shown interacting with directly—using gestures and controls—whereas the other screens on the desktop seem to be informational only. This screen is broken up into three main sections:

The left side panel
The main map area
The right side panel

The left side panel

The communications status is at the top of the left side panel and shows Vika the status of whether the desktop is online or offline with the TET as it orbits the Earth. Directly underneath this is the video communications feed for Sally.

Beneath Sally’s video feed is the map legend section, which serves the dual purposes of providing data transfer to the TET and to the Bubbleship as well as a simple legend for the icons used on the map.

The communications controls, which are at the bottom of the left side panel, allow Vika to toggle the audio communications with Jack and with Sally.

The main map area

The largest section is the viewport where the various live feeds are displayed. The main map, which serves as a radar, as well as the remote video feeds she uses to monitor Jack are both in this section of the display.

The right side panel

The panel on the right side of the map contains the video feed controls, which allow Vika to toggle between live footage from the Bubbleship, the TET, and of course, the main map view.

Although never shown in use in the film, the bottom right of the screen houses the tower rotation controls. This unused control is the only indication the capability even exists, so it is unknown whether the tower rotates 360 degrees or whether it’s limited to set points. (More on this below.)

It has robust capabilities

At one point in the movie, Vika is able to use the drones to search for bio trail signatures when Jack is abducted by the scavs.

Vika is also able to detect and decode various types of signals such as the morse code message sent by Jack or the rogue signal sent out by the scavs.

And, probably unbeknownst to Jack and Vika, the TETVision can be controlled remotely from the TET to allow Sally access to the data stored on the desktop—as shown at one point in the movie, when Sally pulls up a past bio trail signature to send drones after Jack and the scavs.

It’s missing a critical layer of data

At the beginning of the film, as Jack heads toward the downed drone 166, he suddenly encounters a dangerous lightning storm and nearly plunges to his death when the Bubbleship loses power. His signature disappears from the TETVision map, but from Vika’s perspective there is no indication as to what could have happened — or that there was any danger to begin with.

Since the weather is unstable and constantly changing, it would have been better to include a weather overlay so that Vika could have notified Jack of the storm—allowing him to fly around it instead of straight into it.

It’s got some useless bits

The tower rotation controls are never shown in use in the film, so it’s not clear what benefit rotating the tower would serve. The main purpose of their mission is to ensure the hydro-rigs are secure and functioning properly, not getting an optimal view.

The tower is almost completely surrounded by windows as it is. And since the tower windows already face the hydro-rigs, what would be the benefit of changing vantage points?

It seems that the space could be used for something more beneficial to Vika such as bike, hydro-rig and drone cam feeds. This would provide Vika with more eyes on the ground, allowing her the additional support to keep Jack safe and monitor scav activity.

From an clustering standpoint, it would also fall in line logically with the other feed controls on the right side panel.

And some unnecessary visual feedback

Towards the end of the movie, Sally is trying to find Jack and the scavs. She accesses Vika’s desktop remotely in order to pull up the bio trail records. Although no one is around to see the information, the TETVision displays the process as it happens. Of course, this is necessary for the narrative to progress, but in a real-life situation Sally would only need to see the data on her side—not from the desktop in Tower 49. If they’ve managed interstellar travel, cloning, terraforming, and cognitive reprogramming of alien species, they’re not likely still using VNC. This type of interaction should simply run in the background and not be visible on screen.

Better: Provide useful visuals

When a drone picks up a bio trail signal, a visual of a DNA sequence is displayed. Since the analysis is being conducted by Sally on the TET, it seems that this information isn’t really useful to Vika at all.

From Vika’s point of view it seems like the actual trail would be more important, so why not show a drone cam feed complete with the HUD overlay? She could instantly gain more information by seeing that there are two bio trails—proving that Jack has been captured by the scavs and taken to another location.

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.