Smallest Federated Wiki as a Universal JSON Canvas

Watching Alan Kay talk today about early Xerox PARC days was enjoyable, but also reminded me how much good ideas need advocating. As Kay pointed out repeatedly, explaining truly new ways of doing things is hard.

People looked at the PARC stuff, and many saw a solution to this problem or that problem. But that wasn’t the point. If you walked away from PARC saying — wow, fonts! or if you walked out of the Mother of All Demos saying “I’ve been *looking* for a way to organize my grocery list” you didn’t really get it.

These technologies were not solutions to problems as much as a whole new way to think about solving problems.

Anyway, the reason that I keep hammering on about federated wiki is that I think it is one of those rarer meta-technologies. In the way it upends certain ways of thinking about the web it offers us the ability to get beyond our assumptions about how people and computers co-operate.

And yet I find myself cornered into explaining it as a new way to organize a shopping list. (And doing it).

However, I’m lucky to have a good co-analyst in this endeavor. Jon Udell recently looked at Smallest Federated Wiki and, I think, saw something like what I see. SFW borrows ideas from GitHub and re-blogging platforms (like Tumblr, for instance). But it does so NOT in the context of a specialized use, but as a universal canvas. What’s a universal canvas? The Jon Udell of today points to the Jon Udell of 2006  to explain:

The most common workflows, by far, are mundane collaborations involving chunks of semi-structured data. Despite its warts, we continue to rely on e-mail with attachments as the standard enabler of these collaborations because it is a universal solvent. Our HR folks, for example, work for a different organizational unit than I do. Implementing a common collaboration system would require effort. Exploiting the e-mail common denominator requires none.

But while e-mail dissolves barriers to the exchange of data, we need another solvent to dissolve the barriers to collaborative use of that data. Applied in the right ways, that solvent creates what I like to call the “universal canvas”  an environment in which data and applications flow freely on the Web.

Jon, you’ll remember, literally wrote the book on Internet groupware. And he highlights a piece of this I don’t highlight nearly enough. SFW is a platform that allows you to apply a federated, mashup-friendly workflow to ANYTHING. Right now it’sthe *Smallest* Federated Wiki, and it only has a few plugins. But the plugin architecture is JSON-based and extensible.

A quick example. When I worked at Keene State we looked at using a Customer Relationship Management system to help us make sure we weren’t stepping on each other’s toes in dealing with faculty, and also to keep detailed notes on projects we were doing so that if someone had to step in when someone else was away on vacation they could.

But like so many collaborations, it fell apart. I did quite a bit of committee work and wanted my documents on faculty to keep track of nearly every email regarding decisions made, because having those emails at the ready is poitically important. Jenny, in Academic IT, on the other hand, wanted to track IT time more centrally and keep the “customer” record clean of intermittent communication. Becca, who worked in service learning, had about two hundred people off-campus she was working with that no one else wanted to see in the directory.

You’ll recognize this by now as a problem that a federated approach might be able to solve. But if SFW was just a wiki (and not a JSON canvas) you’d have to give up your structured data to use it, and that would hardly be worth the trade.

Here we don’t have to trade. You create a couple JSON plugins:

  • An email plugin that allows you to drag an email onto the Factory drop-area, and store the email in the page
  • An “customer card” plugin that allows you to enter structured data about your contacts, again as an item in the page’s story
  • A “meeting record” plugin that allows you to log future appointments and past meetings as structured, dated data. Maybe it can even accept a drag and drop from Outlook Calendar.
  • A “tickle-file” plugin that allows you to drop a “call next week” reminder on a customers page.

You build these, construct the proper view permissions and set it free. Everyone has their own site, but the records are connected across sites through naming conventions. Everyone has the power to organize their site the way they find most effective.

Better yet, since it’s a universal canvas, if we set up another federated wiki as a site for a project we are doing, we can just fork the pages on the people who are involved with that project over to our project wiki. And if we make notes on those pages in out project wiki, those notes can flow back to the CRM. Because it’s universal, see?

And all this flowing back and forth does not result in one bit of data loss. A page with that “customer card” plugin can get forked a dozen times through half a dozen projects and at the end of the line the JSON data is just as parseable as it was on day one.

“So now it’s a CRM?”

No, I know none of you are thinking that. You all realize the point is that this gives us a new way of thinking about how to think about problems. Not *just* CRM issues. *Even* CRM issues.

SFW isn’t really even a wiki to some extent. It’s more like a networked document.

I’m happy Jon sees this. I absolutely love my edtech friends and colleagues who, as Alan Levine put it, are committed to understanding SFW if only because of my excitement about it. But at some point you begin to doubt your own judgment… 😉

