6 ms·

The CLI is peak UX for anyone technically competent.

Gualdrapo 3y ago
I agree but CLI just can't cover all use cases - just on top of my head are graphics, animation software, video editing, circuit making...
throw10920 3y ago
Well, they think it is. Most of the time, it's not. Command-line tools have terrible ergonomics for many workflows and use-cases.
nvy 3y ago
For a subset of tasks, maybe. But I'd rather use Firefox than lynx. And I'd rather use Thunderbird than mutt or pine.
- worksonmine 3y ago
  I get Firefox (with keyboard navigation) over Lynx but Mutt has been fantastic for my productivity.
IshKebab 3y ago
Utter nonsense. The CLI lets you do complex custom things that you sometimes can't do with a GUI. But it is pretty awful from a UX point of view. Terrible discoverability, terrible UI, very unfriendly, no contextual help, etc. etc. I can't think of a worse interface from a UX perspective.
- nilsherzig 3y ago
  Terrible discoverability? A shell with tab completion is (in my opinion) a lot easier to navigate than for example Photoshops menus.
- olddustytrail 3y ago
  Really? Do you communicate with ChatGPT by pointing at pictures?
  - pjmlp 3y ago
    That is a REPL, not a CLI.
    - yjftsjthsd-h 3y ago
      A shell is a REPL. Though I do I agree there's something to using one with good features (ex. I would completely understand someone using exclusively zsh just for the better tab-completion).
      - pjmlp 3y ago
        A traditional UNIX shell is more of a poor man's REPL, hence the difference in wording.
  - fragmede 3y ago
    Conversation mode, where you talk with it, is quite an improvement over having to type at it, especially for slow, hunt and peck typers.
  - IshKebab 3y ago
    What has ChatGPT got to do with it? We're talking about Unix style CLIs.
- worksonmine 3y ago
  The manual exists for a reason. I find it much easier to type `man program` then `/whatever` until I find what I'm looking for rather than scanning the screen for the correct icon. There are also some conventions and after a while you get to a point where it's intuitive to use any new program. Just like with a GUI and icons, what does the wand do?
  - IshKebab 3y ago
    "You just have to read the manual" and "you get used to it" are basically synonyms for "the UX is bad". 1 second of googling: https://fstoppers.com/opinion/stop-telling-people-read-manual-512473 https://fstoppers.com/opinion/stop-telling-people-read-manua... I'm sure there are better articles if you search more. If you have time for a book, I highly recommend "The design of everyday things". If you don't agree with me that book will change your mind.
    - worksonmine 3y ago
      You get used to it as in "used to how CLI programs are usually designed". Just as you get used to what the select icon in a GUI does. Without any prior experience in any both seem like alien technology, but coming from GUI to CLI you have the bias of already knowing one when comparing. People claim macOS is intuitive and everything works the same, but I'm handicapped in it. I just call it inexperience not being bad UX. Regarding the manual, does GUI programs have a unified way to access guides and documentation? Can I scroll to the bottom with G and find the configuration files and example uses?
      - bitwize 3y ago
        The difference is, you can teach a user who's never seen a computer before to work with a GUI in an afternoon, maybe a weekend -- and if the GUI is well-designed, the skills they learn on one program will transfer well to others. Meanwhile, there are XKCDs about how even experts can't remember how to work tar: https://xkcd.com/1168/ https://xkcd.com/1168/ Before 1984, computer UX was, universally, sucky. As Alan Kay put it, the Mac was the first computer worth criticizing.
lupusreal 3y ago
In principle maybe, but all present implementations fall a bit short. Why can't I use my mouse to position the cursor in any shell? Placing the cursor with the mouse is something people commonly do in terminal editors like vim or emacs; the efficiency arguments against it fall flat because this is entirely optional and besides, many people use laptops with either a track-point directly in the middle of the home row keys or with a touchpad directly below the keyboard. And there's no technical reason it couldn't be done; years ago I once did it as a proof of concept. It just hasn't made it into any major shell yet.. besides eshell anyway. It does work on eshell. Anyway, it's not really a big deal, not important enough for me to pursue, but I do think it counts as a counterexample to disprove the "peak UX" claim. Command line interfaces in principle are great but in practice we're doing it by emulating hardware that went obsolete decades ago and piling cludges and hacks on top of that to make it feel a bit more modern. Another example; there are a few ways to inline images in a terminal emulator but they're all kind of shit in their own ways; graphical thumbnails have clear utility when listing some directories; every serious file manager supports it but to do this in a terminal emulator is cludgy hacks.
- mixmastamyk 3y ago
  It’s not done because there’s no use case. No point in writing anywhere and clobbering existing text.
  - yaomtc 3y ago
    Nonsense. Fixing a typo or amending a command somewhere in the middle are obvious use cases.
    - mixmastamyk 3y ago
      That’s only the last line, not quite what they stated. Still a lot slower than emacs or CUA keys, so no it doesn’t fall flat. The kind of person that would use it doesn’t use a terminal.
      - 3y ago
