elearning2.0

OpenDock is a new european pilot project put together by Dai Griffiths in Barcelona. It is funded by Leonardo and thus very small, but it is a well-conceived pilot with some very good people among its partners and so we expect it to produce some useful results. The kickoff meeting is being held in Barcelona, yesterday Nov 4, and today, Nov 5.

I gave my talk down a telephone line while Dai kindly stepped through the slides in the pdf. I attach two versions of the pdf here (suitable for screen and print respectively), and include a link to the slides as a flickr slideshow.

The overall project remit is as follows (emphasis added)

• Create a corpus of learning materials...
  • published under the Creative Commons license, with provision for IMS Learning Design, drawn from a range of different sectors of VET from different languages and cultures.
• Establish a repository of learning resources
  • building on current best practice and existing Open Source repository implementations and ...standards
• Demonstrate, evaluate, review the materials and repository
• Valorise and disseminate the outcomes, and plan for sustainability

My talk was about how we might concentrate our resources on a few parts of the problem to effect a service-oriented solution rather than create yet another database that no-one wants to use. I think the talk might be useful as an introduction to web2.0 approaches to the web as repository. I also introduce what seems to me a fairly sensible partitioning of the problem space, which is worth using s a discussion-starter:

Isn't the web 'a repository'?

Yes, but 5 (at least) kinds of problems for most authors:

• posting my resources
• helping others to find my resources
• licensing others to use my resources
• using formats that work with other resources
• making my resources usable and re-usable

The talk goes on to elaborate a bit on how users encounter these more particular isues, and to introduce service-oriented options for addressing some of them. It includes a number of screenshots of open, general repository-web tools and clients like del.icio.us, flickr, connotea, citeulike, netnewswire, cocoalicious, ecto, writely, gada.be, collaborative rank, guten tag, google blogsearch, WriteBoard and Video Egg.

...by the way, for those who were there in the 90's - yes, "OpenDock" the name is an homage to the wonderful docucentric middleware as was: "OpenDoc" (see this aborted knotes team-tsk in the sigossee site for more links and info about the old OpenDoc project: History: open software in education | catagory view: OpenDoc.

For more links and tags related to this issue, see an earlier post I made about how ad-hoc repository-like features can be assembled from simple tools.

PS [added Tuesday Nov 8 10:30am gmt] - I was so busy writing and presenting the talk on Friday that I forgot to explicitly include a creative-commons declaration in the pdfs. Feel free to re-use the content of this blog entry or of the pdfs, provided you give me some credit if you re-use large chunks.

OpenDock is a new european pilot project put together by Dai Griffiths in Barcelona. It is funded by Leonardo and thus very small, but it is a well-conceived pilot with some very good people among its partners and so we expect it to produce some useful results. The kickoff meeting is being held in Barcelona, yesterday Nov 4, and today, Nov 5.

I gave my talk down a telephone line while Dai kindly stepped through the slides in the pdf. I attach two versions of the pdf here (suitable for screen and print respectively), and include a link to the slides as a flickr slideshow.

The overall project remit is as follows (emphasis added)

• Create a corpus of learning materials...
  • published under the Creative Commons license, with provision for IMS Learning Design, drawn from a range of different sectors of VET from different languages and cultures.
• Establish a repository of learning resources
  • building on current best practice and existing Open Source repository implementations and ...standards
• Demonstrate, evaluate, review the materials and repository
• Valorise and disseminate the outcomes, and plan for sustainability

My talk was about how we might concentrate our resources on a few parts of the problem to effect a service-oriented solution rather than create yet another database that no-one wants to use. I think the talk might be useful as an introduction to web2.0 approaches to the web as repository. I also introduce what seems to me a fairly sensible partitioning of the problem space, which is worth using s a discussion-starter:

Isn't the web 'a repository'?

Yes, but 5 (at least) kinds of problems for most authors:

• posting my resources
• helping others to find my resources
• licensing others to use my resources
• using formats that work with other resources
• making my resources usable and re-usable

The talk goes on to elaborate a bit on how users encounter these more particular isues, and to introduce service-oriented options for addressing some of them. It includes a number of screenshots of open, general repository-web tools and clients like del.icio.us, flickr, connotea, citeulike, netnewswire, cocoalicious, ecto, writely, gada.be, collaborative rank, guten tag, google blogsearch, WriteBoard and Video Egg.

...by the way, for those who were there in the 90's - yes, "OpenDock" the name is an homage to the wonderful docucentric middleware as was: "OpenDoc" (see this aborted knotes team-tsk in the sigossee site for more links and info about the old OpenDoc project: History: open software in education | catagory view: OpenDoc.

