13 ms·

CLI user experience case study

179 points by Xophmeister 3y ago

hhthrowaway1230 3y ago
I love CLIs, i try to find inspiration in the one simon willison makes. His CLIs extremely good on the DX side. Llm, sqlite-utils and datasette are all very thoughfully thought of tools/clis. So good that I have been thinking to mail him to see if he wanted to write a blog post about his way of thinking about it. Its top notch from naming the subcommands the plugin systems. I always try to think along the lines of: I've i'm going to use this CLI a 1000 times each day. How do i want to use it. And if i want to automate it, how can i script it. Also CLI commands are basically contracts, since people will program against it. Good CLIs are very interesting puzzles bringing human ux and scriptability together. Aws cli's also have an interesting approach to it.
- simonw 3y ago
  Thanks for saying that! I did write a post with a few of the things I've learned about CLI design here: https://simonwillison.net/2023/Sep/30/cli-tools-python/ https://simonwillison.net/2023/Sep/30/cli-tools-python/
  - indymike 3y ago
    That's going into the required reading folder for new devs at my company. Thanks for writing that!
  - hhthrowaway1230 3y ago
    Thank you! Weird that I missed it haha! Will do some reading and will start applying the lessons learned! And ill reach out if im missing anything!
atoav 3y ago
As someone who teaches these things occasionally to non-tech people I think the hard thing about CLI tools are the following: 1. The terminal when you first open it is intimidating to most and doesn't offer any help to figure out how to use it. If people think something is hard, they will have a harder time understanding it as well (same goes for thinking something will be boring, there have been studies on that) 2. Text editing in the terminal works different than literally anywhere else. You can't simply click and mark text, shortcuts are different, etc. 3. You have to get that text has to be exact, you have to know syntax rules with where to put spaces, how to work with quotes, escape strings and all that. That is just not easy. For those of us who already speak any given shell, this may be aomething we forget. But it is like learning a language and a way to think. Once you are fluent, it is easy. But it is worth it in my opinion, especially if you want to work with niche special tools or if you want reliable tools that will just work for decades.
- 9dev 3y ago
  So do you think a terminal that works more along the way of thinking of non-technical people, or maybe similar to other text-based applications, could provide an entry point to non-technical power users? I have been thinking a lot about providing a shell-like experience as a quick way to make advanced functionality available in an app, without having to build fully fledged GUIs for them, but I’m not sure whether that would work. Clearly, discoverability and text input are the key issues, but I don’t know if alleviating those is sufficient to make the interface actually interesting and useful.
  - deleted 3y ago
    [deleted]
  - jonfw 3y ago
    VSCode's command palette is a great example of this- 1. fuzzy search through different options 2. Show lots of suggestions as soon as you focus in the text box 3. have a ? or other "learn more" option available I still think it leans very technical though, users would greatly prefer buttons. There's a good reason that powerpoint doesn't have one of these
  - swozey 3y ago
    When I make terminal apps I make both a TUI and CLI option if the app is big enough to benefit from it. Here's an example: https://i.imgur.com/dxXwRzD.gifv https://i.imgur.com/dxXwRzD.gifv This allows the less familiar or technical staff to do things with the app and also allows for veterans or CLI afficiandos to alias/run what they want directly from the cli.
  - atoav 3y ago
    I think using text to interface with computers is a genius idea and if it didn't exist someone would have ro invent it. But the way text interfaces on computers look nowadays are mostly shaped the way they are for historical reasons. It doesn't need much. First the text should be editable like other text on the OS, the cursor needs to be reactive ro mouse input. Second expected shortcuts should work, that means things like Ctrl+A to select all, Home to go to start of line, Ctrl+C for copy, Escape to cancel things, etc. I know there are reasons to everything and I am used to terminal shortcuts as well, but there is literally no reasons why we can't ensure they are the same there as everywhere else. Next thing would be the startup experience. If you start a terminal the first time, it should offer you some introduction. Sure, a seasoned user like me would be annoyed by that, but if you make it so it can be ignored by the likes of us or people that set the right environment variable, cool. Lastly, maybe it also a bit about the colors and fonts. I like bright on dark, but I can see how people who see this for the first time get flashbackanof every hacker scene they ever saw in any movie. And the subtext there always was: "You only understand this if you sacrifice all your social life". Imagine how a terminal would look like if it was made for kids and how that would make people judge their own ability to get this instead. I think a lot of the reason why terminals still look the way the do (apart from the fact it just works), is gatekeeping. Some nerds like that this is arcane, secret knowledge that looks as if it is hard to aquire. They don't like others to understand unless those others are also nerds.
sasham 3y ago
As all computer interfaces evolved in the past decades (from text to graphical interfaces, to touch screens and voice commands), the users' expectations have changed and the CLIs need to evolve as well. Today's users don't have time or willingness to learn something before they can use it. The number of tools in daily has grown as well, so they really don't have the mental capacity for that. We will always need CLIs for things that are to cumbersome or rare to add into GUIs; but they have to become easier to use, and provide immediate value. That's why we built an interactive CLI by default at Diversion. It's not a revolutionary tool (there are other similar CLIs), but it has shown to help our users get started with Diversion much faster - the feedbacks are overwhelmingly positive.
- BossingAround 3y ago
  From my experience, interactive CLIs are the worst of both worlds. They are not as pretty and intuitive as GUIs, since the user has to learn terminal idiosyncrasies (e.g. unable to ctrl+c, or edit text in the middle of the sentence by mouse). And, at the same time, they tend to be pretty bad for automating things (in the worst case, even unsuitable for automation) since now, you have to map the interactive commands to the non-interactive ones.
  - diversion 3y ago
    You're right in that an interactive CLI's interface is not trivial to nail. We're spending a lot of dev time on that actually. And of course there always also has to be a non-interactive version for automations.
  - Borg3 3y ago
    It depends on tool. If this is some generic utiliy that interacts streams, it most probably should not be interactive. But for example if this tool is some kind of control shell for subprocess (like Quagga vtysh or FW control CLI) it would be much easier to use in interactive fashion (autocompletion, interactive help and hints system).
