Hacker News Reader

Comment by yawpitch | Hacker News Reader

On what basis do we believe GUIs are more accessible? Merely because that’s the default that’s been demonstrated to us? Thinking broadly about accessibility (so including those with sight issues and mechanical impediments like, for example, Hawking had) I’m not sure we’ve got any solid reason to believe a GUI is inherently more accessible.

I’m also not sure that a less social but more democratic system beats a less democratic but more social one, given that we can train people to script CLIs, giving them the socially sourced empowering the piece is speaking to, but we can’t train people to automate and scale up their GUI work in the same manner.

View on HN

Nearly all existing CLIs are much harder to use than GUIs, regardless of what technical possibilities exist.

They will delete your stuff instead of trash it. You can run commands on the wrong folder or even the wrong machine easily, since you're not directly clicking on objects. The context of where you are and what you're doing has to be all in your head.

Even with autocomplete there's a lot of typing involved. If you're not a touch typist, it's a real slog to type that much literally all day, and can even make your eyes and neck tired from glancing back and forth to the keyboard so many times.

If you customize any of this behavior, it doesn't look any different, you can't tell at a glance what's in bashrc.

It's great for scripting, if you do anything that needs to be scripted and also doesn't already exist as a prepackaged workflow in a gui, but there's a lot of stuff where it's rather difficult.

GUIs also could be perfectly well scriptable, we could have some futuristic UI where everything was an auto generated UI around drag and drop script blocks or something.

Knowing where you are in the file browser window is still in your head, it’s just because you’ve clicked from the desktop to the folder to the sub-folder that you’re aware of the current context… sure, it might be configured to display the cwd in a status line or title bar or what have you, but so does a well configured CLI. And sure, a CLI app can just delete stuff without interaction, but so could a GUI, it’s just that one’s be kept default unsafe and the other default safe because of the expected average user… if everyone was always going to be introduced to CLI/TUI first then those default safety features would be there too. What the GUI can never do well is work with things outside the CWD, and while GUIs could be scriptable, they almost never are. I wish they were, I would love to see GUIs be as inherently capable of the social effects the post is speaking to as CLIs, with a shareable artifact of your interaction, but there seem to be incentives that keep that from happening.

Honestly I don’t see there’s any reason we don’t introduce both modes to every user. Where they want to be able to do repeatable and shareable they should have that option, and where they want to click around they should have that… but until GUI frameworks are scriptable by default, with some embedded scripting language (don’t care which) that’s ubiquitously present in every window even if the writer of the app knows nothing about it, then we should be empowering users by showing them the things CLIs are inherently better at.

My guess is the work necessary to make CLIs more ergonomic is smaller than the work needed to make GUIs more scriptable, but I could be wrong.

In the GUI, the file manager always shows you the folder contents, often with thumbnails.

Making the CLI safe at this point would cause issues people might be less careful on systems without the safe configuration.

There's a ton of possibilities with the CLI, but the more you configure it, the more nonstandard stuff you have to learn and remember the differences when you SSH into some other machine...

I think it would be fairly easy to create a GUI framework for everything an average user would want to script, that isn't already covered by a GUI app, with some kind of package manager for CLI-to-drag-and-drop bindings, but it doesn't seem like anyone has done it, at least not in a FOSS form that got traction.

> What the GUI can never do well is work with things outside the CWD

This I believe you. (My idea of operating system design does not have directory structures, though.)

> Honestly I don’t see there’s any reason we don’t introduce both modes to every user.

I think it is a good idea, although good documentation will help with both modes.

> but until GUI frameworks are scriptable by default, with some embedded scripting language (don’t care which) that’s ubiquitously present in every window even if the writer of the app knows nothing about it

My idea of operating system design involves: Although the GUI windows themself do not have a scripting language, command-line windows use a scripting language called "Command, Automation, and Query Language", and can interact with all windows in the system, even if the writer of the app knows nothing about it (although if they do know about it, that can help too). (The combination of the widget library with the security model of the operating system also has a side effect of allowing GUI interactions to be recorded as well.)

> My guess is the work necessary to make CLIs more ergonomic is smaller than the work needed to make GUIs more scriptable, but I could be wrong.

I don't know, although it is helpful to do both, since CLIs and GUIs are both useful.

> Nearly all existing CLIs are much harder to use than GUIs.

Software would tend to be easier to understand if it is better documented; GUIs aren't inherently easier. If the computer display specifies what is expected then a CLI might be easier to understand, and documentation also makes it easier.

