I work a lot with teachers that don’t want to expose themselves to risk, argument, or harassment on the web. They create crazy good stuff that would be useful to other people for their classes, but the thought of sharing it on the web where they would be prone to lawsuits or complaints from wingnuts is unappealing to them or their bosses, so into the Blackboard Learning Management System it goes to die behind a password.

What sort of things are they afraid of? Well, maybe they are afraid that the readings of their class on gender identity will get picked up by wingnut media, and their legislators will be pushing for them to be fired. Maybe they are afraid that the page they wrote on the economics of medical care, in which they use a graphic under fair use, will get hit by a copyright suit. Maybe they are afraid that some unfriendly pedant out there will see hastily composed lecture notes and scoff at a mistake they make in presenting kin selection algorithms.

All these things have low probability overall, but present enough risk that people won’t share. As open educators we’ve fought, I think, a prolonged battle to cut through the FUD and get people to embrace the small level of risk.

I’ve lately been wondering if there are other solutions. Almost all the risks come from people you don’t know encountering your stuff and making your life miserable. So the solution has been to cut off access to your stuff by people you don’t know, which reduces network effects.

But another way to do this is to let anyone access the stuff you create (worksheets, explanations, activities, etc) but only let people who know the creator see the identity and institution of the creator. In other words, you sort of password protect the identity of the person doing it, not the asset itself.

I think (maybe) with hashing this might not even be hard — identity is stored in a hash, when I find materials I like they are checked against my list of email contacts to see if the hashes could be results of any of those, and if they are I can see the person’s identity. If not then they are Anon689aef6, or whatever.

Just playing around with the idea. It would be a scheme mostly for people wanting to release Creative Commons licensed material for other to fork while minimizing exposure.

A lot of people have been tweeting and emailing me and DM-ing me the recent Guardian piece by Iran’s “blogfather”.

You should read it yourself, but in short it is the story of a man sent to jail for blogging in Iran at the height of blogging’s influence and coming out of jail many years later to find that Facebook, Twitter, and Instagram have “killed the web.” And this is true. And it’s horrific. You need to read the article to remember why this fight matters.

In a related conversation yesterday we were talking about the New York Times article featuring a cast of merry Luddites talking about escaping the endless grind of Facebook and the stream.

And yes, The Stream Won. I get it. But when you ask many people *why* it won the answer you get, more or less, is that Evil Facebook and Twitter and Instagram hid the truth from the larger population and fooled them into thinking they wanted Evil Facebook and Instagram and Twitter instead of the exhilarating open web.

But that’s delusion at best. Facebook, Instagram, and Twitter won because they solved problems that the open web repeatedly failed to solve. To some extent, they became evil because they won; they didn’t win because they were evil.

If you want to make a difference in this fight it’s important to understand what those issues they solved were, and to provide open solutions to them. A lot of the things that made Facebook what it is revolve around gaps in HTML and HTTP that once the web got up to speed never got addressed.

What we have learned over time is that people don’t want to go to 80 different sites, with different interfaces, layouts, and ads to read. They want, mostly, to go to one site with a standard layout and look at things there.

Maybe you love to go to 80 different sites a day. Maybe the visual diversity and experience of learning a new interface every five minutes is super-appealing to you. Maybe you think everyone is just being lazy IT’S NOT THAT HARD GUYS AMIRITE?

Great. You get a gold star. But you’re why Facebook won. For most people that “visual diversity” looks like 1970s commercial sprawl:

This is what browsing the web feels like today.

Do you know what Facebook feels like to people? It feels like this:

It feels like a carefully crafted downtown, full of many different things but where building codes have enforced a standardization of design.

Before you protest much, do you remember what your day looked like at the height of blogging? I remember what it looked like for me — it was Google Reader, all the time. And what Google Reader did was strip out all that graphic design we had worked so hard on so we didn’t have to deal with it, and we could read in a peaceful, quiet manner, in a standard interface.

Or engage in a thought experiment. Imagine that every email you got during a day had different fonts, headings, layout, navigation, and scrolling bar behavior. Wouldn’t that be fun? Or even better, every email forced you to click, and go read it on a beautiful custom-designed website. Then you would reply by making that person come to your website and emailing them a link to your new GeoCities creation. Wouldn’t that be awesome?

No? Well here’s the thing. People read the web now at the level they read email — they look at a lot of stuff. And what they want (and what many people continue to shame them for) is a standard interface that allows them to do that without feeling stressed.