- qwery 3y ago
  I think your linear evolution theory might be a bit too simplistic. There must be a branch somewhere (says the CS nerd). Where does AR & VR go? Before or after touch screens?
pr337h4m 3y ago
Discord has pretty much figured out how to give CLIs an actual UX with their bots and slash commands. Midjourney is the largest of the Discord apps that have achieved mainstream usage, despite being CLI-only.
- diggan 3y ago
  Huh? The UX is pretty much the same as in the terminal; "Here is a command, a small snippet of help text and a bunch of options, figure it out", not sure what Discord improved upon here. Autocomplete?
- anthk 3y ago
  Slash commands predate Discord by large.
  - deleted 3y ago
    [deleted]
- latexr 3y ago
  Bots and slash commands have been a staple of chat for decades before Discord. https://en.wikipedia.org/wiki/List_of_Internet_Relay_Chat_commands https://en.wikipedia.org/wiki/List_of_Internet_Relay_Chat_co... They’re no different from other CLIs, UX-wise. But because they are intermingled with chat, you can ask for help from a human right there.
  - deleted 3y ago
    [deleted]
- esafak 3y ago
  This is funny on multiple levels. For one, it is IRC that introduced these commands decades ago, as others have observed. The second is that the Discord "UX", especially for Midwinter, is atrocious. You couldn't pay me to use it.
  - cedws 3y ago
williamcotton 3y ago
?? I need to recursively tar a directory https://githubnext.com/projects/copilot-cli/ https://githubnext.com/projects/copilot-cli/
- s1291 3y ago
  That webpage does not explain how to get it. Instead, I recommend using gorilla-cli [0]. [0] https://github.com/gorilla-llm/gorilla-cli https://github.com/gorilla-llm/gorilla-cli
novagameco 3y ago
Powershell cmdlets make the CLI really nice to use; you declare the variables in your program parameters and then hitting tab will auto-suggest/auto-complete them for you, and you can generate help docs for each cmdlet as well
deleted 3y ago
[deleted]
jasode 3y ago
>Discoverability: Reminding ourselves how to perform what we know (or assume) can be done isn’t the same as guiding us towards the full gamut of what’s possible. I started with text mode CLIs on old 40-column computers like IBM PC DOS and Commodore 64 so I fully understand the techie's bias towards TUI command lines over GUIs. Lightweight, embed commands in scripts, command history, etc. However, the tension between CLI power vs GUI ease-of-use really hit me when I'm the user of personal utilities I wrote. Coding a console utility that uses command line arguments is always faster and easier than a GUI app. So, being lazy, 99% of my utilities are CLI. But I also annoy myself as a user when I can't remember what the syntax options are for the CLI that I coded so I end up having to open the source code and re-examine the argc and argv sections to see what the spelling or ordering is. If this happens often enough, I give in and expend the extra effort rewrite the utility as a GUI app with radio buttons, checkboxes, etc. That said, I still like CLI tools. E.g. I wish banks and credit cards had a pseudo SSH terminal that I could run text commands to list transactions. I really don't want to click around the bank's website or use a smartphone app.
- alright2565 3y ago
  > But I also annoy myself as a user when I can't remember what the syntax options are for the CLI that I coded so I end up having to open the source code and re-examine the argc and argv sections to see what the spelling or ordering is. I try to avoid this in two ways: 1. I use the history in my terminal to search for previous invocations of the command, which tends to give me a good set of examples of how it should be used. 2. For anything but the quickest and dirtiest CLI tools, I like to use a declarative parameter parser like docopt or argparse. This forces me to spend a couple extra minutes writing some docs and makes the --help useful.
- JeffSnazz 3y ago
  > E.g. I wish banks and credit cards had a pseudo SSH terminal that I could run text commands to list transactions. Really, it'd be nice if they offered any upgrade from the 80s beyond a smartphone app. How does the rest of the world have better peer-to-peer payments than we do? How can I still not fully deny all transactions to a bank account? Why can't this banking app ask my permission before letting charges go through? Why is over-drafting a debit card possible at all? Why can I not ensure that a PIN is necessary to use my debit card in all situations and not just at a physical point-of-sale or ATM? Why do they all use SMS for 2FA—which has already bitten my twice? I hate that Venmo and cashapp basically leech off the incompetence of our banking industry. Banking is a joke of an industry in dire need of regulation.
