OPEN DESIGN NOW / Learning By Doing

Mushon Zer-Aviv describes his efforts to teach open source design as an attempt to investigate why collaborative work combined with individual autonomy has not been common practice in design, as it is in open source software development. He discusses whether what worked for code might just as easily be transferred to design: the physical object as binary structure.

I have been teaching open source design since 2008, in an attempt to figure out whether it can even exist. This article is an opportunity for me to reflect on and share my latest failures and successes in teaching what has yet to be learned.

I was first exposed to the open source world as a user of some free software; it was only later that I was introduced to the idealistic arguments about Freedoms, as a more abstract principle. This combination of collaborative work and individual autonomy intrigued me. Coders were developing appealing political structures that were fostering creativity, collaboratively. I envied that degree of creative freedom; as a designer, I live in fear of ‘design by committee’.

Don’t designers know how great free collaboration can be? Are they too afraid of trying? Do they just need a helping hand? Or is the problem that what works for code just doesn’t really translate into the design process?

Inspired by these initiatives, I started my own open source project, co-founding ShiftSpace.org; I took part as a designer, collaborating with Dan Phiffer, a coder. It was my enthusiasm about open development that inspired me, but I was surprised to find that this excitement was not shared by my fellow designers. Don’t designers know how great free collaboration can be? Are they too afraid of trying? Do they just need a helping hand? Or is the problem that what works for code just doesn’t really translate into the design process?

I set out to answer these questions, but trawling through online resources did not yield enough satisfactory writing on the subject. Many discussions confused sharing with collaboration, or were trying to advocate the use of open graphics software for purely ideological reasons. These arguments did not convince me; I was fairly sure that the ideological stance of coders could not be the only element that makes ‘Free Software’ such a desirable practice. Similarly, there is no intrinsic sociable instinct that leads coders to one another. The networked collaborative model of Free Software for coding is pragmatically the best way to go; any other way just makes much less sense. In this context, ideological reasons are secondary to simple pragmatism.

An Open Design Lab, with My Students as Lab Rats

It might be that we just haven’t found the right way to transcend the design process; it’s not as if we’ve tried all that hard yet. Art and design schools still nurture the image of the genius as an individual artist. Originality is rewarded as a higher standard than communication, and copying is considered a sin. I figured the classroom would be the first place to start, so I proposed a class for the Parsons School for Design entitled Open Source Design. I assumed that our exploration of design based on Free Software methods should probably start with interface design, since interface is an integral part of most of the software we use. My hope was that I would be able to convince my students to contribute their design skills to some projects – have them get hands-on experience working on real projects while actually making some actual (and much-needed) contributions to Free Software.

To drive home the point about collaboration (and to scare off any students who might not be ready for the bumpy ride), I decided to kick off the first class with some bold statements:

“In this class, we’re going to explore the possibilities of Open Source Design while learning HTML, CSS & WordPress theming. However, I should warn you that I don’t have much experience in HTML & CSS, and I will practically be learning WordPress for the first time along with you guys.”

You can imagine the looks on their faces. Luckily for me, only some of them left as soon as the class was over. My approach to this class was different than what I had done in previous classes I had taught. Rather than teach the students to use the technology, we learned how to figure things out on our own. Rather than memorizing every HTML element and what it might be good for, we learned to use Firefox and the Firebug extension to inspect the source code of every site. Open source made sense immediately when the students could read the HTML code of any page like an open book. Unlike in other classes, the students were encouraged to copy, to analyze, to understand and to implement code and design patterns they found on the web.

To look at grid-based design, we used the Blueprint CSS framework; for WordPress, we used the Sandbox and Thematic framework themes. In both cases, the students based their work on previous design decisions coded into these frameworks and explored ways of modifying the code or design to fit their needs. We were using design foundations that were strong, but at the same time easy to modify. It made sense to the students; they understood why the concept of openness might actually be relevant for them.

Teaching vs Learning

Like many other design educators, teaching is one of the ways that I can stay up to date. I am required to constantly keep myself informed, constantly learning and make sure I actually understand new subjects enough to teach them. That is also a benefit of being involved in open source initiatives. The professional exchange between coders facilitates a sustainable peer-to-peer learning environment – and one that extends beyond the structures of institutional education. To extrapolate, if I learn by teaching students and geeks learn by teaching each other, maybe my students can learn that way too.

The first assignment in my class was ‘The Tutorial’. Students were required to create a (non-digital) tutorial on something they already knew how to do, preferably a topic that others might not be familiar with. They exchanged tutorials in class; over the following week, all the students had to follow the guidelines provided by their peers and report to the class on their experiences. The students wrote tutorials on such topics as ‘How to curve a football’, ‘A recipe for banana bread’, ‘DIY 3D glasses’, ‘Finding an Apartment in NY (Without Paying a Broker)’ and ‘How to Sell Multiple Pairs of Shoes’. A tutorial is an involved interactive design task, even when the tutorial is not digital. It also provided a framework for the semester that was constructed around knowledge sharing, documentation and peer learning.

Art and design schools still nurture the image of the genius. Originality is rewarded as a higher standard than communication, and copying is considered a sin.

