Tag Archives: navigation

Rescue Shuttle

by

1

shuttle01

After the ambush on Planet P, Ibanez pilots the shuttle that rescues survivors and…and Diz. We have a shot of the display that appears on the dashboard between the pilot and copilot. Tiny blue columns of text too small to read that spill onto the left. One big column of tiny green text that wipes on and flashes. Seizure-inducing yellow dots spazzing around on red grids. A blue circle on the right is probably Planet P or a radar, but the graphic…spinning about its center so quick you cannot follow. There’s not…I can’t…how is this supposed to…I’m just going to call it: fuigetry.

Course optimal, the Stoic Guru, and the Active Academy

by

9

In Starship Troopers, after Ibanez explains that the new course she plotted for the Rodger Young (without oversight, explicit approval, or notification to superiors) is “more efficient this way,” Barcalow walks to the navigator’s chair, presses a few buttons, and the computer responds with a blinking-red Big Text Label reading “COURSE OPTIMAL” and a spinning graphic of two intersecting grids.

STARSHIP_TROOPERS_Course-Optimal

Yep, that’s enough for a screed, one addressed first to sci-fi writers.

A plea to sci-fi screenwriters: Change your mental model

Think about this for a minute. In the Starship Troopers universe, Barcalow can press a button to ask the computer to run some function to determine if a course is good (I’ll discuss “good” vs. “optimal” below). But if it could do that, why would it wait for the navigator to ask it after each and every possible course? Computers are built for this kind of repetition. It should not wait to be asked. It should just do it. This interaction raises the difference between two mental models of interacting with a computer: the Stoic Guru and the Active Academy.

A-writer

Stoic Guru vs. Active Academy

This movie was written when computation cycles may have seemed to be a scarce resource. (Around 1997 only IBM could afford a computer and program combination to outthink Kasparov.) Even if computation cycles were scarce, navigating the ship safely would be the second most important non-combat function it could possibly do, losing out only to safekeeping its inhabitants. So I can’t see an excuse for the stoic-guru-on-the-hill model of interaction here. In this model, the guru speaks great truth, but only when asked a direct question. Otherwise it sits silently, contemplating whatever it is gurus contemplate, stoically. Computers might have started that way in the early part of the last century, but there’s no reason they should work that way today, much less by the time we’re battling space bugs between galaxies.

A better model for thinking about interaction with these kinds of problems is as an active academy, where a group of learned professors is continually working on difficult questions. For a new problem—like “which of the infinite number of possible courses from point A to point B is optimal?”—they would first discuss it among themselves and provide an educated guess with caveats, and continue to work on the problem afterward, continuously, contacting the querant when they found a better answer or when new information came in that changed the answer. (As a metaphor for agentive technologies, the active academy has some conceptual problems, but it’s good enough for purposes of this article.)

guruacademy

Consider this model as you write scenes. Nowadays computation is rarely a scarce resource in your audience’s lives. Most processors are bored, sitting idly and not living up to their full potential. Pretending computation is scarce breaks believability. If ebay can continuously keep looking on my behalf for a great deal on a Ted Baker shirt, the ship’s computer can keep looking for optimal courses on the mission’s behalf.

In this particular scene, the stoic guru has for some reason neglected up to this point to provide a crucial piece of information, and that is the optimal path. Why was it holding this information back if it knew it? How does it know that now? “Well,” I imagine Barcalow saying as he slaps the side of the monitor, “Why didn’t you tell me that the first time I asked you to navigate?” I suspect that, if it had been written with the active academy in mind, it would not end up in the stupid COURSE OPTIMAL zone.

Optimal vs. more optimal than

Part of the believability problem of this particular case may come from the word “optimal,” since that word implies the best out of all possible choices.

But if it’s a stoic guru, it wouldn’t know from optimal. It would just know what you’d asked it or provided it in the past. It would only know relative optimalness amongst the set of courses it had access to. If this system worked that way, the screen text should read something like “34% more optimal than previous course” or “Most optimal of supplied courses.” Either text could show some fuigetry that conveys a comparison of compared parameters below the Big Text Label. But of course the text conveys how embarrassingly limited this would be for a computer. It shouldn’t wait for supplied courses.

If it’s an active academy model, this scene would work differently. It would have either shown him optimal long ago, or show him that it’s still working on the problem and that Ibanez’ is the “Most optimal found.” Neither is entirely satisfying for purposes of the story.

Hang-on-idea

How could this scene have gone?

We need a quick beat here to show that in fact, Ibanez is not just some cocky upstart. She really knows what’s up. An appeal to authority is a quick way to do it, but then you have to provide some reason the authority—in this case the computer—hasn’t provided that answer already.

A bigger problem than Starship Troopers

This is a perennial problem for sci-fi, and one that’s becoming more pressing as technology gets more and more powerful. Heroes need to be heroic. But how can they be heroic if computers can and do heroic things for them? What’s the hero doing? Being a heroic babysitter to a vastly powerful force? This will ultimately culminate once we get to the questions raised in Her about actual artificial intelligence.