For more links and tags related to this issue, see an earlier post I made about how ad-hoc repository-like features can be assembled from simple tools.

PS [added Tuesday Nov 8 10:30am gmt] - I was so busy writing and presenting the talk on Friday that I forgot to explicitly include a creative-commons declaration in the pdfs. Feel free to re-use the content of this blog entry or of the pdfs, provided you give me some credit if you re-use large chunks.

A little over a year ago, I proposed some work towards a middleware and services architecture which we provisionally called moomie and knase. This was meant to be part of a collaboration within the e-compete european project, which recently ended, but for various reasons the practical collaboration never really took off.

This was very disappointing, since the proposed work was - I still think - very good, and potentially quite important. It's about time we at least documented the outlines of that proposed work, and that is what this weblog entry is for. I've made a Flickr slideshow from my presentation to the ecompete partners, and also attach a printable pdf version:

In a nutshell, moomie is a proposed layer to broker object-to-object messaging in a lightweight, easy to implement way, and knase is a proposed set of APIs for requesting and delivering services and tools to complement moomie-aware applications. We intended to do initial experiments towards moomie object messaging in FlashCOM technologies, applying lessons learned there to other web-application clientside platforms such as JAVA and browser-based javascript/DOM. A major initial application of moomie was to have been multiple-instance and multiple-view support for simulations. We planned to experiment with two Knase services: an event-aware graphical chat tool and a 'knowledge-snippet' repository.

Neither moomie nor knase was a completely new idea; for instance in the early days of the IMS Project, middleware for multi-user JAVA applets was seriously proposed. What we considered new were the advances in other new technologies, such as the flashCOM server and standards-savvy web browsers, which might provide a way to creating limited middleware support for more interactive elearning activities in an extremely lightweight and incremental manner. Since we made our proposal, service-oriented architectures for elearning have become quite a buzz, and lightweight standards have also started to gain awareness and credibility. Similarly, there has been a growing understanding of the need for more engaging and interactive web-based learning activities. I have a hunch that the moomie / knase proposal would be very timely if we had the time to make it. :o)

The presentation (see links above) explains our motivation, rationale and planned approach in more detail than I can provide in this weblog entry; please refer to it for more information.

I will try to get back to this issue soon, and write a more substantial explanation of the proposal here sometime in July. We've been very busy over the past year working on knotes and other enhancements to Plone; now that we've made some real progress on those fronts I would dearly love to kick off some practical work on the middleware and services we proposed last year.

Technorati Tags: moomie, knase

First, let me say that I'm in favour of conserving Joshua's bandwidth and cycles, so I am not recommending this as a permanent solution or for high-traffic sites. What follows is in the spirit of experimenting with these great service-oriented functionalities to see how we can make it easy for real authors to effectively mash up their own links and content.

OK. We've been planning to do some work, starting with simple Plone content types, to help editors, authors and site-managers to pull social bookmarks into their content. Since del.icio.us, for instance, delivers wonderfully flexible RSS, it is pretty easy to bring bookmarked links into portlets or RSS-feed objects. In other words, it is easy to include delicious RSS wherever a separate content object might be expected.

But real-world authors want to be able to include links within their content, not in separate objects. So much so that they will hand-edit links into their page content even when those links have already been collected into tags or containers. We here at KnowNet developed our 'indexFolder' Plone container/content-type to help authors with similar issues, but it is a tad demanding of their awareness of containment (see the NGRF site for plentiful examples of bringing listings into page content). We're well-aware that this style of 'object-wise' editing does not appeal to people without computer science or engineering degrees. Developers must find ways to make it easier for ordinary editors and authors to create the content they want and benefit from the goodness of logical links-objects.

The editors of the NGRF site have been 'getting' the power of social-bookmarking lately, and have started to assemble a useful resource at their del.icio.us account. While drafting an email to them about options for leveraging that resource within the NGRF site, it occurred to me that a very easy technique already exists for bringing 'live' links lists into discursive site content, using the del.icio.us javascript linkroll feature. This post explains how to do that.

Two more caveats before explaining the technique:

• It depends on javascripts which fetch content from del.icio.us before the rest of the page loads. Thus it can sometimes be a bit slow, and sometimes appears a bit wonky, and will only display if javascript is available and enabled ( fallback is to link to delicious/tag etc )
• It requires editing "raw html". If you are used to a WYSIWYG editor like kupu, you'll have to go into 'raw' editing mode briefly to paste the special code. In kupu and ecto the link for 'raw editing mode' looks like "<>".

