SYNOPSIS: The author describes history and real teaching experience of using wiki software in course team projects, showing pros and cons of group work and mistakes which can be easily avoided. All the steps of such projects are described in detail together with tips of how to avoid most common mistakes. Examples serve as a good proof for a validity of using wiki as valuable tools in the teaching process.

Wikis have become popular tools for educators in this Web 2.0 era (O'Reilly, 2005), where students are not only readers of Internet content but also producers (Driscoll, 2007). The word “wiki” comes from the Hawaiian term “wiki-wiki” which can be translated as “to hurry.” Ward Cunningham is credited with developing the first wiki software application, naming it such because the tool could be used to quickly create collaborative websites. Teachers now use wikis to build do-it-yourself (DIY) websites. Using a wiki allows them to quickly create an entire website without knowing an Internet coding script, such as HTML. Another popular use for wikis is to have students collaborate on building content as part of a class project (Hazari & North, 2009). This use will be the focus of this paper.

When used correctly, wikis become powerful tools for supporting collaborative learning. Students can engage in inquiry-based activities, working with peers to construct knowledge. However, from an instructional perspective, learning how to structure an activity where students work together in a wiki environment can be challenging. It is analogous to navigating a maze where the correct path is found only after several unsuccessful attempts. In this paper, I will share my experiences using wiki-based collaborative activities in graduate education courses at a private American university. I will do this by sharing ten tips to correct mistakes I have made, i.e., wrong paths I have taken, followed by corrections I made, i.e., paths I took to successfully navigate the wiki maze.

1. Choosing the appropriate tool

There are a wide variety of wiki authoring tools available (Clallborn & Reimann, 2005) and assistance with determining selection criteria (Schwartz, Clark, Cossarin, & Rudolph, 2004). The initial decision I needed to make was determining whether to use a freely available wiki tool or chose a tool that would that would be integrated within the institution’s Learning Management System (LMS), Blackboard. At the time, January of 2005, it was uncommon for students to have logins for multiple Web 2.0 sites. Instead, it was important to consider a solution where students would not have to log in to a website other than the LMS. For that reason, it was determined that it would be best to use a tool that worked within the LMS to simplify access and use.

The tool initially chosen was the LearningObjects Teams LX tool, which can be integrated within the Blackboard LMS. Like all good wiki tools, Teams LX keeps track of individual participation statistics, which can help hold team members accountable for their individual work on group projects. Each page in a wiki can be "played back" to view contributions in order of occurrence. The wiki editing features in Teams LX are not as robust as external wiki authoring tools because of limited formatting options and the lack of a built-in threaded discussion tool. However, the features are sufficient to meet basic collaboration needs of student knowledge construction in a small group project.

While Teams LX has been used successfully in many collaborative projects over the past four years, there are several reasons why I currently consider it to be “the wrong path” for my use. First, learning doesn’t end when the course is over. Students are often excited about the work they did in building the wiki and frequently ask if they can continue to work on the wiki after the term is over. At minimum, they want continued access to their wiki as an artifact for their electronic portfolios. This is impossible to do when the wiki is integrated within an LMS that automatically starts and ends student access to an online course based on an academic calendar. Second, after working on a collaborative project in a wiki environment, Teacher Education students may ask if they can use this same technology with their students. While technically possible, the cost of the software makes it prohibitive for most K-12 schools. Therefore, switching, i.e., finding the correct path to a freely available wiki tool called Wetpaint (http://wetpaint.com/education) allows the wiki to “live” outside of a course. This makes it possible for students to continue to have access to the wiki even after the course has ended. Also, because Wetpaint is free, Teacher Education students can use it with their own students.

2. Choosing an appropriate project

My first attempt at using a wiki with students was in an educational technology course where one of the objectives was “to gain a deep understanding of computer networking nomenclature in order to better understand how to design a networked-learning environment.” The course syllabus had already been set when the Teams LX wiki tool became available in the LMS. Because of this, I decided to experiment with the wiki tool in my course by giving extra credit to anyone who would participate in a wiki assignment I added to the course, rather than adding another assessed assignment. The only model I had for a wiki was Wikipedia; therefore, I decided to create an assignment where all students in the class would help build an encyclopedia of networking terms. This decision quickly led to a “dead end” in the wiki maze as only two of twenty students made updates to the wiki during the term. The experience reminded me that it is important for students to see value in coursework they are asked to complete. I was also reminded that students typically only value course activities that are used to determine the final grade in the course.

Basing wiki project on relevant real-world experiences has worked well in other course projects. A wiki project I designed for a Foundations of Education course is an example of a collaborative wiki project that students have found to be meaningful. Here is a brief introduction to the project:

You have been asked by an administrator to work with others to create a presentation explaining foundational beliefs about education for a new teacher orientation in your school system. Foundational is the operative word here. The goal of the presentation is to help new educators think critically about important issues related to teaching and learning before their first day with students. In this regard, you should rely heavily on the reading and lectures of the course. Your presentation is more than a “how to survive” for beginning teachers. It is intended to give them a sense of the history and philosophy that has guided this noble profession.

Your institution would like your collaborative work to be published in a wiki so that others will be able to add to it in the future. A wiki is a type of website where multiple people can quickly add or edit content on any page of the site. You will learn more about working in a wiki community as you collaborate on this project. Your project will be organized to answer the following questions:

Why teach?

What are qualities of a good teacher?

What do students really need?

What does a good classroom look and feel like?

What is truly meaningful in student learning?

How does a classroom become a place of reflective practice?

(Wicks & Ellis, 2006)

This “wrong turn” of adding a last-minute assignment also reminded me that collaborative learning activities need to be carefully planned with appropriate weight given in grading the assignment. One way to assure proper planning is to develop a collaboration script that students follow as they work through a project (Kobbe, L., et al., 2007).

3. Incorporating a collaboration script

Working collaborative online is counterintuitive for many students. They need guidance on how to form teams, develop goals, and make a plan to complete a project. In face-to-face courses, instructors will often describe the end product and then leave it up to each group of students to figure out how they should work together. In an online course, this may lead to a “dead end” as many students may wait until the end of the term to begin their project, not realizing that asynchronous communication will make it difficult to complete the project in a timely manner. An instructor who provides little or no direction may end up with a frustrating class project as many students won’t know how to plan their work in an asynchronous environment.

In many of courses, the students’ contract is only with the instructor, not with other learners. These students are like many who have been taught primarily with knowledge-centered instruction (Ellis, 2004). They expect the instructor to be the source of all course knowledge. They may struggle to understand how they can learn from other novices in a group project. A collaborative script can be used to provide prompts that help students learn from others as they follow the step-by-step directions for the project (Kobbe, L., et al., 2007). The script describes a real-world project that a team would complete during the course. The script includes deadlines for the project and guidelines for completing it.

4. Forming teams

Student teams can be randomly assigned or created based on heterogeneous or homogeneous requirements of the project. The “wrong turn” that I have taken here is to ask online students to form their own teams. Most LMS applications lack an easy way of actually knowing who is in the course and what their interests are. In other words, it may take extensive time for students to asynchronously communicate with others and determine teams. This organization time would probably need to be subtracted from the overall time allotted to the project.

5. Providing training

Initially, technology training was not provided to students. They had to figure out for themselves what a wiki is and how to use it for collaborative learning. This was a “wrong turn” because it typically meant that some team members were unnecessarily left behind at the beginning of the group work because they were still trying to figure out what needed to be done and how to do it. The “correct turn” is to assume students need help and provide them with clear instructions on what a wiki is and how one can be used for collaborative learning. Doing this will help to put all students on equal footing at the beginning of the project.

6. Including multiple deadlines

The collaborative script should be divided into multiple phases that are based on major milestones within the project. In other words, if the goal of the project was to create a group presentation on a team-selected instructional strategy, there could be a phase for picking the strategy, another for gathering content, and still another for developing the presentation. The “wrong turn” here would be having a single deadline for all project work. A single deadline will almost always guarantee that some teams will fail to complete the project, or that one person will end up doing all the work. Using phases provides instructors with multiple checkpoints where they can examine the status of the project. Teams or individuals who are less than successful during an early phase have an opportunity to improve the quality of their work in future phases after receiving feedback from the instructor.

7. Organizing the project

Dividing the project up into phases may not be enough to get a group project off to a good start. A “wrong turn” in the wiki maze would be to have the first phase and all other phases focused on generating content for the project. Students in the small group may not know each other. Their work together is primarily asynchronous. They may not know when team members are available, in cases where quick decisions have to be made. Students probably haven’t thought about roles. In other words, the first phase of the project needs to focus on team organization. I found the “correct path” in my course when I began having team members work together to complete a team charter (Palloff & Pratt, 2005) where they agree on such things as a team name and code of conduct:

While group members will be sharing drafting and posting responsibilities, the following specific roles have been agreed upon: (Student 1) will serve as organizer and secretary; (Student 2) will serve as instructor liaison and motivator; (Student 3) will serve as researcher and technology assistant.

Our team has agreed to discuss and collaborate keeping the following five operating guidelines in mind: 1) We will complete all phases on time, 2) We will communicate with our partners in a timely fashion, 3) We will commit to full and equal participation and effort, 4) We will respect each other's opinions and ideas in the development of each product, 5) We will approach suggestions in a positive and professional manner.