Fortunately the navigator is not a full-blown artificial intelligence. It’s something less than A.I., and that’s an agentive interface, which gives us our answer. Agentive algorithms can only process what they know, and Ibanez could have been working with an algorithm that the computer didn’t know about. She’s just wrapped up school, so maybe it’s something she developed or co-developed there:

  • Barcalow turns to the nav computer and sees a label: “Custom Course: 34% more efficient than models.”
  • BARCALOW
  • Um…OK…How did you find a better course than the computer could?
  • IBANEZ
  • My grad project nailed the formula for gravity assist through trinary star systems. It hasn’t been published yet.

BAM. She sounds like a badass and the computer doesn’t sound like a character in a cheap sitcom.

So, writers, hopefully that model will help you not make the mistake of penning your computers to be stoic gurus. Next up, we’ll discuss this same short scene with more of a focus on interaction designers.

Plotting Course

by

1

StarshipT_PlottingCourse01

While on “third watch” on the bridge, Barcalow brings Ibanez a cup of coffee and they hang out a bit. Looking at the screen, he notes that “something’s wrong.” He reaches down and presses a button, and a screen appears with the label PLOTTING COURSE. A small yellow circle zeroes in on their spot in space, labeled in green as CURRENT POSITION (with “galactic” XYZ coordinates listed beneath). Then a yellow circle zeroes in on their destination, labeled in blue as TARGET DESTINATION. (With fuigetry from her earlier interfaces lining the top and bottom.) Each dot becomes two squares that slide into place on a side-by-side comparison screen with an efficiency analysis below.

Ibanez explains that she replotted the course, it being “more efficient this way.” To check it he walks to a different computer, which we’ll discuss in the next post. Even though this little interaction takes place over a few seconds, already there are things that need to be discussed before we move on.

StarshipT_PlottingCourse02

Why wasn’t he notified?

Barcalow only finds out about the change to the course by coming to the bridge and observing something on a screen there. Any system that knows its user (and recall that Ibanez had to log in to her station) should know and respect the authority chain of its users. With only three weeks of experience at the helm, it seems more likely that Ibanez should have had to submit a plan for consideration rather than being able to just grabbing the wheel while everyone else is asleep. Seems like a hijacking waiting to happen. More sensibly, Barcalow should have come onto the bridge with the coffee saying, “I saw you submitted a new course. That’s a pretty bold move, ensign. Want to show it to me over a cup of this here space jo?” Then we’d get the idea that there’s an actual chain of authority in this military.

Even if Ibanez has the authority to alter the course without approval, her superior officer (at least) should be notified of the change immediately, so he could be aware and check up on it if he needed to.

Why is this information on a tiny screen?

Everyone on the bridge should be aware of the same basic bits of information. It’s one of the main reasons you get people clustered together in a bridge or a mission control center in the first place. Shouldn’t this be some of that basic information? If so, why is it only appearing on a tiny screen that Barcalow happens to glance at because he’s trying to woo Ibanez? Do they always have to hire womanizing superior officers? Better is a shared information source like Star Trek’s viewscreens where some glanceable mission information—like progress against course—can be seen by everyone.

StarshipT_PlottingCourse03

Cartesian coordinate system

I do want to credit the interface designer for including 3D coordinates. Sci-fi can fall into the trap of treating spaceships as if they were seagoing vessels floating on a 2 dimensional surface like the sea. Props for acknowledging that the ship is moving through three dimensions. And Cartesian coordinates are nice in that anyone who has completed remedial geometry will be familiar with Descartes’ coordinate system. (Though I doubt that Cartesian Coordinates would be the actal system being used in space. It’s much more likely to be something like the International Celestial Reference System or even sweet-looking Keplerian graphs.) But narratively, showing 3D coordinates is a step in the right direction. But we can do René one better for both the audience and the navigators.

Show don’t tell

Other interfaces on the bridge already showed us that the system is capable of displaying 3D information. On this screen, it would be better to show the plotted course and the point at which the ship is along it.

Of course space travel is likely to be incredibly boring with long stretches of straight-line travel through vast swaths of emptiness. But this is sci-fi, so let’s presume that its path includes gravity assist fly-bys of stars. That gives the display useful markers for orientation and something for Barcalow to look at to realize how the course has changed. Then when he needs to compare, he presses the left arrow key and can see the old path overlaid in a new color in the display, letting him (and us the audience) see the change in course rather than be told about it. Numbers can overlay this display to provide exact details, but it would augment the immediate understanding offered by the 3D.

Starnav

by

5

STARNAV

To travel to Jupiter, navigator Zander must engage the Star Drive, a faster than light travel mechanism. Sadly, we only see the output screens and not his input mechanism.

Captain Deladier tells Ibanez, "Steady as she goes, Number 2. Prepare for warp."
She dutifully replies, "Yes m’am."
Deladier turns to Barcalow and tells him, "Number 1, design for Jupiter orbit."

In response, he turns to his interface. We hear some soft bleeping as he does something off screen, and then we see his display. It’s a plan view of the Solar system with orbits of the planets described with blue circles. A slow-blink yellow legend at the top reads DESIGNATING INTRASYSTEM ORBITAL, with a purple highlight ring around Earth. As he accesses "STARNAV" (below) the display zooms slowly in to frame just Jupiter and Earth.

StarshipT-STARNAV07

