Google Docs is an example of “software as a service,” a document-sharing, cloud computing service. Unlike most document-sharing services, Google Docs does not require any user fees. Google Docs allows people in different locations to collaborate on documents, presentations, spreadsheets, and forms.
All files are stored on the Web, in the Google Cloud, rather than on individual hard drives, and any editor or viewer of a file can add other editors or viewers, so a number of collaborators can make changes to a file without having to e-mail each other updated versions.Google Docs is like a free version of Microsoft Office that lives online, with files that can be opened and edited on any computer with Internet access.
Google Docs launched in 2006, and I began using it in 2007 as a tool for producing scholarship. I was living in Chicago and was able to work with an Australian scholar on a piece about fan cultures and then share it with another scholar in Boston by creating a Google Doc and giving editing and viewing privileges to my collaborators. Since then, I have collaborated with a number of other colleagues and friends via Google Docs, co-creating everything from budgets to conference abstracts to slide decks for important talks with potential funders. My collaborators may be located in other cities or countries, or simply in a different room of my building; online co-authorship works just as well and has proven to be just as useful when I am geographically close to my co-writer(s) as when we are separated by a great distance. I’ve also used the service for files that only I access, since storing files in the cloud and being able to access them from anywhere is often far more convenient than carrying around an external hard drive with all of my works-in-progress and trying to remember to sync all of the files on my work and office computers.
Google Docs has also become an invaluable teaching tool for me.
In fall 2008, when I started as an Assistant Professor at the University of California, Berkeley where I am jointly appointed in the Berkeley Center for New Media (BCNM) and the Department of Theater, Dance and Performance Studies (TDPS), my chairs and deans invited me to take part in a new Digital Media Labs project, whose mission was to build out and equip two new labs, which would be added to an existing two labs on campus, with the end goal of having four digital labs dedicated to creative arts courses administered by four campus units: Art Practice, Film and Media, TDPS, and BCNM. Thanks to the hard work of a number of individuals from all four groups, the two new labs came into being at the start of 2010, and I signed on to teach a course called “Sound Design and Media Theater” in one of them.
I had taught several “theory” courses at Berkeley before, but this would be my first “practice” course. When I taught “Performance and Technology,” “The History and Theory of New Media,” or “Asian/American Performance across Media,” I stood at the front of the classroom, lecturing and facilitating discussions. Frequently, I or a student giving a presentation would need to project a video clip or series of images or sounds from a laptop, and I would step to the side of the room so that the projection and/or the student who was presenting could be front-and-center.
Soon after my first semester teaching Sound Design began, I realized that a design class requires instructors and students to relate very differently, both to one another and to media, than does a theory class. In my theory classes, the students direct their attention primarily towards the front of the classroom, to the instructor (who, most of the time, is myself, the professor, though oftentimes in my classes, the instructor is a student or a guest speaker presenting or performing or leading a class discussion). In a digital media design class, there is still a “front of the classroom” where all students’ eyes and ears are directed, but at that “front” is not a person, the instructor, but rather a digital projection of the instructor’s computer screen. It is still “I” who is teaching, but not by making my face or body the center of the students’ visual apprehension. I sit at a workstation in the front row of the classroom, my back facing the students, my eyes on the screen in front of me, and the students do not, of course, watch the back of my head. They watch the large white wall directly in front of all of us, where the movements I make using my mouse and keyboard are magnified so that even the minutest rollovers or double-clicks are easily observed. The students watch my manipulation of, and engagement with, the software tools that they are learning. They do their best to follow my example of keystrokes, scrolls, and clicks. These “demonstrations,” when I show students how to use various features and modes on software, are the heart of every class meeting. There are other activities during class time—discussions, show-and-tell presentations of professional artists’ sound and video work, practice/lab time, group critiques—but it is during the demonstrations that I communicate to students the protocols and guidelines and shortcuts for successfully editing, crafting, and playing back sound and video in programs such as Pro Tools, QuickTime, and QLab.
Reinforcing Software Demos with Lecture Notes
Software demonstrations are full of specific information, and I didn’t want students to attempt to scribble down dozens of details and rules as they were watching my demonstrations. I wanted them to engage with the software and practice in tandem with me, so that they could see for themselves how the programs work and so that they were able to ask pertinent questions while we were together. To encourage them to direct their attention to hands-on engagement rather than note-taking, I began using Google Docs as an instructional tool very early on in my first semester teaching Sound Design.
I created a Google Doc called “Lecture Notes.” Before every class session, I opened up the Lecture Notes Google Doc and wrote a set of point-by-point directions on how to use the particular features that I would demonstrate to the students that day. I also included links that I thought would be helpful to the students, for example, to The Freesound Project and ccMixter, which make sound and video files available for download through Creative Commons licenses. I sometimes included screenshots from my work with software so that students could reference visual guidelines as well as textual ones. I then published Lecture Notes as a web page, and used Berkeley’s course management software to put a permanent link to the Lecture Notes URL in the “Resources” folder of our course site.
Because Lecture Notes was stored in a living document accessible to all registered students via the restricted course site, my students could pull up the document on their workstations as they sat in class, watching me interact with software, and they had the security of knowing that they could access those notes later, when they were working with the programs on their own. They didn’t have to take careful notes during class (although I always tell students that they certainly *may* take their own notes if they wish, if note-taking helps them learn better), and they could reference my notes anytime, either in class or while they were constructing their individual projects.
One of my primary goals in teaching the Sound Design class is to make “myself” present to my students when they are working independently, and in such a class, the “me” that they need most often is the mouse moving across the screen, the typing appearing in text boxes, and the voice accompanying the visual demonstration and telling them orally what I am doing as I move the mouse and type text to create sound and video files. My Google Doc Lecture Notes allows me to be present to students when they need “me,” as they attempt to learn a set of technical skills. I could pass out hard copies of my notes, or e-mail notes to the class after every session, but then students would have to compile disparate sheets of paper or digital information sent on different days. The Google Doc is comprehensive and searchable, so that students wondering about a specific tool or operation can digitally find it in Lecture Notes in seconds using the Command + F keys.
I could create a Wiki or blog that would contain the same information as my Lecture Notes, which would keep all of the information in one place, but a Google Doc is preferable because I can more or less limit its circulation to the students enrolled in my class. The doc is published on the Web, but with a relatively Google-proof URL (i.e., the doc doesn’t come up in any of the first 10 pages of a Google search for the name of my class), and can be easily accessed only through the course’s bSpace site (bSpace is UC Berkeley’s online course management system). I wish to restrict the circulation of my Lecture Notes to my students so that potential future students, or students not taking a sound design class but interested in the topic, don’t get the impression that my detailed step-by-step instructions constitute any kind of comprehensive guide to using design and editing software. I’m certain that some excellent online guides to software exist for the platforms that I teach to my students; I just don’t want my Lecture Notes, which are written specifically as a supplement to my in-class instruction, to be used by a wide audience as one such online guide.
Facilitating Group Critiques
Another way that I use Google Docs in the classroom is as a means of facilitating group critiques. In Sound Design, students must create a number of projects (sound alone, sound plus video, sound plus live performance), and their projects are played for the entire class. The designers-in-training listen to their peers state their thoughts and opinions on each project. In addition to leading a verbal discussion of the merits of the students’ works, I also instruct the class to type their feedback for their classmates, plus a numerical rating of each piece (on a 1-5 scale, 5 being best) into Google Docs. They share the documents containing their written critiques with me, and I compile them into a single Google Doc, then post the link to that collection of critiques on the course bSpace, so that students can read what their classmates wrote and see how their work was rated.
Requiring students to contribute written comments and ratings as well as verbal ones helps them improve as designers, since they give and get far more feedback than they would from class discussion alone. In all oral discussions, naturally talkative individuals tend to dominate, and other participants are rarely heard from. But when everyone listening to a project must write their opinions down in a Google Doc, they all have to critique one another’s work, even if they are unwilling to voice their thoughts aloud in the room. Then, after the group critique session in the classroom, the group critique document allows them to read and consider their peers’ reactions over a longer period of time (since the Google Doc is a lasting record), which is a very different experience than listening to rapid-fire group chatter and trying to glean useful information from it.
Also, by asking students to type feedback into a Google Doc after listening to their classmates’ projects, I ensure that everyone in the class stays focused during group critique sessions. All instructors today, and especially those of us who teach in digital media labs, must deal with the challenge of students having access to screens, keyboards, and the Web during class time and potentially going off task. Group critique sessions are class periods when I am not actively demonstrating techniques the students need to learn, so I am at an exponentially greater risk of losing their attention. However, when every screen in the room is filled with a Google Doc, into which each student must constantly type information, I see that everyone’s attention stays on the projects being played.
A Failed Experiment
Not all of my experiments with Google Docs in the classroom have been successful. In one of my classes, I created a doc and shared it with every student in the class, so that they were all editors and viewers of a single file. Then, I asked that they enter their ratings (on the 1-5 scale) and comments simultaneously, immediately after they listened to a peer’s project. I did not know that Google Docs does not really allow files to receive entries from 15 different editors at the same time; the document I created frequently automatically saved, and every time it saved, it deleted a handful of comments that had just been typed. Students tried to re-type their feedback four or five times in a row, but even this did not guarantee that the Google Doc captured all of their writing, which led to frustration for those commenting, whose work was often lost, as well as those who anticipated being able to read feedback from everyone in the class and were disappointed to have written feedback from only a fraction of their peers. Needless to say, I was probably more frustrated than all of them that my attempt to use Google Docs as a collection point for group critiques had failed. But as soon as I realized that I could simply have each workstation use a different doc, my frustration dissipated.
Google Docs has been an ally far more often than it has been an enemy in my efforts to teach college students in a digital media lab. At this point, I cannot conceive of structuring my classes without it.
“Cloud computing” refers to the practice of storing data online rather than exclusively on personal computers. For example, if you store your digital files—images or sound or video or text—using a website or web-based e-mail provider rather than on your hard drive, your computer could crash or disappear, and your data would be safe online, in “the cloud,” where you could access it anytime, from any computing device. See <http://www.20thingsilearned.com/cloud-computing/1> for a definition of cloud computing authored by the developers of Google Chrome.
 The Fall 2010 syllabus of my Sound Design & Media Theater course can be viewed at: <https://docs.google.com/document/pub?id=1Ie2El4fy04LoQ6cqF5L3c5mZqQGPVhsssugTHV8Cgzc>.