The Answer to Project-based Work in MOOCs is Federation

Matt Crosslin, who’s a pretty smart guy, has an article in the EduGeek Journal about dual-layer MOOCs. This is an idea I’ve been pursuing for quite some time, and studied for a bit but never quite was able to pull together.

What even readers of this blog may not realize is that its been this chain of failure  and partial success that’s got me to the idea of federation as a model for coursework instead of syndication. It seemed zig-zaggy at the time, but in hindsight there’s been a pretty clear trajectory in my thought from the idea of the “xMOOC as the chewy center of the cMOOC” through the “Feed-Forward” Psych MOOC we launched at Keene State College to the research on non-communication in blended xMOOCs, to the ultimately aborted Water106 project (a failed project which strangely seems to be inspiring more people than projects of mine that have launched successfully — weird what a mockup can do).

Anyway, Matt identifies the right problem around authentic PBL work in MOOCs and comes up with a good analogy, but I think selects the wrong implementation model. First, let me restate his analogy, because I think it’s worthwhile:

In order to do this, we would have to stop thinking about group work in the typical ways we usually do: instructor assigns groups, forces all people in groups, and groups never change the whole course. We need to think of these groups in a different paradigm. If you are familiar with river tubing, think of how groups form in that activity. For those who are not familiar, here is a visual:


As individual tubers float down the river, they drift in and out of groupings as needed. Maybe they stick with people they knew the whole time. Maybe they make new friends as they go and the group grows. Maybe one group wants to go look at something that the others don’t. But the groupings of tubes are constantly changing, growing, and morphing. Some stay solo, some stay in the same group. But as the river (the course) flows, the structure is flexible enough to change over time. (I wish I could find an animated gif of river tubers to better illustrate).

But then Matt veers toward a Reddit-style solution:

So, layer this flexible grouping system on top of a Reddit system that allows learners to create and up-vote learner content (that can then be used as the problems in PBL), and allow the groups to form around these ideas. It would kind of be like tubers that discuss what drinks to bring, then putting the ones that won the vote into coolers, and those various coolers end up being what draws in the groups of tubers (which would of course change and morph as they float down the river).

I haven’t tubed much, so maybe I’m mis-reading the metaphor. But it seems to me the hard part of the problem is not the initial organization of groups here, but that behavior in the last parenthetical clause:

 (which would of course change and morph as they float down the river).

Solve that, and work backwards. And what you need for that to happen is not a centralized voting and sorting mechanism, but a way that people can easily be exposed to second and third order nodes, and move easily through those networks.

How does federated content solve this? In the case of federated wiki it’s simple — when I pull someone else’s work into my own space, I become connected to the people who have worked on that document. They enter my “neighborhood”.  Now search, link resolution, recent changes and other features include products from them — writing, data, visualizations, problem sets, whatever. As good and useful products travel through the network they create connections which can be further explored. Move off that content, and on to different content and my neighborhood morphs, automatically.

Note the difference — people don’t vote on content around which to create groups — rather they *use* the content, and for each person that use connects them to the creators of that content in specific ways.

Let me show you how this might work — check out the five minute screencast below.

If you haven’t watched the screencast and you are interested in technology to support self-organizing groups, I can’t emphasize enough that you really need to watch the screencast now.

Federation is hard to get in theory, but relatively easy to get in practice. But getting it is essential. Just as syndication formed the basis for the explosion of creativity in online pedagogy over the past ten years, federation is likely to provide the basis for the next decade of experimentation if we’re willing to spend the time to wrap our head around it.



The Hidden History of Online Learning

I’m starting up a federated wiki on the “Hidden History of Online Learning” to attempt to demonstrate to what the experience is like.

If any readers of his blog would like to participate, I’m willing to set up a federated wiki for you on my S3 instance. I’ve already set sites up for Audrey Watters and Jim Groom.

The site URL will look like where “audrey” is your name. Leave a comment below if you would like to participate, indicating your preferred URL.

You will be obligated to write a 1 to 2 paragraph article on the wiki, or to substantially revise another 1 to 2 paragraph article on  the wiki. That’s it. Ten minutes work.

Leave a comment below!

Smallest Federated Wiki as an Alternate Vision of the Web

The web is not going away. And you’ll probably never see anyone in your immediate family ever uttering the phrase “Smallest Federated Wiki”.

But after three weeks of using Smallest Federated Wiki, a reimagining of the wiki (and really, of the web) by wiki inventor Ward Cunningham and a cadre of incredibly talented coders, I’m struck by how SFW undermines some of the basic premises of the web.

And I’m even more surprised how good that feels.

Writing in Hypertext

  Quoted Text  

I had done a great deal of writing as a youth, and re-writing, and the intricacy of taking ideas and sentences and trying to arrange them into coherent, sensible, structures of thought struck me as a particularly intricate and complex task, and I particularly minded having to take thoughts which were not intrinsically sequential and somehow put them in a row because print as it appears on the paper, or in handwriting, is sequential. There was always something wrong with that because you were trying to take these thoughts which had a structure, shall we say, a spatial structure all their own, and put them into linear form.

                    — Ted Nelson, inventor of modern hypertext. source


It’s been 20 years since MOSAIC and over 50 years since since Ted Nelson invented computer-based hypertext and we are still not writing in hypertext.

We think we are writing in hypertext. But look at what Nelson is talking about. Does the composition process he was trying to create sound like what you do when you compose? Are you constructing “spatially”, in two dimensions?

In all likelihood, you’re not. You’re linking pages to one another, but you aren’t doing anything like Nelson is describing here.

And you really can’t. Because the dominant paradigm of the web is that you are on one page at any given time. You don’t go into WordPress and work on three pages at once, fluidly shifting bits and pieces until a multi-page networked structure emerges.