Each team is given a separate folder in the Assignments area of the LMS, which includes a wiki, a discussion forum, and a chat area. While the first phase is used to organize the project, all of the remaining phases are used to walk teams through the process of designing and completing their projects. Here is an example of phases from the Foundations of Education wiki project that was described earlier (Wicks & Ellis, 2006):

Phase 1: Teams plan how they will work together by writing the Team Charter.
Phase 2: Teams collaborate on a five-paragraph essay that answers the questions: Why teach? What are qualities of a good teacher?
Phase 3: Teams collaborate on a five-paragraph essay that answers the questions: What do students really need? What does a good classroom look and feel like?
Phase 4: Teams collaborate on a five-paragraph essay that answers the questions: What is truly meaningful in student learning? How does a classroom become a place of reflective practice?
Phase 5: Teams use the three essays they wrote to create a twenty-minute presentation that will be given to new teachers during an inservice prior to the start of the school year. They will write a team reflection evaluating how well they followed the Team Charter created in Phase 1.

8. Requiring both individual and group work

When used as part of a small group project, a wiki provides students with an egalitarian environment where each team member can have an equal voice (Hazari & North, 2009). A “wrong turn” I made was to give students the option of making individual posts in the team’s work area prior to beginning group collaboration. Some students willingly forfeit their opportunity to provide input if there is not a requirement stating that all team members need to begin each phase by sharing individual ideas. Without this requirement, students may choose a team role that does not include writing, such as managing the technical aspects of the wiki. In my courses, I now follow the “correct path” in the wiki maze by requiring students to post their own thoughts on each phase of the team's wiki prior to the team’s work on a collaborative response. Hopefully, this guarantees that all students have a voice. It should make it less likely that one person will do all the work since it will be easy to review other students’ ideas prior to writing a group answer. I also encourage teams to rotate roles after each phase.