STARNAV

As the zoom starts, a small box in the lower right hand corner displays a still image of Mars with a label LOCAL PRESET. In the lower left hand corner text reads STARNAV-0031 / ATLAS, MARS. After a moment these disappear replaced with STARNAV-3490 / ATLAS, NEPTUNE, STARNAV-149.58 / ATLAS URANUS, STARNAV-498.48 / ATLAS, SATURN, and finally STARNAV-4910.43 / ATLAS JUPITER. The Jupiter information blinks furiously for a bit confirming a selection just as the zoom completes, and DESIGNATING INTRASYSTEM ORBIT is replaced with the simpler legend COURSE. Jupiter has a yellow/orange ring focus in on it as part of the confirmation.

Some things that may be obvious, but ought to be said:

  1. How about "Destination" instead of "Local preset"? The latter is an implementation model. The former matches the navigator’s goals.
  2. Serial options are a waste here. Why force him to move through each one, read it to see if that’s the right one, and then move on? Wouldn’t an eight-part selection menu be much, much faster?
  3. The serial presentation is made worse in that the list is in some arbitrary order. It’s not alphabetical: MNUSJ? It’s not distance-order either. He starts at 4, he jumps to 8, 7, and 6 before reaching 5, which is Jupiter. Better for most default navigation purposes would be distance order. Sure, that would have meant only one stop between Earth and Jupiter. If you really needed more stops for the time, start at Mercury.

    4. planets_iau (1)

  4. What are those numbers after "STARNAV-"? It’s not planet size, since Uranus and Neptune should be similar, as should Saturn and Jupiter. And it’s not distance, since Jupiter has the largest number but is not the fathest out. Of course it could be some arbitrary file number, but it’s really unclear why the navigator would need to know this when using the screen. If a number had to be there, perhaps a ranking like Sol-V Best would be to get rid of any information that didn’t help him with the microinteraction.
  5. How about showing the course when the system has determined the course?
  6. NUI would be better. When he looks at that first screen, he should be able to touch Jupiter or its orbit ring.
  7. Agentive would be best. For instance, if the system monitors the conversation on the bridge, when it heard "design for Jupiter," it could prepare that course, and let the navigator confirm it.

StarshipT-STARNAV08

Sneakily agentive?

Regular readers of my writing know that agentive tech is a favorite of mine, but in this case there is some clue that this is actually what happened. Note that the zoom to frame Earth and Jupiter happens at the same time as he’s selecting Jupiter. How did it know ahead of time that he wanted Jupiter? He hadn’t selected it yet. How did it know to go and frame these two planets? Should he select first and this zoom happen afterward? Did it actually listen to Deladier and start heading there anyway?

No.

It would be prescient if this throwaway interface was some secret agentive thing, but sadly, given that the rest of the interfaces in the film are ofttimes goofy, powered controls, it’s quite likely that the cause and effect were mashed together to save time.

STARNAV fuigetry

Though I can’t quite make sense of them (and they don’t change in the sequence), for the sake of completeness, I should list the tabs that fill the top and bottom of the screen, in case its meaning becomes clear later. Along the top they have green tab strokes, and read from left to right POS, ROLL, LINE, NOR, PIVOT, LAY. Tabs at the bottom have orange and purple strokes and read SCAN M, PLACE, ANALYZE, PREF, DIAG-1 on the first row. The second row reads SERIAL [fitting -Ed.], CHART, DECODE, OVER-M, and DIAG-2.

Shuttle Yoke

by

4

StarshipTroopers_piloting

Our first scene with Ibanez in training shows her piloting a shuttle to her ship. We don’t see much of the instrument panel or any footpedals, but the interaction with the yoke is pretty clear. She sits in the pilot seat, flicks a couple of switches on an overhead panel, and then gives the yoke a hard yank back to ignite the engines and take off. The reactions from the other characters tell us that she’s meant to be something of an aggressive pilot.

shuttle_yoke

The shuttle exits the flight deck and we get a glimpse of the instrument panel. It has a screen, displaying moving gradients, and a bank of unlabeled buttons. Ibanez never looks at these. She flies visually by the viewport. As she approaches the Rodger Young, we see her holding the yoke close to her, and rolling it to the right as the shuttle arcs near the giant spaceship, and then into a “hallway” within its scaffolded hull. She doesn’t move the yoke very much at all to pitch it 90 degrees up and back out to space again.

StarshipT_shuttleoutput

Problems

There’s not a lot of information in this short scene, but enough to talk about. It’s a simple powered interface, with Ibanez operating a yoke that’s kind-of like a plane’s yoke. She banks the yoke to bank the shuttle. She rolls the yoke to roll the shuttle. There’s a bit of confusion about what the back-and-forth (ventral) controls do. On the flight deck it ignites thrust, but in space it seems to mean pitch (more like what we’d expect.) Yokes are problematic conceptually (for reasons being discussed here) but let’s go with it as a given for now.

First, where’s the safety measures on the flight deck? There is no clearance zone behind the shuttle and that thing is spitting blue fire, right at head level. You’d expect her to check her equivalent of the rear-view mirrors and key some warning klaxxons on the flight deck. Unless that fire is somehow harmless.

While we’re at it, where are the safety measures for the shuttle while in space? She’s clearly freaking the other pilots out with reckless piloting. Sure, they’re new and she’s a “maverick” but you’d expect it to alert her visibly and audibly if she’s undertaking maneuvers that are risky to the shuttle and the giant warship. So fine, the shuttle doesn’t have some gigantic and expensive equipment needed for this. But later in the movie we see that the Rodger Young has a collision alert function. (See below.) Why isn’t she contacted by someone assigned to security aboard the Rodger Young when she first approaches the ship in a reckless way?

This is not aboard the shuttle.

This is not aboard the shuttle.

And finally, there’s the control. It’s risky to use yoke-jerk for initiating thrust if the same motion means something else in flight. If the pilot needs a sudden boost of power, having them strain leaning forward or backward risks their messing with other variables and pointless repositioning for the pilot. Sure, it might be a mode where this only works when docked, but as we all know, modes are problematic at best and to be avoided. And then there’s the fact that the yoke’s sensitivity to pitch is nearly a force gauge, but to roll requires around 45 degrees. Shouldn’t these be at least the same order of magnitude?

It’s so unreal that it breaks the scene. The eyes of the actor and the camera do some work to keep us distracted, but it’s still there, like a bug hiding under the sand of Klendathu.

Piloting Controls

by

31

Firefly_piloting

Pilot’s controls (in a spaceship) are one of the categories of “things” that remained on the editing room floor of Make It So when we realized we had about 50% too much material before publishing. I’m about to discuss such pilot’s controls as part of the review of Starship Troopers, and I realized that I’ll first need to to establish the core issues in a way that will be useful for discussions of pilot’s controls from other movies and TV shows. So in this post I’ll describe the key issues independent of any particular movie.

A big shout out to commenters Phil (no last name given) and Clayton Beese for helping point me towards some great resources and doing some great thinking around this topic originally with the Mondoshawan spaceship in The Fifth Element review.

So let’s dive in. What’s at issue when designing controls for piloting a spaceship?

BuckRogers_piloting

First: Spaceships are not (cars|planes|submarines|helicopters|Big Wheels…)

One thing to be careful about is mistaking a spacecraft for similar-but-not-the-same Terran vehicles. Most of us have driven a car, and so have these mental models with us. But a car moves across 2(.1?) dimensions. The well-matured controls for piloting roadcraft have optimized for those dimensions. You basically get a steering wheel for your hands to specify change-of-direction on the driving plane, and controls for speed.

Planes or even helicopters seem like they might be a closer fit, moving as they do more fully across a third dimension, but they’re not right either. For one thing, those vehicles are constantly dealing with air resistance and gravity. They also rely on constant thrust to stay aloft. Those facts alone distinguish them from spacecraft.

These familiar models (cars and planes) are made worse since so many sci-fi piloting interfaces are based on them, putting yokes in the hands of the pilots, and they only fit for plane-like tasks. A spaceship is a different thing, piloted in a different environment with different rules, making it a different task.

2001_piloting

Maneuvering in space

Space is upless and downless, except as a point relates to other things, like other spacecraft, ecliptic planes, or planets. That means that a spacecraft may need to be angled in fully 3-dimensional ways in order to orient it to the needs of the moment. (Note that you can learn more about flight dynamics and attitude control on Wikipedia, but it is sorely lacking in details about the interfaces.)

Orientation

By convention, rotation is broken out along the cartesian coordinates.

  • X: Tipping the nose of the craft up or down is called pitch.
  • Y: Moving the nose left or right around a vertical axis, like turning your head left and right, is called yaw.
  • Z: Tilting the left or right around an axis that runs from the front of the plane to the back is called roll.

Angles_620

In addition to angle, since you’re not relying on thrust to stay aloft, and you’ve already got thrusters everywhere for arbitrary rotation, the ship can move (or translate, to use the language of geometry) in any direction without changing orientation.

Translation

Translation is also broken out along cartesian coordinates.

  • X: Moving to the left or right, like strafing in the FPS sense. In Cartesian systems, this axis is called the abscissa.
  • Y: Moving up or down. This axis is called the ordinate.
  • Z: Moving forward or backward. This axis is less frequently named, but is called the applicate.

Translations_620

Thrust

I’ll make a nod to the fact that thrust also works differently in space when traveling over long distances between planets. Spacecraft don’t need continuous thrust to keep moving along the same vector, so it makes sense that the “gas pedal” would be different in these kinds of situations. But then, looking into it, you run into a theory of constant-thrust or constant–acceleration travel, and bam, suddenly you’re into astrodynamics and equations peppered with sigmas, and you’re in way over my head. It’s probably best to presume that the thrust controls are set-point rather than throttle, meaning the pilot is specifying a desired speed rather than the amount of thrust, and some smart algorithm is handling all the rest.

Given these tasks of rotation, translation, and thrust, when evaluating pilot’s controls, we first have to ask how it is the pilot goes about specifying these things. But even that answer isn’t simple. Because you need to determine with what kind of interface agency it is built.

Max was a fully sentient AI who helped David pilot.

Max was a fully sentient AI who helped David pilot.

Interface Agency

