4.8 KiB
| layout | title | tags |
|---|---|---|
| post | UwUI: Making the Most out of CLI and GUI | 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.