Why the command line is not usable

A command line interface is like a door with no handles.

A command line interface is like a door with no handles.

A number of FLOSS tools require users to do work at the command line in order to set them up or operate them. With Linux and its applications, this is often expected. Very few Windows, Apple, or even Android applications expect anyone to do this anymore.

Expecting this of end users is problematic (as I’ve explored to some extent before), and is likely to lead to very minimal spread and adoption of a piece of software.

Recently, I have been speaking with the Tahoe-LAFS project about improving the usability of their secure, decentralized file hosting system. They told me an OSX package was newly available. Oh, excellent, I thought. They can be a candidate for the expert UX review sweep we’re about to do. Under the guidance of a Nielsen Norman Group researcher, we would walk through the discovery, install, setup, and basic functions of a small suite of FLOSS security tools.

The Tahoe-LAFS team gave me a link to a recent functional build. I downloaded the package, ran the standard Mac installer, and clicked on the resulting app. It gave me the error message “You can’t open the application “tahoe” because it may be damaged or incomplete.”

I went back to their devs. It’s broken, I told them. Can I have a new package?

Oh, they said. You just have to run it at the command line.

At this point, it looked like the expert review for Tahoe-LAFS was off, and I was going to have to report that the app had showstopping failures. Mac users are at least marginally used to double-clicking packages to install them (and these days, the iTunes store means they often don’t even need to do that). Any user, no matter how advanced, is likely to take a system message saying an app is “damaged or incomplete” at face value. Even an expert user would be unlikely to try to work the app at the command line at that point; forget about asking your average nurse, retail clerk, or office manager to do so. All that aside, I didn’t have any interface to evaluate.

Then one of their developers sent me a video of the Tahoe-LAFS setup process, and I saw an opportunity to do a review comparing what I saw to standards for usability.

And as it turns out, this is may also be more generally helpful to explain to FLOSS developers why the command line isn’t just “not ‘shiny‘” or “not dumbed down like a GUI” — it actually cognitively disables users.

Here is my annotation of the Tahoe-LAFS setup video. NOTE: Have the YouTube “Annotations” feature active, or you won’t see the usability comments and none of this will make much sense.

I’ve used the relatively standard usability heuristics from Jakob Nielsen as the source of the annotations here. Quibble with them as you may; note that heuristic review is kind of outdated as a UX tool; complain that the article is old. That still doesn’t change the fact that from the moment the user hits a command line prompt, they’re instantly faced with a tremendous number of known usability problems.

Not the least of which is cognitive load. Command lines demand that users remember the correct phrase to make the system run, rather than giving them prompts which might help them guess what the system needs them to do next. The overwhelming majority of people alive today have never had the opportunity to learn those commands. Making them look them up and learn them themselves would make them very, very frustrated — they don’t have time for that. GUIs aren’t just “shiny“: they are tools which help us remember what is possible.

As the cognitive load article advises tool developers:

Offload tasks: Look for anything in your design that requires users to read text, remember information, or make a decision. Then look for alternatives: can you show a picture, re-display previously entered information, or set a smart default?

(Let me just put this one more way:

Interior-solid-wood-doors--14The door on the left is like a command line interface. Notice it has no handle. It’s not at all clear to the user which way the door would open, if it opens at all. The user is going to have to work hard to figure this door out. But it looks like whoever owns the building doesn’t want you using this door, anyway. “Get lost,” this door says. “You’re not wanted here.”

The door on the right is like a GUI. You can get a sense — just by looking at it, without any pushing or prodding — of what you’re supposed to do from the handle on the right. If you look even closer, the hinges on the left would clue you in that the door opens inward, so you won’t stand in its way and get hit. As an added bonus, this design lets you see what might come next — someone might be waiting to come in, you might need an umbrella if it’s that overcast, etc.)

