Real developers don't use UIs
August 13, 2018
Notes and comments on this article by Micah Linnemeier.
At first glance, CLIs appear to be worse than UIs in almost every way.
|Where is the input entered?||Command prompt only||Web or app|
|Accepts input as||Files and text||anything|
|Presents information to users||Files and text||anything (images for example)|
|Produces output for further processing as||Files and text||files|
If this perspective is real then…
Why haven’t UIs killed off CLIs
CLIs are more widely available
- They use fewer resources and have fewer dependencies so can be more easily installed on any machine.
- They work in low latency environments.
- They have reduced security attack surface.
- They sometimes come pre-installed on many many OSes.
CLIs are automatable
It’s easy to create repeatable processes with CLIs. That’s why they make good tools for actioning deployments.
CLIs are more easy to share
If I have a series of CLI commands I can share them directly with someone else who has the same CLI installed and they can run them. It’s more difficult to share instructions for repeating a process on a UI.
CLIs are composable
Because all CLIs share the same input and output formats (text and files), they can be composed into chains of operations.
CLIs are faster
CLIs have a simpler rendering process and can be faster than CLIs for that reason.
Some of the comments in this section are misguided in modern situations.
Where CLIs typically request only raw data from the server, web UIs must transfer not only raw data but also presentation information
Less true these days in the world of JSON APIs.
CLI commands typically only hit one server endpoint once. Web UIs often request resources which then request their own resources, which then request their own resources
Not sure about this one. This is a problem typically caused by religious REST implementation and Hateos.
GET /projects returns a list of project IDs and the client must then traverse the list and hit 50 different
GET /projects/:id endpoints in order to be able to render the page. Both CLIs and GUIs can succumb to this issue.
CLIs can also be more friendly to advanced users who can cut their usage down to a small set of specific commands that they need to run. The clicking around on a UI is a bit more winding.
CLIs make remote systems feel local
Using UIs across a slow network is horrible. This is a common issue when dealing with internal tools in the enterprise where there may be multiple jump boxes between the GUI and the data.
Where are GUIs better?
GUIs can leverage signifiers
UIs can have tooltips, icons, popups and title attributes in order to pack more information into a smaller space. CLIs can just display flat text.
GUIs can use images to pack information
GUIs can take tabular information and turn it into images and graphics which make it more easy to consume. CLIs can output ASCII charts to perform some of the same functions but they can’t compete with the information density of a GUI. They also can’t do visual formats such as maps.
GUIs can display options
GUIs can show the user the options when they are constructing a command to execute in a way that completely flat CLIs struggle to do. For example, consider this command to create a VM on Digital Ocean:
doctl compute droplet create <name> --image <image-id> --size <size> --region <region> --ssh-keys <ssh-key-id> --wait
What are the available image IDs, sizes, regions and ssh key IDs? I can’t tell without running a number of other commands. I can’t hardcode because images may be deprecated at some point and thus I need to send multiple requests and write my own error handling code before I could use this CLI command in a production situation.
A UI can use select boxes or other controls to show the user what the options are.
Advanced CLIs can use auto-complete to do a similar thing but doing so will negate a number of the advantages of a CLI.
GUIs can offer more intuitive interaction
Think of Trello’s card dragging interaction. This simple idea changed the face of planning tools. This couldn’t have happened with a CLI.
It’s worth realizing that typing in a standard web form isn’t intuitive interaction of the type that really gels with the brain. Tapping and dragging are more representative of things we can actually do in the physical world.
GUIs can achieve superior performance in some tasks
Think of scrolling by flicking the Apple touch mouse vs holding the down key on the keyboard.
GUIs can guide users via Paternalism
paternalism is limiting a person’s autonomy in a way that is intended to promote that person’s own good.
Whether paternalism helps or hurts a UIs success depends on three factors:
- How smart the UI is. How accurately can it know what the user needs right now?
- How experienced the user is. Experienced users don’t need or want suggestions.
- The culture the user comes from. Many Software Engineers hate paternalism as a rule.
Most CLIs are aimed at allowing the user to do anything they want.
The GUI wins when the relief of having the right thing suggested to you outweighs the pain of things being hidden from you that you want.
Where CLIs win
- Anything which can be automated
- Expert, frequent users
- Workflows involving other CLIs
Where Web UIs win
- The getting started phase
- When users don’t quite know what they’re looking for. Discoverability.
- Workflows that involve analyzing large amounts of data.
- Workflows that involve interaction with the rest of the web
What Web UIs should not do
Reimplement the CLI
CLIs are very good at making everything possible. Web UIs are not. The CLI can act as a safety net for the users so you don’t have to make every command possible in the UI.
Written by David Tuite who is a product manager at Workday and used to be a software engineer. You should follow him on Twitter