Free software scares normal people

If you only care about converting media without tweaking anything, ffmpeg offers the simplest UI ever.

    ffmpeg -i input.avi output.mp4

Proposing a CLI command as a candidate for "simplest UI ever" is a great gag.

Come on. "type ffmpeg, then hyphen i then the input filename then the output filename". I would've understood this when I was 8. Because I was super smart? No, because I was making a genuine effort.

The portion you've overlooked is there is an entire population of users out there who have never seen, nor used, a command line, and telling them to "just type this out" ignores all the background command line knowledge necessary to successfully "just type this out":

1) They have to know how to get to a command line somewhere/how (most of this group of users would be stymied right here and get no further along);

2) They now have to change the current directory of their CLI that they did get open to the location in their filesystem where the video is actually stored (for the tiny sliver who get past #1 above, this will stymie most of them, as they have no idea exactly where on disk their "Downloads" [or other meta-directory item] is actually located);

3) For the very few who actually get to this step, unless they already have ffmpeg installed on their PATH, they will get a command not found error after typing the command, ending their progress unless they now go and install ffmpeg;

4) For the very very few who would make it here, almost all of them will now have to accurately type out every character in "a-really_big_filename with spaces .mov", as they will not know anything about filename completion to let the shell do this for them. And if the filename does have spaces, and many will, they now need to somehow know 4a) that they have to escape the spaces and 4b) how to go about escaping the spaces, or they will instead get some ffmpeg error (hopefully just 'file not found', but with the extra parameters that unescaped spaces will create, it might just be a variant of "unknown option switch" error instead).

How are we so blind to these beginner hurdles?

Few people are able to see through the eyes of a beginner, when they are a master.

The 4th one is a pain to teach. Every other file and directory has spaces... so I encourage liberal use of the TAB key for beginners.

This describes me somewhat. I use FEA software and only recently started using it to execute jobs in CLI. I still trip over changing directories. Fortunately notepad++ has an option to open CLI with the filepath of the currently open file. I also didn't know right-click is paste in CLI. Don't use ctrl+c accidentally. But ctrl+v does work in powershell (sometimes?). "Error, command not found" is puzzling to me. Where does the software need to live relative to the directory I am using? This is all still very foreign to me, and working in CLI feels like flipping light switches in a dark room.

To grab a random part of an ffmpeg command in my history: "-q:a 0 -map a"

Sorry, that's pretty damn indecipherable.

To answer your last question, on your operating system there is something called “PATH”. It is a user- or systemwide variable that dictates where to look for programs. It basically is a list of directories, often separated by “:” Further reading: https://www.java.com/en/download/help/path.html (this may have Java references but still applies)

To add on to this, there's no standardized way of indicating what needs to be typed out and what needs to be replaced. `foo --bar <replace me>` might be a good example command in a README, but I had to help someone the other day when they ran `foo --bar <test.txt>`, not realizing they should have replaced the < and > as well as just the text.

They are using text inputs, where you press enter to send stuff daily. Most of the hurdle is just overcoming the preconception that at black in put window means hard mode.

They can right-click in the folder view of their OS file viewer. On Windows they can also just type the command into the path bar.

When you tell them the command, you could also just install it. Also you could just tell them to type the name of the app 'ffmpeg' into the OS store and press install. They do this on their phone all the time.

The GP here appears to be on Windows, given their reference to PowerShell. And on Windows, the path separator is ";", not ":".

One of the things I've noticed is that people trying to help the true beginners vastly overestimate their skill level, and when you get a couple of people all trying to help, each of them is making a completely different set of suggestions which doesn't end up helpful at all. Recently, I was helping somebody who was struggling with trying to compile and link against a C++ library on Windows, and the second person to suggest something went full-bore down the "just install and use a Linux VM cause I don't have time to help you do anything on Windows."

Yes, your example that completely ignores the premise is pretty damn indecipherable.

"If you only care about converting media without tweaking anything"

