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 rule-based system that has been present throughout the history of graphic design. 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 mainly focus on teaching readers how to draw with code by introducing algorithms and computational concepts, rather than investigating how computation might have impact on design process, for example, by offering computation as a material and process for building systems and logic for creative processes. 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 twelve practitioners and three curators / writers in the field of graphic design who have varying levels from none to expert in hands-on experiences of computation, with whom I led conversations that 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.
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 algorithms 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 that summarises what computation is to their practice: ‘programming is the graphic design process’ (Shim 2016, p. 104). Whether this is an argument that equates programming and design process or one that claims programming as a valid methodology in graphic design practice needs 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 a 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 colors 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.
The integration of computation can simply be seen as a transition of epistemology in graphic design process. Rob Giampietro explained that designers have started to embrace what we might previously have considered an engineer’s role (ibid., p. 14). Following his thought, what was once a collaboration between design and engineering may be evolving to an inborn integration of the two. Perhaps, our understanding of craftsmanship in graphic design extends to include both direct engagements with our medium and indirect simulations of logic. Despite the changes in designer roles and their implications on a variety of tools and languages used in graphic design processes, what has been and remains consistent across time is the implementation of logic through system 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 (ibid., p. 62).
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 might 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 and product. From the responses that the interviewees gave regarding their understandings of abstraction, I was able to gather that abstraction is not only modularization or simplification of shapes (graphic abstraction) but also 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 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 solutions’ (1968, p. 12), and presents a change in viewpoint from design as the building of form to that of 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 (Shim 2016, p. 38). This necessitates a renewed inquiry regarding the role of system, which can be defined as a set of rules automated within the process that facilitates the process of generating formal variations in a consistent manner. 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 (ibid., p. 28). 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 (ibid., p. 74). For instance, when designing something non- responsive or repetitive, building a system with code would not be required. However, as van Blokland pointed out, as long as the design problem can be abstracted into algorithms, computational systems will stand at the center of graphic design process. Computation, then, might be the design process itself.
Gerstner, K., 1968, Designing Programmes, 2nd edn., New York: Hastings House.
Shim, K. (ed.), 2016, Introduction to Computation, GRAPHIC Magazine, 37, Seoul: Propaganda.
