Using Federated Wiki in the Classroom: Getting Started

This post assumes that you’ve read some other posts on federated wiki. There’s a few dozen on this site if you have not. Click the federated wiki tag and then scroll down to see them all.

If you know what federated wiki is, the following description should get you started with federated wiki use in your classroom.

Make Page of Site Creation Links

Set up a page in your class federated wiki (owned and managed by you) that links to not-yet-existing sites for each one of your students. You’re running federated wiki in farm mode, so going to these sites will create them for the students who go there. The page will look like this:

2014-09-01_0716_001

 

 

Have Students Set up Their Sites and Bio Pages

When a student clicks on their link, it will give them a new site with the name you specified. I chose a convention of “first two letters of first name + first two letters of last name” which allows me to quickly identify a student while still giving them internet anonymity if they want it. Here’s what it looks like when the student clicks it:

2014-09-01_0700

Under “Pages about Us” have the student put in a name as a link. It could be their full name, their first name, a nickname. Just as long as it is recognizable to you. After adding the name as a link, they click on the link. This new page will be their bio page. At this point I show them an example bio of myself — something relatively lighthearted but substantial.

Students will draft their bio pages. A lot of students will make boring bio pages at first, but here’s part of the genius of wiki — have the students look at other student bios after they are done making theirs, and generally this will help some of the students conceptualize theirs. At the end of this you’ll end up with a lot of very cool bios.

2014-09-01_0702a

 

IMPORTANT: After students set up their bios, it’s a good time to have them “claim” their sites with the big “Claim” button at the bottom. This uses a Mozilla-based Persona login that sets the student up as the sole editor of the site. If you forget to do this early, students will end up unintentionally editing other students sites, which isn’t the end of the world, but is a bit of a headache. Have them claim the site early.

 

Create a “Class Circle”

Now it’s your turn — you have to create what we’ll call the “Class Circle”. This will be a page that students can load to see the work of all the other students in the class — not just in the recent changes feed, but in search results, “twin” notifications, and the like. To make a circle create a bunch of factory drop areas on a page named “Our Class Sites” or something similar:

2014-09-01_0708

Now go to that page of links of all the student sites, and for each link:

  • Click the link to go to the student page.
  • Click the link to the student bio.
  • Drag the student bio onto an empty “factory” drop area

This will pull a “reference” to the student site and the first paragraph of their bio into your page. (Note: I did this with the “link launch page” described above to streamline the process and standardize site names, but you could also have student self-select site names and email you the link).

I had 20 students — the process took about 10 minutes. It’s the most time-consuming part of the setup. But when you are done you should have a page that looks like this.

2014-09-01_0709

 

Tracking Student Work Using the Neighborhood

The circle page is pretty cool, because anyone can load it and see all the class activity (to be technical: it pulls class sites into their “neighborhood”). Students can (and will) fork it back into their own sites. Unlike FeedWordPress and other “hub” designs, however, the power to make circles is given to the students as well — the students can easily create their own circle page entitled “English majors” if they want, and pull in all the references to sites by English majors in the class. They can set up circles for their group, or for the three people who always do exemplary work.

Once you have your class circle in place, you be able to track the work of the class through your recent changes page. Here’s a snapshot of it the day after class:

2014-09-01_0718

Here I’ve loaded my class circle, clicked recent changes, and am looking at a recent submission by a student on the “redefinition” aspect of SAMR. One thing to note here is how well the form supports a “notes” aesthetic — the student here writes very well, but is allowed to put half-formed thoughts up and questions up to which they can later return.. If the metaphor for the student blog is the personal journal, the metaphor for federated wiki is the researcher’s notebook.

We also see the usefulness of the colored icons here. Scanning this changes feed, we can see that:

  • The student we are looking at right now, with the teal gradient, has been very busy, and has in fact gotten all their work for next week already done.
  • Four other students have done a page on the SAMR model of educational technology impact,
  • Another student (purple gradient) has done the SAMR assignment, although maybe not the “note-taking strategies” assignment.

