CLI user experience case study
tweag.io
tweag.io
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.
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.
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
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.
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.
(if you can make an unfriendly but more consistent terminal, that'd also be a worthwhile improvement, just not for your target audience)
If you're willing to lead the horse to water, we'd be able to see if it drinks.
Rather than just structural colouring (params are colour a, valid paths colour b etc) the input is recoloured as you type in response to validity for the specific tool you're about to invoke.
* There is no enforced standard for commands other than using a file name to invoke them.
* Different languages and frameworks have different and multiple ways of parsing command lines. For example Gooey (a python gui tool) works with scripts written with the argparse library but dodes not work with optparse.
* The terminal is not the shell. That means that to present a gui, you'll have to launch something that runs outside of the terminal to present the gui.
* It's common for developers to write command line tools with out understanding the shell and os's input and output system beyond reading and writing files. I routinely have to teach jr developers about stdio, stderr, pipes etc...
That said, there's great potential to take advantage of shell autocomplete files to make better guis for commands: https://blog.deepjyoti30.dev/tab-autocomplet-cli-apps . Someone probably already has done this...
Hmm. Writing a wrapper that uses autocomplete definitions might be more useful... There's also the approach of Zenity that gives you the ability to create GUIs from shell scripts. When you do have a gui from parser tool, it can be quite nice (like Python's gooey).
They will only use composition if there isn’t a tool that solves the problem by itself.
Which is actually also a problem with GUIs. Many times, with a few CLI commands you can do a ton of stuff that you just cannot represent in UI without having tons of buttons...
There are a specific set of skills required to learn how to use the terminal - a combination of knowing when and how to read man pages, when to look up Stack Overflow, when to look up YouTube videos, and where to hang out to learn about more esoteric commands exist like `parallel`.
Without those skills - and there is no recommended path on how to get them - the terminal is unusable. It isn't a case of people thinking it is hard, it is actually logically impossible to learn how to learn terminal commands without getting lucky at the start.
Software has two phases - a learning phase and a using phase. A lot of great software ideas died quietly because there wasn't a sanctioned route to scale the learning curve.
[0] Or this classic: https://cs.wellesley.edu/~cs249/Resources/ed_is_the_standard...
Just like no one really uses ed anymore, the C shell is pretty much dead and many userspace programs have had their edges rounded over the years, but the experience of trying to imagine working around their foibles gives the perspective necessary to helpfully advise someone trying to learn an acceptable shell today (except that they'll have more use for their effort at some point) because they're pretty much the same kind of transition. Compare these highlights to that ed page:
>Pipes are not the be-all and end-all of program communication. Our favor-ite Unix-loving book had this to say about the Macintosh, which doesn’t have pipes: "The Macintosh model, on the other hand, is the exact opposite. The system doesn’t deal with character streams. Data files are extremely high level, usually assuming that they are specific to an application. When was the last time you piped the output of one program to another on a Mac? (Good luck even finding the pipe symbol.) Pro-grams are monolithic, the better to completely understand what you are doing. You don’t take MacFoo and MacBar and hook them together." Yeah, those poor Mac users. They’ve got it so rough. Because they can’t pipe streams of bytes around how are they ever going to paste artwork from their drawing program into their latest memo and have text flow around it? How are they going to transfer a spreadsheet into their memo? And how could such users expect changes to be tracked automatically? They cer-tainly shouldn’t expect to be able to electronically mail this patched-together memo across the country and have it seamlessly read and edited at the other end, and then returned to them unscathed. We can’t imagine how they’ve been transparently using all these programs together for the last 10 years and having them all work, all without pipes.
>This morning I read an article in the Journal of Human-Computer Interaction, “Expertise in a Computer Operating System,” by Stephanie M. Doane and two others. Guess which operating system she studied? Doane studied the knowledge and performance of Unix novices, intermediates, and expert users. Here are few quotes: “Only experts could successfully produce composite commands that required use of the distinctive features of Unix (e.g. pipes and other redirection symbols).” In other words, every feature that is new in Unix (as opposed to being copied, albeit in a defective or degenerate form from another operat-ing system) is so arcane that it can be used only after years of arcane study and practice. “This finding is somewhat surprising, inasmuch as these are fundamental design features of Unix, and these features are taught in elementary classes.”
In both cases, we have someone moving from a relatively monolithic, high-level, restricted, commercialized system that focuses on uniformity, error-bar tolerance, and DWIM/intuitiveness of the intended or common use-case over giving every capability equal billing to one that focuses on completeness, atomicity, and implementation simplicity/efficiency. Learning this transition has two phases because the best way to keep going with the learner's current knowledge has two phases: Before making the transition they probably learned the old system through self-tutoring and exploration; the stakes were low enough and the environment painstakingly organized to be similar enough that a little curiosity and a little induction from past experience explained basically every level of the user-visible stack, and the slab of composed foundation functions that made the first-blush system run were either walled off fully or guarded to wave away novices. Pre grokking the new software, though, the user lacks the idioms that make it possible to write a more complete computing system out of less code, and so don't know when to apply what even if they've read up on most of the pieces they need already. It's like a transition from an upper-class aerospace engineer or hedge fund manager exploring Animal Kingdom Park to making a trek through the indian jungle. Even if you're carrying a reference tome on the region there are intangibles you're just missing, so you're far more likely to get lost and confused or hurt yourself if you don't walk right in the footsteps of someone expeeienced for a good long while. It's similar with the terminal: When you're successful, things are clearer and simpler than a jumbled heavyweight gui, but when you make the "mistakes" that come along with not almost entirely knowing what you're doing it can be unhelpful, mystifying, and rarely dangerous, because the experienced users happen to be the most-engaged target market. Not everyone has Apple money, after all.
The phase change back to effective exploration, and actual use over learning through apeing, only comes after they've got both most of the terrain and most of the problem-solving strategies in their head all at once to hit a self-sustaining critical mass. Something akin to the Khan(academy) flipped method is what I think is most important to remember when teaching: most experienced users think in terms of learning new skills through integrating new components, while beginners tend to know less about the implications of recombining the utilities they're already aware of in the less common and simple ways than show up as line snippets in crash courses. New users can read a man page as well as you can recite it by heart, but what they really need tutoring in is how to know they're reading the right part of the right page and what your experience says to do with it.
Just getting that all off my chest as someone who didn't have anyone to teach me and used to be spectacularly bad at teaching others, so someone might learn from my mistakes.
I think that's because casual users did not learn how to look at a terminal. If you start `vim`, it shows you a few lines that say "type :help for help". The help starts with "how to move around" and "how to quit". But people ignore that.
One could say "people don't ignore it, it's just not intuitive". But I have seen many casual users struggle with GUIs, too. The difference, IMO, is just that they learned the basics of GUIs, and never had to learn the basics of CLI. I don't really believe in something fundamentally harder with CLIs.
A lot of great software is dismissed because people pretend there should be no such thing as a learning phase.
2. You can add cursor and mouse control to your .nanorc. I'm not sure if bash, etc have that. With that said, I have cursor enabled in my .nanorc along with a bunch of other stuff. The cursor thing.. I'm kind of confused on how you use it, but I rarely use it. It's (to me) weird. I think I just havent used it enough to really know its capabilites.
I think as a teacher it'd be super helpful to you to have a base set of dotfiles that your students just git clone when they start the class. Or even better, have them write their own and just provide them the settings you want them to enable. When I bring new SREs on board, without the base dotfiles for them to grab on day 1 it takes practically a week for someone to get setup and ready to work.
Have each of them commit their dotfiles to their own repos, probably forked from yours. That will get them familiar with github. Then try to get them to actually build out a github portfolio. I spent 6 months interviewing for a few positions last year and I was really surprised how few people had githubs with anything on them. It's not my main criteria but it's nice when someone has put effort into their gh/gitlab/etc profile and projects.
Also please teach them about filesystems. Most of the younger people (20s) I interviewed knew very little linux/containerization/filesystems.. I think the filesystem thing is from them growing up with MacOS and iPhones. They don't need to dig into anything beyond their "folders" if even that.
3. Absolutely one of my CLI annoyances here. I wrote another comment explaining why it frustrates me.
Related to your last sentence- I'd say 99% of the CLI/TUI apps I write are things that give you an easy front end (TUI and simple commands/flags) to perform backend systems tasks. So I have a ton of them as an SRE. The main reason I like to put things in a TUI and not just CLI flags is that ANYONE can hop in and use it because the options are all displayed to you front and center. You just use arrows or numbers to navigate.
I do TUI *AND* command line flags because some people want to do it quick and fast, or make aliases, etc for what they're doing. THen there's the TUI which opens if you don't run a flag, the TUI is so, so helpful to people new to the apps.
This lets me democratize the various apps I've created and let anyone who isn't me use them. It's great.
Here's one example of my TUI+CLI apps. This is super old it's much prettier now.
YES, this is the way to go! I've written a couple of internal tools that work this way and it's the best of both worlds IMO.
More importantly, in a class of a couple hundred, somebody will find a way to get off the happy path. No matter how well you design it. Hopefully they’ll come to a teaching assistant or something, but there’s a good chance they’ll go to YouTube or something instead. In that case, it is best if their installation is as standard as possible.
Also the filesystem problem is such a thing and you have dredged up some feelings, hahaha. In particular, I think operating systems and VSCode have gotten way too good at hiding the fact that the file somebody is editing is, in fact, still in a zip archive. Until they go to save it or run it.
It is very difficult, at least initially, to even begin to discover what’s possible in a terminal environment.
There are so many important things that a new user simply needs to be taught, or they will likely never discover basic functionality - such as how to even open, read, and navigate the manual.
The UX barrier to entry is very high without hand-holding or extensive online searching and a strong willingness to persevere in the face of adversity.
GUI applications (generally) solve the initial discoverability barrier by simply showing you what’s possible.
I remember being a kid looking at DOS and wondering “what do I even do?” It was essentially a blank screen with very little indication of how to proceed. My dad had sticky notes on the monitor with the commands to enter to run games.
I never really looked at a command line again after I started using the Windows desktop until I started really learning programming after college, and it was just as daunting at first.
In the ancient times, we'd say "RTFM" to people who attempted to "discover" functionality instead of Ring the Fing M.
(to what extent have we made progress in software by standing on each others' shoulders instead of each others' toes, and to what extent have we been fortunate that the EEs have been standing on each others' shoulders this short century?)
Note that I'm not anti-discoverability in general — it's just the ticket for GUIs. I just happen to believe that attempting to make CLIs discoverable would nerf their greatest power: that single-character changes can have drastic effects on behaviour. We have high display bandwidths, even in our pockets, so why not have GUIs for infrequently used software and CLIs for power used software?
1. People have to learn the basics of the GUI. Take someone who lived 50 years without seeing a computer and show them Windows. They will have to learn that they can move the mouse, left/right click, and even move while clicking. They will have to learn that some parts of the UI are interactive (e.g. buttons) and others aren't. It is not as intuitive as people tend to imply. My father still double-clicks on elements that - to me - obviously don't require a double click (like a hyperlink). And many people are completely lost if you move them from their Windows to macOS or some Linux UI. Or even between two flavours of Android.
2. Once you know the basic of GUI ("there is a start menu", "I can click on buttons", ...), the UI does not show you that there exists apps like Photoshop to edit pictures, or like Slack to talk to people. You have to somehow learn about the app from somewhere, install it, and only then you get their UI that "shows you what's possible".
I would argue that the CLI is actually quite similar. Once you have learned the basics ("I can change directory", "I can `man cmd`"), then you have to discover apps somehow (e.g. a friend saying "install git with `apt install git`"), and then you can just open the manual with `man git`, and it will most definitely show you what's possible.
The difference, I think, is that people generally don't really want to learn the CLI (it "looks old", I guess?), and many apps don't provide proper manpages (pretty sure most developers don't know how to even create manpages, or package their app for their distro).
With a CLI you have absolutely nothing. There is nothing to see at all, nothing to even begin to interact with to discover the capabilities.
I kindly disagree :-): I would say that with the CLI you have the exact equivalent: man pages.
Just like for a GUI you have to know that by hovering the cursor about an icon you will get some text description, with a CLI you have to know that there are man pages. And just like a bad GUI may have cryptic icons without any description text, a bad CLI will have no manpage. But we should compare a good GUI to a good CLI, to be fair.
[0] admittedly a holdover from the typewriter, but even presented only a keyboard and a screen I've had a kid realize that one special key makes the words go vertically instead of horizontally.
In most GUI applications I can at least find the word “help” of I look around.
Unless the GUI uses some material style nonsense. Then you have to guess where buttons are. Menus are so uncool. Every modern emacs distro starts with disabling them. Mobile apps have replaced the menubar with the hamburger button by necessity. Modern desktop GUIs have copied that despite it clearly being worse on a desktop than a menubar.
The DOS we had came with a few-hundred page manual. The same for any major programs that ran on it. These must have been exhaustive, as I don't remember being stuck at any point, honestly.
The answer is: It doesn't tell you anything. So either you grew up in a time where computers with terminals were new and interesting enough for you to try, or you were a teenager that was bored enough to try, or you had somebody show/tell you.
But what it does not do is explain itself.
Once you learn "man" and "man -k" the cli environment is emminently explorable, and it's not just "try poking at it and see what it does" it's all laid out in written documents that you can read in advance.
I dunno if it is all as high as it appears. I learned to navigate and use Unix type systems in the mid 90s, with only terminal access.
Internet was practically non existent and gopher was still (barely) in active use.
So, yeah, for a start, I don't know if extensive online resources are necessary. For example, I learned most of bash from the bash manages.
If I was to actually use this in a real system, I'd definitely build a restricted shell to execute in, and probably run it inside a Docker container with just the essential files mapped in, because I don't trust an LLM not to describe what it's doing as "updating timestamps" or whatever but actually the command is "rm -rf ~"
uxterm -xrm '*VT100.translations: #override !<Btn1Down>: vi-button() readline-button()'One of the interesting things Plan 9 did differently is that its terminal is rather more like a standard graphical text editor that happens to have the ability to execute a line. As someone used to unix terminals this was super jarring, but I can see where it would be nice.
The obvious solution here is that people who don't like precision can pay people who do to wrangle CLIs on their behalf.
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.
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/
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.
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.
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.
The reason is that my memory sucks, and has always sucked. If I'm not typing a command every day, I'll forget it very quickly. If I am typing a command every day it's probably an alias or a script I've written to save myself some time so the "real" command is already forgotten. So in reality if it's not cd, ls, less, sudo or grep the chances are that I've forgotten it.
Where the CLI really shines is automation. Software I can control with a CLI in a script is amazing. So what I really want is for everything to have both a GUI and a CLI. I realise I'm asking a lot.
It's great to be able to find the weird JQ filters or kubectl patch commands I ran last year when I need them
- spaced repetition for stuff that you use sporadically. I use Anki, it's great. For how to use it, this article is great: https://borretti.me/article/effective-spaced-repetition. I've found a positive feedback loop where the more I know how to do things without looking anything up, the more I use the CLI, the easier I remember things, the more things I discover, etc. I read once that when learning a new language, you should aim for content where you know 80%/90% already. It seems to be true for learning the CLI, and especially for integrating that learning into my day to day job.
- sd (https://github.com/ianthehenry/sd) for lowering the cost of creating a "documented alias". Before that I made aliases with either alias, or bash functions, all starting with "," to quickly see all which are "mine" (I read that trick in an article that I can't find), now the more complex stuff is in sd with some documentation.
All the scripts are in the same folder, so I can look through them if I forget which one. Same goes for aliases by using:
alias | grep <original command>Why are you not implementing -h & --help?
I use CLI a lot.. Im lazy too. But pretty much 90% of my tools implement --help because some tools are used not that often.
If I ever try to use tool that does not have nice and clean --help output I curse :)
I even have a sort of template for shell scripts, if any arg will be on the commandline, it gets implemented.
For python (using argparse obviously), in my current project i built a toml file that handles the args. It allowed me to do more, like generating code blocks for js for the web frontend, documentation for both the cli and remote api, etc. Actually, now that I think about it, i might chunk that out to its own library.
Python's argparse is pretty good in this respect. Even if you don't supply help text and good metavar names, it'll at least give you --help output showing which options are supported, and adding help text and helpful metavar names is not much additional effort.
argparse has inspired a number of knockoffs in other languages, and the ones I've used are pretty good at --help output too. (Or you can write your own! If you've done this not only long enough to not only forget the syntax of command line tools you've written, but also often enough to have recognised this as a repeated trend, the effort involved could be worth it.)
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.
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.
I tend to go by the paradigm of single dash for single character options, and double dash for full words (and common things like —-help should have aliases like -h).
I've always wondered why the style of command flags wasn't "more" standardized after 32 years of Linux being around (not that thats the first time flags were introduced, just an easy stop so I don't have to dig into that since it's not super relevant).
So, maybe it is somewhat/completely standardized and I'm just not aware of where that information is?
I think your style would still frustrate me. I'd first type "executable -help" thinking that was probably the - and -- option, and get a command not found error. I wouldn't think that think we're using - and -- differently.
> An option and its argument may or may not appear as separate tokens. (In other words, the whitespace separating them is optional.) Thus, -o foo and -ofoo are equivalent.
Thanks this is super helpful I never knew this was a GNU thing.
More specifically, getopt(3) in POSIX lets programmers very this by giving a format string. "o:f" would make your example parse as "-o" "foo" while "of:" would make it parse as "-o" "-f" "oo" and an "of" format would make it parse as you describe, "-o" "-f" "-o" "-o".
( darnir mentioned parts of this above: https://news.ycombinator.com/item?id=38968612 using the term "single character flags" to indicate no argument. )
Also, while --long-option is GNU, gcc which is perhaps the aboriginal GNU command-line utility uses single dash as in, e.g. `gcc -pipe`, though it also accepts `gcc --help`. CL syntax remains quite varied in the wild.
My pet peeve is commands not supporting -h for help and making me write --help. This is especially worse when the command already supports single character arguments.
So rage inducing
The name option is misunderstood. You have options. Sometimes you just have to pick one.
Try going to the ice cream shop and ask for an ice cream but refuse to give them the size, flavour or the type of dip. Tell them it's optional and you shouldn't need to provide this information on order to get ice cream.
Chances are you're suddenly getting a new set of options. A. Kicked out. B. No ice cream. C. Gigantic truck size vanilla icecream with garlic dip and tuna flavour. That'll be $79.99.
You have options but sometimes you have to pick a few.
If you argue for positional arguments, try ordering ice cream: large chocolate strawberry.
Does that mean chocolate flavour or dip?
Midjourney is the largest of the Discord apps that have achieved mainstream usage, despite being CLI-only.
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.
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.
> 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.
I am working on it here: 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.
It gets way too complicated real quick and a lot of things you _dont_ want to expose in documentation. It’s better to generate docs from a spec than the other way around, I’m pretty sure of this now.
At that point it would make sense for them to also make scaffolding generators, meaning the cli author only has to write one spec and don’t have to repeat the effort for their code so much.
I made a process where args are now in a toml file, with some various data for different operations, like whether its available in the CLI or API library, its arg flags, help text required value type, etc. From that, i can generate argparse args, documentation, code for other things, etc. Right now im generating args, docs, and a js code block from the same structure.
Heres the toml file: https://gitlab.com/accidentallythecable-public/prover-suite/...
And some docs that were generated from that: https://gitlab.com/accidentallythecable-public/prover-suite/...
Maybe it will give you some ideas on yours
Specification: https://gitlab.com/accidentallythecable-public/argstruct-spe...
Python module implementing specification: https://gitlab.com/accidentallythecable-public/python-module...
Then there's dd...
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.
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.
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.
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.
record video and then comment it ?
have detailed logs what button, and what fields where edits/pressed ?
etc ...
I'm not sure I like this modern idea where everything has to come to you without any effort.
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)
`command -function`
To
`command function -option`
Example:
Why is it:
ssh -l bob myhost.com
Vs
ssh login bob myhost.com
We need more TUI. Before there were GUI OSes, almost every application had a TUI of some sort (think back to DOS, etc.).
- 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.
Correct title is:
CLI User Experience Case Study: Topiary
?? I need to recursively tar a directory
Instead of git add you should have git-add. Few bother to get this right.
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
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!
!! 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.ccThere 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:*
> Among other things it makes the shell’s ! commands harder to use.
How so?
I can't think of any huge positives from using subcommands. I know for a fact that that will take longer to write and add some complexity to --args-* and I also feel like getting a quick --help option would be a lot more cumbersome.
Maybe a good way there is to list commands then tabbed/dashed indented under the root command list its subcommands.
git --help
git add --help
The former returns general information about the whole git executable, while the latter returns specific details about the add command.
It also gives an immediate intuition of entering a whole different flow that can not be composed with other flows, something that you don't have with --args There is a hierarchy between commands and options that is not expressed when both use the -- syntax
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.
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.
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.
But please, enlighten me how an average modern desktop computer user could install a free media codec pack on a user friendly distro without opening the terminal?
Linux has this problem where if you want to do anything above the absolute most basic tasks, you have to start goolging and copy+pasting cryptic lines of text into the terminal and cross your fingers that it does what you hope it will. As soon as you break away from the tasks that 95% of users do, you're in for punishment.
Mind you, I have been using ubuntu for 18 months now. And have been using Linux on and off for 20 years. I do it because...Micorsoft, but holy shit am repeatedly stunned by how average-user hostile linux is. They just refuse to stop speaking Klingon except for the most absolute basic things.
Do you need to? I thought Ubuntu shipped codecs by default these days. But if it's an extra package, I was pretty sure Ubuntu shipped a GUI frontend to package management these days, and if that's not good enough you can use it to install synaptic and do whatever you need[0][1].
> but holy shit am repeatedly stunned by how average-user hostile linux is. They just refuse to stop speaking Klingon except for the most absolute basic things.
To marginally overextend the metaphor, you speak English (which is a terrible mess of a language[2], but it's familiar to you), immigrated into the Klingon Empire, appear to understand that Klingon is actually a more efficient language, and still want the Klingons to stop speaking Klingon and convert to using English, because you want it to be easier to flee the Terran Empire[3] if they did even though most people won't do so regardless.
[0] https://itsfoss.com/synaptic-package-manager/
[1] https://help.ubuntu.com/stable/ubuntu-help/addremove-install...
[2] I say this as a native speaker: English is a horrible mess of a language, mostly because it started as 3 other languages in a trench coat and never stopped tacking on bits and pieces of other languages.
[3] Okay, the metaphor is way more than marginally overextended, but it's not like people would flee the Federation...
No terminal needed. Of course, on my own installation of Fedora, I've actually uninstalled the GUI package manager and use dnf in the terminal. :)
EDIT - And if the new user doesn't find the Discover app by browsing around, it will be the first result if you use the search bar in the start menu and search for "install". This aspect is truly easier than Windows. EDIT 2 - Oh, actually the Welcome/onboarding thing that pops up on a new install explains what Discover is for...
Why would the user need to worry about the ergonomics of the terminal? Is that something people worry about on Windows and MacOS?