Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CLIs are reified UIs (2017)

expressionsofchange.org

Post reply on HN
Print view View original

41–50 of 126 posts

Re: CLIs are reified UIs (2017)

#41

Post by funcDropShadow »

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…

docker is an especially bad case of CLI UI. 1. Details of parameters changed quite often in the early times of docker. 2. Docker does not provide man pages, just a very terse --help output. 3. The --help output is often similar to the provierbial Javadoc comment of a Java getter, i.e. it is just a repetition of the parts of the name in different order with more noise. It usually doesn't answer any important questions about the tool. Just look at these:

      --dns list                       Set custom DNS servers
      --dns-option list                Set DNS options
      --dns-search list                Set custom DNS search domains
      --domainname string              Container NIS domain name
      --entrypoint string              Overwrite the default ENTRYPOINT of the image
  -e, --env list                       Set environment variables
      --env-file list                  Read in a file of environment variables
      --expose list                    Expose a port or a range of ports
None of these comments clarify the syntax or precise meaning of the parameters to the flags. Does it mention you can map internal to external ports with --expose? No, it doesn't but it would be really helpful to be able to look up the syntax.

You claimed man pages do not help. I disagree. To me man pages have the following advantages over web based documentation.

- A locally installed man page usually matches the version of the installed tool.

- I don't have to search for the correct web page or even software project that is the source of an installed program.

- It works offline.

- No SPA bullshit (hello docker and kafka) in documentation that slows down browsing, adds time wasting scroll animations, and often breaks navigation (Implementing the back and forward button in a SPA is not helpful if you loose your scroll state when navigating)

- Sometimes you have to use older software, i.e. because you want to recompile your college project with a matching compiler. Then it is really useful to have the documentation matching to your tools. Or you maintain certified firmwares, which were released and certified some years ago, then you have to use that software.

I am sure you are aware of the advantages of Web based documentation so I skip them.

update: [typos and formatting]

Re: CLIs are reified UIs (2017)

#42

Post by FroshKiller »

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…

Personally, I feel like verb-based CLIs get, like, four verbs max. I don't like Swiss Army knives. Do one thing, and do it well.

Re: CLIs are reified UIs (2017)

#43

Post by funcDropShadow »

slightwinder wrote: post #14
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…

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

> No, the moment you embedd the discoverabilty of GUI it stops being a CLI.

That statement is falsified by the advent of programmable completions. Nothing stops us from integrating context sensitive help into the shell completion mechanism. The shell could display a help text next to each item of a completion list, or you could press keyboard shortcut to get help to the command your cursor is positioned on. shellcheck could highlight a bash command while you are typing it. All that would not change the fact that a shell is a CLI.

Re: CLIs are reified UIs (2017)

#44

Post by old-gregg »

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…

> 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 learn about existence of every feature. Photoshop is still like that.

Most frequently used actions deserved two additional things: a hot key and a toolbar button. Each toolbar button had to have a tooltip. See? Right there, by going over the toolbar one could quickly learned the most important features.

Using windows, splitters, panes, tree views and tabs - there was logic behind those choices, and having standardized set of UI controls allowed users to learn software much more rapidly.

Modern web "applications" are crude by comparison. There's no standardized way to discover anything. Is it a button? Is it a dropdown? Is it just a strange background to display an error? Things auto-hide and auto-appear for no reason, you have to move mouse around (or practice every swipe variation you're familiar on mobile). Hotkeys are an afterthought, even resizing the browser or even scrolling sometimes breaks things.

I am not going to name names, but we tried to use one of web-based conferencing apps a few years ago. The UI it offered for joining a call (the URL you'd include into a meeting invite) was so bad that nearly 30% of people could not find out how to join. That's basically the only thing that page needed to provide, yet their UX people managed to obfuscate it so much that users sat waiting & thinking that something is about to happen instead of clicking the "join" button... Ughh.

There's so much demand for software right now, every industry needs more... There is severe shortage of talent for everything, from engineers to UX designers and product managers. Eventually there will be an equilibrium and we'll have professionals design and program GUIs again.

I am a CLI-first person, but there's no doubt in my mind that a well-done GUI massively flattens the learning curve for a new app.

Re: CLIs are reified UIs (2017)

#45

Post by c-smile »

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…

> GUIs are a discoverability nightmare.

Which GUI?

Re: CLIs are reified UIs (2017)

#46

Post by funcDropShadow »

wnevets wrote: post #28
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…

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.

Re: CLIs are reified UIs (2017)

#47

Post by funcDropShadow »

inetknght wrote: post #6
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…

> The biggest problem with CLI is discoverability I don't agree. Discoverability's a big problem with "modern" GUIs too. > is there a way to make CLI "more discoverable"? Reading the man page doesn't count Why doesn't reading the man page count? I've learned a hell of a lot more about CLI tools by reading their manual than I have by ... oh wait GUIs often don't come with a manual.

>> The biggest problem with CLI is discoverability

> I don't agree. Discoverability's a big problem with "modern" GUIs too.

Absolutely, nowadays you have to discover which part of the screen is clickable, you have to discover where they hid that stupid hamburger menu. The menus of the mac and Amiga were so, you could find them blindly with your mouse. On endless scrolling pages you often cannot skip ahead you have to scroll and wait, scroll and wait, scroll and wait, until the browser hangs.

Re: CLIs are reified UIs (2017)

#50

Post by zoomablemind »

I always considered GUI as a 'dialog'. That is implying a conversation between user and program. Meanwhile, CLI, especially in scripted use, appear as monologs. Of course, CLI can also show user-prompts, but in repeated use they will likely get scripted. This turns CLI into a command monolog: "I described everything needed", where program declares: "Here's the best I could do for that."

On the other hand, a dialog assumes there's some value in the exchange of bits of information. In a general sense, GUI is a forum, allowing user to interact with several systems/components at once, as if constantly refining the common understanding of what needs to/could be/has been done.

I noticed a paradigm shift in GUI handling of settings dialogs. While traditionally there was an OK button to effectuate the changes, modern GUI assumes a more affirmative stance and effectuates each given change immediately, without the need for a final OK.

In a way this removes the program as a party in the dialog, making it closer to CLI interaction style.

Ultimately, we don't want to converse with the program/machine/system. We want the result, whatever it takes.

I'm not into chatting to bot/Siri/Google/Cortana/Echo/?? about turning on lights in the room. I'm commanding the lights. LIGHT!

I'm not convincing gmail to send a message for me. I'm talking to the recipient. Instead, I'm shown a progress bar, as if the program is asking me to cheer for it to reach the golden 100%.

I guess, deep down as user I'm more like 'command-and-control', rather than a receptive 'let's-hear-all-opinions' kind.

Post reply on HN