Tuesday, February 13, 2007

Our first class wiki

In early 2006 our team was asked if we wanted to support the college's first course support wiki. An innovative faculty member, David Kyuman Kim, wanted his students to be able to "create their own web site", and showed us what he wanted and was inspired by: Social Justice Movements, a site for a class by Prof. Robin D. G. Kelley at Columbia University. This was a pretty clean-looking site, running on a heavily customized install of MediaWiki.

I admitted to Professor Kim I did not yet have the know-how to get this fancy, and demonstrated our first team wiki. He was satisfied with the appearance. He did ask if we could include a few images, and make it look "like a normal web site" as much as possible. I stressed that students' ability to create and edit content collaboratively was the wiki's strength, and not a great ability to control visual appearance. We had one organizational meeting before the semester started, with Prof. Kim, Diane Creede (an Instructional Technologist), myself, and Ashley Hanson, who was going to provide the Reference Librarian support. The final result of this collaborative effort was the Theorizing Race and Ethnicity Wiki

Lessons I learned in supporting this wiki were:

1. I wish I had, from the beginning, a better understanding of the role of the wiki in the overall course. I only read the portion of the syllabus referencing the wiki itself, and did not study the rest. Our only meeting with Prof. Kim was for an hour before the start of the semester. We scheduled more meetings but something always came up to postpone them. I did contact Prof. Kim and the class by email occasionally, to remind them we were willing to help as much as needed, so they knew we were available. But I would have enjoyed more involvement in the process.

(Solutions: Go to the entire first class to hear about the overall course requirements and get a "feel" for the course. Ask to go to some classes when the wiki is discussed or used. Try harder to schedule meetings with faculty to ensure their needs and expectations are understood and met.)

2. We only had an hour of class time to present, in person, both the wiki instructions (30 min) and the reference librarian instructions (30 min). Students were strongly encouraged to contact us later for further assitance, and I put as much information as possible in the wiki on-line help. However, I only heard from one student once.

I think the students could have benefited from more instruction on how to format text in a wiki (wikitalk). A single 30-minute introductory class is not enough. The large number of students in the course, forty-two, could have made support challenging. However, as they never contacted us, it was not a factor.

