I'm in the middle of designing a #CLI (command line interface) for my deployment tool and came across this comment on hacker news about how hard some CLIs are.
My theory is that the level of complexity that a CLI is able to support without causing the user to lose the ability to use it, is a function of two factors:
[#]cli #design #software #programming
=> More informations about this toot | More toots from sumanthvepa@mastodon.social
The more frequently the user interacts with a CLI, the more complexity the CLI can have. For example #git can get away with having a complex CLI, because users interact with it a lot, and get used to the complexity quickly. But for #systemd, the frequency of use is not high enough for the user to remember how to use its complex CLI.
[#]cli #design #software #programming
=> More informations about this toot | More toots from sumanthvepa@mastodon.social
@sumanthvepa I want to object. I frequently interact with systemd and its tools but very rarely with git besides clone, pull, commit and push. git is highly confusing for me while systemd is well documented and the multiple commands follow similar schemes.
Is this the One Truth? Of course not. I feel that way because I'm familiar with systemd while still seeing myself as a systemd beginner. But I'm completely at a loss with git because I'm no developer. For you it seems the other way around.
=> More informations about this toot | More toots from fluchtkapsel@nerdculture.de
@fluchtkapsel You're right. I really had developers in mind when I wrote that post. It should have read 'developers' not 'users'.
Which does bring up an interesting point. For #git, developers are power users, while for #systemd system administrators are the power users.
It may be that a CLI may have to find a way to balance serving power users with providing ease of use for newbies.
=> More informations about this toot | More toots from sumanthvepa@mastodon.social
@sumanthvepa
I use git every day, as a developer, and I can't master it's CLI. Maybe because it's so complex and I don't need most of that complexity most of the time, but I suspect also because it's poorly designed.
=> More informations about this toot | More toots from alter_kaker@hachyderm.io
@sumanthvepa
For example, if I need to do a branch operation, do I use git branch or git checkout? Or maybe git push?
=> More informations about this toot | More toots from alter_kaker@hachyderm.io
@alter_kaker Git's CLI is 'infamousl'y complex. The concepts involved are complex.
You're right that the CLI may be poorly designed, particularly for beginners.
Git tried fixing this with 'porcelain' and 'plumbing'. But, while it helped with keeping the really deep functionality away from normal users, it didn't help with complexity of the concepts themselves.
I'm not sure there is a good solution here. How does the CLI educate a newbie on difference between a branch and a checkout?
=> More informations about this toot | More toots from sumanthvepa@mastodon.social
@sumanthvepa
There needs to be a logical system to the CLI and it needs to make sense. I'm not a newbie, I've been using git for 15 years. I still think that it's opaque and bad and hostile, and I have to memorize different uses like they are incantations instead of the CLI helping me remember. A good contrast is Docker CLI.
=> More informations about this toot | More toots from alter_kaker@hachyderm.io
@sumanthvepa
I think that the key is when you are designing a user interface, including a command line interface, you need to think about how it's being used, not how it works. It's a user interface, it's supposed to be communicating with the user, so you have to think about what the user is trying to do and how they're thinking about it
=> More informations about this toot | More toots from alter_kaker@hachyderm.io
@sumanthvepa
So with Git, to the user "branch" and "checkout" doesn't mean whatever they mean in the back end where git does its magic. They just mean I want to do something that is related to the branch I'm working on or some other branch, and I want to change the state of my working tree. The user doesn't know, doesn't care, and, crucially •doesn't need to know• the backend meanings of those words. The reason that git is so notorious is because it was just not designed for users at all.
The git CLI is just a very very poorly designed tool, no matter how well designed the actual back end is.
=> More informations about this toot | More toots from alter_kaker@hachyderm.io
@sumanthvepa
Last piece: The only job of the interface is to •abstract away the internal complexity of the program into the vocabulary of its use•
So when you say how does one the concept of a branch, you shouldn't have to. An interface should aspire to be as close to self-explanatory as possible.
=> More informations about this toot | More toots from alter_kaker@hachyderm.io
@alter_kaker This! Absolutely. That should be the design objective for a CLI.
BTW. Thank you for the discussion. Mastodon.social has been a surprisingly great community to actually have real technical discussions outside the workplace. Love it!
=> More informations about this toot | More toots from sumanthvepa@mastodon.social
@sumanthvepa
Thank you too. I got worried that I was being too aggressive, so I appreciate your response 🙂
=> More informations about this toot | More toots from alter_kaker@hachyderm.io This content has been proxied by September (3851b).Proxy Information
text/gemini