Algorithmic generative design, is basically the defining of rules to define behavior boundaries and letting random() take the wheel. I was asked by a client to incorporate motion into a project and had been struggling to decide what tool to use to prototype it, framer, aftereffects or whatever. I had asked a few designers what they would do and got some suggestions about puppet tools and precomping behavior and so on. I was not excited at the the time I was expecting it would take to manually key frame the kind of dynamic feeling motion I was after.
Thankfully one of the people I talked to had mentioned Processing, the code language made specifically for dynamic visualisations. Not in the D3.js dataviz way, but the Conway's Life kind of way. I had run into it a little bit with some maker projects (ie the Ambilight dynamic backlight) but had not really seen the potential until I saw openprocessing.org. The gallery of work was amazing and after digging through some code samples and a little bit of prodding and poking I was able to get close to the behavior I was looking for, and with processing.js it can run in browser.
What I really liked was that it was easy to add both user and data interaction to create dynamic generative behavior that could reflect some underlying data making it more than decoration but an abstraction of some piece of information.
The specifics of the behavior are known, but the starting points and thus the visual is different on every page load, which is also really interesting to me. I don't know that I would use processing on an enterprise scale project, the in-browser calculations would be kind of a jerk thing to unleash on folks, particularly mobile (battery constrained) people. Granted it could done serverside with node.js or something, but for small scale of the project it seemed like a fair match.
The wondrous magical weather wand casts an enchanting spell of light. A way of making visible something that is normally felt. In less magical terms, I have an Arduino pro mini with a temperature sensor (currently a TMP36) and a RGB LED. The Arduino checks temperatures and sets the color of the light based on the temperature.
The early version of this used a temp to color table (like the temperature map project) that would for example set to the light yellow if above 70º or to blue if below 30º. However it would be pretty unlikely to encounter that wide of a temperature range within a space so instead of re-tuning the table for every location I wanted to have it set its own range.
The solution was to use statistics! It takes and averages the temperatures it sees and sets the color to normal (green) based on that average. The standard deviation (ie max/min range) is set based on the variation the sensor picks up. The color changes based not on a specific temp value but the number of standard deviations from that average. ie: 2+ stddev is red -2 stddev is purple, etc.
That worked for me because I wanted a way to paint with light and see temperature variation and I didn't really care about the specific temperature values.
Weather Underground has a makers club. Bits of information can be combined with different people's programing and craft skills. Everyone brings something to the table. The API group sponsored some hardware (Thanks Ali!) and so we have everything from the spark and Arduino to the Beagleboard to work with. I am excited to share the projects I have put together including the Weather Map and the Weather station robot.
Also on Hackster.io
Continuing the post-hackathon weather gadget making, fueled by the Spark Core (Think Arduino with WiFi) I got from Zack at TechCrunch and liking shiny lights, I started on the weather map. A matrix of addressable LEDs that were in the general form of the United States. The idea was that the spark could talk to the Weather Underground API, pull down temperature data for each of the lat/long locations assigned to each light, and the light would change color to reflect the temperature.
The built in WiFi made talking to the API pretty straight forward, the challenge was more about memory and the API limit, making 100 requests per map refresh was not something my free api account could sustain. Luckily the API team helped me out with my limit to keep the project going.
The big break came when Adam Williams got involved, he was able to program the light matrix to show temperature, precipitation, and storms.
Bonus story: while working on the map all the lights switched purple (not assigned to anything), cluing the team into an API problem. Needless to say it was almost immediately fixed and the map came back to life. My little side project accidentally became useful.
Tech detail: 100x rgb addressable LEDs with WS2801 controllers in series, attached to a Spark core being fed data over wifi from the Weather Underground API. Powered by a 5v 2A wall wart plug.
Another year at the gigantic hackathon that is TechCrunch with Weather Underground. We had a few devs from the API team out to support the hackers that might have questions pop up and help them along. I came out to support the devs with boxes of little electronic bits and we hacked together little things to pass the slow spots as the clock went around the small hours.
The material I designed for last year's TechCrunch is HERE
I recently started working with electronics as way to make something real, tangible with programing as a way to learn a little more. Working at Weather Underground I deal a lot with weather so of course one of my first ideas was to make a weather station.
Making something that does the job is never enough, so Amy (my co-conspirator) and I set out to give the little bundle of wires a more entertaining form. Inspired by Adventure Time we settled on a robot body. In addition to housing the controller and sensors, the robot form gave us a good reason to include a large screen that could display data (making the whole thing self contained) and as a bonus, make funny faces.
A quick project to test a few ideas quickly grew and ended up keeping us company at our booth at TechCrunch.
It started innocently enough, seeing #sfpostit on twitter. I went ahead and built up a quicky storm cloud pointed at GSP up the street.
It occurred to me, being a weather company, the next level post-it project would be to put the temperature up on the window.
Less fun, sounds like a bunch of work every morning. Having recently bought a copy of make magazine, I got the idea that I could built a robot to do the the work for me.
A post-it display plan was hatched.
First there was the small task of learning how such a thing might work, I immediately went and bought an Arduino, and set myself to learning how to program it. Being a designer, and not a programer I expected this to be a big problem. Thankfully, it wasn't terrible to learn, a few introductory books later I ended up with a pretty good idea of how it might work.
Prototype to test of course.
Then the larger scale.
To build the silliest analog display using post-it notes, I taught myself a little bit of programing and learned my way around the Arduino and basic electronics. Not a bad little project.