aw1l 3.1 Results

Results

Lecturers

The opinion from the teaching staff about the advantages and disadvantages of the Wiki methodology compared to the traditional is summarised in Table 2.

Permission denied

In first cycle students (for example, “Functional Ecology”-ECOFUN, “Health and Environment”-SIMA), we have detected that:

• They have difficulties to organize themselves in work groups.
• They have difficulties to synthesize the information, since it is easier for them including information from digital sources than adapting it to their context and synthesizing the sometimes too long texts.
• First cycle students learn quicker and accept better the new methodology than those of the second cycle, even if this varies among degrees.

On the contrary, in second cycle students (for example, “Evaluation of Environmental Impact”-AIA, “Applied Ecology-UB”-EAUB, “Applied Vegetable Physiology”-FVA), we have detected that:

• In general, they can organize themselves much better than first cycle students and they have previous experience in working in teams (distributing work, assuming roles inside the team and taking profit more efficiently of the effort and time invested).
• Many of the teams have not been of new formation but the members already knew each other and had collaborated or are collaborating in other assignments or subjects of the degree
• They are people with resources that tend to know already how to 'move' themselves at university and use the available resources quite efficiently
• Depending on the details of size and type of assignment for work groups, the Wiki methodology has been little or very accepted:
  • In some cases, the grade of acceptance of the Wiki methodology has been very low (subject FVA) partly attributable to the fact that they are in their last year of the degree (their priority is to finish, they take many subjects in some cases, and they don't have time to learn novel methodologies, especially if they have other tools that they manage well enough, even if they lack some of the needed features for group work that Wiki technology includes)
  • In other cases of subjects in last course, they found positive and negative aspects (subject “Applied Ecology, Environmental Sciences, UAB” - EAUAB). In the positive part resides the facility of distance interaction among them and the fact that, at all times, there is only one “good” copy of the document. It is also positive the fact that the students manage to learn the new technology with little training and information (expressly) given by their lecturer, since their handling of the Web technologies seemed enough for this type of applications. In the negative part resides the fact that they were not too used the Web environment of work, and that the final format for the document was not Web format but paper format.
  • Nevertheless, in the case of “Evaluation of Environmental Impact”-AIA, of third course, the students have accepted very well the new Wiki methodology, since for the type of work that they had to do and for the big size of the work groups (15 persons), they were foreseeing that it would facilitate very much the work to them. This way, Wiki has meant a tool and methodology very well valued by students for the comments in class at the end of the course (from both those who could use it, and also from those who had to use the traditional methodology).

Lecturers have the impression that if students could have work at an standard Office software environment (either Microsoft or OpenOffice, for example) which could work agile and quick enough for the group work, the success had been much more important. However, the speed of using standard office documents combined with Web folders (Webdav protocol) was not good enough for students nor lecturers, after a pilot experience that was deployed at the early stages of UniWiki project, besides many other handicaps for the web office methodology use in educational scenarios with the current development of technologies (De Pedro 2005a).

Students

On the student side, there where a total of 229 surveys and 223 self-recording tables collected of invested time (divided in methodologies and subjects in Table 3).

Permission denied

A count of the extra comments voluntarily written by the students in their surveys in the blank fields is shown in Table 4, classified by type of methodology and feeling.

Permission denied

The extra comments voluntarily written by the students in their surveys in the blank fields (Table 4) show that, the students value very positively the collaborative writing methodology based on Wiki because:

• it allows them cooperating without travelling to meet,
• it allows them observing the development of their mates' work,
• it is a dynamic communication tool,

Some of them point out their interest in knowing new tools or the security to have their data on the Internet, (apparently) "free from accidents or viruses".

The negative valuation of Wiki methodology, usually comes from connecting problems to Internet o from the lack of time to learn the specific Wiki markup. Most of the negative valuations correspond to problems in organisation: too big or disperse groups, or work organised inadequately. A group declared that they lacked time to deepen at the same time in the three activities:

1. the writing work itself
2. learning the methodology of working in group
3. learning the Wiki technology

In order to illustrate some precise examples, three literal comments are shown of each type below, among the total number of those comments collected

Three examples of POSITIVE comments expressed after working with the WIKI methodology

1. "The time that you devote to it is minor than if it was traditional methodology and can be coordinated with many more people"
2. "It has not been necessary to meet out of the university since we could make it through the wiki"
3. "In FVA I do not use the Wiki because my colleague of work is not very in favor, so we let it be. Anyway, I have to say that the idea is very good, I think that for the works in group (especially when they are mass groups, of 4 people, for instance, I mean) it is a great thing. I always thought, and here the question is already personal, that four persons in front of a computer, once everybody successfully get to meet a day (one of the most usual handicaps ), it is very little productive. I find it more "efficient" if we create general ideas when we meet in person, and then being able afterwards to work each one at his/her home. The fact of sharing files and seeing what the others have been changing is perfect, and if we add up that the forum already goes very well for the hourly incompatibilities of the members of the group, then we have a good combination."

Three examples of NEGATIVE comments expressed after working with the WIKI methodology

1. "I believe that working with the Wiki can serve to facilitate the exchange of information but that it is necessary that the people of the group meet in person to argue how to do it..."
2. "I have lost a lot of time on reworking lost texts (6 or 7 occasions), suffering because you cannot make a backup while you work"
3. "I think that the Wiki can only be useful if all the members of the group have daily access to Internet and the habit of using it"

Three examples of POSITIVE comments expressed after working with the TRADITIONAL methodology

1. "I have not had any problem to communicate with the members of the group since that we are together in the class and taking profit of the same spare hours is very helpful"
2. "I think that the meetings in person improve the work much more, they are an enrichment for the person"
3. "All the possible doubts that we have had, have been able to ask directly to the teacher and this is also well"

Three examples of NEGATIVE comments expressed after working with the TRADITIONAL methodology

1. "I think that we were too many people and that we have not been enough identified among ourselves. Perhaps it is that I am not used to make works in big groups"
2. "Too big working group, so that it is very difficult to be able to meet altogether or even simply a representative of each group"
3. "Difficulty in organizing the work, lack of spirit of group"

“Good practices for Wiki methodology” proposal

The methodology for writing documents collaboratively and cooperative learning based on Wiki (“Wiki methodology”) comprises two aspects to allow sharing information, and following changes with an always ready available copy of your merged version (or any previous version, if needed):
(1)a Wiki-like philosophy or conception of the way of working (what e called "Wiki philosophy", from now onwards), as well as
(2)a Wiki-like computer technology ("Wiki technology", according to definition and initial prototype of Wiki from Ward Cunningham, 1995).

The "Wiki philosophy" means that:

1. . people need to lose the fear of that the other people see the non-finished working documents of everyone, and that they could contribute changes. Every person allows that his document of work should be read and modified by other persons of his/her group of work, along the whole process of writing
2. . people is encouraged to participate with their colleagues work (making a proposal of changes already modifying the other person's document), at any time and at any part.

The "Wiki technology" allows that:

1. it is possible to apply the most common markup to a document in a simple and quick way (here it comes its name, since “Wiki-Wiki” means “quick”, in Hawaiian language), without having to raise the hands of the keyboard
2. any person could see and/or modify the information of the document. Permissions can be granted easily for documents and groups of users, so that many scenarios of collaborative work can be configured
3. it is possible to get notice by e-mail (or RSS feed syndication) when someone comments or does changes on a page of the document, emphasizing first the specific changes made to the previous version
4. changes introduced between any pair of versions of a document can be easily visualized later on
5. content that has been modified or erased (by oneself of by other people) can be recovered, if needed

Thus, a "Good practices with Wiki methodology" proposal can be suggested, after the experience acquired in UniWiki project, including 3 generic plus 7 more TikiWiki-related items (even if other similar Internet platforms, such as Mediawiki, dfWiki, eWiki, etc, would need similar procedures to perform these common tasks when editing documents through “Wiki methodology”):

1. It is convenient to prevent students from aiming to define the structure of his work through telematic means (forums, Wiki, e-mail). It is necessary to define concisely an initial structure of the work. This can be due to teachers suggest an initial concise structure to start working as well as help distributing tasks and tentative work calendar, or due to students define it in meetings in person in front of a blackboard, or similar.
   
   
2. Big work groups need Wiki technology Wiki. Some groups of 4 people each have taken profit out of Wiki methodology, but others have not. Work groups from 8 people onwards did take profit of Wiki methodology indeed (Functional Ecology'05, Evaluation of Environmental Impact'05; De Pedro et al. 2006).
   
   
3. Initial structure of the document can be modified or even lost as time passes, and redundancies of information can appear, etc. There is needed periodic work of restructuring and synthesizing of the introduced information. It can be thought (a priori) that any person might take part in this task, but the experience in this project has indicated that the figure of “Editor in chief” for the joint work is crucial.
   
   Then, some additional recommendations can be given (more Tiki-related, in this case):
   
   
4. It's advisable to define a structure of pages Wiki (book-like collection of Wiki pages, with the featured named "Structures" in Tiki).
   
   • Make single Wiki pages to be as small and divided in sub-pages as possible, in order to avoid the attempts of simultaneous editions of the same content (remember that, up to present date, no Wiki engine can cope with merging the changes from simultaneous edits of the same page; a “Concurrent Versions System” -like tool would be needed instead). In case of attempt of simultaneous edition of Wiki pages of TikiSheets?, Tiki would warn the user that another using is editing this content before him/her, and haven't saved or canceled edition yet.
   
   
5. In case of small tables, include them directly in the text with the proper Wiki format, so that these tables are created and will be editable directly within the body of the Wiki page.
   
   
6. In case of big tables, on the other hand, include them through the “wysiwyg” tables that are included in the Spreadsheets feature in Tiki starting in 1.9 version onwards (http://doc.tikiwiki.org/Spreadsheet - also known as TikiSheets)
   
   
7. In order to include graphs:
   
   1. In case of common graphs (pie chart, multi-line, multi-bar, stacked bars), TikiSheet? feature can generate graphics (figures) directly from the web spreadsheet in Tiki, and you can dynamically include them inside Wiki pages (changes in spreadsheet data will automatically update the figures shown in Wiki pages).
   2. In case of need of more complex or different graphs inside Wiki pages:
      Generate them with your favorite software (there are very nice free software tools to create them), and you need to convert them to bitmap images (like photos; formats *.jpg, *.png, or *.gif), either by exporting the graph as such through your software, or by taking a computer screenshot when the image is viewed and cropping it to your needs (different procedures depending on the operating system in the computer). Once the image is in the hard drive, then select it and press “Upload picture” from within the Wiki page edit form.
      In order to include many graphs generated from external software programs, an easy procedure to convert all of them from graphs in OpenOffice Calc or MS Excel (for instance), into single images on disk could be to save the spreadsheet as html - Web page. Image files should be either in the same directory as the generated html file, or in a folder of the same name as the html file, depending on the program). Then they can be uploaded as images or photos to the Wiki page as previously described.
   
   
8. The powerful “Category system” in Tiki can be used if some dynamic information and coordination is desired regarding the pages that are in on-going process, or just need to be polished, spell checked, improved markup, etc. (or already finished). Even if this would require some more training from students since they may not be used to categorizing content (web or desktop content). Each single object in Tiki can be categorized into one or many of the defined categories (http://doc.tikiwiki.org/Categories).
   
   
9. Once the edition of all the pages is finished, it is possible to export (“print” in Tiki language) at once the whole structure of Wiki pages in html. This can be done with the option "Wiki > Print", in the main menu, through selecting the “structure” of pages to print. This would be the equivalent procedure of working with a master document and sub-documents with standard Office software programs.
   
   • Saving as web page on hard disk from Internet browser is needed again, selecting as “Full Web page” (or similar option, depending on the browser).
   • Then a conversion of the html document on hard disk to common office document format is needed. From OpenOffice (OOo) , an extra step is needed and thus it will be explained here to illustrate a possible procedure. Open the html document with OOo (everything will be inside a single-cell long table). Select the whole content from inside the single cell of the table (the full contents of your document), copy it and paste it into a new (blank) OOo Writer document. Save this new document as text document (either ".sxw" or ".odt"). Then you can already edit the document as wished in that Office suite with normality (modifying styles and formats if needed, including a paginated initial index, header and footer, numbers of pages, etc.).
   
   
10. Before printing the final version in paper, the tasks from the " Editor-in-chief " figure/s are very recommended, as previously reported:
    
    • synthesizing ideas,
    • deleting repetitions,
    • unifying styles and markup (that will be the minimum, thanks to the unified ".css" stylesheet employed by web portals such as Tiki does)
    • improving the spelling and grammar of the text. A good dictionary (online or paper) and standard office spell check tools may help the editor in chief for this final review, specially when the most of the students didn't pay attention to this issues. Some help to reduce duty load at the end for the editor in chief, would be to promote single users to take care of it, and to use spell checking online tools while still editing through the web forms in the Wiki. These could be, for instance, the “Konqueror” Web browser for spell checking almost any language at real time while writing, for GNU/Linux, or also recently through the “Google toolbar” for any operating system, in case your language is supported.
    • make a copy of the document in ".pdf" (there are nice free software tools which produce them, such as OpenOffice, PdfCreator, for instance.