If handbrake scares them, don’t you dare to demonstrate how to use ffmpeg. I remember when I used handbrake for the first time and thought “wow, it’s much more convenient than struggling with ffmpeg”.
replies(7):
for certain types of tooling UIs should be cheap, disposable and task/worlflow specific.
Whereas with complicated GUI tools, you have to watch a video to learn how to do it.
It struck me as a weird example in the OP because I don't really think of Handbrake as a power user tool.
From which I was able to then say, "Can I have the equivalent source code" and it did that too, from which I was able to spot my mistake in my original attempt. ( The KDF was using md5 not sha ).
I'm willing to bet that LLMs are also just as good at coming up with the right ffmpeg or imagemagick commands with just a vague notion of what is wanted.
Like, can we vignette the video and then add a green alien to the top corner? Sure we can (NB: I've not actually verified the result here) : https://claude.ai/share/5a63c01d-1ba9-458d-bb9d-b722367aea13
Well, there are different issues.
Reading a manual is the best you can do, theoretically. But Linux CLI tools have terrible manuals.
I read over the ssh man page multiple times looking for functionality that was available. But the man page failed to make that clear. I had to learn about it from random tutorials instead.
I've been reading lvm documentation recently and it shows some bizarre patterns. Stuff like "for more on this see [related man page]", where [related man page] doesn't have any "more on this". Or, here's what happens if you try to get CLI help:
1. You say `pvs --help`, and get a summary of what flags you can provide to the tool. The big one is -o, documented as `[ -o|--options String ]`. The String defines the information you want. All you have to do is provide the right "options" and you're good. What are they? Well, the --help output ends with this: "Use --longhelp to show all options and advanced commands."
2. Invoke --longhelp and you get nothing about options or advanced commands, although you do get some documentation about the syntax of referring to volumes.
3. Check the man page, and the options aren't there either. Buried inside the documentation for -o is the following sentence: "Use -o help to view the list of all available fields."
4. Back to the command line. `pvs -o help` actually will provide the relevant documentation.
Reading a manual would be fine... if it actually contained the information it was supposed to, arranged in some kind of logically-organized structure. Instead, information on any given topic is spread out across several different types of documentation, with broken cross-references and suggestions that you should try doing the wrong thing.
I'm picking on man pages here, but actually Microsoft's official documentation for their various .NET stuff has the same problem at least as badly.
The idea behind a cheap UI is not constant change, but that you have a shared engine and "app" per activity.
The particular workflow/ui doesn't need to ever change, it's more of a app/brand per activity for non-power users.
This is similar to how some apps historically (very roughly lotus notes springs to mind) are a single app but have an email interface/icon to click, or contacts, or calendar, all one underlying app but different ui entry points.
ffmpeg -i input.avi output.mp4they are. ive only used ffmpeg via llm, and its easy to get the LLM to make the right incantation as part of a multi-step workflow.
my own lack of understanding of video formats is still a problem, but getting ffmeg to do the right thing only takes a vague notion
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).
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.
Someone who only wants to convert from one format to another, and isn't accustomed to CLIs, is far better served by "drag the file here -> type an output filename and extension in the text box".
The problem (and the reason both FFMpeg and Handbrake exist) is that tons of people "only" want to do two or three specific tasks, all in the same general wheelhouse, but with terrible overlap.
Sorry, that's pretty damn indecipherable.
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.
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."
"If you only care about converting media without tweaking anything"
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.
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.
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?
Handbrake is easier in that I don't have to think too hard about how to use it; but that I think a lot more critically about the options that I choose.
FFmpeg is easier when I go in knowing the exact options I want; often pulled from notes that I've stored away, or combined with scripts.
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.