Based on our experience with our first wiki, we feel our second was more successful. Some of the things we did differently:
1. Myself, Diane Creede, another instructional technologist, and Ashley Hanson, who provided research support for the class, attended the entire first class. This gave us a good overview of the course syllabus, goals, and expectations, in addition to understanding better how the wiki was integrated into the course. I demonstrated how the wiki and wikitalk worked for about 25 minutes, but also stressed that students were to see me for additional instruction before starting their wiki pages.
2. The faculty member assigned the wiki production 20% of the total grade. This provided incentive for the students to create a nice wiki. it was obvious to me that the students were motivated to do a good job.
3. There were about 20 students in the course. These were paired, and each pair was responsible for creating a wiki page or pages on their topic, which was selected from a list. Each pair of students came to see me for a private lesson to go over how to create and edit a wiki page, including the use of images. This was done BEFORE they did any significant work in their wiki pages. As projects' due dates were spaced at least a week apart, this made support easier, as I only had to meet with one pair of students every week. The individual lessons took about an hour.
Assuming all 20 students had to start and finish the wiki at the same time, a different approach might have been required. I feel this second lesson is indispensable, the first half-hour introduction the first day of class is not enough.
4. The wiki was private until almost complete, and only students, their faculty and our 3 staff could view it. Thus, students were not concerned about others seeing their unfinished and rough work. The class as a whole decided when to make the wiki public. I encouraged students to start writing right away in the wiki, and not copy-paste from Word documents.
5. I encouraged students to first create main sections, using the wikitalk == characters. The sections acted as an outline of top-level topics, that could then be filled in a non-linear manner, or by a different student. Each section has its own Edit button on the side, making the process easier.
6. I would look at the wiki every 10 days or so, and if I saw something that could obviously be made to look better, or could be coded better, I would email the students with suggestions on how to do it, without making the changes myself. The main problem encountered was in using images in MediaWiki: the formatting around the text for a second image can be skewed unless break code is inserted between text blocks. This was occasionally forgotten.
7. I told students it was OK to look at each other's code, copy/paste chunks of it in their own wiki page if they liked the formatting and did not know how to code it themselves, and then customize it to their own content and appearance. I see the wiki as a collaborative effort so I feel this is justified. The main goal of the wiki was not to learn how to code.
Credit for the wiki goes to Prof. Joseph Schroeder, who had the idea for using a wiki in his course, and to the students that did such a great job. I think that just a little extra effort on our own part paid off in big improvements.
Here is a link to the Neurobiology of Disease Wiki. Prof. Schroeder even created the professional-looking wiki logo shown above.
I learned about areas where MediaWiki software could use improvements for these types of projects:
1. Administration. It would be nice to have a GUI from which one could perform user administration (add/delete/password change), and granular page permissions (read/write/protect). The latter seems impossible unless one gets into the PHP config files.
2. Esthetic control. Students want more control over the wiki appearance. For font style and color, this now means getting into htlm code. It would be nice to have an easier way to do it. Students wanted more control over image placement, and background color, this is impossible with wikitalk.
I'm not sure how well MediaWiki would scale as "campus wide" wiki software without better administrative functionality, but it is certainly a good tool for a handful of individual projects. At this time I think we could administer about 30 individual wikis. Beyond that, one would need a full-time MediaWiki administrator.
We are looking forward to supporting our third class wiki, and I can't think of much we would do differently. One improvement will be to centralize our "Help" section. We now have 7 wikis, each with its own Help section! As we find better ways of organizing this information, it becomes impossible to update each one. In addition, when you click on Help in the sidebar, you navigate OUT of the page you need help in. It makes more sense to use the Help in our Instructional Technology Group Wiki, keeping it in the background as a separate web page for reference.