Re:CLI user experience case study
by BossingAround on Friday January 12, 2024 @08:02AM
(#38967456)
From my experience, interactive CLIs are the worst of both worlds.
They are not as pretty and intuitive as GUIs, since the user has to learn terminal idiosyncrasies (e.g. unable to ctrl+c, or edit text in the middle of the sentence by mouse).
And, at the same time, they tend to be pretty bad for automating things (in the worst case, even unsuitable for automation) since now, you have to map the interactive commands to the non-interactive ones.
You're right in that an interactive CLI's interface is not trivial to nail. We're spending a lot of dev time on that actually.
And of course there always also has to be a non-interactive version for automations.
It depends on tool. If this is some generic utiliy that interacts streams, it most probably should not be interactive. But for example if this tool is some kind of control shell for subprocess (like Quagga vtysh or FW control CLI) it would be much easier to use in interactive fashion (autocompletion, interactive help and hints system).
We will always need CLIs for things that are to cumbersome or rare to add into GUIs; but they have to become easier to use, and provide immediate value.
That's why we built an interactive CLI by default at Diversion. It's not a revolutionary tool (there are other similar CLIs), but it has shown to help our users get started with Diversion much faster - the feedbacks are overwhelmingly positive.