neatze 3y ago
seems like wrong case study, cli power (at least for me) is in comments and record keeping what has been done months if not years ago, and an "easy way" to script repetitive tasks, I just don't see how same thing can be achieved with GUI: record video and then comment it ? have detailed logs what button, and what fields where edits/pressed ? etc ...
DrBazza 3y ago
The consistency rule I follow in any CLI tools I write: options are optional, required are commands or arguments. Anything with `-` or `--` is an optional. Just like all the basic unix/linux tools. You don't have to `ls --thing` to list a folder, just `ls`. Or `cat --magic --args the_file` and so on. If I require an 'option', it becomes a command or an argument for the command, i.e. `tool --list-files` becomes `tool ls`. Copy for example: `cp src dest` works, `cp` on its own, doesn't. I even tend to write extensible CLI tools, `tool-ls` will drop into the same folder as `tool` and running `tool` will detect `tool-ls` and present it in the list of commands. Just like git.
- swozey 3y ago
  One of my huge frustrations is the inconsistency between various apps or even in the same app. Sometimes it's "executable -help" or "executable --help", sometimes it's executable -h, or --h. I also find it really annoying when running a bad/wrong/typoed command doesn't give you a "You wrote fkuc but did you mean ...." those are super helpful. IMO, if you use --help, you also should be using -help, and -h --h, unless you're using C and c to seperate two different commands. Which I don't like AT ALL. Don't make --help show help but --HELP show something different. Use a different word/letter. I write TUI apps ALL the time and it's not hard to do ANY of this. It's super easy in go and ruby. There are two big things I do - I add CLI flags that you can run directly - "executable --help" which does the same thing as opening the TUI app with a nice little TUI menu where anyone can use it and select their options and put a couple of inputs in to get what they want done. So, if you DON'T want the potentially slighty slower of uising the TUI vs a CLI command with a few flags you can just run the commands directly. Hell, if someone puts the wrong CLI --flag in instead of letting it just bomb with a *nix error have it echo the actual command flags. Don't make me have to dig around for commands. And don't send me to your manpage with --help. God I hate that. Manpages sometimes are absolutely awful. I want ONE command flag that you made some esoteric word for, I want a nice concise list of the flags. I do NOT want a 5 page manpage written so dry and cumbersome that it's such a pain to read that we have other cheatsheet apps.. I ONLY want the manpage if I ask for the manpage.
  - TheCleric 3y ago
