I talk a lot about the open pedagogy case for federated wiki, but not much about the OER/OCW case for it. That doesn’t mean it isn’t a good fit for the problems one hits in open materials reuse.
Here’s how you currently reuse something in WordPress, for example. It’s a pretty horrific process.
- Log into the WordPress source site
- Open the file, go to the text editor.
- Select all the text, cntrl-c copy it.
- Go log into your target WordPress site
- Create a new page and name it.
- Go into the text editor, and paste the text in.
- Save Draft.
- Go back to the source site. Right click on the images in the post and download them.
- Go back to the target site. Open the Media Gallery and upload the images you just downloaded.
- Go through you new post on the target site, and replace the links pointing to the old images with links pointing to the images you just uploaded.
- Preview the site, do any final cleanup. Resize images if necessary. Check to make sure you didn’t pull in any weird styles that didn’t transfer (Damn you mso-!)
- Save and post. You’re done!
- Oh wait, you’re not done. Go to the source post and copy the URL. Try to find the author’s name on the page and remember it.
- Go to the bottom of your new “target” page and add attribution “Original Text by Jane Doe”. Select Jane Doe and paste in the hyperlink. Test the link.
- Now you’re REALLY done!
It’s about an five to ten minute process per page, depending on the number of images that have to be ported.
Of course, that’s assuming you have login rights to both sites. If you don’t, replace steps one and two with trying to copy it from the actual post, attempting to paste it in the *visual* editor to preserve formatting, go through the same steps, except spend an extra five to ten minutes cleanup on step eleven.
It’s weird to me how fish-can’t-see-the-water we are about this. We’re in 2015, and we take this 15 step process to copy a page from one site to another as a given.
Conversely, once you see how absurd this process is, you can’t *unsee* it. All these philosophical questions about why people don’t reuse stuff more become a little ridiculous. There are many psychological, social, and institutional reasons why people don’t reuse stuff. But they are all academic questions until we solve the simpler problem: our software sucks at reuse. Like, if you had an evil plan to stop reuse and remix you would build exactly the software we have now. If you wanted to really slow down remix, you would build the World Wide Web as we know it now.
Conversely, here’s what the steps are in federated wiki to copy a page from one site to another:
- Open your federated wiki site.
- Drag the page from the source site to the target site and drop it.
- Press the fork button. You’re done!
And keep in mind you don’t need to have the front-end of your site look like federated wiki. All that matters is you have federated wiki on the backend. Here’s a short video showing how two sites with different web-facing appearance still allow the easy transfer of pages:
You’ll notice that most of the length of this video is explanation. The actual transfer of the three pages transferred here is from 1:45 in the video to 2:30. It’s about 15 seconds a page to copy, complete with images. While the question of why people don’t remix and reuse more is interesting to me from a theoretical standpoint, I think it pales in comparision to this question: what would happen if we dropped reuse time from 10 minutes to fifteen seconds?
How is this possible? Mostly, it’s the elegance of federated wiki’s data model.
- Data Files not Databases. Traditional sites store the real represenation of a page in a database somewhere, then render it into a display format on demand. The database takes a clean-ish copy and dirties it up with display formatting, You grab that formatting and try to clean it up to put it back in the database. Federated wiki, however, is based on data files, and when we pull that link from one federated wiki driven site to another federated wiki grabs the JSON file, not the rendered HTML.
- JSON not HTML. HTML renders data in a display format. A YouTube video, for example, specifies an IFRAME as a device along with width, height and other display data. This hurts remixability, because our two sites may handle YouTube videos in different ways (width of player is a persistent problem). JSON feeds the new site the data (play a YouTube video with this ID, etc) but let’s the new site handle the render.
- Images Embedded. This is a simple thing, and the scalability of it has a few problems, but for most cases it’s a brilliant solution. Federated Wiki’s JSON stores images not as a link to an external file, but as JSON data stored in the page. This means when you copy the page you bring the images with it too. If you’ve ever struggled with this problem in another platform you know how huge this is: there’s a reason half the pages from 10 years ago display broken images now – they were never properly copied.
- Plugin Architecture.
Federated Wiki’s plugin architecture works much like Alan Kay’s vision of how the web should have worked.The display/interaction engine of federated wiki looks at each JSON “item” and tries to find the appropriate plugin to handle it. Right now these are mainly core plugins, which everyone has, but it’s trivial to build new plugins for things like multiple choice questions, student feedback, and the like. If you copy a site using a new-fangled plugin you don’t have, the page on your site will let you know that, and direct you to where you can download the plugin. Ultimately, this means we can go beyond copying WordPress style pages and actually fork in tools and assessments with the smae ease. - History follows the Page. As anyone who has reused content created and revised by multiple people knows, attribution is not trivial. It consumes a lot of time, and the process is extremely prone to error. Federated wiki stores the revision history of a page with the page. As such, your edit history is always with you and you don’t need to spend any time maintaining attribution. If the view of history in the federated wiki editor is not sufficient to your needs, you can hit the JSON “Journal” of the page and display contribution history any way you want.
We could probably say more on this, but this should do for now.
Hapgood 
Curse you Mike Caulfield for making such compelling cases that undermine my ways! (I mean that as a high compliment)
At first reading, my thought was going to be a bit of pushback over re-use in WordPress as making pages of content. But on thinking, what I have seen in practice is even more far from water– Designers assemble content into MS Word and then hand it to developers who push it back into WordPress. That 15 minutes bloats even more time.
This new flavor of using FedWiki as almost a back end is intriguing. The one thing I missed is, where/what are these other sites (the blackboard one) that are all json delivered? What else is available to harvest from?
One minor correction, the copy from Word HTML cruft issue is gone in WordPress. As of (?) v 3.9 any rich text copied from Word, or a browser page, is stripped clean of non standard markup in the TinyMCE editor- you get headings, links, bullets, bold, italic, and all the mso hoohah is gone (but no media). No, it’s not as clean as what you showed.
Wheels engaged….
Well, I should clarify — I *made* the blackboard site I just didn’t use any special login powers on it. I suppose that makes it less magic, because it means there’s not really any other sites out there to harvest, so we’re at chicken and egg again.
Good point about the mso crap. I guess I still decontaminate rich text in textpad, so I didn’t notice yet.
I tried to be reasonable in the steps for WordPress. I had it at about 22 steps with clicks and highlights and popup forms. but it felt strawman-ish. I think it’s ore or less fair as presented.
The front-end thing is new. I built the front end for the target site shown, and my brother modified the template (Gratis, thanks Ben!) to get the Blackboard site. The templates don’t interpret every fedwiki object yet, but they get by, and I think it could be a good option for someone who needs/wants a traditional looking site but would like the flexibility of the fedwiki editor. Since the templates are just js files and HTML they can live anywhere, there’s no server side capability needed.And since you can lock them to a specific backend if you want, you can prevent other peoples pages being seen on your site if that’s important to you.
You could also point at a curator site, and have the fedwiki on the backend participate in a neighborhood of editors. It would make for a very robust and scalable moderated site.
Good argument. Though WP.com allows u to reblog (granted, without editing but u can append)
Maha, that’s a good point about reblogging — it would certainly be nice if their was a similar “reuse” option.
Hang on. It’s actually not fair at all to compare WP (meant for blogging by one author per post) to fedwiki
Then again, nothing is like fedwiki so any argument would face that issue
I prefer comparison with google docs and traditional wikis
I think perhaps an argument for the comparison comes primarily in context of WordPress as CMS — a practice that is quite acceptable, socially and otherwise.
I’m not very experienced with fedwiki, but I still can’t help think you might find some magic when you begin to think about your own writing (i.e. traditional blogging) as something that can branch and iterate, where the versioning has value in and of itself. That is, setting aside all the collaborative possibilities.
PS: Decimating formatting in Textpad? Shift-command-v ftw.
I am quite familiar with fedwiki which is why i made that comment (which i can’t
remember now!)
Hi Mike,
I think that Federated Wiki’s plugin architecture is very far from Alan Kay’s vision of how the web should have worked. The key feature of Kay’s tape reel was that the data “travels with everything it needs” — every tape reel contains a library of procedures that are used for accessing and displaying the data on that reel.
A Federated Wiki data file does not contain the procedures needed to render it. A person copying a non-standard data item receives an error message. They must, via a side-channel, “download” some code from some external site and “install” it on their system. This doesn’t seem much different to me than the situation with web browser plug-ins.
In an object-oriented Federated Wiki (in the Kay sense), all data items would have rendering code embedded, similar to how images are embedded, and copying an item would bring its code along with it. And if I want some special behavior on a page, I write that code directly into the item on the page, and people copying the item get the whole working “object”, code and all — instead of me having to develop a “plug-in”, and others having to download it.
I think the plug-in situation is one of Federated Wiki’s weakest points right now (which is fine, it’s still early days, and this is a tricky problem to solve well!), and I think there’s a huge potential for data-rendering code to be written, shared, and remixed in the same federated-wiki manner as the data itself. The plug-in architecture seems like an okay stand-in until then. But when promoting something as interesting and important as Federated Wiki, I think one should be careful not to overstate its strengths.
Well, being corrected by Bret Victor is a privilege. You’re exactly right. I’ll correct the error.
The situation is better in federated wiki when you are viewing the site through the origin, because then the scripts do download with the data. But the hard problem of the web is security doesn’t allow us to do that cross-site.
Would you be interested in joining me and Ward some Wednesday on the weekly Hangout and talk through some ideas on this. We’re struggling with some issues around the spectre of plugin proliferation (e.g. you both want proliferation and fear it) and this is the issue under that. Your thinking on it would be appreciated. You can contact me at caulfield.mike@gmail.com.
As someone who has repeatedly tried and failed to get on fed wiki as a whole package, I’m glad to see the discussion breaking down the fundamentals of it.
So talking about the backend in particular, how does it compare to something like git — where data files and attribution history are alive and well?
My thoughts are:
– Histories and metadata are per-page rather than per-repository, making it easy to have a collection of pages from various sources. Preserving history while moving across git repositories is unnatural though not impossible: http://stackoverflow.com/questions/1365541/how-to-move-files-from-one-git-repo-to-another-not-a-clone-preserving-history
– History is recorded in “page actions” rather than line diffs. While nice theoretically, I’d be curious to see use cases where this is critical.
– Git histories maintain the commit ID and author’s email address while fed wiki page histories tell you the URL source of previous versions. I may be wrong about this, but if you move a git file across repositories, you might not be able to figure out where it came from. (Other than having globally centralized directory of commit hashes — which we more or less do via GitHub — but that kind of centralization isn’t ideal.)