
CLIs are reified UIs (2017) - ascertain
https://www.expressionsofchange.org/reification-of-interaction/
======
fermienrico
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't count. Like can we combine the advantages of CLI
with the discoverability of GUIs? I wanna have the cake and eat the whole
thing.

~~~
njharman
GUIs are a discoverability nightmare.

I've __always __found --help (or help <command> 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 complete non-convention chaos.

both --help (but not "help <command>" (a reason they are "wrong") and man are
1 level deep and show you the entire ui, all at once. That is definition of
discoverable! One action, i've discovered everything.

GUIs are deeply nested. And context sensitive so it may not even be possible
to see actions until certain condition is met. The definition of opaque and
undiscoverable.

~~~
crazygringo
> _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/palettes/tabs/etc.). Then I can
drill deeper into dialog boxes and tool settings _as needed_.

It's _far_ more efficient to quickly browse a GUI to figure out the lay of the
land, than it is to wade through what is essentially the _reference manual_ of
a CLI tool.

Reference manuals are the _opposite_ of discoverability.

~~~
cma
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'.

~~~
themacguffinman
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?

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

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

------
wrs
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-...](https://docs.microsoft.com/en-us/windows-
server/identity/ad-ds/get-started/adac/advanced-ad-ds-management-using-active-
directory-administrative-center--level-200-#BKMK_HistoryViewer)

~~~
rcxdude
Blender does this, and I've also used an FPGA IDE which had the same feature.
I think it's pretty useful, but both have holes where there's actions in the
GUI which don't work properly in the script.

------
faleidel
While discoverability can be better with GUI's I find that googling things is
always better for CLI tools. Most of my CLI search have a one or two lines of
bash I can simply copy paste while solutions for GUI programms often involves
lot's of screenshots of dropdowns to open and if the look of the application
changed or the element's in the dropdown's are not the same it can be hard to
follow.

Taking not's of how to do things or creating shorcuts will also always be
better with CLI's since manipulation text is easy and always supported.

~~~
fctorial
Give cht.sh a try. You'll like it. It kind of does googling for you.

Doesn't work everytime though.

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

~~~
strogonoff
To me CLI feels much more like a verbal dialog with a person, while many GUIs
give a feel of poking and pointing. Might be subjective—I also much prefer
audio calls over video, for example.

------
morty_s
I have great respect for consistent and coherent CLI interfaces. The first
piece of software I released was a command line app. I put a lot of time into
designing the interface before I wrote any code.

I “designed” the commands (the grammar, collected terms, syntax and semantics,
etc.) before implementing them. The goal was to provide a “guessable”
interface, eg. if you ‘load’ then it makes sense to ‘unload’.

Next time I do something graphical, I’d like to design a scriptable CLI
interface first, then use end/entry-points to build the GUI.

------
FpUser
CAD and other high end complex packages for example offer combination of
command line and GUI at the same time where one can augment the other at many
points.

~~~
krab
What I liked the most was when a GUI would emit the CLI commands for my
actions. It breaks the discoverability barrier significantly. You learn in the
GUI but you can switch gradually to the CLI with aliases, functions and loops.

------
shric
I really wish more CLIs would have a, ideally standard, flag to output
something structured and easily parsable. One of the biggest arguments for
CLIs is their composability, which is true for canonical examples like | sort
| uniq -c | sort -nr | head -10 etc. However, I find myself constantly having
to use awk, sed, cut, etc. far too often. A very much inexhaustive list of
things one has to deal with:

\- whitespace delimited with fields that contain whitespace.

\- tabular lined up data that doesn't actually use tabs, and when a field is
too wide, it just pushes the rest of the line over.

\- 5,000 different variants of CSV

Of course some things (e.g. kubectl) have json and yaml output options, which
can be nicely parsed with jq.

I also found
[https://github.com/kellyjonbrazil/jc](https://github.com/kellyjonbrazil/jc)
handy, which attempts to convert many commands to json output.

------
pritovido
You could use both GUIs and CLIs in the same program. It has been done this
way in CAD since the old days.

E.g Most people today do not know that Autocad started using text commands for
everything you did with your project(in DOS).

Those commands were interpreted in a dialect of Lisp(AutoLISP). First those
commands were organized in menus, then text was replaced by icons, but the
commands were there if you wanted to use them.

So you can use Rhino3d with both the GUI or the CLI. Or in blender3d, each GUI
has a corresponding command you can use in Python.

Apple wanted to make it generic behavior for Apple apps with automator but
most developers refused to make their programs scriptable.

~~~
akx
Not as much refused, but didn't or don't see the value in the added complexity
(of development).

------
roryrjb
Previously discussed here:
[https://news.ycombinator.com/item?id=15619796](https://news.ycombinator.com/item?id=15619796)

------
pontifier
This brings up some interesting ideas about improving a CLI by improving the
record keeping making it more deterministic, and enabling undo.

Thinking about these 3 features together would essentially give a computer
system a version control or tool assisted speed run kind of feel.

Every command changes the state, and the system can be rolled back, and
experimented with.

I really like where this line of thinking could lead.

~~~
troelsSteegin
What do you mean by "deterministic" in this setting? That each action afforded
via the CLI has a specific outcome with only first order effects? That's what
I interpret as necessary for the robust undo you describe. Is that what you
have in mind? tx.

------
carapace
I have an experimental GUI that uses a simple language to _reify_ interactions
as described here. It works great.

~~~
vanschelven
I would love to see it.

~~~
carapace
Cheers! It's not really ready yet but I could really use some feedback:

Docs:
[https://xerblin.readthedocs.io/en/latest/](https://xerblin.readthedocs.io/en/latest/)

Project: [https://sr.ht/~sforman/Xerblin/](https://sr.ht/~sforman/Xerblin/)

Repo (browse or clone):
[https://git.sr.ht/~sforman/Xerblin](https://git.sr.ht/~sforman/Xerblin)

I am in the process of adding more information to the docs. The code should
run on a recent version of Python 3. The underlying language is Joy and the
package for that is on PyPI so it should (fingers crossed!) download and
install automatically if you run setup.py (I think). I'd appreciate any
feedback you can give me. Ciao!

------
tony-allan
The closest CLI style interaction in a GUI is the Jupyter Notebook interface
that combines code and documentation.

This could easily be used to document complex reusable command sequences.

[https://jupyter.org/](https://jupyter.org/)

------
BiteCode_dev
I think all cmd should have a "tutorial", "doc", and "quickref" subcommands.

Eg:

git quickref

This will list the most commonly used git invocations and their affect

Git quickref chekcout

This will list the most common checkout invocations.

Git doc open your browser to an offline doc html doc, etc

------
techbio
Reification/logging is forward-looking too, and I might be interested in the
ability to compose a GUI from the ‘history’ file with my most commonly used
commands.