Since I used a naming scheme (first two letters of first name and first two letters of last), I can hover over these icons and know immediately which student they represent. The teal icon here has a hover text of “krde.mits.wsuv.wiki”, which tells me this is Kristin D’s work.  If we click on the teal icon at the top of Redefinition, we can get her Welcome Page. Another shift-click opens up her bio page as well (click replaces the page to the right of the page clicked, shift-click adds a page in the first empty spot, giving you the page in an added column — it sounds odd, but feels awesome when you get the hang of it).

2014-09-01_0721

 

 

We can also look at just Kristin’s feed now that we’ve collapsed our “neighborhood” to just her.

2014-09-01_0722

 

 

Using “Twins” as a Student to See Other Approaches to an Assignment

Reloading our class circle and going to the page on SAMR model, we can start to see how the federated aspect works in the classroom. Any student or teacher can easily use the “twins” notification up top (that part that shows links to older and newer versions) to pull up different student work on the same subject.

2014-09-01_0726

The assignment was to find some articles on SAMR and to summarize them. In this case, a day after class, a couple students have found the article they want to use, but not done anything yet. One of the neat things here is I can check on work in progress — see what articles they’ve selected and the like. For the students, one of the neat things is that by seeing other student work in progress, they have some idea of what the target they are trying to hit might be.

That’s enough to get you started. We did more in class than this, but I’ll write up the next part later.

Noteworthy Problems

I found the process to be pretty smooth by edtech standards. Certainly orchestrating mass registration in a class always has a bit of a herding cats element to it, but this process actually compared favorably with something like signing up for Google Sites or setting up a blog. That said, there were a few issues I’d make more effort to plan around.

Claiming Sites

As I mentioned, you should be very insistent that students claim their sites early on. We did have one issue where a student looking at other student bios ended up claiming someone else’s site inadvertently, which was a bit of a mess to sort out. Before the students start to wander off their newly created site, have them claim it.

Creating the Class Circle

I found it a tad difficult to create the Class Circle while simultaneously assisting students in setting up their bio pages. I think what I would do in retrospect is have them set up bio pages, claim them, surf other bio pages, edit their own pages again — then I’d call a break. I could probably get the circle page made in about five minutes while the students go get a soda. When they came back, we’d continue.

Logouts and Yellow Borders

I’m not sure how this happened, but a couple students logged themselves out and started getting “yellow-border” pages, indicating their changes were not being saved to the server. Additionally, in the flurry of 18 people hitting the AWS micro instance at once it may be that one or two of the edits did not post because of that (note: this is only speculation). In any case, I think I would have started off explaining blue and yellow borders to students, and showing them what to do if they got a yellow (check to make sure you’re logged in, then fork the page to the server to save your offline edits).

Surprises

The biggest surprise is that no one really had trouble wrapping their head around the tool. It was no harder for students to understand than blogging or social bookmarking. We even did an activity where students forked a page with a  George Siemens video on it, took notes on the video, checked the notes other students had written through using the “twins” links, collaborated with students in their group on a page, then did a cross-tab drag and drop to fork the resulting video summary to their site.  One or two students out of the class didn’t quite make it, but the vast majority of the class did this easily.

george

(If Warhol did George, it’d have looked like this).

This might all fall apart as we get deeper into the tool — here they are just executing actions without really understanding the underlying interaction model. So I don’t want to celebrate too much yet. But it may be that federated wiki is easier for people who have no extant understanding of feed-based blogging communities or standard wikis since we don’t have to unseat any exisitng ideas of how the web is supposed to work.

Then again, it could just be I got lucky — this was a heavily guided activity, and the question is whether they can do it without the guidance. We’ll find out next week.

 

 

Advertisements

Copying a Whole Site Is Remarkably Easy In Smallest Federated Wiki

Operations in Smallest Federated Wiki tend to be page-level — dashboard style site managers have been avoided for the moment. Still, the speed at which operations can be executed makes site-wide stuff pretty easy. This video shows how to copy a small fifteen page site in about a minute.

If you think about how long it would take you to log into a dashboard interface, export a site, log into another dashboard interface, and upload the file to the import process — Smallest Federated Wiki compares favorably.

How is this speed achieved? First of all, moving the integration to the browser allows us to pull two sites together into a single interface. Importantly, neither site has to have any knowledge of the other before the drag, because to the browser a site is just another data source. It’s the difference between the two models below, with the federated model on the right.

