Deconstruction/Reconstruction: A Pedagogic Method for Teaching Programming to Graphic Designers
Note: The method is described in greater detail in my GA2017 paper and its accompanying presentation (see video below) given at the conference.
Being code-literate is considered a crucial ability in today’s society. Permeating through all parts of contemporary culture, this view is also influencing the education of graphic designers, prompting students to recast their existing skills to fit the medium of the code and educators to develop new courses that help build this literacy. As a contribution to this ongoing work, I propose a hands-on experiential pedagogic method, deconstruction/reconstruction, specifically designed to introduce graphic design students to programming in a visual context.
Method explained
The deconstruction/reconstruction method consists of two successive phases, deconstruction, and subsequent reconstruction. Each phase has three steps. Activities associated with each step are briefly described in figure 1 and discussed in greater detail in my GA2017 paper.
Figure 1: Schematic overview of the deconstruction/reconstruction method.
The purpose of the deconstruction phase is to keep the students in their comfort zone by letting them rely on their pre-existing knowledge of graphic design principles and terminology to deconstruct an existing design product to form the basis of the reconstruction phase. The purpose of the reconstruction phase is to let students discover programming as a practical craft acquired by incremental conversion of their notes from the deconstruction phase into code, thereby constructing a self-contained design system capable of reproducing a chosen specimen, and acting as a platform for playful discovery through manipulation of variables and the code itself.
Material
As its main material, the method relies on pre-existing commercially applied graphic design specimens (e.g., posters, packaging, logos, typography, signage, bank notes, stamps). Specimens are handpicked based on their ability to be deconstructed, meaning that they must exhibit distinct visual characteristics indicating that an underlying system or set of rules has played a key role in their creation. Specimens should be easily replicable using geometric primitives, basic linear transformations (e.g., translation, rotation, scaling) and control flow statements (e.g., decision-making, looping, branching). A selection of suitable specimens that meet these criteria is shown in figure 2 to provide an idea of the visual genre.
Figure 2: A selection of specimens exhibiting visual characteristics that make them suitable as material for the method
Using pre-existing specimens resolves several issues at once: It establishes a direct link between programming and design, introduces a relatable "object-to-think-with" that doubles as a fixed target, thus eliminating the risk of students losing focus by being having to make aesthetic choices.
Method applied
The deconstruction/reconstruction method has been tested on three introductory programming courses taught at The Danish School of Media and Journalism, where it was used as a recurring daily exercise in the course’s first week. Every day, each student had to complete steps 1-6 to reconstruct – in code – a specimen chosen from a provided sample set of 20 pre-existing graphic design specimens taken from a curated collection. An example set of specimens given to one class of students is shown in figure 3.
Figure 3: A collection of chosen specimens taped to the blackboard in the students’ studio.
Initially, the students felt confident as they began to describe their chosen specimen. Trained observers of graphic design, they had few problems describing the immediately visible components. They also spontaneously developed the habit of using Photoshop's eraser and cloning tool to remove all design components besides the background and typographic elements. This provided an authentic background to import in step 4 to make the output look almost identical to the original specimen as shown in figure 4.
Figure 4: Separating design system and background. The design system is recreated in Processing. An ”empty” background is created in Photoshop providing an authentic background.
Students began leaving their comfort zone when asked to explicitly describe the math, logic, and rules of their chosen specimen. Certain relations and behaviors were easily described using basic mathematical principles (e.g., sine/cosine, Pythagoras, linear transformations) while others relied on formulas or phenomenon one could not expect the students to know beforehand (e.g., Fibonacci series, recursion, moiré).
Figure 5: Students are encouraged to make sketches using paper and pen to aid them in their process of understanding and formalizing the math, logic, and rules behind the specimen they are trying to recreate.
Launching Processing and converting their notes into code, students gradually discovered how variables, arrays, functions, classes, as well as other programmatic building blocks, helped them extend their static system to become a fully functioning, dynamic system capable of replicating the original specimen. This step was – without a doubt – the most challenging step for the students. They spent the majority of the time working on the daily assignment completing this step, slowly grasping programming logic, structure, looking up syntax in the language reference, and tracking down bugs.
Next, students used Processing’s ‘Tweak Mode’ or simple GUI’s to manipulate variables in their code with instant visual feedback. They would bend, stretch and inevitably break their programs. Immersing themselves in playful experimentation, students kept generating new variations from the seemingly infinite number of possibilities, always curious to discover what output their system would generate next.
Figure 6: Exploring the “mechanics” of reconstructed design system by altering its variables to produce new versions of the original specimen.
Students were asked to keep a visual log of their progress to show the extent of the visual diversity that their system was capable of producing. Examples from a students' visual log are shown in figure 7.
Figure 7: A students attempt at reconstructing the original specimen (big image, left) using code, and his subsequent experiments modifying the identified variables and the code itself to produce radically different versions (small images).
Finally, students began to modify the code itself. Through this process, students discovered that code, although immaterial and intangible, still possess plasticity and is highly malleable. Their confidence in their abilities grew, and this kind of tinkering and hacking was encouraged to support their urge to experiment.
Figure 8: Extending the look of the reconstructed specimen by modifying the code to include rotation as an adjustable variable.
Concluding remarks
Supported by an overall positive student response expressed in follow-up plenary interviews, the method appears as a promising way of introducing graphic design students to programming in a visual context.
Students entered the programming course with skepticism and anxiety, but introducing the deconstruction/reconstruction method and explaining how it relied on familiar and well-known material defused the student’s immediate aversion to code. Additionally, the students also appreciated being given a real-life case as a starting point and step-by-step method to guide their learning process.
Though praised by the students, it can be argued, that repetitiously remaking work done by other graphic designers does not stimulate them to synthesize their knowledge into new independent creations. While this might be true, the deconstruction/reconstruction method is primarily designed to keep students engaged and motivated while introducing them to the nuts and bolts of programming. If students, by the rote learning and repetitive practice implicitly inscribed in the method, manage to cognitively link visual patterns with basic programmatic techniques, they have established a solid basis for taking full advantage of the creative potential of computational media in their future line of work.
Contact me:
Stig Møller Hansen
Ph.D. Student
Department of Digital Design and Information Studies, Aarhus University
Interactive Design Program, The Danish School of Media and Journalism
;){kind=link}