democracy 3y ago
As someone who started with speccy and cp/m I hate command line - and also nothing beats good commander like FAR Manager for simple stuff
jvanderbot 3y ago
Minor point, but on a recent project I stepped around Clap, looking for something that was small, focused, and fewer silly edge cases. Argp works really well. Highly recommend.
gumby 3y ago
I hate the “sub command” model and consider it user hostile. Among other things it makes the shell’s ! commands harder to use. Instead of git add you should have git-add. Few bother to get this right.
- rocky_raccoon 3y ago
  As a layman designing an app with subcommands, can you explain this a bit further? I'm only familiar with using !! to bring up the previous command.
  - swozey 3y ago
    They're saying that they don't want sub commands (executable --action actionsoption). They prefer (executable --actions-option) which is a command flag as opposed to chaining commands off one another. Example: https://i.imgur.com/dxXwRzD.gifv https://i.imgur.com/dxXwRzD.gifv
    - gumby 3y ago
      I don’t care if you have `git add` as long as you also have git-add, which is more easily scriptable and simply easier to use. The `git add’ approach always reminds me of using a mouse and a menu (ugh): select the git option, drag down until you get to the “add” subotion and then…. Supposedly that’s more “discoverable” and maybe it is, but you don’t need discoverability for the things you use every day!
  - gumby 3y ago
    There are a lot of super useful "!" commands documented in the bash manual in the section entitled 'History Expansion' !! which you know runs the previous command in your history. It's just short for !-1 !123 runs the 123th command in your history !gi runs the most recent command in your history that begins with letters g and i !* is the args to the most recent command !$ is the last argument to the most recent command !:0 is argv[0] of the most recent command (i.e. the program name) These can be combined: !g:$ is the last argument to the most recent command that began with g They are also really handy in backquotes since you can do things like grep foo `!find | egrep .cc` because your find command was almost right Sometimes you can get away with a ^ substitution: git add foo.cc bar.cc oops ^add^reset There are a lot of such commands that let you use the basename of the argument etc. After a short while they are so automatic they are easier to type than the actual command name ("I just want to do that thing again but with this filename"). These have actually become so deeply wired that I had to think to write them down because I use them “without thinking”. So this is handy with normal commands: git-add foo.cc <do some stuff> !g:0 bar.h git-add foo.cc bar.cc <do some stuff... oh wait, I didn't mean to do this> git-reset !g:* But with subcommands, you end up matching against all the git operations; !* matches all the arguments to the `git` command including the subcommand so you can't conveniently say "yes, that last git command but I want to change the subcommand"
rocky_raccoon 3y ago
Would there be any usefulness in some sort of a "CLI standard" that defines certain behaviors and provides useful recommendations? e.g., - Apps must always have a --help/-h argument - Apps that require subcommands or arguments must display "Usage" or "Help" when no subcommand or argument is specified - When an invalid subcommand or argument is inputted, apps must display "Usage" or "Help" - Arguments that require a file/resource as a parameter SHOULD use the --file/-f flag where possible (and other standardizing best practices) Most of this stuff is already built into clap etc. If nothing else, it could remove some of the initial cognitive load.
- thomasahle 3y ago
  Always requiring "-f" for files is over the top. Think about commands like "mv", "cp" or even "less".
  - Izkata 3y ago
    Also that already means "force" for a lot of commands, including two of the ones you mentioned.
  - floren 3y ago
    Or the many cases where you want to specify an input file and an output file.
- CubsFan1060 3y ago
  https://github.com/Textualize/trogon https://github.com/Textualize/trogon > Ultimately we would like to formalize this schema and a protocol to extract or expose it from apps. This which would allow Trogon to build TUIs for any CLI app, regardless of how it was built. If you are familiar with Swagger, think Swagger for CLIs.
  - jdxcode 3y ago
    it's not complete, but I've been thinking about this problem for years and have been thinking about how to solve it. I am working on it here: https://github.com/jdx/usage https://github.com/jdx/usage It's mostly just a README right now, and I'm still iterating on it, talking to friends, but I think I'm getting close. It's definitely not yet written for the average developer to consume yet either. My hope is within the next month or two I might have a usable alpha release of it. I have a use-case for it now so I think it’s finally ready to happen. If you have any thoughts on my design lmk.
orliesaurus 3y ago
Ok there's a really good point here about when commands 'layout' shifted from: `command -function` To `command function -option` Example: Why is it: ssh -l bob myhost.com Vs ssh login bob myhost.com
- bluetomcat 3y ago
  The "subcommand" approach is the one popularised by Git. It makes sense for complex tools that incorporate many different actions. Every action is essentially its own CLI tool. That approach isn't suited well to the traditional Unix mindset where a single tool is supposed to do one thing and do it well – "ls" is meant to list files and "tr" is meant to replace characters, and you should be able to pipe them together.
  - cb321 3y ago
    Not to challenge anything you said, but rather expand upon it.. git just followed a grand tradition of software version control systems in general (sccs/cvs/svn/..): https://lobste.rs/s/dnazns/contextual_clis#c_b7rl9k https://lobste.rs/s/dnazns/contextual_clis#c_b7rl9k
seveibar 3y ago
Most projects design CLIs wrong, CLIs should be interactive by default to maximize discovery, everything from the command selection, to option selection, to specific parameter enum or even searchable resource ids. A -y flag should force it to be non-interactive. This is what I did with seam-cli and the usage of command line tools over eg postman for interacting with our API exploded- a good interactive CLI is all you need. It helps to use a well-defined schema, or for an API company an OpenAPI schema, to keep the CLI up to date and to maximize it’s capabilities.
- WhyNotHugo 3y ago
  What you are describing is a TUI, not a CLI.
- latexr 3y ago
  “Most” would be an awful experience. You wouldn’t be able to pipe anything in a terminal or write a script without polluting everything with a bunch of `-y` all over the place.
  - gavinhoward 3y ago
    I agree with you, but there is something to what GP is saying. I use a multicall binary to implement a TUI; they are the same program, but one opens interactive, and the other is a regular CLI.
- qwery 3y ago
  But you must agree it is almost certainly the case that most people design standards wrong.
error9348 3y ago
Terseness is the point. Man pages can be discoverable too if your shell supports autocomplete
Workaccount2 3y ago
Linux will be eternally doomed to <5% market share as long as it's developers harbor their masochistic fetishization of the linux terminal. You have ostensibly "user friendly" distros like Ubuntu, that still, in 2024, refuse to implement the standard ctrl+v for paste and add a modern cursor to their terminal. The OS is kept artificially difficult to use, just because it's maintainers get off on knowing it's cryptic interface language. Imagine an LLM better than GPT-4, but the devs only speak Klingon and refuse to implement English because Klingon is more efficient on paper. Then they constantly groan about low adoption and training data availability, while death gripping Klingon as the superior way of interfacing. Please, for the sake of humanity trapped in Microsoft's dungeon, please come down off your CLI high horse and make a user friendly OS.
- at_a_remove 3y ago
  Around 1999, I said to someone, "You cannot be 'l33t' and also have the Year of the Linux Desktop." And some people really love that l33t feel, right down to git. I've had people here tell me that "reflog" is just as intuitively obvious as "undo." You can't reason with those people. I'm scratching an itch right now to make a wizard-driven application, but in the CLI. Right now I am noticing little subtle bits of friction driven by Arcanery, such as things which aren't easily possible in Windows being available in Linux, but locked behind a hoop or two. Even the input prompt itself in my chosen language is slightly sad.
- yjftsjthsd-h 3y ago
  > You have ostensibly "user friendly" distros like Ubuntu, that still, in 2024, refuse to implement the standard ctrl+v for paste and add a modern cursor to their terminal. The user-friendly distros - correctly - aim to solve this by making terminal use optional, not by taking on the nigh-impossible task of completely changing how input works in the terminal. > The OS is kept artificially difficult to use, just because it's maintainers get off on knowing it's cryptic interface language. Also, that's not the reason. It's not some superiority complex or fetish, it's that the existing terminal paradigm is really good for what it's good for and there's no point in sacrificing the existing user-base in order to try and appeal to a wider audience who will never use it anyways.
JohnMakin 3y ago
As someone that spends 99.99% of their working day in the terminal with CLI's, here are the things I want - - clear documentation, eg --help - order of parameters should not matter - clear, helpful error messages (git is great at this) - consistent outputs That's all I want. It can be as complicated as you want it to be, as long as you do this stuff I don't really care. One tool that comes to mind I use a lot that does not do this well is jq. It's very unintuitive, at least to me.
protomikron 3y ago
An annoying thing is if CLI tools don't exit with non-zero if the tool is used incorrectly. It's pretty standard to print the usage string if the tool is invoked with invalid arguments. However the program should then also exit with non-zero, otherwise it can be inconvenient to use in scripting.
1vuio0pswjnm7 3y ago
Why does the title omit the program beng studied. It easily fits within the 70 character limit. Correct title is: CLI User Experience Case Study: Topiary
charlie0 3y ago
You'd think that by now, autocomplete would come standard with any shell and cli tool, but nop.
m463 3y ago
I think one of the most uplifting things for decent CLIs has been python's argparse. I enjoy using it, and it helps you create arguments that are readable, expressive, and have decent capabilities. All with great help. it makes it easy to do something well. (in comparison, the shell/c and getopt is rudimentary)
aulin 3y ago
Maybe I'm getting old and nostalgic, but in my times I really enjoyed reading Linux howtos. That's how you discovered stuff. Then man pages for the more uncommon options. Everything was preinstalled you just had to spend some time reading it. I'm not sure I like this modern idea where everything has to come to you without any effort.
- rochak 3y ago
  I think it all comes down to the instant gratification offered by modern world that has reduced people’s attention spans. Almost like if something takes longer than a few minutes for people to get started, that move on. Don’t blame them when there are so many alternatives to choose from. Doesn’t matter if you offer a better long term solution if your users don’t even stick around long enough to experience that.
deafpolygon 3y ago
This is why I believe that more CLI applications need to be built using a solid TUI alongside a CLI. This will enhance discoverability - imagine embedding a help screen inside a TUI when invoking `somecommand --help` or just simply `somecommand --tui`. We need more TUI. Before there were GUI OSes, almost every application had a TUI of some sort (think back to DOS, etc.).

179 points by Xophmeister 3y ago

I love CLIs, i try to find inspiration in the one simon willison makes. His CLIs extremely good on the DX side. Llm, sqlite-utils and datasette are all very thoughfully thought of tools/clis. So good that I have been thinking to mail him to see if he wanted to write a blog post about his way of thinking about it. Its top notch from naming the subcommands the plugin systems. I always try to think along the lines of: I've i'm going to use this CLI a 1000 times each day. How do i want to use it. And if i want to automate it, how can i script it. Also CLI commands are basically contracts, since people will program against it. Good CLIs are very interesting puzzles bringing human ux and scriptability together. Aws cli's also have an interesting approach to it.

simonw 3y ago
Thanks for saying that! I did write a post with a few of the things I've learned about CLI design here: https://simonwillison.net/2023/Sep/30/cli-tools-python/ https://simonwillison.net/2023/Sep/30/cli-tools-python/
- indymike 3y ago
  That's going into the required reading folder for new devs at my company. Thanks for writing that!
- hhthrowaway1230 3y ago
  Thank you! Weird that I missed it haha! Will do some reading and will start applying the lessons learned! And ill reach out if im missing anything!

atoav 3y ago

As someone who teaches these things occasionally to non-tech people I think the hard thing about CLI tools are the following: 1. The terminal when you first open it is intimidating to most and doesn't offer any help to figure out how to use it. If people think something is hard, they will have a harder time understanding it as well (same goes for thinking something will be boring, there have been studies on that) 2. Text editing in the terminal works different than literally anywhere else. You can't simply click and mark text, shortcuts are different, etc. 3. You have to get that text has to be exact, you have to know syntax rules with where to put spaces, how to work with quotes, escape strings and all that. That is just not easy. For those of us who already speak any given shell, this may be aomething we forget. But it is like learning a language and a way to think. Once you are fluent, it is easy. But it is worth it in my opinion, especially if you want to work with niche special tools or if you want reliable tools that will just work for decades.

9dev 3y ago
So do you think a terminal that works more along the way of thinking of non-technical people, or maybe similar to other text-based applications, could provide an entry point to non-technical power users? I have been thinking a lot about providing a shell-like experience as a quick way to make advanced functionality available in an app, without having to build fully fledged GUIs for them, but I’m not sure whether that would work. Clearly, discoverability and text input are the key issues, but I don’t know if alleviating those is sufficient to make the interface actually interesting and useful.
- deleted 3y ago
  [deleted]
- jonfw 3y ago
  VSCode's command palette is a great example of this- 1. fuzzy search through different options 2. Show lots of suggestions as soon as you focus in the text box 3. have a ? or other "learn more" option available I still think it leans very technical though, users would greatly prefer buttons. There's a good reason that powerpoint doesn't have one of these
- swozey 3y ago
  When I make terminal apps I make both a TUI and CLI option if the app is big enough to benefit from it. Here's an example: https://i.imgur.com/dxXwRzD.gifv https://i.imgur.com/dxXwRzD.gifv This allows the less familiar or technical staff to do things with the app and also allows for veterans or CLI afficiandos to alias/run what they want directly from the cli.
- atoav 3y ago
  I think using text to interface with computers is a genius idea and if it didn't exist someone would have ro invent it. But the way text interfaces on computers look nowadays are mostly shaped the way they are for historical reasons. It doesn't need much. First the text should be editable like other text on the OS, the cursor needs to be reactive ro mouse input. Second expected shortcuts should work, that means things like Ctrl+A to select all, Home to go to start of line, Ctrl+C for copy, Escape to cancel things, etc. I know there are reasons to everything and I am used to terminal shortcuts as well, but there is literally no reasons why we can't ensure they are the same there as everywhere else. Next thing would be the startup experience. If you start a terminal the first time, it should offer you some introduction. Sure, a seasoned user like me would be annoyed by that, but if you make it so it can be ignored by the likes of us or people that set the right environment variable, cool. Lastly, maybe it also a bit about the colors and fonts. I like bright on dark, but I can see how people who see this for the first time get flashbackanof every hacker scene they ever saw in any movie. And the subtext there always was: "You only understand this if you sacrifice all your social life". Imagine how a terminal would look like if it was made for kids and how that would make people judge their own ability to get this instead. I think a lot of the reason why terminals still look the way the do (apart from the fact it just works), is gatekeeping. Some nerds like that this is arcane, secret knowledge that looks as if it is hard to aquire. They don't like others to understand unless those others are also nerds.

sasham 3y ago

As all computer interfaces evolved in the past decades (from text to graphical interfaces, to touch screens and voice commands), the users' expectations have changed and the CLIs need to evolve as well. Today's users don't have time or willingness to learn something before they can use it. The number of tools in daily has grown as well, so they really don't have the mental capacity for that. We will always need CLIs for things that are to cumbersome or rare to add into GUIs; but they have to become easier to use, and provide immediate value. That's why we built an interactive CLI by default at Diversion. It's not a revolutionary tool (there are other similar CLIs), but it has shown to help our users get started with Diversion much faster - the feedbacks are overwhelmingly positive.

BossingAround 3y ago
From my experience, interactive CLIs are the worst of both worlds. They are not as pretty and intuitive as GUIs, since the user has to learn terminal idiosyncrasies (e.g. unable to ctrl+c, or edit text in the middle of the sentence by mouse). And, at the same time, they tend to be pretty bad for automating things (in the worst case, even unsuitable for automation) since now, you have to map the interactive commands to the non-interactive ones.
- diversion 3y ago
  You're right in that an interactive CLI's interface is not trivial to nail. We're spending a lot of dev time on that actually. And of course there always also has to be a non-interactive version for automations.
- Borg3 3y ago
  It depends on tool. If this is some generic utiliy that interacts streams, it most probably should not be interactive. But for example if this tool is some kind of control shell for subprocess (like Quagga vtysh or FW control CLI) it would be much easier to use in interactive fashion (autocompletion, interactive help and hints system).
qwery 3y ago
I think your linear evolution theory might be a bit too simplistic. There must be a branch somewhere (says the CS nerd). Where does AR & VR go? Before or after touch screens?

pr337h4m 3y ago

Discord has pretty much figured out how to give CLIs an actual UX with their bots and slash commands. Midjourney is the largest of the Discord apps that have achieved mainstream usage, despite being CLI-only.

diggan 3y ago
Huh? The UX is pretty much the same as in the terminal; "Here is a command, a small snippet of help text and a bunch of options, figure it out", not sure what Discord improved upon here. Autocomplete?
anthk 3y ago
Slash commands predate Discord by large.
- deleted 3y ago
  [deleted]
latexr 3y ago
Bots and slash commands have been a staple of chat for decades before Discord. https://en.wikipedia.org/wiki/List_of_Internet_Relay_Chat_commands https://en.wikipedia.org/wiki/List_of_Internet_Relay_Chat_co... They’re no different from other CLIs, UX-wise. But because they are intermingled with chat, you can ask for help from a human right there.
- deleted 3y ago
  [deleted]
esafak 3y ago
This is funny on multiple levels. For one, it is IRC that introduced these commands decades ago, as others have observed. The second is that the Discord "UX", especially for Midwinter, is atrocious. You couldn't pay me to use it.
- cedws 3y ago

williamcotton 3y ago

?? I need to recursively tar a directory https://githubnext.com/projects/copilot-cli/ https://githubnext.com/projects/copilot-cli/

s1291 3y ago
That webpage does not explain how to get it. Instead, I recommend using gorilla-cli [0]. [0] https://github.com/gorilla-llm/gorilla-cli https://github.com/gorilla-llm/gorilla-cli

novagameco 3y ago

Powershell cmdlets make the CLI really nice to use; you declare the variables in your program parameters and then hitting tab will auto-suggest/auto-complete them for you, and you can generate help docs for each cmdlet as well

deleted 3y ago

[deleted]

jasode 3y ago

>Discoverability: Reminding ourselves how to perform what we know (or assume) can be done isn’t the same as guiding us towards the full gamut of what’s possible. I started with text mode CLIs on old 40-column computers like IBM PC DOS and Commodore 64 so I fully understand the techie's bias towards TUI command lines over GUIs. Lightweight, embed commands in scripts, command history, etc. However, the tension between CLI power vs GUI ease-of-use really hit me when I'm the user of personal utilities I wrote. Coding a console utility that uses command line arguments is always faster and easier than a GUI app. So, being lazy, 99% of my utilities are CLI. But I also annoy myself as a user when I can't remember what the syntax options are for the CLI that I coded so I end up having to open the source code and re-examine the argc and argv sections to see what the spelling or ordering is. If this happens often enough, I give in and expend the extra effort rewrite the utility as a GUI app with radio buttons, checkboxes, etc. That said, I still like CLI tools. E.g. I wish banks and credit cards had a pseudo SSH terminal that I could run text commands to list transactions. I really don't want to click around the bank's website or use a smartphone app.

alright2565 3y ago
> But I also annoy myself as a user when I can't remember what the syntax options are for the CLI that I coded so I end up having to open the source code and re-examine the argc and argv sections to see what the spelling or ordering is. I try to avoid this in two ways: 1. I use the history in my terminal to search for previous invocations of the command, which tends to give me a good set of examples of how it should be used. 2. For anything but the quickest and dirtiest CLI tools, I like to use a declarative parameter parser like docopt or argparse. This forces me to spend a couple extra minutes writing some docs and makes the --help useful.
JeffSnazz 3y ago
> E.g. I wish banks and credit cards had a pseudo SSH terminal that I could run text commands to list transactions. Really, it'd be nice if they offered any upgrade from the 80s beyond a smartphone app. How does the rest of the world have better peer-to-peer payments than we do? How can I still not fully deny all transactions to a bank account? Why can't this banking app ask my permission before letting charges go through? Why is over-drafting a debit card possible at all? Why can I not ensure that a PIN is necessary to use my debit card in all situations and not just at a physical point-of-sale or ATM? Why do they all use SMS for 2FA—which has already bitten my twice? I hate that Venmo and cashapp basically leech off the incompetence of our banking industry. Banking is a joke of an industry in dire need of regulation.

neatze 3y ago

seems like wrong case study, cli power (at least for me) is in comments and record keeping what has been done months if not years ago, and an "easy way" to script repetitive tasks, I just don't see how same thing can be achieved with GUI: record video and then comment it ? have detailed logs what button, and what fields where edits/pressed ? etc ...

DrBazza 3y ago

The consistency rule I follow in any CLI tools I write: options are optional, required are commands or arguments. Anything with `-` or `--` is an optional. Just like all the basic unix/linux tools. You don't have to `ls --thing` to list a folder, just `ls`. Or `cat --magic --args the_file` and so on. If I require an 'option', it becomes a command or an argument for the command, i.e. `tool --list-files` becomes `tool ls`. Copy for example: `cp src dest` works, `cp` on its own, doesn't. I even tend to write extensible CLI tools, `tool-ls` will drop into the same folder as `tool` and running `tool` will detect `tool-ls` and present it in the list of commands. Just like git.

swozey 3y ago
One of my huge frustrations is the inconsistency between various apps or even in the same app. Sometimes it's "executable -help" or "executable --help", sometimes it's executable -h, or --h. I also find it really annoying when running a bad/wrong/typoed command doesn't give you a "You wrote fkuc but did you mean ...." those are super helpful. IMO, if you use --help, you also should be using -help, and -h --h, unless you're using C and c to seperate two different commands. Which I don't like AT ALL. Don't make --help show help but --HELP show something different. Use a different word/letter. I write TUI apps ALL the time and it's not hard to do ANY of this. It's super easy in go and ruby. There are two big things I do - I add CLI flags that you can run directly - "executable --help" which does the same thing as opening the TUI app with a nice little TUI menu where anyone can use it and select their options and put a couple of inputs in to get what they want done. So, if you DON'T want the potentially slighty slower of uising the TUI vs a CLI command with a few flags you can just run the commands directly. Hell, if someone puts the wrong CLI --flag in instead of letting it just bomb with a *nix error have it echo the actual command flags. Don't make me have to dig around for commands. And don't send me to your manpage with --help. God I hate that. Manpages sometimes are absolutely awful. I want ONE command flag that you made some esoteric word for, I want a nice concise list of the flags. I do NOT want a 5 page manpage written so dry and cumbersome that it's such a pain to read that we have other cheatsheet apps.. I ONLY want the manpage if I ask for the manpage.
- TheCleric 3y ago

democracy 3y ago

As someone who started with speccy and cp/m I hate command line - and also nothing beats good commander like FAR Manager for simple stuff

jvanderbot 3y ago

Minor point, but on a recent project I stepped around Clap, looking for something that was small, focused, and fewer silly edge cases. Argp works really well. Highly recommend.

gumby 3y ago

I hate the “sub command” model and consider it user hostile. Among other things it makes the shell’s ! commands harder to use. Instead of git add you should have git-add. Few bother to get this right.

rocky_raccoon 3y ago
As a layman designing an app with subcommands, can you explain this a bit further? I'm only familiar with using !! to bring up the previous command.
- swozey 3y ago
  They're saying that they don't want sub commands (executable --action actionsoption). They prefer (executable --actions-option) which is a command flag as opposed to chaining commands off one another. Example: https://i.imgur.com/dxXwRzD.gifv https://i.imgur.com/dxXwRzD.gifv
  - gumby 3y ago
    I don’t care if you have `git add` as long as you also have git-add, which is more easily scriptable and simply easier to use. The `git add’ approach always reminds me of using a mouse and a menu (ugh): select the git option, drag down until you get to the “add” subotion and then…. Supposedly that’s more “discoverable” and maybe it is, but you don’t need discoverability for the things you use every day!