fedwiki

 

 

Client-based integration is more amenable to fluid reuse because it can have a single integrated view of multiple sites in a way that server-based systems can not.

The second reason it’s so quick is the parallel pages structure. The multiple pages on the screen are less impressive looking than your average web page. But you pay a massive tax for that look in the form of the “click-forward, act, click-backward” actions you perform every single day. Here you see how much eliminating that speeds up interaction, as you click on a list that stays in place and then fork the pages without playing the “forward-back” game.

As a side note, having used SFW for a while, I now get frustrated in “normal” web interfaces that use the single-page model. It feels ridiculously kludgy. Forward and back in 2014? Are you kidding?

The third reason the operation flows well is the data-based nature of it. We’re not shipping layout to the new site, we are essentially copying the database record for that page. No formatting surprises to greet you after the copy operation.

So fine — this is fifteen pages. What if you wanted to fork a site of a hundred pages? Well, it’d probably take seven times this long, so maybe 10 minutes?

That’s ten minutes to fork a picture perfect copy of any SFW site in the world. I’m not even sure you can do that in GitHub in ten minutes.

(Are people beginning to get the power of these few small interface changes yet?)

 

The Web is Broken and We Should Fix It

Via @roundtrip, this conversation from July:web

There’s actually a pretty simple alternative to the current web. In federated wiki, when you find a page you like, you curate it to your own server (which may even be running on your laptop). That forms part of a named-content system, and if later that page disappears at the source, the system can find dozens of curated copies across the web. Your curation of a page guarantees the survival of the page. The named-content scheme guarantees it will be findable.

It also addresses scalability problems. Instead of linking you to someone’s page (and helping bring down their server) I curate it. You see me curate it and read my copy of that page. The page ripples through the system and the load is automagically dispersed throughout the system.

It’s interesting that Andreessen can’t see the solution, but perhaps expected. Towards the end of a presentation I gave Tuesday with Ward Cunningham about federated content, Ward got into a righteous rant about the “Tyrrany of Paper”. And the idea he was digging at was this model of a web page as a printed publication had caused us to ignore the unique affordances of digital content. We can iteratively publish, for example, and publish very unfinished sorts of things. We can treat content like data, and mash it up in new and exciting ways. We can break documents into smaller bits, and allow multiple paths through them. We can rethink what authroship looks like.

Or we can take the Andreessen path, which as Ted Nelson said in his moving but horribly misunderstood tribute to Doug Englebart, is “the costume party of fonts that swept aside [Englebart’s] ideas of structure and collaboration.”

The two visions are not compatible, and interestingly it’s Andreessen’s work which locked us into the later vision. Your web browser requests one page at a time, and the layout features of MOSAIC>Netscape guarantee that you will see that page as the server has determined. The model is not one of data — eternally fluid, to be manipulated like Englebart’s grocery list — but of the printed page, permanently fixed.

And ultimately this gives us the server-centric version of the web that we take for granted, like fish in water. The server containing the data — Facebook or Blogger, but also WordPress — controls the presentation of the data, controls what you can do with it. It’s also the One True Place the page shall live — until it disappears. We’re left with RSS hacks and a bewildering array of API calls to accomplish the simplest mashups. And that’s because we know that the author gets to control the printed page — its fonts, its layout, its delivery, its location, its future uses.

The Tyrrany of Print led to us gettting pages delivered as Dead Data, which led to the server-centric vision we now have of the web. The server-centric vision led to a world that looked less like BitTorrent and more like Facebook. There’s an easy way out, but I doubt anyone in Silicon Valley wants to take it.

fedwiki

Ward Cunningham’s explanation of federation (scheme on right) — one client can mash together products of many servers. Federation puts the client, not the server, in control. 

UPDATE:

It seems we got front-paged at Hacker News. So for those that don’t follow the blog I thought I’d add a one minute video to show how Smallest Federated Wiki uses a combination of JSON, NodeJS, and HTML5 to accomplish the above model. This vid is just about forking content between two different servers, really basic. Even neater stuff starts to happen when you play with connecting pages via names and people via edit journals, but leave that to another day.

This and more videos and explanations are available at the SFW tag.

The Part of Wiki Culture the Classroom Forgot

