79 lines
4.8 KiB
Markdown
79 lines
4.8 KiB
Markdown
|
---
|
||
|
|
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.
|