Hapgood

Mike Caulfield's latest web incarnation. Networked Learning, Open Education, and Online Digital Literacy


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?)

 



7 responses to “Copying a Whole Site Is Remarkably Easy In Smallest Federated Wiki”

  1. I think the admin of this website is actually working hard
    in support of his site, because here every material is quality based information.

  2. 2015Der Polizeichef einer kleinen Stadt südlich Texas wurde währenwe d einer Verkehrskontrolle am Sams3 erschossen, sagte ein County Sheriff!we

  3. Dogs have an excellent sense of smell, thousands of times more sensitive than ours.
    After a full-fledged detection procedure sprays, insecticides or solutions can be eventually spread out.
    These dogs are trained enough to sniff out any kind of parasites.

  4. Very neat, but you can actually do it in Github in just a few seconds 🙂 (Nitpick)

    1. I really want to know how FedWiki is different than GitHub. Is it because I host my own FedWiki?

      1. Granular forkability mainly. I can fork content at the level of the page, not the repository. Lots of other things, but that’s the kicker.

  5. […] actually cheating a bit because I got into this blog a few years ago when he was writing about Federated Wiki, then he moved on to the garden model versus the feed model, and on to shared resources. But […]

Leave a comment