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-graphics1 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).

1Some people might consider that a set back...
2When 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.

  • 2
    $\begingroup$ Comments are not for extended discussion; this conversation has been moved to chat. $\endgroup$ – Tim B Nov 13 '17 at 19:21
  • 1
    $\begingroup$ Strongly related: ux.stackexchange.com/questions/101990/… $\endgroup$ – Panzercrisis Nov 13 '17 at 20:23
  • 3
    $\begingroup$ Would you consider a hybrid model? The answers below offer good reasons why you'd might want to give the user a textual interface for issue commands. But presenting data/status to the user can be far more efficient graphically than textually. A schematic display of an orbital maneuver can effectively communicate a ton more detail than a table of numbers, even if the way to modify the operation is to apply new constraints with textual commands. $\endgroup$ – Adrian McCarthy Nov 13 '17 at 22:39
  • 3
    $\begingroup$ Your premise is flawed. A fundamental characteristic of CLI's is - the operator has to memorize all commands and all options. For a space ship, that's a lot of memorization. The GUI can present menus and hints to help an overburdened astronaut eliminate pure memorization. The only circumstance under which a space ship might have a CLI is if that ship were designed in pre-GUI days, as the Apollo moon craft were, and all US and Soviet spacecraft of that era. Want to figure out what a 1202 alarm is when you're about to touch down on the moon for the first time? $\endgroup$ – tj1000 Nov 15 '17 at 3:34
  • 6
    $\begingroup$ There is no good technological reason for graphical interfaces to be rare. None. At all. Zero. If that were the case, then you'd see CLI being the input and display method of choice for systems in real life where input and output is absolutely critical for safety and operations, such as in aircraft, warships, or factory processes. And yet you don't see that at all. GUI interfaces are preferred. No one uses a CLI on an aircraft or on a warship for operational reasons. The only reason to have a CLI is for obscure actions a specialist would carry out involving the code, not operations. $\endgroup$ – Keith Morrison Nov 15 '17 at 22:20

38 Answers 38


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

  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:
    Cockpit keyboard

  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:

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...

  • 1
    $\begingroup$ Comments are not for extended discussion; this conversation has been moved to chat. $\endgroup$ – Monica Cellio Nov 17 '17 at 2:53
  • 1
    $\begingroup$ "it's easy to type blindly - so you don't have to keep your eyes on the monitor at all times" This is the wrong way round. The point about blind typing (better name: touch typing) is that you don't have to look a the keyboard. Thus, the correct sentence would be: "It's easy to type by touch - so you can keep your eyes on the monitor at all times, immediately spotting and correcting mistakes as they appear before your eyes." (This comment was written on a keyboard with all blank keycaps...) $\endgroup$ – cmaster Nov 18 '17 at 8:33
  • $\begingroup$ Regarding less system resources—maybe also that it's easier to rad-shield a button-sized microcontroller than a box server. $\endgroup$ – imallett Nov 19 '17 at 7:36
  • $\begingroup$ I think almost all of your answers more broadly answer the question of CLI over GUI in general at present, and they are all valid for sure. I just can't help but think that in a future where humans are living off Earth and regularly traversing the solar system there would probably be a way to interface with a ship's computer via speech. Plus GUI just makes more sense if not everyone in space is a trained expert. No reason technical people can't still access CLI when needed. $\endgroup$ – ben Apr 12 at 22:05

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:

