For those of us who saw Blackboard’s aggressive acquisition of commercial competitors WebCT and Angel, and seen the patent litigation they unleashed against Desire 2 Learn, the idea of Blackboard pledging to be a good open source citizen may seem a bit … unsettling, if not 1984ish.

But it has been clear for a while that Blackboard’s old strategy of ‘owning the market’ just wasn’t going to work. Whatever the unique features are that Blackboard has over Moodle and Sakai, they aren’t enough to convince every institution to pay for the license. Choosing between VLEs was largely about price and service, not functionality. Even for those institutions where price and service were not an issue, many departments had sometimes not entirely functional reasons for sticking with one or another VLE that wasn’t Blackboard.

In other words, the VLE had become a commodity. Everyone needs one, and they are fairly predictable in their functionality, and there is not that much between them, much as I’ve outlined in the past.

So it seems Blackboard have wisely decided to switch focus from charging for IP to becoming a provider of learning tool services. As Blackboard’s George Kroner noted, “It does kinda feel like @Blackboard is becoming a services company a la IBM under Gerstner”

And just as IBM has become quite a champion of Open Source Software, there is no reason to believe that Blackboard will be any different. Even if only because the projects will not go away, whatever they do to the support companies they have just taken over. Besides, ‘open’ matters to the education sector.

Interoperability

Blackboard had already abandoned extreme lock-in by investing quite a bit in open interoperability standards, mostly through the IMS specifications. That is, users of the latest versions of Blackboard can get their data, content and external tool connections out more easily than in the past- it’s no longer as much of a reason to stick with them.

Providing services across the vast majority of VLEs (outside of continental Europe at least) means that Blackboard has even more of an incentive to make interoperability work across them all. Dr Chuck Severance’s appointment also strongly hints at that.

This might need a bit of watching. Even though the very different codebases, and a vested interest in openness, means that Blackboard sponsored interoperability solutions – whether arrived at through IMS or not – are likely to be applicable to other tools, this is not guaranteed. There might be a temptation to cut corners to make things work quickly between just Blackboard Learn, Angel, Moodle 1.9/2.x and Sakai 2.x.

On the other hand, the more pressing interoperability problems are not so much between the commodified VLEs anymore, they are between VLEs and external learning tools and administrative systems. And making that work may just have become much easier.

The Blackboard press releases on Blackboard’s website.
Dr Chuck Severance’s post on his new role.

Back when Wave was first demonstrated by Google, one of the robots (participants in a Wave that represent some machine or service) that got a few minutes in the limelight was Tweety the twitterbot. Tweety showed how updates to a Wave can be piped through to Twitter, and vice versa. Great, you can follow conversations in the one, without leaving the other.

Tweety the twitterbot pipes tweets into a Wave

In the same vein, when Google unveiled Wave Gadgets (small applications that can be integrated into a Wave), their collaborative, multi-user, concurrent or realtime nature was so similar to Wookie, that Scott Wilson converted them to run on Wookie rather than Wave. Now that Wave is slowly opening up, what could be more natural than seeing whether a bunch of people on a Wave could be interacting with a bunch of people in Moodle via a Wookie widget?

Technically, all this is possible, and I’ve seen it work- but it does require some thinking about how the contexts fit together.

For example, Tweety relays all tweets from all followers of one account to everyone in a Wave. Worse, it relays everyone’s blips from that Wave as separate tweets via the one account. Apart from the fact that seeing other people’s contributions appear in your own name, the Wave conversation is just too noisy and fast to make any sense in a micro-blogging context. Likewise, all tweets from all followers of one person (live!) is a lot of noise when a worthwhile Wave conversation can only really be about a couple of linked tweets between a few followers.

The Wookie ‘Natter’ chat widget in Wave integration looked more of a natural fit. As integrations go, this was pretty shallow: Natter is displayed in Wave, but has no idea who is interacting with it there. Put differently, everyone in Wave is just one participant in Natter. This is potentially quite useful, as everyone else in Natter is in a wholly different environment, and therefore engaged in a different activity. They can’t see what’s going on in the linked Wave. Channelling contributions through one entity therefore makes sense; linked but separate.

The Wookie 'Natter' chat widget in Wave

A deeper integration where Wave participants showed up in a Wookie widget properly, much like Moodle or Elgg based people do now, looks technically feasible and socially doable. Unlike Twitter and Wave, the basic user interaction models of Wookie and Wave look similar enough not to jar.

Other integrations are also conceivable: you could push updates on a Wookie widget as blips to a Wave via a robot (Tweety-style) and vice versa, but that looks like a lot of effort for not much gain over a widget approach.

Longer term, though, the best way to integrate realtime platforms seems to be via something like the Wave protocol. That way, people can pick and choose the environment and/or user interface that suits them, independent of the social context or network they’re interacting with. Fortunately, that’s what Google is aiming for with some more releases of open source client and server code and updates to the Wave protocol.

For a wider overview of Wave and its potential for teaching and learning, see my earlier post

