7 ms·

A CLI offers horrible discoverability compared to a UI where you can properly model UX. You can sorta approximate it with TUIs, but then you're basically buildi

by Tehnix 6y ago

A CLI offers horrible discoverability compared to a UI where you can properly model UX. You can sorta approximate it with TUIs, but then you're basically building a simplified UI anyways. I say this as someone that's a heavy CLI user, but I simply don't care to remember CLI options for anything I don't use a ton of times every day (like git). Just the AWS Lambda page in the AWS Console would take a whole bunch of CLI requests to even gather the basic information that's shown there, and that's ignoring you won't get the metrics visualization that'll tell you that your function every now and then has some outlier durations. My point being: UIs (GUIs) are not just for non-power users—they are indeed for power users as well.

anoncake 6y ago
There are plenty of GUIs less discoverable than a documented CLI with completion.
- notsuoh 6y ago
  Sure, but that doesn’t change the point I don’t think. By and large, regardless of the existence of what you’re saying, GUIs lead to greater discoverability.
  - anoncake 6y ago
    They simply don't. Good GUIs lead to better discovery.
    - adamisom 6y ago
      Pardon my potential ignorance here, but it seems to me a valid argument to simply say "if the GUI lets you search, that alone will probably make it more 'discoverable' than a CLI".
tejohnso 6y ago
Doesn't cli-tool --help cover discoverability in a more complete and formal way than a gui? Your AWS Lambda example seems to be about observability, which I agree is better suited to a gui.
capableweb 6y ago
I don't think that's true. Three ways that are de-facto standarized for CLIs for discoverability (where UI has almost no de-facto standards like this): - `man $program` - Usually shows EVERYTHING you can do with the tool - `$program --help` - shows a brief help with flags, parameters and commands - `$program $cmd --help` specific help for that command Most CLI tools implement these and most of everyone who is using a terminal daily knows about those three ways. In the GUI world, you sometimes have a "Help" link in the menu bar, that either opens a little widget or a web page. Nothing like man pages for GUIs.
- Jtsummers 6y ago
  It's frustrating, but people often seem to say "discoverable" when they mean "doesn't need a manual" or "intuitive". So CLIs that don't conform to standard patterns, or whose subcommands/options don't make intuitive sense would be "non-discoverable". But also, well-written manuals and usage/help screens are becoming increasingly rare these days. Technical writing is time consuming and people choose not to do it.
  - dgb23 6y ago
    Building GUIs is time consuming as well. I just don't think it is as common to find good technical writers instead of ui designers?
    - xfitm3 6y ago
      I'd say its less common for a project to have budget for a technical writer. I think there are plenty of people who have stellar writing ability, it's just nobody is willing to pay for it. I remember back when I ran Ironport appliances it came with a giant manual - maybe 1000 pages. It was very well written, had CLI excerpts, explained theory, etc. It was amazing.
      - Jtsummers 6y ago
        Companies see things like admins, technical writers, configuration management as excess. Technology today has reduced the need for these specialist-but-not-core-to-the-business roles. So the work is increasingly piled on the specialist in other fields rather than being a specialist position of its own. "I'm not paid to write manuals" is a common refrain in places I've been. The developer wants to write the code, maybe write the spec and design document. But they have no interest in writing the manual because "it's not my job." Only, today, it is their job because their employers (contrary to last century) don't employ writers on staff and contracting for fast changing documentation to keep up with fast changing systems isn't worth the effort. So it's up to the dev. Same with many other tasks. There have been some really good articles about the impact on professions like professors, teachers, doctors and others as their workload has increased. Why? Because technology has reduced each individual task to something small, but cumulatively it's drowning them (and us). Something has to give. The shifted work makes sense until you look at the aggregate impact. In the case of doctors, they have little they can avoid doing so they just drown in work. Teachers are made to work 12-16 hour days during the school year. But we, the programmers, get to skimp on these things (and hurt our users) because it hasn't yet hurt our bottom-line or cost any lives (safety critical systems still do a better job here out of necessity).
oftenwrong 6y ago
CLI discoverability is much better when the utility has good support for completion. For example, kubectl, which can output its own completion script for different shells, and can complete things like resource names. I don't know much about how shell completion actually works, but I do appreciate it greatly.
prionassembly 6y ago
Yes, but then you make aliases. If my .flotsam_and_jetsam file gets lost, I don't think I know how to use a computer anymore.
- selfhoster11 6y ago
  That's why you check it into a Git repo. Right?