Tutorial hunting has become a substantial part of the semester, as tutorials become a major source of pooled knowledge. We used a class mailing list where students could submit technical questions and ask for creative feedback. I encouraged them to post their code and questions on the blog and refer their peers to the relevant blog post from the mailing list. However, in many cases, a code snippet was not enough to get the full picture, reproduce the problem and help solve it; we needed to share the full code repository. I was concerned that getting the students on a version control system would be pushing them just a bit beyond the geekdom level that design students could handle in one semester, but it became unavoidable. I set them up on a centralized Subversion code repository, so every student would get every code update downloaded directly to their computers. They shared all the code by definition and could modify each others’ work when needed.

This worked well, but it had an unacceptable side effect: at the end of each semester, the class code repositories created in that semester would be left abandoned. Symbolically, each class became an abandoned open source project. Obviously, that was not the message I wanted to leave the students with. I recently gave up on the Subversion system, which used centralized version control, and got my students on Git and the Github.com ‘social coding’ site. On Github, the students publish their code in public and other users (not just the other students in the class, but also other users) can easily fork, merge and comment on the code. When the semester ended, the students maintained control of their own repositories, beyond the context of the class.

Pragmatic, Not Altruistic

By that point in the semester, I have managed to convince the students why free and open source content available online is relevant to them and will advance their creative work. But that was the easy part; I have not yet managed to convince them why they should contribute too, why they should give back to the commons.

I initially set up the final assignment of the semester as an arbitrary task: “Find an open source project, and contribute to it as a designer.” I was naïve, to say the least, and this ill-conceived task failed miserably. My students didn’t really understand the projects they chose, and the geek-talk on the mailing lists was incomprehensible jargon to them. The communities they approached did not have a frame of reference to appreciate the students’ contributions and were suspicious of the students’ motives. The first semester of the Open Source Design class ended in disappointment; it was clear we were on the wrong track.

In the following semester, I understood that assigning an arbitrary contribution was the wrong way to go. I had a smaller class that time around, and we chose to work together twice during the semester. First, we took part in the WordPress 2.7 icon design challenge. Later, the students chose to help some of their friends get their portfolios up online using the Indexhibit system. They wrote tutorials, they recorded screen-capture videos, they wrote code examples and style comments. Finally, they posted their contributions on the class blog and on the Indexhibit forums. Back then, the documentation available for Indexhibit was lacking and the students’ work was well received.

The second attempt had worked much better than the first one, but I knew its success had a lot to do with the qualities and personalities of the students in class. They enjoyed working together but at its core, the Indexhibit documentation was still a relatively altruistic contribution to a project that they were not actually planning to use after the class ended. If they were not going to benefit from their own contributions, why should they contribute again once they were no longer required to for a group assignment?

In the following semesters, I guided students to write the kind of tutorials they would have liked to find for themselves. Their tutorials focused on CSS, WordPress, Github… environments they used for their own benefit, in their own work. They not only covered the technical side of the technologies they documented; they also looked at the design aspects. At the end of the semester, the blog featured valuable, peer-reviewed and tested tutorials that benefited the students who had already completed the class. Months and years after each of these semesters ended, these publicly available contributions constantly receive thank-you comments from random users on the web. And still, it was not enough yet.

Toward a Collaborative Design Process

As far as knowledge sharing is involved, the tutorial approach has indeed proved itself. However, sharing technology and design tips is not collaboration. In this context, sharing has been happening post mortem to the creative act. To really challenge the design process and discover whether design can enjoy the benefits of the networked production revolution, I needed to focus my efforts on design collaboration.
Writing a wiki and coding software both benefit from a highly collaboration-friendly technology: text. Both types of content generation use a vocabulary predefined by language, which levels the playing field for the various contributors. It poses implicit prerequisites (literacy) and it funnels the contributions through a finite list of the syntax options standardized by language. For better or worse, both visual and behavioural languages are not confined within such rigid structures. Ironically, it is the openness of these languages that makes networked collaboration harder.

In the last few decades, interface design emerged as an important cultural practice. There have been many attempts recently to coordinate and standardize this new language. The critical discussion of interface linguistics does not happen in the academic arena, it happens in the blogosphere. These interface linguists document design patterns and evaluate best practices for following them. Many of them are advocating semantic content and structured data, claiming such approaches would support efforts to index and process this content. The aim here is to serve artificial systems that are not intelligent enough to derive the meaning without external assistance. At the same time, these index-based and component-based approaches help structure the creative process as well. We see it in Wikipedia, where the way that articles are structured helps to focus and process the collaborative act. We see it in the structure of Cascading Style Sheets (CSS), where design decisions propagate through the document’s structure. And we see it in interaction modules, where code libraries encapsulate a single action which can still be modified externally through APIs.

The critical discussion of interface linguistics does not happen in the academic arena, it happens in the blogosphere.

The next frontier for the academic collaborative design lab that my students and I have been leading would have to involve the linguistics of interaction design. We will start drafting characters, then words and then sentences; some might call it building a structured visual language. We will try to define a syntax, then rearrange it and try again; some might call it designing modular systems. We will try to set standards, then extend them, then break them; some might call it developing a design guide. We will try to evaluate the legibility and readability of our messages; some might call it usability testing. We will try to discover a new collaborative paradigm for the design process; some might call it ‘Open Source Design’.