Why would technology dictate graphical interfaces to be rare on spaceships?

Question

This question differs from that question in that the other question is asking about a change in history while this question is looking for a change in the future.

---

In a near future setting I am working on, humans have built space-habitats and have established colonies on celestial objects such as Luna. Their spaceships cannot go faster-than-light and have their fair share of other issues - yet are still the primary means of transport across the Solar, and are the result of constant improvement since the first space shuttle.

The void between these specks of life is populated by small-scale entrepreneurs, shipping cargo from a to b in trips that are measured in months to years. That is, thanks to cryogenics, for them only a few days pass, maybe a week.

They basically take on a cargo, plot the course and then wake up sporadically for maintenance, course-corrections, and so forth.

---

While the setting is an extrapolation of current-day earth, the technology aboard ships and stations is intended to mainly use text-interfaces and vector-graphics¹ for interaction and feedback. Think of your typical Unix terminal.

There are plenty of hardware buttons for everything, but more complex commands or configurations, as well as direct access to ship-systems and devices, are done via text-prompt. E.g.

cryo set wakeup=time+2d
> wakeup procedure scheduled for SOL3-1_37:4:12m-6:23:40-127812_79812301
_

²

---

Q: Why would technology dictate graphical interfaces to be rare on spaceships?, as opposed to the GUI-centered thinking that is today's norm?

I am looking for answers that bring up plausible, tech-based reasons (e.g. advantages) for this paradigm shift. Answers based on social subjects are welcome but will likely rate worse.

Bonus points for answers that explore going towards dumb terminals that are used to interface with shipboard/station-board systems but have themselves little to no other abilities (e.g. back when people had to swap disks).

_{¹Some people might consider that a set back...
²When travelling between stations, planets, etc. Time is denoted as an amount of seconds and nanoseconds that have passed since the departure from a MAJOR/MINOR appended to the departure time.}

Answer 1

A quick web search for "CLI vs. GUI" (Command Line Interface vs. Graphical User Interface) shows that many developers hold the following¹:

1. CLI is faster for an experienced user

   It is much faster to type than to navigate layered menus with a mouse. You can type with both hands, and it's easy to type blindly - so you don't have to keep your eyes on the monitor at all times. These become much more important when your physical environment isn't stable (acceleration, low G, etc.) - it's very difficult to use a mouse in such situations, but there are special keyboards designed for pilots:
   

2. CLI is more efficient to use

   There are tasks (e.g. searching through multiple files / directories with a complex set of parameters) which are easier to perform using CLI. In addition, CLI allows easy "chaining" of series of commands (also called "piping"), so that the output of the first is the input of the second and so on, for example:

   • command 1: list all cargo entries for explosives,
   • command 2: list all cargo bays in input,
   • command 3: seal all airlocks of rooms in input, and,
   • command 4: flush emergency coolant in all rooms in input.
     
     

   This set of actions is much faster to perform in CLI than in GUI, unless someone already created a GUI button for that specific scenario. Finally, CLI makes "aliasing" and scripting very easy - so experienced users can create their custom batch operations and keyboard shortcuts, making their common tasks very fast.

3. CLI requires less system resources

   While the task of maintaining an active GUI isn't terribly demanding for today's computers, CLI requires much less resources. This becomes more important when you are working on a remote terminal - all the graphics needs to be compressed and communicated "over the wire", and the screen is redrawn constantly (not only when you move the mouse, but even an untouched graphic display will typically have a clock, network status icon etc which means constant refreshes) - by contrast, a CLI terminal only refreshes when the user types, or when a command returns a result (and even then, while your local terminal refreshes its display on every keystroke, it only transmits to the remote when you hit "Enter"). If you are operating several remote computers simultaneously, or if you are instructing one remote machine to send commands to another remote machine, using CLI becomes even more preferable as performance degradation of GUI in these situations makes it difficult to work. Finally - in many systems, if something goes wrong, CLI is your only option as the machine can't even load up the GUI.

   All of this may be much more important for a ship flying for several months/years where energy conservation is possibly much more critical (you may have solar panels, or nuclear reactors, but even they have their shortcomings). Also, a cargo ship is likely to have several tied systems rather than a single monolithic computer - as different vessels will have radically different systems and rigs, each with their own computerized control - which in most cases you'd operate remotely.

4. Simple elitism ("any idiot can muck around with GUI, CLI is for pros who know what they are doing")

   While this is a disadvantage of CLI - it takes time to master, and there are no visual hints to remind you of possible commands (though every CLI user will know how to use /? or bring up a man page...). This can be an indication of how experienced a pilot/crew member is - you can tell much faster that someone working with a CLI knows what he is doing or guessing his way through the commands, which is useful if you are going to trust him with operating your cryo-chamber...

---

Some references:

• Quora: What are the advantages of using CLI rather than GUI?
• WIRED: Why the GUI will never kill the sacred command line
• Computer Hope: Command line vs. GUI
• Craciun Dan's Blog "Echoes": 5 Reasons to Use CLI over GUI

