Canvas and Code
by Sean McCrohan, Ryan Sims, Celine Ulgado, Kevin McDonald

Introduction
As increasing numbers of visual designers enter professions associated with software development, they must adapt to a rapidly changing skillset. In addition to understanding and conveying basic design principles, they need to learn to communicate with software developers and computer scientists in the effort to transform ideas into computer-generated realities. A priority: the ability to understand and utilize the lexicon of the programming world. In essence, designers must be able to " talk theand walkin their interactions with software experts. Acquiring this knowledgehoweveris easier said than done.

Objective
Our goal in this project is provide a seamless and efficient method for designers to obtain this knowledge. An influential directive: we seek to mitigate the apprehension designers might associate with programming. How can this be accomplished? By introducing programming in a familiar context - the studio environment. We propose a constructivist tool that draws upon the work done by Mark Guzdial in EMILE and John Maeda, the director of the Aesthetic Computing Group at the MIT Media Lab. Named Canvas and Code, our solution is an environment in which designers can reduce apprehension while both developing a foundation in programming and furthering their design education. To clarify, learninga programming language is not as important as exposing the designers to the lexicon of coding. In essence, our solution is a preprogramming course that introduces the world of programming in the security of the familiar environment. We are not looking to produce expert programmers; instead, we are enhancing the skills of designers and giving them a solid programming foundation. Ideally, this should enable them to more easily master whatever programming skills they choose to pursue later.

Target Audience
In a sense, we are the target audience for this project. We are all affiliated in some fashion or another with the Information Design and Technology program here at Georgia Tech. Most of our group would probably consider themselves more designers than programmers. But as we begin to consider careers in this field, we are all realizing we must have a basic understanding of programming in order to communicate our ideas. For one reason or another (fear, non-interest), several of us have avoided taking a programming class in our educational experiences. This doesn't mean we haven't been exposed to programming, it just means we haven't taken a formal class. This project is an attempt to change that situation.