However, what is easier for one user might also depend on what they are familiar with. Someone familiar with a specific kind of CLI or GUI might be able to more easily understand that. I will find it easier to use an unfamiliar computer if it has a command-line interface that I can understand, rather than the GUI.

> They will delete your stuff instead of trash it.

Yes, although it is not really an inherent issue of CLI vs GUI, but of specific implementations.

> You can run commands on the wrong folder or even the wrong machine easily, since you're not directly clicking on objects.

I think this is not legitimate. A CLI and GUI will both have to display such things in order to know which folder/machine/objects/etc you want, and at least bash already does display these things (and I would expect that a good quality GUI should also do), so it does not have to be "all in your head".

> Even with autocomplete there's a lot of typing involved. If you're not a touch typist, it's a real slog to type that much literally all day, and can even make your eyes and neck tired from glancing back and forth to the keyboard so many times.

This is legitimate. However, people who intend to operate a computer a lot, should learn typing if they can.

> If you customize any of this behavior, it doesn't look any different, you can't tell at a glance what's in bashrc.

It depends on the specific customization. If you modify the prompt then it will look like differently. Customizations are still useful whether it looks different or not. (You can also make other changes to the looks, e.g. changing the font size, which are not a part of bash and are a part of the terminal emulator (or display settings, if the operating system you use handles them like that instead) so would be configured separately.)

> GUIs also could be perfectly well scriptable, we could have some futuristic UI where everything was an auto generated UI around drag and drop script blocks or something.

I have another idea, which is similar in some ways but is different. You could copy objects between the command-line and GUI in either direction, and program stuff in the command-line to trigger things in the GUI as well.

I think the lack of context and safety kind of is baked into CLI.

GUIs can be a guided experience, the documentation is in the UI itself. There's nothing external to look up, which greatly lowers your productivity unless you have an excellent memory and can do it once and still remember it months later.

CLIs in theory can be, but most things these days assume that you know exactly what you want to happen and the computer is a passive tool that does exactly what you say.

Technically rm could ask for confirmation and then trash, but the confirmation step would get in the way of scripting. You could add a -y flag as some commands do, but if simplicity, scriptability, and maximum efficiency for power users are the goal, you probably won't.

On the GUI you can assume it's interactive, and the generally accepted way of design is to aim for the lowest common denominator, not power users.

GUIs can present unrelated information and make changes to the UI, some users will be annoyed but nothing will break, and those of us without a good sense of space will hardly notice if stuff is moved...

On the CLI as it currently ls and cd are separate actions and combining them would make lots of useless output in scripts. On the GUI, LS and CD are the same thing, double clicking a folder takes you to a new page and there's no such thing as "being in a folder" without the contents displayed.

Making a CLI as safe and discoverable as a GUI would involve reinventing half the entire ecosystem. Possible in theory, but then you'd be maintaining a bunch of stuff on your own, because CLI users seem to like the idea of computers as passive tools for computing, and there might not be much interest.

In my view CLI is "inherently" more abstract and requires a relatively deeper understanding of the system that is being interacted with. I honestly find it strange one needs to elaborate on this manifest fact: see all the unwashed happily tapping away on their smart phones.

Also we're not discussing "systems" rather interfaces. The system is invariant. Take OS X. I know few normies who even know what "terminal" is or what it means and on the other extreme, most of my fellow techies mainly interact with it via a terminal. It's the same system.

Training also indicates specialization. Arguably any endeavor requiring specialization is already anti-social, if we consider society in its widest sense.

Give me five minutes and I can get most of the unwashed to see that a Terminal window is not much different than a Finder window, for the tasks most of the unwashed are doing (browsing, finding, opening, maybe deleting, maybe moving). Sure, it’ll take me longer to get them up to speed on all the extra facilities the Terminal provides, but the mental model required for a Finder window and that required for a Terminal cwd aren’t a heck of a lot different, except that the latter can optionally do things outside its context.

Also training doesn’t have to be specialization… just like we do basic arithmetic and literacy and (mostly useless and often curated by people with agendas) history we could do basic directory navigation and associated operations, side by side, just to get everyone on the same page, going forward. Now suddenly everyone has access to the social value of sharing their interactions with machines.

Arguably this is what little value LLMs might actually provide, assuming we ever get to the point we can talk one into reliably performing some interaction with the OS for us, then capture that as an output we can share as well.

Reply on news.ycombinator.com