1: Let's not debate how much all of this is correct - it's enough to influence the state of the art today, even if it is based on a fallacy. Note that the web is full of arguments and even flame wars over this matter...

Answer 2

I have worked in spacecraft avionics for 17 years and was involved in the data management system for the latest ORION spacecraft.

We do actually use graphical interfaces and in fact the the ORION displays are based on Boeing 777 cockpit displays and controls:

CLI's are generally a bad idea for realtime control as its too easy to mistype a command or use the wrong units (I worked on a project where an operator typed in the command angle in degrees instead of radians and lost a $500M spacecraft).

So use GUI with touch screen all you want .. its what I would use.

---

Engineers do pay attention to designing displays and there is a lot of literature on the subject. This may provide some top level guidance you could use in your storyline: laws of design for universal cockpit displays

Answer 3

Touch screen GUIs may be rare in space ships because of the difficulty using them in space suit gloves. Mouse and touch-pad interfaces are a problem also, but not as bad. These are actual, real-world, non-worldbuilding problems. Using them requires a stylus designed for use with touch screens. A text interface with real physical buttons would be a better option compared to requiring everyone to carry around a stylus (or a Soyuz button pushing stick).

Background: I am an amateur beekeeper. Trying to take pictures or videos with a touch-screen phone is impossible with regular beekeeping gloves. A stylus works along with a Bluetooth record button that has an actual physical switch.

Also, text can be easier. Think of all the people who use their phones to text more than talk.

Answer 4

Remote control

The spaceship can be remote controlled. Due to the distances involved, sometimes the bandwidth is tiny and the lag gets enormous, so a low-bandwidth text-based protocol makes perfect sense. Therefore, command line ssh would be a natural fit. Remote control is a must-have feature in many use cases:

• The company's boss would have root access and be able to set the autopilot back to home base if the crew decides to steal the ship... The crew could also use the remote override if their ship gets stolen by someone else.

• The ground team's shuttle breaks down, they are stranded on a planet while the pilot onboard the orbiting ship has a xenomorph indigestion and is unable to respond. They must program the backup shuttle to deorbit and land.

• Once back on the ship, after Leeroy bravely sacrifices himself to delay the crawling xenomorphs, being able to rush back to the shuttle, leave, and remotely trigger venting out of the atmosphere will seem like a great idea.

Another advantage of ssh is that you can use it from pretty much any hardware without installing a client specific to your ship. As long as you have auth credentials it will work. You can use it from a bar, from a cyber cafe... quite useful when you wake up naked and robbed blind in a back alley on Omega and you need to tell your ship to send a drone to pick you up...

So this command line would be the native way of controlling the ship. Why invent another one with bells and whistles? Now you'd need to learn two interfaces.

Flexibility

Since we are talking about small-scale entrepreneurs, their ships are likely to be a bit rusty, with retrofitted hardware, basically they would make do with what they can find at a good price. Sometimes when a system breaks down beyond repair, you need a new one, and you don't get to choose what's in stock.

Sure, if you buy ALL your hardware from the same provider, you can get a nice GUI, but since your ship is a custom job, each manufacturer's GUI would most likely not be compatible with the others. You'd have to customize the GUI. Also pay a license to use it from your phone. People just don't bother.

And when you want to make various incompatible systems cooperate... you often need glue scripts. Command line is a very good fit for this. It also makes sense that many operations would be scripted using a programming language like python for example. Think checklists, self-tests, working around a piece of buggy hardware that you don't have enough money to fix...

Answer 5

GUIs provide the easy 'What we think you'll want' commands, terminals are where the user tells the computer what they want

You won't have to click through to get to the button you want or wait for the visuals to load, you just write what you want in the terminal. Think of any setting you want to change, you have to open up the control panel (on windows), get the relevant options, click that one, find which of those you want to change, change it....this is good if you don't know exactly what to do or change but fairly long winded when you might be able to say sudo date --set "12 Nov 2017 14:56:00" and get the same result.

Of course this also makes it a lot harder for other people to use your ship too. Perhaps at some point there were competitors flying about in their GUI ships and pirating...only it takes a while to figure out the necessary commands so it is more worth their while stealing other ships...and so your successful company emerged from the competitors.

Answer 6

Sorry to be negative here, but my only possible answer is:

They wouldn't, unless all display technologies were impossible.

A text prompt is great for ad-hoc hackery. It doesn't need any great thought about useability, because there is no useability. It's the lowest common denominator. As the lowest common denominator, it is easy to knock stuff together - but it absolutely is not easy to use, even for experts.

As soon as you need something done where the results need to be checked and validated for safety, or just where people other than a "designated expert" may need to operate the systems, a text prompt simply doesn't cut it. Earlier UIs used simple text-based menu systems to get around this. PCs have evolved a GUI with windows and a mouse pointer, but which is heavily oriented to physical pushbuttons. Touchscreens have continued this with a GUI which even more closely emulates physical pushbuttons.