(Incidentally, Alan Kay also used to talk about a universal canvas, and claimed the most idiotic thing about the Internet was that your page of mixed-mode data didn’t arrive with the code you needed to interpret it. So the web became text with some hope-you-have-this-extension content. I’ll try and find that video.)



One Minute Federated Wiki: Pulling Something From Twitter

I’m going to start documenting how to do various things in Smallest Federated Wiki. These little tidbits will be helpful to people who have already started using SFW but may not know some of its less obvious features.

In this video, I deal with the problem of getting SFW pages you found through Twitter and other means onto your site. Often when you find a site in SFW your “left-most” context is your site, because that’s where you came from. When coming from Twitter, or a link in an email, or while browsing a site you “collapsed” (more on that later) you need a way to get another site’s page into your site’s context so you can fork it. It sounds complex; it’s easy in practice. Check out the video.

Making Class Wikis vs. Thinking in Wiki

In general I describe myself as a blogger, partially because my work title (Director of Blended and Networked Learning) just leads to too many questions, and partially because it ties together some experiences I’ve had over the past decade or so. Blogger is not quite accurate even there — the work I did with Blue Hampshire was technically more about running a pretty volatile online community than blogging, but it’s good enough description most days, even if blogging consumes only 20 or so minutes a day.

The other reason I describe myself as a blogger, though, is that after you blog for a while, you start “thinking in blog”. Your mind is writing blog posts everywhere, constantly trying to synthesize new experience into a meaningful blend of narrative and exposition. It changes you, mostly for the better.

I can’t find the reference now, but I read something recently that argued that the difference between the way a botanist looks at a flower and the way a layperson does is that the botanist looks at the flower with a question. And the point the person was making is when you write every day you start to look at everything with a question. In a way, daily writing defamiliarizes the world to you and makes it more difficult, because thoughts must be reconstructed for others who do not have reference to your experience or share your dispositions.

That said, however, different forms accomplish this in different ways, and are suited to different sorts of things. Blogging is a great tool in that it pushes you to see posts as steps in a journey to a current (and future) understanding. You link to past posts. You watch your thinking evolve. It also places you into a conversation with other bloggers, so that you understand how your conceptions map on to a larger communal consensus or disagreement. I could go on, but you get the point: the reverse-chronology structure of blogging combined with trackbacks, comments, blogrolls, and RSS pushes us to see knowledge in a certain way.

It’s been interesting playing with wiki the past few months, because what I’ve realized is that while I’ve used wikis (and taught with wikis) I’ve seldom *thought* in wikis.

As a simple example, I’ve done stuff with TV Tropes before. In TV Tropes you give certain tropes (repeated conventions) names, for instance Incredibly Obvious Bomb. Over time this library builds up to where many scenes in movies can be quickly analyzed with these ideas. You remember, for instance, the scene in Casablanca where the Jerk With a Heart of Gold makes an Iconic Song Request of his Black Best Friend?

If that seems silly, it’s not. Not in the least. By “chunking” large, complex observations and histories into terms and pages you make it possible for people to see patterns that would otherwise be invisible. The fact is, you’ll find that Jerks With a Heart of Gold tend to make a *lot* of Iconic Song Requests. That’s kind of interesting, right? It may be even more interesting that Jerks With a Heart of Gold often have Black Best Friends in a bizarre (and racist) form of Pet the Dog.

What’s Pet the Dog? Pet the Dog is another nexus of ideas. Here’s a snippet of that page:

This term was coined by cynical screenwriters, basically meaning: show the nasty old crank petting a dog, and you show the audience, aw shucks, he’s all right after all. Often used to demonstrate that a Jerkass is really a Jerk with a Heart of Gold, or, if more limited, that the character is goal oriented rather than sadistic and/or thoroughly evil. If used as an Establishing Character Moment then you skip right past the jerkass phase. Of course, this doesn’t mean specifically petting a cute animal, but any sign of nobility within a morally ambiguous character.

Sub Tropes include Photo Op With The DogEven Bad Men Love Their MamasMorality Pet (a character’s entire relationship with a villain is one long Pet the Dog moment), andAndrocles Lion (where the dog would later reward the one who petted him/her).

Now you can ask a meaningful question — to what extent is having a Black Best Friend in a film an instance (or non-instance) of Pet the Dog. Does that change over time? That’s a question in a simple sentence that as complex as any cultural studies article abstract, but rather than being established through a specialized jargon that implicitly references certain touchstone works it accomplishes the same density of meaning through simple parts well connected.