If you look at most treatments of wiki in the classroom, people talk about collaboration, group projects, easy publishing, revision control. All of these are important. But one important element of what makes a wiki a wiki has been underutilized.

Wikis not only introduced the editable page to users, but the idea of page-creating links. (In fact, this invention pre-dates wiki and even the web, having been first pioneered in the Hypercard implementation Ward Cunningham wrote for documenting software patterns).

Page-creating links are every bit as radical as the user-edited page — perhaps even more so. What page-creating links allow you to do, according to Cunningham, is map out the edges of your knowledge — the places you need to connect or fill in. You write a page (or a card) and you look at it and ask — what on this page needs explanation? What connections can we make? Then you link to resources that don’t exist yet. Clicking on those links gives you not an error, but an invitation to create that page. The new page contains both links back to concepts you’ve already documented, but also generates new links to uncreated resources. In this way the document “pushes out from the center” with each step both linking back to old knowledge and identifying new gaps.

In the video below I show this “pushing out from the center”  process on a wiki of my own and talk about how this architecture and process relates to intergrative learning. For best viewing, hit HD button and make full screen.

Using Wiki for Connected, Integrative Learning from Mike Caulfield on Vimeo.

Amelia Bedelia’s Hats Are Not the Problem

So there’s been an Ameila Bedelia Wikipedia hoax. We learn that Amelia was not inspired by a maid from Cameroon who wore sensational hats, a “fact” cited in a vandalism which survived on the site since 2009.

Yawn.

First, let me say in a world where Elsevier was recently discovered to have published half a dozen fake journals for drug companies, a world where more recently 60 articles were retracted from the Journal of Vibration and Control due to a “citation ring”, and a world where med research postdocs are faking anti-cancer trials and still working, I’m not sure to what we’re comparing this “hoax”.

But, more importantly, the main problem with Wikipedia is not about error.  The problem is more subtle than that, and it’s not something that the Daily Dot is going to cover anytime soon.

Here, for example, is a segment introduced on the Amelia Bedelia Wikipedia page in Spring of 2007, and existing through the end of that year:

The name “Bedelia” is a derivation of the common Irish name Bridget. Irish maids were portrayed as being comically inept in the vaudeville theaters of New England in the late19th century. A popular joke of the period has a maid instructed to “Serve the tomatoes undressed”; she brings the dish to the dining room, wearing only her underclothes, saying, “I won’t take off another stitch- not if I lose my place, Maam”.

Interesting, right?

vaudeville

In January 2008, that edit disappears.

bedelia

As far as I can tell, the redaction never is discussed, and the vaudeville connection never returns.

Is the beloved Amelia Bedelia a protracted Irish Maid joke? A sanitized relic of a previous age when the Irish weren’t yet considered “white”?  That seems a rather important question for a scholarly work. And after reading  about the potential vaudeville connection, it’s hard to un-see:

tumblr_l5fdweyUDY1qzjiplo1_r1_500[1]

At the same time, that’s a pretty hefty accusation to make on something that is supposed to be the reference page on Amelia Bedelia.

It’s important to note that, unlike uncaught hoaxes, this sort of thing happens on Wikipedia all the time.

And the problem here is not that the Wikipedia community allowed such a paragraph initially, or that it eventually deleted it. People can have honest disagreements about such things.

The problem here is the centralization. Someone removed the edit, no one in the community noticed or defended it, and the information disappeared for good. For all intents and purposes, it vanished from the face of the earth.

So while EJ Dickson runs down the number of places the Cameroon hoax showed up, somewhat harmlessly, in news copy and book reports, it’s more interesting to me to think how many of those people doing web research on Amelia Bedelia may have, in fact, been spared considering some of the more difficult and interesting questions Amelia Bedelia raises.

irish-african

We need to have authoritative networks to turn to when trying to answer questions. There’s a place for things like Wikipedia, which pushes groups toward consensus. But when those networks are too centralized, or hold a monopoly on truth, minority concerns get lost, deleted, and overuled. Controversy gets papered over. Difficult questions get sanded down smooth. Life gets easier, but at a substantial cost.