Even your "typical Unix terminal" has gone this way. The most common "Unix terminal" these days is an Android phone. After that, you're looking at set top boxes, wifi routers, smart TVs, and DVD players. Do you use a CLI much on your phone? Have you ever used a CLI on any of these devices? Did you even know they ran some flavour of Posix OS? Case proved, I'm afraid.

Arthur C Clarke said "Any sufficiently advanced technology is indistinguishable from magic." As far as UIs go, the clear implication of this is that a CLI is insufficiently advanced. Even with Linux development, a decade or so of UI work, frequently by hobbyists, has been enough for some reasonably competent UIs to evolve.

So back to that caveat. If display technologies are possible, a GUI WILL ALWAYS exist, even if it has to be created by hobbyists in their spare time. A GUI will only not exist if it is physically impossible for it to exist. Why might your spacefaring civilisation not have any display technologies? Honestly, that's got to be some kind of strange handwavy justification within your plot, and we can't really help you with that. It's got to be so fundamental to your universe that basic physics and electronics breaks down, and that's going to fundamentally influence your story. Without that handwavy justification though, your story will look strangely dated when it's stuck in CLI-land, in the same way as all those Golden Age sci-fi stories with robots running on tape recorders and valves, or 1960s movies with warehouses full of blinkenlights.