You want to win against Facebook? Let go of the idea of people reading your stuff on your site, and develop or support interfaces that put your readers in control of how they view the web instead of giving the control to the people with the servers. Support people looking into federated recommendation systems. Make friends with the idea of full copies of your stuff flowing across the web instead of links.

There’s a way out of this that brings back a diversity of viewpoints on the web. But we will never get there if we require people to read our stuff on our site.

NOTE: People that don’t understand federation or syndication may think I am saying that we just have to make peace with the Facebooks and Twitters of the world. I’m not. I’m saying that we have to build a federated system with less ego, one that has the affordances of Facebook but on a distributed platform. Read my old posts on Federated Wiki if you want to see what that looks like.

Markdown support has been added to Wikity (more specifically GitHub-flavored Markdown). I’ve done this for some very good reasons, and I’ve also done this a bit differently than most implementations, and I thought I’d explain why.

First, a brief description of what Markdown is, for the uninitiated. Markdown is a markup format produced in 2004-ish by Jon Gruber with some input from Aaron Swartz. The idea of Markdown was to create a markup syntax that balanced human-readability with machine readability. Like wiki markup before it, it drew heavily from conventions of a format called setext which was used in Usenet newsgroups and email communications.

Here’s a comparison of what markup looks like in HTML and Markdown:

Heading
=======

Sub-heading
-----------
 
### Another deeper heading
 
Paragraphs are separated
by a blank line.

Leave 2 spaces at the end of a line to do a  
line break

Text attributes *italic*, **bold**, 
`monospace`, ~~strikethrough~~ .

Shopping list:

  * apples
  * oranges
  * pears

Numbered list:

  1. apples
  2. oranges
  3. pears

The rain---not the reign---in
Spain.

