CLIs are reified UIs (2017) • Hacker News Board

Re: CLIs are reified UIs (2017)

#91

Post by camgunz » Thu, May 28, 2020, 6:03 AM UTC

crazygringo wrote: post #35

njharman wrote: post #17

Earlier quoted context omitted.

GUIs are a discoverability nightmare. I've always found --help (or help for tools breakin the "standard") and man pages massively more discoverable than any gui. There are two well known entry points "--help" and "man". There has been much convention standardization with operating system guis, still they have many, many possible entry points. not all programs use same ones, use in same way. And webapps/pages are comp…

> GUIs are deeply nested. And context sensitive so it may not even be possible to see actions until certain condition is met. This is a feature, not a bug. For me, browsing 20 pages of --help or man is a discoverability nightmare. I don't want to wade through arcane option after arcane argument. The GUI gives me a well-organized top-level understanding of the program: organized menus, and organized panes (panels/pale…

CLIs and GUIs aren’t an either/or proposition. They each implement very different paradigms; OP goes over them pretty reasonably. You’re not supposed to discover a CLI; you’re either supposed to remember the 4 things you do all the time (see git) or script it and build your own interface/program (see coreutils or stuff like troff). It’s an entirely different UI. Arguing that CLIs aren’t discoverable misses the point just as much as arguing that GUIs aren’t composable. They’re not supposed to be.

Re: CLIs are reified UIs (2017)

#92

Post by whilenot-dev » Thu, May 28, 2020, 6:19 AM UTC

nerdponx wrote: post #27

fermienrico wrote: post #3

The biggest problem with CLI is discoverability as the article points out. Looking at Docker CLI, there are like a bazillion commands and it takes forever to read through the docs to find out what exactly to use. Furthermore, there are some commands that depend on the others being there - that breaks the composability. Back to discoverability, is there a way to make CLI "more discoverable"? Reading the man page doesn…

is there a way to make CLI "more discoverable" I've thought about this a lot. The answer, I think, is to have a "reverse index" of tasks that you can do with the tool and their corresponding commands or recipes. For example, man pages are typically organized alphabetically by option or subcommand. I'm envisioning a section of documentation - maybe a separate man page or just something on a website - that looks like t…

I use tldr[0] for that.

[0]: https://github.com/tldr-pages/tldr/

Re: CLIs are reified UIs (2017)

#93

Post by hhas01 » Thu, May 28, 2020, 7:39 AM UTC

camgunz wrote: post #91

crazygringo wrote: post #35

Earlier quoted context omitted.

> GUIs are deeply nested. And context sensitive so it may not even be possible to see actions until certain condition is met. This is a feature, not a bug. For me, browsing 20 pages of --help or man is a discoverability nightmare. I don't want to wade through arcane option after arcane argument. The GUI gives me a well-organized top-level understanding of the program: organized menus, and organized panes (panels/pale…

CLIs and GUIs aren’t an either/or proposition. They each implement very different paradigms; OP goes over them pretty reasonably. You’re not supposed to discover a CLI; you’re either supposed to remember the 4 things you do all the time (see git) or script it and build your own interface/program (see coreutils or stuff like troff). It’s an entirely different UI. Arguing that CLIs aren’t discoverable misses the point…

“CLIs shouldn’t be discoverable because they’re not supposed to be discoverable.”

Imagine if we applied the same defeatist tautological thinking to our other written materials: books wouldn’t have TOCs or indexes, the Web wouldn’t have search engines, and so on.

10,000 years of the written word, yet nothing is learnt. SMH.

Maybe if text-based interfaces did provide good, safe discovery they wouldn’t have been beaten into a cocked hat by GUIs for 99% of users. And this is despite GUI being something of a UX trap itself (as CLI fans are happy to point out), becoming ever moreso as personal computing moves beyond traditional physical point-and-click and expands into voice control.

Honestly, there’s more text smarts in a modern smartphone’s txt-ing interface than in today’s “cutting edge” of 1970s CLI design.

Is it really about providing good UI/UX, or about preserving the entrenched power structures of the computing world status quo?

--

“It’s a curious thing about our industry: not only do we not learn from our mistakes, we also don’t learn from our successes.”—Keith Braithwaite

Re: CLIs are reified UIs (2017)

#94

Post by nucleardog » Thu, May 28, 2020, 9:00 AM UTC

fermienrico wrote: post #3

The biggest problem with CLI is discoverability as the article points out. Looking at Docker CLI, there are like a bazillion commands and it takes forever to read through the docs to find out what exactly to use. Furthermore, there are some commands that depend on the others being there - that breaks the composability. Back to discoverability, is there a way to make CLI "more discoverable"? Reading the man page doesn…

> is there a way to make CLI "more discoverable"?

The first time I used Cisco’s IOS was pretty eye-opening to me, and I was thoroughly confused why something like that wasn’t present everywhere. (The only other place I’ve seen it is in MikroTik’s CLI.)

For those not familiar, at any point anywhere you can simply type a question mark and it will tell you all the valid inputs (commands, arguments, etc) at the exact spot your cursor is at and then put you right back where you were ready to continue typing.

You could discover a lot — not only what you were searching for, but related functionality — just by throwing a ‘?’ at it whenever you didn’t know what to type next.