So here’s the thing — I’ve known this is the point of much wiki when reading things like TV Tropes. But I’ve never made use of it when running a class wiki (or co-designing a wiki with an instructor for a class). We’ve sat down and written encyclopedias, collaborative class notes, community resource mapping sites — all of which are excellent uses of wiki.

But we’ve never asked the class to develop a new language in the study of a subject, or to extend an old one. Instead, we gravitate to more traditional modes of academic production, but wikified.

Does anyone have examples of a class producing their *own* analytical language through wiki, TV Tropes style? If you do, can you share links in the comments?

Pressey’s Automatic Teacher

I’ve been writing a short two or three paragraph article a day on the Hidden History of Online Learning federated wiki. Usually I’ll start by dropping something I kinda-sorta know about educational technology into Google, do ten minutes research, and write it up.

It’s amazing what you find in that short amount of time. The subject I chose today was Pressey’s Automatic Teacher, invented in the 1920s and considered by some to be the first modern “teaching machine”. I had heard about it, but knew almost nothing. But the internet is a lovely thing: in short order, I came across this adverstisement in a journal article on the subject:


I’m fascinated by how much this echoes our current rhetoric, right down to the fact the advertisement can’t settle on whether it’s a tool for teaching, testing, or educational research. Of course, it can serve all three purposes, but the stuff I’ve read about Pressey seems to indicate that he really wanted it to be seen as a teaching and research machine, not a testing one, and it was economic necessity that pushed the testing frame to the forefront. It’s not too difficult to find history repeating itself in this regard (Are ePortfolios a teaching or assessment tool? Both! Sure. But as time goes on, however, the teaching mission gets buried under assessment needs…).

I’ll also take this opportunity to ask you to join the Hidden History of Online Learning project. It’s a great way to have an excuse to do enjoyable research for fifteen or twenty minutes a day while working on a federated wiki. Federation is the future, and you get to learn about it while studying the past. Mind blown? Leave me a comment below and I’ll get you set up. I’m including a video on “Your First Five Minutes in Smallest Federated Wiki” below, so you see how easy it is once I give you an account.

Student Curation in Smallest Federated Wiki

The video below shows what the process of collaboration looks like from the student end of SFW. Note that in many ways it seems like pretty standard collaboration, with two major differences.

First, the student edits their own copy of pages instead of editing communal pages. This solves an awful lot of problems that I’ll ennumerate at a later time.

Second, the student collaborates with people not by virtue of some externally or internally defined group membership, but rather by the ever expanding and sometimes shrinking “neighborhood” which adds sites to the reading/workspace based on the authors and curators of pages the student has viewed/edited.

The take-away? As a person that has written something close to 2,000 blog posts over the past decade or so, for me the best description is that it is some combination of blogging and wiki. The stuff you do is very wiki-like: recursive writing/editing, collaborative knowledge building, etc. But the way you do it is to build out your own site. You are engaged in building the sort of personal site you want, and you don’t need to get anyone’s permission for that.

The combination allows for some of the personal vibrancy (and diversity) of blogging while engaged in very un-bloglike, recursive, news-peg-less activities. And just as with blogging communities, the sum here ends up being much greater than it’s parts, over time taking on a life of its own.

P.S. I know Rolin Moe will *love* my use of the work curation here, but we lack another word for the process of collecting web materials into our own spaces and annotating them. So there you go. FWIW, web surfing isn’t really surfing either. 😉


Letting Lots of People Host Your Stuff In Their Collections Is a Good Survival Strategy



Just now I clicked on link to an article  on Jef Raskin (designer of the Macintosh interface) and received the above result. The article was an interview with him just before he died in 2005, and I was interested on his take on modern interface.

Instead it’s just more link rot.

Of course, my head goes straight to the idea of federated wiki. In federated wiki people are encouraged to fork your stuff to their own server. Read something you like? Fork it.

Getting your stuff forked is a good recipe for for making it more durable over time. If you disappear, your articles won’t. It’s kind of like 1960s psychedelic pop singles — all these bands that made just a record or two disappeared, but their music is still accessible to us because hundreds of people bought those albums and stored them in their record collection. Later on, 1980s compilations such as Rubble pulled those yard sale records together, and published compilation records that went out, again, to thousands of houses into their personal collections.

And it’s that reason why we haven’t lost short-run 45 rpm gems like The Factory’s “Red Chalk Hill”:

Whereas on the other hand an interview written up a few years ago and posted on the internet is gone forever.

Ephemerality can be cool. It’s not always a bad thing. But in general I’d like my blog articles to have a life after I shut down the server, and my music to have a life after goes under. If either thing happens it’s likely to be the people who copied them who made that happen, not me.


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.