If you’re not familiar with my categories of agency in technology, I’ll cover them briefly here. I’ll be publishing them in an upcoming book with Rosenfeld Media, which you can read there if you want to know more. In short, you can think of interfaces as having four categories of agency.

  • Manual: In which the technology shapes the (strictly) physical forces the user applies to it, like a pencil. Such interfaces optimize for good ergonomics.
  • Powered: In which the user is manipulating a powered system to do work, like a typewriter. Such interfaces optimize for good feedback.
  • Assistive: In which the system can offer low-level feedback, like a spell checker. Such interfaces optimize for good flow, in the Csikszentmihalyi sense.
  • Agentive: In which the system can pursue primitive goals on behalf of the user, like software that could help you construct a letter. This would be categorized as “weak” artificial intelligence, and specifically not the sentience of “strong” AI. Such interfaces optimize for good conversation.

So what would these categories mean for piloting controls? Manual controls might not really exist since humans can’t travel in space without powered systems. Powered controls would be much like early real-world spacecraft. Assistive controls would be might provide collision warnings or basic help with plotting a course. Agentive controls would allow a pilot to specify the destination and timing, and it would handle things until it encountered a situation that it couldn’t handle. Of course this being sci-fi, these interfaces can pass beyond the singularity to full, sentient artificial intelligence, like HAL.

Understanding the agency helps contextualize the rest of the interface.

Firefly_piloting03

Inputs

How does the pilot provide input, how does she control the spaceship? With her hands? Partially with her feet? Via a yoke, buttons on a panel, gestural control of a volumetric projection, or talking to a computer?

If manual, we’ll want to look at the ergonomics, affordances, and mappings.

Even agentive controls need to gracefully degrade to assistive and powered interfaces for dire circumstances, so we’d expect to see physical controls of some sorts. But these interfaces would additionally need some way to specify more abstract variables like goals, preferences, and constraints.

Consolidation

Because of the predominance of the yoke interface trope, a major consideration is how consolidated the controls are. Is there a single control that the pilot uses? Or multiple? What variables does each control? If the apparent interface can’t seem to handle all of orientation, translation, and thrust, how does the pilot control those? Are there separate controls for precision maneuvering and speed maneuvering (for, say, evasive maneuvers, dog fights, or dodging asteroids)?

The yoke is popular since it’s familiar to audiences. They see it and instantly know that that’s the pilot’s seat. But as a control for that pilot to do their job, it’s pretty poor. Note that it provides only two variables. In a plane, this means the following: Turn it clockwise or counterclockwise to indicate roll, and push it forward or pull it back for pitch. You’ll also notice that while roll is mapped really well to the input (you roll the yoke), the pitch is less so (you don’t pitch the yoke).

So when we see a yoke for piloting a spaceship, we must acknowledge that a) it’s missing an axis of rotation that spacecraft need, i.e. yaw. b) it’s presuming only one type of translation, which is forward. That leaves us looking about the cockpit for clues about how the pilot might accomplish these other kinds of maneuvers.

StarshipTroopers_pilotingoutput

Output

How does the pilot know that her inputs have registered with the ship? How can she see the effects or the consequences of her choices? How does an assistive interface help her identify problems and opportunities? How does as agentive or even AI interface engage the pilot asking for goals, constraints, and exceptions? I have the sense that Human perception is optimized for a mostly-two-dimensional plane with a predator’s eyes-forward gaze. How does the interface help the pilot expand her perception fully to 360° and three dimensions, to the distances relevant for space, and to see the invisible landscape of gravity, radiation, and interstellar material?

Narrative POV

An additional issue is that of narrative POV. (Readers of the book will recall this concept is came up in the Gestural Interfaces chapter.) All real-world vehicles work from a first-person perspective. That is, the pilot faces the direction of travel and steers the vehicle almost as if it was their own body.

But if you’ve ever played a racing game, you’ll recognize that there’s another possible perspective. It’s called the third-person perspective, and it’s where the camera sits up above the vehicle, slightly back. It’s less immediate than first person, but provides greater context. It’s quite popular with gamers in racing games, being rated twice as popular in one informal poll from escapist magazine. What POV is the pilot’s display? Which one would be of greater use?

MatrixREV_piloting

The consequent criteria

I think these are all the issues. This is new thinking for me, so I’ll leave it up a bit for others to comment or correct. If I’ve nailed them, then for any future piloting controls in the future, these are the lenses through which we’ll look and begin our evaluation:

  • Agency [ manual | powered | assistive | agentive | AI ]
  • Inputs
    • Affordance
    • Ergonomics
    • Mappings
      • orientation
      • translation
      • thrust
    • consolidations
  • Outputs (especially Narrative POV)

This checklist won’t magically give us insight into the piloting interface, but will be a great place to start, and a way to compare apples to apples between these interfaces.

The HoverChair Social Network

by

2

WallE-SocialNetwork03

The other major benefit to the users of the chair (besides the ease of travel and lifestyle) is the total integration of the occupant’s virtual social life, personal life, fashion (or lack-thereof), and basic needs in one device. Passengers are seen talking with friends remotely, not-so-remotely, playing games, getting updated on news, and receiving basic status updates. The device also serves as a source of advertising (try blue! it’s the new red!).

