The Glow and Glare of Software

2004-04-06 19:22:00

How does one extract teaching digital media, tools, and processes from the host of variables one balances in becoming a graphic designer worth an agreeable mound of salt? One cannot—must not.

I will cheerfully, gladly admit that I like teaching software. I get excited introducing PS, DW, AE, Dir, Fla, and ID (ILL not so much)—heck, I get goose bumps. Teaching software is generally seen as that thing that a grad student should be doing or some hot shot that has no intention of developing a course; let alone a curriculum in digital media. It is not for a serious educator with better things to do. Well yes, have you noticed what an anchor the box can be? It can sink your students faster than you can.

Teaching software is a necessary responsibility choked full of amazing opportunities to explain all the high-brow stuff. Time and color are two mutant variables that are not easily mastered, but either make or break good/appropriate work. Taking time out from discussing the need for software to be user-friendly one will find a series of graphs and charts embedded in the software that will assist in explaining and gaining control of these elusive variables. One need not go much further than remapping of time and vector control in AE, shifting gamma in PS levels, and CMYK channels.

Students need to take an active role in learning the tools and media (this is make or break), but we as teachers also need to learn it to the degree that we can save our students time so that we can effectively and efficiently cover all the other (more important) stuff.

How do you teach software? Do you? Should you? What balance do you seek? Does it give you hives or goose bumps when you teach it?

posted by Tony Brock on October 9, 2005 | comments: 11 | post a comment

I am currently in my second year of the graduate program at NCSU. Here's my two cents, as a student, about teaching/learning multimedia software.

Discussions about multimedia software can be a valuable part of the counsel given to individual students during the ideation or story boarding stage of a project. Most students have access to a handful of programs that handle—in some capacity—video, sound, motion, and vector graphics. For students who are new to multimedia design it's often a challenge to figure out which software tools are best suited to the tasks that they have in mind. Class-wide tutorials are helpful, but they don't eliminate the need for some one-on-one technical discussion while a student is outlining his or her concept and process for a particular project. I consider the latter a step toward helping students learn to make the tools work for them, rather than just how to work within the tools.

As I said before, this is my perspecitve as a student. I'm curious about the pros and cons of this kind of approach from an instructor's point of view. I look forward to reading this discussion as it continues.

Posted by Jennifer Over on April 9, 2004 01:02 PM

I confess I get dog-tired thinking about all this software vs. DEEsign teaching stuff. Not because the questions are tired but because they are among the most pertinent to design education and are, lamentably, not easily resolved---at least as institutions perceive (and structure) design instruction to date.

Teaching software is ghettoized. Yet, when I was an instructor at Art Center teaching studios I recall criticizing the fact that software courses (Quark and Pagemaker or Photoshop and Illustrator) weren't taught by designers of consequence (1). They tended to be taught by the "tech" side of the house, which in the hierarchy of things seemed logical (and expeditious). Yet I felt that the mindset of the designer should dominate these courses even while they delivered the pragmatics of production. (2)

In that way maybe I'm old school. Literally. Think Bauhaus. Think Annie Albers teaching the loom and how amazing that would be. Teaching not technology but the consequences of technology. Jennifer's comment resonates: "...helping students learn to make the tools work for them, rather than just how to work within the tools."

Before the Bauhaus what might have been perceived as options for production of goods was limited (3). On one end of the spectrum was mass production and on the other end rote craft. The gap was taken up by craftsmen who proposed a hybrid. What if the crafters were the ideators? What if the massive mechanisms of manufacture could be conceived as chisels, shuttles, needles, blowpipes in the hands of technopiliactic conceptualizers?

Okay so I rarely if ever invoke the "B" school to ground an argument. And clearly I'll be doing penance to Mr. Meggs in future. But in that centennial consciousness way I can't help but see parallels between the aims of a 1919 Weimar school where master makers sought reconciliation between Machine, Craft and Concept (4) and today's search for a fluid stream uniting the now deified Concept with Craft and Machine.

Okay, no immediate solution. The hubris of the Bauhaus might have been the proposition that it had answers. Such is the modern way and I don't offer it here as a model. I'm just saying we are challenged with a different notion of manufacturing concepts and its relationship to the vagaries of making; different than 1923 certainly, and different than 1960. How will we as educators/designer's of consequence rise to the challenge?


++++++++++++++++++++++++++++++++
1.) I know I'm going to catch sh** on that, but hey, such is my lineage.
2.) As Tony points out, so called software courses might be those relegated to graduate students, akin to Literature Ph.D. candidates teaching composition courses. It's not that grad students don't promise to be designers of consequence; but the system is such that skills are distinguished from concepts. Grad students are in the business of earning the right to concepts by grunting through the skills.
3.) Consider that even in 1920 reactions against the rampant proliferation of cheap and ill-considered goods (a.k.a. Industrial Revolution) were ongoing.
4.) The writing on the wall then was automation...now it's CSS.

Posted by denise on April 13, 2004 09:14 PM

