The article is a beast but there is a lot of good information in there. I find that I try to do as much as possible from the keys when I'm doing programming related tasks. An IDE like vscode is a good mix of UI and CLI for me.
That being said, I've been excited in the past seeing a new take on IDE's with things like LightTable (I'm not positive that's the name...) which have pushed the needle even further on the UI/CLI balance.
There's a ton of great info packed into this article. It's definitely been a struggle over the years to find a balance between when to prioritize CLI over UI development for Cloud services, but I think they arrived at a sweet spot when it comes to building complementary experiences that help one out where it is most appropriate.
I used to work on a product UI that provided the equivalent CLI command for every action you perform in the UI. Use the UI to learn the CLI - complementary experience.
Kind of a turn-off that it jumps immediately from CLI to web UI, without even considering native UI. Macintosh developers worked quite effectively for almost two decades without any sort of standard, out-of-the-box command line environment; sure some used Macintosh Programmer’s Workshop, but the vast majority lived in IDEs like THINK Lightspeed Pascal and C (later Symantec THINK Pascal and C) and Metrowerks CodeWarrior, and were extremely satisfied with their experience.
I always feel like CLI is for power user's for people that already know what they are trying to accomplish and want to batch together scripts to do it. A UI is better for beginner user's to become familiar with a products functioning.
From a design perspective I feel like the CLI is far too often forgotten.
That was a well written and entertaining article. A bit long for my taste and I feel like it could have been said in fewer words, but like I mentioned, it was entertaining.
What this makes me wonder is how much effort should go into each User Interface. You describe a web GUI (in this domain) to be a good place for people to learn about something new and maybe kick the tires. It can also speed up their interactions via visual tricks. However, you mention that productive, at scale, and "more money" use occurs more in the CLI. Does that mean companies should make their UI better at educating the CLI and worry less about doing things in it and make the CLI be the encouraged primary form of "Doing"?
On top of that, making a GUI requires front end/backend development, UX, visual, research, and a whole lot of time while a CLI requires UX (maybe) and backend development and is overall simpler. I feel like the positives and negatives described in this article don't really support making a UI do anything more than discovery and education on the CLI. And CLI are finally attempting UX improvements like your example from Yeoman. They are taking the best bits from the Usability of GUI (color, shapes, iconography, recommendations, etc)and putting them in the CLI. Does that diminish the relevance beyond education and marketing of a GUI in this domain even further?
Definitely back-end and it is exciting to see all that UX is bringing to CLIs, but relative to a full front end GUI it is much more straight forward. (Not to discount the hard work CLI developers do since it is still plenty complex)
9 comments
[ 4.4 ms ] story [ 36.9 ms ] threadThat being said, I've been excited in the past seeing a new take on IDE's with things like LightTable (I'm not positive that's the name...) which have pushed the needle even further on the UI/CLI balance.
Disclaimer: I work for IBM Cloud
From a design perspective I feel like the CLI is far too often forgotten.
What this makes me wonder is how much effort should go into each User Interface. You describe a web GUI (in this domain) to be a good place for people to learn about something new and maybe kick the tires. It can also speed up their interactions via visual tricks. However, you mention that productive, at scale, and "more money" use occurs more in the CLI. Does that mean companies should make their UI better at educating the CLI and worry less about doing things in it and make the CLI be the encouraged primary form of "Doing"?
On top of that, making a GUI requires front end/backend development, UX, visual, research, and a whole lot of time while a CLI requires UX (maybe) and backend development and is overall simpler. I feel like the positives and negatives described in this article don't really support making a UI do anything more than discovery and education on the CLI. And CLI are finally attempting UX improvements like your example from Yeoman. They are taking the best bits from the Usability of GUI (color, shapes, iconography, recommendations, etc)and putting them in the CLI. Does that diminish the relevance beyond education and marketing of a GUI in this domain even further?
Doing a CLI also requires, at least, back-end development and research. Doing a decent one requires a tremendous focus on UX.