pjmlp 3y ago
We should have kept using MS-DOS...
chefandy 3y ago
That's what people who gained their technical competence in a CL environment always think: we're always most productive in the interfaces we are familiar with. I'll agree that most technically competent people probably prefer using the command line for many tasks, but correlation != causation. It's really easy to mistake our own preferences for being objectively good, generally... which is why designers exist, why most user-facing commercial software doesn't require reading a single line of documentation, and why most FOSS projects-- almost entirely indifferent to or hostile towards deliberate design-- are only useful to people who have a working mental model of what's happening under the hood. I was strictly a vim guy for a decade and a half... my coworkers occasional snicker merely steeled my resolve, but I knew I was doing the pure and efficient and technically correct thing by sticking to barebones vim. Lots of vim stuff and ex commands are beneficial to my workflow, but after a coworker convinced me to try out some more modern options with vim modes, I realized that my attachment to vim as an editor was driven by my emotional investment in how many times I struggled with vim's clunkiness. I wore it as a badge of honor. I thought it gave me cred. In reality it just showed how utterly inflexible I was. The Jetbrains editors, for example, offered more functionality out of the box than I could practically cram into my vim setup, yet was completely configurable, and the features were generally intuitive and discoverable. I didn't have to look up how to do some relatively obscure thing in ex-- there was probably a menu option for it so I just didn't have to keep it in my head. Sure, vim is and always will be my default editor for light editing, and there are obviously people whose use cases are perfectly satisfied by using it. However, assuming for years that I was more technically competent for doing intensive professional work in complex codebases using that clunky old editor was plain old self-indulgent arrogance, like most other nerd badge-of-honor things are. I've been using command line environments daily for decades, and usually head there first to do many tasks, but many of these archaic tools only persist because of a reverse eternal-September problem. By the time someone gets technically advanced enough to start influencing how our technical environments work, the curse of expertise obfuscates their downsides and they mistake their own comfort with something for it being objectively good.
curt15 3y ago
The best CLI will never have the discoverability of any competently designed GUI.

I agree but CLI just can't cover all use cases - just on top of my head are graphics, animation software, video editing, circuit making...

throw10920 3y ago

Well, they think it is. Most of the time, it's not. Command-line tools have terrible ergonomics for many workflows and use-cases.

nvy 3y ago

For a subset of tasks, maybe. But I'd rather use Firefox than lynx. And I'd rather use Thunderbird than mutt or pine.

worksonmine 3y ago
I get Firefox (with keyboard navigation) over Lynx but Mutt has been fantastic for my productivity.

IshKebab 3y ago

Utter nonsense. The CLI lets you do complex custom things that you sometimes can't do with a GUI. But it is pretty awful from a UX point of view. Terrible discoverability, terrible UI, very unfriendly, no contextual help, etc. etc. I can't think of a worse interface from a UX perspective.

nilsherzig 3y ago
Terrible discoverability? A shell with tab completion is (in my opinion) a lot easier to navigate than for example Photoshops menus.
olddustytrail 3y ago
Really? Do you communicate with ChatGPT by pointing at pictures?
- pjmlp 3y ago
  That is a REPL, not a CLI.
  - yjftsjthsd-h 3y ago
    A shell is a REPL. Though I do I agree there's something to using one with good features (ex. I would completely understand someone using exclusively zsh just for the better tab-completion).
    - pjmlp 3y ago
      A traditional UNIX shell is more of a poor man's REPL, hence the difference in wording.
- fragmede 3y ago
  Conversation mode, where you talk with it, is quite an improvement over having to type at it, especially for slow, hunt and peck typers.
- IshKebab 3y ago
  What has ChatGPT got to do with it? We're talking about Unix style CLIs.