A slight digression: What are the ads there for? Considering that the Axiom appears to be an all-inclusive permanent resort model, the ads could be an attempt to steer passengers to using resources that the ship knows it has a lot of. This would allow a reprieve for heavily used activities/supplies to be replenished for the next wave of guests, instead of an upsell maneuver to draw more money from them. We see no evidence of exchange of money or other economic activity while on-board the Axiom…

OK, back to the social network.

Security?

It isn’t obvious what the form of authentication is for the chairs. We know that the chairs have information about who the passenger prefers to talk to, what they like to eat, where they like to be aboard the ship, and what their hobbies are. With that much information, if there was no constant authentication, an unscrupulous passenger could easily hop in another person’s chair, “impersonate” them on their social network, and play havoc with their network. That’s not right.

It’s possible that the chair only works for the person using it, or only accesses the current passenger’s information from a central computer in the Axiom, but it’s never shown. What we do know is that the chair activates when a person is sitting on it and paying attention to the display, and that it deactivates as soon as that display is cut or the passenger leaves the chair.

We aren’t shown what happens when the passenger’s attention is drawn away from the screen, since they are constantly focused on it while the chair is functioning properly.

If it doesn’t already exist, the hologram should have an easy to push button or gesture that can dismiss the picture. This would allow the passenger to quickly interact with the environment when needed, then switch back to the social network afterwards.

And, for added security in case it doesn’t already exist, biometrics would be easy for the Axiom. Tracking the chair user’s voice, near-field chip, fingerprint on the control arm, or retina scan would provide strong security for what is a very personal activity and device. This system should also have strong protection on the back end to prevent personal information from getting out through the Axiom itself.

Social networks hold a lot of very personal information, and the network should have protections against the wrong person manipulating that data. Strong authentication can prevent both identity theft and social humiliation.

Taking the occupant’s complete attention

While the total immersion of social network and advertising seems dystopian to us (and that’s without mentioning the creepy way the chair removes a passenger’s need for most physical activity), the chair looks genuinely pleasing to its users.

They enjoy it.

But like a drug, their enjoyment comes at the detriment of almost everything else in their lives. There seem to be plenty of outlets on the ship for active people to participate in their favorite activities: Tennis courts, golf tees, pools, and large expanses for running or biking are available but unused by the passengers of the Axiom.

Work with the human need

In an ideal world a citizen is happy, has a mixture of leisure activities, and produces something of benefit to the civilization. In the case of this social network, the design has ignored every aspect of a person’s life except moment-to-moment happiness.

This has parallels in goal driven design, where distinct goals (BNL wants to keep people occupied on the ship, keep them focused on the network, and collect as much information as possible about what everyone is doing) direct the design of an interface. When goal-driven means data driven, then the data being collected instantly becomes the determining factor of whether a design will succeed or fail. The right data goals means the right design. Wrong data goals mean the wrong design.

Instead of just occupying a person’s attention, this interface could have instead been used to draw people out and introduce them to new activities at intervals driven by user testing and data. The Axiom has the information and power, perhaps even the responsibility, to direct people to activities that they might find interesting. Even though the person wouldn’t be looking at the screen constantly, it would still be a continuous element of their day. The social network could have been their assistant instead of their jailer.

One of the characters even exclaims that she “didn’t even know they had a pool!”. Indicating that she would have loved to try it, but the closed nature of the chair’s social network kept her from learning about it and enjoying it. By directing people to ‘test’ new experiences aboard the Axiom and releasing them from its grip occasionally, the social network could have acted as an assistant instead of an attention sink.

WallE-SocialNetwork05

Moment-to-moment happiness might have declined, but overall happiness would have gone way up.

The best way for designers to affect the outcome of these situations is to help shape the business goals and metrics of a project. In a situation like this, after the project had launched a designer could step in and point out those moments were a passenger was pleasantly surprised, or clearly in need of something to do, and help build a business case around serving those needs.

The obvious moments of happiness (that this system solves for so well) could then be augmented by serendipitous moments of pleasure and reward-driven workouts.

We must build products for more than just fleeting pleasure

WallE-SocialNetwork09

As soon as the Axiom lands back on Earth, the entire passenger complement leaves the ship (and the social network) behind.

It was such a superficial pleasure that people abandoned it without hesitation when they realized that there was something more rewarding to do. That’s a parallel that we can draw to many current products. The product can keep attention for now, but something better will come along and then their users will abandon them.

WallE-SocialNetwork07

A company can produce a product or piece of software that fills a quick need and initially looks successful. But, that success falls apart as soon as people realize that they have larger and tougher problems that need solving.

Ideally, a team of designers at BNL would have watched after the initial launch and continued improving the social network. By helping people continue to grow and learn new skills, the social network could have kept the people aboard the Axiom it top condition both mentally and physically. By the time Wall-E came around, and life finally began to return to Earth, the passengers would have been ready to return and rebuild civilization on their own.

To the designers of a real Axiom Social Network: You have the chance to build a tool that can save the world.

We know you like blue! Now it looks great in Red!

The Hover Chair

by

2

Three animated characters lounging in futuristic chairs, enjoying drinks, set in a vibrant, high-tech environment.

