Hacker News Reader

Comment by wmf | Hacker News Reader

If you don't perform a task frequently, a discoverable interface (e.g. GUI) is dramatically more productive than reading documentation.

View on HN

Conversely, if you perform a task frequently you want to be able to script it out and automate it away.

Why not both? GUIs can be built that can emit the command-line equivalent.

In ffmpeg's case, I would be looking for a GUI beyond just "here's all the command line parameters, only in a form"... the hardest thing is taking something I already know what I want to do, and encoding it into the command line, because the way to encode a graph into a command line is not obvious. It is easy in principle but there are so many degrees of freedom in how it is done that I can never remember it all. This is a perfect time for a visual language.

there is winff(not sure of its state today) its totally just a gui frontend even shows you it working in console for an example of something already written. scripting can help with more complicated operations but just for common shorthand there are aliases which can be written out scripts single command lines and pointing to script files.

I use ffmpeg not infrequently, but rarely to do the same thing, so automation doesn't help. Knowing how filter chains work and having access to the filter documentation is great.

Well there are video editing GUIs, even straightforward ones. But they'll have footguns and surprising behaviour everywhere. Lossy or compressed video is a hard problem.

This really depends a lot on the quality of the GUI and the documentation.

IMO the best option is the best of both worlds. A GUI that outputs the CLI command along with good documentation would be ideal.

Reply on news.ycombinator.com