History: aw1l 3.1 Results

Source of version: 8

Version
!! 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. 

{SHEET(id=15)}Table 2. Advantages and disadvantages detected by the teaching staff after using Wiki methodology{SHEET}

~~red:En alumnes de primer cicle (per exemple, Ecologia Funcional, Salut i Medi Ambient) hem detectat que:

    * Tenen dificultats per organitzar-se pel treball en grup.
    * Tenen dificultats per sintetitzar la informació, donat que l’accés a la informació ja no és una dificultat con en èpoques anteriors.
    * Depenent de la llicenciatura, els alumnes de primer cicle aprenen més ràpid i accepten millor la nova eina que els de segon cicle. 


Per contra, en alumnes de segon cicle (per exemple, Avaluació d'Impacte Ambiental, Ecologia Aplicada-UB, Fisiologia Vegetal Aplicada) hem detectat que:

    * En general, saben organitzar-se i tenen experiència prèvia en el treball en equip (tenen facilitat per repartir la feina, assumir rols dins l’equip i rentabilitzar l’esforç).
    * Molts dels equips no ha estat de nova formació sinó que els membres ja es coneixien i havien col·laborat o estan col·laborant en altres treballs.
    * Són persones amb recursos que saben “moure's” i utilitzen les eines que tenen a l’abast amb eficàcia
    * Depèn dels detalls de mida dels grups de treball i tipus de treball a fer, la nova metodologia ha estat poc o molt acceptada:
          o En alguns casos, el grau d’acceptació de l’eina ha estat molt baix (assignatura FVA) en part atribuïble al fet d’estar a l’últim any de la carrera (es troben a la recta final i la prioritat es acabar, agafen moltes assignatures i no tenen temps per invertir en novetats, sobretot tenint en conte que ja tenen unes eines que manegen amb facilitat).
          o En altres casos d'assignatures d'últim curs, hi van trobar aspectes positius i negatius (Assignatura "Ecologia Aplicada - CCAA-UAB"). En la part positiva hi ha la facilitat d’interacció entre ells remotament i el que només hi hagi en tot moment una sola còpia bona del document. Es positiu també el fet que els alumnes s’hagin espavilat tot sols amb la poca informació que els vaig donar (expressament) per a utilitzar el Wiki. El seu maneig de la Web sembla suficient per aquest tipus d’aplicacions. En la part negativa destaca el fet que el format Web no és el que estaven més acostumats ni el que els demanava jo al final.
          o En canvi, en el cas de l'assignatura d'Avaluació d'Impacte Ambiental, de tercer curs, l'alumnat ha acceptat molt bé la nova metodologia i tencologia Wiki (assignatura AIA), doncs pel tipus de treball que havien de fer i la mida gran de l'equip de treball (15 persones), preveien que els facilitaria molt la feina. Així, el Wiki ha esdevingut una eina molt ben valorada pels alumnes en comentaris de classe al final de les pràctiques (tant pels que el podien fer servir, com pels que havien de fer servir els mètodes tradicionals). 


Entre el professorat tenim la impressió que si l'alumnat hagués pogut treballar en un entorn d'Ofimàtica estàndard (sigui el de Micro$oft, o el d'OpenOffice) i que funcionés de forma àgil i ràpida, l’èxit hagués sigut molt més important. Aquests entorns són els estàndard de facto, i a la gent no li costa res introduir algunes, poques, variacions sobre aquest estàndard. Ara bé, en la prova pilot que es va realitzar amb l'assignatura Avaluació d'Impacte Ambiental en el curs 2003-04es va detectar que la Ofimàtica Web funciona amb molta més lentitud en l'actualitat, amb la present velocitat dels ordinadros i comunicacions (malgrat a les universitats es disposa d'ordinadors de darrera generació i comunicació per cable d'alta velocitat).
~~

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

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

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. 

{SHEET(id=17)}Table 4. Total number or positive and negative extra written comments declared in empty spaces on the survey by the students{SHEET} 

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: 
# the writing work itself 
# learning the methodology of working in group
# 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__
# ''"The time that you devote to it is minor than if it was traditional methodology and can be coordinated with many more people"''
# ''"It has not been necessary to meet out of the university since we could make it through the wiki"''
# ''"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__
# ''"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..."''
# ''"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"''
# ''"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__
# ''"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 smae spare hours is very helpful"''
# ''"I think that the meetings in person improve the work much more, they are an enrichment for the person"''
# ''"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__
# ''"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"''
# ''"Too big working group, so that it is very difficult to be able to meet altogether or even simply a representative of each group"''
# ''"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 de Ward Cunningham, 1995).

The "__Wiki philosophy__" means that: 
#. 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
#. 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: 
# 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
# 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 
# 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
# changes introduced between any pair of versions of a document can be easily visualized later on 
# 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”):
<ol><li> 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. 

<li> __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).

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

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

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

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

<li>In order to include graphs:
# 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). 
# 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. 

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

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

<li>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.
History

Legend: v=view , s=source , c=compare, d=diff
Information	Version	Action
Tue 06 de June, 2006 17:07 CEST by Xavier.dePedro from 83.180.166.105	12 Current	v s
Sat 03 de June, 2006 16:30 CEST by Xavier.dePedro from 83.180.153.74	11	v s c d
Sat 03 de June, 2006 15:13 CEST by Xavier.dePedro from 83.180.153.74	10	v s c d
Sat 03 de June, 2006 16:19 CEST by Xavier.dePedro from 83.180.153.74	9	v s c d
Sat 03 de June, 2006 15:13 CEST by Xavier.dePedro from 83.180.153.74	8	v s c d
Sat 03 de June, 2006 15:02 CEST by Xavier.dePedro from 83.180.153.74	7	v s c d
Sat 03 de June, 2006 15:02 CEST by Xavier.dePedro from 83.180.153.74	6	v s c d
Sat 03 de June, 2006 11:32 CEST by Xavier.dePedro from 83.180.153.74	5	v s c d
Fri 02 de June, 2006 15:08 CEST by Xavier.dePedro from 83.177.57.188	4	v s c d
Fri 02 de June, 2006 14:37 CEST by Xavier.dePedro from 83.177.57.188	3	v s c d
Fri 02 de June, 2006 12:07 CEST by Xavier.dePedro from 83.177.57.188	2	v s c d
Page: 1/2
Enable pagination per page
SourceHistory
Col·laboren

Traduccions automàtiques
