9 ms·
Take this feedback as constructive, because Racket is cool and a movie-making language is interesting and I want you to succeed. Good software design is about
by javajosh 7y ago
Take this feedback as constructive, because Racket is cool and a movie-making language is interesting and I want you to succeed.
Good software design is about anticipating what your user will need to know to move forward. Your project failed to do that at step 0: the project home page doesn't show the information people will need to move forward. Some indication of what the project does, what it looks like...
What I thought when clicking on the HN link:
Video-making with a programming language! How interesting! Lots of potential with animation, concurrency, etc. What does that look like? I want to see a session with the tool. At the very least I want to see the output of the tool, and some code snippets. If I like it I'd like to know who made it, and why, and what they've done with it so far, and where the money's coming from. Well, at least there's a getting started button, nice and big and red! Oh, all it's telling me to do is install this thing. Is the author crazy? I'm not installing something without a single goddamn screenshot! Lets write an HN comment...
The thing is I am not going to install your program without this information, and I think you need to spend some time thinking about what visitors to your project will need to see before they take the plunge and look at your stuff.
- codetrotter 7y agoI agree they ought to show what it’s like to use this on the landing page. Meanwhile, for anyone curious there are some screenshots and demonstrations of usage in the docs, starting with this page: https://docs.racket-lang.org/video@video/Getting_Started.html#%28part._.Video_.Basics%29 https://docs.racket-lang.org/video@video/Getting_Started.htm...
- derision 7y agoI disagree. A link to documentation is at the start of the page. That's where I expect to see code samples and output which is all there
- mdip 7y agoWhich covers, reasonably, people who have an idea of what the product is and enough motivation (i.e. working in the space, or a serious hobbyist) to click in more deeply. Myself -- little more than an enthusiast -- clicked the homepage link, the documentation link, the blog and ended up landing at the point where the line on my "interest in the product" part of the graph met my "time I'm willing to spend figuring out if I'm going to be more interested" before I ever got the answer to "would I want to use this?" That's fine -- the author is within his rights to target what s/he wants. Perhaps it's so Alpha that the author doesn't desire people other than "serious hobbyists" to dig in deeper (there's valid reasons to do this). But if the goal was to get larger traction (as posting to HN is likely to cause), that didn't happen, for me.
- brudgers 7y agoI posted it to HN. It's not my project. I found it interesting because I have some level of current interest in ffmpeg. I googled "ffmpeg racket" probably because I saw this or (something like it) at some point in the past several years. I went about as deep into the project as you did and concluded "it's not for me" too. It was still intellectually interesting, hence the submission. The reason I concluded "it's not for me" is I've realized that trying to avoid learning big heaps of pain like ffmpeg takes more energy than just climbing the steep learning curve of the original tool...and in theory writing my own abstractions over it. To put it another way, I can probably automate ffmpeg using Babel in emacs org-mode and get tooling that hews closely to what I am trying to do. FWIW I also posted a link to a Python repository wrapping ffmpeg. Similar reasons. Similar conclusion. But the Python tool is much more mature and would probably be a better engineering choice than an org-mode document in a team environment with a normal distribution of tool preferences among its members.
- javajosh 7y ago>The reason I concluded "it's not for me" is I've realized that trying to avoid learning big heaps of pain like ffmpeg takes more energy than just climbing the steep learning curve of the original tool Well, then, a valuable lesson. I would suggest that writing a blog post about that experience and posting to HN about that would actually have been more interesting, for me.
- brudgers 7y agoEven though I know that its better for me to just learn the base technology doesn't mean I don't try to avoid reading the manual. Knowing there are no silver bullets doesn't mean I don't want one. It's just that this time it only took me a few hours and a night's sleep to stop looking. Unfortunately, by that time, both articles were on the front page. Or fortunately to the degree my self worth is tied to my HN karma.
- mdip 7y agoAh, another person experiencing `ffmpeg fatigue`. Holy cow is that a language-in-a-command-line. I ended up using 11/17 graph paper to write out a mess of notes trying to understand how everything is put together. There are some solid wrappers, now, but in the past most of the libraries I've run into (at least on the C# side) exposed a limited feature set as a way of reducing the complexity. The features omitted, of course, were ones I needed. So I always ended up back using a ba/zsh script and the command-line. Based on my notes, I've always felt that it wouldn't take much to represent the command-line options in a more elegant way using a YAML definition (with more descriptive property names than the CLI options use). Inputs, Outputs, Filters and their Relationships between each. Seems like it'd be easy to validate outside of ffmpeg... I went down the path, briefly, but got side-tracked.
- bscphil 7y agoThis link is hidden under a hamburger menu on Firefox for Android, and it's not even visible on the screen unless you scroll to the right. I didn't even realize it existed until you mentioned it because the page seems to be formatted deliberately to keep you from knowing it's there on mobile devices.