(Edit to add assumptions: I'm assuming that user input by fingers/tentacles/appendages is required, and direct brain/neural interfaces are not possible.)

Answer 7

Ruggedness, weight and interaction via speech

A large lcd panel (needed for a usable GUI) is more prone to damage. Either physically (loose objects flying around) or by radiation.

A large lcd panel takes up valuable real-estate that can be used for something else. Science module, cargo, velcro mounting point etc.

A CLI can be a lot smaller therefore lighter. Weight is alway going to be a big factor when designing space craft.

Having two smaller displays could add redundancy and in more convenient locations (one by the air lock/observation window, one by the habitat module at the other end of the space craft)

A CLI can easily be augmented by a text to speech interface, so you don't even need to be able to see the screen to interact with it. Also you can cut down on mistakes by using more than one sense (sight, touch, hearing).

Text to speech with speech recognition can be useful if the keyboard breaks/keyboard is not maintained.

The constraint of a CLI can be a benefit in that it can force the design to stick with a small strict set of rules. e.g., Commands always follow the pattern Verb Noun Value(s) and commands can be chained together (To learn more look at Powershell) This can make a complex system much more intuitive/predictable; useful in high pressured situations.

Answer 8

Because all operations in given environment are very important and need careful setting.

It is much easier to click on the wrong icon than to input a syntactically correct command that's not what intended.

"Command Line" is much harder to learn and thus the popularity of "GUI" interfaces, but in the given environment that's not a problem as your "small-scale entrepreneurs" are bound to know their ships very well and are likely to welcome anything forcing them to think before committing a command.

In the example given they surely won't like "oversleep" any important (orbital) appointment.

Edit: I know this is a very slippery subject and many Holy Wars have been fought under the flags of GUI Fawkes and CLI_nt Eastwood, but I will clarify my thoughts nonetheless. Bear with me.

The trend in general and about Interfaces in particular, has always been to make things "easier" for the user. This is generally regarded as a Good Thing, but, as with everything, there is a price to pay and situations where this price overweight any advantage had.

The specific "price", in the case of Interfaces is that an "easy one" requires less thought and thus can be used while distracted, sleepy, inebriated or otherwise not fully focused on the task.

A special note, here, should be done about Unix CLI: Usage of short commands (mostly 2 letters, 3 if clashing) and single letter options was essentially chosen to "avoid too much typing" (and because of limited parsing capabilities in the late 70's, of course). Thus it already is on the path of "making life easier" for users.

The "small-scale entrepreneurs" cited in the OP are bound to be very skilled people caring little about easiness and having all the time in the Universe to do the things "right". To them a "punitive" interface, requiring precise and redundant input, is a boon.

The cited example would be modified in:

cryo set wakeup=time+2d
> Ambiguous input, did You mean 'cryo cell 0 set wakeup=current_time+2days'?
cryo cell 0 set wakeup=current_time+2days
> wakeup procedure scheduled for SOL3-1_37:4:12m-6:23:40-127812_79812301
> that is 2 hours, 25 minutes and 16 seconds before next scheduled task (filter cleaning).
> you have 15 minutes to enter cryo cell 0.

General idea is CLI is not necessarily "stupid" and, by the time OP conditions come true it's very likely some good quality A.I. will be available, but it should never rely on "intuition" or things said in a way not perfectly clear to take action, but it should rely on clear evidence the person know exactly what's asking, and that is much better done in written form.

Answer 9

A ship where the entire crew spends most of its time frozen will by design handle all routine tasks automatically. Any task the crew will need to do will be due to unexpected and unpredictable change that the original flight plan could not cover.

It is not practical to build an efficient GUI that handles all possible unexpected and unpredictable events. It is much simpler to give the crew direct access to all configuration that is not hardwired. Unless they are using a graphical programming language, which seems unlikely, this means text. It is possible to create a visual or verbal representation of all configuration data and system code and let the users interact with that in some sort of VR, but I am not convinced that would be better than just using text.

So using text makes sense.

As for an actual CLI, you could argue that a system would have two modes. A full text editor where you can edit configuration data and source code and then commit the changes and a CLI that allows you to make small changes on the run with added safe guards for system stability. It would even be reasonable to assume that the full access editor would be heavily restricted to authorized people and only be available in flight during emergencies, so using CLI would be the norm.

This would still give crew access to all configuration that can be changed safely while in flight, which would be very complex to do with a GUI. The CLI would also presumably directly map to the relevant configuration data, so the same knowledge would be usable for both CLI and full editor.

This is actually an issue with GUIs where they either require you to map user friendly and localized language to what you actually want to do (usually requires Googling or training) or are just as arcane as a CLI would be, but with extra confusion from navigating the interface. Checking command syntax is generally easier, especially if you do not have internet or AI assistant.

Answer 10

That is how the ships come.

The humans are not using space ships they build, but spaceships they found and salvaged.

The novel Gateway (Frederick Pohl) has ships like this, built by a mysterious vanished race the Heechee. https://en.wikipedia.org/wiki/Gateway_(novel)

There are nearly a thousand small, abandoned starships at Gateway. By extremely dangerous trial and error, humans learn how to operate the ships. The controls for selecting a destination have been identified, but nobody knows where a particular setting will take the ship or how long the trip will last; starvation is a danger. Attempts at reverse engineering to find out how they work have ended only in disaster, as has changing the settings in mid-flight.

The book Beyond Heaven's River by Greg Bear sticks in my mind because of its descriptions of the space ships the human protagonists use. These ships are ancient. It is cheaper for the independent operators and small-time entrepreneurs to weld down a few comfortable chairs but otherwise learn how to use these ships as they are.

from the book

Alae slapped a test module on the panel and pushed her way past Oomalo, walking down the oval corridor to the ships old Aighor command center. Her footfalls we’re the only noise. She wanted to put her hands over her ears to hide from the silence. A quarter century of routines had made decisions agonizingly difficult. Oomalo followed. They sat in the twilight of the half awake control consoles, smelling the dust and the cool electronic odors. Human-form chairs had been welded to the floor plates when the station had been re-outfitted, thirty years ago.

Most of the pathways and living quarters have been tailored for human occupation, but the command center was much as it had been for the past 10,000 years. The light on its consoles glowed with the same spectrum chosen by the last Aighors to crew the ship. Alien displays indicated that the dormant engines were still in working order.

…

The old ship went above space-time as smoothly as a Leviathan through arctic seas. For three hours there was nothing around them; the ship was their universe. It was at least 10,000 years old, from the third stage Aighor civilization, and a sizable 3 kilometers from bow to stern. They had purchased it at auction from Crocerian free merchants.

So too your space ships. This command line interface (in an alien language) is how they were found. Instead of trying to hack and augment these interfaces (at some expense and considerable risk of disaster) it is faster, cheaper and safer for the new human owners to adapt and use them the way they are.

Answer 11

GUI is much superior to CLI when it is known with reasonable certitude what you will do, if the number of choices is small (or the workflow is always the same), if spending a few more resources and having some extra latency doesn't matter, and if reliability is not paramount.
In every other case, you will want CLI or hard wiring (which I consider the most primitive form of CLI).

If you cannot anticipate what will be needed, CLI is preferrable as it allows much more easily to do things that the user interface designer did not anticipate, basically CLI is almost like a primitive form of programming. Well, not quite, but it comes close.
Not that it isn't in principle possible to do virtually everything (even unanticipated things) with a GUI as well, it is just a lot harder to design and a lot less straighforward.

If speech recognition can be assumed (and it likely can) then CLI is also much more "compatible" with that kind of interface. In fact, one may serve as backup for the other. Anything you can type, you can say, and anything you can say you can type. Anything you can read, the computer can as well tell you via speech synthesis, if need be.
That's useful when you are for example in a location (doing repairs on the outside, carrying a space suit) where no physical terminal, let alone much of a way of interacting with a GUI (other than a minimal HUD), is available.

Dumb terminals have the immense advantage that in case of failure, you can pull one terminal out of one location (possibly from a 25 year old terraformer on that planet which is going to explode in 17 minutes) and connect it to your main engine where all the terminals have been destroyed by, uh... a neutrino cascade, and chances are good that it will "just work". You might even pull the network/serial/whatever interface out of one and put it in another where the monitor and keyboard is still working (I've actually done such things successfully towards the end of the last century).

If your life or something even more critical (landing a starship with a thousand tons of bioweapons on an inhabited planet?) depends on the outcome then the most primitive form of CLI, a board of mechanical switches, and a stick (or steering wheel) is even more preferrable, retro as it may seem. The less abstraction, the better. You want a stick that makes the ship go right when you push it to the right. You don't want to be waving hands over a holographic projection or be playing a flute.

You don't want to crash into an asteroid because dwm.exe hangs or because you can't find the control quick enough. You don't want to needlessly delay an emergency reactor shutdown for 15 seconds while your display shows animated whirling balls. You don't want cryo chambers being ejected because the cat walked over the touch display (you really want a big, red, mechanical lever, or a push button for such things).

Answer 12

In addition to other answers,

GUI exists but no one cares

Even though I'm a software engineer myself, I don't believe there will be absolutely no gui in space. It's just not practical. But... most of the time gui is a limitation.

So, consider the regular interplanetary voyage. There are various aspects at work that should be taken into account by crew:

• Gravitation might affect ship's trajectory
• Hi-orbit junk may damage the ship - need to avoid that
• Complicated computations to get a correct aircraft vectoring without help from ground-control
• Keep track of fuel consumption and perform special maneuvers to use gravitation and momentum instead of burning the fuel until you're good
• Astromechs need a script they'll execute to do their job inside or outside of the ship - you'll need to write a code for that
• [insert your sci-fi reason here]

Ok, now we have all the complications. The crew will have to manually guide the ship according to external conditions and current goals. You'll need a GUI with hundreds of buttons and input fields which is no way better than a console. Besides, there's no need to use good old MS DOS, right? It can be a super powerful CLI that supports some easy-to-use scripting engine Sci-Fython and it allows the crew to write smart navigational and maintenance scripts on every day basis.

The GUI can still be used but in read mode in order to display readings. It's quite convenient since most important parts can be highlighted and plot-charted. And it's better than typing "sys.fuel-monitor.getXXXparam()" anyway.

Answer 13

Most factors already seem to have been covered here, except the nature of the their use of computers, there may be a place for GUIs in a starship, but not a lot.

• Raw calculations are typed, not clicked in a GUI
• Courses and corrections are typed, not clicked in a GUI
• Time periods are better typed, not clicked in a GUI
• Error reports want to be text, not pretty graphics

For their primary day to day use of computers, GUIs just don't work, CLI is what you want and the GUI is going to get in the way and slow things down.

Until the navigation software is at a point where there you're just clicking a destination on a screen from a limited number of available destinations, then CLI is fundamentally the way to go.

You're suggesting dumb terminals, but why not? There's only really a need for a single (distributed) shipboard computer. It runs everything and has access terminals around the vessel as required.

Answer 14

There's a simple functional reason why you might prefer CLI to either cursor-input or direct-touch GUI: vibration.

Controlling a mouse/trackball cursor, or even poking the right bit of a touchscreen, are hard if everything's shaking.

Even voice input is difficult if there's enough noise (at some frequencies even a throat mike will be vibrating).

A keyboard though, has a rest to anchor the heel of your palm, and finger movement relative to that is pretty accurate.

Answer 15

I'm sidestepping your base requirement a little bit, to arrive at a plausible, consistent system:

The most efficient handling of complex, flexible systems is not a GUI. A GUI is brilliant if you have a reasonably low number of possible actions, and can fairly well predict the typical command path a user takes.

So some basic controls would be GUI or hardware controls. You can bend it a bit and tend towards hardware controls.

Anything that needs to give you full control over a complex system will not be a GUI system. Even today, serious administration of IT systems is generally done in some kind of CLI interface. Other answers have already spelled out the advantages of CLI over GUI.

But you also support vector graphics. That is perfect because very often a graphical display can convey much more information than a text-based output. So in essence you have something like the Wolfram Language and that is a perfectly good interface.

So the answer is that your spaceships use these kinds of interfaces because they are the most adequate solution to the task. Full control at the fingertips of a trained user, output via text or vector graphics, depending what is more suitable, better usability in space (as outlined in other answers). For the particular context, the CLI offers a better advantage vs. disadvantage ratio than the GUI - which has some advantages, but just not enough.

Remember that your solution does not have to be perfect, just better than the alternative.

Answer 16

Radiation and other environmental effects damage computers. Longer times in space will accumulate that damage. Since computers are something your ships need to work, reliability would be preferred over looks or performance. Especially since spare parts are hard to come by out past Jupiter.

Another idea is that someone has invented a computer that doesn’t suffer damage from radiation (perhaps a “tiny” mechanical computer) but doesn’t obey Moore’s Law (it’s difficult to improve performance past early 80’s processing power).

Answer 17

Engineers are notoriously bad at building GUI's, but on the other hand your average GUI designer can't get a spaceship off the ground. The "reason" for the CLI is simple: the engineers building the spaceship started with a CLI, as they are wont to do, and indeed that was necessary to get the thing working in their simulators down on earth.

And yes, the upper management knows they really should get some UI experts in to fix that, but for the moment they have a spaceship flying. And it's not like there s a lot of competition in the market. Besides, so you need to teach a CLI to all of your pilots. But how many are you training? Sure, by now you're training a dozen new pilots a year, up from 1 or 2 when you just got started. But by now refitting the whole fleet with GUI's has also become more expensive, so the board has just decided to move that decision forwards by yet another year.

TLDR: Building a GUI is the correct decision, but has up-front costs and management is shortsighted.

Answer 18

Mass and cost.

A small multiline LCD display has less mass and costs far less than a small LCD graphical display.

The more mass a ship carries, the more fuel it needs to use to move. More fuel = more cost. Plus, why use an expensive display, when a simple, cheaper display will do? The costs multiply when you have to carry multiple spares. Multiline LCDs also take up far less space.

Answer 19

A spaceship cannot rely to get its tech support from earth. Thus, they'll want at least a few highly-skilled programmers on board to ensure ability to operate and repair the ship computers in any situation.

It only makes sense that these programmers are also the ones who regularly interact with the computers. The ship's captain won't be typing the commands, he'll just say "schedule a wakeup for tomorrow" to one of the tech guys.

And even in real world, many programmers prefer command line interfaces for various reasons. Once enough there is enough inertia behind CLI use, any new guys have little choice but to go with the established workflow.

Answer 20

1) For crucial systems, physical controls are better: you can feel for them in the dark, you don't have to look at them to use them, and many of them don't even need power to work. Everything that would use a GUI is given a mechanical control.

2) Everyone allowed into space can code. GUI's are not needed.

3) GUI's require displays. Displays come in many form-factors (resolution? size? touch? color?). You don't want to be dependent on a particular part for a particular display.