- gumby 3y ago
  There are a lot of super useful "!" commands documented in the bash manual in the section entitled 'History Expansion' !! which you know runs the previous command in your history. It's just short for !-1 !123 runs the 123th command in your history !gi runs the most recent command in your history that begins with letters g and i !* is the args to the most recent command !$ is the last argument to the most recent command !:0 is argv[0] of the most recent command (i.e. the program name) These can be combined: !g:$ is the last argument to the most recent command that began with g They are also really handy in backquotes since you can do things like grep foo `!find | egrep .cc` because your find command was almost right Sometimes you can get away with a ^ substitution: git add foo.cc bar.cc oops ^add^reset There are a lot of such commands that let you use the basename of the argument etc. After a short while they are so automatic they are easier to type than the actual command name ("I just want to do that thing again but with this filename"). These have actually become so deeply wired that I had to think to write them down because I use them “without thinking”. So this is handy with normal commands: git-add foo.cc <do some stuff> !g:0 bar.h git-add foo.cc bar.cc <do some stuff... oh wait, I didn't mean to do this> git-reset !g:* But with subcommands, you end up matching against all the git operations; !* matches all the arguments to the `git` command including the subcommand so you can't conveniently say "yes, that last git command but I want to change the subcommand"

rocky_raccoon 3y ago

