Using Google Docs for Classroom Instruction

by Philip Greenspun, January 2011

Site Home : Teaching : One Article

In January 2011, the author and three colleagues taught a laboratory course in relational database management systems and SQL programming at MIT. The course format was an intensive three days of students gathering in a room with their laptops running a virtual machine that we had distributed. Three instructors were physically present in the room and a fourth was available from his home in California via Skype, instant message, and email.

One of the challenges that we faced was that we had never used the problem sets before and each one involved complex and sometimes confusing problem specifications, source code, URLs, and other material where a simple typo could result in students getting stuck.

This article explains how we used Google Docs to support classroom instruction.

Developing Course Materials

Though our hearts belong to GNU Emacs, a text editor developed in the 1970s for programmers, it was more effective for the four of us to use Google Docs to collaboratively develop course materials. Even had all of us been logged into the same server and using Emacs simultaneously, Google Docs was more effective because simultaneous updates could proceed in different areas of a document. Also, the "insert a comment" feature of Google Docs was very useful whereas in Emacs editing a standard .html file there is no way to augment a document other than with in-line content.

Distributing Material to Students

We created two Google Docs folders the night before class: lessons, writable by us and read-only for students; workspace, writable by everyone. Into the "lessons" folder we moved the first day's assignment. In the "workspace" folder we created a "Day 1 Workspace" document intended for students to cut and paste code into.

Updating Course Materials

Whenever we noticed an error in the problem set or a student asked a question that we thought called for a hint or a better explanation, we would edit the problem set immediately and the students would see the change on the projector and/or on their own screens.

This was particularly helpful for hints. Suppose that after 5 minutes nobody is making much progress and they are digging unproductively in a SQL reference manual for syntax examples and you realize that it would be better to include a skeleton such as

SELECT ... FROM ... WHERE ID NOT IN (SELECT ... )
the skeleton can be added in seconds and viewed by all students just a few seconds later.

Distributing Solutions

Each morning we would create a "Day N Solutions (January 2011)" document and copy it into the lessons (read-only for students) folder. As the day progressed we would copy one solution at a time into this folder so that students would have it available before they attacked the next problem. In some cases we thought of better solutions and we would IM our California-based teacher and have him develop and test the solution, then add it to the solutions document. We were able to make much better use of a "distance teacher" because of the Google Docs-based nature of the course materials.

As discussed below, sometimes student solutions were better than our own solutions. We were able to add those to the official solutions document immediately, keeping our own inferior work underneath for those who wanted to see an alternative.

Code Review

One of the sad facts about teaching at MIT is that the students are invariably smarter than the instructors. Despite the fact that none of the students had used SQL before, some of them came up with better solutions than ours and/or interesting questions or perspectives that called for discussion. We would ask students to post their work on each problem to a workspace document, which we would then project and use as the basis for discussion. The fact that it was in a Google Doc meant that students could cut and paste other students' code and try it out in their own environment.

[Here's an IM transcript between me and Andrew Grumet, our California-based colleague:

]

Gathering feedback after the course

We created a feedback document and put it into the workspace folder, then used the "email editors/viewers" feature (from the Share menu) to contact all of the students to solicit their feedback entered into the document.

What did they have to say? "This class rocked!" was the first comment. Maybe we should change the document to read-only now!

Had we wanted structured feedback, it probably would have been better to use Google Spreadsheets with the Forms feature.

Email communication

The "email editors/viewers" feature was a big time-saver because we never had to develop a separate email list for the class. Everyone who walked in the room was asked if they'd been shared on the Google Docs folder yet. If not, we added them. When we wanted to email everyone in the class, we picked any Google Doc that happened to be open and used the "email editors/viewers" feature.

Performance and limitations

With a file that is writable by 30 people, all of whom have it open simultaneously, the Google Docs system seems to be up against its practical limit. Performance and cursor-tracking can be sluggish.

Could we have done it all with the Web?

Some of what we accomplished with Google Docs we could have accomplished by having a shell client open on a Web server, updating .html files, and then hollering out to students "okay now, reload the problem set".

With version control systems, however, it isn't necessarily quick and simple to make a small change to a .html file. Here are the steps:

  1. edit file in Emacs on development server
  2. test page on development server to make sure it looks right
  3. use "git add" on development server
  4. use "git commit" on development server and tell the git version control system what change was just made
  5. "git push public" on development server
  6. log into virtual private network
  7. through the VPN, log into production server
  8. "git pull" on the production server
  9. test page on production to make sure it looks right
The same operation in Google Docs: type and look.

The students could have shared their work with us using a discussion forum system. Each would have had to establish an account on the forum server.

Wishlist

During development of the problem sets, we wished that Google Docs had a native "code" style that would wrap text in the HTML code tag and perhaps indent it. The only fixed-pitch font in Google Docs consumes too much page width for showing standard code, so it would be nice to have a font that is fixed-pitch but much more compact.

When projecting Google Docs for a class to view, it would be nice to have a mode that shrinks the toolbars and other screen bureaucracy, thus freeing up approximately 30 percent more vertical display area on a medium-resolution projector.

Conclusion

Google Docs was an important asset for our course and significantly enhanced the in-classroom experience. I believe that it could be equally useful for any class that requires the distribution and collection of text, e.g., a class in writing poetry. I will thus close with a Haiku:
Windows 7 crashed
I am the blue screen of death
No one hears your screams

Acknowledgments

I could not have taught the course, which included a bewildering range of systems such as virtualbox, MySQL, PHP, Apache, Eclipse, Java, and Android SDK, without John Patrick Morgan, Shimon Rura, and Andrew Grumet. Thanks, guys!

Special thanks to Anne Hunter and Lisa Bella in the Department of Electrical Engineering and Computer Science for romancing the schedules office and explaining "yes we really do need a classroom, all day every day, for three days straight".

Thanks, finally, to Hal Abelson and Michael Stonebraker for advice and assistance.

philg@mit.edu
Add a comment | Add a link