Petit compte-rendu d'expérience sur l'utilisation d'un wiki :

en cours de rédaction

Profil de l'utilisateur

Enseignant-chercheur, bonne culture informatique bureautique de base (word, excel, access...), bonne maîtrise du langage HTML (autodidacte) et assez bonne maîtrise du language css (autodidacte). A 'bricolé' un dicaticiel pour la compréhension orale : le chinois par les films, livré au étudiants sous forme d'un site statique hors ligne gravé sur CDROM. Ma devise par rapport aux TICE > l'autonomie de l'étudiant OUI, mais sans oublier l'autonomie de l'enseignant : nous ne pouvons pas tous nous transformer en informaticiens professionnels et nous voulons que les outils Tice servent notre imagination didactique et pédagogique comme jadis le papier, la colle, les ciseaux, les diapos...

Problème de départ : site statique vs site collaboratif

Je mets en ligne les travaux de mes étudiants, ce qui a un effet très dynamisant sur la qualité et la quantité du travail personnel. Mais, victime du succès, j'ai fini par craquer devant l'envahissement de ma boîte Mail, et le temps passé à convertir au format html leurs documents (le plus souvent en word).

J'ai donc commencé à utiliser un moteur Wiki il y a trois mois (en urgence), pour permettre aux étudiants de mettre directement leurs travaux en ligne. Le thème de ce semestre Karaoke se prêtait bien à monter une petite base de connaissances sur les chansons chinoises, les auteurs, les compositeurs, les interprètes, les festivals... :
http://www.malaoshi.levillage.org/wiki/

Au départ, il s'agissait dans mon esprit d'un site ''kleenex" (i.e. jetable, provisoire). Mais le résultat a été au-dela de mes espérances et en quelques semaines, les étudiants ont constitué une base très riche de chansons chinoises contemporaines traduites et référencées. Si bien que j'envisage de transférer les données sur un moteur wiki plus perfectionné (notamment plus sécurisé et gérant mieux l'historique des pages).

J'avais choisi au départ le moteur wikibabe (simplification de phpwiki) tout simplement parce que mon hébergeur proposait son installation automatique et que j'avais essuyé plusieurs tentatives plus ou moins réussies d'installation manuelles d'autres moteurs sur mon serveur. Je dois avouer que j'avais laissé "pmwiki" de côté au départ, à cause de son skin par défaut un peu austère. Puis la lecture des études comparatives, la simplicité d'intallation (merci, on évite cette ribambelle de messages d'erreurs qui découragent dès le départ !), l'absence de base de données et la découverte de la rubrique skins ont vaincu mes réticences.

Le choix de pmwiki :

C'est un concept généreux qui n'oublie pas les nuls en informatique.
N'ayant aucune compétence en programmation php (et pas de temps pour m'auto-former à php, Sql...), "pmwiki" m'offre quand-même la possibilité de réaliser avec un peu d'autonomie un site collaboratif et 'dynamique' (fonction include etc...).
La documentation est très claire. Je m'en sors bien pour installer petit à petit de nouvelles fonctionnalités en suivant à la lettre les consignes de Cookbook.

Fédération de plusieurs sites dans une ferme

J'installe désormais des pmwiki pour tout le monde (associations et groupes de travail universitaires). Il est fastidieux lorsque l'on installe un nouveau skin ou une nouvelle fonctionnalité Cookbook d'avoir à le faire sur plusieurs sites indépendants. Je m'oriente donc vers la formule ferme, qui permet de stocker les skins et les extensions cookbook dans un seul endroit, de faire les mises à jour en une fois pour tous les champs.

Petits soucis actuels

Migration phpwiki (wikibabe) vers pmwiki :

Ce sera vraiment la fête lorsqu'une formule simple sera mise au point pour les migratios interwikis !
Néanmoins, en attendant, voici un utilitaire en ligne qui rend bien des services : http://diberri.dyndns.org/html2wiki.html. Il permet de convertir des pages html dans plusieurs dialectes de markup (pmwiki, mediawiki, dokuwiki, wakkawiki, usemod, phpwiki etc...). (page de documentation : http://search.cpan.org/~diberri/HTML-WikiConverter-0.30/WikiConverter.pm). Il peut donc être utilisé pour convertir les pages html générées par un moteur de wiki dans le dialecte d'un autre wiki.

Affichage des résultats de la Recherche : mots en contexte