Denise brings up a parallel with the Bauhaus and its relatively innovative hybridization of craft with ideation or concept. I would suggest another historic comparison, the incunabula of 1450-1500. I appreciate this period because of its heightened sense of financial and cultural opportunity brought about because of the printing press without all the designer self-consciousness. Just as the early printers had no idea what part they would play in establishing graphic design as a discipline so to are we at a loss to see the results of digital technology. I think this cluelessness is healthy. I think trying to manufacture ways of making graphic design respond to this revolution is not.

I think the Bauhaus parallel is a good one. There was a formalization of how the designer would respond to the continuum of Machine, Craft and Concept. One thing I try to keep in mind however is that these categories are inherited and therefore their relevance post digital deserves serious re-evaluation. This is not to say we should ignore them, only to be aware that the impact of revolutions are always much larger than we can imagine. As designers, we have a hard time accepting the unimaginable. It is our duty, thanks to Mr. Gropius and his staff, to imagine, to envision and to propose. We are however always bound by history, to how precedent handled similar “looking” situations. Guttenberg changed reality as it was known by altering how ink hit a readable surface, but he could never imagine a sans serif typeface.

As for the question of digital technology in the design classroom, let’s stew in our incunabula for a while.

Posted by Will Temple on May 14, 2004 11:22 AM

I have been thinking about these issues in earnest lately, but it was a student designer that reminded me of this particular thread. So here it is resurrected.

Denise is on the mark—‘Think Annie Albers teaching the loom and how amazing that would be. Teaching not technology but the consequences of technology.’ This is the intimacy one must have with their implements of design. Pencil, loom, computer—the three have their individual roles in design production, but these ‘tools’ must be considered for their complexity and impact on the designer. And more importantly, the impact on the student designer proper.

The loom hints at it’s evolutionary roots in the computer, but the two are far from analogous. The computer adds many additional levels of stress and delight to the mere sense of a implement of production. It is a tool of production, a textbook teaching with dynamic illustration, a sketching space which can either severely impede creativity or enhance it in new ways, it is home calling at the end of the day, it is our journal, our file drawer, it is the synthesis of a much larger learning and making environment. It is a distinct medium fused of disparate media. In this light, have educators in design even begun to considered the cognitive impact of putting one of these vacuums in the teaching studio?

I see a striking compression in the undergraduate levels in many design course where more is the norm. Faculty far too often expect their students to mange greater numbers of variables within a single composition far too early. I find this to be in direct response to what computers can do for right or wrong. Computers not only allow for this mass synthesis, they encourage it. More layers, more colors, more effects, more stuff in a composition, more assignments—simply more. Software is not designed to simplify the choices one makes—it is feature oriented and software designers do not make a profit by removing features.

As software continues to add features and faculty continue to add more to the what they expect a student to produce, there is greater urgency to ask what values are instilled in the student designer who tried to juggle this chaos. What lessons are retained? What working relationship is established with these ‘tools of production’? I concede that this sounds all too starry-eyed and apocalyptic but I think it fits the absurdity that is developing without reflection on what is being learned—actually retained and understood with greater meaning not in spite of the computer but because of it.

(please note that I started this thread and I still get goose-bumps teaching software)

Posted by Tony Brock on October 9, 2005 07:40 PM

I want to start out this post by explaining my background as it pertains to my point of view in this discussion about technology within a design education. I came into the College of Design with an advanced knowledge of print design applications which I have gathered from internships (for graphic design as well as prepress), jobs, prior design education, and self motivated study. I find that this advanced technical knowledge has allowed me to observe and take note of how other students relate to and use these techonlogies during the production of their work.

Thinking about all of this actually reminds me of a related story from my childhood. My mother, when I was very young would always play the piano for me. When I became older and started to become interested in music, I wanted to take piano lessons. So, my father arranged lessons for me with the pianist from my church. I was so excited about lessons, and I was ready to put in all of the practice time required to learn scales, proper finger positioning, etc. All I ended up getting out of two lessons was how to play a trite, simple song—no mention of scales, proper finger positioning, or anything else I had expected/hoped to learn. Even at a young age, I was able to sense that I probably wasn't going to truly learn how to play the piano, just how to play a few songs. I've yet to take another piano lesson.

I find the idea of being taught software by "designer's of consequence" very interesting, and I think that ideally the best way to teach software is right along with capital "D" Design. However, I have been wondering if there are some over looked values in teaching students the nuts and bolts/ins and outs of software by tech guys/gals SEPERATE from the teaching of "Design." I think that since part of being a designer is the ability to synthesize parts—whether it be type and image, or concept and form—that ability to synthesize should be utilized in applying technilogical learnings to conceptual ones. I think if the basics of software are taught (and i mean REALLY taught) then that application to design is where the student designer comes in. I think to be truly successful at what you do you have to have a true understanding off the basics within your field, so that you can apply those basics to any and everything you work on. If I can flailingly reach back to the story above, I think it would better benefit the students to be learning the "scales and finger positions" of the software, as opposed to simply how it is used within a specific project.

I also invite the face to face discussion of this issue, as I feel more can be said and probably more clearly than I have stated above.

(I too get goosebumps learning/teaching software)

Posted by [sp] = Ryan Cook on October 14, 2005 10:55 PM