Picture of ORION spacecraft cockpit

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

  • 2
    $\begingroup$ Interesting. However I don't think this really answer the question. Can you elaborate more? $\endgroup$ – Vylix Nov 13 '17 at 16:47
  • 15
    $\begingroup$ @Vylix This is more of a "your premise is flawed" type of answer than one attempting to provide a detailed solution to the question. In that regard, I wouldn't say this isn't an answer, but rather it points out a problem in the question: we don't know why the OP wants to achieve his/her stated objective. $\endgroup$ – Frostfyre Nov 13 '17 at 17:40
  • 2
    $\begingroup$ @Frostfyre how would I go about clarifying the why in my question? Or shouldn't I bother about that? $\endgroup$ – dot_Sp0T Nov 13 '17 at 18:38
  • $\begingroup$ @dot_Sp0T Normally that would be done via an edit, but I don't think it will make much of a difference at this point. You could, alternatively, ask another question where you ask if the solution you have devised has a better alternative and link the two questions. This works if it's not because of a plot point; that would (probably) be off-topic. $\endgroup$ – Frostfyre Nov 13 '17 at 21:03
  • 1
    $\begingroup$ Ideally, the software should require inputting of the units, and then do computations from there or simply reject the input (e.g. "10 deg" gets internally converted to 0.1745 radians before being acted upon, or spew an error "expected 'rad', got 'deg' -- "oh right, this thing wants input in radians" does math, re-enters correct value) $\endgroup$ – Doktor J Nov 15 '17 at 20:13

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. Stylus and remote shutter button.

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

  • 17
    $\begingroup$ Ever try typing on a keyboard with gloves? You'd need +1" square keys to work with those gloves. Google "touch capacitive gloves" and you'll see that gloves exist for using touch screens. In fact, NASA has them for the astronauts: cnet.com/news/… Also, text isn't easier, it's just more private on phones. A 30 sec audio conversation conveys more information than a text that took 30 sec to write. $\endgroup$ – computercarguy Nov 13 '17 at 14:50
  • $\begingroup$ The stylus is required only because the screen is capacitive, which wrong type for your use case. This same feature makes it sensitive to drops of rain or other liquids. Touchscreens meant to be used with "whatever" or "wherever" have resistive sensors that can be operated with any object you can literally throw at them. $\endgroup$ – Agent_L Nov 17 '17 at 12:33

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.


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...

  • 2
    $\begingroup$ I am not sure about your focus on SSH, it is but a protocol to encrypt data-traffic between the client and the server. There are plenty of graphical softwares that make use of SSH connections to communicate with a server - so if you don't mind me I would love to try to understand your train-of-though there :/ $\endgroup$ – dot_Sp0T Nov 12 '17 at 19:43
  • 2
    $\begingroup$ The idea is that text command line uses very low bandwidth, accomodates high latency, and the client is standard and can run on anything without hassle. If you tunnel GUI like xwindows over ssh it needs lots of bandwidth and low latency. If you use a custom software to connect over a ssh/ssl tunnel then you need to install the custom client on the hardware you use to connect. $\endgroup$ – peufeu Nov 12 '17 at 21:46
  • 9
    $\begingroup$ This argument is only valid on the premise that the remote connection is limited to being some type of screen share. Why could the ship's input interface not be a GUI, the remote controller's input interface be a (locally running) GUI and the (exact same) data (instruction sets) be transmitted to the ship as would be from CLI commands? $\endgroup$ – Johannes Pille Nov 12 '17 at 23:01
  • 1
    $\begingroup$ The data could be transmitted via any conceivable protocol (say SSH or HTTPS) in any conceivable form (say SOAP messages, JSON). It would need not be an interactive shell login at all. $\endgroup$ – Johannes Pille Nov 12 '17 at 23:09
  • 4
    $\begingroup$ A remote control for a TV is more GUI-like, while being much more bandwidth-efficient than an SSH session. $\endgroup$ – idrougge Nov 13 '17 at 20:30

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.

  • 12
    $\begingroup$ The 'clicking' through you base your argument on is sort-of a false positive. Commandline tools can necessitate navigating through menus or subprograms to get to the desired functionality just as well, e.g. have a look at the windows tool 'netsh', the design-process of a commandline tool need assumptions of What you'll want just as well when choosing letters for things such as flags or shortcuts. Also a GUI can be designed around a principle of a max depth, e.g. any menu will not be deeper than 3 layers (or even 2) $\endgroup$ – dot_Sp0T Nov 12 '17 at 16:23
  • $\begingroup$ I like to think of CLI's halfway between a GUI and an AI. You tell the computer what to do - but you have to do it in the computers language. $\endgroup$ – sdfgeoff Nov 13 '17 at 7:17
  • $\begingroup$ @sdfgeoff in that light you could basically call anything a computer does halfway to an AI.. after all, everything a computer does is just logic created by a person to be run later on. Running a CLI commands just tell thes computer to run this specific set of logic, that was written into a language the computer understands by bob 15 years ago. $\endgroup$ – Trotski94 Nov 13 '17 at 12:56
  • 2
    $\begingroup$ It's easy to think that command line tools give you "everything", but they only give you "what we think you'll want", too. A menu driven interface can give just as many options as a command line utility, it's just that programmers are often too lazy to give all the options. Also, programmers tend to be "typists" and tend to think everyone else is too. I've been programming for +20 years, and if I could find a good menu driven IDE to do my programming for me, I'd be using it. BTW, why do you think people like auto-complete so much. They hate typing! :-) $\endgroup$ – computercarguy Nov 13 '17 at 14:55
  • 1
    $\begingroup$ It's more that meta commands are well-established in CLIs, so if what you want to do can be composed out of multiple existing commands (e.g. run this command once on every file in this directory, concatenate the outputs together, filter that through that other command with these options, etc), then it's often not too painful to do it in a CLI. Whereas with a GUI such meta-commands don't usually exist (unless you're working in a visual programming language), so every step has to be clicked on manually. Individual commands aren't really inherently any more flexible with either CLI or GUI. $\endgroup$ – Ben Nov 14 '17 at 1:11

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.)

  • $\begingroup$ You should probably get your terms fixed. UI is a term describing a means of interaction between a user and an interactable thing (e.g. a touch screen for your phone, or a door handle for... a door). $\endgroup$ – dot_Sp0T Nov 13 '17 at 15:09
  • 1
    $\begingroup$ I mostly agree with this. But there is one thing that I still use the Unix command api for (on a MacBook), and that is to do things on a larger scale. Like, "move all png files whose name starts with 'test' to a special directory". And a lot of text manipulation: "select the second column from this CSV file". Those kind of operations are almost impossible to do with a GUI. So I have to say that a CLI will also always exist, even if it has to be created by hobbyists in their spare time. $\endgroup$ – fishinear Nov 14 '17 at 13:35
  • 2
    $\begingroup$ @fishinear I'd agree, and I don't have any objections at all to a CLI generally existing. Like you say, it's fine for quickly hacking something together for a specific temporary need. It's also a good way for systems to interact, because scripts consisting of lines of text are easy to manage. What I disagree with is the OP's concept of the CLI as a way for people to do their normal day-to-day work, because we have ample evidence of how slow-to-use and error-prone it is. $\endgroup$ – Graham Nov 14 '17 at 15:16
  • 1
    $\begingroup$ @dot_Sp0T Yeah, there are physical dials around, where they make sense. Still no CLIs though. Most of the monitoring on the ISS actually happens on the ground, on screens; and even on the ISS there's a substantial amount going on with laptops. $\endgroup$ – Graham Nov 16 '17 at 11:39
  • 1
    $\begingroup$ "It doesn't need any great thought about useability, because there is no useability." You clearly are not using a CLI on a daily basis. Otherwise you would know that a CLI can be much more usable than a GUI for an expert. Ever cared to know the ten most frequent words in your text file? Well, a "simple" cat <file> | tr ' ' '\n' | sort | uniq -c | sort -n | tail will tell you. This type of simple combination of simple primitives to form complex, meaningful commands is what GUIs typically fail at. The average GUI user is simply not able to determine the most frequent words in large texts. $\endgroup$ – cmaster Nov 18 '17 at 8:55

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.

  • $\begingroup$ I'm not sure I'd call it "intuitive". (Not that GUIs are necessarily "intuitive" either.) Maybe "recognizable" or "predictable" would be a better term? $\endgroup$ – a CVn Nov 13 '17 at 9:23
  • $\begingroup$ TEXT to SPEECH ! An easy and simple solution ! no need for hands, no need for eyes, lets the user do anything else at the same time. I can imagine users simply talking to the ship for directions: "Ship, we're going home to jupiter ! And tell my wife I'm coming so that she can get my lunchbox ready !" $\endgroup$ – everyone Nov 13 '17 at 14:40
  • $\begingroup$ Ruggedness and radiation are the best reasons to not use a graphical interface, but even those can be overcome. As for "smaller and lighter", buttons become heavy quickly. Your average desktop keyboard is heavier than most tablets. A GUI can change screens quickly and easily, so they are much more compact than a something physical. And Star Trek shows that voice command goes well with GUI's, too. $\endgroup$ – computercarguy Nov 13 '17 at 15:47
  • 2
    $\begingroup$ @everyone When a computer can parse "Cap Ten and my kaftan cried the captain from the capstan" I'll trust the speech interface.Until then, the adventures of auto-(mis)spell serve as cautionary tales. $\endgroup$ – pojo-guy Nov 14 '17 at 7:19
  • 2
    $\begingroup$ @pojo-guy If the interface is limited to something like "Initiate command <Verb> <Noun> <value> <units (optional)> End Command which is read back using text to speech, and waits for a "Confirm" command i think even our rather rubbish Speech to text would cope. But hey make it a plot point if you want to... $\endgroup$ – DarcyThomas Nov 14 '17 at 19:52

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.

  • $\begingroup$ Because it's so easy to forget commands, business owners are going to want an simple interface for the average user. They may allow their commanders to have/use a command line utility, but not the junior crew members. $\endgroup$ – computercarguy Nov 13 '17 at 15:42
  • 8
    $\begingroup$ Not really - there's only one letter difference between rm -rf * and rm -rf /*. So the truth is that actually it's ridiculously easy to make mistakes in a CLI, whether that's through typos, misreading, or simply misunderstanding a command. Suppose your cryosleep guy intended to extend the time by 200s, and accidentally hit "200d" instead? On the GUI he'd need to be incrementing the "days" button by accident, and he'd very likely see that mistake before he hit "go". On the CLI he's simply flat-out screwed. $\endgroup$ – Graham Nov 13 '17 at 15:57
  • 3
    $\begingroup$ Actually, if you make a ton of mistakes on a GUI, it's a crappy GUI. Put another way, if you had a CLI that only accepts Brainfuck as input, I'd bet you'll start loving that GUI $\endgroup$ – Passer By Nov 13 '17 at 17:38
  • 2
    $\begingroup$ @computercarguy the only two commands that the junior member is expected to type are duct-taped below the screen. Don't ever dare to enter anything different! Not even the command help... $\endgroup$ – Ángel Nov 13 '17 at 23:52
  • 1
    $\begingroup$ @Graham If you use rm as root, you deserve your fate. $\endgroup$ – kingledion Nov 16 '17 at 18:20

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.

  • $\begingroup$ I agree that the crew would need a CLI for certain tasks, but I don't see why this argument precludes a GUI. Most tools for handling complex technical tasks in the modern day (e.g. NASA command center dashboards, developer IDEs) have a GUI to display a broad view of system state and to perform common tasks, combined with a CLI for fine-grained control. This trend has evolved over many decades and differing fields of practice. A crew awakened to deal with non-routine tasks needs to parse a lot information quickly to know exactly where and how to intervene - currently this is often done via GUI. $\endgroup$ – brichins Nov 14 '17 at 19:56
  • $\begingroup$ My argument was that the automation is so extreme no common tasks need to be performed by the crew. Or real-time control either (mentioned in another answer) because the system couldn't wake the crew fast enough, if something like that was needed. Basically, the crew would read system logs of what happened while they slept and make configuration changes based on that. And such logs would mostly be about unexpected errors or exceptions the system could not handle automatically. This is very different from control centers or space shuttles because control model is very different. $\endgroup$ – Ville Niemi Nov 15 '17 at 0:51
  • $\begingroup$ The second stage of the argument was that it is difficult to make an effective GUI to handle rare and unexpected better than an CLI. Basically, if the developers could have visualized it, the automation would have handled the issue. // Obviously I have no idea how realistic this argument is. We frankly haven't had computers long enough for anything to be this automated. More than that this would would require the whole spacecraft to be thoroughly understood as a system, so both the computer and space technology would need to be mature and stable to point of stagnation, IMHO. $\endgroup$ – Ville Niemi Nov 15 '17 at 0:58
  • $\begingroup$ '"this would would require the whole spacecraft to be thoroughly understood as a system"' - precisely. Reading system logs (months or years worth if coming out of stasis!) is a terrible way to understand the current state of an entire system; try reading a single day of your OS's logged events sometime to determine the current activity of all running processes. A GUI could help narrow focus quickly. --- Personally, I think any complex system will always have both GUI and CLI, each is suited to different tasks. $\endgroup$ – brichins Nov 15 '17 at 20:29
  • $\begingroup$ @brichins That's actually a useful way of thinking of it. My idea was based on that same dichotomy and then assuming that all the "GUI stuff" has been automated. I can't really see another way the "GUI stuff" would go away and only CLI would be left behind. $\endgroup$ – Ville Niemi Nov 16 '17 at 6:01

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.


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).


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.


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.

  • $\begingroup$ Introducing AI actually makes a CLI more reasonable. If you are just talking to the AI, then doing it at the command line--passing courses and corrections and such--is pretty reasonable, in my opinion. $\endgroup$ – kingledion Nov 16 '17 at 18:25

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.

  • 1
    $\begingroup$ Ever used a laptop on a shaking airplane? $\endgroup$ – computercarguy Nov 13 '17 at 15:48
  • 1
    $\begingroup$ If you are having trouble with the GUI, it is because the GUI is ill-designed for the task, not because CLI is the only solution $\endgroup$ – Passer By Nov 13 '17 at 17:42
  • 1
    $\begingroup$ Note that combat aircraft have managed to provide GUIs since the seventies. You don't necessarily operate them using a mouse or trackball. By comparison, a keyboard is bulky and far from optimised for use in shaky environments. $\endgroup$ – idrougge Nov 13 '17 at 20:34
  • $\begingroup$ We've been making GUIs for a while now, and lots of them still are ill-designed for the task - whatever single specific task they were designed for. Almost no GUIs are well-designed for multiple tasks, and the most flexible ones are still essentially a collection of prettified text-entry boxes. Using GUIs for control, rather than just readout, is still very limiting $\endgroup$ – Useless Nov 14 '17 at 11:05
  • $\begingroup$ Someone has yet to explain why you'd want a computer interface that allows you to do "everything" on a spaceship where there would be systems where you absolutely do not want anyone, experienced user or not, to be able to do anything they want. $\endgroup$ – Keith Morrison Nov 15 '17 at 9:04

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).

  • 1
    $\begingroup$ Why is a graphics based system less reliable than a non-graphical one? $\endgroup$ – Bellerophon Nov 12 '17 at 19:05
  • 2
    $\begingroup$ @Bellerophon You could probably argue (with reasonable degrees of success) that the more code there is, the higher the risk of bugs creeping into the total code mass; graphical systems require more code than pure text-based systems because the presentation is more complex, hence systems with GUIs have more code; from this, it follows that for a given amount of effort, the risk of, or even number of, bugs would be higher in a GUI-based system than a text-based system. $\endgroup$ – a CVn Nov 12 '17 at 19:34
  • $\begingroup$ Of course in our world, we've been learning how to approach building software to make it more reliable along the same route that has also resulted in much software shifting toward GUIs. $\endgroup$ – a CVn Nov 12 '17 at 19:34
  • $\begingroup$ @MichaelKjörling True. $\endgroup$ – Bellerophon Nov 12 '17 at 19:35
  • $\begingroup$ @Michael I once had a broken calculator. Software one. The one built in Windows. It is only anecdotal proof but I've seen bug creep in and now I can take that without suspension of disbelief. $\endgroup$ – Mołot Nov 12 '17 at 19:58

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.


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.


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.


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.


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...


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.

  • $\begingroup$ Compare this to CLIs. No two Unix commands tend to share the same layout for their parameters, and other command-line OSes (MS-DOS, Powershell, VMS…) have their own conventions, just as GUI systems do. $\endgroup$ – idrougge Nov 13 '17 at 20:39

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.


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.



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).

  • $\begingroup$ Why is there so much vibration in space? $\endgroup$ – kingledion Nov 16 '17 at 18:26
  • $\begingroup$ Heavy maneuvering to dodge laser fire and exploding space ships. Or atmospheric reentry (not all the time, but a critical part at the end of a space trip - would the space ship feature two sets of controls, one for idly cruising in empty space and one for rough situations? Well, could be, indeed!), And you wouldn't want to mistakenly push the self-destruct button when reaching for the engage-docking-clamps button, in the case that the docking maneuver gets a little "bumpy" at the critical point. TL;DR here: trs.jpl.nasa.gov/bitstream/handle/2014/16247/… $\endgroup$ – Klaws Nov 17 '17 at 14:28
  • $\begingroup$ That document might be a bit more accessible to the casual reader: ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19880004228.pdf $\endgroup$ – Klaws Nov 17 '17 at 14:30

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!

  • $\begingroup$ I am not sure if your choice of the word 'dummy' when referring to 'dumb' terminals is deliberate or by misunderstanding - so I'll just ask here: Are you still talking about dumb terminals, e.g. terminals connected to an access-point or similar that interfaces with your retinacomputerthing, or are you talking about dummy terminals, e.g. slabs of metal that get overlayed with some AR (augmented reality) interface when staring at it with your retinacomputerthing? $\endgroup$ – dot_Sp0T Nov 13 '17 at 15:41
  • $\begingroup$ Misunderstanding, indeed. To answer your question, I imagine it could be either a dumb, or dummy terminal, depending on the authors needs. If the retina computer is robust enough to not need redundancy, then having an overlay appear on specific slabs of metal would be neat. Though I think the Op imagined physical buttons, so I imagine the terminal would a dumb terminal that waits for the end-user and then activates an in eye screen. I suppose further, that if we needed redundancy, the dumb terminal would need a small screen of its own that would activate in lieu of a retina screen. $\endgroup$ – Wrobes Nov 13 '17 at 15:52