4) GUI's are an extra layer of software on top of the software that you actually wish to operate, that is, an extra, non-mission-critical layer of potential bugs. Being killed by an "Event not key-value coding compliant" bug would just be humiliating.

5) Voice control: it's easier to control a machine with an audio-only interface when the expectation of visual feedback is removed. I'm imagining two astronauts in a damaged lifepod writing out a sequence of text commands for the navigation unit, on paper, and double-checking, then turning on the mike...

Answer 21

Why would technology dictate graphical interfaces to be rare on spaceships?

GUIs change far too often and are based on what the particular manufacturer of that device thinks is the best GUI. From a tech perspective, policing possibly hundreds of manufacturers to provide a consistent GUI ranges from difficult to downright impossible. Each of the current OS manufacturers provide specifications on how applications are supposed to look and work in their environment yet most 3rd parties think they have a better way of presenting information and choices and go a different route.

This only gets worse as manufacturers are allowed to patent particular looks or behaviors which essentially forces other manufacturers to come up with their own paradigm. ie: rounded corners, swipe right to open, tiles, etc.

By going text based, you can install commands from the various manufacturers into the computer core while caring nothing for how their particular program looks or functions. The main thing here is just to provide parameter references that can easily be accessed - which is usually built into the programs themselves.

---

Taking a slightly different viewpoint:
I could easily envision that multiple companies are producing their own spaceships and 3rd party manufacturers want their devices to be on them.