Not wanting to rely solely upon our own experience (beware the dangers of the designer's ego), we informally polled some of our colleagues in the IDT. What did we learn? Since we are targeting designers, rather than computer scientists, the learners’ uncertainty over attempting to learn a programming language is fairly high. Most of these students approach the notion of learning a programming language with apprehension at best, and dread at worst. When pressed to elaborate, common responses included, "Oh, I don’t have the analytical mind for programming” or "I would be afraid I would look incompetent if I were incapable of completing a program." So, the fear of looking foolish plays an influential role in designer’s reticence to learn programming. That should come as no surprise given some of the experiments we have reviewed in the readings throughout the course. What is more interesting, perhaps, is the first sentiment: I don’t think like a programmer, so I won’t even attempt to learn how to program. We believe that if this particular notion is addressed, designers can not only learn to program, they can actually thrive at it.

Our target audience is drawn from the pool of visual designers with the imperative to learn the fundamental concepts of a programming language. In our project, the particular programming language is not of great import. Rather, it is the environment in which that language is taught that warrants our attention. Our goal is to provide an environment in which designers can feel truly comfortable learning to program. In this instance, we are attempting to tie the learning experience to an environment designers already know: the studio class experience. Most of the designer's training and learning occurs in the studio classroom. Students observe experts performing a critical skill and then are given the opportunity to try it on their own. Work is produced and displayed for constructive criticism and iterative revisions. This studio environment encourages collaboration, critical skill development, and, most importantly of all, the creation of a design artifact.

In the development of this final project, we had the opportunity to review the current state of affairs in the IDT program. We conducted a brief discussion with a second-year IDT student about the Advanced Multimedia course offered during the fall quarter of 1998. The objective of the course was for students to develop a mastery of Lingo (a scripting programming language associated with Macromedia Director) in the creation of a cogent, well-designed interactive artifact. During the discussion, the student reflected on the advantages and disadvantages of the class:

Pros

Cons

In reviewing the student’s comments, we hope to replicate the positive aspects of the experience while negating, or at least limiting, some of the disadvantages. Therefore, the objectives our project require the following elements:

Our Solution Canvas and Code is our proposed solution. It is an environment in which designers can utilize a simple programming language to create visual artifacts. We have included some screenshots and descriptions in the next section.

The class environment is meant to reflect a studio art class. The enrollment should be limited to a small population to engender a sense of collaboration and critical thought. There should be an expert knowledgeable in both the design and programming fields. We discuss the role of this expert in more detail in the Teacher Requirements section. Before the student sits down to the computer to use Canvas and Code, the expert has lectured and demonstrated a solution to a sample problem. The expert then gives the assignment for the week. Students refine their skills by working on these assignments in the lab section and on their own time. At the next class meeting, the group gathers together and individuals demonstrate their assignments. This collaborative session is essential in the studio environment, allowing students to hone their critical skills and defend their design choices.

Sample Assignment
The type of assignment is important to our design. Here are examples that increase in complexity (as the semester progresses) but all ask for creative, visual solutions.


Fig. 1 In the lab the student opens up their project. Here we see the main interface in which students will design.



Fig. 2 Before beginning their work, the student opens the Design Notebook. Patterned after the notebook in Guzdial's EMILE, it can structure the task. This screen asks the student to describe the design goal for their project before they begin coding. The student can find other examples and projects that are similar and describe the reasons why they are similar (or dissimilar).


Fig. 3 Here is what the student found.



Fig. 4 Another step in the design notebook is explicitly stating what visual elements will play a role in your project. The student can browse objects in the language that might create the desired visual element.



Fig. 5 Another look at the main workspace.



Fig. 6 The final step in the design notebook happens after the discussion of the student's work. The student reflects on what was said about their design and how it could have been improved from both a design and code standpoint.

Teaching Requirements
In determining what the teacher's needs and roles are, we first acknowledge that the teacher is an integral element in the proposed learning environment, rather than just a live "user guide" of sorts to help the students through the technology. We base our determination on existing courses that attempt, on one level or another, to teach either graphic design or programming. Our own experiences in one or more of these courses helped us identify the needs and roles that the teacher has.

First, the teacher must be an expert in both visual design and programming. Only expertise in both areas would suffice for the proposed learning environment to be successful, as the teacher will be depended upon to provide clear direction, guidance, and scaffolding as the course progresses.

Second, the teacher must be able to provide structured activities for the learners, so that the results of these may be reviewed in the context of the course objectives, and in the larger context of design and programming principles. The teacher would also need to be able to synthesize the exercises and activities in a meaningful way.

Third, the teacher needs to be physically present in the class (as opposed to conducting the course off-site or on-line), so that the studio environment is truly created and utilized. The teacher should be able to hold discussions about the work created and the exercises completed, providing coaching when necessary. Scaffolding in the proposed learning environment comes in the form of a live teacher, not in a collaborative web space or data bank of past work or knowledge.

At the moment pedagogical practices are still dominated by the information transmission method, rather than the motivated learning-by-doing, collaborative method that would drive our proposed learning environment. But while there seems to be no educational curriculum that addresses the need of the learners we are targeting, our proposed learning environment is to some extent already at work in LCC's Multimedia Design courses. The studio environment in the computer lab demonstrates that it is possible to teach in an open, informal environment that is collaborative, creative, and critique-driven. The existing technology infrastructure to help support this environment already exists. And although the existing course emphasizes design, not programming, both the infrastructure and the culture setting of the studio/classroom are easily adaptable to what we envision.

Evaluation Plan
In considering evaluation methods for this project, it is important to keep in mind both the long-term and short-term goals. While Maeda’s work suggests that teaching designers to program will eventually increase their skills at design, that impact, though desired, is a secondary effect and may not be immediately apparent. The short-term, observable outcome the program is intended to achieve is three-fold. When compared to students from similar backgrounds undertaking traditional-style programming instruction, our students should:

The actual effect of the program on all of those traits will need to be evaluated, both for the purpose of presenting them to faculty and administrators and for use in refining and redesigning the program. Faculty and administrators in the field of visual design are strongly divided over the use of technology, with some enthusiastically embracing it and others regarding it as a necessary but unwelcome intrusion into a traditionally creative and artistic discipline. Support for the program may depend upon demonstrating that programming can be a creative endeavor that fits within the traditional structure of visual design instruction.

Formative Evaluation
Given that design students and instructors have extensive experience with performing group critiques, experience that could be usefully directed at pointing out flaws in the program itself, a ‘discussion group’ technique would be an ideal formative evaluation. Additionally, the design notebook will provide opportunities for learners to record difficulties they encounter with the interface, for later review by the designers. Further formative input has taken the form of interviews with potential learners, to develop more detailed pictures of learner needs.

Summative Evaluation
A collection of projects completed by students over the course of the class would be a qualitative demonstration of effectiveness, potentially persuasive to faculty members. Project assignments should, naturally, be chosen so as to demonstrate the relevance of programming skills to the discipline of visual design. Since traditional computer science classes are not taught with design skills in mind, comparison against projects completed in those classes would be meaningless in this case. The quality of the projects, ideally, will be able to speak for itself without comparison to other classes.

To evaluate the first desired outcome, increased knowledge of general programming concepts, a straight-forward test of that knowledge can be administered to design students, both those who have taken the preparatory course and those who have not. This test should not present the concepts using the same language as the course itself, as that would be unfair to those students who did not have the preparatory course, and would be a poor test of potential transfer for that knowledge.

In order to address the second factor, self-efficacy and a sense of programming as being a relevant skill-set, pre-instruction and post-instruction questionnaires can be administered to design students undertaking both the design-oriented and traditional programming classes. Questionnaire items would ask for attitudes towards programming and the use of technology, attitudes on the relevance of programming to design, ask how likely the participants feel they are to make use of their programming skills on design projects, and ask for self-reports of confidence in their ability to program effectively.

The third goal, increasing students' abilities to work with computer professionals, is more nebulous than the previous two, and would be best evaluated in a qualitative fashion. Design students - again, both those who have taken the preparatory class and those who have not - could be assigned to work on projects with partners who are computer science students. Their interaction and teamwork could then be assessed by an observer, as well as by self-reports from the two students.

Conclusion
While the need for actual programming ability, and the variety of programming skill needed, will vary from designer to designer and from job to job, it is becoming increasingly likely that visual designers will encounter some form of programming in the course of their work. We hope that by leveraging off the existing tradition of studio environments for instruction, the solution we present can address the need of today’s visual designers to understand programming concepts while working within the context of the traditional educational environment for design. In such a way, these skills can be made relevant and familiar, rather than continuing to be perceived as mysteries accessible only to the initiated.