The remaining phases will focus on creating a real-world product with a couple of exceptions. Typically, one of the phases will ask team members to review the work of another team and provide that team with feedback. Each team will then use the feedback to reflect on how they could improve their project. Making actual changes will depend on the amount of work that needs to be done and the amount of time remaining in the course.

As part of the final phase, I ask students to reflect on their own contributions to the project. I also ask the team to write a collaborative reflection on how well they did in staying true to their charter. This reflection is an important component of the group project as demonstrated by this team’s reflection:

Our team charter from Phase 1 prepared us for how the whole project would be organized and designed throughout the quarter. Each of us knew what the group expectations were as well as the fact that we would all need to contribute equally throughout the project. We had organized who would play what role for each phase but as the project unfolded, it seemed unnecessary as everyone jumped in to complete each part from the beginning. Creating the team charter also helped us develop timelines that we would try to have certain elements of each phase completed by. Setting these deadlines help us to stay on top of each phase and complete quality work in a timely manner. The key part of our phase was the last question that included our operating guidelines. These kept us going and reminded us of the commitment we had made to make our project a quality piece of work!

The process used to complete this project seemed complicated in the beginning stages. We spent some time figuring out the best way to post our initial thoughts and then collaboratively come up with the group outline. Our essays for each phase had to be composed of many different thoughts and ideas. We used the discussion board and the comments section at the end of each wiki page as a collaboration tool. As the project progressed through each phase we became more adept at using the variety of collaboration tools provided to keep each other informed and to create a final group project for each phase.