Rather, almost all web writing begins with an idea that we are going to write Page X. And Page X can absolutely drop into a web of links to page Y and Z. But we are never invited to change Page Y and Z as a response to the existence of Page X. Or to write a concise and specialized version of Page Y uniquely tuned to the context of Page X.

That’s using links, but it’s not the spatial composition that Nelson is referencing. And strangely, it’s less than we had with some of the Hypercard variants of the 80s and 90s.

As Nelson himself said, the current web is FTP with lipstick. It’s a works cited page with hidden links to other documents. But it ain’t hypertext.

Smallest Federated Wiki solves this through a focus on allowing page-refactoring across entire sites, along with features that make a pass at Nelson’s dream of a pool of reusable bits.

How does this work? Multiple columns with draggable text and data elements you can pull between pages as you build out your spatial text.


Speaking of columns…..


From Jump Links to Columns

  Quoted Text  

Project Xanadu is a much-misunderstood initiative to create a different kind of computer world, based on a different kind of electronic document–


We should have stressed that point from the beginning.

       — Ted Nelson’s Project Xanadu, source


We call links internal to a page “jump links”, but really all links are jump links.

Worse yet, they are “blind jump links”. You’re reading along in a page, there’s a link to another page, providing (supposedly) additional context.

But when you click it, it doesn’t provide additional context. It provides a *new* context. And if in that new page there is yet another link, you are whisked again into a new location, usually reading text only marginally related to what the link was supposed to provide.

Every page, because it is a complete and total page (or as Nelson would explain, because it is essentially an FTP’d document) can’t truly supplement context. It has to own the context. Instead of connections, we get teleportation.

If you want connection — if you want to supplement context rather than replace it — you need parallel pages.

Parallel pages — or, in the case of SFW, pages laid out in columns — allow us to read spatially. New pages open to the right, while preserving your current context.


This seems small. What you learn after a couple weeks of writing and reading in SFW is it is anything but.

From Unmixable Layout to Mashable Data

HTML is at heart a publishing format, one that does very well with static text. It’s a great format for a snapshot.

But when we add data to text, we either lock it into the document as an output (a chart or other output format) or, if we want to keep it editable, we embed it from a third-party application.

In other words, the process of publication becomes a process of freezing our data in place or exiling it elsewhere.

SFW has an elegant solution to this: everything becomes data. Your paragraphs are a little nugget of JSON, with a wrapper that tells the page “This data should be displayed as a paragraph.”

  Sample JSON Data  
   "text":"The web is..."},

Outside of the fact that that text can now be mashed and processed in any way you choose (write a Markdown plugin if you want to write paragraphs in Markdown), the system allows all types of data to become first class citizens of the page in a way they have never been. You have the capability to write or use interpreters for any microformats or domain-specific languages you use, from languages that communicate with remote sensors to ones that produce complex visualizations.

As a simple example, adding the MathTEX code

\tan^{-1} \theta+C\)

into a the MathJax plugin adds this to the JSON representation:

 "text":"\\(\\int\\frac{d\\theta} {1+\\theta^2}= \n\\tan^{-1} \\theta+C\\)"},

Which displays on the page like so:


Images get stored not as external references, but as embedded JSON data that can follow the page. Graphs carry the data that generate them behind them. Calculator plugins define and compute data across pages.

Here’s me realizing it should be BETA not THETA and fixing the equation:


I’ve flubbed up the explanation of this before (Jim will remember my peculiar ByteBeat obsession), but what’s notable here is your data travels *with the page*, and can be made to produce any appropriate format. This is what we mean when we say data is a first class citizen in SFW.

Even better, all of these objects inherit the dragability, edit histories, and forkability of the text elements of a page. When you fork a page,you don’t fork something pointing to a bunch of references you can’t edit. You get the whole enchilada, not a pointer to one.

Parallel Revisions

One of the big sticking points people have with the SFW interface is the bottom bar of revision history.

Each icon represents a specific action in the page history. Click any edit, and it opens up a copy of the page at that point in time.

That’s pretty standard for a wiki. But here’s where it gets pretty neat. First, a quick scan of the set of tiles shows you the history of the page concisely.

You can see the sequence and amounts of adds, edits, and deletes. If the page has had multiple editors, you can see how it was passed back and forth, and who did the bulk of editing, or even which editor tended to add, and which to delete, all at a glance.

Hovering over the edits gives you an even more detailed view of the sequence of changes. As you hover over each icon, each parallel page scrolls to the edit in question and highlights it.


It’s not quite Heavy Metal Umlaut yet, but it’s getting there, and it’s already one of the slickest approaches to revision scanning I’ve seen. (Sorry for the small size image, but this page was getting too download heavy).

Federation over Collaboration

It’s perhaps weird that I would cover the federation aspect of the Smallest Federated Wiki last in this article. But I have two good reasons for that.

The first is it is really hard to grasp what federation looks like in wiki-land without trying it.

The second is that federation is really a smaller idea in a larger vision. The core problem addressed in Smallest Federated Wiki is how to make a wiki that resists calcification.

Parallel columns, draggable elements, and revision features make reorganization cheap and attractive.

The JSON basis prevents fossilization of data elements, and allows an easy route to bring dynamic third party material into the site.

And federation’s secret weapon is diversity as an evolutionary strategy.

But this is perhaps enough of a post for today.  The point here is to just try it. Explaining why you’d want to do this stuff is like explaining why you’d want to browse web pages in 1993.

Get started in the sandbox. Put some time into this — this is a mental stretch, but it is worth it.  Then talk to me if you want to go further.