Visibility
Sometime around 1995, computers and the Internet started becoming a lot more mainstream. It might have been sometime between '95 and 2000 when UI design reached its peak before it plunged deep into the abyss of "mobile first"... but even if you disagree with this statement, the rate of evolution was definitely pretty high.
One of the gems I know about from this time is this piece of research Microsoft did to figure out how to make Windows easier to use. This was a time when a lot of people saw computers from up close for the first time; it was definitely challenging to come up with something that would be reasonably intuitive for new users too.
(And yet, one of the design goals was to keep things working well for people who are already familiar with the system... something that doesn't always happen these days.)
One thing they found was that it's important to keep some user interface elements always visible.
As it happens, before Windows 95, if you minimized an application, it ended up as an icon on the desktop... which was also still missing everything else modern variants have on it (shortcuts, folders, etc.). The minimized programs still weren't drastically hard to find though... or at least that's what designers thought before looking at experimental results. As it turns out, especially new users had real trouble finding apps after minimizing them, so they kept re-opening them. (In a world where the recommended computer configuration had 8MB of RAM, this is perhaps not the best idea.)
A lot of what was introduced in Windows 95 and has been around ever since is a solution to this problem. For example, the taskbar is always on top by default so that if you minimize something you can see exactly where it went and that it is still there and running. Likewise, the Start menu is there so that you can always find where to look for launchable programs.
(Internet Archive happens to have a ton of Windows 3.1 apps runnable in the browser; they load in seconds & you can also try out said minimization behavior.)
We could now launch into a discussion on how modern UI design forgot about a lot of this. Instead, we now turn our attention towards a domain which misses this not because it's too new but because it's too old.
... the CLI again?
True Unix users have only command line shell windows open alongside with, possibly, a browser. The browser is there because it was forced upon them. A True Unix user always tries to use the command line first.
There are variants, of course. A True Emacs user does everything in Emacs. It is a lot faster to either use the command line or fancy Emacs key combos compared to clicking on things, right?
Now, this is technically true. Here is the point of this post though:
GUIs that you can see without actively imagining them have benefits to even users who are very experienced computer users.
First of all, for things that you do sometimes but not especially often, it's a lot less mental effort to find a thing to click on, even if this is something you have set up for yourself earlier. You can definitely dig it up from the command line, but it takes some time. (Also, I'm sometimes surprised by the number of Emacs keybindings I have set up once and proceeded with never using them.)
There is also the question of even knowing what the possible actions are. Yet again, these could be things set up earlier by yourself. For example, if you open up your computer and it has a "write new blog post" icon, you are somewhat more likely to consider writing a new blog post versus if you have to look up a certain directory and invoke a certain command to start editing something.
It's not that it's impossible, it's that "visibility" might make the difference between you doing it because it's there or not doing it because it's not.
Modern computing makes it surprisingly hard to build quick UIs for things like this. Nevertheless, just like with bookmarks, there are surprising relics from the past that are fun to use.
For example, the Windows desktop.
Some examples
You can put browser bookmarks on your desktop.
You can also connect to servers via SSH! If you're using PuTTY, you can pre-configure connections which you can just invoke with a shortcut.
Also... blogposts.
The first one uses emacsclient to open the blog post directory; I now have sufficient training to just hit "P" for a new post once there. The command line is something like
c:\Program Files\Emacs\bin\emacsclientw.exe -n "/plink:the-dev-server::/the-path/to/posts"
(Still unsure of the usefulness of this; I just put this icon there.) Meanwhile... the other two are great and in use already.
"Update RSS" calls the RSS generator via SSH (same PuTTY settings); no password needed because Kerberos (people who don't find enough joy in seeing "Unspecified GSS Failure"s can do this using SSH authorized_hosts, too).
"Deploy" then rsyncs this up to the Actual VPS in the Cloud.