An ugly day in Philly; a beautiful day for Drizzl.
I recently developed Drizzl, a generative weather-art toy, for my final project at NYCDA’s three-month web-development intensive program.
Inspired by Tero Parviainen’s excellent presentation on generative art, “How Generative Music Works”, I set out to make an interactive app that uses weather data, rather than an algorithm, to inform the app’s visual elements.
I discovered a number of emergent aspects during development. Here are a few:
Discovery #1: The best way I found to create the app’s interactive elements is by procedural generation.
The app first queries the Dark Sky weather API with the user’s location and then iterates through the forecast returned to the client as a JSON object. (If you’d like, you can open the browser’s console and examine the forecast object.) It then generates a button for each forecast key:
The result: there are no statically generated buttons. For example, when I input the lat and lng of the most remote island on earth, I get the following buttons and a pretty sparse animation:
This scarcity of buttons confused me at first, but I now presume the lack of forecast data is due to the low demand for weather (and weather equipment) at that spot. The same happens if you search other remote locations, like Antarctica.
I figured out how to shoehorn as many variables as possible into an html canvas element animation.
Learning to make the animation itself was tricky. I started by searching for html canvas animations on CodePen, copying or forking them, breaking them, and then trying to fix them. After about 10 animations, I learned enough to create my own simple particle flow. You can hit up Drizzl’s github repo for the full code, but as you can see below, I implemented quite a few animation variables for interactivity:
To see each of these variables in action, open the console when the app is running and you’ll see messages indicating what each button does.
As a novice to web development, but an old (and quite amateur) hand at art, I rediscovered a lesson that consistently rings true: you’re never really done art until you package it up, ship it off, and move on to the next project.
With that said, I began to implement but ultimately dropped effective use of a database so users can save and share forecasts. If you take a look at app.js, you’ll see I’ve already set up an Mlab database, but I haven’t implemented its use. That also begs the question: would users actually save and share their forecasts? I don’t see a reason to do so right now. Maybe if a user could save the state of their interactivity and then share it, they would, but that will remain unsolved until I learn a dynamic view library like React.
Still, I want to point out that even though this is a single page app, the forecast is requested by the server and rendered to the client:
I initially struggled with rendering the forecast back from the server to the client, but I solved this problem by hiding the forecast in an H3 tag, grabbing it, and then deleting the H3 tag:
I have no doubt there’s a routine, elegant solution to this problem, but I like my quick fix for its novelty. That reminds me: a long time ago, I used to work the 6 am shift at a great bakery in Boston. That early in the morning, I rarely had the wherewithal to check the weather. This could be punishing. Later that afternoon, covered in flour, having forgotten an umbrella, I wasn’t afraid to wear a trash bag on the bike ride home back to Jamaica Plain. You gotta do what works.
Thanks for reading!