i'm going to be {not so}brief and {in}eloquent:

+ watching software tutorials is dull

+ working alongside a software tutorial is engaging and i learn from it

+ i prefer to spend my time in class working, critiquing, or having design-related discussion with my peers.


so-

+ i have to take the initiative to teach myself pieces of software

+ i have to get help on software pieces at times ( see above post )

+ i share the tech knowledge that i have to anyone who asks

i think a problem with this system is that not everyone is motivated (or tech savvy enough?) to teach themselves the technology that we are essentially required to use. I think it inhibits their process on some level. it leads to a lot of frustration and subsequent quitting. the computer becomes an enemy and not another tool.


my thoughts (apologies in advance if this is too ... rough?):

+ in the freshman year, a supplemental course that introduces the computer as an idea. why/how/when it is appropriate to use. where the tutorials are. where the books are. spark off a desire to learn earlier than before one is in the middle of three projects and at a breaking point.

+ this supplemental class idea could be implemented at any point. we have graduate students here that are, i believe, current on the tools and willing to help. above poster and myself have talked about leading (voluntary) tutorials on the pieces of technology; those have never come to fruition, but perhaps with the right support system in place.....

my basis for this is my experience in computer science: i never learned how to write software in a class. class time was devoted to theory, design, abstraction, and a lot of math ... labs led by graduate students - or older undergraduates - were where the details were hammered out. i'm certainly not suggesting that we abandon the bauhaus model in favor of the school of engineering, but i think that there is a pragmatic idea there worth mulling over...


it is important to me that my professors are pushing me to think more critically and consider more carefully. it is less important to me that they know all the new features of CS2 (although that's a nice touch!!)

i feel that with a little work, communication, and effort between students and faculty in this department (this thread certainly being the first step) we can resolve this issue without having to spend a lot of class time working on software exercises.

and finally - it is important to me that great work comes out of this school. i, and others, are willing to do anything that we can to make this department and this degree as significant and valuable as it can be/

Posted by lauren on October 16, 2005 10:49 AM

Ryan and Lauren: Thanks for your input! Encourage others to add to the thread. Cheers!

Posted by Tony Brock on October 16, 2005 12:20 PM

It is very important that students learn how to use the tools of design from a person who understands design theory and concept. Anyone with a mouse can use and learn photoshop, but only special people can use programs to construct aesthetically pleasing and effective messages. I am so sick of people claiming to be designers because they "know" photoshop (or any other program)" and designs artifacts that are both ineffective and ugly (yes I said it.)

Software does not equal design.
Software +Questions+Pushed Boundaries x Aesthetics^2=Design

We need professors to teach the programs along side with design theory: this can only make the student's work better.

Posted by Shanthony Exum on November 7, 2005 09:50 PM

hi hi. pk from chicago here.

su and i both are constantly on the lookout for new plugins, new filters, new micro-applications, or whatever. we particularly like it when we can break our tools and make them do things they shouldn't.

example: su wrote a great piece about his internal monologue (you know, the voice with which we all speak to ourselves) and how others invariably misinterpreted his personal thoughts. he wrote the piece, translated it via (babelfish.altavista.com) into several different languages and then translated those translations back into english, then stitched components back together to create a more interesting verbal rhythm for the piece. it was a great way to illustrate how ill-equipped another mind might be to try and look into his without any sort of prior experience.

tools should very much be part of the conversation in tandem with ideation. if su hadn't had the mechanical process of machine-translation to rely upon, the piece would've been a lot more mundane.

when you separate the tool from the idea, you end up with this factory-like process that honors the idea, but then sends craft to the corner to wait its turn. that's pretty much the same way ad agencies work, and why so much agency work is so heavy on writing but light on visually-designed thought -- the writers can insert their craft on the fly in a concept meeting. designers can't.

Posted by pk on December 21, 2005 04:29 AM

I think it's essential to teach software to students, and they really want to learn it. I don't claim to be an expert in software myself, but I do what I can to give students the resources they need. In basic courses, it's easy to create projects that are designed to developed technical skills. Hey, isn't this what design problems always did? Only the tools have changed.

Posted by Ellen Lupton on February 18, 2006 07:18 AM

Tools, software...I may have read all of these posts too fast, and the discussion may have ended months ago, but as a newly minted professor from RISD facing the realities of introductory experiences in digital environments (in the Middle East no less), I'm not really looking for students to gain specific skills, more so, specific points of view. The digital embodies, not represents, a fundamental shift in the way we relate to information, image, meaning, authorship and many other issues of great import to any designer, graphic or otherwise. I don't get goosebumps, I don't get hives from having to introduce the idea of software, but I DO get goosebumps when my students come to the realization that BIOLOGY is the ultimate technology, and the digital is not a tool or code or anything else, but rather a fundamentally different environment that the real. In this sense, there is no virtual, only a different real, if that makes sense. I think what we need to focus on as educators responsible for a valuable experience is the transition from one environment to antoher, and what is the nature and impact of that transition as a process we can navigate, manipulate, tease and taunt.

Posted by Roddy Grant on June 16, 2006 06:06 AM