The infopocalipse in the 21st century was brutal.

AI researchers developed self-modifying code that started solving much of the world's problems. Self driving cars, airplanes, chemical plants, surgery -- AI solved almost everything.

Sure, there where problems. Ransomware and computer criminals where everywhere. AI was deployed to solve the security problem, and systems never seemed more secure. AI would rewrite the OS and network protocols to make it more secure.

Criminals responded in kind with AI that attempted to hack systems, and shortly no undefended computer could exist. Even air gaps could be defeated by the aggressive AIs. Every computer, even secure ones, would be a battle of friendly secure AI vs unfriendly criminal AI, and sometimes things went wrong and they would switch sides.

Things started getting quirky, and emergent effects developed. Seemingly meaningless rituals developed to keep your computer "healthy" and "happy", and nobody could tell why they worked or even if they did.

By the time of the infopocalipse, even the chips and transistors a computer was built out of was designed by AIs with security in mind, as attack AI could use insecurity in your very transistors to harm system operation.

The defending AI missed something, and it got everywhere. One day, the computers stopped working. This caused a worldwide economic collapse; millions died. Some directly, as they had computer hardware installed in their wetware. Some indirectly, as AI driven cars and planes crashed. And many from the raw economic damage and scramble to recover.

If you built a new computer using new design and new metal based off decades old tech, it was also infected. The attacking AI had gotten into the supply chains, the archives, everywhere, and had modified everything. Every single iota of computer power on the planet no longer worked, and if it did it shortly stopped working.

