Google Wave and Higher Education

If you haven’t seen Google’s IO presentation on its newly unveiled project, you should: watch the Google Wave preview.

Basically, it’s a real time collaborative editing and communication tool. Imagine a wiki, email, a message board, and instant messaging all rolled into one seamless product, and you still won’t quite realize how cool it is going to be.

So, a wave is a document. A document that has more than one editor. A document that is updated in real time on every contributor’s screen character-for-character. A document that allows inline edits for message context, but still keeps track of who did what for accountability. A document that that shows exactly how it got to where it is with a sweet playback tool.

This seems like the solution for a Higher-Education group project. It could facilitate group meetings/communications. Groups could even produce the project/documentation itself collaboratively – even with inline conversations about individual edits (you can later create a new wave without the conversations). If instructors required access to the project wave, they could have extremely high visibility as to who contributed what to a group project for grading.

It also seems like a wave would be great for a classroom session. Instructors could present their lessons in-wave. Students could ask questions in-line, teachers could answer them. The whole classroom conversation could be replayed for anyone who missed class. Instructors could even replay the wave to determine class participation, or easily take a roll call. It would be great for a brick-and-mortar lesson – and it would be revolutionary for online course systems.

Once I calmed down a bit after watching the presentation, I realised that there are three major issues to deal with when using waves in higher education:

  1. FERPA Compliance (protecting access to student work)
    • Documents/correspondence can end up on outside (Google) servers
    • Students would need notification
  2. Section 508 Compliance /Accessibility
    • Live edit mode in a browser doesn’t work for the blind’s screen readers and other accessibility technologies
  3. Browser Compatibility
    • HTML5 is not widely supported – only betas/nightlies of Safari, Chrome, Firefox. No IE support – not even for a formally planned version

Thankfully, Google saw fit to make Wave highly extensible. The protocol is completely open (so you could build your own client) – they are even going to open source “the lion’s share” of their client. This allows solutions to those three issues:

  1. You can host your own wave server – student work can reside on the same servers as your courseware/etc
  2. Since the wave protocol is open, you (or the developer community) could build a desktop wave client that could speak out live document changes or provide other assistance for impaired users.
  3. With the Wave extension api, you could build a robot that could send wave changes to a html4 document – would would be viewable in any browser. You could also create a html4 web form interface to add content to a wave through a bot. Not only would this solution work for older browsers, it would also solve 2) – screen readers can handle the well written, static html4 document this robot would produce.

I’m extremely excited about Waves and how they can work for education. Hopefully Google accepts our developer application so I can get my hands on it soon.

New In Foliotek: Inline File Editing

Foliotek - Zoho

In Foliotek, our electronic portfolio tool we have some users who do a lot of file editing. Basically, they download, edit, and reupload files while evaluating student work.  The logistics of this can turn into a problem if there are many files to edit, and can be made worse if the files are very large and they share similar file names.

It would be a much more efficient workflow if they could edit the files and add comments directly in the browser.  In addition to that, in-browser document editing would make the basic file editing easier for students and faculty who are using the system to store and manage their files.

So, we decided to look into some JavaScript based document editors. Zoho stood out because of the APIs provided for remote document editing, in which the files are never saved on their servers. We have been working to incorporate an instance of the Zoho editor into Foliotek.  This will allow editing spreadsheets, word documents, and plain text files using their remote API. Hopefully this will help boost the productivity of our users and improve their experience using our software.  We are looking forward to feedback!

Also, I did a write up about one of the technical challenges that was encountered when adding this feature: generating a multipart form post in C#.