In a panel at CCCC organized by Madeleine Sorapure and with Joanna Wolfe, I offered some of my thoughts (and personal data) on my current obsession: quantifying time. Specifically, I wanted to figure out how long it took for me to learn some software to support a potential pedagogical project. If you do digital composition, you know it takes a long time to learn programs and support interesting projects. But if you don’t, it’s hard for you to know. I’m trying to figure out how to communicate that a little better.
Before I go into the program and project, I’ll say: I think it’s important to communicate this time for a lot of reasons. On a purely selfish level, I want to be able to tell my tenure committee that I am investing a lot of time to do the digital pedagogy that my department values. From a departmental/composition program level, I think it’s important for directors to see how much time it takes to do this work so they can factor it in to any call for program-wide digital pedagogy imperatives. At the level of the field(s) of digital pedagogy, I think we need to be a bit more circumspect about diving into new projects until we know that they will be supported. As Stuart Selber writes in Multiliteracies for a Digital Age, “high-quality programs in computer literacy cannot be built or sustained on the backs of unsupported teachers” (224). Good digital pedagogy requires systematic support for teachers, and “should account for the fact that technology adds real layers of complexity with any project, pedagogical or otherwise” (226). Selber goes on: this support consists of not just equipment, but incentives, valuation of the work (beyond just thanks), training, and support from key stakeholders. Most importantly, at least for my work here, is that sufficient time be alloted for the labor. For many of us who teach with technology, this is a labor of love. But that doesn’t make it free.
We need to recognize the human labor of digital pedagogy—what resources we draw upon to work into our syllabi these exciting new digital ways of representing information, communicating, and participating. But recognition needs to go beyond just a call to attention. So in a little pilot study, I’ve attempted to quantify some of my own labor in digital pedagogy to attempt to peel back some of those “real layers of complexity” as well as articulate what “sufficient time” might look like. I ask: What resources does it take (for me, in this instance) to do digital pedagogy? And, how might we understand and communicate what those resources are?
First, I chose a project and piece of software. I decided to teach myself to use Adobe AfterEffects to do some kinetic typography. [Here’s an example with a lovely Ira Glass quote on creativity, and a fun example featuring Nicki Minaj’s Superbass.] I thought it might be fun to do that in a class sometime, and if I wanted to do it, I needed a better sense of the program and its capabilities to write up an assignment and support students in the work.
While I taught myself the program and the project, I tried to quantify everything I could–mostly, my time and other resources. I wrote down all of the things I could think of that helped give me a leg up on learning the software. (Well, I didn’t write down everything: my literacy, my flexible job, my luck in having good health, etc.) I kept track of all of the time I spent watching videos and learning the interface and working on a scratch kinetic typography piece.
By my count, it took me just over 22 hours to learn the program and project well enough to begin to feel comfortable using it in a class. (That counts the 2h it took me to procure the software, at a cost of $210 of my university-given research budget, because that time and money is also a resource.) I drew on a lot of things I already knew about complex interfaces, sound and image editing, timeline paradigms, font and design, and key terms to help me search the web when I got stuck. Someone who knew Adobe Final Cut Pro better than I did would have gotten to that level much more quickly; someone who had never used Photoshop might be banging their head against a wall for a lot longer than I did. Also, I still have a lot to learn about the program and the project of kinetic typography. I stopped at the point where I felt sufficiently competent, which isn’t to say that I know this stuff well or am any good at it. (At the bottom of this post, I’ve provided a lot more detail about my own learning process, for any of my hardcore fans out there.)
Here was what I could do after 15 hours, my first attempt at kinetic typography:
And here’s what I could do after 22.5 total hours (I chose a clip from Marshall McLuhan talking about The Medium is the Massage):
As you can see, I’m still not that good at it. But it’s competent work, and sufficient for me to support students’ exploration of a similar project.
So, what does this rather navelgazing pilot project suggest about learning the technologies that we teach?
Support for digital work in the classroom takes more time than the teaching of traditional textual writing, which we already know takes a lot of time to do well. It took me over 20 hours to learn a program well enough to feel comfortable writing up and trying out a new assignment in one of my classes. Importantly, there is no way for me to have kept track of the time it took me to amass the resources I had already to get up to speed in the program in that timeframe. Additionally, instructors need time to maintain and update any learning they do with digital software. Like students in first year writing courses, we cannot expect instructors to have a one-and-done model for learning to support digital pedagogy.
Working in digital spaces means that we must also be willing be bad at something for a long period of time—and as Ira Glass says (in this kinetic typography example), willingness to be bad at something when you know you’re bad at it, and willingness to work through that. Digital pedagogy takes a lot of trial and error and willingness to learn from your students or be an incomplete expert with them. Digital pedagogy, then, is not only a labor of time, it is also emotional labor.
Traditionally, the work of digital pedagogy has been done by those who enjoy it and who elect to do it–who spend a lot of their free time thinking about, learning and practicing digital composition for themselves. I’m one of them, and it’s work I like to do. But instructors of digital work also have other things we do with our non-work time—spending time with kids, house maintenance, travel, normal people things. Nearly every digital instructor I know feels crunched for time to learn and support this kind of teaching, and poaches from their non-work time in order to do it. That stress is widely acknowledged and shared among those of us who do this work, but is not readily apparent to those who don’t.
So here’s my point: We need to better communicate the kind of labor and human resources it takes to bring digital assignments into the classroom. To make this kind of digital labor more visible, we need good methods to catalogue and quantify it. The pilot lifelogging self-study that I’ve done here is one way to think about what those methods might look like. More carefully, rigorously, and quantitatively cataloging our labor will help those of us who work in digital pedagogy to articulate our work in the contexts of administration and constrained budgets. This articulation of labor will be especially critical as we consider programs that scale up digital pedagogy to include instructors who do not already do this work and who do not have the wealth of knowledge gained already through digital hobbies. I fully support digital pedagogy, and scaling it up beyond just the few instructors who already do it. But we must better understand the time and resources it takes to implement, and I argue that we must track those time and resources in order to better understand them.
More detail than you really want about my learning process:
Before I started this project, I knew these things:
- That kinetic typography existed and that tutorials were available online to help me learn how to do it
- How to record myself in Audacity (which I already had installed) use a mic (which I own already)
- The basics of Adobe Illustrator
- Some aspects of timelines from other time-based composition programs like Audacity and Final Cut Pro
- Some experience with design: fonts, arrangement, colors, theories (not practice) of animation
By the end of my first attempt, I had learned some rudimentary things about AfterEffects, including details about the interface. I learned how to:
- play sound while scrolling through the timeline to sync up words
- import items (although still some troubleshooting there)
- type in the interface and change position, font, color and other attributes of type
- make objects 3D, and move them along the X, Y, Z axes.
- Add a camera to move focus through the piece
- Control the camera’s postion along 3 axes and rotation (though not well)
- Preview and render the video with both video and sound functioning
In my first attempt, I ran into trouble in these areas:
- I couldn’t import a layered Illustrator file with layers intact
- Sound wouldn’t play while I scrubbed the timeline
- Camera wouldn’t recognize the 3D words I’d made
And I did some troubleshooting to isolate and fix issues:
- Googling keywords like: troubleshoot, import, render, scrub, two-node camera, point of interest, timeline, audio
- Opened new project (started over)
- Created new, simpler Illustrator file
- Played with different settings
- Asked husband the computer programmer (didn’t work)
- Watched videos very closely to see which settings were being used
Some of the troubleshooting worked, some didn’t. Those problems I just worked around. For instance, I didn’t use an Illustrator file to design the layout of the first attempt because I still couldn’t get it to import correctly.
In my second attempt (the McLuhan video), I ran into more trouble as I ramped up the complexity of the project, and I used similar troubleshooting strategies. I learned a few more things in the process, too.
Additional resources I drew on for my second attempt at kinetic typography:
- Time (7.5h beyond the first attempt)
- My knowledge of websites where I could get images and sounds to mix in (flickr creative commons search and freesounds.org)
- Math and coordinate geometry
- My knowledge of Photoshop
- Recording and editing in Audacity
Here are a few of the additional things I learned from the second attempt:
- How to pre-render and pre-compose to manage more complex composition
- Effects panels
- Improved work and understanding of keyframes (a common paradigm in time-based media)
- Offsetting time
- Updating source material in my project when I’ve edited it in another program (Audacity or Photoshop)
Things I ran into trouble with
- Increased complexity of animations loaded down my computer and forced me to think about workflow more
- Program crash and lost work
- Rendering issues
- Getting AfterEffects to recognize transparency in images
- Animating two layers together using a third null layer
- Bouncing camera paths (not quite resolved)
- Changing animation settings on preset effects
I made a few observations about the differences in my knowledge-gathering approaches from my very first attempt to my second. For instance, in my first attempt, I spent a lot more time watching general videos introducing me to what the software could do because I didn’t know the scope it. In my second attempt, I spent more time targeting particular problems I had, seeking out videos and explanations that would respond to my own goals and needs. I also played around more with the interface and effects without reading directions because I’d gotten more comfortable doing so. This process is not unusual—many education curricula are structured around the model of initial lessons, followed by independent work.