(Solutions: Make a requirement, or a strong suggestion, that at least one student from each group or team meet with wiki support staff to go over how to use it, at the beginning of their actual use. Course time is usually tightly scheduled, so this must be done on the student's own time.)

3. It seemed there were long periods when no work was done on the wiki. Then, all of a sudden, it would greatly expand in size. This seemed to happen twice, at mid-term and at the end of the semester, probably when due dates came up.

(Solution: Create a greater number of deadlines or "milestones" when material has to be submitted in the wiki. This, however, is up to the faculty. This can also be addressed in the solution to Observation 5.)

4. At deadline times, text was usually copied-pasted from Microsoft Word. Formatting such as bold, italic, and paragraph spacing is lost when this is done, and you end up with long run-on sentences without any breaks. In many cases, these were not fixed by students. This made the wiki very difficult to read, with a disorganized appearance. I ended up fixing all the problems myself, at the end of the semester.

(Solutions: Encourage writing directly in the wiki instead of copy-pasting from Word. Implement better instruction on how to format text in a wiki. There should be a student 'visual editor' for each group, responsible for appearance, not content. This editor needs to contact staff for assistance with wiki formatting. Staff needs to contact the editors if they see things are not right.)

5. A student contacted me twice, concerned that "everyone" outside the class could see his unfinished work, while he was working on the wiki. In both cases I suggested he contact Prof. Kim directly to express his concerns. I also told the student that the chance of someone stubling into the wiki, one of millions of web sites, is pretty slim. It's possible this aspect of the wiki: always open to readers, though only editable by students, may have been responsible for the large amount of "copy-paste", from finished Word documents, at deadline times.

(Solution: Make the wiki private initially, with a password needed for reading in addition to editing. However, as the goal is to eventually "publish" the results, do this when students feel comfortable, or at the end of the course.)

6. The wiki never did look like a "normal web site", though it has more variety than many wikis. All fomatting to make text more "stylish" was created by staff. It seemed that there was just enough time for students to insert text in the wiki, with no time left to learn to make it more esthetically pleasing. There was a possible misunderstanding with Prof. Kim, he may have expected us to do that. No images have yet been included. In addition, we did not know what types of images to look for.

(Solution: determine whose responsibility it is to make the wiki attractive. If it is the students', then allow for adequate training, support, and time. If our job, ensure we ask for enough guidance regarding text style and image selection. Better communication between our staff and faculty is needed in this area. After the course is completed, ask faculty if anything can be done to enhance its appearance. Obviously, content should be left alone. Insure faculty understand that it is technically difficult to make a wiki appear like a "normal" web site.)

7. I thought that Prof. Kim was satisfied with the work we and the students did, but things were so rushed at the end of the semester that I did not ask for more detailed feedback on the overall process.

(Solution: Request a meeting with faculty at the end of the project to go over, in more detail, their likes and dislikes, and their own "lessons learned")

As the instructional technologist that was in charge of primary support, I hold myself responsible for any problems that could have been resolved by better involvement or judgement. I think and hope I have learned my lessons. All in all, though, I think it turned out to be a nice wiki.

In a future post I'll describe how we are handling our second wiki at Conn. Thanks to Ward Cunningham for inventing the wiki. He prototyped it on HyperCard, and then ported it to the web in 1995. Ward named it after the Hawaiian word for fast or quick, and was inspired by the Honolulu Airport shuttle bus that runs between the airport's terminals. The fact that the wiki was invented over 10 years ago shows how some collaborative, participatory technologies that are now sometimes considered "Web 2.0" have been around for a long time, since "Web 1.0"

That first wiki, WikiWikiWeb, is still running!
To the left is its logo.

Wikis at Conn, Beginnings

In the fall of 2005 I thought it was time to get familiar with wiki technology for the purpose of course support. After evaluating a dozen hosted and locally installed solutions, I decided to go with MediaWiki for our first wikis. The reasons for this were, in no specific ranking:

1. A local install gave us more customization possibilites and software control. For some nice MediaWiki customizations, look at Beagle and Mozilla Developer Central. I wanted the potential to get away from the stock wiki look.
2. The college already had a student-managed wiki on another server, Connwiki, running on MediaWiki.
3. There is a very large user base in Wikipedia, which runs on MediaWiki.
4. There is a large base of developers and tweakers, with lots of helpful support information on-line. Many other sites run on MediaWiki.
5. MediaWiki is open-source, free, and non-proprietary.
6. Although relatively complex compared to some of the other wikis, I thought I would be competent enough to administer it after installation, with enough sources of help online if I needed assistance. There are also tech support staff here familiar with the technologies involved: HTML, CSS, PHP and MySQL.
7. If the on-line help and local help was not enough to get me out of trouble, the underlying technologies were popular enough that it would not be hard to find and hire an expert to fix things.
8. I wanted some "under the hood" experience, for my own personal development.

I spent my Christmas vacation in December 2005 learning how to install and configure MediaWiki. I first reformatted my PowerBook hard drive into 2 partitions, put OSX and all my stuff on one, and installed OSX Server on the other. I could boot into either partition, and used the server side for wiki development. I imaged the server side with NetRestore after a basic system configuration, but before installing any software, so I could easily restore it to its pristine state if I messed up. I did end up having to restore and start fresh a few times, due not only to MediaWiki. I was also learning how to customize Apple's Weblog Server for a podcast server in the same partition. So, the restoration option came in real handy.

It took about 40 hours to teach myself how to install MediaWiki and customize it to the state I needed. I had little background in HTML, CSS, PHP, and MySQL, though I had some programming experience in Director's Lingo, which no-one seems to use much any more. I learned just enough of the technologies that MediaWiki runs on for the job at hand. I have to admit my experience was usually more of a "cookbook" approach than true understanding. Thankfully, there are enough "recipes" around, though spread out a bit.

My biggest concern, on top of having the wiki run reliably, was security. I did not want a hacker getting in and messing up our site. This concern proved to be justified, as looking at the web logs later I determined an average of two hacking intrusion attempts a day, for a considerable amount of time.

After a few successful installs on my PowerBook, I felt confident enough to install the production version on an older but reliable Mac G4 running OSX Server 10.4, and started our first wiki, for our Instructional Technology Team. The computer is automatically backed up every night, with a complete image of the hard drive created weekly. Our wikis are still running on this G4, but will be migrated to a new XServe this spring.