Would there be any usefulness in some sort of a "CLI standard" that defines certain behaviors and provides useful recommendations? e.g., - Apps must always have a --help/-h argument - Apps that require subcommands or arguments must display "Usage" or "Help" when no subcommand or argument is specified - When an invalid subcommand or argument is inputted, apps must display "Usage" or "Help" - Arguments that require a file/resource as a parameter SHOULD use the --file/-f flag where possible (and other standardizing best practices) Most of this stuff is already built into clap etc. If nothing else, it could remove some of the initial cognitive load.

thomasahle 3y ago
Always requiring "-f" for files is over the top. Think about commands like "mv", "cp" or even "less".
- Izkata 3y ago
  Also that already means "force" for a lot of commands, including two of the ones you mentioned.
- floren 3y ago
  Or the many cases where you want to specify an input file and an output file.
CubsFan1060 3y ago
https://github.com/Textualize/trogon https://github.com/Textualize/trogon > Ultimately we would like to formalize this schema and a protocol to extract or expose it from apps. This which would allow Trogon to build TUIs for any CLI app, regardless of how it was built. If you are familiar with Swagger, think Swagger for CLIs.
- jdxcode 3y ago
  it's not complete, but I've been thinking about this problem for years and have been thinking about how to solve it. I am working on it here: https://github.com/jdx/usage https://github.com/jdx/usage It's mostly just a README right now, and I'm still iterating on it, talking to friends, but I think I'm getting close. It's definitely not yet written for the average developer to consume yet either. My hope is within the next month or two I might have a usable alpha release of it. I have a use-case for it now so I think it’s finally ready to happen. If you have any thoughts on my design lmk.

