Easiest solution is just to use the highest resolution thumbnail the official documentation says is supported on all videos (vs "some"), which is hqdefault.
Maxresdefault is overkill for this purpose IMO. Why waste the data? Incidentally this is why I run an add-on that redirects all youtube thumbnails to mqdefault, it saves me a nice chunk of bandwidth / memory / perf.
I made an Astro component for this [1] which does the iframe srcdoc thing [2] (example page with dozens of videos [3]). Most of the code is just TypeScript types and building a big srcdoc string, so easy to repurpose if anybody wants to.
Handling the fallback image has been sitting as an issue in the repo for a while, in favour of just checking it with the Astro dev server when I'm adding new videos, so… yoink‽
So playing around with the goal of "highest quality thumbnail" in mind, I notice that the oEmbed data appears to always return the hqdefault.jpg url, regardless of what's available.
I just took a look at the code that's returned when you open https://www.youtube.com/embed/<videoid>?feature=oembed and noticed a couple of additional image file names you may want to check.
[author] It's my idea of how app builders should design and build apps. It's an anti-pattern to build an app that allows children to spend their parent's money without express permission.
Author here. Not every app needs to be focused on teaching kids to read. When my 3 year old was using the app, putting words on the icons was meaningless, and a sign that I needed to put more effort into communicating visually. Older kids can handle more text, but I found that the app could achieve it's primary functions without it, and there is a beauty in simplicity.
Of course I read with my children every day, and they are now both voracious consumers of real world books. I encourage you to do the same. I also included features in Kidz Fun Art that help kids practice their hand writing and math problem solving. However, trying to have every app solve every need for every child (e.g. reading in this case), just leads to an ugly, messy interface that is off putting to everyone. Add lightness - take things away that are not needed.
Author here. I find this to be a pretty cynical take. I tried to express that if I build something and it makes my kids smile then it stays in the app. You appear to have a different take on it. Should we not try to make children enjoy using the tools they use? What's the alternative? Make you app actively hostile and difficult to they'll go touch grass? I'm honestly not clear on the point you're making here.
It would help if you hadn't repeatedly used exploitative marketing/business language like “user retention” and “monetization”. Your desire to delight children and make them smile is commendable if that is the end-goal, but the text reads like the end-goal is to hook children and make money off of them.
The app's audience is children. The blog post's audience are professional designers and engineers. I am speaking their language. People build apps for a variety of reasons - I started off with this app just making it for my kids, until I decided to make an effort to find more users - and one of those reasons is to make a living off the time spent working on it. There is absolutely nothing wrong with hoping to be compensated for your time and effort, and that is why we must discuss user retention and monetization. These are not dirty or exploitative terms in and of themselves, they are simply tools used to measure an app's usage and current level of progress towards your goals so that you can react accordingly.
What is exploitative is the way almost all supposedly child friendly apps try to trick or corrupt children with ads and gamified purchases. My post comes out very explicitly against this, which I presume you read.
I did, and I do genuinely find your project (and approach) commendable! I'm sorry I didn't say that because of the focus of my comment.
I was merely responding to the kind of language you used to describe it. You call it the language of designers and engineers, but I'm sorry, that's not my language! To me, that is the language of commercial entrepreneurs and capitalists and they give me a gag reflex.
I would love for you (and everyone else) to be able to live in a world where you can pursue this kind of passion project without having to worry about “making a living”. The commercial and capitalist mindset is what's standing in your way.
This actually captured my intended point, which was expressed poorly and hastily. It's not my intention to twist or neglect the good intentions of the OP in designing an app for his kids, merely pointing out that some of the language read more sinister.
You both fall for the false dichotomy trap. If anything, this remark should be taken as criticism towards parents who find it much more convenient to use an app and a tablet, rather than buying physical stuff, have to put it away, and to keep a close eye on their kids so they don't ruin the wallpaper or run with pointy pens in their hands etc. Certainly the thing you need on rainy days or when you have other things to do. Uti, non abuti (use but don't abuse)
Struggle is very good for learning, I remember as a child enjoying very difficult interfaces because I was proud of being able to navigate the software when I finally get there, becoming very efficient with it, and I learned way more about the domain. (I'm thinking for example Cubase, reason, Photoshop at the time, most linux softwares, vim,...)
While easy to use softwares are more 'enjoyable' and the dopamine reward is high for small actions, it also prevent to develop some ability and resilience in navigating harder things. When the software complexity increases, users get annoyed and don't use it correctly because they were never exposed to much complexity before. (thinking about medical softwares that require many many actions to encode a patient, finance softwares, etc..)
Now, not all softwares are made to improve one efficiency. In your case, the app allows a children to express its creativity in other ways, which is very valuable also. So I think it is good that the interface and the interaction are easy, the focus should be on the creativity and not on the manipulation.
Learning can and should be also through practice and raising the bar, I agree, but don't mix learning as a general concept applied to a population with your own survivorship bias.
I think both kind of applications should exist in parallel. I generally dislike current trend in professional softwares that try to be easy to use, at the cost of less power or more clicks to do a simple action.
Professional apps should stay professional and more time should be spent in training power users.
I'm trying not to mix with my own survivorship bias,but I tend to believe that current trends of design remove the existance of advanced users at a young age. The applications are so polished and limiting that you don't spend time trying to do complex things with them.
I find bugs in old apps were a feature for learning. If it doesn't work, you try to understand why. Curiosity is intrinsic to young children, until we remove it by giving them something that never bug or limits their possibilities.
I'm working on a game for my kids to play, so I for one am appreciative and taking notes for my own implementation. I've definitely observed at least some of the things mentioned, so hopefully combining those with your others will save me some time and grief. Thanks!
Great to see more competition in this space - I'm currently on Slack and not happy about it. Here's hoping Emdash can fill the void left by Workplace and get some momentum to put pressure on Slack. It's much needed
Same here! Slack is… fine. The one catch for Emdash for me is that we are hybrid (3 days in office) and use Zoom Rooms for our conference room are pretty happy with it.