The Hover Chair is a ubiquitous, utilitarian, all-purpose assisting device. Each passenger aboard the Axiom has one. It is a mix of a beach-side deck chair, fashion accessory, and central connective device for the passenger’s social life. It hovers about knee height above the deck, providing a low surface to climb into, and a stable platform for travel, which the chair does a lot of.

A Universal Wheelchair

We see that these chairs are used by everyone by the time that Wall-E arrives on the Axiom. From BNL’s advertising though, this does not appear to be the original. One of the billboards on Earth advertising the Axiom-class ships shows an elderly family member using the chair, allowing them to interact with the rest of the family on the ship without issue. In other scenes, the chairs are used by a small number of people relaxing around other more active passengers.

At some point between the initial advertising campaign and the current day, use went from the elderly and physically challenged, to a device used 24/7 by all humans on-board the Axiom. This extends all the way down to the youngest children seen in the nursery, though they are given modified versions to more suited to their age and disposition. BNL shows here that their technology is excellent at providing comfort as an easy choice, but that it is extremely difficult to undo that choice and regain personal control.

A group of animated characters lounging on futuristic recliners by a pool, wearing blue outfits and surrounded by a vibrant resort setting with palm trees and digital screens.
A scene from a daycare center with small animated characters in hover chairs watching a holographic display. The room is decorated with stars and features a sign that says 'All Day Care'.

But not a perfect interaction

We see failure from the passengers’ total reliance on the chairs when one of them (John) falls out of his chair trying to hand an empty drink cup to Wall-E. The chair shuts down, and John loses his entire connection to the ship. Because of his reliance on the chair, he’s not even able to pull himself back up and desperately reaches for the kiosk-bots for assistance.

A scene featuring a small robot named WALL-E and a character in a red suit with a large body, flying in a futuristic setting filled with colorful advertisements and robotic figures in the background.
A scene featuring a chubby character in a red outfit lounging on a smooth surface, waving to a small robot, characterized by its rusty exterior and expressive eyes, set in a futuristic environment.
Aerial view of a futuristic setting with rows of seated individuals in red attire, some using hover chairs, while a small robot navigates between them.
A child's hand reaching out towards a colorful ice cream vendor cart surrounded by bright advertising posters.

This reveals the main flaw of the chair: Buy-N-Large’s model of distinct and complete specialization in robot roles has left the chair unable to help its passenger after the passenger leaves the chair’s seat. The first responders—the kiosk bots—can’t assist either (though this is due to programming, not capability…we see them use stasis/tractor beams in another part of the ship). Who or what robot the kiosk-bots are waiting for is never revealed, but we assume that there is some kind of specialized medical assistance robot specifically designed to help passengers who have fallen out of their chairs.

If these chairs were initially designed for infirm passengers, this would make sense; but the unintended conscription of the chair technology by the rest of the passengers was unforeseen by its original designers. Since BNL focused on specialization and fixed purpose, the ship was unable to change its programming to assist the less disabled members of the population without invoking the rest of the chair’s emergency workflow.

John reaching for help from the Kiosk-bots makes it appear that he either has seen the kiosk-bot use its beams before (so he knows it has the capability to help, if not the desire), or he pays so little attention to the technology that he assumes that any piece of the ship should be able to assist with anything he needs.

Whether he’s tech literate or tech insensitive and just wants things to work like magic as they do on the rest of the ship. The system is failing him and his mental model of the Axiom.

Make it ergonomic in every situation

Scene from animated movie featuring a small robot named Wall-E interacting with a large human character in a futuristic environment filled with entertainment screens.

Considering that the chairs already hover, and we know Buy-N-Large can integrate active tractor beams in robot design, it would have been better to have a chair variant that allowed the passenger to be in a standing position inside the chair while it moved throughout the ship. It would then look like a chariot or a full-body exo-skeleton.

This would allow people who may not be able to stand (either due to disability or medical condition) to still participate in active sports like tennis or holo-golf. It would also allow more maneuverability in the chair, allowing it to easily rotate to pick up a fallen passenger and reposition them in a more comfortable spot, even if they needed medical attention.

A cartoonish figure lying on the ground with a speech bubble saying 'ouch!' next to a tilted chair.
Sketch of two cartoon characters: a plump figure lying on its side and a boxy robot standing upright, both positioned within circular motion lines.
An outline sketch of a robot-like character lying down, next to a robotic arm or device, with circular motion lines indicating movement.
A simple sketch of a cartoon character lounging on a reclined chair, with a relaxed expression.

This would allow immobilization in the case of a serious accident, giving the medical-bot more time to arrive and preventing the passenger from injuring themselves attempting to rescue themselves.

The chair has been designed to be as appealing to a low-activity user as possible. But when technology exists, and is shown to be relatively ubiquitous across different robot types, it should be integrated at the front line where people will need it. Waiting for a medical bot when the situation doesn’t demand a medical response is overly tedious and painful for the user. By using technology already seen in wide use, the chair could be improved to assist people in living an active lifestyle even in the face of physical disabilities.

Helmsman’s HUD

by

10

TheFifthElement-helmsman-001

