Live data from Hacker News

CLIs are reified UIs (2017)

expressionsofchange.org

61–70 of 126 posts

Re: CLIs are reified UIs (2017)

#61
I've used at least a few GUIs that automatically generated a log of commands corresponding to your GUI actions, which you could observe, replay, or copy into a script. The only one I can think of right now is the Active Directory Administrative Center [0], with its "history viewer" that shows the PowerShell command equivalent of everything you do. I think another one was SQL-related. Anyway, this is one way you can "reify" a GUI that happens to correspond to an equivalently powerful CLI.

(Edit) Another example of reification is the Google Cloud Console, where you can go through a webpage for a complicated operation like creating a VM, but instead of pressing Save, you can click a link to see the equivalent gcloud CLI command and HTTP API request. I've used this a lot to script bulk operations after generating one outline for a request.

[0] https://docs.microsoft.com/en-us/windows-server/identity/ad-...

Re: CLIs are reified UIs (2017)

#62

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…

> Badly made GUIs are.

So pretty much every browser out there? Without knowing ahead of time from random pilfering through various menus, how can you tell if your browser is up-to-date or not?

How do you find the extensions page? Or is it add-ons? Depends, I guess.

How do I figure out which tab of (potentially) hundreds is consuming CPU and memory?

I won't claim that CLIs are better, but GUIs are definitely not made for discoverability these days.

Re: CLIs are reified UIs (2017)

#63
post #7

Earlier quoted context omitted.

The VMS operating system had a standardized command line help UX. Typing HELP gave you an overview of commands available (Curses style) and you could drill down into more specific commands from that. If you knew the command but not the flags then you could add the HELP flag to get more and more specific information. See page 1-18 and 1-19 of the user guide: https://www.isis.stfc.ac.uk/Pages/vms-user-manual.pdf We had…

On the one hand, I recall that fondly. On the other hand, a modern Linux box might have thousands of commands, and I'm not sure that VMS HELP could handle that well.

It sounds almost exactly like the unix (1)man command actually, and, well:

  $ ls /usr/share/man/man1/ | wc -l
  2997
I'd say that qualifies as thousands (plural).

Re: CLIs are reified UIs (2017)

#64
post #37

Earlier quoted context omitted.

Isn't that just the EXAMPLES section of a man page?

Yes but not all CLI tools have it, or have it extensive enough.

But then the solution is just "better documentation". Every time the solution is just "don't suck", i think it's fair to say that the solution won't work.

For instance, in the past decade or so, the quality of guis have gone so far downhill, that is now commonplace for advanced users to have no idea that certain features exist because they're only exposed if you swipe like so and then tap this logo that doesn't look like a button. the technical knowledge exists for how to design usable graphical user interfaces, but "make better UIs" is not a high priority for businesses and the people they hire.

cli's have a certain advantage that many cli's are open source and technically not beholden to business interests (altho they may be defacto), and they're not fashionable amongst those for whom empowering users is a curseword, so "don't suck" is theoretically possible, but i don't know that it's particularly likely.

Re: CLIs are reified UIs (2017)

#65
post #12

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…

This probably won't work with Unix shell, but some CLIs (JunOS comes to mind) have a context help that's shown when you press "?". But note it's not "? ", you don't need to press enter; merely inputting a single "?" character shows possible things you can append to the command line at that point.

That's not a CLI, that's a TUI. Eg, Dwarf Fortress does this.

Re: CLIs are reified UIs (2017)

#66
post #38

Earlier quoted context omitted.

I rarely wade through it and just search for what I'm looking for. Typing '-i' (in the session, not as a param) will make the search case insensitive if using 'less'.

So the solution is to use another separate CLI utility that you have to read the manual for, and memorize '-i' as an option for it?

I wouldn't consider less a pure CLI utility, since it puts the terminal more into a screen mode.

Re: CLIs are reified UIs (2017)

#67
post #18

Earlier quoted context omitted.

> 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. Is this really a problem of CLI or just an example of a complex application? If we take for example something like excel or photoshop, then you can't easily figure what to do, even if the doc is directly embedded inside the UI. > Back to discoverability, is there a way to make CL…

The hundreds of millions of people that use excel with limited to no training would likely beg to differ with the proposition that it isn’t discoverable. I’ve never taken an excel class or read basic excel docs, yet I know how to do basic excel things. That’s literally impossible in a CLI. Similarly, how many people have trouble saving and quitting a word document? What about vim?

I have trouble saving a word document nowadays, since they close the document when you want to save or print. (You press file, and now the document has been closed and replaced by some menu. I do not know if my actions will apply to the document that I had had open before the program helpfully closed it and makes me feel very uncertain. I do not like to use Word for this reason. It is completely unfathomable to me why of all menus, the File menu is the menu that closes your document. I thought it should be the one to help you interact with it most.)

Re: CLIs are reified UIs (2017)

#68

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…

Don't forget "whatis" as your standard third entry point on Unix.

macOS does have a standard Help menu, and you can even live search from within it; it'll find a command within the menus and show you where it is, even if it's deeply nested. Or it will search through help topics if the application provides them.

> And context sensitive so it may not even be possible to see actions until certain condition is met.

That's gotten worse as developers have jammed more and more features into applications, to where they can't lay out their commands in the traditional menus.

We somewhat dodged a bullet in this regard. Apple and Microsoft both did experiments in component software back in the '90s, with Object Linking and Embedding on Windows and OpenDoc on the Mac.

They flopped for a variety of reasons, but one was the insane complexity of the UI: any object in a document was now potentially a mini application and had to negotiate control of the UI with other objects.

Re: CLIs are reified UIs (2017)

#69

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…

> 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.

Re: CLIs are reified UIs (2017)

#70
Oh so many false or misleading claims.

1. "The keyboard allows for faster input"; sometimes that's true, but consider picking a coordinate within an image. Mouse is better than KB for such a task. 2. Composable commands; GUIs have these too. 3. Scripting; GUIs have this too.

Reification in GUIs exists; consider an activity log or automator script. Absence of reification also exists in CLI; consider a package manager downloading packages; basically any CLI program that manipulates the screen like ncurses.

Which brings us to the worst offenders: CLI programs pretending to be GUI programs. They minimize the benefit of CLI while only taking the weakest advantages of a GUI. Build tools like webpack come to mind here.

The article seems to be presenting best-case CLI against worst-case GUI.

Post reply on HN