Computation for Graphic Designers

The integration of computation in graphic design practice is seemingly a recent phenomenon and one that is commonly deemed as cross-disciplinary between design and engineering. Yet upon a closer look we discover that underlying this practice is a methodological structure of modularity and logic that has been present throughout the history of graphic design. Then, how exactly are we to understand computation for graphic designers? There are a number of publications on computation to date, such as Designed by Numbers (Maeda, 1999), Generative Design (Bohnacker, Gross, and Laub, 2012) and Form+Code (Reas, McWilliams, and Barendse, 2010); however, they mostly focus on teaching readers how to draw with code by introducing algorithms and computational concepts. A special issue of GRAPHIC magazine titled, ‘Introduction to Computation’ (no. 37), takes the initiative in presenting a platform for discussing a range of concepts related to computation as seen and used by contemporary graphic designers and writers. As guest editor and graphic designer for the issue, I invited and interviewed 12 practitioners and 3 curators / writers in the field of graphic design who had varying levels from none to expert in hands-on experiences of computation. The conversations pose a breadth of knowledge and opinions regarding the nature of computation in design process and any changes it presents for the role of the designer, essential topics that deserve a fuller examination and study. In particular, the idea that computation is system and logic for creative processes — a key to understanding and defining computation as a practice methodology, i.e. ‘computational thinking’ (Wing, 2006), for graphic design — was merely touched upon and demands further reflection and contemplation.

The editorial in GRAPHIC includes a brief introduction of computation and outlines the distinction between computer-aided and computational approaches, which underlies the subject of design authorship in the shifting of roles from crafting forms to designing systems. It contextualises the topic of integrating computation in graphic design practices in Karl Gerstner’s Designing Programme (1968) and Donald E. Knuth’s MetaFont (1979) that lead an inquiry regarding the impact of automation in designers’ systems. Nevertheless, despite their significant contributions to systematic thinking and making in graphic design practices, there have been only few graphic designers since then who built generative systems with computation. This may be due to the steep learning curve in programming or, perhaps, because designers are more used to processes of tangible form-giving than those of linguistic, immaterial and scripting-based computation. However in recent years, designers are increasingly susceptible to considering computation as a valid method for graphic design practice. The change owes to a number of different factors: 1) designers work with multiple layers of parameters on their software UIs; 2) designers build their own portfolio websites with HTML/CSS (some designers use Javascript to create and control events); and 3) increasing number of open-source high level programming tools (e.g. Processing, openFrameworks, Nodebox) are being developed and widely distributed. These factors have been significant in inviting designers to work with code yet, there needs to be greater effort to de-stress the current emphasis made on learning the syntax of code and, rather, to stress the focus on building logic with code.

In the interview with Catalogtree, a Dutch graphic design studio based in Arnhem, Joris Maltha made a bold statement, ‘programming is the graphic design process’. Whether this is an argument that equates programming and design process or one that claims programming as a valid methodology in graphic design practice need to be further discussed. Nevertheless, there is certainly a strong sense of assimilation that is made between programming and graphic design. This is generally a controversial subject since programming is a core element in the field of computer science. Yet it would simply be illogical to immediately separate computation from design practices today, since the majority of design products (e.g. web, app) are created, distributed and interacted through computational media. Of course not everything built with code is labeled as graphic design work, but if the intent of any project is led by and made for graphic design, then why shouldn’t we address it as graphic design? In my conversations with Andrew Blauvelt and Ellen Lupton, we discussed several graphic designers who use algorithms to create their own systems that are data-driven, generative and responsive. It must be noted that such dynamic and real-time features differentiate computational systems from non-computational ones. There are clear implications of the expanding horizons in the role of designers. Still, some may adamantly insist that anyone who uses computation in his or her process is a coder rather than designer. Jeroen Barandse at LUST, on the other hand, claims that making decisions on a range of parameters in code should definitely be considered a valid craft in graphic design. Even though such process poses a seemingly different experience from how we directly tweak the positions of vertices and colours of shapes, numeric parameters controlled with code are undoubtedly decisions made for graphic design. The way in which designers refine their designs may be different, comparing manipulating shapes or changing code, but they are both essential processes of considering form and formation.

Let us consider an example in music. Let’s say there are sounds composed with GarageBand (computer-aided) or generated with algorithms using MaxMSP (computational). Do we undervalue any one sound over the other, just because of the method used in production? The value of what is created does not depend on what method was used but, rather, on the music itself. Similarly, graphic design products do not have any restrictions as to what methods must be used in production. The integration of computation can simply be seen as a transition of epistemology in graphic design process, just as when software tools and digital printers first appeared during a time when hands-on typesetting for letterpress and screen printing were the dominant methods of production. Rob Giampietro explained that designers have started to embrace what we might previously have considered an engineer’s role. Following his thought, what was once a collaboration between design and engineering may be evolving to an inborn integration of the two.

Despite the changes in designer roles and their implications on the variety of tools and languages used in graphic design processes, what has been and remains consistent across time is the implementation of system and logic by graphic designers. According to Jonathan Puckey, logic that underlies any system is fundamental beyond any means and is, therefore, unbound to a particular time. Exemplary models of modularity are Albrecht Durer’s work (1525), Architype series made by Theo van Doesburg and Josef Albers at the Bauhaus (1920s) and Crouwel’s New Alphabet (1967), to name a few. Then what may systems using programming offer that is different? The most significant point of difference is that programming allows automation of rules and real-time generation of forms in response to data. This has shifted our understanding of process (system) and product (form). From the responses that the interviewees gave regarding their understanding of abstraction, I was able to gather that abstraction is understood not only as the modularisation or simplification of shapes (graphic abstraction) but also as the translation of visual structures into procedural objects for computational systems. In the latter case, instead of creating static swatches to make certain patterns, designers now can define objects that are conditionally transformative in response to user control and data feed. This is alike to how designers set tracking and leading for alphabets A-Z considering the harmonious interaction among them in a sentence or paragraph. Instead of working with pre-defined models in existing software tools, designers now can add or remove parameters (functions, behaviours) in their systems with algorithms. In other words, designers can use algorithms to create flexible systems, a process that is concentrated on iterative formation with parameters instead of a fixed end form. This resonates with Gerstner and his idea, ‘instead of a solution for a problem, programme for problems’, and presents a change in viewpoint from form to formation.

As designers start to build their own computational systems with code, they have the freedom to add or remove certain conditions and parameters. Andrew LeClair claims that, in this way, designers have become more independent with the use of computation. This necessitates a renewed inquiry regarding the role of system, which can be defined as a set of rules automated within the process that facilitate the process of generating formal variations in a consistent manner. In this way the system can continuously drive input from databases and interactions with users in real-time generation of outcomes, and sometimes autonomously through app, digital installation and website. To this, Jürg Lehni claims that the authorship of designers would be more concentrated on the manipulation of algorithms and data in consideration of generated outcomes. In other words, designers would place greater emphasis on the parameterisation of contents and contexts and integration of relations for building procedures in generation of form.

This leads to our final thought: do graphic designers always need computation? Erik Van Blokland remarks that computation is not omnipotent and not all tasks in graphic design can or need be carried out through computation. This is true if and only if we are to understand computation as programming, which yields automation in graphic design production. For instance, when designing something non- kinetic or responsive, it would be more efficient to draw with software tools instead of writing code. However if we are to understand computation as computational thinking, i.e. as a practice methodology that emphasises logic and systems in design process, then designers would certainly always benefit from computation. Along this line of thought, computation is simulating not only form but also the logic (=formation) with computers. In this way, we may be able to say that computation is design process itself.