Aboard the Fhloston Paradise luxury liner, we are treated to a quick view of the ship’’s wheel. The helmsman stands before the wheel, in the middle of a ceiling-mounted translucent yellow cylinder that drops just below shoulder level. This surface acts as heads-up display that is visible only from the inside.

TheFifthElement-helmsman-002

The content of the display is a 3-D, featureless, blue graticule with an overlay featuring target brackets, various numeric data strangely labeled with various numbers of ““m””s and “n”s, and a green, faint outline of a railing, as if the helmsman was looking out from a Lawnmower Man interpretation of an Age of Sail wheelbridge. At the top of the display are three yellow-outline rectangles with no content. In the center-top of his view is a compass readout, with a rolling counter display that appears to show bearing.

In practice, the Captain calmly gives an order to a barker, who confirms with a, “Yes, sir” before walking to the edge of the cylinder and shouting the same order, “HELM ONE OH EIGHT!” To confirm that he heard the message, the helmsman repeats the order back and turns the wheel. The helmsman wears a headset that amplifies his spoken confirmation back to everyone on the bridge.

Sometimes a Human is the Best Interface

The Captain doesn’t want to shout or wear a headset. He’s a gentleman. But if the helmsman is going to be trapped in the yellow cone of silence, there must be an intermediary to convey the commands and ensure that they’re carried out. Even if technology could solve it better, I have the sense that navies are places where traditions are carried on for the sake of tradition, so the human aspect of this interaction doesn’t bother me too much. It does add a layer of intermediation where data can go wrong, but the barker and the helmsman each repeat the command loudly, so the Captain can hear and error-check that way.

Long live the HUD

On the plus side, showing the graticule grants a sense of speed and (kind-of) bearing that would be much more difficult to do on the surface on all-water planet like Fhloston Paradise. So that’s nice.

But that information would be even more useful if it was backed up by some other contextual information like the clouds, the position of the sun, or, say, anything else on the surface of the planet toward which they might be barreling. A simple highly-transparent live feed of a camera from somewhere would have been more useful.

helmsman

And of course I can’t let the silly nonsense data on the edges just go. Shipmen love their sea-salted jargon, but they also love effectiveness, and there is no sense to labeling one variable “nm” and the next “nmn,” much less a whole screen of them. They would be difficult to distinguish at the very least. Certainly there’s no use to having two variables labeled just “m” with no other contextualizers. Even if it was better labeled, presenting this information as an undifferentiated wall of data isn’t helpful. Better would be to turn some of these into differentiable graphics that help the helmsman see the information and not have to read it. In any case, the arbitrary blinking on and off of data just needs to stop. It’s a pointless distraction unless there is some monitoring data that is trending poorly and needs attention.

Sometimes an AI is the Best (Secret) Interface

Finally, if you obsess over editing details (and you are reading this blog…) you’ll note that the bearing indicator at the top begins to change before the helmsman moves the wheel. It even moves before the helmsman repeats the order. It even begins before the the barker shouts the orders. (Reminiscent of the chem department flub from Cabin I covered earlier.) It looks like the HUD designers wanted movement and mistimed it before the events in the scene.

But we don’t have to leave it there. We’ve already noted that seamen love standing on tradition. What if this whole interface was vestigial? If the ship has a low-level AI that listens to the captain, it wouldn’t need to wait for any of the subsequent human processes: the barker, the helmsman repeat, or the wheel turning. Each of these acts to confirm the command, but the ship can go from the first order when it has a high degree of confidence. This would also excuse the nmnmmnonsense we see on the HUD. The display might have degraded to displaying noise, but no one needs to fix it because the ship runs just fine without it.

Thinking that the Fhloston Paradise might have been a bioship only makes its destruction from a Zorg Mangalore Zorg bomb only makes its destruction much more tragic, but also more heroic as it died saving the people it had been programmed to serve all along.

tellherkorben

Mondoshawan piloting

by

12

Mondoshawn_piloting

The Mondoshawan pilot grasps two handles. Each handle moves in a transverse plane (parallel to the floor), being attached to a base by two flat hinges. We only see this interface for a few seconds, but it seems very poorly mapped.

Here on Earth, a pilot primarily needs to specify pitch, roll, and thrust. She supplies this input through a control yoke and a throttle. Each action is clearly differentiated. Pitch is specified by pushing or pulling the yoke. Roll is specified by rolling the yoke like a steering wheel. Thrust is specified by pushing or pulling the throttle. It’s really rare that a pilot wanting to lift the plane will accidentally turn the yoke to the right.

But look at the Mondoshawan inputs. They can specify four basic variables, i.e., an X and a Z for each hand. Try as I might, I can’t elegantly make that fit the act of flying well. (Pipe up if I’m not seeing something obvious.) Even if roll, pitch, and thrust was each assigned to an axis arbitrarily, the pilot would end up having to use the same motion on different hands for different variables, and there would be one “extra” axis. Of course there are two other Mondoshawans visible in the ship, and perhaps between them they’re managing that third axis of control somehow. With training and their “200,000 DNA memo groups,” the Mondoshawans could probably manage it, but it would spell trouble for us poor humans with our measly 40 and need for more direct mapping and control differentiation.

fifthelement-079