The team charter was a fantastic assignment to begin this project. As we complete this group project we do not feel that there would be any necessary changes to our original team charter. All group members carried out their roles for each phase and contributed equally to the completion of each final product for each individual phase.

As we look back on the overall process of this group project there are not many changes that we would make. The most significant challenge for our group was to create deadlines that worked for everyone's busy schedules, while still allowing for enough time to create a final product that reflected each group member's thoughts and ideas. There was not a single time that a portion of our projects was not completed because each group member always fulfilled their roles. In future group projects we would all hope that we would be fortunate enough to work with other people who were as dedicated to contributing equally to each portion of the project and creating such high quality work as each team member of this group was.

9. Individual reflection after each phase

A “wrong turn” I took in the wiki maze early on was relying on the statistics provided by the wiki software to determine whether students were doing appropriate work on a project. These statistics can be misleading. For example, a student who clicks on the Save button frequently will appear to have done more work than another student who contributes more content but clicks the Save button fewer times. Providing students with opportunities to privately share how the project is going can be a “correct turn” in the wiki maze that may help identify pages that the instructor should investigate beyond the numbers. An instructor can “play back” the creation of a wiki page and examine the actual contributions of each student. A student who made major contributions to the content may have similar quantitative statistics as a student who only made minor improvements but saved frequently. The instructor can use these qualitative findings to encourage a student to make more substantive contributions to the project. It would be extremely time consuming to find possible issues like this without help from student reflections.

Giving students multiple opportunities to reflect on their own work, as well as the work of others in the project, may help identify team issues that need to be dealt with early in the project (Riel and Harasim, 1994). I do this by asking students to write a private blog post, i.e., one that can only be seen by the student writing it and the instructor, after each phase of the project. The students respond to a prompt asking them to post answers to questions about how the project is going, report on any technological issues, and reflect on the quality of individual work and the quality of other team members’ work . This time of reflection helps students focus on what they committed to doing when the project started. Because this blog post is completed after each phase, students have an opportunity to improve. This assignment can be valuable for the instructor because it can provide advanced warning of any team members who are slacking. These students can be contacted. Corrections to inappropriate behavior can be made early in the project, allowing students to recover and be successful rather than receive a low score for the entire project.

10. Assessing student work

Assessing student work in wiki projects can be challenging because students are asked to produce work that is part of a collective, rather than work that is easily distinguished as their own (Wheeler, S., Yeomans, P, & Wheeler, D., 2008). Positive interdependence is an important aspect of group work (Johnson & Johnson, 1992). Students should feel that they are an important part of the team, as well as feel they are needed for the team to have a successful project. In an effort to increase positive interdependence, I have two assessments for each phase. The first assessment is a group grade that is based on the quality of the team's work. I assess this by looking at whether teams successfully completed the tasks assigned to them during the just-completed phase. All students receive the same grade regardless of whether it is obvious that one person didn’t do his or her work. The second assessment is peer-assigned grade, where I ask students to rate each other’s work on the just-completed phase. They are also asked to make a short comment about the work of the person they are reviewing. This is all done anonymously in the LMS. The student being assessed only sees an average score. A student may think he or she is a strong contributor to the team, only to find out that teammates did not agree. Because this is done after each phase, students have an opportunity to change their ways.

Discussion
Prior to using wikis for small group collaboration in online courses, I had come to the conclusion that small group work wasn’t possible in an online environment. Since implementing wikis and correcting a number of “wrong turns” in the wiki maze, my experience with online collaborative projects has been mostly positive. Out of the 50-plus teams I have had in small group wikis, only one team complained about it being an overall negative experience. This group was in trouble from the beginning as they were never able to satisfactorily complete the Team Charter, thus they never reached an agreement on how they would work together.

Students appreciate the accountability features of wikis. They like the "play back" feature that allows them to see what contributions each member has made to the project. They like to look at the history page and see how many words each team member has contributed (Hazari & North, 2009). Features like these expose social loafers, making it difficult for them to tell others that work is being done when the statistics say otherwise (Piezon & Ferree, 2008).

