My collaborative partner and I had worked together before in putting together our alternative certification portfolios, and as a group in the InTech class. I knew we could work well together despite the extreme differences in our disciplines. He teaches French in the World Languages department, I teach science. This AP European history class was something he really worked hard in obtaining at our school, and he had to convince both the social studies department chair and administration that he would be the best instructor for this course. I knew that he was motivated in setting up the course and that he needed new instructional activities for the course.
In interviewing him before the lesson, he stressed the importance of the DBQ’s and how his students had really struggled with them. For one thing, reading a series of documents and writing an essay are not considered to be very fun for most students. We felt that adding a collaborative technology based component to the DBQ would make the kids more interested in completing them and would improve their quality. Providing this collaboration, along with peer feedback could also serve as scaffolding activities, where elements could be removed in the future. DBQ’s are an essential component of the AP exam; improving student’s scores is a motivator for all stakeholders: the students, the teacher, and the school as a whole.
I researched various wiki server software programs using web-based resources. I had leaned towards MediaWiki in the beginning because it powers Wikipedia, with which most of the students were familiar. Because of its ease of use and installation, and because it did not require a database, I chose PMWiki instead. Having a wiki that used flat files instead of databases issue was important because I would not have to learn database administration on top of wiki administration. Flat files are simply indexed text files that can be easily managed. Downloading and installing the wiki was very easy. Customizing the wiki took some expertise that I did not have. I was able to contact a knowledgeable user of PMWiki who had generated a feedback forum for his site. This was an essential element that was not included in the basic installed portion of PMWiki. We communicated through e-mail, and he instructed me how to change my code to add the feedback forum. The skin he suggested also came with drop down menus, which were an added benefit. I used those for site navigation as well as contact information for the teacher and myself.
I trained the teacher over winter break. It lasted about three hours, including lunch. When he left there were some password technical issues to resolve. I had those solved by that night and communicated to him through phone and Internet. I was very happy to see that by the end of the week he had learned how to upload files and change text colors. He had completed the four sets of documents and we were ready for the students. Towards the end of the week he did notice a glitch in his screen layout that did not occur on mine. Long text would run off the left side of his screen, so he could only see the right-most portion of any text. It was not happening to me and we determined it was browser incompatibility with Internet Explorer. I temporarily fixed the site using hard returns in FireFox, but I had to fix the site to be browser compatible. A quick search through the PMWiki help documents led me to a small bit of code that forced all text to wrap after 72 characters. That did the trick.
The students were placed in the computer lab soon after break, and disaster struck almost immediately. As soon as the students logged in, most were logged off when they tried to save changes. I was at a loss, and found no references on the web site. I e-mailed the mailing list and received several responses, including one from the original author. They provided suggestions for sharing the session and increasing the length of timeouts. The software apparently had not been tested on a computer lab setting with multiple users, and the configuration of our computers was causing the issue. The entire lab shared one IP address, and thus it also shared the session. This was something out of my control, I could never completely solve the problem but I was able to mitigate its effects, and provide a work-around for the students.
The second day of training, after I had put in place the suggestions, went very well. There were still some early logouts, but only one out of eleven (one absence) experienced these instead of nearly everyone. The students created a wiki page about themselves to motivate them to learn how to use the wiki. Training the students only required about thirty minutes. We let the students work on their profiles for twenty minutes more and then introduced them to the DBQ’s.
Three out of the four groups completed the wiki within the time frame set by the teacher. The fourth group finished soon after but did not indicate if the problems were technical in nature, due to working as a group, or any other reasons. Students indicated that ten of the twelve students had successfully performed their duties as part of the collaborative effort. One student had excessive absences and had missed the day of training. The other student is also failing the class and not participating well in other class activities; the instructor claims she has “senioritis”.
The students had some frustrations early on but most were able to do all of the required activities: post a portion of their project and provide feedback. Only the two previously mentioned students did neither. Rather than provide feedback through the wiki as we had originally planned, the teacher gave written and oral feedback in class. He assumed that once the project was over most students would not go back to the wiki to check for feedback and that they would prefer their feedback be more private.
The survey I administered to the students after the project evaluated their prior knowledge and present abilities as well as their feelings towards the project. I left evaluating the actual effectiveness up to the instructor and concentrated more on motivation with the students. Students were mainly familiar with wikis in the context of Wikipedia. Many thought the purpose of a wiki was to create encyclopedic-like content, and this project was definitively not about creating those sorts of articles. Surprisingly, the vote on the collaborative aspect was split. Many of these students preferred working in groups, others preferred working alone. The majority (90%) preferred doing a wiki based DBQ than a traditional DBQ. Despite the survey being anonymous, the one student who voted against wikis was particularly vocal, and had not been a fan of technology when she was in my biology class last year. This shows that even in our student body there are resisters, and one should be cautious in assuming that every member of the future generations is a digital native.
Given the survey data, I felt that this activity would be good to repeat next year as the first DBQ if it went well on the instructional side. Not only did the teacher agree to use it again next semester, but he said the kids are begging him to do another wiki DBQ this semester! He felt that since it was easy to set up and do, he will do another one soon. The change will be that each student will copy the DBQ into a new wiki page and work alone. This is removing one of the supports that had been part of the scaffold. He wants a way to control the time that a student can access a wiki. Another disadvantage is that if a student works outside of the teacher’s supervision there is no guarantee that textbooks and other resources are not used. He felt that using the rubric to grade the students work right from the web was very easy; he printed out the rubrics to grade the projects, but did not need to print out the students’ responses.
For this project, grades were higher this time than the last time he did DBQ’s. However, in his first DBQ, students worked alone and on paper, with no peer feedback. He will attempt to use this wiki framework as a scaffold in the future by dropping some of the supports during future wiki based DBQ’s: peer feedback, collaboration, time constraints, and the overall interactive and formative nature of the activity. He really feels the project went very well, and I could see that not only did his students grow, but he also increased his professional knowledge and even his LOTI level. From the perspectives of the three groups of stakeholders (wiki administration, wiki instruction, student motivation/learning) this project has clearly allowed each of us to grow and is worthy of being expanded into other projects. I myself am planning on converting my static classroom web page to a more dynamic wiki that my students can add resources that they discover.