Interview

Tips for Getting Started with Educational Wikis

• By Linda L. Briggs
• 09/03/08

[Editor's note: This is the second in a two-part interview series on educational wikis. You can read the first part here. --D.N.]

"Using a wiki in an organizational context is radically different from Wikipedia," according to  wiki consultant Stewart Mader. In this second portion of a two-part interview, Mader discusses choosing between commercial and open source wiki products, getting started with a wiki--and why Wikipedia is the single biggest stumbling block to wikis in higher education.

Mader consults for organizations, including higher ed, on wiki implementation, and offers information on wikis at his Web site, ikiw.org.

Campus Technology: When you go in as a consultant to a university and try to help them get started with wikis, what are some of the typical stumbling blocks?  What is keeping more schools from using wikis?  

Stewart Mader: The biggest stumbling block, bar none, is Wikipedia. It's funny; I've been fascinated by wikis for close to six years now, and they've really dominated my professional work. All that time, I've found myself wrestling with my perception of Wikipedia.

I think there are things about it that are incredibly transformational in terms of the way that people can work socially with technology--people who would otherwise not interact--including the whole idea that people who are not necessarily experts can build content together.  

So there's a lot of great stuff about Wikipedia, but there is a huge dark side, which is that it's anonymous, it's a very flat structure, and people don't necessarily have to log in and identify themselves to contribute. That leads to a lot of the problems you hear about in the mainstream media. I'm sure you've heard of various incidents where people have erroneously edited each other's entries or introduced errors on purpose or deleted entries....
 
But the problem for higher ed, and really for every organization where people hear about a wiki or where somebody says for the first time, "Hey, let's use a wiki," well, people immediately think of all the negative [incidents with] Wikipedia. They start thinking, "I don't want a tool where everything I do is seen by the world. I don't want a tool where anybody can come and edit what I've done, or vandalize it."

So the biggest road block is educating people that using a wiki in an organizational context is radically different from Wikipedia.

In Wikipedia, the audience and the potential contributor is theoretically anyone in the world who has an Internet connection. In a wiki that you might use in your classroom or your research group, you know who the audience is. There's a fixed set of contributors or readers or participants. It's the 20 or 30 students in your class....

[Regarding anonymous contributions], in a wiki that you use in an organizational context, everybody should log in. Most of the tools that are available ... require you to log in before you contribute. So your name is associated with your contributions. That's important in an educational context for several reasons:

1. You don't have the risk that because somebody is anonymous, they are going to do something mischievous;
2. You need to know everybody's names so you can give them credit for their work and a grade for the quality of their work; and
3. You open up to building a community, using the strength of the community that you have in your classroom, by using the wiki as a virtual extension of that.  

You typically get two meetings a week with your students; let's say that's 90 minutes total. That's not a lot of time, but if you had a tool that can extend that time and do it in such a way that students feel extremely engaged by what they are doing, you've got an opportunity to work a lot more closely with them and engage them in what you are teaching them.

CT: In terms of tools, can you talk about what's out there and how to choose a wiki product, especially considering the open source wiki products?

Mader: The most well known freeware or open source tool is MediaWiki; that's what powers Wikipedia.

There's a tool called Twiki that is open source. It's what they call an enterprise wiki and has more of the features necessary for use in an organizational context.

A company in Oregon called Jive makes a tool with wiki capabilities called Clearspace.

A company called Wet Paint that makes another.

A company called MindTouch makes a wiki called Deki-Wiki. The code base is open source, and I believe they also sell a commercial version of it, and/or they sell support for their open source version.

There are also some others that are commercial.... Atlassian makes Confluence, which fits squarely in that category of enterprise wikis.

A company called Socialtext makes a wiki in both an open source and commercial version. I believe their business model is similar to Mind Touch. 

CT: How do open source wiki tools differ from commercial ones? Which is a better choice for higher ed?

Mader: That's an important distinction now among wikis. There's a recent post on my blog called "5 Differences between Wikipedia & Enterprise Wikis."

A lot of the open source tools like MediaWiki are designed with a major project in mind. In MediaWiki's case, it is Wikipedia.... an encyclopedia, and a very flat structure. So MediaWiki is designed to support that. When you download and use MediaWiki, sure, it's free, but it comes with the caveat that they are not going to customize it or improve it for your needs. If you want to use it, you have to figure out what to do yourself.

What makes enterprise wikis a lot better suited for internal use in a university or school is that they've got the ability to interface with ... the account system that's already in place in your institution. The wiki becomes just another thing you log in to, the same way you log in to e-mail.

[Enterprise wiki tools] also have the ability to manage multiple wikis from one place. So, in the case of Confluence, you install one instance, and then you can have a space for a Modern History course and a Chemistry 101 course and a space for a Physics course and so forth. In each of those spaces, people can control access. So, if you want to have just the students that are attending a certain class have access to their wiki space, you can set it up that way. It's much easier to do that in a tool that has all the capabilities built in.

CT: Do most schools tend to tie their wikis into their course management system or some other part of their larger systems?

Mader: Generally, the answer is yes....  I get a lot of people from higher ed who initially contact me and say, "We want to integrate our wiki into Blackboard. What do we do?"

Integrating can mean different things. With a wiki in any course management system, the most basic level of integration is having single sign on. So students log in to Blackboard, or any course management system, and if you have links in your course page that go out to wiki pages, those links should seamlessly work, and vice versa--if you are in the wiki and there's a link back to the course management system page, that should work too.  To me, that's the most important kind of integration you can have.  

The other kind of integration that can happen is in a tool like Confluence, when you create a page in the wiki, and people can subscribe to that page by RSS and see when changes are made.
That's useful for a teacher if you've got students out doing a group project and you want to keep an eye on when they're working. You can see when they've made changes....

That's where an RSS feed can be useful. It can also be useful if you have a course page in Blackboard and a lot of content in a wiki. You might want to use something like an RSS feed to bring some of that content into your course site.

CT: How would you recommend an instructor or school get started with wikis?  Is it best to kick off a small project to test out the concept?

Mader: Well, now you've hit on the heart of my consulting.

This is an approach I've been using in every organization I'd worked with for the last several years. It's a phased wiki adoption.  

The best way to get started is to bring the tool in--typically it's going to come in through an IT department--to get it set up and get the initial technical issues out of the way. Then, I go into organizations and run a strategy session where we plan out the time frame for letting the campus know that it's available and advertising the ways that people might think about using it and getting people involved.

From there, the first step is to select a group of people to be the pilot. Often that's done collaboratively with something like the Teaching Excellence or Instructional Technology department because the staff in that department already knows the faculty. They talk to them on a regular basis and know who are going to be either early adopters or interested in trying out a new trend in technology. They can help in getting those people together, several weeks or a couple of months before the wiki is made more broadly available.

Giving them access first gives you a chance to do a few things:

• You can work out the technical issues that arise once you have users in the system. Your pilot group is going to be a lot more forgiving than when it's available to everyone, because those people generally understand that the tradeoff to being first is to help work out the last bugs.
• You get the chance to work very closely with those people and help them be really successful with the tool. They will then spread the buzz about it to their colleagues, and you'll have the success story of what they've done to show people who come to you and express interest in using the wiki.

From then on out, you can begin to make the wiki more widely available. [However], I strongly urge organizations against making it available to everyone at once.  I think it's better to say, "Okay, we're going to do a pilot group, and we'll have, say, 40 people on the pilot. Once we're done with that and we deem it successful, we'll make the wiki available to, say, 100 people."   

Once you have that next phase of people coming in, you have a little bit more stress on the system. Now you have more people and you're going to have more [support] demands as they get started. You want to make sure you can handle that. Then once you're comfortable with the group you brought in, then you bring in an even larger group--say, 500 people.

CT: Just rolling it out to everyone isn't the best approach, then?

Mader: The problem if you do that is that people either rush to use it, and then you have major issues ranging from possible technical performances with the wiki itself, to issues of getting inundated with support calls. Or there's the other side of it, which is a ghost town where nobody expresses interest because they don't know what to with the tool, and they don't want to add something else to their already busy schedule.

You're far better off to spread the growth out over time, versus opening the flood gates and saying everyone can have it.