Une utilisation pédagogique très intéressante des moteurs de recherche est la possibilité de visualiser des mots ou chaînes de mots en contexte. De nombreux moteurs de recherche de wikis affichent les résultats de la recherche avec une portion de contexte, le mot clef étant surligné. Ainsi, mes étudiants peuvent-ils observer le fonctionnement d'une particule grammaticale donnée dans le corpus des pages du wiki (exemple, recherche de 把 bǎ sur sinowiki1 : http://www.malaoshi.levillage.org/wiki/index.php?full=%E6%8A%8A). On peut bien sûr les renvoyer sur Google ou sur des concordanciers en ligne, mais il est alors impossible de circonscrire ou de choisir le corpus de travail.

Il s'agit pour moi de l'évolution la plus attendue de pmwiki.

Recherche sur le site avec les moteurs de recherche externe à "pmwiki"

Je ne comprends pas pourquoi les résultats ne tiennent compte que des pages statiques (html) et pas des pages html générée par le wiki. Le moteur est-il bloqué par une restriction d'accès ?

Formulaires

Il s'agit d'un des modules qui m'intéresse beaucoup et que je n'ai pas réussi à faire fonctionner (j'ai mal compris les explications). Je trouverais intéressant de faire travailler mes élèves eux-même sur de petites bases lexicales, à partir de formulaires de saisie, permettant ensuite quelques requêtes simples de tri ou de sélection.

La gestion de l'UTF8

J'ai perdu beaucoup de temps avec ce problème : en effet, tout fonctionne très bien avec Firefox, mais IE6 est un casse-tête chinois. Je ne peux malheureusement le négliger, car mes étudiants sont à 70-80% équipés de ce browser. Je fais profiter ici les personnes intéressées de mes minuscules remarques. J'avais soupçonné un moment la déclaration de doctype, mais finalement, il s'agit d'un défaut de certaines versions de IE6 (je ne parle même pas ici de IE5 !).

IE6 version XP pack SP2 ne pose aucun problème.
IE6 version window 2000 pack SP1 pose le problème suivant : le texte s'affiche (à peu près) correctement en mode lecture. En fait, sans balise <span lang="zh-cn"> (pour le chinois simplifié, par exemple), le browser va puiser dans différentes polices chinoises installées (ignorant les options de police paramétrées par l'utilisateur), ce qui donne des caractères irréguliers, mais bon, c'est lisible, il faut cependant veiller à ne pas préciser de font-family dans les feuilles de style, afin de permettre l'affichage complet des lettres accentuées de la transcription PinYin). Notons que ce problème n'est pas propre au wiki, on rencontre le même dans les pages html statiques. Au passage, je me demande s'il ne serait pas intéressant d'ajouter à la distribution standard une balise qui insère un <span lang="">, afin d'améliorer l'affichage dans IE6 (qui se conforme alors aux options de polices paramétrées par l'utilisateur dans les préférences du browser). Par contre, en mode edit, la zone d'édition ne permet pas de visualiser tous les sinogrammes, ni même toutes les lettres accentuées de la transcription PinYin. On travaille donc en aveugle, en utilisant le copier-coller depuis un autre éditeur, ce qui est très embêtant et va contre l'esprit même du wiki.

Voici un échantillon pour vérifier (une partie de) mes dire dans vos browsers (car les présentes pages ne sont pas codées en `UTF-8, donc vous ne verrez pas les problèmes concernant l'affichage des sinogrammes en mode edit) ):

在广场的左边，搭起了一座木台，
Zài guǎngchǎng de zuǒbian， dāqǐ le yī zuò mùtái,
Une estrade en bois fut dressée à gauche de l'usine,

Visualiser avec quelques copies d'écran: http://www.sinowiki.info/Inalco/BoYa/wiki.php/Site/Test(approve links)

à suivre...

Lenteur de chargement des pages

J'ai l'impression que les pages des champs de ferme se chargent beaucoup plus lentement que les pages d'un wiki indépendant.

Index

Je me demande s'il y a un moyen pour que le fichier .php initial soit interprété comme un index par le serveur sans passer par une page index.html?) J'ai finalement trouvé la réponse à ma question en farfouillant sur le présent site : écrire DirectoryIndex pmwiki.php dans le fichier .htaccess (en remplaçant pmwiki.php par le nom du fichier initial dans le champ de ferme.% Remarque : il existe une autre solution : créer un fichier index.php (ou index.php5 pour forcer le PHP5) contenant uniquement la ligne : <?php include('pmwiki.php'); Voila, c'est tout.