A [link](http://example.com).

Why Markdown and Reusability Go Together

“So what?”, you might think. “Markdown is moderately easier to read and work with than HTML but I use an HTML editor so I don’t ever see that HTML gobbledygook!”

Well, we’ve set it up so you can use the HTML editor side by side in Wikity next to Markdown. So you don’t need to change a thing. But I’d like you to consider a couple reasons why you might try working in Markdown.

Markdown keeps you honest. Visual editors pander to people who want to control how something looks rather than what it means. But in our multi-device world you can’t really control how something looks. When you do silly things like declare the size of a heading in absolute terms, you create a reusability mess that adversely effects everyone down the line.

Now it’s true, the WordPress editor has gotten very good at saving people from their worst instincts, but then there’s the copy problem…

Markdown solves the copy/paste problem. When you copy text from another website into your WordPress editor kittens die. Lots of kittens. Even if the text you pasted in looks good to you in your browser it looks horrible in someone else’s, and it’s probably uneditable to boot.

What happens is this. The website you go to has a databased version of your text. It looks at your browser, your platform, your screen size and the surrounding template and encodes that all into a set of HTML probably keyed to a specific style sheet served up separately. Now you go and copy that text into a new context that has to serve multiple browsers and platforms and screen sizes from a template that works entirely differently and uses its own, different style sheet.

What you’ve done is coded the use context into the content, and that is very bad.

With Markdown, you copy and paste the text in, and then quickly add the semantic markup, indicating links, blockquotes, italics, etc. Your text comes over clean.

Markdown is friendly to the mobile composer. I’ll be honest: I think mobile devices are the wrong devices for composing things. But I know I’m in the minority here.

Now if you’ve ever tried to blockquote or bold text with a mobile device, or tweak which words in a phrase should be part of a link you’ll have realized that a big problem with text editing on these devices is that 30 years of WYSIWYG development has assumed that there is a mouse attached to your machine.

Markdown solves this problem by making all formatting text-based. If you can type on your phone you can format.

Markdown will make you faster at everything. Add this to the “hard-to-learn but easy-to-use” category. There is a small learning curve with Markdown. However, because Markdown allows you to compose and format without periodically breaking concentration to look for the tool bar, grab the mouse, select text and find the right button it will make you faster in everything you do. There’s a reason that programmers, the laziest people on the planet, have gravitated to Markdown for documentation and composition.

Special bonus for teachers: keep students focused on the content. I’ll just add this in here, from personal experience. I have been teaching with various site making tools for more than a decade and there’s a definite balance to be struck with student design on projects that are not about student design.

I think, for example, that your history or stats class will enjoy being able to choose a WordPress template for their page, a background image, maybe a custom header, etc. These things build a sense of ownership with a site.

But I’ve also seen projects with Google Sites and other tools go awry, where a certain group gets so fixated on the issue that they can’t get the picture to float-left just the right way or get the blockquote in a certain section to just the right size that they forget they are supposed to be doing history or stats or sociology.

In fact, I’d argue that part of technical literacy these days is understanding in a multi-device accessibility-focused world that this pixel-level focus is a sign of technical illiteracy, and we must do our best to get students to understand the separation between content and styling that makes the modern communications ecosystem possible.

There are more reasons, but damn this post is long. I was going to go into a long discourse (diatribe?) on the history of WYSIWYG and how it killed text reusability, but this post is too long already.

Final Note

We did the implementation differently than JetPack, becuase JetPack has different goals.

JetPack lets you type in Markdown which is then converted to HTML which then gets saved. This is because the assumption in blogging engines is that once you post you will likely never edit that page again, so there’s no benefit in maintaining Markdown editability relative to the cost of the system having to interpret Markdown each time a viewer looks at your page.

Needless to say, we see things differently. The primary use to us of Markdown is as a storage format, so that when someone forks your page they get a nice clean Markdown version of it (if that’s the way you wrote it) that they can easily edit and update.

So we hacked in a module called Parsedown, and rolled our own wrapper for it.

What this means is if someone writes Markdown-based pages you should be able to fork those pages. Ideally, what I’d like to see is that a few communities that emerge on Wikity might make community rules which either require or forbid the use of Markdown for materials that they produce.

There is a Markdown Cheatsheet here, and of course you can go get an account on Wikity here. The join code for the moment is “peloton”, but if it changes you can always reach me via Twitter (@holden).

Here’s the pattern for searches for “open textbook” searches on Google.

(source)

I just ran this out or curiosity a couple minutes ago. You’ll notice immediately that there is a cyclical pattern.

Click source up under the image to go and explore the graphic yourself, but the pattern is pretty easy to sum up. The high peaks are all August/September and January, months in which both the semester system and the quarter system launch courses. The slightly lower peaks are April, when the quarter system launches courses but the semester system does not.

This is interesting, because this is *not* the cycle you would expect if faculty were searching for open textbooks during a textbook selection process. In both the semester and quarter systems you’re generally locking in a textbook not at the beginning of a class, but during the previous registration period. For example, at WSU we lock in textbooks in Feb/Mar for the fall semester and November for the spring semester, and we do that, more or less, because it is both federal and state law that we have textbooks set at registration time.

It’s foolish to speculate too much on Google Trends data, especially on low frequency terms, but I just can’t help but imagine that this is an instructor looking for something in the couple weeks before a class.

The picture gets even weirder if you map out “open educational resources”. From my experience with faculty in my instructional design role, I’d expect to see a pattern where open resources are pulled during the first few weeks of the semester as the final holes in later weeks of the course are plugged. And we do see that — but what is surprising is the obviousness of the pattern:

(source)

It’s almost too perfect. The red line of OER here looks like the blue line has been shifted slightly to the right. When the course starts, we’re looking for open textbooks, but a few weeks into the course we’re desperate for OER.

Again, I can’t stress enough the dangers of reading narratives into trends like these. This is idle speculation at best.

But it sure is curious, right? And if true, there are some implications, I think, about how these materials might be designed…

I just found this 2014 quote from Clint Lalonde:

Something that is easy to copy makes it more likely that it will be copied. And if it is copied, it has more chances of living beyond its original life. A thousand versions of something seems to me to be the ultimate sustainability plan for any piece of content.

This is exactly right. And the crazy thing to me is that we have an entire movement based around reuse that has not made it easy to copy things.

I’ll add that profligate copying is probably also the route to getting past the rigidity of the current textbook paradigm. A certain amount of people who copy will adapt a text. But zero percent of people who link to a text will adapt it.

So if you want to get to a culture that iterates the current textbook model out of existence, you need to get people to copy at a level that looks, frankly, absurdly wasteful. I don’t know if “a thousand versions” was hyperbole on Clint’s part, but for me it represents a minimum we should be aiming for on more popular resources. Assume a static percentage of reusers to remixers and get the copy number where it needs to be to produce real pedagogical change.

1. WSU Vancouver installs a server running some Wikity-esque software on WordPress Multisite. It allows faculty (and hopefully, eventually, students) to make as many WordPress sites as they want.
2. Faculty make wiki-like linked sites on personal interests, but also use the platform to assemble and write materials for their classes.
3. Meanwhile UBC or UMW or NIU or Clark College installs a similar instance of Multisite (or really, anything that can comply with the Wikity protocols). Faculty there get to do the same thing — make as many little sites as they want for both classes and personal interest.

Now, without forking, maybe you’ve seen this story before. It’s pretty close to the repository dream that will get you laughed out of any OER veteran’s office. But forking makes all the difference.

As a faculty member putting together a course, I pull out my syllabus and look at the week to week learning goals. And I search our open repository for stuff that makes sense for my course, and fork it into my evolving class space. Here’s me doing that.

Of course, what happens is that the software makes sure that as I build my own site in my own space I am feeding forward materials for others to then take and build on.

The WSUV site is live, I showed it to my boss yesterday, and I’m ready to promote it locally. But I’d love some partners in the effort. Anyone want to try running one of these at your own school?

After my presentation at OpenEd, David Wiley said he wished he hadn’t gotten a call in my session because he wanted to ask a provocative question: How was what I was doing with OER different from Pinterest for text? He said he thought he knew the answer to that, but would have liked to hear me articulate it.

I replied that I’d *love* to be compared to Pinterest, which is a huge inspiration to me. In fact, I’ve long thought that Pinterest is the most successful OER sharing engine in existence. In K-8 education, Pinterest is *the* OER platform; everything else is a rounding error. This is partially because pictures are just more natively shareable than text on the web, but it is also because the metaphor is one of copying resources into one’s own space. This is made grokable to the user by treating these spaces as “boards” where multiple resources exist for collection and tagging. (In fact, Ward Cunningham talked a bit about the Pinterest metaphor as a direction that community visualization could go).

The differences between Wikity and Pinboard?

• Pinterest requires that you be on a single site (there’s no federation, or even quasi-federation)
• Pinterest does not give you tools to edit or modify pins. There’s no 5Rs in either the legal framework or the tool capability
• Pinterest doesn’t do hypertext. These pins are saved, but they are not *linked*.

These are not small distinctions — in building an open framework they represent core ideas. If you imagine some sort of sliding scale of open architecture, Pinterest is far closer to Facebook than Wikity. We share a metaphor, but not an architecture or a philosophy.

True, said David — but maybe you could start the conversation from Pinterest, and you’d get further.

So I’ve taken that to heart, and have chosen to represent the front page of Wikity in a Pinterest-ish style:

Right now the federated aspect makes it hard to provide certain functionality from the front page — you can’t copy without going to the article in question first, etc. But these issues are probably surmountable.

I was talking with Jim Groom yesterday, and he wondered if we could push the metaphor even further, and have the individual sites have a default view like this too. And the more I think about it, the more I think we are going to have to do that.

If we do do that, we might have to contend with the issue of forking before reading. We’ve generally assumed that people read an article and then decide whether to fork it to their site. But another interesting pattern might be to go on a quick foraging session and fork everything that looks halfway interesting to a working space which gets pruned later. Maybe I make a site called mike-toread.wikity.cc and I just scan quick and dump everything in there. I kind of like this idea, because it radically reduces the stress around copying. You copy a resource into one space to read it — if you copy it to some of your other spaces, *then* it maybe means you think it’s good.

I’m also increasingly thinking that even individuals are going to want a multisite installation — that people may use different sites like different boards. But it may also be that use of tagging fills those needs, so that will be something to watch.

Wikity is up. The join code is “peloton”.

I show how you can work in Wikity in the video below. In brief, the idea is other people’s investigations or explanations of things feed into what you are exploring; you add your bit to that and feed it forward for others to use. At the same time, since people work in their own space, everybody gets to keep control of their own process, built to achieve their own ends.

If you’ve seen that model before, it’s because it’s exactly the model that Downes and Siemens advanced all those years ago in the first cMOOCs: “Aggregate – Remix – Repurpose – Feed Forward“. But the tools used there — wiki, blogs, etc — were, in my opinion, not as well suited to the cycle as they might have been, at least for certain types of endeavors. Blogs tend towards conversational and quotative reuse, which is great for some subject areas, but not so great for others. Wiki feeds forward into a consensus process that provides a high level of remix and reuse, but at the expense of personal control and the preservation of divergent goals.

Wikity takes lessons from federated wiki, combining the individual control of blogging with the permissionless improvement of wiki. In the video above I show how a student might use this to begin an investigation into a subject, but there are multitude of uses for this technology. I am particularly excited about ways it might be used to help faculty and students to collaborate on OER across institutions. (If people want, I can show what the process of putting together class materials looks like on Wikity — it’s pretty amazing).

I’m putting together an institutional version of this too for WSU Vancouver around the OER idea. If other people wanted to run an OER site like this at their institution, we could build a federation of easily remixable content. Because when there is a network of these sorts of sites — that’s when it gets really interesting. 😉

(Oh, and thanks to Shuttleworth’s flash grant, which helped make this progress possible).