History: aw1l 3.1 Results

+ 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. <br />* 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.<br />* 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).

+ 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).

+ {SHEET(id=16)}Table 3. Surveys and self-recording tables handed in, for each work methodology and subject.{SHEET}

+ # ''"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"''

+ !!! Good practices for Wiki methodology proposal<br />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):<br />(1)a Wiki-like philosophy or conception of the way of working (what e called "__Wiki philosophy__", from now onwards), as well as<br />(2)a Wiki-like computer technology ("__Wiki technology__", according to definition and initial prototype of Wiki from Ward Cunningham, 1995).<br /><br />The "__Wiki philosophy__" means that: <br />#. 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<br />#. 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.<br /><br />The "__Wiki technology__" allows that: <br /># 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<br /># 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 <br /># 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<br /># changes introduced between any pair of versions of a document can be easily visualized later on <br /># content that has been modified or erased (by oneself of by other people) can be recovered, if needed<br /><br />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):<br /> 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. <br /><br /> __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).

+ 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):

+ It's advisable to define a structure of pages Wiki (book-like collection of Wiki pages, with the featured named "Structures" in Tiki). <br />* 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.

+ 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.

+ 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'')

+ In order to include graphs:<br /># 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). <br /># In case of need of more complex or different graphs inside Wiki pages: <br />+ 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. <br />+ 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.

+ 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).

+ 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.<br />* 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).<br />* 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.).

+ Before printing the final version in paper, the tasks from the " Editor-in-chief " figure/s are very recommended, as previously reported: <br />* synthesizing ideas, <br />* deleting repetitions, <br />* unifying styles and markup (that will be the minimum, thanks to the unified ".css" stylesheet employed by web portals such as Tiki does) <br />* 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.<br />* make a copy of the document in ".pdf" (there are nice free software tools which produce them, such as ))OpenOffice((, ))PdfCreator((, for instance.