Today it's nearly impossible for a 3rd party to have the exact same GUI experience on multiple devices (iOS/Android/Linux/Windows). However if the app is a CLI then it's trivial for the usage to be near identical. It's also far cheaper to produce and maintain.

---

Now, I still think it's better to use GUIs on core systems that require immediate or very fast operation such as flight controls in order to increase reaction times and reduce the possibility of human error.

Answer 22

GUI's have evolved

In the future Graphical User Interfaces have evolved to complete immersive VR environments. These VR environments are absolutely amazing for work efficiency and use completely novel interactions, but require somewhat clunky and heavy machinery (VR immersion capsules/chairs).

The result is that an average future teenager will have as much problems using a modern-day GUI with a mouse and keyboard, as they will have using a CLI. They simply have no clue in both cases.

The end result is that when designing a space ship where weight and space matters and placing lots of VR immersion chairs is not an option, they simply went with CLI's. Not because they are necessarily the best option, but given the necessity to use a cumbersome old fashioned system they don't really care anymore.

The advantage of this is that it makes it very likely that someone is going to mess up. Which in turn will of course make for beautiful plot drivers.

Answer 23

Others have already pointed out that CLI is very fast for a trained user, and it is almost impossible to accidentally click on the wrong button with clumsy fingers in your space suit gloves, or fingers still half frozen after cryo sleep. Admittedly, typing with half-frozen fingers gets you some interesting effects, too, but it's harder to accidentally type "self destruct" when you wanted a cup of coffee than clicking the wrong button (and don't get me started on user interfaces that managed to put buttons in the weirdest of arrangements).

Someone also mentionned text-to-speech.

And of course, a lot of things run automatically, and the computer doesn't click on buttons, but runs commands directly.

But the question was why would technology dictate that GUIs might be rare and CLI might be common place.

