A Modern Prometheus
"When we started Processing in 2001, the goal was to bring ideas and technologies out of MIT and into the larger world. One idea was the synthesis of graphic design with computer science, combining the visual principles of design with ways of thinking about systems from computer science. We also wanted to share a way of working with code where things are figured out during the process of writing the software. We called this sketching with code. A third idea was to share what we had learned about how to teach programming to designers — to share this beyond the people we could teach directly through our workshops and classrooms. We wanted to spread this as far as we could.
ANotes in Casey’s sketchbook in 2001 from our first conversation about the project that would become Processing. There was an early focus on creating a coding environment that would be compatible with the tradition of foundation studies in art and design education. This was all made possible by a set of programming tools we created specifically for making pictures, for choreographing animation, and for creating interactive work. Over many years, we refined a set of elements for creating visual design with code. Additionally, we didn’t start this work from scratch, we built on top of existing ideas and code from people who worked in this area before us.
The Lab
Processing has direct origins at the MIT Media Lab back going back to The Visual Language Workshop (VLW.) The VLW was founded in 1975 and it became a founding research group at the Lab from 1985 to 1994, when Muriel Cooper, the director, passed away. Cooper was a graphic designer at MIT, first at the Office of Publications and later as the founding art director at MIT Press. The VLW focused on traditional design considerations within the domain of screen-based publication and information spaces. One of the most compelling and public demos to emerge from the VLW was Information Landscapes, a three-dimensional presentation of animated, interactive typography that was well ahead of its time. Processing was hugely influenced by the research and people within the VLW.
Processing emerged directly from the Aesthetics and Computation Group (ACG), a research group started at the Media Lab by John Maeda in 1996. Maeda’s research at the Lab continued to synthesize visual design exploration with emerging software technologies. The students he recruited worked within similar themes to the VLW and their work continued research into programming tools to create visual media. David Small was the one person to start in the VLW and to graduate with his PhD in the ACG. His work and knowledge established a continuity.
Within the ACG, code was most commonly written with the C++ programming language and a graphics toolkit called ACU that was started by Ben Fry, with Tom White and Jared Schiffman contributing significant portions as well. In the late 1990s, when we started at the Media Lab, ACU was used on Silicon Graphics Octane and O2 workstations, computers that cost tens of thousands of dollars at that time. By the year 2000, ACU was used on PCs configured with a graphics hardware that cost hundreds of dollars. This shift in hardware affordability is one of many reasons why, at the turn of the century, it became possible to create the kind of work created within the VLW and ACG outside of academic and corporate laboratories.
The ACG website remains online at http://acg.media.mit.edu/ and there are a few personal backups. A slice of the work is archived in Maeda’s Creative Codebook, published by Thames and Hudson in 2004. The ACG concept videosthat Maeda encouraged us to make are low-resolution videos by today’s standards, but they show the work in motion as intended. Most of the ACG MS and PhD thesis documents are online as well.
John Maeda started the Design By Numbers (DBN) programming platform within the ACG. Both the MIT Press book and software for the project were released in 1999. Maeda brought the two of us into the project after the initial release to help maintain and extend it. Many aspects of Processing were modeled after DBN, which also integrated a code editor with a language. DBN was a minimal system, the canvas was always 100 × 100 pixels and only gray values could be used — there was no color. These constraints, as well as comfortable code elements such as paper and pen made DBN easy to learn.
Teaching with Design By Numbers was a formative experience for us. Our first event was a workshop at the AIGA national headquarters on August 25, 1999. This “computational illustration” workshop was planned for people with no prior background in programming and even for people without much experience operating a computer. Maeda led the workshop and Tom White also assisted. Maeda later asked us and Elise Co to teach a series of workshops at RISD. For these and other workshops at the time, we designed and built the DBN Courseware software, a series of Perl scripts that allowed teachers to create exercises and students to upload their work directly to a web server.
This experience kindled the ambition to start Processing. We started by extending DBN to include color and other features, but soon realized that these limitations were the essence of that platform and it shouldn’t be expanded. We wanted to make a system that was as easy to use as Design By Numbers, but with a bridge to making more ambitious work. We wanted to allow people to work in color, at large sizes, to create 3D graphics, and more. Simple Processing sketches are almost as simple as DBN sketches, but Processing scales up — it has a “low floor” and a “high ceiling.” The ceiling is more similar to the C++ programs we used to write with ACU partly because the rest of the Java programming language and its libraries were available.
Language, Environment, Community
We created Processing as three parts: language, environment, community. Each part is essential; the project is defined by the interactions between all three.
Language
A Processing program is called a sketch. This is more than a change in nomenclature, it’s a different approach to coding. The more traditional method is to resolve the entire plan for the software before the first line of code is written. This approach can work well for well-defined domains, but when the goal is exploration and invention, it prematurely cuts off possible outcomes. Through sketching with code, unexpected paths are discovered and followed. Unique outcomes often emerge through the process."— Jeffrey Fleishman, Jun. 15, 2018
This post is an excerpt, read the full article on the Medium website.
Stay engaged. Use #UCLAarts to stay connected.
