3 Commandments for CLI Design in 2020
medium.com
medium.com
I have also been living on the command line since the 90s, and I mainly write command-line systems (in C, but sometimes in bash).
The biggest takeaway for me was "enable progressive discovery." I wrote an essay years ago called "The Mythical Man-Finger" that was all about CLIs and how modern GUIs are often more cumbersome (I was arguing that for many applications, language is a superior interface than "pointing at things").
The biggest objection to my essay was that CLIs make it hard for you to just jump and screw around, and I had to concede that this is mainly right. You won't know how to make things look like chrome by manipulating alpha channels in Photoshop the first time you open it, but . . . you know, this big button probably means rotate. ;)
But it may also be that "optimizing the first fifteen minutes" in this way results in a program that's actually harder and slower to use as you get more familiar with it.
It seems to me that what you're doing is trying "optimize the first fifteen minutes" of the UX with CLIs -- a thing CLIs often do very poorly. It's great stuff.
For me personally: Why am I so addicted to switches and arguments rather than commands? I think my only reason is because I see a lot of other CL programs working that way.
I guess I haven't decided what I think about "bat" (I feel like there's a landmine in there somewhere that makes it so you should be super careful about going upscale in this particular case). But I take the general point. Why are we coding like it's 1975?
Great stuff.
Interesting point about "first 15 minutes" - the service (and CLI) we're building will probably guide users into the CLI experience during that first ... maybe first 30-60 minutes, rather than 15, but _really_ early on as they get familiar with it.
From a UX standpoint, that discoverability you describe with the GUI is really about the affordances the user can discern with from the baseline state. That is, the 'rotate' button is visible without the user having to do any discovery at all, it's just _there_. What would the CLI equivalent be - I think part of it is the autocompletion scripts that bash/zsh let programs drop in to the `completions` directory so `command <TAB>` shows you all the possible next steps...? Worth thinking about.
What frustrates me is that CLIs are not really part of the "design" conversation in computing at all. I feel like GUIs have so taken over, that no one is even interested anymore in figuring out how to create great language-based interfaces (which is really what CLIs are, I think).
When I say "no one," I mean the professional UI/UX crowd -- who very often come up with miraculous ideas with GUIs. It would be great to see some of that energy being brought to bear on text-based systems.
P.S. I'm amazed this didn't take off on HN!
I was really expecting, given the strong opinions people here have about all things design related, that there'd be some spicy takes :D
But I super appreciate your feedback, thank you!