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.
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.
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.
Good points, especially about the lack of documentation. Regardless of the type of interface, people need references to go with them.
Discoverability can mean more than discovering features of the app too. To me, I think more about discovering information contained within it, seeing things I wouldn't have noticed in a command line experience. In a complex system like server automation, there's actually a lot of potential value in GUIs making it easier to see correlations between things or notice problems or discrepancies before they become bigger issues.
I've been a command line-first user since the 90's, but I would hesitate to recommend this over other solutions specifically because of the lack of GUI.
Apple did something like this with A/UX back in the day (their variant of Unix which apple sold for its 68k machines). https://en.wikipedia.org/wiki/A/UX The tool that did this was called Commando; I'm not sure if it was hand-crafted, or automatic.
A huge part of the problem is that `man` pages really are only softly standardized, and just, commandline options in general are just softly standardized. They don't all obey the same rules for spaces, capitalization, usage of dashes, etc - they're close, but it's far from consistent.
What we ought to have done at some point, would have been to rebuild the whole suite of commandline utils - to make them all do an ironclad standard, and probably even make them all spit out a totally normalized data format like JSON, man pages included, so that external tools could be built around them way easier without everyone having to write their own parser (or - having to write a generalized parser with tons of 'special-case exemptions' for all the CLI tools that break the rules).
There have been several attempts, but nobody's been willing to do the big "rip off the bandaid" and take the pain of breaking legacy scripts.
We have had automated GUIs generated for command line utilities since PowerShell 2:
PS C:\> show-command get-childitem
will popup a GUI form for all the options get-childitem takes. It's basically useless because it's a dump of all available parameters. At least they're in alphabetical order, but there's no hint which ones you might want or not want.
Not sure it'd be trivial unless the documentation is really good. I have, however, seen TCL used to good effect of GUIfying a CLI, and providing a scriptable interface so that you can access features that don't translate well to the GUI or (for whatever reason) haven't been made directly accessible in the GUI.
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.
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).
Don't forget `-h` "chastise me for not using --help, and don't show the help".
and `-h` print "usage: $program [TBhrRtzFwbvjEBUQ]"
This is assuming all the commands are in one binary, and you know what the binary is (compare 'yum install' and 'yum search' with 'apt-get install' vs 'apt-cache search').
> Most CLI tools implement these
Most? You can see there's a big competing pattern of having multiple binaries with the same prefix like ssh ssh-agent ssh-keygen, dbus-FOO dpkg-FOO apt-FOO snmpFOO ldapFOO.
And there are plenty which don't have this "clearly delineated sub-command" like git has.
> where [GUI] has almost no de-facto standards like this
The massive main de-facto standard a GUI has is showing you important things up front and hiding irrelevant and uncommon things away. With a CLI you see nothing until you --help then you see everything. There's no indication of what's a common path through the tool.
It's not showing options in alphabetical order. Am I to infer that "-sigopt nm:v" is more common, more used, more important, than "use SHA1" because it's higher up in the list? If not, why is it higher up in the list?
Hamburger menu? Right-click on a thing to show you a context menu of things you can do with a thing? A central content area with "tabbed sections" along the top (real tabs or links like a menu bar)? Mouse hover-and-pause tooltip? "select an item and press F1 for help"? Have a username link or avatar picture behind which your user-specific options are? Are these not large and common "de-facto standards" in GUIs?
> You can see there's a big competing pattern of having multiple binaries with the same prefix
One could create an entire ecology of tools that operates as a sort of compromise: Have a family of separate programs named with a common prefix (e.g., foo-), and a dispatch program (foo) that, when run like
foo bar options
dispatches to foo-bar with the options, and when run like
foo [-h|--help]
prints a help message and then lists every foo- program on the PATH, incorporating the whatis output where available. (That last bit requires man pages to work, but you can't very well tell people to read a manual that doesn't exist.)
I have used this strategy at work with considerable success.
I'm a big CLI user, but my primary gripe with these sorts of interfaces vs a GUI is when they have a huge number of nested sub commands. I often find myself searching through the tree of possibilities running --help on every single level just to do something simple. Especially if what I'm trying to do may exist in disparate sub commands. With a web interface there'd likely be some kind of nested menu or dropdowns that offer more of a sense of the overall arrangement at a glance.
I'm always happy to have access to the CLI to be able to script things, but if it's the only interface to a service with many features it can be awfully cumbersome.
Sometimes with these deeply nested do-it-all CLIs I feel like I'm playing a text adventure trying to navigate a maze, constantly typing /look and /examine. Often these tools have so many sub commands that a man page is not helpful if it exists at all.
The best CLIs are interactive. Try a Cisco console. At any point they have a limited search space and you can just type "?" to get autocompletion for what you're doing. Everything is hierarchical and very discoverable. You can negate things with "no" to unset properties and such.
Even zsh with various plugins or fish feel rather primitive in comparison.
I typically write bash wrappers in situations like that. You could also write in a real programming language that shells out to the CLI tool if it gets too complicated.. even better if there's a library that does away with the need of shelling out.
Hah, `man aws` prints `No manual entry for aws`. You can of course dig around the help pages for each individual subcommand, but it doesn't give a very good idea about how the resources stitch together. More importantly, you miss out on the wizard-like behavior for spinning up new resources without needing to provide a reference to each upstream resource (the GUI can create these upstream resources for you or let you bring your own depending on how you navigate the creation wizard). I'm sure this is all possible with a sufficiently well-designed CLI (`eksctl` does this for EKS), but no such CLI exists for AWS holistically and these are pretty rare for any kind of application.
Also, personally I really dislike man pages--paging through tons and tons of text that has nothing to do with my use case to find the one or two bits that are actually relevant is not really my idea of a good time. They are the most flat-footed solution to the discoverability problem, but they leave a lot to be desired.
To be clear, my comment was about using `/<search term>`, not manually paging. It's still a very unpleasant experience. If you're interested in a particular concept, but you're not sure what your program calls it, good luck. Even if you're looking for a particular flag (e.g., `-c`) you can have hundreds of search results to parse through depending on the size of the man page. I personally don't enjoy this experience.
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.
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.
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.
> 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).
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.
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.
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.
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".
If you want adoption CLI only is a not a great choice. 90% of the developers and IT staff I work with are GUI only. A CLI only also means you need great documentation, still people won't read it and constantly ask for a GUI for simple things. Finally for those pointy hair bosses a CLI only service is hard to sign a check for, since they can't really "see it" even if you send a great invoice.
Hey (Micro Author and CEO here). I hear you. GUI is a thing that's hard to break away from with the point and click crowd. This is where "IT" people and old school sysadmins becoming devops people likely thrive with the AWS dashboard, but considering most devs are writing code and use Git we think the CLI first approach is really key.
To this point when we do anything on the web it will start purely as a CLI at m3o.com/cli and replicate the existing terminal experience, but maybe with some messaging like component so you can have nice emojis, rendering screenshots for graphs, etc.
When it comes to cheque signing (6-9 figure deals) from the people with the money, I'm sure at that point we'll have to do something to win them over but we're a long ways from it right now.
This looks really cool! Personally, I'd use it---web interfaces are getting increasingly annoying these days.
But do you have plans to release libraries for your API in major languages? Stringing together a bunch of shell commands in a bash script is also a little bit annoying... or at least much less friendly than doing the same thing with, say, a Python lib...
Thanks! Yes, so the CLI is the main consumption experience but Micro is geared towards services development, meaning we provide a Framework, CLI and Server that all work together. The CLI is mostly just proxying commands via a gRPC server and the entire thing is written in Go so everything we do in the CLI you can use the Framework to do in code. We also generate multi-language clients. Check out the 3.0 release announcement for more info https://micro.mu/blog/2020/11/05/micro-v3-aka-m3o.html
> 90% of the developers and IT staff I work with are GUI only.
That's terrible - especially the part about the boss who cares more about toys than productivity and delivery. I hope you can find a way to demonstrate your skills to a talented team who in turn can offer sane working conditions.
> the boss who cares more about toys than productivity and delivery.
It is terrible, but very common in my experience. It is the success recipe for Apple to a large degree.
Software houses are something different, but if you change to another industry as inhouse dev, the priorities change drastically. It has advantages and disadvantages, but in industry jobs outside of software people just cannot really evaluate the quality of your work. It just needs to look shiny to a degree.
I don't think it's an issue of talent. But a preference for GUIs often hampers people and the work they support. You can't compose GUIs like you can CLIs, and that's important as your workflows become more complex and need to involve more things. You can either extend the GUI (Hah! only if you own it or it's open source) or develop manual processes, or use tools that can automate GUIs but tend to be fragile.
That is terrible. As a "boss" of an SRE team, we only use the GUI for groking, testing (in a sandbox account), and for a handful of _documented_ things that have to be done in the GUI (usually account wide settings). Everything else, in every "real" environment is in source control, we use Terraform.
> 90% of the developers and IT staff I work with are GUI only.
That's weird to me, but I'm in the embedded space. GUIs aren't scriptable (or aren't easily scriptable) which, for me and the teams I've been in, has basically been a no-go. If we can't script it, we can't automate it (easily), so we don't want to use it. A GUI + (good) CLI is a reasonable compromise. GUI helps us do some things, explore the tools/space, and then the CLI for all our automation.
> Finally for those pointy hair bosses a CLI only service is hard to sign a check for, since they can't really "see it" even if you send a great invoice.
Again, weird to me. But also still the embedded space. We buy tools with no GUI (or an awful one, but a decent CLI) all the time.
I love cli, absolutely love using it whenever I can. But I totally agree with you. A lot of my own team (including great developers or technically competent people) prefers GUI and I was always surprised at that but I have given up fighting that battle trying to get everyone to stick to CLI as much as possible :). There must be a reason why people prefer GUI even though cli freaks like me don't get it.
This isn't the "fault" of CLI itself so much as bad documentation, but for Azure at least it's sometimes difficult if not impossible to find the insane CLI command which corresponds to a fairly basic operation in the GUI. So even though I'm very much a CLI person I frequently find myself in the Azure GUI, just because there's no other way to get stuff done.
I think guis are more useful for things you don't do everyday.
I'm a cli junkie, but if I'm only going to do something every 6 months, it's not worth the mental effort to remember. I could be using that mental energy for learning obscure git subcommands and trying to shoehorn them into random situations I find myself in.
As a general followup observation, if you're building a system, that's probably a sign you're not your primary customer. The fact that you want a CLI-only SaaS is unlikely to be a good measure of what your potential customers want.
Something to keep in mind when you eventually _do_ launch a GUI is to make sure it and the CLI are using the same flows, concepts, etc. It can be really confusing to use a GUI that does things one way and a CLI that does thing a totally different way!
I think being CLI-first (and maybe API-first) is a really clever strategy. My gut feeling is that it’s much easier to get a CLI/API right than to get a GUI right. So you can just expose an API or a machine-parsable CLI, and let people who care enough to build their own wrapper GUIs the way they want.
Whenever I make a desktop application, this has been my strategy and it's usually been effective. Create a library for the core logic and various CLIs using the library to expose functionality (also helpful for creating automated tests of larger chunks of functionality). Then create a GUI that essentially wraps those same features in a pretty presentation and (hopefully) intuitive interface.
Not everyone has liked my approach, though. And some managers have scrapped it even though the users (usually these are internal tools, so our teammates) liked it.
Another advantage of this style is that, for me at least, I tend to get a better design out of the system which makes that "library" portion more reusable. In theory, that CLI tool can become a GUI or become a server application as well without having to change the core code. But many people (and I sometimes fall victim to this as well) when making a GUI integrate the business logic too tightly with the GUI code (the same with web services). Something about making a CLI makes it easier for me and many people I've worked with to make a clearer delineation between the core logic and the interface logic. Perhaps because we know the CLI isn't the final or only presentation.
The main appeal of Command-Line Interfaces is repeatability. GUIs are hard or impossible to script, but CLI commands can be followed, typed in or copy-pasta'd.
The main appeal of RESTful interfaces is discoverability and semantic CRUD conventions. Now if only I could remember the CLI arguments to `curl`...
A potential advantage of using just a CLI would be that you could use SSH authentication, with public key cryptography. It would be much more secure, especially for a VPS provider, where if your SSH key gets cracked it's game over anyway, so that the password is only an additional security risk.
I think the post has some valid points, developing front-end dashboards nowadays is a pretty big undertaking and if your userbase doesn't require it, why would you?
I can see some future expansion into the webspace as a premium feature like serverless.com does.
Thanks! Author here. I believe that's the key takeaway, knowing your audience and being able to do things that are perhaps controversial. In our case, it's also focusing on our strength while we are such a small team. Being mostly backend devs (although many of us launched products where we did the full stack) CLI is in our DNA.
We believe if the product and experience is not compelling enough, having a shiny GUI won't help. Then why waste the effort instead of making our core proposition stellar?
I totally disagree. Heroku CLI is a mess, the API is not much bette - neither are consistent with the web app, including missing ability to perform manifest based deployments!
Im sure if you are doing trivial stuff, its adequate, but its really poor IMHO.
It is a bit offputting that the install script expects sudo rights just to copy a file from a user-readable directory to a user-writeable directory.
That is literally the only place where sudo is used, so it should be removed. (After removing it myself, everything still set up okay -- not a surprise.)
This is really interesting. I happen to dislike GUIs wherever it comes to any kind of software development. CLIs are just more programmatic, and I happen to be comfortable with programming. I've thought quite a bit about this while working on Pragma [0]. I think GUIs offered by BaaS (e.g. Firebase or Hasura) just aren't efficient compared to writing everything in files and using Git and my favorite text editor to work with it.
Azure CLI works great and you can do everything with it. Often times, especially with new features, they go CLI first and then slowly migrate things into the GUI.
On the other hand, Azure GUI is way faster for me to get stuff done in as a casual user, and if they didn't have a GUI I doubt many people would use Azure.
This is awesome seeing a paas optimize for expert users before planning how to expose those features more broadly. I hope their documentation follows suit!
This is awesome and I think the point here missed is that the audience of this PaaS are experts who do not have a hard time with a CLI. I personally would not hire a Devops person who could not navigate a CLI but I am not experienced in HR either. Great job.
Is this go only? I don't have numbers but I rarely see go backends, I wonder if the market your addressing exists / is big enough.
Going CLI is an interesting concept!
Having a gui is useful when you're dealing with different services and you don't have the muscle memory to do some operations quickly.
It's easier to get something out of aws-cli than that horribly complicated frontend.
Npm is somewhere in between: some operations are easier from the cli, other from the GUI.
Digital ocean has a snappy and simple ui, I don't miss a cli.
I would go with both and hire a frontender - even for cheap: just HTML can be another hill to die on.
IMO this is a great strategy to get off the ground.
Eventually, I don't think you'll be able to get around offering a web GUI because if you don't somebody else will build one for you (around your CLI tooling).
I've seen auto-generated passwords break bash and powershell alike. Please include a way to bind variables to something not parsed as process arguments - such as a pointer to a env var, Azure KeyVault key, AWS SSM key or just the raw contents of a file.
Watch out for template expansion hell. Azure DevOps provide multiple types of variable expansion: macro, template expression and runtime - this helps but has it's own limits.
Also I found arg forwarding with '-' with node cli tools
rather powerful lately.
I didn't find any way to try or register from Android. I mean, it looks like a blog ? I was able to click on the Github logo then to the link to your home page. But the menu 'explore' doesn't work for me..
Yet something else that I definitely need to try out as soon as possible. I generally don't like leaving the CLI, so this seems like it could work great for me.
I wouldn't count Amazon screwing up UX against CLI tools. More a testament to Amazon and their inability to successfully implement good UX in both GUIs, webpages and CLIs.
This is the question that needed to be asked. What are the people building production with your PaaS going to use?
First and foremost, infra engineers use generally one tool to build their Infrastructure as Code (Terraform, Pulumi, Ansible, Puppet, etc). This is the heart of their deploys and whatnot, so they need robust tools that integrate with all the different services they use, handle deployment complexities, etc.
Second they use a [web] GUI. If you want to prototype something or throw together a quick MVP, you don't spend a week fidgeting with a console, you open a GUI and just make it work. If developers have access, they can prototype things very quickly. I also tend to then use Terraformer to spit out HCL for what I've created in the GUI, so I don't have to spend hours/days fucking around with making Terraform modules just to reproduce what I did in 5 minutes in the GUI. (hey, CLI writers: please don't intentionally make your tool a fucking pain in the ass just so your company can make more money off of consulting or whatever your excuse is, because now I resent your company for making my life harder rather than easier)
Next comes CLIs. Why are they third? Because you're not using them to prototype (see above) and you'd be using your all-in-one tool for long-lived IaC. The CLIs are used for quick hacks and investigations and the like. And of course they're all different, and most of their UXs suck, because the designers of them apparently have never used GNU tools before.
Finally come the APIs when nothing else works. Typically scripting something with bash and curl, or Python, Ruby or Node.js for those who aren't console cowboys.
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.