In its favour though, the technique is completely independent of your content-publishing system - you can use it anywhere you can edit web content - and very easy to place in a particular context within your own words and pictures - just choose where you paste the special code. It also has the great merit of working now, with absolutely no further work needed to get some useful content brewing. Read the rest of this entry for a full explanation and to see some rather arbitrary examples.

Technorati Tags: social-bookmarking del.icio.us structured-blogging elearning2.0 elearning web2.0 content2.0 authoring how-to

I'm starting to realise just how big the communications challenge is for us 'elearning2.0' advocates and developers. This stuff seems obvious to those of us who have invested years of painful development effort in artefacts like heavyweight learning objects repositories, and who have since have come to prefer loosely coupled, lightweight services for our own working practices. But I am discovering that web2.0 is counter-intuitive and even repellent to a lot of other people in the educational technology business. It takes time and practice for people to become happy with the web2.0 way of getting things done. We need to start spreading the word about compelling practical examples and vividly written explanations.

Scott Wilson has been producing some great, "gettable" figures and presentations lately. In this post I discuss a presentation he recently gave in Norway in which he reflected personally on the failure of the Big Standards approach, and the opportunities opened up by web2.0 with its smallscale standards and services and largescale emergent benefits.

A powerpoint presentation I gave yesterday in Norway - eduresources (PPT, 8.6Mb). Apologies for the file size, I included a lot of screen captures! If you'd prefer a smaller file, or just have problems with the powerpoint, I've also got an archive of JPEGs: eduresources.zip (ZIP, 3Mb)

I've attached a conversion of his ppt slides into a pdf on white background for printing. (Scott, this version has corrected the oversize text in the one I emailed you originally; I've made a little KeyNote theme to handle that in future conversions). As you might guess from that, I like to read things like this offline. And just about the only real chance I have to do so is when I'm on a train, which thank heavens has been seldom these days. Yesterday I finally gave Scott's presentation my full attention, and realised what a great resource it is for communicating these opportunities and issues to ed-tech folks.

I particularly liked his slides 10 and 11:

• So, we can create libraries of learning objects, and assemble them in all kinds of combinations to suit any need, all a teacher need do is select the correct combinations for their context.

• But there is one small problem...

• It doesn’t work

Scott goes on to qualify and explain that dramatic assertion, and to introduce some of the services and architectural styles that make the web2.0 approach to using learning resources so attractive. He also develops some ideas about other ways of approaching the issue of using resources. See for instance:

• slide 41 : using resources; the repository view
• slide 42 : using resources; the web view
• slide 46 : using resources; the web2.0 view
• slide 39 : so how are we to share [1]?
• slide 67 : so how are we to share [2]?

Now, I guess I should fess up about 2 things which explain some of my personal delight at reading those words:

1. In the mid to late 90's, I was a committed advocate of the approach I have since come to call Big Standards: people like me used to go on at great length about how wonderful these 'learning objects' were going to be, and why heavy-duty structured metadata and object repositories were essential to realising our vision of open, active elearning
2. Since the late 90's, I have opposed the Big Standards approach: It became clear to me that there were not going to be many highly interactive learning objects (in the object-oriented programming sense) and that we had all just bought a lot of snake oil.

I have spent the years since 1999 increasingly convinced that:

• concepts like "learning objects", "learning objects metadata" and "learning object repository" have lost their ambition and become overblown ways of denoting low-tech concepts like 'web pages', 'categories' and 'database'
• the reality of Big System / Big Standards elearning for almost all its users has been disastrously bad
• fundamental breakthroughs in the collaborative web were needed before organised online learning was of any use to learners

In fact, that pretty much sums up the mission of KnowNet: work hard to try to exemplify and explore those much-needed improvements to the collaborative web. (For instance, see this Online EDUCA 2001 paper).

And ( no thanks to us :o) improvements have started to appear. The web is much more collaborative now than it has been, and extremely rich new functionalities have started to emerge from an ecology of simple services, rich interfaces, massive uptake and easy re-use.

The web is smart because of the richness and variety of the interactions people have within it, not because its content is getting any smarter. Resources do not have to be smart for the system - the whole wild web and its real world users - to be rich and interesting. We do not have to regulate and contain the resources that learners use; on the contrary, our job is to add value to the system by making it even easier for people to interact meaningfully with each other, single, in groups or in emergent communities.

Thus, although it's been a long time since I've had any interest in Big Standards Learning Objects Repositories, it makes me very happy to read Scott's sharply-put words helping the rest of the ed-tech community to 'think out of the repository'.