We had to scrub the planet clean of computers. And once we did it, we had to build and design computer hardware from the ground up. This time we had a roadmap to follow, so we were a bit faster.

The first few times we did it, after reaching a certain point the collapse happened again. We had missed something -- maybe some solar powered weather station in someone's attic -- and it jumped an air gap and swept over our network destroying everything we built. The attacking AI was clever and everywhere.

Eventually a solution was found. We engineered the computer system for infection resistance and low bandwidth from the start, so there was fewer ways for the infopocalypse to get in. Computers are kept simple, and they do not network. Computers are designed to be hardened against external intrusion even through graphics interfaces or keyboard input: they have minimal bandwidth in and out. As yet the infopocalipse hasn't repeated; we hope it isn't just biding its time.

GUIs require a lot more processing and IO bandwidth than vector graphics and text, and that simply isn't worth the risk. Hardware vector graphics displays don't require computing power, nor do simple text displays. They are connected over a low bandwidth pipe to a computer which states what to display.


Quite simply, GUIs are not safe. That kind of high-bandwidth communication between a computer and the rest of the world is akin to an organism without a skin in our biosphere.

  • 3
    $\begingroup$ This is a nice story, but there does not seem to be anything that actually answers the question. It might be drowned-out by your fiction though.. $\endgroup$ – dot_Sp0T Nov 13 '17 at 19:54
  • $\begingroup$ @dot_Sp0T The question is "why no GUIs for technological reasons?" The last paragraph directly addresses why, in this scenerio (which is tech-driven), GUIs cannot be used anywhere (including on spacecraft). $\endgroup$ – Yakk Nov 13 '17 at 20:17
  • 2
    $\begingroup$ yes your last paragraph, addresses this, but it is based on a whole story you made up as the reason for this to work. There is no risk in the premise, you invented the risk and to invent it created a whole century-spanning story :/ $\endgroup$ – dot_Sp0T Nov 13 '17 at 20:21
  • 1
    $\begingroup$ @dot_Sp0T One has to invent a reason, because there honestly isn't a reason without extra premises. Guis are cheap and easy with current computing hardware. We stick them on watches at this point. $\endgroup$ – Yakk Nov 13 '17 at 20:40
  • $\begingroup$ I don't consider there to be anything wrong with your answer, personally, but I've always assumed the proscription of Story Based questions extends to Story Based answers as well. $\endgroup$ – MozerShmozer Nov 13 '17 at 23:25

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.

  • $\begingroup$ In the future, all astronauts must have contributed to a Linux package. No more need for GUI's! $\endgroup$ – kingledion Nov 16 '17 at 18:29
  • 1
    $\begingroup$ After patent law is extended for the umpteenth time, it becomes highly illegal to use a GUI on a spacevessel without the permission of Engelbart. Alas, Engelbart died way back in 2013, so getting his permission is... difficult. $\endgroup$ – gmatht Nov 18 '17 at 10:42

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:

