4 ms·
I think what a lot of GUI's fail to do is to just get out of the way when it's failing to accomplish whatever task is at hand. You don't have the problem with C
by kadenshep 9y ago
I think what a lot of GUI's fail to do is to just get out of the way when it's failing to accomplish whatever task is at hand. You don't have the problem with CLI's most of the time because you probably have to implicitly compose commands to achieve the same thing the GUI might do in a single click.
A button might kick off a set of tasks and aggregate the output into a final success message. If it doesn't work there's almost no way to dig into what's going on or even attempt to get the program to an acceptable state with whatever data you're working with.
A CLI might have an analogous command that also kicks off a set of tasks but if it breaks/doesn't work and assuming the CLI is following a unixy model, you can run through specific commands diagnosing the issue or at the very least get to an acceptable state in your workflow that leaves you with a few options to work with.
Any GUI, in my opinion, should just be a visual abstraction from a set of executable tasks that can be run individually. Take something like Github's Desktop client. In yester-years, when it first came out, it was pretty bad at handling git rebasing operations. But because of the way git was built and used most of the time, the Desktop client actually just called into the gitlib API or even just straight up wrapped git commands. If something broke, just like rebasing, I could actually take to the command line, inspect the state of the repository, and continue with rebasing via the vanilla git commands. And even then, when a git command doesn't act right, it might actually just be a wrapper around other more internal commands that you can execute yourself (i.e., git pull is actually analogous to git fetch; git merge origin/*). Compare this to a TFS error I've been getting for a few months on a legacy repository, with little to no information across application and system logs, and almost no information via google: "Provided parameter is not valid." Neat.
I wish the described "composable application" if you will was just a standard across every application. Even in web applications I build I make sure there are "steps" in data processing instead of just monolithic operations. I take care to make sure steps can be kicked off individually with sane output. It seems like we lost this philosophy along the way across every level of application development and the linux ecosystem hasn't been immune from this in my experience. Windows has never really stepped foot in those waters until recently with PS. But most of the time, in my experience, we get GUI's with no recourse. If it breaks you just might be out of luck until a patch comes in or you can interact with the data yourself.
Maybe one day if a program (even a web app!) doesn't provide a set of clean commands to run we'd look at it like we do a badly designed GUI, with disdain and disgust.