Of course it helped that everything was named in a very straightforward manner. Something like this is never going to help you to discover a new Unix command because many are “cleverly” named. But once you find one you’ll be able to use it without ever referencing a manual page.

Re: CLIs are reified UIs (2017)

#95

Post by imtringued » Thu, May 28, 2020, 9:12 AM UTC

viraptor wrote: post #69

njharman wrote: post #17

Earlier quoted context omitted.

GUIs are a discoverability nightmare. I've always found --help (or help for tools breakin the "standard") and man pages massively more discoverable than any gui. There are two well known entry points "--help" and "man". There has been much convention standardization with operating system guis, still they have many, many possible entry points. not all programs use same ones, use in same way. And webapps/pages are comp…

> both --help (...) and man are 1 level deep and show you the entire ui, all at once Have you seen git's help/man? That's at minimum 2 levels deep.

Yes and that is much better than a one level deep manual.

Re: CLIs are reified UIs (2017)

#96

Post by micmil » Thu, May 28, 2020, 9:19 AM UTC

njharman wrote: post #17

fermienrico wrote: post #3

The biggest problem with CLI is discoverability as the article points out. Looking at Docker CLI, there are like a bazillion commands and it takes forever to read through the docs to find out what exactly to use. Furthermore, there are some commands that depend on the others being there - that breaks the composability. Back to discoverability, is there a way to make CLI "more discoverable"? Reading the man page doesn…

GUIs are a discoverability nightmare. I've always found --help (or help for tools breakin the "standard") and man pages massively more discoverable than any gui. There are two well known entry points "--help" and "man". There has been much convention standardization with operating system guis, still they have many, many possible entry points. not all programs use same ones, use in same way. And webapps/pages are comp…

Taking every single function of a program and splorting them all into one giant chunk of text is not discoverability or anything near it. It's an info dump, which is pretty much the opposite of discoverability.

At this point anyone arguing against GUIs likely doesn't have to actually USE a computer, simply keep them running.

Re: CLIs are reified UIs (2017)

#97

Post by Austin_Conlon » Thu, May 28, 2020, 9:19 AM UTC

old-gregg wrote: post #44

njharman wrote: post #17

Earlier quoted context omitted.

GUIs are a discoverability nightmare. I've always found --help (or help for tools breakin the "standard") and man pages massively more discoverable than any gui. There are two well known entry points "--help" and "man". There has been much convention standardization with operating system guis, still they have many, many possible entry points. not all programs use same ones, use in same way. And webapps/pages are comp…

> GUIs are a discoverability nightmare. Badly made GUIs are. I started my career developing desktop software. Both Apple and Microsoft used to publish guides for building proper GUIs for their platforms. Our UX designers and PMs were enforcing those vigorously. On Windows, every feature had to be represented in the menu of the main window. See, right there, by going (not even clicking on) every menu item you will lea…

Why past tense for guidelines from Apple? They're here: https://developer.apple.com/design/human-interface-guideline....

Re: CLIs are reified UIs (2017)

#98

Post by imtringued » Thu, May 28, 2020, 9:20 AM UTC

kondu wrote: post #33

njharman wrote: post #17

Earlier quoted context omitted.

GUIs are a discoverability nightmare. I've always found --help (or help for tools breakin the "standard") and man pages massively more discoverable than any gui. There are two well known entry points "--help" and "man". There has been much convention standardization with operating system guis, still they have many, many possible entry points. not all programs use same ones, use in same way. And webapps/pages are comp…

Yep. CLIs often also have a predictable interface. (Help is almost always -h or --help, version info is -v or --version, etc). On a GUI you'll have to play around a bit more and search for functionality.

CLIs are not guaranteed to have a predictable interface at all. The flag prefix isn't standardized at all. On Windows you see the awkward / prefix. On Linux you will see a random mix between -- or - and the way values are specified is also random. Sometimes it is --flag value at other times it is --flag=value or just -f value or -f=value with no fully written out counterpart. If there was actually a standard that every CLI application followed (or the format was parsed by the shell instead and applications simply receive the parsed array of arguments) then you could make this argument. I would love it if this were true but that isn't the world we live in.

Re: CLIs are reified UIs (2017)

#99

Post by imtringued » Thu, May 28, 2020, 9:26 AM UTC

funcDropShadow wrote: post #46

wnevets wrote: post #28

Earlier quoted context omitted.

My patience is so bad when it comes to cli discoverability I just skip to googling what I want to do.

Without patience you can master nothing. I hope you are fine with that.

Half the battle is knowing whether something exists or is possible.

Re: CLIs are reified UIs (2017)

#100

Post by prima-facie » Thu, May 28, 2020, 9:30 AM UTC

fermienrico wrote: post #3

The biggest problem with CLI is discoverability as the article points out. Looking at Docker CLI, there are like a bazillion commands and it takes forever to read through the docs to find out what exactly to use. Furthermore, there are some commands that depend on the others being there - that breaks the composability. Back to discoverability, is there a way to make CLI "more discoverable"? Reading the man page doesn…

There are a few things you can do.

1. Get a better shell with good auto-completion. I find bash to be lacking in this regard. I use fish but others like zsh.

2. Use a helper command like `tldr`[1]. It's not perfect and certainly not a replacement for a proper manual page, but it helps when in the middle of work.

[1]: https://github.com/tldr-pages/tldr-python-client