Technorati Tags: elearning, elearning2.0, learning-resources, web2.0, repositories

I'll be participating in an meeting in Manchester hosted by CETIS on June 6th. This is a meeting of experts, the day before CETIS' public meeting on personal learning environments. We experts ( ahem :o) were asked to contribute very short position papers in advance of the meeting. I've pasted my position paper below (also available in a pdf version).

By the way, apologies for the scarcity of these posts.. I've been burning both ends of the midnight oil for a while now and just haven't had time to write...

Patterns in the clouds: Some thoughts on not being completely wrong about PLEs

To kick things off, let me admit that I have been completely wrong about some previous "xLx"s. When "virtual learning environments" and "learning objects" began to be spoken of in the 90's, I was one of the original dupes. Back then, I would tell anyone who would listen that these objects and environments, powered as they were by Standards™, were going to make cheap online learning possible, even ubiquitous. The web was great, and everyone saw its potential for learners, but creating good learning experiences online was hard and labour-intensive. To address that obstacle, software & standards architects had seen a way to augment the infrastructure.

Augmenting the infrastructure was what I assumed it was all about. When people spoke about 'learning environments', I took it as read that we were talking about smart middleware that added value to content and supported rich interactions across users and applications. It seemed obvious that by 'learning objects' people meant clever little programmatic objects that bundled content with code and knew how to hook up with each other in those smart environments. Begging, of course, the little question of engineering the actual software, but I assumed that (a) everyone knew about that little matter, and (b) the hard work would get done - what with big institutions on board, and big standards to help them work together for a common good.

I was completely wrong. That 90's jargon in effect meant something like... 'learning environment': institutional intranet, but with some 'spaces' named after a university's administrative concepts; 'learning object': a web page, but in a folder with the word "course" in its name. I'm not saying that nothing good has been accomplished by researchers, developers and practitioners of online learning - just that the hard infrastructure work implied by the 90's jargon got sidestepped in the rush to market.

Evocative notions like 'Personal Learning Environment' can mean radically different kinds of thing to people in different fields of work. So, nowadays, when I get excited about how some great common good can come from sharing out some tricky work, I assume that we'd better belabour the nature of that work before we get carried away with how good everything is going to be when we have the product. Work first, then hype.

So here I go, belabouring it. But first let me make it clear that I am very excited about the potential of "PLEs" in the sense of "leverage web2.0 for learners". In fact, I spend much of my working life organising and coding for experiments which try to deliver great features to real world users by combining, proxying and integrating the "small, loose" standards, simple services and social software entities of web2.0. (We here at KnowNet have built KNotes - a GPL'd collaborative weblogging system for Zope and Plone - which makes a very useful platform for such experimenting - pardon the plug :o) Some caveats, do's & don'ts follow:

Avoid reification by repetition

If we talk about "PLEs" for long enough, people will begin to assume they exist - and that there is a particular kind of artifact which "is a" PLE. This could encourage funders and vendors to concentrate on visible omnibus products - to the neglect of much needed work on other aspects of the services, systems, clients, interfaces, applications and best-practices which could comprise an environment worth describing as 'PL'.

The 'E' is out there

Many punters will mistakenly assume that the 'environment' will be metaphorically instantiated in some kind of desktop application program or web interface, but we all know better: a large part of the work required to make 'PL' happen will be in adding new services, service layers and bits of bridging code.

Practical experiments to reveal real-world use-cases

Our ignorance of pertinent use-cases is almost complete. The best way to shake out the issues and use-cases is to undertake some serious experimentation - try to use existing services and tools to accomplish small-scale aims with real users, and document the issues, patterns and gaps. Ideally, these experiments should have access to specialist development help, so that ad-hoc features and behaviours can be added or tweaked to meet the emerging cases.

I've done some experimenting with real users, and can attest that it is subtle and tricky in the extreme to mix and mash existing services and applications for ordinary groups of users. To my mind, small-scale collaborations among educators and developers, imaginatively pushing the limits of what can be done with existing equipment, are the most pressing immediate issue for all of us.

Creativity, connection and expression - not just consumption and aggregation

There is much work to be done to enable ordinary end-users to create their own content-in-context; to add connection and commentary to what they 'pull in'. The connectedness of content in web2.0 offers huge scope for exploring new ways for learners to create interesting structurings and representations of their own, but that will require determined experimentation, research and development

Respect the web2.0 way

In any work on PLEs, let's be very careful to learn from the simplicity, clarity, user-centricity, restraint and attention to detail that characterise web2.0. The good systems-effects only emerge when usage becomes rich and plentiful - and that depends on an ecology in which the individual parts are simple, focused and easy to get along with, and in which the interoperability architecture makes very lightweight demands on its citizens. Small pieces, loosely joined. Small APIs. Small steps. And remember to make it shiny :o)

Understand the gaps in web2.0 as it is

There are some wonderful applications, services and mash-ups out there, but existing services and applications are not quite enough to support the features we can envisage learners having access to in a PLE. Only by determined experimentation can we begin to characterise and address the gaps. (By the way, I have some hunches about where a few key gaps are to be found, but have had no chance to document them yet).

Concentrate on the parts web2.0 doesn't reach

My feeling is that we should concentrate our limited efforts on implementing functionalities and services which are not already available elsewhere ( or which practice has shown are unsuitable in the forms currently available).

Tools and platforms to experiment with

One crucial development task is to provide experimenters with platforms which can be flexibly and rapidly adapted to cases as they emerge. For instance, I am not sure that we need an omnibus desktop application in itself, but I am certain that we need to be able to rapidly experiment with desktop clients for new or adapted APIs/services (structured blogging and microformats through atom-publishing or weblogging API clients for instance, or structured-commentary on items read within an aggregator). Our own KNotes - which I mentioned above - is a useful platform for playing with the serverside of such experimental interactions.

Practice, practice, practice...

In case I did not emphasise my feelings about this enough above: web2.0 is a loose set of practices as much as it is a system... 1) Practical experiments are a key immediate task; (2) practice "in anger" with the web2.0 services and social software systems is to be heartily recommended to anyone who hasn't yet done so; (3) much of what will make the 'E' in PLE will be distillations and encodings of good practice, and much of our jobs will be to solicit, support, generalise and empower such practices.