What is Google Wave?

There’s many aspects, and the combination of features is rather innovative, so a degree of blind-people-describing-an-elephant will probably persist. For me, though, Google Wave exists on two levels: one is as a particular social networking tool, not unlike facebook, twitter etc. The other is as a whole new technology, on the same level as email, instant messaging or the web itself.

As a social networking tool, Wave’s brain, erm, ‘wave’ is that it focusses on the conversation as the most important organising principle. Unlike most existing social software, communication is not between everyone on your friends/buddies/followers list, but between everyone invited to a particular conversation. That sounds like good old email, but unlike email, a wave is a constantly updated, living document. You can invite new people to it, watch them add stuff as they type, and replay the whole conversation from the beginning.

As a new technology, then, Google Wave turns every conversation (or ‘wave’ in Google speak) into a live object on the internet, that you can invite people and other machine services (‘robots’) to. The wave need not be textual, you can also collaborate on resources or interact with simple tools (‘gadgets’). Between them, gadgets and robots allow developers to bring in all kinds of information and functionality into the conversation.

The fact that waves are live objects on the internet points to the potential depth of the new technology. Where email is all about stored messages, and the web about linked resources, Wave is about collaborative events. As such, it builds on the shift to a ‘realtime stream’ approach to social interaction that is being brought about by twitter in particular.

The really exciting bit about Wave, though, is the promise that – like email and the web, and unlike most social network tools – anyone can play. It doesn’t rely on a single organisation; anyone with access to a server should be able to set up a wave instance, and communicate with other wave instances. The wave interoperability specifications look open, and the code that Google uses will be open sourced too.

Why does Wave matter for teaching and learning?

A lot of educational technology centres around activity and resource management. If you take a social constructivist approach to learning, the activity type that’s most interesting is likely to be group collaboration, and the most interesting resources are those that can be constructed, annotated or modified collaboratively.

A technology like Google Wave has the potential to impact this area significantly, because it is built around the idea of real time document collaboration as the fundamental organising concept. More than that, it allows the participants to determine who is involved with any particular learning activity; it’s not limited to those that have been signed up for a whole course, or even to those who where involved in earlier stages of the collaboration. In that sense, Google Wave strongly resembles pioneering collaborative, participant-run, activity focussed VLEs such as Colloquia (disclosure: my colleagues built Colloquia).

In order to allow learning activities to become independent of a given VLE or web application, and in order to bring new functionality to such web applications, Widgets have become a strong trend in educational technology. Unlike all these educational widget platforms (bar one: wookieserver), however, Wave’s widgets are realtime, multi-user and therefore collaborative (disclosure: my colleagues are building wookieserver).

That also points to the learning design aspect of Wave. Like IMS Learning Design tools (or LD inspired tools such as LAMS), Wave takes the collaborative activity as the central concept. Some concepts, therefore, map straight across: a Unit of Learning is a Wave, an Act a Wavelet, there are resources, services and more. The main thing that Wave seems to be missing natively is the concept of role, though it looks like you can define them specifically for a wave and any gadgets and robots running on them.

In short, with a couple of extensions to integrate learning specific gadgets, and interact with institutional systems, Waves could be a powerful pedagogic tool.

But isn’t Google evil?

Well, like other big corporations, Google has done some less than friendly acts. Particularly in markets where it dominates. Social networking, though, isn’t one of those markets, and therefore, like all companies that need to catch up, it needs to play nice and open.

There might still be some devils in the details, and there’s an awful lot that’s still not clear. But it does seem that Google is treating this as a rising platform/wave that will float all boats. Much as they do with the general web.

Will Wave roll?

I don’t think anyone knows. But the signs look promising: it synthesises a number of things that are happening anyway, particularly the trend towards the realtime stream. As with new technology platforms such as BBSs and the web in the past, we seem to be heading towards the end of a phase of rapid innovation and fragmentation in the social software field. Something like Wave could standardise it, and provide a stable platform for other cool stuff to happen on top of it.

It could well be that Google Wave will not be that catalyst. It certainly seems announced very early in the game, with lots of loose ends, and a user interface that looks fairly unattractive. The concept behind it is also a big conceptual leap that could be too far ahead of its time. But I’m sure something very much like Wave will take hold eventually.

Resources:

Google’s Wave site

Wave developer API guide. This is easily the clearest introduction to Wave’s concepts- short and not especially technical

Very comprehensive article on the ins and outs at Techcrunch

Recipe

Ingredients:

• Google docs account
• Sproutbuilder.com account
• Mediawiki account with friendly administrator
• Moodle installation with administrator access
• (optional) iGoogle account, plain html site, Apple Dashboard, Windows Vista Sidebar, etc.

Take the Google docs account, and create a new spreadsheet. Rustle up a form from the toolbar; you have a choice between simple text, paragraph text, multiple choice, checkboxes, choose from a list and a scale. The questions will be added as columns to the first sheet. To calculate marks from the returns, use sheet 2 (the answers from the form will brutally overwrite anything on sheet 1). Refer to the cells in sheet 1 from the formulae in sheet 2. Finish with inserting widgets or charts that sum up your calculations. Send out the form via email, and let the sheet stew.

