Eye Magazine

Until recently, the software available to designers was rather static in nature. Driven by the promise of What You See Is What You Get (WYSIWYG) and inspired by ways of working that predate the computer, the full potential of computers as programmable devices remained unexplored. But with the advent of programming platforms aimed at designers and artists, many new ways of working have emerged. This, however, has led to a gap between designers who are literate in code and those who are not. This suggests a need to explore the potential of the computer beyond its role as a ‘simulation machine’ for pre-digital processes such as print, or photography with film.

In 2001 I launched Scriptographer (scriptographer.org) as a freely available plug-in for Adobe Illustrator. Since then, I have developed it continuously as open-source software. The first few releases of Scriptographer served mainly as a test-bed for ideas, but the program also triggered other works such as Hektor, the spray-paint output device I created together with Uli Franke for my diploma project at ECAL [Ecole cantonale d’art de Lausanne] in Switzerland, and later its siblings Rita and Viktor. (See David Womack’s article ‘Tools to make or break’, Eye 60.)

Around 2005 graphic designer Jonathan Puckey started using the software, and it soon became an integral part of his work. This triggered a dialogue between us that has strongly influenced subsequent work on the platform. In 2008, our joint experience prompted us to formulate a structure that would help evolve our ideas further. We proposed a two-year research project to ECAL that would focus on methods through which visually oriented students with no prior knowledge of coding could be taught to devise appropriate tools and apply them in their work. Luckily, the proposal was accepted.

The impulse to create Scriptographer was triggered by the observation that although the predominant software applications had a strong influence on the aesthetics of the products, their role was rarely questioned by the designers who worked with them. Other motivations included the lack of a suitable existing software framework within which to explore the mathematical potential of vector graphics, and the fact that Illustrator seemed to be doing one part of the equation really well, but lacked a scripting environment.

This integration into a software application that is already part of the daily workflow of many designers facilitated a combination of conventional ways of working with the new possibilities offered by programming. Rather than focusing purely on these new generative methods, Scriptographer encourages a symbiotic relationship between the two, allowing designers to forge their own tools and then use them directly in their existing workflow. This combination later became a crucial component in teaching students.

Early on in the dialogue that Jonathan and I had about the functionality and structures of the platform, we began focusing on the definition of a well formulated and easy-to-learn set of linguistic building blocks, or what specialists call the Application Programming Interface (API). The API describes a programming library’s architecture, and is not so different to the way the architecture of a real building describes how it is meant to be used by its inhabitants, with all its different functions, intended uses, rooms and movements through it and its surroundings. All too often software engineers seem unable – or unwilling – to perceive areas of possible improvement and simplification of their APIs.

Programmers who understand the basic needs of someone who is about to learn how to program are rare. As designers, we know that to design in the most simple way can be a very difficult task, and programming is no exception to this principle.

Once we started teaching and explaining Scriptographer to others we could quickly identify areas that seemed more complicated than necessary. An early workshop at ECAL with a large group of students who were new to programming made us question things we had long accepted as a given. We also realised how little we could assume as a base, and how important it was to restrict what the students were allowed to start working with.

Research, development and teaching
We planned the research project as four subsequent stages over two years, each starting with an analysis of the current state of things, followed by a phase of refinement and improvement of identified areas, along with the writing of teaching materials, documentation and tutorials. Each stage was concluded by our teaching in a concentrated, one-week workshop, where our assumptions were tested and results were collected for the next stage. Both the methods of teaching and working with scripting – as well as the platform itself –kept evolving, with each new group of students benefiting from the results of previous stages and workshops.

Throughout this time, we became aware that instead of offering pre-formulated modules of code that could only be tweaked, the workshops should focus on teaching the students to program their tools from scratch, using a limited vocabulary that comprised a carefully selected set of drawing commands and simple mathematical tools.

The focus on vector geometry emerged after the first workshop, in which the issues of opening up too many possibilities to the students became apparent. Underestimating the complexity, students immediately reached for the stars, forcing us to help out far too much with their projects. But towards the end of the workshop, an idea emerged.

During the workshop, vector geometry often turned out to be the easiest way to solve a seemingly complex problem of drawing with curves and paths, simply because it provides the maths to describe geometric processes in two-dimensional space, without having to deal with separate ‘x’ and ‘y’ coordinates, but instead using more explanatory values such as angle and length, and operations such as translation and rotation. One evening during the week, on a tablecloth in a restaurant, we started sketching and exploring ideas, realising that there was a very intuitive connection between manually drawing vector geometry operations using arrows and lines, and describing them in algebra, language or code. That evening’s work inspired a new approach. We realised that vector geometry, despite the mathematical complexity behind it, can provide a limited yet powerful vocabulary with almost endless possibilities.

Soon after that workshop, Puckey, together with Timo Hofmeijer, tested and explored this method in a series of posters called ‘Cities and Objects’, giving many fruitful impulses for the following workshop, where we decided to focus only on the development of simple drawing tools defined by clear sets of rules. But in order to do so, a modification of the JavaScript language used in Scriptographer became necessary, allowing the students to write mathematical operations with vector objects, thus adding operator overloading to the language’s core features. This modification permitted us to dare to teach such mathematical tools to our students. Without it, the resulting code would have been unreadable for a student at that level, and the learning curve far too steep.

Based on these principles, we defined a new structure for workshops. After an introduction to the basics of scripting, vector geometry and Scriptographer, we asked the students to formulate a series of tools that when applied together would form a coherent visual world or language on paper. They created tools that could be applied over and over almost obsessively, layering decisions upon decisions, creating non-repeating patterns. The students had to abstain from using random values and replace any random part in their ideas with a decision-making moment in their tool’s process: ‘Can it react to the speed of the mouse?’, ’How about using the click and release points?’

By continuously switching between code and design, the tools were allowed to influence their designs and vice versa. We considered the act of applying the tools as important as the formulation of the tools themselves, encouraging feedback loops between application and formulation. Despite the tools’ simplicity, students were able to create impressive results with an often surprising aesthetic, sharing qualities of manual drawings and digital automatisms.

Ways forward: Paper.js
Towards the end of the research project, technical changes and incompatibilities present in new versions of Adobe Illustrator became an increasing burden and took up more and more of our time. Keeping up with Illustrator’s many updates consumed energy that we felt could be spent better on new features, simplifications or improvements to the new platform.

So to broaden the reach of Scriptographer’s API and free it from the closed and expensive confines of Illustrator, we set out to make a version of Scriptographer that could run on the Web. This new effort, named Paper.js (paperjs.org), is an open-source vector graphics programming framework that runs on top of the new HTML5 Canvas element.

By transplanting Scriptographer into this new domain, new possibilities have arisen for animation, dynamic data visualisation and games, all areas for which the existing API turned out to be suitable. Based on the lessons learned and resources developed during the research project, the Paper.js website offers a detailed index (paperjs.org/reference) and a series of tutorials featuring interactive code examples that can be easily edited and run by visitors directly on the website.

Puckey and I never envisioned Scriptographer nor Paper.js as pure programming environments. Instead, they are ongoing efforts to provide evolving platforms for experimentation and establish programming concepts in the world of design.

Aware that design students cannot turn into programmers within one week and that the majority of them may not become regular programmers, we believe that the direction that we embarked upon with our research is a valid one. It is beneficial for today’s students to encounter this way of working during their education. Design schools should engage more in such efforts and integrate them better in their curriculum. Just like spoken languages, programming environments and languages are never static. They keep evolving, and as they become an increasing part of our toolset, we should remain concerned with their formulation and the health of their communities. Open source is a key component in this evolutionary process.

Jürg Lehni, designer and developer, London and Switzerland

First published in Eye no. 81 vol. 20 2011

Eye is the world’s most beautiful and collectable graphic design journal, published quarterly for professional designers, students and anyone interested in critical, informed writing about graphic design and visual culture. It is available from all good design bookshops and online at the Eye shop, where you can buy subscriptions and single issues.