I think a plausible answer is much better language recognition.

With CLI today you need to know the exact command syntax, the correct order of parameters, and whatnot. If you do, no mouse-wielding point-and-click-user will ever come near your speed, but if you don't, you'll have a hard time getting your command to be executed.

But if language recognition evolved, and it seems safe to assume it would, then you loose the downsides of CLI. You type what you want, and the computer understands, translating to the "correct" commands.

You still have some GUIs for those cases where visual information transports the important bits a lot faster than text and numbers would, but to interact with the computer, just type what you need, it will understand, and if unsure, will request clarification.

So, why not direct voice input?

It might be because of the noise aboard the spaceship. But most likely it's because it's annoying when your workstation keeps executing the commands of the colleague next to you.

Answer 24

Vibration

That should be obvious.

However, there are menu-driven user interfaces even in vibration-heavy environments nowadays. But these are used for secondary or tertiary tasks, not for primary functions. Try to hit an alternate destination on an animated touch screen map while your spaceship undergoes re-entry. Or in your car while you are speeding down a bumpy road. Interaction via speech (mentioned by DarcyThomas) can be an option for task which do not be processed in hard read time or when the environment can be extremly noisy (vibration in the audio range).

However, with sufficiently advanced technolgy, the distinction between GUIs and "hardware buttons" may begin to blur. Imagine a tactile 3D display which can extrude hard controls at will. Like a round cylinderical control when the need arises to adjust the volume of the intercom or the temperature of the climate control (this will be pretty hard to turn so it will not mistakenly be turned due to vibration or an accidental touch).

Answer 25

In the near-term future, we could expect augmented reality "glasses" to be the norm. The GUI of yesteryear will be obsolete, as will most 2D screens. GUI's operate in a 2-dimensional plane and are merely a translation of our 3D world and, as such, are inherently flawed. In this future, the likes of Google Glass and the imagined Magic Leap will allow for three dimensional manipulation of the environment. While immature today, I expect this technology to quickly flourish.
Imagine seeing your system, in this case the ship, in a translucent 3D scaled image. Retina tracking allows the user to simply look at the ship and the system intelligently zooms to parts or commands of interest in that section. Want to slow the ship? Look at the engines. Care to maneuver a bit? Visually focus the thruster nozels. Need to seal a compartment? Glance at the doors of that section in your 3D model. This 3D representation of the ship has menus intelligently pop-up with items of interest for the given part.
Following this thought experiment, it would not be hard to imagine a ship devoid of all interfaces. For example, you could walk up to a door and the commands you are allowed to do to the door popup in your retina - focus on an option to perform the task.
So, to answer the question specifically, the GUI type interfaces do not exist on the ship because each user has a better personal interface on their person. Such technology would likely not be some wired, or rechargeable device, but rather one that charges from some ambient energy, or from the end-users body directly. For example, a single eyepiece that is powered from the pulse by the temple of the user. Or, if we move further into the future, an eye embedded device that laser "paints" visuals directly onto the retina. In any case, we end up with a ship that needs no interfaces anywhere at all.

The "Bonus Points" for a dummy terminal indicate the Op wants some terminals, so from my above scenario, the ship is laced with dummy terminals for one of a couple reasons...

1. In the visual interface it could be difficult for the system to "guess" what you want to do without a solid, albeit, narrow AI. Thus, any user can walk over to a dummy terminal and type commands onto their own eye screen to work faster. i.e. in-eye typing exists, but is too slow.
2. The dummy may be needed just because the system is not good enough at its job, thus needing personal input from the user at all times. i.e. there is no AI that helps to show what you want, the terminals are how you navigate your in-eye 3D world.
3. Alternatively the dummy interfaces could just be for redundancy. As another user pointed out a CLI could exists, but it would be the "experts only" way of interfacing with the ship. Not that the eye-piece couldn't be used in all cases, but rather the expert can quickly do "that one thing"

Regardless, the end-user becomes the "disk" of the system as the Op wanted. New user at the terminal? - new disk. Each time you approach the terminal, that user is shown the last commands they performed and starts where they left off... personalized each time.

I realize such an "eye interface" may still be a GUI in itself, but being personal to the end-user eliminates them from the ships leaving expert-only CLI type terminals. Thus this addresses the Op's questions fully. I hope this helps, good luck!

Answer 26

Technology restrictions will probably not dictate whether future ships have GUI or CLI tools - cultural ones definitely will.

Technology is developed (and installed) to meet human needs, which are based on business / mission requirements, and even personal preference of the ship's owners and/or users if spaceships are widely available. As illustrated by all the other answers and comments this question has generated, it's clear that both GUI and CLI interfaces have pros and cons.

Your universe will need to some cultural or physiological imperatives to drive development towards CLI and away from GUI. Some of the arguments already presented may be a good starting place.

Answer 27

Are you looking for more or less logical reasons that answer your question? Well, then I don't think you will find any.

