1. 33
  1. 12

    Most technical people choose GUIs not because GUIs are the best tool for the job. People choose GUIs because the CLI alternatives usually suck.

    [Citation Needed] Speaking personally, there are a lot of times a GUI really does work better. Often it’s when browsing through long lists or hierarchies — while the git CLI is pretty good, I use the Fork app instead 99% of the time because it’s so convenient to scroll through the commit graph or modified-files list, and to stage or skip diffs with single keystrokes.

    I’ll also often type “open .” when I’m looking through a directory tree and continue the search in Finder. I know there are terminal-based file browsers, but I’d classify those as GUIs running in a character-grid display, not as CLIs.

    Obviously these choices are highly personal. But it’s undeniable that a lot of developers use IDEs and visual tools, and while there’s still a strong trope of the neckbeard Unix programmer banging away on his (always his) VT100 and sneering at wussy GUIs, I wonder if the majority of devs are still so CLI-centric.

    1. 9

      CLIs are good when you know what you want to do and don’t need context. CLIs suck for context. That’s not to say you need a full blown GUI. A TUI might be good enough. But for example, if you’re looking at a file system where you don’t already know the contents, a GUI is going to kick the pants of typing cd and ls over and over. Even a TUI like Midnight Commander will be better than that. OTOH, if you already know how the files are laid out and you just want to look at the permissions of one file, typing ll path/to/file with tab completion will be faster.

      I use a GUI for day to day git tasks like looking at diffs and staging them, but then for anything even slightly more advanced than changing branches, I end up using the command line. Then there’s git rebase -i which is effectively a TUI on the cheap.

    2. 7

      I disagree with some parts. For example I find emojis visually distracting. The reason is that they usually means some multi colored thing in the middle of (hopefully) mostly single colored text. So your fucus will automatically shift towards it.

      While I think colors can be used to highlight s stuff please don’t overuse it. Sometimes it’s enough to have output bold. Especially when you don’t need to signal “look at this” because your tool is forced to output a lot of text to do its job.

      On that note please desoite this don’t per default output huge amounts of redundant text. Every additional line can cause important bits to be missed or take time from whoever is using the utility.

      I also have an addition. Please make sure that with all these things you add you still keep it good for non interactive use. And please don’t just assume nobody will use the tool in some script so make sure it also works well in that scenarii.

      The article is really great and especially the human readable output and the streams section are things that people seem to mess to a bit while writing cli utilities.

      1. 5

        I find emoji useful for prompts, errors, or other things you want strongly highlighted. But yeah, they can easily become overwhelming, like using too much jalapeño or cumin in a recipe.

        alternatively, there are a bunch of useful Unicode symbol characters — math symbols, dingbats, etc. — that are evocative but not multicolored.

        I’m also font of using bold/italic text instead of color. A problem with using colored text is that you can’t predict the background color, so you don’t know what the contrast will be. Some colors that work great on a white background disappear against black or dark green, and vice versa. (Is there even an API to discover the terminal’s background color?)

        1. 4

          I disagree with some parts. For example I find emojis visually distracting. The reason is that they usually means some multi colored thing in the middle of (hopefully) mostly single colored text. So your fucus will automatically shift towards it.

          It’s not just that they’re distracting (because of the colours), but they’re also visually ambiguous.

          The first example on that page is an excellent example. In the shell’s prompt, the weird v-shaped symbol means “branch”, I guess. I’ve no idea what the box is supposed to mean. Tag, maybe? Revision number? The bullet next to it is… is it a bullet, or does it mean something else?

          I mean, these are CLI tools, they’re probably meant for professional users. They’re not apps meant to keep you hooked so that they can show you ads. Intuitiveness is a really bad metric to optimize for (leaving aside questions like is that even a thing and how do you measure it so you can optimize for it) – intuition is just one of the many species of assumption, and we all know who its children are. I really don’t want to guess what’s going to happen if I git push from this directory based on cute little shapes, or find out that mistook the x-shaped emoji to mean “failure” instead of “this box is checked” and I did not, in fact, update some remote config. Unless you’re writing a cartoon-themed text adventure for the 8-12 yo age group maybe just write the damn thing, like it’s meant for adults.

          1. 5

            In the shell’s prompt, the weird v-shaped symbol means “branch”, I guess. I’ve no idea what the box is supposed to mean

            The same thing happens with ASCII characters in “classic” tools, like the marks appended to filenames by ls -F. You have to learn that “*” means “executable” and so on. With emoji or Unicode symbols you at least get a bigger choice of icons to choose from, so you can pick something more evocative or at least less overloaded.

            1. 2

              You do, but the “*” is more or less the same among different computers – depending a little on font, but it’s usually recognizable. Emojis vary considerably between platforms, both in shape and in color, making reference documentation pretty difficult to present. They also come in a far greater range, so there’s a far greater range of ad-hoc conventions about them.

            2. 2

              I mean, these are CLI tools, they’re probably meant for professional users. They’re not apps meant to keep you hooked so that they can show you ads.

              Ironically, this is one of the arguments that I use to support using more symbols in certain CLI projects. When I’m making software for non-technical users, I “just write the damn thing”, so I don’t have to deal with user confusion.

              On the other hand, when I’m designing CLI tools for developers, I usually seek to maximize information density. I know that a technical audience, when confronted with an unfamiliar symbol, can read the documentation and learn what it means. A small upfront cost to pay for greater flexibility down the road.

              Granted, all of these developer tools start with me scratching my own itch, so the symbols are always glyphs that I find intuitive. I’ve used other tools where I was confused by the symbols, but I usually could find it in the docs soon enough. Granted, search the docs for a unicode symbol is much easier than searching for an icon.

              1. 3

                I’m all for greater information density. But if I’m writing software that drives industrial pumps, or handles the private data of thousands of patients out there, cutesy bubbly red broken hearts instead of grepable/searchable error messages are just not something I want, and especially not something I want to show my customers.

                1. 2

                  The article did say explicitly that emojis were in addition to error messages – even using the word “grepable”:

                  Ensure your tool’s output is still “grepable”. Do not use emojis to replace words for which users may want to search.

                  1. 2

                    In practice, it’s really difficult to guess what users may want to search. If you don’t use emoji to replace anything, your output just gets longer and bubblier.

          2. 7

            See also: https://clig.dev/ “guide to help you write better command-line programs, taking traditional UNIX principles and updating them for the modern day”

            1. 1

              My greatest wish is that CLI tools on Unix would return 0 on success and remain silent by default unless a verbose flag is passed or an error occurs, so they could be properly scripted.

              So many tools fail in this regard and assume I want to have a colorful, Unicode-laden interactive “experience” in my terminal. No thanks. If I will use the tool more than say 3 times I want to automate it away so I can move on to something more interesting

              See also: Style section of McIlroys intro the Unix docs: http://danluu.com/mcilroy-unix/

              1. 1

                Generally good, but I must make a comment here:

                In 2022, you can even have beautiful animated charts if you use libraries like Go’s termui. What a wonderful world.

                I’m not sure why this sentence begins “in 2022”. To be clear, both termcap and the curses library (now ncurses) has been a standard part of Unix since the 1970s. While the original curses library may have been slow to adopt newer (at the time) features like 256-color capabilities, all of that was well standardized before the existence of Go.

                1. 2

                  curses has always had absolutely horrific DX.

                2. 1

                  I don’t know if it’s nitpicking because I quite like the article (overall, fully agree sans emojis) but that huge, annoying, distracting “Getting Started” message isn’t intuitive, it’s instructive. Intuitive would be that you can run a subcommand and have a pretty good guess at what it does and how to use the tool without reading through lots of documentation. Your intuition might be “tool init is going to initialise a project, merge is going to merge this project and another, delete is going to do what I expect.” If there’s a big Getting Started ascii block you’re just being told what to do.

                  1. 1

                    Nit: the screenshot that is supposed to showcase yarn’s output is actually showing what git commyt does.