enter image description here

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"

  • 1
    $\begingroup$ ..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.., have you spent time thinking about that very argument? Why should a '1-click-button' not equal a '1-command-input'? And the same issue is present in all your other arguments now that I read the rest. Your GUI mockup necessitates a state-machine, the same state-machine could also be accessed and used with a CLI - think of GIT for example. $\endgroup$ – dot_Sp0T Nov 15 '17 at 17:52
  • $\begingroup$ being someone that uses both on a daily basis, yes, i have thought about that, it's natural for me. Again, 4 dimensions map. User touches a location (maybe she zooms in) pointing to an object in another solar system. The object is an arbitrary representation, because it may not exist at that place anymore. Now spaceship can go there. 1 button. 2 if you want. Do that using command line and tell me how it went. How would you explain a machine that you want it to go to a small dot in teh screen? Other cases are possible with CLI (I never said the opposite), but who would do that and why? $\endgroup$ – Devin Nov 15 '17 at 18:11
  • $\begingroup$ please note that when I say a button I mean a graphical representation in a screen that supports a command, not a mechanical button $\endgroup$ – Devin Nov 15 '17 at 18:12
  • 1
    $\begingroup$ Your use-case is only feasible for objects or locations that have been somehow specified/mapped. You state that 'The object ... may not exist at that place anymore.', so random coordinates in space are eliminated by definition. Now we have a list of locations that we can either select on a visual map or from a list. E.g. nav plot-course Ganymede, and if there are multiple objects that are known as Ganymede then there might be a filter or similar nav plot-course Ganymede -f Jupiter $\endgroup$ – dot_Sp0T Nov 15 '17 at 18:21
  • $\begingroup$ Nope. You can simply explore a region and let the machine extrapolate data based on many different indicators, something a human wouldn't be able to do and machines do every day. NOWADAYS. This is not new in science fiction, you can just take Asimov's Foundation where this was pretty common and the pilot Golan Trevize used what we now would call a visuo-haptic device. And what I gave is just a minimal example between thousands I could give. Seriously, you're arguing against history of mankind and technology. Either everybody is wrong or you should re-think your arguments $\endgroup$ – Devin Nov 15 '17 at 19:37

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.

  • $\begingroup$ I don't get what you try to say $\endgroup$ – dot_Sp0T Nov 14 '17 at 16:17
  • $\begingroup$ If you're ship has a failure you need a log of events prior to the failure to fix the problem. If the problem is a power outage you won't have access to digital logs. An analog copy of the log is one potential solution to this. $\endgroup$ – Muuski Nov 14 '17 at 17:38
  • $\begingroup$ Oh, that is supposed to be a log-statement! $\endgroup$ – dot_Sp0T Nov 14 '17 at 17:41
  • $\begingroup$ I tried to modify your answer to make your point clearer. I hope I got it right. $\endgroup$ – dot_Sp0T Nov 14 '17 at 17:46
  • $\begingroup$ You got it! I made another edit just for typos and grammar. $\endgroup$ – Muuski Nov 14 '17 at 17:52

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

  • 1
    $\begingroup$ Your Alternative would be better posted as an answer or comment on the linked earlier question. $\endgroup$ – JDługosz Nov 13 '17 at 2:09
  • $\begingroup$ Computer hardware is extremely cheap compared to overall equipment and mission costs; even space-rated hardware. I can't imagine the deciding factor would be the price of a couple GPUs instead of functionality for the users. $\endgroup$ – brichins Nov 14 '17 at 20:10

protected by James Nov 13 '17 at 18:31

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.