orliesaurus 3y ago

Ok there's a really good point here about when commands 'layout' shifted from: `command -function` To `command function -option` Example: Why is it: ssh -l bob myhost.com Vs ssh login bob myhost.com

bluetomcat 3y ago
The "subcommand" approach is the one popularised by Git. It makes sense for complex tools that incorporate many different actions. Every action is essentially its own CLI tool. That approach isn't suited well to the traditional Unix mindset where a single tool is supposed to do one thing and do it well – "ls" is meant to list files and "tr" is meant to replace characters, and you should be able to pipe them together.
- cb321 3y ago
  Not to challenge anything you said, but rather expand upon it.. git just followed a grand tradition of software version control systems in general (sccs/cvs/svn/..): https://lobste.rs/s/dnazns/contextual_clis#c_b7rl9k https://lobste.rs/s/dnazns/contextual_clis#c_b7rl9k

seveibar 3y ago

Most projects design CLIs wrong, CLIs should be interactive by default to maximize discovery, everything from the command selection, to option selection, to specific parameter enum or even searchable resource ids. A -y flag should force it to be non-interactive. This is what I did with seam-cli and the usage of command line tools over eg postman for interacting with our API exploded- a good interactive CLI is all you need. It helps to use a well-defined schema, or for an API company an OpenAPI schema, to keep the CLI up to date and to maximize it’s capabilities.

