fef/blog
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

add combining-cli-and-gui article

Browse source
This commit is contained in:
anna 2021-02-15 23:02:56 +01:00
parent ba8d40419c
commit f03f4b2e5b
Signed by: fef
GPG key ID: EC22E476DC2D3D84
1 changed files with 78 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

78
_posts/2021-02-15-combining-cli-and-gui.md Normal file
View file

@ -0,0 +1,78 @@
---
layout: post
title: "UwUI: Making the Most out of CLI and GUI"
tags: tech
---
The most common implementations of human-machine interaction are the CLI and GUI--two concepts with
mutually exclusive core beliefs, having caused countless heated discussions over which one of them
being superior. While the former focuses on brevity and efficiency, the latter excels at guiding
(especially, but not only) unexperienced users by being more expressive than raw text. But is that
everything there is to this story? Obviously not, otherwise this would be the end of the article.
Please note that this post is just the result of a spontaneous idea and definitely not thought
through entirely, so it is absolutely possible that i am overseeing something critical here and the
whole thing is garbage.
## Using CLIs is Programming
The command line came long before graphical interfaces for a reason--it is the least ambiguous and
most simple way to receive user input, and CLI parameter parsing libraries can be reused with ease.
In other words, using the CLI can be thought of as describing a collection of instructions that are
precise enough to be executed by a computer to achieve a specific task. If that sounds familiar,
it's probably because the standard industry term for this is _programming_. An incredibly high
level form of programming, sure, but still programming nonetheless. The command line is, if you
will, nothing but a language binding between natural (human) language and machine instructions.
## Everything is Programming
Continuing this train of thought will in turn lead to the conclusion that pretty much any human
interaction with computers is technically a form of programming, even if an excessively obfuscated
one. And this very fact is the fundamental flaw with GUIs--they are just too good at hiding that
the machine you are interacting with is still just that: a machine, nothing more.
When we are subconsciously thinking of machines as something else, we automatically make certain
assertions about their behavior, making situations where they can't keep up with them all all the
more frustrating. By the way, this is also a reason why graphical programming languages probably
aren't that good of an idea for anything other than educational purposes.
## Write Text, View Images
Even though graphical programming languages aren't exactly the smartest way of _writing_ programs,
they are doing a pretty solid job of giving people _reading_ them an understanding of what is
roughly going on. Why? Because meat bags are as good at image recognition as machines are at
number crunching (people say "a single image conveys more than a thousand words" for a reason).
Coincidentally, computers have become stupidly fast at rendering stuff. So fast, in fact, that we
can afford fancy animations and whatnot without really impacting system performance that much.
Why not make use of the meat bags' ability to parse images then?
In conclusion:
- text is the most efficient and least ambiguous way of commanding machines,
- people are better at understanding images than reading text, and
- machines have become pretty fast at rendering images.
With that in mind, the answer to the intial question seems quite obvious: commands should be input
as plain text, while immediate feedback is given using fancy graphics. The best application
scenario for this is managing files, which a GUI can visualize vividly using tree views and
thumbnails and whatnot, while a shell prompt is going to require barely more than a few keystrokes
to do any basic action, at least if you're using autocompletion.
I am calling this paradigm _UwU User Interface_, or **UwUI** for short, because i am imagining it
being indeed very uwu to use (i am absolutely not open to alternate name suggestions btw, unless you
manage to come up with an even worse one). I am probably going to publish a proof of concept app
for this if i don't forget about or lose interest in it, which i would definitely write a follow-up
article about and link it here.
## Why Stop There?
But that is not everything there is to it. If you ever wanted do do stuff like bulk deleting files
using regular expressions but ended up moving them to a different directory first or specifying the
`-i` flag because you were too scared of accidentally deleting something you didn't intend to, a GUI
can help by displaying all files that would be affected by the operation that is only executed once
you hit enter.
Another incredibly useful feature of most GUIs is the undo button. Why wouldn't shells want to make
use of this as well? This could make them significantly more attractive, especially to new users
who often are afraid of breaking something. Knowing they could make everything as before by simply
writing `undo` would lower their threshold to wanting to experiment significantly.