This is the issue that federation as an alternative model of networked community is meant to solve, and one of the issues Smallest Federated Wiki is meant to address.  I’ve talked about that before here, but the point I want to make in this post is even more basic. In short, we are not living in a 2008 Jay Leno monologue. It’s time to stop pretending that error and overload are the web’s biggest issues, and time to start looking at the vast variety of voices and bodies of knowledge that still have no home on the web, and no easy entry into the discussions that define our culture.

That’s a less amusing story than stoned kids vandalizing Wikipedia pages, but it’s the one that actually matters.

 

 

[Images are linked through to sources. Click for source.]

 

 

 

Federated Wiki for Distributed Notetaking (and the surprising pedagogical implications of that)

I mentioned earlier that I’d decided to change my explanation of federated wiki from a “top-down” explanation to a “bottom-up” one.

It makes a heck of a difference. I made this video below for one of our faculty, to show how even something as simple as notes becomes an integrative exercise in federated wiki. I don’t know about you, but watching the flow on SFW work is just *enjoyable* to me. I mean it when I say once you get fluidity with it it feels like a direct extension of your own mind.

So what about the federated stuff? The JSON stuff? The Universal Canvas stuff?

It’s still there. Once you start to think of wikis as personal it raises all the sorts of questions these things solve. But it’s better to start bottom-up than top down.

Doug Engelbart’s Grocery List

If you’ve watched the Mother of All Demos, you know that one of the aha! moments of it is when Engelbart pulls out his grocery list. The idea is pretty simple –if you put your grocery list into a computer instead of on a notepad, you could sort it, edit, clone it, categorize it, drag-and-drop reorder it.

mother-of-all-demos

That was 1968. So how are we all doing?

If you’re like my family, there’s probably multiple answers to that, but none particularly good. When Nicole shops, she writes it out on a sheet of paper, and spends a good amount of time trying to remember all the things she has to get. I sometimes write it out in an email I send myself, and then spend time trying to look for past emails I can raid for reminders.

Sorting? Cloning? Drag and drop refactoring?

Ha! What do you think this is, the Jetsons?

How the hell did we get here? Your average car’s fuel injector has more computing power than the machine that Englebart demonstrated this on. And it’s not like this problem has been solved elsewhere.

I’d argue that what happened was we moved towards database-driven single use apps. The truth is that there are DOZENS of shopping list apps, from Don’t Forget the Milk, to the creatively titled GroceryList, to whatever LiveStrong is doing this week.

But they each read like GroceryIQ:

Grocery IQ (Free) includes all the features you would expect in a powerful grocery app, including a barcode scanner, list sharing, and integrated coupons. If you are like me and buy the same things every week, the favorites list will help you save time. You can also edit your list online and it will update automatically on the app.

On one level, GroceryIQ works better than anything we see with Englebart. Barcode Scanner! Favorites list! Wow, powerful!

But chances are it’s a worthless piece of junk to you compared to the email method. Why? Well, you need your specific phone to use it. You can’t print it out. The people you share with need accounts too.  Your data is being compiled and sent somewhere for god knows what reason. You can choose favorites, but there’s no easy way to save this year’s Thanksgiving shopping list for next year  without the programmers building that for you. If you’d like to separate your list by the store you buy it at, you’re also out of luck. You’ve got to learn a whole new interface. If you ever move off of it, you lose all the stuff you put into it — no export/import functionality. And of course the idea that your grocery list app could somehow exchange data with a recipe app or a food log — not possible in the least.

On the other hand, managing my list in email gets me 90% of these things. So why go to another app I’ll use for two weeks and give up on?

The reason we keep using email is that for that set of tasks requiring more than plaintext but less than an app we have nothing. MS Word maybe. Excel. But somewhere along the line we handed the keys  to the current model, and so instead of getting general use tools that radically expand our ability to solve problems we get GroceryIQ, followed by whatever piece of crapware we download next week.

The solution is to capture some older priciples of software design. We need to look at that gap between the tools we use for unstructured data (email, Word) and the over-specified locked-in products that comprise single-use computing, or worse yet, enterprise software bloat. As Jon Udell has noted, most of our day consists of dealing with semi-structured data, yet the tools we have access are either too rigid or too loose to be of use. It’s time we fill the gap with networked, generative tools that can take us to the next level.