brendanr

Music Lab by Code.org is a Blockly-based experience, built for K-12 education, at https://code.org/music.

It's open source, and we wrote some technical documentation at https://github.com/code-dot-org/code-dot-org/blob/600ebafa52....

There were a bunch of interesting aspects to this project. One of my favorite things was developing the user programming model. Organizing your music using functions is very powerful.

The vegetables gardens were there literally 90 minutes ago when I took a photo of them.

The transition to CSS transitions seems primitive to me. https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Animati... makes it sound very much like a fire-and-forget approach.

My concern, also when building UI with React, is that web design is often only interested in end-state of an interface, playing a bunch of fire-and-forget animations to transition between states.

The reality, that only games and Apple seem to have embraced, is that it's far more sophisticated for animation to reflect a state that can change at 60 or even 120 frames per second, depending on what the user is doing.

This is a great presentation from Apple, Designing Fluid Interfaces, that captures the concept: https://developer.apple.com/videos/play/wwdc2018/803/

Am curious: have any web frameworks embraced this approach?

It's not a question of browser support, it's a question of infrastructure support. When I was using them years ago, there were a lot of networks which blocked them.

Is it okay to rely solely on websockets these days? I was always impressed by pusher.com's commitment to a variety of fallback protocols (and there are three blog posts about it, see https://blog.pusher.com/how-we-built-pusher20-part-1/)

Big fan of Isaacson's Benjamin Franklin biography, but also did not enjoy his Jobs one. The most interesting part of the story was when Jobs returned to Apple and executed perfectly on everything. It seemed that he'd learned some very important lessons and had undergone quite the transformation. The book doesn't hint at what he'd learned; it just recounts things happening really well. It left so many unanswered questions, and didn't even notice they were there to be explored.

Canvas drawing is fast on platforms where it's hardware accelerated, which has been the case on things like iOS Safari for years now. At least in the past it was also beneficial to make a few optimisations such as drawing to integer pixel coordinates, avoiding special paths for subpixel rendering.

Canvas doesn't have a DOM, for what it's worth.

The perf issues sound suspicious. At least in the past, canvas sprites on iOS can get very slow if you don't render to integer coordinates.

Hopefully the author attached macOS Safari to his iOS device to do some basic debugging and profiling.

Does anybody remember the old Manhunter games from Sierra? They used a very similar idea of replaying a timeline multiple times to track a bunch of suspects as they interacted throughout an event. What was a clever but abstract sci-fi game mechanic has suddenly become reality.

Seems to be in https://github.com/bookiza/bookiza

For Code.org, you will find https://code.org/about/2015 to be quite interesting, including a breakdown of where money was spent. You'll see that a lot goes towards training teachers and building interesting programs.

nice design, but i wonder if their design team has any non-retina machines? the anti-aliasing in the tilted phone UI is pretty bad in Chrome on a non-retina display.

If you found this article interesting, check out the book Addiction by Design: Machine Gambling in Las Vegas, by Natasha Dow Schüll.

It's an incredibly interesting book about building addictive gameplay, the industry that does it, and the people that use it.

I might add that never alerting my phone was the worst thing simply because it was the only reason to buy a Protect. A regular smoke detector continues to detect smoke just fine.

Actually mine just runs on batteries. I think they have an optical sensor which can be triggered by dust. I was told by support that they used to recommend blowing the debris out, but it wasn't good for customer confidence.

Nest did a great job with their thermostat, but the Protect leaves a lot to be desired. I was vacuuming which triggered the sensor. The alarm went off, and it was really loud.

I looked at how to hush it, and couldn't figure out how. My alarm was too high up to safely climb up and press the button -- I had paid for somebody to install it safely before.

So I called their support, and they told me they couldn't legally add a feature to turn it off. Which is a bit bewildering, considering that wave-to-hush had been a launch feature (albeit removed for apparent reliability issues). So I had to dangerously climb up high and remove the alarm and take out the battery.

But the worst thing? It never alerted my phone.

I have my own theories about why this happened. I had recovered my iPhone and not logged back into the Nest app, which I think is required for notifications to start flowing again.

But the support guy thought Nest engineering would be back in touch with me to discuss this crucial flaw within two weeks. Months later, I've not heard back.

Nest had a ton of options after the thermostat. It feels like they put a smaller B team on the smoke detector, despite it being a critically important safety device. It's really bewildering how the Protect turned out this way.

More generally, the lesson is that the Internet of Things is going to be fraught with complications.

Good point. It's essentially a scene-by-scene navigation model, where you jump from one scene to another. While inside a scene there can be animations.. looping, triggered, one-off, etc.

I always meant to link to a couple sample projects (both source and output) on the homepage.. you've encouraged me to revisit that soon!