Have you seen Google Wave yet?
For my colleagues in Rhetoric and Writing Studies, Technical and Professional Communication, New Media, and related fields, Wave represents your future course management system. Wave is going to make Blackboard, WebCT, Drupal, Wordpress, and other iterations of academic course management systems look awfully old-fashioned.
Now, a caveat. I have no more information about Wave than you yourself can obtain from any number of places, including first-look reviews from Tech Crunch, Mashable, and Google's Blog. I've even embedded the I/O keynote presentation which demos the new platform below.
That said, I do know a little something about working with CMSs from the perspective of writing research, curriculum, and pedagogy (as do many of my colleagues in the field who may be reading this post), and I can tell you that if the end-product performs anything like the demo, we can expect to use Wave to great effect in academe as soon as Spring 2010 (and more likely Fall 2010).
I want to do a couple of things in this post: first, I'll provide a little background on the idea of sympatry in the design of digital communication platforms. Then I'll discuss some of the highlights of the Wave demo from within this context, specifically addressing Wave's potential as a robust CMS for rhetoric, writing, and communications courses.
Finally, I've embedded the demo below. At around 80 minutes, it's not something you can digest quickly. However, it's very much worth your time if you're at all interested in exploring more effective CMS options. I also want to note that my enthusiasm for Wave is not based upon it's slick UI and the trappings of bleeding edge technology; Wave is significant because it's the first potential CMS I've seen that actually approximates sympatry, reveling in the complexity of contemporary, distributed, and digital knowledge work.
Sympatric Design Platforms
Back in 2007, I presented a paper at SIGDOC called "Agency, Invention, and Sympatric Design Platforms" (if you don't have access to the article through ACM and would like a copy, please don't hesitate to contact me). I argued that course management systems like WebCT and Blackboard (and, to a certain extent, even wikis) fostered frameworks of traditional writing pedagogy, partitioning student-users as isolated, individual producers of text-centric discourse.
Some of the problems with such platforms include poor or non-existent interoperability with other communication platforms where students already participate (such as IM clients, social network sites, etc.), little or no interface malleability (WebCT, for example, is essentially impervious to user-driven design changes), poor or non-exitsent collaborative writing/editing tools, poor collaboration with other institutional communication tools (like university email), little or no interoperability across courses a student might be taking (each course a walled garden), and a host of administrative issues for course designers.
The main issues for me, however, were the ways in which these course management systems reinforced problematic norms of traditional writing pedagogy. WebCT and Blackboard partition users as individual producers of alphabetic text. As an instructor working with and teaching postmodern notions of rhetoric, the course platforms themselves undermined my work, making distributed and collaborative knowledge work the exception rather than the rule, making student-driven design malleability a non-starter, and rendering alphabetic text as really the only valuable mode of communication, pushing visual and aural discourse to the margins, or to another digital space away from the CMS. Because of these problems, many instructors in my field have developed their own CMSs, using Drupal, WordPress, wikis, and blogs.
In 2007, I described traditional course delivery platforms (like BB or WebCT) as allopatric, a term from anthropology which theorizes speciation events as occuring through genetic separation and boundary formation. In terms of design and pedagogy, an allopatric classroom environment sees creativity emerging through separation, fostering traditional norms of text-centric individual creative genius in writing activity. This is a tremendously problematic position for folks in our field ascribing to notions of rhetoric as epistemic and ontological. The social turn has essentially argued exactly the opposite, in fact. Yet such norms are perpetuated in our predominant course delivery platforms.
I argued that sympatric design platforms should be developed, fostering collaboration, UI malleability, multi-modal rhetorics, and interoperability. Sympatry, in short, is the antithesis of allopatry. In genetic terms, sympatric environments see speciation occuring in the same geographic area, through genetic recombination and hybridization. A sympatric CMS, therefore, would foreground real-time collaboration, robust integration with other communication tools, and rhetorical knowledge work as complex, social activity. At the time, Microsoft's SharePoint was the platform closest to approximating this kind of complex distributed work. How things have changed in two short years.
Hopefully you're still with me. I provide the context above because without it my discussion of the Wave demo just won't make much sense. I recognize that borrowing terms from anthropology is somewhat problematic and even awkward, but I think the idea of sympatry in the design of digital communication platforms is still solid.
Vic Gundotra describes Wave as a "personal communication and collaboration tool," a description which barely hints at Wave's potential as a CMS for writing courses. In the notes to follow, I highlight some of this potential within the context of postmodern digital rhetorics. Wave, in other words, may actually be able to approach sympatry in communications platform design.
Wave is truly a platform--it's not an app, but a framework for communication ecologies that comes with a set of APIs that will (hopefully) enable robust extension and application development that operates within Wave (think of the iPhone application ecosystem, or the myriad Firefox extensions). Wave is premised on conversation and communication, not messages, as in email or threaded message-board posts. These conversations are hosted in the cloud, and thus always already internetworked; in other words, if I were typing this post on a Wave (such an option is built into the system, by the way), you would see it growing character by character, just as you experience speech, hand movements, and other bodily interaction in face-to-face conversation.
This real-time writing activity, just like face-to-face conversation, thus enables collaboration in a way that even current IM clients cannot approach. Rasmussen describes this as being able to devote 100% of your time to reading and writing. While this is certainly debatable, it introduces something to digital writing activity that has so far been absent.
Waves are essentially communication events that take a variety of forms--standard one-to-one asynchronous email-like conversations, group IM conversations in real-time, wiki-like environments for asynchronous collaborative document production, and even etherpad-like real-time collaborative writing. But Waves also enable something else: collaborative real-time blogging, webinar-like group interaction, collaborative real-time slideshow or presentation production, etc. These are, of course, just a hint of what can be done. Since Wave's APIs will be available to developers, the possibilities are as yet undetermined (think of the variety applications that have been built on the GoogleMaps API alone...).
Some other points of note: conversations in Wave include the ability to create private replies, so that backchannels can arise within primary communication spaces. You know how wikis have that cumbersome "previous versions" function? Wave has a "playback" function, so that if you enter a conversation some time after it began, you can hit playback (it's just like it sounds), bringing you up to speed by threading previous contrubutions contextually. Google is working on drag and drop operability between desktop and Wave (like dropbox), allowing you to add files, photos, videos, etc., instantly sharing that info across participant UIs.
Many writing instructors use blogging applications in their work. Waves can be published straight to Blogger. This is not simply embedding the content from the Wave, but embedding the full Wave on the blog, which means real-time, contextual collaboration on the blog. I could be editing from a Wave, you can be editing on the blog, and anyone viewing the blog can see this activity in real-time. Such embedding of Waves in blogs is important for student agency, allowing them to recontextualize work from the CMS to an environment which better reflects their own design choices.
Wave aggregates web conversations within the Wave UI. For example, I can integrate Tweets into a Wave, or conversations and information from FriendFeed. I can create Waves that pull data on a specific search term; like Gmail, I can search Google from within a Wave, embedding links with a couple clicks. I can import contacts not on Wave into the UI, allowing me to bring together previously splintered conversations and contacts. In collaboratively written Waves, there is support for illustrations, photos, videos, font differences, language differences--all in real-time; we are no longer talking about discrete and individualized text-centric writing production. Wave can enable complex rhetorical knowledge work, giving writing instructors a viable platform for teaching and exlploring that work.
From an application development perspective, Wave-as-platform has tremendous potential. But from the perspective of communication design, Wave is not revolutionary--this is what a CMS should be within the context of postmodern rhetorics, where writing isn't the product of isolated, creative genius, but the conflation and integration of overlapping publics.
I've said enough for now. If you're still with me, enjoy the Wave demo: