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:

teaching_testing

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

raskin

 

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 last.fm 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:

tubing

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.

http://screencast.com/t/fRlahVd0EK5

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 audrey.hapgood.net:3000 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.

refactoring1-sm

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–

PARALLEL PAGES, VISIBLY CONNECTED!

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.

multi-column

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  
{"type":"add","item":
  {
   "type":"paragraph",
   "id":"e824fa0816b71e50",
   "text":"The web is..."},
"id":"e824fa0816b71e50","date":1401835049316},
  ..  

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

\(\int\frac{d\theta}{1+\theta^2}= 
\tan^{-1} \theta+C\)

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

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

Which displays on the page like so:

equationdθ1+θ2=tan1θ+C

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:

equation-32-nodither

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.

revisions

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.