Other standards which would be useful to Linux developers moving to develop for Macs might include the OSX Human Interface Guidelines. In this case, their guidelines for “Starting and Stopping” come in handy. Note the mismatch between these guidelines and the video above:

  • The guidelines assume that developers give users setup and onboarding information. Not much of that has apparently been provided in the video. (Maybe there’s a balance to be struck?)
  • The guidelines suggest using animation and interactivity to explain setup. None of that in evidence in the video.
  • The guidelines suggest setting reasonable defaults. One of the first things the video demonstrates is changing defaults. It will be useful to the Tahoe-LAFS team to answer the questions: Why would a user want to change defaults? What are their goals for protecting their files? How often will they need to access these files, where, in what settings, and from which devices?
  • Like the Nielsen guidelines, the OSX guidelines recommend making features discoverable — which, at the command line, they won’t be.

So there’s the review. The good news is, it seems like Tahoe-LAFS is in a very good position to build a smart new interface from the ground up. I hope to work with them on that…

Comments 18

  1. Professor Sir wrote:

    Homework assignment: read the manual.

    Posted 07 Apr 2015 at 4:21 pm
  2. Karl Fogel wrote:

    I think it’s not a matter of “useable” or “not useable” as objective facts — usability is by definition subjective. The question Tahoe-LAFS and other programs should be asking themselves is “What is our intended end-user like? Whom are we writing this for?”

    It’s a real question. If the answer is “experienced Unix sysadmins who are comfortable at the command line”, then that’s fine, but the program’s distribution channels need to say so. The introductory documentation, the downloads page, etc, should make it clear who the software is meant for, so that people who aren’t intended users don’t make the mistake of downloading it and trying to install and/or run it.

    There’s a *separate* question of whether Tahoe-LAFS is making the right decision in being a command-line program. Maybe it’s not. But it’s not simply an issue of “Command line people vs ‘normal’ people”. Rather, the software authors have to characterize their expected user base explicitly — there’s no such thing as a “general audience” (as writers already know, but software authors sometimes don’t).

    I suspect you would say that they are making a mistake if they’re targeting command-line-comfortable users, and I think I would agree with you :-). But first they have to say who they’re aiming this at; only then can they consider the question of whether they’re aiming accurately.

    A statement like “…the command line isn’t just “not ‘shiny‘” or “not dumbed down like a GUI” — it actually cognitively disables users” is false — or rather, it cannot be evaluated as true or false, because it doesn’t include enough information to determine its accuracy. If you are a command-line-comfortable user using a tool that is designed for the command line, then it *is* in fact way better than a GUI. Measurably so: you can accomplish what you’re trying to do faster, often orders of magnitude faster. But if those conditions don’t hold, then all bets are off. Just saying it “cognitively disables users” without saying *which* users isn’t meaningful, though, I think.

    (That’s a minor criticism of an otherwise tremendously useful post, I hasten to add. The experience you had with Tahoe-LAFS was obviously sub-optimal, and you’ve taken the trouble to explain to them exactly how. I hope they listen!)


    Posted 08 Apr 2015 at 4:24 pm
  3. gus wrote:

    Thanks, Karl. That is, in fact, a variation of what I’ve been saying to Tahoe-LAFS’s team on IRC in the aftermath of writing this: this was a matter of mismatched expectations. They presented their client to me as an OSX app which was ready for heuristic usability review; I presumed for end-users, they presumed for more sophisticated users, I guess. And it’s ok! Even if we’re looking at this as a tool which should be for less-sophisticated users, there was just a little mismatch in what the understanding of the process was: we were proceeding as if there was a reviewable product in that regard, when in fact the stage they’re at is “time to design workflows for a minimum viable product for end-users.”

    But tbh? If you did comparative cognitive or even neurological studies of CLI versus GUI use, say between expert users of each, I bet you’d find that time on task, reaction time, and mental activation on CLI would indicate the user was still having to do significantly more work in the CLI. (I’m not a neurologist, but I have done some work on cognition.) I wouldn’t be surprised to find such studies already exist. Not to mention that if you had learners of each system measured along those lines, you’d pretty definitely find they were having to labor harder at doing what they wanted to with a CLI.

    It’s not for no reason that Jakob Nielsen points out that recognition is easier than recall. This is backed up by cognitive science, and explained at more length in this NNG article.

    I am worried that those of us who have worked at the command line for a long time (and I have! Since 1995! Twenty years now) are ignoring the cognitive bias we have as a result of all of the practice we’ve had at the command line. Of course it’s easy for us! By now, we’re experts, and experts think faster because they are able to recognize chunks of patterns more quickly as a result of practice and regular use. (Lots of good research on chess masters, in that respect.) But that doesn’t mean the system is inherently usable in the abstract.

    You can accomplish things orders of magnitude faster at the command line, Karl. And Garry Kasparov can accomplish checkmate orders of magnitude faster in chess than he can accomplish bingos in Scrabble, I’ll bet you.

    And now I’m waiting for a bunch of Glyph’s friends to show up with the complaints they’ve had about good and bad command line interfaces — because even at the command line, there’s good design and bad design. And without criteria for comparison, like Nielsen’s heuristics, we’re likely to be subject to our own biases in evaluating those designs.

    Posted 09 Apr 2015 at 10:21 am
  4. David Reid wrote:

    Hi Karl,

    I disagree that it’s a problem of characterizing the expected user base.

    You have to understand in what context your users want to use the product you’re building. As a developer I frequently DON’T want to use many tools because they force me to use my skills as a developer in a context that isn’t developing software. (Skills such as memorizing and manipulating long sequences of characters.)

    Let’s say we want to write a book keeping program. It has a command line, and it mostly manipulates plain text files. There are totally advantages to both of those features, but for most people, the process of editing a file, running some commands, editing another file, running some commands is going to be painful.

    Developers recognize this as the edit-compile-test cycle.

    We do it a lot.

    But that doesn’t mean we want to do it when we’re just trying to balance our checkbook.

    You can’t just put “for developers” on the end of the description of your product and be absolved of all your usability sins. The context in which the user actually interacts with your product is more important than your expectations about when the user will interact with your product.

    -David “No, not the pilot.” Reid

    Posted 09 Apr 2015 at 11:38 am
  5. _Mark_ wrote:

    I think one thing that’s triggering the command-line “old hands” is that when you say the command-line “cognitively disables users” (paragraph 9 above) you’re *also* not qualifying your target user base, so it reads (perhaps unintentionally?) like you are asserting that claim about people like Karl or myself (and I certainly have people express surprise at how fast I do things from the command line – makes *teaching* command line things harder, for sure – and while that’s not rigorous either, *something* is going on there…) rather than restricting the scope of your users to whatever subset of “Mac users” you based your tahoe analysis on. To put it more succinctly, “you seem to have painted us with an awfully broad brush”…

    As for criteria in the computer interface space – how about Raskin? “The Humane Interface” actually lays out what appear to be a decent (and commercially tested, though I haven’t looked for further academic work myself) set of metrics for interfaces in terms of steps taken and mental effort; the novel part at the time was assigning a cost to *switching* between mouse and keyboard, but there was a lot more to it than that; that was just the part that explained where the “mice make it better” fallacy came from.

    Posted 09 Apr 2015 at 9:42 pm
  6. gus wrote:

    I do stand by my assertions that cognitive research could probably be used to demonstrate the additional burden the command line places on any user at some point in their use (if not learning for the first time, perhaps re-learning after a long period of absence, or learning a new command). But yes, Mark — I am painting with an awfully broad brush. (Thanks for pointing me back at Raskin; will review.)

    I am forcing our attention back to cognitive research because without the support of cognitive research, you get people dismissing usability, as Karl did above, as “by definition subjective.” This is dismissive of a long tradition of research which has factored hugely in the spread of computer use to more than just a small elite group.

    I’m pushing so hard, taking such a hard line, because I care about the open source ethos. And it kills me to watch open source projects shoot themselves in the foot by insisting end users be as expert as developers are. To even have to explain at this point in history that the command line doesn’t really count as a “usable interface” for most people is kind of mind-boggling. But after a few go-rounds with developers, it became clear this point needed to be made, and it needed to be made by referring to and re-creating the evidence that has slowly been built up by user researchers over decades. Because developers respect evidence, I think.

    At least, if I went in without evidence, I was sure to be dismissed as being subjective, working off anecdotal evidence, or being biased towards other operating systems or interfaces. As it is, the tradition that this argument is based in was dismissed as “subjective” anyway (and in IRC, I was told that a given research paper could just be evidence of “the publish or perish system,” not of any more enduring pattern of human behavior).

    Posted 13 Apr 2015 at 11:26 am
  7. Karl Fogel wrote:

    @David Reid

    Sorry, I may not have explained clearly. When I said “characterize the expected user base”, I meant characterize them with respect to the task at hand — i.e., to how they expect to interact with this software. It’s not about the person; it’s about the person-task relationship.

    IOW, even if someone is a developer who likes to use the compile-edit-test cycle for developing programs, that doesn’t mean the same person wants to use that method of interacting with their bookkeeping software.

    (However, some people do. I literally *do* use a comand-line-and-text-files style of bookkeeping software, because that’s the way of interaction I want for that particular task. Fortunately, someone is writing software to target that specific user/task relationship, so I have something I can use. But I would never want to use that style for, say, a musical score editor — for that, I want a GUI, even though there are some rare people who actually prefer a non-GUI interface for that.)


    When I said it was “subjective”, I just meant that literally — as in, any evaluation must involve the subject (in this case, user+task). Saying something is “subjective” is not the same as dismissing it, and I wasn’t dismissing user research at all. “Objective” and “subjective” aren’t synonyms for “measurable” and “not measurable”; the subjective questions I was suggesting are quite measureable — all I meant was that the formulation of the question needs to involve knowledge about the type of user and the goals they have around the task (e.g., goals such as how much up-front investment they’re willing to make for how much benefit, etc).


    “To even have to explain at this point in history that the command line doesn’t really count as a “usable interface” for most people is kind of mind-boggling.”

    Yes, I agree: any developer who thinks otherwise is clueless. I hope nothing I wrote above sounded like it disagreed with that, because I certainly didn’t mean to.

    Posted 13 Apr 2015 at 5:23 pm
  8. imuli wrote:

    “I do stand by my assertions that cognitive research could probably be used to demonstrate the additional burden the command line places on any user at some point in their use (if not learning for the first time, perhaps re-learning after a long period of absence, or learning a new command).”

    I fairly frequently run into the opposite problem that you seem to have here. Too many applications without decent command line interfaces. The use hints provided by GUIs come at the cost of programability, which is key to accommodating unforeseen uses and automation.

    Ideally one has both, and ideally, the UI and scripting interface are united. We’re a long ways from having the first ideal, but the command line at least gives us the second.

    Posted 14 Jun 2015 at 2:08 pm
  9. Mike S. wrote:

    I’ve been thinking about this exact problem recently. How about a shell session like this?
    # processes
    Welcome to ‘processes’. Press ‘q’ to exit.
    Add ‘ –noprompts ‘ or ‘ -np ‘ to the command line to skip this interactive process.
    Show processes for all users (y/n)? y
    Added flag ‘ –all-users ‘ or ‘ -au ‘.
    Search for program name (y/n)? n
    Search for command line arguments (y/n)? y
    Enter string to search (press enter for none): foo
    Added flag ‘ –cmd-args “foo” ‘ or ‘ -ca “foo” ‘.
    Running> processes -np -au -ca “foo”

    … why didn’t we make this years ago?

    Posted 03 Aug 2015 at 7:51 pm
  10. A. Person wrote:

    Uh, for most command line tools:

    executable –help

    or even


    should spit out a bunch of helpful usage information. This has been a CLI UI standard since the 1980’s (1970’s even?).

    There’s also:
    man executable

    I wouldn’t otherwise bring it up as first example, but you mention OS X, so I’ll start on that. Notice how Apple has totally retooled the GUI on a number of their criticial system applications in the last few years (eg: Disk Utility in El Capitan)? If you are relying on being able to execute a particular “workflow” based on your past knowledge, and a GUI is fully retooled, the user must adapt their knowledge to the new GUI, and the patterns of use that the UX developers have forced upon them.

    I don’t have any evidence, but I’d expect that for command line tools, you’re likely to see less dramatic overhauls in things like flags, etc. and where you do you will often see warnings letting you know a particular flag is deprecated or unsupported.

    Something that comes to mind, again with OS X, is moving directories. On Windows, Linux, and pretty much every other modern OS that I know of that has a “directory” or “folder” concept, when you move one directory into another in a GUI and there’s conflicting subdirectories there, you will get a warning and be prompted to merge; on OS X the existing subdirectory with name conflict will be over-written, and I believe this used to be *silent*. To avoid this, I think you need to hold the “option” key, or something.

    Now, if you were doing this on the command line, firstly you’d know if you were doing ‘cp’ or ‘mv’ vs. a GUI drag and drop operation, whose interpretation varies by OS and version, you’d know that; and secondly, I’d expect most sensible command line tools wouldn’t let you silently overwrite a directory without using a ‘–force’ flag.

    So these are just some scenarios to consider.

    Well-engineered GUIs can be extremely useful. I think the recent problem is the trend towards dumbing-down of the GUI to more of a web-page (or “mobile”) style UX, instead of maintaining traditional GUI standards we’ve been relying on for decades; I think this creates a huge burden on the user to adapt to the new interface, and that it’s been generally coupled to a shift to “beta” product releases that often have very poor documentation. So, you end up with features that you need becoming buried deep in the GUI, and there’s no apparent recognition on the developers side of the cost to the user of these disruptive UX changes.

    I think you’ve hit on the source of these problems when you mention Apple and Android, which I think is a move to make applications run across all device types, most of which do not have a keyboard. You can look at a parallel situation in game development when games switched from predominantly PC-based to console-based in the dumbing-down of controls, which then constrains the type of games you can make. (eg: would games like “Lemmings” — I know this is a really old reference — have existed if not for the PC and mouse?)

    Which brings me to the last point, which is “pipelining”. Sure, there are things like “AppleScript” (which really is command line, if you think about it) that allow you to create “pipelines” or “workflows” out of GUI-base applications, but I don’t think anyone would argue that having the ability to use a command line for this sort of thing is preferable. This is why Linux (and OS X) is popular in science and engineering — people need to be able to automate workflows to get things done, and good luck doing that efficiently in a GUI (and then try porting across OSes!!!).

    That said, there are a lot of command-line tools that have great web-based frontends, without which I probably wouldn’t use those tools. So you need both, but a good command line comes first.

    Do you use Homebrew for installing packages on OS X? It really simplifies things on the CLI side on OS X.

    Posted 29 Sep 2015 at 1:46 pm
  11. gus wrote:

    What I mean is that “executable –help or even executable” are not visible immediately to the mass-market end user. For the first time user who is not in the know, it doesn’t matter that this has been around since the ’70s or ’80s. And that person has become accustomed to iPods: they have one button. It is obvious that you’re supposed to push it, and it will Do A Thing. And then the other things on the screen behave like physical objects you can move around with your hands — something the vast majority of living human beings learned to do before they were even verbal. Most of those same human beings did not have the time or resources to practice the memorization necessary for facility at the command line.

    Tahoe-LAFS was, at the time I wrote this, suggesting to me that they had made a GUI which would soon be able to serve as a competitor to Dropbox. This article was me explaining why that was not what they currently had.

    Posted 11 Oct 2015 at 10:24 pm
  12. Mr. Mister wrote:

    The whole “Why the command line is not usable”.. GUI is GOD.. idea is just so wrong. GUI interfaces are in another whole universe separate from the system they control. GUI programming takes a different kind of brain to produce, different from that needed to create complex systems software that works. Upstart projects have limited man power and all developers are focused on creating a system that works. GUI interfaces are not even considered until the system has been proven out, and even then only if there are enough human resources to permit GUI development. The best way to kill a complex project is to try and make it GUI driven in parallel with system development (unless you are Microsoft or IBM with unlimited delevoper resources). Thrown together GUI interfaces many times limits and possibly makes unusable otherwise great system software. One might consider too that Granny probably was not the intended target user as well.

    Posted 17 Oct 2015 at 9:26 pm
  13. Sam wrote:

    Professor Sir wrote,”Homework assignment: read the manual.”

    Sam says”Where did I put that damn manual?”

    Posted 01 Nov 2015 at 8:33 am
  14. Nick P wrote:

    There’s a simpler solution that goes back to mainframe era: well-designed, textual interfaces. Not blind, cryptic commands plus Google, Gmail, forums, etc. Instead, a series of menu’s, dialogs, and/or command parsers with built-in intelligence/suggestions/checks. There have been many text interfaces that avoided most of the problems mentioned in the video. They were either the app itself or a separate, configuration app that produces config file or feeds primitive commands into main app.

    Far as command line vs GUI, that GUI’s were superior for common tasks in both productivity and cognitive load is long proven by research studies on actual users. All types of users. They used to be cited all the time when GUI’s weren’t popular in business. It’s actually kind of obvious when you compare filesystem configuration that’s in the video to a GUI like Ubuntu’s setup, Windows disk setup, or Apple’s Time Machine. The common case either eliminates a need for figuring something out or the presentation is so good that I can do what I’m trying to do without fully understanding internal concepts. If you have to do more to achieve same job, then clearly that approach is harder regardless of one’s level of expertise. Break it into objective steps, each’s underlying knowledge, each’s assumptions, and difficulty of acquiring all that. You’ll find objectively that well-designed GUI’s come out way ahead in terms of whats required to get job done.

    Now, all that said, there are times when non-GUI’s (or at least an option) make plenty of sense. A commenter already mentioned automation or use-cases people didn’t see coming. Cryptic, non-standard commands are still a problem, though. Languages like COBOL, BASIC, and Tcl were highly successful in these cases even with laypeople because their design keeps close to the verbal, step-by-step description of solving the problem. Usually came with suggestions, case tools (eg 4GL’s), little to no boilerplate, anything complicated already done generically, and so on to ease user burden. Basically, ways for the user to think as little as possible about how the tool works and easily do what they need it to do.

    So, there’s tons of room for improvement in usability and even flexibility in these command-line-driven tools. The GUI’s are objectively, provably superior when designed well for common cases. However, the TUI’s (not command lines) are often nearly as usable when designed well. Programmatic, text-based control is best done with a consistent, easy-as-BASIC-or-TCL scripting language that abstracts away as much as possible. Preferrably a common one across all apps so user learns platform language rather than apps. Or, for developers, a real programming language using an API the application exposes for the purpose. I’m guessing that’s out of our current discussion, though, given most users won’t do that.

    Note: Also helps to stick closely to the conventions of the platform. One of the reason I always separate the business logic from the presentation part.

    Posted 16 Dec 2015 at 2:59 pm
  15. sohalt wrote:

    I think the problem with the sort of GUI that is widely spread today is that it is very inflexible, not adaptable and not scriptable and often constrains power users too much and makes more advanced tasks unnecessarily tedious. Most GUIs don’t grow with their users and while they are more approachable for a beginner they prove more of an annoyance for the expert. That is not to say that GUIs are a bad idea. To the contrary, I think they are the inevitable next step in user interfaces. All the noted concepts about user friendly design are valid and CLIs really do a poor job at handling the “recognition rather than recall” paradigm (although context sensitive auto completion can help a great deal) and a well designed GUI can often be faster for certain workflows than typing a series of commands.
    I would like a GUI to exist for a lot of tools that only have CLIs, but as long as the GUI doesn’t provide the flexibility of the CLI the CI has to be provided in addition for when you want to do more advanced work. Given this fact and the problem, that modern GUIs of the kind that is most prominent are very labor intensive to design and hard to adapt I can very well understand, why many projects only offer a CLI. But I think this is a solvable (and partly solved) problem, in that there are ways to streamline GUI design and make GUIs more flexible and adaptable. For example the Smalltalk programming language ecosystem and its descendants provide what to me is to this day probably the best approach to GUIs I know of. The GUI is a first order citizen in the language and parts are easily reconfigured or changed. For example adding a new button executing a custom function using parameters from a dropdown __while the program is running__ is trivial.
    For me a lot of the GUI vs CLI debate comes down to tooling.
    GUIs have to be as easy to create as CLIs and have to provide the same flexibility. I want to generate a GUI with sliders, textboxes, dropdowns etc. automatically from a declarative specification, eg the types of fields in an object/record/map/whatever your favorite programming language calls them. I want to be able to “ask for a phone number” (i.e. one function call getPhoneNumber() or similar) and have the system automatically open an interface, that asks for a phone number in a reasonable way, for example including suggestions from a persons contacts, validating that the input is a valid phone number and then provides the number to me in a standardized format.
    There is a lot of work to be done to make this possible.
    I think it’s doable, but quite a way from where we are now.

    Posted 21 Dec 2015 at 1:45 pm
  16. Slinky wrote:

    @gus: “And that person has become accustomed to iPods: they have one button. It is obvious that you’re supposed to push it, and it will Do A Thing.”

    Well, explain to me how one connects to a WIFI with a tablet (iPad, Android, whatever). Or how one sets up WIFI tethering. Also explain why these use-cases would be obvious for someone who has no idea what a wireless network is or what tethering is as a concept, even though they know (by prior experience!) that pressing a physical button usually Does Things (not necessarily A singular thing!).

    When one has done the connecting/tethering a few times, one probably remembers it and then it’s not a hard thing to do. Same thing with remembering that usually “command –help” displays a list of help, and usually “man command” goes much deeper into details.

    GUIs are perfect when the task description is quite limited and there are not many combinations of possible things to do. CLIs are perfect when maximum flexibility is required.

    Case in point: if a CLI program is always used to do one thing, and one thing only, with a tiny set of changing parameters, one usually makes an alias or a shorthand command to do just that. And then we are nearing GUI thinking – that “simplification” could well become a GUI program.

    Another case in point to illustrate the differences: one wants to sort a file containing names and process every name with “i” or “e” or “k” and create a picture from them and put them to a directory called “nametags”. A GUI program would have to have this use-case specifically designed in. A CLI program would (for example) just pipe the name-list output to a filter program, collect the list and then use another CLI program to generate images with the text.

    Personally, I would not process digital photos using a command-line tool, I would use a GUI program like the Gimp. If I needed to resize 100 images to 33% of the original size, I would not use the Gimp, but something like ImageMagick (a CLI program). For me, it’s much much faster to write the CLI command and be done with it, than to search for a suitable mass-resizer GUI program, install it, figure out how to use it and then do the task. Other people do it differently.

    My point is, usability is task-based and is not an absolute: CLIs are not universally unusable. Something is not of low usability just because you are not accustomed to it. Usability depends on the context and prior knowledge and experience which varies from person to person – sometimes GUIs are the only thing which makes sense, sometimes CLIs work better, for some there’s a choice of what to use, for some there is no choice.

    Posted 23 Jan 2016 at 2:51 pm
  17. WorBlux wrote:

    A GUI is easily adopted to be discoverable and reveal relationships between options or other information. A CLI is precise, has minimal dependencies, and is easily compensable and lends itself well to scripting and automation.

    There are some interesting ways of mixing or combining features of both (parted, fdisk, and the kernel’s make config come to mind or two-window file managers that include a text box where you can run commands or filter files.

    If you just want a free dropbox, you’re probably ok in being put off by a GUI, however if you are concerned about your data and security becoming comfortable in a CLI environment is going to help you out a lot over the long run.

    Posted 04 Feb 2016 at 7:36 pm
  18. Karolin wrote:


    As you said, the shell is lacking is a way to hint users towards common use cases,
    while in the GUI, it is almost impossible to combine applications.

    I think we need to use a new, combined approach that lets users start with user interfaces as concise as today’s excellent GUIs, but providing tools to empower users to learn the power of programming in a rewarding learning curve. Without the leap of faith that is jumping from GUI to CLI or any programming language today.

    Thanks for your post; the shell is indeed entirely unsuitable for use by non-experts:
    if a user opens a shell to solve a particular task (let’s say they want to display the current time), they will probably understand that they have to text something. Maybe they think of typing ‘time’ or ‘help’, but both of these commands will be entirely useless for what they want to achieve. Maybe they will take some time to research, and after a considerable time they might successfully be able to type `date`.
    Next, if they want to list the items on their desktop, they won’t have any idea where to begin with: after even more research they will learn about cd and ls, but at this point we’re just in day two of learning a programming language.

    In the GUI, by contrast, you are likely to find out in seconds how to do these things; you will see the current time anyways on any decent system and even from only knowing how a mouse works you can probably learn how to navigate the file system from randomly clicking on the screen within 30 minutes or so.

    Now let’s take a much more complex task; let’s delete all the images from a folder. This can be accomplished easily if you are an experienced shell users, yet if you are an experienced GUI user, it will be extremely difficult. I just tried to research how to “mac delete all mp3 from folder”, and the first result I got was a forum showing me an appropriate command line.

    We create GUIs often by analyzing what usecases an application will have and based on that we will create hints for maybe 90% (arbitrary guess) of them. We can optimize that by using sane defaults (values for preferences, or just showing all the tracks in the playlist without any need for user intervention). We can group actions/views so users can make an educated guess about where to find a certain action.
    Ultimately though, there is a limit to the space of actions that can be performed using a GUI; we can only display so many options and hints until we simply can’t fit more information onto a screen: a list of 10000 preferences is about as useful as displaying none – just like we do in a shell.

    GUIs also put a considerable load on the programming team: I am a programmer and I’d usually estimate two times the effort for creating a terrible GUI I design myself and more than ten times the effort for creating an excellent GUI with professional designers and usability studies.
    This is because good user interface design is very hard, but also because with a GUI you have to explicitly handle every single use case: if a want a feature that lets the user select a file to write to, or read from a website, I will have to built that in manually. Moreover, for the URL feature I should probably even display the website I am reading from within my application.
    In the shell, I usually just assume that the user will use curl and redirection to accomplish both those features, so I can support those features without actually programming anything.

    GUIs show what can be achieved, by limiting what can be achieved. Having the computer hint users at what the system needs them to do quickly reaches it’s limits: ultimately the user needs to tell the computer what they want it to do.

    I think it is possible to combine those approaches, because in a way GUIs already do this: App stores let you expand your system and customize it to your needs. At the beginning you see a very limited set of possibilities with those applications you are most likely to use.
    When you then expand your set of applications and add an application, you will have actively selected it and learn what it does.

    I also think, we can take that even further and create a learning curve for normal users that empowers them to expand the way they use their system and even get to a point where they can perform moderately complex programming tasks (such as removing all mp3s from a folder).

    It is hard to predict what such a system could look like and you’d need a big research team to get any meaningful idea, but my best guess would be having a normal GUI on top, backed by a graphical gui editor and a flow based, graphical programming language as a replacement for the shell and it’s pipes.
    Simple things like moving a button, or connecting the value of one field to some data receiver could be done using drag and drop (drag a text field to the notification icon to display notifications when it changes; drag it to the browsers URL bar to automatically follow the url). You could show users what happens in the flow interface when you drag a value somewhere, to teach them about the flow interface.
    If the GUI can easily be edited, this could also be useful to admins, optimizing an interface for their specific organization.
    The Flow interface could be stored as a full programming language (Rust or GO or something), so you can use that for algorithms and tasks that exceed the flow interface and you could learn about the language by using the flow interface and looking at the resulting code.
    You could even package sets of hints how to program as GUIs: how about a window that just displays the date in various configurations, so when you want your date in some weird format, use the GUI to configure how the date format should look like and then drag the result to the menu bar (on os x).

    Posted 20 Mar 2016 at 12:28 pm

Trackbacks & Pingbacks 3

  1. From No, the GUI is hard — but we can make the CLI better – INGEGNUE on 27 Mar 2016 at 6:59 pm

    […] mentioned this blog, which contains this quote on why the command line is […]

  2. From 7 ways to make new contributors feel welcome | D4mations.com on 22 May 2016 at 4:24 am

    […] (open source software). Sumana (who had so many great references for us) encouraged us to read an article that addresses this controversial topic (command line versus GUI). And, one professor argues that computer science students who are […]

  3. From 7 ways to make new contributors feel welcome - Opensource.com - Adverther on 22 May 2016 at 2:27 pm

    […] (open source software). Sumana (who had so many great references for us) encouraged us to read an article that addresses this controversial topic (command line versus GUI). And, one professor argues that computer science students who are […]

Post a Comment

Your email is never published nor shared. Required fields are marked *