The communication challenge

This stuff is subtle. What seems obvious to us is unknown to most policy-makers - indeed it's little-known or misunderstood by most professional ed-tech developers. In my experience, people do not "get" the new opportunities until they have made fairly serious use of some of them. Spreading the meme to funders and educators will require vivid demonstrators and small real-world success stories to exemplify the potential we see represented in those pretty omni-graffle clouds :O)

I thought I'd share these figures/drawings from the notorious patent, since they were such a pain to access and organise. You can read the Blackboard document at the US Patent and Trademark Office's Patent Full-Text Database, but it refers to 41 figures/drawings, and these are organised in a very awkward navigational format, viewable one at a time in a pane that requires a lot of scrolling (the uspto site says this is because some patents are 5000 pages long, and thus they cannot afford in general to allow omnibus downloads).

I wanted to read the patent, so I downloaded all these images, gave them meaningful names and rotated them as necessary so that I could make reference to them in a sensible way. That was such a pain that I thought I'd spare others the trouble, so I uploaded the images to flickr, gave those images complete titles based on the captions in the patent document, and placed them in order in a Flickr set: Figures from Blackboard's Patent (also available as a Flickr slideshow). If you want to have a local copy of all the figures (for printing etc), I also uploaded the figures as a zip full of TIFFs to my yahoo briefcase.

While I'm at it with links to resources... I've collected a good set of links in my del.icio.us tag 'blackboard', and will continue to add items I feel are particularly useful or important. Best viewed in our shiny new interactive tag-viewer: mmalloch/tagviewer?tag=blackboard.

By the way, I hope to post next week about these slick new tools we've been writing for interactive viewing of del.icio.us tags, clouds, items and related tags (and even for live-searching tagged sites!). Lots of goodness on the way and we'll release variants for Plone and plain html embeds under GPL as soon as the interfaces are complete.

And I also hope to post sometime soon with my own feelings about the Blackboard patent issue. For the moment, let me just say that having spent the summer of 1998 in Blackboard's DC offices (seconded there from the UK to do some IMS work on metadata), and having spent a lot of that time interacting with the architects of Blackboard's subsequent systems, I know that these guys did not 'invent' the VLE, and that they knew they weren't 'inventing' the VLE.

On the other hand, I've never understood why people are interested in these 'L' blinking 'E's in the first place. I prefer to call these things 'procurement-ware', since their sole use in the real world is to get bought by IT departments as evidence that they 'offer online learning'. I agree with those who've pointed out that outlawing the monolithic VLE really doesn't matter - it'd be wonderful if anybody peddling such monstrosities could be sued (and not just BB's competitors :o) ...I think a bit of student protest would be very welcome, against the injustice of this nuisance patent, but also against the injustice of cramming procurement-ware down students' eyeballs ... "No L Es" anyone?

Technorati Tags: blackboard, patents