The reality is that we've been infantilizing users for far too long. The belief that people can't handle fundamental concepts is misguided and primarily serves to benefit abusive tech companies.

Two decades ago, users understood what "C:\Documents and Settings\username\My Documents" meant and navigated those paths easily. Yet, we decided they were too "stupid" to deal with files and file paths, hiding them away. This conveniently locked users into proprietary platforms. Your point #2 reflects a lie we've collectively accepted as reality. Sadly, too many people now can’t even imagine that a straightforward way to exchange data among different software once existed, but that's a situation we're deliberately perpetuating.

This needs to change. Users deserve the opportunity to learn and engage with their tools rather than being treated as incapable. It’s time we started empowering users for a change.

This is an interesting position because that's only simple if you already know it. From the perspective of discoverability, it's literally the worst possible UI, because a string of that length has, say, 30^30 possible combinations, among which only one will produce the desired effect, and a bash prompt gives you no indication of how to arrive at that string.

Well, you're cheating a bit here. You're basically assuming the user has never seen a text prompt before. Which is a good assumption.

But, if we assume the user has never seen a graphical application before, then likely all GUI tools will be useless too. What is clicking? What does this X do? What's a desktop again? I don't understand, why do I need 1 million pixels to change an mp3 to an avi? What does that window looking thing in the corner do? Oh no, I pressed the little rectangle at the top right and now it's gone, it disappeared. No not the one with the X, I think it was the other one.

Pretty much all computer use secretly relied on hundreds if not thousands of completely arbitrary decisions and functionality you just have to know. Of all of that, CLI tools rely on some of the least amount of assumptions by their nature - they're low fidelity, forced to be simple.

It is easy but annoying. I nearly always find it easier to write a short script and run that rather than type terminal commands directly.

first u gotta tell them how to install ffmpeg... scary stuff

The difference is a lot of "computer education" (as opposed to computing education most in this forum have) has happened with GUIs. "Simple" CLI tools doesn't mean they're understandable or even user-friendly.

Heck, even computing education (and the profession even!) has been propped up by GUIs. After my first year in CS, there were like only three to five of us in a section of forty to fifty who could compile Java from the command line, who would dare edit PATH variables. I'm pretty sure that number didn't improve by much when we graduated. A lot of professionals wouldn't touch a CLI either. I'm not saying they are bad programmers but fact of the matter is there are competent professional programmers who pretty much just expect a working machine handed to them by IT and then expect DevOps to fix Jenkins when it's borked out.

Remember: HN isn't all programmers. There are more out there.

> But, if we assume the user has never seen a graphical application before, then likely all GUI tools will be useless too.

We don't even need to assume, we just need to look at history. GUIs came with a huge amount of educational campaigning behind it, be it corporate (i.e., ads/training programs that teach users how to use their products) or even government campaigns (i.e., computer literacy classes, computer curriculum integrated at school). That's of course followed by man-years upon man-years of usability studies and the bigger vendors keeping consistent GUI metaphors across their products.

Before all of this, users did ask the questions that you enumerated and certain demographics still do to this day.

> Of all of that, CLI tools rely on some of the least amount of assumptions by their nature - they're low fidelity, forced to be simple.

"Everything should be made simple, but not simpler." Has it occurred to you that maybe CLI tools assume too little?

Type what into where?

I agree with pretty much all of this, I think where the divergence is what to do about it. IMO, tool wise, nothing - this is an education issue.

And onto your point about CLI tools often making too little assumptions: this is 100% true, and also a superpower. There's a reason that a tool like ffmpeg can spawn 1000 GUI programs from it, each with their own draws. It's a generic tool, not necessarily an application. Many CLI programs are like this.

That can raise the complexity but it's a tradeoff. Many GUIs are too "happy path" centralized, and that happy path is different for different people, so they become cumbersome and unintuitive in too many use cases. A great example would be just about everything Microsoft makes.