However, if your world is a bit on the fantasy side, then you might create some particular condition. I don't know, maybe a cultural thing that makes people hate graphics, maybe a population that relies on pure abstraction... I don't know, you could play around that.

However, if you consider this scenario as a more evolved one than ours, then there's no way you can offer a logical reasoning for this. You have to understand that CLI existed only because GUI were impossible or very complex to do at times when a byte was gold. Nowadays... there's GUIs for everything (yes, including servers). As a matter of fact, I was wondering how is it possible that people still uses CLI over GUIs!

And this is our current state of the art. Where AI/MI is taking their first baby steps, same for AR. And where computational resources are almost limitless. I'd imagine that people doing interstellar journeys are way more advanced than our current state of the art

Just imagine this user case: the pilot has to avoid a collision with an object. Would you rather press a button or type a series of commands instead? Or even better, leave the spaceship do whatever it wants because chances of errors will be millions of times lower than human interaction ones?

Let's get down to Earth. Just imagine the stellar map, and replace it by Google maps. Do you type coordinates or just use commands like zoom and click? Now, back to space, and instead of a bi-dimensional plane (like a Google map), think on a 4th dimensions scenario (oh yes, remember that in space you also have to consider time!). See what happened? your CLI commands are literally impossible, because even if the pilot knows distances, she won't know at least one of the dimensions (time) and quite probably she won't know the Y axis either. Something that would take... 1 click on a button.

I'll take G0blin example (not to be confused as a stab at his answer, just trying to explain using the same set of commands:

1. command 1: list all cargo entries for explosives,

2. command 2: list all cargo bays in input,

3. command 3: seal all airlocks of rooms in input, and,

4. command 4: flush emergency coolant in all rooms in input.

In advanced technologies that are available nowadays, this would probably require just some oral input and aural acknowledgment, or maybe even nothing (the machine would do this without the pilot's intervention). But even "older" approaches, like the most common nowadays would require just a... dashboard. I did a quick one in less than 5 minutes:

Just think of the above image like this:

enter what to search
show cargo with that input
offer available actions to user

While I'm an UX professional, I'm nowhere close to be a spaceship UX professional! So just imagine thinking this thoroughly with adequate testing by professionals that know the possibilities of their technologies!

In short

Unless you find some kind of cultural reason or you force some strange sociocultural scenario, I don't think your question is logically possible. However, it doesn't mean that CLI commands should be completely neglected. You could have them for very strange and arcane commands, or just because "real men don't use GUI"

Answer 28

In addition to the other answers, consider the advantage of being able to print out a log of all commands executed, and being able to look up to what happened before the ship lost power. It could read

...
Lt. Jerry @ 12:30 11/13/2117: lifesupport --kill
...

which is easier to figure out than from looking at what buttons were pressed and when.

In a practical implementation of this it's more likely that the ship would have a "rolling" hard copy of the last couple hours of the logs, that would overwrite the oldest entries with the newest, instead of printing miles and miles of paper over the lifetime of the ship.

This hard copy would almost be exclusively for the situation where the ship loses power accidentally.

Additionally, typically when there is an error in a GUI: It appears as a dialog box which is gone once you close it. CLI allows you to scroll back up and view results from previous commands such as errors.

Answer 29

New system requirements and inertia

Many years ago when the current systems were being devoloped, they did ship with graphical interfaces with animations that rendered current ship status, simulation outputs, and general diagnostic information. Shortly after these systems were introduced, a major new practical functional requirement was required by all certification and government entities. This functional requirement

1. Required lots of processing power
2. Needed to be done in real-time
3. Involved a large amount of matrix algebra

Instead spending the money to design new hardware and retrofit/redesign existing units (space rated hardware is very expensive), the processing power previously used for these interfaces was redirected towards this new functionality. This happened at a large enough scale that virtually all ships were converted in this manner. Due to the reasons mentioned in G0BLiN's post, and not wanting to retrain experienced spacers, command line interfaces became the default.

Alternative suggestion

Instead of a purely command-line based interface, users interact with a tile-based window manager. These GUI interfaces are specifically designed to be usable with just a keyboard, but can use graphical windows like any other system. Here's a demo of one in action: A Better Linux Window Manager: i3 Tiling Basics

Answer 30

In addition to the other answers about the efficiency of CLI for skilled users I might add one other consideration specific to interplanetary society.

Graphical interfaces are culturally specific and may be be meaningless to an alien species that has a different technological history. For example, We use icons representing envelopes to mean "send" and floppy disks to mean "save". Even people who have never sent a paper letter of used a floppy disk know what they mean because they have grown up in that cultural environment. Without that acculturation, it may be difficult to interpret the pictures. Even more abstract signs like arrows for movement may be meaningless without the implicit understanding that things move toward the pointy end.

Of course the CLI would also have to be learned but it is a limited number of logical commands made up of and even more limited number of letters.

There may be other physical or neurological difference in the the way that different species perceive and mentally process images. The CLI is closer to a purely logical representation.