In the mean time, soften up your mediawiki instance by asking your friendly administrator to allow img and object tags in pages. Make sure that the wiki isn’t very public, or you might get burned. To embed the form, go to sproutbuilder.com, and create a widget with the google form as content. Publish the sprout, and copy the object tag code, and trim off the single pixel image code on the end. Stick the object tag in the wiki, et voila.

To display the results, go to the chart in the google spreadsheet you prepared earlier, and publish it. Stir the resulting img tag you will be presented with into the wiki, and enjoy.

The outline for a Moodle instance is fairly similar, but allows greater freedom in what gets mixed in, where- provided you have administrator privileges. The form widget, for example, can be called directly in the iframe Google provides, which can be put into a Moodle html block. Likewise, results gadgets can be stuck in an Moodle html block as the javascript concoction Google dispenses.

Usability and security

As the recipe indicates, the deployment of widgets could be much easier. Getting rid of the copying and pasting of gnarly bits of code is only a minor aspect of this issue; security is the much bigger aspect. The hacking of the mediawiki instance is a tad questionable from that point of view, even if the wiki isn’t open to all miscreants on the web. There is a mediawiki extension that takes care of the trusting and embedding of widgets, but it doesn’t look particularly easy to use.

Much the same goes for deploying widgets in a Moodle instance, even if Moodle’s more fine-grained controls over who has which privileges over what, makes things rather easier. I had a quick look at a web platform like Facebook, and couldn’t find a way in there for my gadgets at all. A lame list of my Google documents was as far as it went.

What’s required here, IMHO, is plug-ins to these web apps that allow administrators to set trusted domains of origin for widgets. That way, regular users can stick in homebrew and pre-packaged widgets from these trusted domains into their favourite platforms without stuffing up security.

When inserting the assessment widget into the VLE, it also struck me that it wasn’t offering a whole lot more functionality than was already there in Moodle. I can imagine that using the Moodle question forms is easier for some people than wrangling spreadsheet formulae too. Still, there are important advantages of using a web app like Google docs or Zoho. Most importantly, the fact that it allows learners and teachers to pick their favourite tools to a common environment. But that does presuppose that deploying the various channels in and out of the docs web app is easy.

Pedagogy

As is usual with a newly found hammer, you start looking for nails that may or may not be there. My first effort (Gadgets and mashups 101, log in as guest) therefore resulted in the shiniest widgets piled on top of each other. There is no indication of the right answer on submission, and the fact that the scores of everyone is plain to see, may not have been the best way to approach the learning activity, though.

The second effort was better, I feel (Gadgets and mashups 102, log in as guest). In this version, there is at least some feedback on submission, and an indication of which questions people struggled with, on average. Even so, using email or a link directly to the form on Google may be better still, with just the average score on each question as a gadget, and a list of respondents just for the teacher.

The spreadsheet can be viewed on Google docs.

You can see what the widgets look like in mediawiki on the CETIS wiki.

While I can’t pretend to be particularly knowledgeable in the area, I keep hearing stories of all kinds of artificial constructs that make what should be a reflective dialogue with experts more like a course. The reason is simple: institutions are geared to deliver lectures, tutorials and mark assignments and exams. Any learning process or activity that doesn’t follow that pattern fits badly.

As my colleague Oleg asked, when are students supposed to actually do PDP- in the middle of a lecture?

Thinking back of my secondary school days, I realised that that was exactly what I did, almost every day. In my school, though we didn’t call it that, PDP was the central organising principle, not the subject course or lesson.

To be sure, my school was a rather unusual place, inspired by the pedagogical ideas of the early 20th Century Dutch educator, pacifist and Quaker Kees Boeke. At the school, there were no marks, just pass or no pass, with specific comments. There were very few ‘stand up and teach’ sessions either, most hours were essentially unstructured consulting sessions where pupils of all grades and ages could collaborate with each other, work on their own or interact with the teacher. Everyone was expected to work at their own pace.

Most of all, though, the curriculum for any given subject was only partially defined. Roughly a third of the work had fixed content and assessment, another third defined the topic -but not much else-, and the final third was entirely open, bounded only by the subject area. That meant that most of the learning was negotiated between the individual learner and the subject teacher.

While this may sound like some anti-authoritarian, hippy paradise, the kids were just as ruthlessly assessment driven as they are anywhere else. What made the system work was that it harnessed that drive, by organising the learning process around credits. For a majority of these credits, you had to negotiate what learning they accredited first. And that meant reflecting on what competencies you already had, and which ones you needed, personal interests, cross-overs with other subjects and more. Just jumping through the pre-set hoops wasn’t an option, you had to do PDP.

The school, alas, has long shut down. I wonder, though, whether anyone today would have the guts to forgo the safety of packaged curriculum delivery and testing in order to compel students to negotiate each credit.