marsrover 6y ago
I disagree. I find both the Azure and AWS CLI more discoverable than their web UIs.
2easy 6y ago
Yeah, I agree. Nothing beats google search and Stack overflow. If you has something later let that in the console it might be very nice indeed. `cloud-tool -h expand volume on pod` which would return examples, maybe even suggest ones based on your setup/configuration.
1vuio0pswjnm7 6y ago
This comment sounds like a criticism of the way AWS is designed, not the concept of the CLI. As someone who prefers CLI to GUI and works exclusively in CLI, I find the AWS CLI offerings no better than a GUI. AWS is a big ball of mud that keeps getting bigger. Commercial success does not change that fact. Perhaps the point of starting with a CLI first instead of a GUI is that it creates limits, it favours simplicity and creativity. If you find yourself creating dozens of single-purpose utlities or one utility with dozens of options, then maybe you are doing something wrong. Rather than looking to AWS as a model, why not look at something non-commercial, like djb's software or Wireguard. There is "power" in keeping a CLI simple.
- marta_morena_28 6y ago
  There are probably alternative market segments for your approach. The AWS CLI is generated from the API, not the GUI. That is not CLI first either, but it follows the GIT approach of the CLI being effectively an API. AWS is big and it keeps getting bigger. However that is not an argument for simplification. AWS does not add features because they don't know what else to do. They add all these features because they fulfill customer demand. Yes, you can come up with a dumbed down version of a cloud and wrap it in a beautiful CLI first approach. This might even work, you know, until people start picking up on it, feature requests come in... And then you are faced with either sticking to your original mission and serving a niche market, or breaking your promise for the potential gains in expanding your market share. By building a CLI first approach, you need to be very good at positioning yourself in the market and picking the untapped potential. At either side, there be dragons and if profitability gets the better of you, that might very well be end of it. I would rather have a CLI that wraps AWS or in general existing clouds behind a simple, friendly interface for common use cases. But of course you can't earn money with that.
ignoramous 6y ago
> My point being: UIs (GUIs) are not just for non-power users—they are indeed for power users as well. Hear hear. GitLab has ably demonstrated that their business model works and isn't replicable by hyper-clouds mostly due to making sure the UI is the differentiator (selling it at a premium) and not the APIs (in Micro's case, the CLI) [0]. Micro may want to focus back again on the UI, given they are more or less in the same domain (open-core devtools). [0] https://www.heavybit.com/library/video/commercial-open-source-business-strategies/ https://www.heavybit.com/library/video/commercial-open-sourc...
zokier 6y ago
Ultimately GUI vs CLI is false dichotomy. GUI refers how information is represented to the user, and CLI refers how user interacts with the application. If not quite 100% orthogonal, they are two different aspects of the total UI, and there imho is plenty of room to go further and explore the space instead of fixating on some age-old patterns.

by Tehnix 6y ago

anoncake 6y ago

There are plenty of GUIs less discoverable than a documented CLI with completion.

notsuoh 6y ago
Sure, but that doesn’t change the point I don’t think. By and large, regardless of the existence of what you’re saying, GUIs lead to greater discoverability.
- anoncake 6y ago
  They simply don't. Good GUIs lead to better discovery.
  - adamisom 6y ago
    Pardon my potential ignorance here, but it seems to me a valid argument to simply say "if the GUI lets you search, that alone will probably make it more 'discoverable' than a CLI".

tejohnso 6y ago

Doesn't cli-tool --help cover discoverability in a more complete and formal way than a gui? Your AWS Lambda example seems to be about observability, which I agree is better suited to a gui.

capableweb 6y ago

I don't think that's true. Three ways that are de-facto standarized for CLIs for discoverability (where UI has almost no de-facto standards like this): - `man $program` - Usually shows EVERYTHING you can do with the tool - `$program --help` - shows a brief help with flags, parameters and commands - `$program $cmd --help` specific help for that command Most CLI tools implement these and most of everyone who is using a terminal daily knows about those three ways. In the GUI world, you sometimes have a "Help" link in the menu bar, that either opens a little widget or a web page. Nothing like man pages for GUIs.

Jtsummers 6y ago
It's frustrating, but people often seem to say "discoverable" when they mean "doesn't need a manual" or "intuitive". So CLIs that don't conform to standard patterns, or whose subcommands/options don't make intuitive sense would be "non-discoverable". But also, well-written manuals and usage/help screens are becoming increasingly rare these days. Technical writing is time consuming and people choose not to do it.
- dgb23 6y ago
  Building GUIs is time consuming as well. I just don't think it is as common to find good technical writers instead of ui designers?
  - xfitm3 6y ago
    I'd say its less common for a project to have budget for a technical writer. I think there are plenty of people who have stellar writing ability, it's just nobody is willing to pay for it. I remember back when I ran Ironport appliances it came with a giant manual - maybe 1000 pages. It was very well written, had CLI excerpts, explained theory, etc. It was amazing.
    - Jtsummers 6y ago
      Companies see things like admins, technical writers, configuration management as excess. Technology today has reduced the need for these specialist-but-not-core-to-the-business roles. So the work is increasingly piled on the specialist in other fields rather than being a specialist position of its own. "I'm not paid to write manuals" is a common refrain in places I've been. The developer wants to write the code, maybe write the spec and design document. But they have no interest in writing the manual because "it's not my job." Only, today, it is their job because their employers (contrary to last century) don't employ writers on staff and contracting for fast changing documentation to keep up with fast changing systems isn't worth the effort. So it's up to the dev. Same with many other tasks. There have been some really good articles about the impact on professions like professors, teachers, doctors and others as their workload has increased. Why? Because technology has reduced each individual task to something small, but cumulatively it's drowning them (and us). Something has to give. The shifted work makes sense until you look at the aggregate impact. In the case of doctors, they have little they can avoid doing so they just drown in work. Teachers are made to work 12-16 hour days during the school year. But we, the programmers, get to skimp on these things (and hurt our users) because it hasn't yet hurt our bottom-line or cost any lives (safety critical systems still do a better job here out of necessity).

oftenwrong 6y ago

CLI discoverability is much better when the utility has good support for completion. For example, kubectl, which can output its own completion script for different shells, and can complete things like resource names. I don't know much about how shell completion actually works, but I do appreciate it greatly.

prionassembly 6y ago

Yes, but then you make aliases. If my .flotsam_and_jetsam file gets lost, I don't think I know how to use a computer anymore.

selfhoster11 6y ago
That's why you check it into a Git repo. Right?

marsrover 6y ago

I disagree. I find both the Azure and AWS CLI more discoverable than their web UIs.

2easy 6y ago

Yeah, I agree. Nothing beats google search and Stack overflow. If you has something later let that in the console it might be very nice indeed. `cloud-tool -h expand volume on pod` which would return examples, maybe even suggest ones based on your setup/configuration.

1vuio0pswjnm7 6y ago

This comment sounds like a criticism of the way AWS is designed, not the concept of the CLI. As someone who prefers CLI to GUI and works exclusively in CLI, I find the AWS CLI offerings no better than a GUI. AWS is a big ball of mud that keeps getting bigger. Commercial success does not change that fact. Perhaps the point of starting with a CLI first instead of a GUI is that it creates limits, it favours simplicity and creativity. If you find yourself creating dozens of single-purpose utlities or one utility with dozens of options, then maybe you are doing something wrong. Rather than looking to AWS as a model, why not look at something non-commercial, like djb's software or Wireguard. There is "power" in keeping a CLI simple.

marta_morena_28 6y ago
There are probably alternative market segments for your approach. The AWS CLI is generated from the API, not the GUI. That is not CLI first either, but it follows the GIT approach of the CLI being effectively an API. AWS is big and it keeps getting bigger. However that is not an argument for simplification. AWS does not add features because they don't know what else to do. They add all these features because they fulfill customer demand. Yes, you can come up with a dumbed down version of a cloud and wrap it in a beautiful CLI first approach. This might even work, you know, until people start picking up on it, feature requests come in... And then you are faced with either sticking to your original mission and serving a niche market, or breaking your promise for the potential gains in expanding your market share. By building a CLI first approach, you need to be very good at positioning yourself in the market and picking the untapped potential. At either side, there be dragons and if profitability gets the better of you, that might very well be end of it. I would rather have a CLI that wraps AWS or in general existing clouds behind a simple, friendly interface for common use cases. But of course you can't earn money with that.

ignoramous 6y ago

> My point being: UIs (GUIs) are not just for non-power users—they are indeed for power users as well. Hear hear. GitLab has ably demonstrated that their business model works and isn't replicable by hyper-clouds mostly due to making sure the UI is the differentiator (selling it at a premium) and not the APIs (in Micro's case, the CLI) [0]. Micro may want to focus back again on the UI, given they are more or less in the same domain (open-core devtools). [0] https://www.heavybit.com/library/video/commercial-open-source-business-strategies/ https://www.heavybit.com/library/video/commercial-open-sourc...

zokier 6y ago

Ultimately GUI vs CLI is false dichotomy. GUI refers how information is represented to the user, and CLI refers how user interacts with the application. If not quite 100% orthogonal, they are two different aspects of the total UI, and there imho is plenty of room to go further and explore the space instead of fixating on some age-old patterns.