Category Archives: ~ scifianimatedgifs

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.

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.

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. Continue reading →

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.

Julia’s timer reaches 0:00:01.

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. Continue reading →

While Vika and Jack are conducting their missions on the ground, Sally is their main point of contact in orbital TET command. Vika and Sally communicate through a video feed located in the top left corner of the TETVision screen. There is no camera visible in the film, but it is made obvious that Sally can see Vika and at one point Jack as well.

The controls for the communications feed are located in the bottom left corner of the TETVision screen. There are only two controls, one for command and one for Jack. The interaction is pretty standard—tap to enable, tap again to disable. It can be assumed that conferencing is possible, although certain scenes in the film indicate that this has never taken place. Continue reading →

As Vika is looking at the radar and verifying visuals on the dispatched drones with Jack, the symbols for drones 166 and 172 begin flashing red. An alert begins sounding, indicating that the two drones are down.

Vika wants to send Jack to drone 166 first. To do this she sends Jack the drone coordinates by pressing and holding the drone symbol for 166 at which time data coordinates are displayed. She then drags the data coordinates with one finger to the Bubbleship symbol and releases. The coordinates immediately display on Jack’s HUD as a target area showing the direction he needs to go. Continue reading →

As Jack begins his preflight check in the Bubbleship, Vika touches the center of the glass surface to power up the desktop that keeps her in contact with Sally on the TET and allows her to assist and monitor Jack as he repairs the drones on the ground.

When Ibanez and Barcalow enter the atmosphere in the escape pod, we see a brief, shaky glimpse of the COURSE OPTION ANALYSIS interface. In the screen grab below, you can see it has a large, yellow, all-caps label at the top. The middle shows the TERRAIN PROFILE. This consists of a real-time, topography map as a grid of screen-green dots that produce a shaded relief map.

On the right is a column of text that includes:

The title, i.e., TERRAIN PROFILE

The location data: Planet P, Scylla Charybdis (which I don’t think is mentioned in the film, but a fun detail. Is this the star system?)

The lowest part of the block reads that the SITE ASSESSMENT (at 74.28%, which—does it need to be said at this point—also does not change.)

Two inscrutable green blobs extend out past the left and bottom white line that borders this box. (Seriously what the glob are these meant to be?)

At the bottom is SCAN M and PLACE wrapped in the same purple “NV” wrappers seen throughout the Federation spaceship interfaces. At the bottom is an array of inscrutable numbers in white.

Since that animated gif is a little crazy to stare at, have this serene, still screen cap to reference for the remainder of the article.

Design

Three things to note in the analysis.

1. Yes, fuigetry

I’ll declare everything on the bottom to be filler unless someone out there can pull some apologetics to make sense of it. But even if an array of numbers was ever meant to be helpful, an emergency landing sequence does not appear to be the time. If it needs to be said, emergency interfaces should include only the information needed to manage the crisis.

2. The visual style of the topography

I have before blasted the floating pollen displays of Prometheus for not describing the topography well, but the escape pod display works while using similar pointillist tactics. Why does this work when the floating pollen does not? First, note that the points here are in a grid. This makes the relationship of adjacent points easy to understand. The randomness of the Promethean displays confounds this. Second, note the angle of the “light” in the scene, which appears to come from the horizon directly ahead of the ship. This creates a strong shaded relief effect, a tried and true method of conveying the shape of a terrain.

3. How does this interface even help?

Let’s get this out of the way: What’s Ibanez’ goal here? To land the pod safely. Agreed? Agreed.

Certainly the terrain view is helpful to understand the terrain in the flight path, especially in low visibility. But similar to the prior interface in this pod, there is no signal to indicate how the ship’s position and path relate to it. Are these hills kilometers below (not a problem) or meters (take some real care there, Ibanez.) This interface should have some indication of the pod. (Show me me.)

Additionally, if any of the peaks pose threats, she can avoid them tactically, but adjusting long before they’re a problem will probably help more than veering once she’s right upon them. Best is to show the optimal path, and highlight any threats that would explain the path. Doing so in color (presuming pilots who can see it) would make the information instantly recognizable.

Finally the big label quantifies a “site assessment,” which seems to relay some important information about the landing location. Presumably pilots know what this number represents (process indicator? structural integrity? deviation from an ideal landing strip? danger from bugs?) but putting it here does not help her. So what? If this is a warning, why doesn’t it look like one? Or is there another landing site that she can get to with a better assessment? Why isn’t it helping her find that by default? If this is the best site, why bother her with the number at all? Or the label at all? She can’t do anything with this information, and it takes up a majority of the screen. Better is just to get that noise off the screen along with all the fuigetry. Replace it with a marker for where the ideal landing site is, its distance, and update it live if her path makes that original site no longer viable.

Of course it must be said that this would work better as a HUD which would avoid splitting her attention from the viewport, but HUDs or augmented reality aren’t really a thing in the diegesis.

Narratively

The next scene shows them crashing through the side of a mountain, so despite this more helpful design, better for the scene might be to design a warning mode that reads SAFE SITE: NOT FOUND. SEARCHING… and let that blink manically while real-time, failing site assessments blink all over the terrain map. Then the next scene makes much more sense as they skip off a hill and into a mountain.

When the Roughnecks respond to a distress call from an outpost on Planet P, they quickly learn that it is a trap. Rasczak tells Dizzy to immediately summon an evacuation. To do so she uses this “uplink” interface. It has five components. Continue reading →

The Ghostbusters wear “unlicensed particle accelerators” to shoot a stream of energy from an attached gun. Usefully, this positively-charged stream of energy can bind ghosts. The Pack is the size of a large camper’s backpack and is worn like one. The Proton pack must be turned on and warmed up before use. Its switch, oddly, is on the back, where the user cannot get to it themselves.

Regular readers will have noticed that Starship Troopers is on a bit of pause of late, and the reason is that I am managing a bizarrely busy stint of presentations related to the scifiinterfaces project. Also it’s Halloweek and I want to do more spooky stuff. Last week I wondered e-loud if Gozer from Ghostbusters was a pink Sith, but this post is actually talking about a bit of the interfaces from the movie.

When the Ghostbusters are called to the Sedgewick Hotel, they track a ghost called Slimer from his usual haunt on the 12th floor to a ballroom. There Ray dons a pair of asymmetrical goggles that show him information about the “psycho-kinetic energy (PKE) valences” in the area. (The Ghostbusters wiki—and of course there is such a thing—identifies these alternately as paragoggles or ectogoggles.) He uses the goggles to peek from behind a curtain to look for Slimer.

Far be it for this humble blog to try and reverse-engineer what PKE valences actually are, but let’s presume it generally means ghosts and ghost related activity. Here’s an animated gif of the display for your ghostspotting pleasure.

As he scans the room, we see a shot from his perspective. Five outputs augment the ordinary view the googles offer.