Graduate students are frequently asked to work in asynchronous discussion environments. They are comfortable interacting with chronological comments. A wiki environment can challenge them to extend or counter others by editing rather than replying, organizing thoughts by content rather than chronology. The explosion of tools like Wikipedia forces educators to examine the reliability of its content. Having students work in a wiki environment allows them to see both the value and shortcomings. Future educators need to be informed consumers of available resources. Whenever technology can be appropriately integrated into a learning activity we get the benefit of double loop learning (Palloff & Pratt, 1999). Students can gain knowledge about the content of a course while improving their technology skills.

Group projects that utilize wikis will have their technical challenges but students seem to work together and teach each other how to overcome problems they face within the wiki environment. I encourage students to author their initial contributions in Microsoft Word, and then cut and paste into the wiki. Students aren't as comfortable composing in the wiki environment that is okay because there are more possible points of failure when composing with a networked tool.
Instructors are excited about using wikis for group projects in both face-to-face and online courses. They like how a wiki helps organize student work. Most instructor questions revolve around pedagogical issues like appropriate group size and how to choose an engaging project topic.

Conclusion

Students generally say they don't enjoy group work because they don’t want their grade to depend on the work of another individual or because one group member ends up dominating the project and doesn’t let anyone contribute. A wiki environment can democratize group work by giving all students equal access to team documents (Hazari & North, 2009). Students can be engaged in inquiry-based learning using a tool that includes statistics to hold all team members accountable for their individual work. However, student success in online collaborative projects is dependent on an instructor’s implementation of the project. An instructor who can successfully navigate around the challenges of the wiki maze will be able to provide a successful online collaborative learning experience for their students.

References

Clallborn, C., & Reimann, T. (2005). Technical Evaluation Report 47. Wiki products: A comparison. The International Review of Research in Open and Distance Learning, 6(2).
Driscoll, K. (2007), "Collaboration In Today's Classroom: New Web Tools Change The Game." Multimedia & Internet @ Schools, Vol. 14, No. 3, pp. 9-12.
Ellis, A. (2004). Exemplars of curriculum theory. Larchmont, NY: Eye on Education.
Hazari, S., & North, A. (2009). Investigating Pedagogical Value of Wiki Technology. Journal of
Information Systems Education, 20(2), p. 187-98.
Johnson, D. W., & Johnson, R. T. (1992). Positive interdependence: Key to effective cooperation. In R. Hertz-Lazarowitz & N. Miller (Eds.), Interaction in cooperative groups: The theoretical anatomy of group learning (pp. 174-199). New York, NY: Cambridge University Press.
Kobbe, L., Weinberger, A., Dillenbourg, P., Harrer, A., Hamalainen, R., Hakkinen, P., Fischer, F. (2007) Specifying computer-supported collaboration scripts. Computer-Supported Collaborative Learning, Vol. 2, pp. 211-224.
O'Reilly, T. (2005), "What is Web 2.0?" Retrieved August 15, 2009 from http://oreilly.com/web2/archive/what-is-web-20.html
Palloff, R. M., & Pratt, K. (1999). Building learning communities in cyberspace: Effective strategies for the online classroom. San Francisco: Jossey-Bass.
Palloff, R. M., & Pratt, K. (2005). Collaborating online: Learning together in community. San Francisco: Jossey-Bass.
Piezon, S., & Ferree, W. (2008) Perceptions of Social Loafing in Online Learning Groups: A study of Public University and U.S. Naval War College students. The International Review of Research in Open and Distance Learning [Online] 9:2. Available: http://www.irrodl.org/index.php/irrodl/article/view/484/1034
Riel, M., & Harasim, L. (1994), Research Perspectives on Network Learning. Machine-Mediated Learning, Vol. 4, No. 2-3, pp. 91-113.
Schwartz, L., Clark, S., Cossarin, M., & Rudolph, J. (2004). Technical Evaluation Report 27. Educational wikis: Features and selection criteria. The International Review of Research in Open and Distance Learning, 5(1).
Wicks, D., & Ellis, A. (2006) Foundational Beliefs about Education Group Project Collaboration Script, Handout in Foundations of Education course.
Wheeler, S., Yeomans, P., & Wheeler, D. (2008) The good, the bad and the wiki: Evaluating student-generated content for collaborative learning. British Journal of Educational Technology, Vol. 39, No. 6, pp. 987-995.