I’m a wiki novice myself, and yet I’ve had two semesters to get familiar with using a wiki. Have we, in either class, used the wiki as a wiki? Not really. In my first class using a wiki, we created help topics and also used the wiki to post policies for online students. The only thing collaborative was the location of the documents, and the fact that we attempted to make our individual documents look alike, for cohesion on the wiki. The policies for online students ended up being one document that was separated into different parts to be written by each student. We then put the entire thing together as one document and published it on the wiki. Again, the platform was a wiki, but the document could have been published via email, a blog, D2L discussion board or Google Docs. It wasn’t a true wiki collaborative work.
In this class, we have a wiki to apply what we are reading in the two books. So far, my group has managed to create individual profile pages and post comments about presentation on the discussion page. A page for Technical Communication references has been created. Only one member of the team has posted anything so far. It remains to be seen whether anyone else will participate before the end of the class. Another team member posted the syllabus in sections and the time and effort worksheet. As an overall statement, the wiki has been more of individual web pages or documents, than any collaborative work in true wiki fashion. So, like the author, we haven’t “used the wiki as a wiki.” (227)
McCorkle discusses using a wiki for the GlossaTechnologia project, a resource wiki for an electronic version of an annotated bibliography. There are two issues McCorkle identifies in getting a wiki started and making a wiki project successful. These issues are 1) getting people actively involved in the project, and 2) keeping the project going and growing. This reminds me of a project that grew out of a whole class assignment in our Fall 2012 Social Media class.
Like McCorkle, our Social Media class spent a good deal of time identifying the correct platform for our social media project. We weighed a lot of the same factors as McCorkle, such as function, categories, organization and “strategies to maintain site cohesion.” (220) In the end, we determined that LinkedIn was the correct platform for a MSU, Mankato Technical Communication group. It have the right amount of security, while being open enough to invite in those we wanted to participate.
Getting the LinkIn group started was easy. Dr. Perbix created it and sent invitations for us to join. From there, we had great hopes that the group would take off. To date, the group has 68 members. That really is quite good, considering the original intention was to have the group announced at the beginning of each semester, in each class, so students would become aware of its existence. So far, I am unaware of anyone announcing its existence. I can only hope that the momentum that has helped the group grow to 68 members will keep it alive and growing.
This chapter is all about the pros and cons of using a wiki in a classroom. Group projects can be a rewarding experience or a complete nightmare, depending on the assignment and the participants in the group. A wiki only serves to highlight the rewards and downfalls of collaborative projects.
As the author points out, “A class wiki provides an ideal online interface with which to address the fissures and overlaps between creative, collaborative, and theoretical work, while also providing students a space they can access and edit.” (205) This is a great sentiment, as long as the class utilizes the wiki in the way that the wiki is intended to be used. In other words, a wiki is a great environment for equality of authorship and collaboration. It is not a good environment if concerns over ownership, plagiarism and editorial control exist.
Some of the benefits of wikis the author points out are the ability to use a wiki for quick and informal means of editing and collaborating content. In addition, a wiki creates equality of authorship and collaboration. The biggest question the author poses is “whether a wiki truly provides a common, collaborative space.” (206) In my experience in using a wiki in two classes, I have not seen a wiki used as a wiki is truly designed to be used. A wiki, in two semesters of experience, has been no more of a collaborative space than using Google Docs.
Of the downfalls the author identified in his class is the ability to publish misleading information, hurtful words or opinions. In addition, works that are published in a wiki are available for the whole world or community to see. Another concern is that someone can follow along and have the ability to wipe out another’s work. Students are taught from an early age to have ownership of their written material, so it is disconcerting to find out in a wiki no one’s thoughts and entries stay untouched by others. One of the biggest concerns expressed by a student was “if other people plagiarized or changed my content, I would be upset.” (213)
Nelson points out the benefit of wikis is they are “fluid, fast, fixable, and free.” (198) He says there are four points inherent in a wiki. They are: “open-source software/writing, problematizing textual authority, process orientation, and real rhetorical circumstances.” (198) What does this mean?
Wikis are an ongoing process. They are a means of communicating and writing, by sharing pool of knowledge. Wikis are also self-repairing and provide real-world opportunities for rhetoric. One of the key points of wikis is that they are open-source.
Open-source software “refers to a program in which the source code is available to the general public for use and/or modification from its original design free of charge, i.e., open. Open source code is typically created as a collaborative effort in which programmers improve upon the code and share the changes within the community. Open source sprouted in the technological community as a response to proprietary software owned by corporations.” (http://www.webopedia.com/TERM/O/open_source.html) One role of open source software is in “helping public sector organizations become more innovative, more agile, and more cost-effective by building on the collaborative efforts of open source communities.” (Driving innovation with open source,Posted 7 Jun 2013 by Clarice Africa, http://opensource.com/government/13/6/singapore-open-source)
Wikis and open-source software share similar attributes. Is it any wonder they both are embraced enthusiastically by those who seek a more open, free way of communicating and sharing? It is inherent in human nature to rebel against overbearing authority. Wikis and open-source software are means for rebelling against those who seek to control us – large corporations, big government and domineering elitism.
This article draws a sharp contrast between the elitism of academia and the freedom offered to individual voices on the World Wide Web. In addition, Barton shows how wikis help the “citizen band” replace the top-down corporate forces with the “independence and autonomy of communities of people.” As he argues, in academia, “an individual’s prestige may partially be determined by how well he is able to suppress other voices.” (177) By contrast, wikis aren’t dependent upon individual prestige. Wikis embrace other voices, instead of arguing to the point of squelching others’ arguments.
The very concerns that draw academic criticism of wikis is show to be the asset that makes Wikipedia and other such wikis such a success. Vulnerability is their asset. As a comparison, consider Ghandi’s passive resistance against the British Empire. This was the vulnerability of the Indian people being used effectively against a superior military force, the British. By contrast, controlling the vulnerability of the World Wide Web and wikis would result in a confrontational battle against superior forces, such as was seen in the 1982 Falkland War (Argentina’s claim of the Falkland Islands versus Great Britain). Controlling and confrontation doesn’t work against a larger, superior force.
The success of wikis is in the neutrality, driven by formal or informal policies on wikis. This neutrality creates a tolerance and diversity that contributes to a richer, more collaborative environment. A successful wiki overcomes the vulnerabilities through the “force of pride felt by a wiki community.” (185) It is the anonymous citizenry of the wiki, overriding any assaults brought about by exterior forces. That same anonymity and wiki pride create an atmosphere that provides no rewards for those who would seek to deface the wiki. Absent rewards, there are no reasons to actively seek to confront or cause harm to the wiki. It is almost metaphysical. It reminds us of the greater good and ideals man often seeks in an imperfect world.
Similar to the writing process for an individual author, wikis have their own process. “Writing on a wiki proceeds from ThreadMode to DocumentMode by way of Refactoring.” (160) These WikiWords define three separate processes of a wiki that can happen sequentially, and as an ongoing, concurrent process.
ThreadMode is described as a discussion. It generates topics, positions and arguments. ThreadMode is public thinking which is grounded in specifics. The purpose is to allow others to understand and create their own threads. It is not persuasive, nor is it intended to win. ThreadMode is similar to Web discussion boards. If you have participated in the discussion boards in D2L, you have experienced something similar to ThreadMode.
The major difference between ThreadMode and discussion threads is three things: 1) Threads are incorporated in the evolving shared document; they cannot be separated. 2) Threads do not follow a chronology of posting. 3) They tend to be concise and pointed.
DocumentMode correlates to an exposition. In DocumentMode, the threads are drawn together, similar to drafting an essay. Theads are converted from first person to third person, active voice. DocumentMode is unsigned. Ideas become the focus, and the document is written in “transparent style”.
Refactoring is like a document revision. Refactoring takes the ideas present in ThreadMode and creates an organizational pattern of those ideas. We refactor in everyday life by reorganizing a grocery list to map it onto the physical store. It makes it easier for human maintenance.
Ultimately, the reasons for ThreadMode, DocumentMode and Refactoring can be traced to the purpose behind wikis. Wikis are self-correcting. One technique used in the self-correcting process is DoubleLine to separate the DocumentMode OpeningStatement from ThreadMode discussions. The double lines help coauthors and contributors determine the state of knowledge on the page.
When I read this chapter, one quote stood out from all of the text. Lakeman tells us that hypertext has the “potential to reconfigure the activities of its writers, substituting the isolated production of closed documents with dynamic webs of intertextuality.” (144) What he is really saying is that hypertext removes the concept of lone writers, and creates a framework for collaborative writing. He also states that wikis are “relatively unique as a popular model of electronic writing.” (145) I would beg to differ. There are other models of electronic writing that are quite similar to wikis.
In a recent class, horror was expressed by some of the students when discussing the concept of single-sourcing documents and utilizing content management systems (CMS). The main concern revolved around single-sourcing taking away the author’s voice and substituting a technology-driven anonymity. In addition, they felt the result was text with a sterile aspect, voiceless and devoid of any human connection necessary to make it consumer-friendly. How is this different from wikis?
Like wikis, which open information to multiple authors, single-sourcing documentation and CMS employ that same concept, albeit on different platforms. The entire concept behind single-sourcing and CMS is to create text that can be applied in multiple formats, different platforms and for a variety of uses. It removes the lone writer from their position of creating entire documents in isolation. Single-sourcing and CMS store text in smaller chunks to be readily used for various document types. These smaller chunks of text can be created, modified and edited by any number of different writers. Changes and editing either update the source text to a new version, or create a new document chain. Some CMS have commenting feature, much like the discussion aspect of a wiki. Single-sourcing and CMS are especially pertinent for updating in smaller bits, rather than entire documents requiring updating. The updates are immediately applied across all documents that utilize those data chunks.
We are reading about wikis as a collaborative, communal activity that creates a democratic social composition. Many of the same aspects that make wikis a collaborative, communal activity, apply equally to single-sourcing and CMS. The biggest difference is the motivation to create and contribute. Wikis are driven by a democratic notion of shared information. It creates personal satisfaction and the psychic income that comes from freely sharing with others. Single-sourcing and CMS are work-related, and therefore are profit-driven mechanisms. It changes one of the aspects that motivates workers to produce and achieve, that motivation is the tie between showing one’s work and the reward of payment received for that work.