worksonmine 3y ago
The manual exists for a reason. I find it much easier to type `man program` then `/whatever` until I find what I'm looking for rather than scanning the screen for the correct icon. There are also some conventions and after a while you get to a point where it's intuitive to use any new program. Just like with a GUI and icons, what does the wand do?
- IshKebab 3y ago
  "You just have to read the manual" and "you get used to it" are basically synonyms for "the UX is bad". 1 second of googling: https://fstoppers.com/opinion/stop-telling-people-read-manual-512473 https://fstoppers.com/opinion/stop-telling-people-read-manua... I'm sure there are better articles if you search more. If you have time for a book, I highly recommend "The design of everyday things". If you don't agree with me that book will change your mind.
  - worksonmine 3y ago
    You get used to it as in "used to how CLI programs are usually designed". Just as you get used to what the select icon in a GUI does. Without any prior experience in any both seem like alien technology, but coming from GUI to CLI you have the bias of already knowing one when comparing. People claim macOS is intuitive and everything works the same, but I'm handicapped in it. I just call it inexperience not being bad UX. Regarding the manual, does GUI programs have a unified way to access guides and documentation? Can I scroll to the bottom with G and find the configuration files and example uses?
    - bitwize 3y ago
      The difference is, you can teach a user who's never seen a computer before to work with a GUI in an afternoon, maybe a weekend -- and if the GUI is well-designed, the skills they learn on one program will transfer well to others. Meanwhile, there are XKCDs about how even experts can't remember how to work tar: https://xkcd.com/1168/ https://xkcd.com/1168/ Before 1984, computer UX was, universally, sucky. As Alan Kay put it, the Mac was the first computer worth criticizing.

lupusreal 3y ago

In principle maybe, but all present implementations fall a bit short. Why can't I use my mouse to position the cursor in any shell? Placing the cursor with the mouse is something people commonly do in terminal editors like vim or emacs; the efficiency arguments against it fall flat because this is entirely optional and besides, many people use laptops with either a track-point directly in the middle of the home row keys or with a touchpad directly below the keyboard. And there's no technical reason it couldn't be done; years ago I once did it as a proof of concept. It just hasn't made it into any major shell yet.. besides eshell anyway. It does work on eshell. Anyway, it's not really a big deal, not important enough for me to pursue, but I do think it counts as a counterexample to disprove the "peak UX" claim. Command line interfaces in principle are great but in practice we're doing it by emulating hardware that went obsolete decades ago and piling cludges and hacks on top of that to make it feel a bit more modern. Another example; there are a few ways to inline images in a terminal emulator but they're all kind of shit in their own ways; graphical thumbnails have clear utility when listing some directories; every serious file manager supports it but to do this in a terminal emulator is cludgy hacks.

mixmastamyk 3y ago
It’s not done because there’s no use case. No point in writing anywhere and clobbering existing text.
- yaomtc 3y ago
  Nonsense. Fixing a typo or amending a command somewhere in the middle are obvious use cases.
  - mixmastamyk 3y ago
    That’s only the last line, not quite what they stated. Still a lot slower than emacs or CUA keys, so no it doesn’t fall flat. The kind of person that would use it doesn’t use a terminal.
    - 3y ago

pjmlp 3y ago

We should have kept using MS-DOS...

chefandy 3y ago

That's what people who gained their technical competence in a CL environment always think: we're always most productive in the interfaces we are familiar with. I'll agree that most technically competent people probably prefer using the command line for many tasks, but correlation != causation. It's really easy to mistake our own preferences for being objectively good, generally... which is why designers exist, why most user-facing commercial software doesn't require reading a single line of documentation, and why most FOSS projects-- almost entirely indifferent to or hostile towards deliberate design-- are only useful to people who have a working mental model of what's happening under the hood. I was strictly a vim guy for a decade and a half... my coworkers occasional snicker merely steeled my resolve, but I knew I was doing the pure and efficient and technically correct thing by sticking to barebones vim. Lots of vim stuff and ex commands are beneficial to my workflow, but after a coworker convinced me to try out some more modern options with vim modes, I realized that my attachment to vim as an editor was driven by my emotional investment in how many times I struggled with vim's clunkiness. I wore it as a badge of honor. I thought it gave me cred. In reality it just showed how utterly inflexible I was. The Jetbrains editors, for example, offered more functionality out of the box than I could practically cram into my vim setup, yet was completely configurable, and the features were generally intuitive and discoverable. I didn't have to look up how to do some relatively obscure thing in ex-- there was probably a menu option for it so I just didn't have to keep it in my head. Sure, vim is and always will be my default editor for light editing, and there are obviously people whose use cases are perfectly satisfied by using it. However, assuming for years that I was more technically competent for doing intensive professional work in complex codebases using that clunky old editor was plain old self-indulgent arrogance, like most other nerd badge-of-honor things are. I've been using command line environments daily for decades, and usually head there first to do many tasks, but many of these archaic tools only persist because of a reverse eternal-September problem. By the time someone gets technically advanced enough to start influencing how our technical environments work, the curse of expertise obfuscates their downsides and they mistake their own comfort with something for it being objectively good.

curt15 3y ago

The best CLI will never have the discoverability of any competently designed GUI.