WhyNotHugo 3y ago
What you are describing is a TUI, not a CLI.
latexr 3y ago
“Most” would be an awful experience. You wouldn’t be able to pipe anything in a terminal or write a script without polluting everything with a bunch of `-y` all over the place.
- gavinhoward 3y ago
  I agree with you, but there is something to what GP is saying. I use a multicall binary to implement a TUI; they are the same program, but one opens interactive, and the other is a regular CLI.
qwery 3y ago
But you must agree it is almost certainly the case that most people design standards wrong.

error9348 3y ago

Terseness is the point. Man pages can be discoverable too if your shell supports autocomplete

Workaccount2 3y ago

Linux will be eternally doomed to <5% market share as long as it's developers harbor their masochistic fetishization of the linux terminal. You have ostensibly "user friendly" distros like Ubuntu, that still, in 2024, refuse to implement the standard ctrl+v for paste and add a modern cursor to their terminal. The OS is kept artificially difficult to use, just because it's maintainers get off on knowing it's cryptic interface language. Imagine an LLM better than GPT-4, but the devs only speak Klingon and refuse to implement English because Klingon is more efficient on paper. Then they constantly groan about low adoption and training data availability, while death gripping Klingon as the superior way of interfacing. Please, for the sake of humanity trapped in Microsoft's dungeon, please come down off your CLI high horse and make a user friendly OS.

at_a_remove 3y ago
Around 1999, I said to someone, "You cannot be 'l33t' and also have the Year of the Linux Desktop." And some people really love that l33t feel, right down to git. I've had people here tell me that "reflog" is just as intuitively obvious as "undo." You can't reason with those people. I'm scratching an itch right now to make a wizard-driven application, but in the CLI. Right now I am noticing little subtle bits of friction driven by Arcanery, such as things which aren't easily possible in Windows being available in Linux, but locked behind a hoop or two. Even the input prompt itself in my chosen language is slightly sad.
yjftsjthsd-h 3y ago
> You have ostensibly "user friendly" distros like Ubuntu, that still, in 2024, refuse to implement the standard ctrl+v for paste and add a modern cursor to their terminal. The user-friendly distros - correctly - aim to solve this by making terminal use optional, not by taking on the nigh-impossible task of completely changing how input works in the terminal. > The OS is kept artificially difficult to use, just because it's maintainers get off on knowing it's cryptic interface language. Also, that's not the reason. It's not some superiority complex or fetish, it's that the existing terminal paradigm is really good for what it's good for and there's no point in sacrificing the existing user-base in order to try and appeal to a wider audience who will never use it anyways.

JohnMakin 3y ago

As someone that spends 99.99% of their working day in the terminal with CLI's, here are the things I want - - clear documentation, eg --help - order of parameters should not matter - clear, helpful error messages (git is great at this) - consistent outputs That's all I want. It can be as complicated as you want it to be, as long as you do this stuff I don't really care. One tool that comes to mind I use a lot that does not do this well is jq. It's very unintuitive, at least to me.

protomikron 3y ago

An annoying thing is if CLI tools don't exit with non-zero if the tool is used incorrectly. It's pretty standard to print the usage string if the tool is invoked with invalid arguments. However the program should then also exit with non-zero, otherwise it can be inconvenient to use in scripting.

1vuio0pswjnm7 3y ago

Why does the title omit the program beng studied. It easily fits within the 70 character limit. Correct title is: CLI User Experience Case Study: Topiary

charlie0 3y ago

You'd think that by now, autocomplete would come standard with any shell and cli tool, but nop.

m463 3y ago

I think one of the most uplifting things for decent CLIs has been python's argparse. I enjoy using it, and it helps you create arguments that are readable, expressive, and have decent capabilities. All with great help. it makes it easy to do something well. (in comparison, the shell/c and getopt is rudimentary)

aulin 3y ago

Maybe I'm getting old and nostalgic, but in my times I really enjoyed reading Linux howtos. That's how you discovered stuff. Then man pages for the more uncommon options. Everything was preinstalled you just had to spend some time reading it. I'm not sure I like this modern idea where everything has to come to you without any effort.

rochak 3y ago
I think it all comes down to the instant gratification offered by modern world that has reduced people’s attention spans. Almost like if something takes longer than a few minutes for people to get started, that move on. Don’t blame them when there are so many alternatives to choose from. Doesn’t matter if you offer a better long term solution if your users don’t even stick around long enough to experience that.

deafpolygon 3y ago

This is why I believe that more CLI applications need to be built using a solid TUI alongside a CLI. This will enhance discoverability - imagine embedding a help screen inside a TUI when invoking `somecommand --help` or just simply `somecommand --tui`. We need more TUI. Before there were GUI OSes, almost every application had a TUI of some sort (think back to DOS, etc.).