Comment by catapart | Hacker News Reader

Comment by catapart | Hacker News Reader

Parent Full thread

Yeeeep.

My response to this article is the same one I have to anyone out here screaming "it's so easy to just do it my way!": if it's so easy, then do it for me!

The ffmpeg fans are the loudest screechers I've found, in this area. They'll point to the trainwreck of a UX that is Handbrake as an example of GUI for terminal commands. And, look - command line utilities are great and Handbrake is a super good product that functions well and does more than I'd ever want it to. But neither of those things are the same thing as having good UX.

If it's so easy to compile a bunch of shell scripts and store them in a directory in a git repo, then package together a bunch of them that every dev would need, sprinkle in a few with placeholders that most devs would need (with some project-specific input), and then serve them to me in a composable GUI that, in real time, builds the command to be run in my shell. Let me watch the clicks edit the command, and then let me watch the "submit" execute the command. There's no surer way for me to learn exactly what commands I need than to see them all the time. And if I have to learn them (so that I can use them) BEFORE I've seen them - in context - a few times at least, then I'm going to have a much harder time remembering. UX, when done right, helps the user.

Put simply: if I can do everything I would be able to do with postman using curl, then I should also be able to wrap curl in a thin DearImgui window that is reactive to user input. And if it's as easy as the author says, their time would have probably been better spent just making the GUI wrapper app and presenting it as a way to get better with curl, rather than writing an edgelordy article about it.

You can’t compose GUI unless you go the emacs and smalltalk route (MacOS AppleScript is a very poor example). The one thing with CLI tools is how easy to compose them and have something greater. Also more versatile than a GUI app.

Also they’re more stable than anything else. You can coast for decades on a script.

Anything you can do in a terminal can be done with what I suggested because what I suggested was literally using buttons to write a terminal command.

Not really. In a terminal the whole input can be dynamic with variables, pipe and executors like find’s exec, xargs and parallels. That’s pretty much the whole point of a shell and CLI interaction.

yes, really. If you think what I'm describing cannot enter text into a cli, you are thinking about what I am describing wrong. There's nothing you can put onto a command line with a keyboard that cannot be put there by an app using string manipulation. You're welcome to try to describe something, though.

There is nothing that you can’t. Visual programming languages do exist and the shell is an REPL. What’s important is how well you can do it. If you nail down the common use cases, you can create a nice wrapper and people have done so.

But text is very versatile. Adding another layer on top is losing that versatility. And while graphics is nice, symbolic manipulation is on a whole other level.

So fo a closed, and I guess small, you can have gui for intuitiveness. But if you want expressivity, you need symbols and formalism.

But there’s one thing that still beat Graphic in terms of intuitiveness. Tacticality. I’d bet that it’s way faster for a person to learn a physical car dashboard than a touchscreen one.

What's supposedly wrong with Handbrake UX?

To me it seems like the complexity is just irreducible. There's so many formats, so many bits and pieces that can go in a video stream, they're not very visualizable, and they have surprising edge case interactions. Not to mention there's a lot of "normally the program figures this out for you, but there's an option to override it if broken" knobs and dials.

In my experience, handbrake doesn't expose every option from ffmpeg and is more focused on transcoding. One nitpick I have with handbrake is that it doesn't support VAAPI encoding nor Vulkan Video Encoding for AMD cards on Linux.

Good UX is not about reducing complexity, nor is it about hiding complexity. It's about surfacing the exact utility a user needs in the exact context they are best suited to understand each of its inputs entirely (with the least friction in generating those inputs for the user). It's very hard to do. So much so that describing 'what is wrong' with a UX would be almost as burdensome as just designing a better UX. So I'm not going to tell you what is wrong with it; you KNOW what is wrong with it. It could be better. That you can't specify as to how just means that you aren't currently undertaking the complicated process of redesigning it. It doesn't mean you don't know good UX from bad UX.

Now, all of that aside, I do like Handbrake and I do think it offers a ton of functionality with so little friction that it's one of my very favorite and most-used apps. No login, no project setup, no x, no y, no z. Just a thin wrapper around a badass command line utility, with tons of options for users to override, and sensible defaults. There's a lot to love about Handbrake!

But "my grandma can use it", or "a plumber can use it", or "a person who doesn't understand the technicals and just needs to do one stupid thing that the app can definitely do, can use it" are signs of good UX. You wouldn't say any of those things about Handbrake.

Reply on news.ycombinator.com