Les polices de caractères Tiresias ont été conçues pour faciliter la lecture des personnes malvoyantes. Elles sont déclinées selon les usages :

• pour de l’affichage et la signalétique publics (Tiresias Infofont & Signfont),
• pour les claviers (Tiresias Keyfont),
• pour les textes larges, comme les pages d’un livre (Tiresias LPfont),
• pour l’affichage sur écran d’ordinateur (Tiresias PCfont),
• pour les sous-titrages TV (Tiresias Screenfont).

Chaque police contient des subtilités propres au handicap visuel et au contexte d’utilisation. C’est un travail de recherche approfondi, mené par plusieurs organismes anglais (dont le Royal National Institute of the Blind, partenaire du CRI-Greta du Velay), qui a permis de donner à ces polices une forme optimale et accessible. Par exemple le l (L minuscule) et I (i majuscule) sont clairement différents, de même que le i et le j sont plus difficiles à confondre. Les polices traditionnelles ne tiennent pas forcément compte de ces subtilités, rendant parfois la lecture hasardeuse même pour les voyants.

La police Keyfont, plus particulièrement adaptée à l’écriture des touches (clavier, calculatrice, boutons d’interphone, etc.) est désormais gratuite. Il suffit de la télécharger et de l’installer (format True-Type Font, TTF) sous Windows, Mac OS ou Linux. Au-delà de l’usage prévu par les chercheurs qui l’ont mise au point, elle est tout à fait utilisable dans d’autres contextes. Elégante, elle facilite la lecture de tous sans stygmatiser le handicap.

Sébastien Billard (Référencement, Design et Cie) nous signale un article critique à propos des polices Tiresias, ainsi que l’existance de l’APHont (A Font for Low Vision), une police dont les lettres sont (en autre) plus larges, plus ouvertes et plus espacées. Gratuite, présentation plus détaillée ici.

AJAX est une nouvelle façon de combiner un ensemble de technologies pour concevoir des sites web aux fonctionnalités très évoluées. Le terme signifie « Asynchronous Javascript And XML ». Mais au delà de Javascript et XML, le HTML et les CSS sont fortement impliqués dans la conception d’applications AJAX puisqu’ils en constituent la face visible. Le(s) navigateurs(s) étant la coquille d’accueil de ces applications. Une partie de l’application co-existe en général côté serveur, dans un langage différent de Javascript.

Le « Web 2.0 », symbole de l’explosion des nouvelles tendances au partage, et AJAX se nourrissent mutuellement. AJAX permet de concevoir des sites web dignes de véritables applications d’un nouveau type pour l’internaute. Et le « Web 2.0 », sans le saut technologique apporté par AJAX, ne serait pas vraiment vu comme une révolution.

Alors, [r]évolution majeure ou nouveau joujou pour technophiles ? AJAX est-elle la technologie qui manquait, ou juste une façon bricolée d’arriver à son but ? Son émergence est-elle dû aux qualités intrinsèques de Javascript, depuis longtemps critiqué, ou bien au désert laissé par ce qui devrait être LE framework (cadriciel) libre de développement d’applications portables, partageables, ouvertes et modifiables, ergonomiques ?

Voir l’article de Jean-Louis Nauges qui présente AJAX en détail et Fred Cavazza pour une « première définition du web 2.0″. Eric van der Vlist propose également un bon article de fond sur le web 2.0.

La mutation dans l’utilisation de Javascript

Juste avant la révélation AJAX, Javascript était plutôt le vilain petit canard des langages de programmation. Les développeurs du web ne l’aimaient pas pour différentes raisons : un nom proche de Java qui suscite l’amalgame, trop d’implémentations pas très compatibles entre elles et sources de bugs, trop sous l’emprise de Sun et Netscape, frein à l’accessibilité, et surtout des situations d’usage plus proches du gadget boiteux que de la fonctionnalité ingénieuse et indispensable. De nombreux exemples de sites ont contribué à la mauvaise image de marque de Javascript, le reléguant à quelques vérifications de formulaires ou la gestion des fenêtres « popup » insupportables.

Puis Google a marqué les esprits avec Google Maps, qui n’existerait pas sans Javascript, et qui est un exemple de bon usage remarquable. Depuis Javascript s’est désinhibé, et de véritables logiciels sont apparus dans nos navigateurs (citons Netvibes, exemple parmi tant d’autres^[1]). Google continue dans cette voie avec plusieurs services basés sur AJAX (Google Maps n’était pas le premier). Apple a également choisi Javascript pour développer ses widgets « Dashboard » (Yahoo! également avec ses Widgets), de véritables petites applications autonomes, que l’on peut modifier ou créer soit même. Et la fondation Mozilla développe un modèle proche d’AJAX+HTML avec son framework XUL.

Javascript est donc passé du petit langage d’agrément pour pages web au langage de développement d’applications réseau. Non pas parce qu’il est le plus doué pour ce genre de développement, mais essentiellement parce qu’il est présent dans tous les navigateurs quelque soit le système d’exploitation. Et le navigateur, pour un grand nombre d’utilisateurs, est la porte d’entrée de l’ordinateur et du réseau.

Avant AJAX : la page web est le support pour de petites applications Javascript, le plus souvent d’agrément et facultatives pour utiliser le contenu.

Avec AJAX : Javascript devient le coeur du site. Il génère du contenu HTML dont il a la maîtrise. D’autres langages côté serveur peuvent intervenir. Javascript, côté client, s’appuie sur le moteur graphique du navigateur pour générer l’interface de l’application, plus pratique que n’importe quel « toolkit ».

Cette mutation a quelque-chose de perturbant et d’illogique : le navigateur n’est plus seulement un logiciel pour consulter des pages web (ce que tout le monde avait fini par comprendre), mais c’est également un logiciel qui permet d’exécuter d’autres logiciels en son sein (en somme il devient système d’exploitation). Il faudra écrire un autre article pour essayer de comprendre comment les « vrais gens » vont interpréter et adopter ces prérogatives technologiques. Car s’il est logique pour le développeur AJAX de s’appuyer sur le navigateur pour créer un tableur, un traitement de texte, un calendrier, etc, du point de vue de l’utilisateur ce n’est pas aussi évident ! Le point d’orgue de ce délire technologique est peut-être atteint avec http://palary.org, un navigateur web créé avec AJAX… et qui fonctionne donc, pour l’instant, à l’intérieur d’un navigateur web ! Ou ici encore avec YouOS (voir la demo), un bureau entièrement fait en javascript (menu démarrer, barre des tâches, gestionnaire de fichiers, etc).

La simplicité et le bricolage

AJAX est donc plébiscité parce qu’il donne naissance à des applications comme jamais nous avions vu par la fenêtre du navigateur. Mais il s’agit bien d’applications qui pourraient exister de façon autonome : Google Earth par exemple est l’équivalent « extrapolé » et bien plus puissant de Google Maps. Parmi tous les langages existants et doués grosso modo des mêmes fonctionnalités que Javascript, aucun n’a séduit et rassuré les développeurs pour faire cela. Aucun n’a donné facilement accès à HTML pour mettre en page simplement des interfaces graphiques, les animer, et interagir avec l’utilisateur. Aucun n’a permis aux utilisateurs de créer des applications installables aussi naturellement qu’en téléchargeant quelques scripts texte dans un navigateur, en un clic, sur n’importe quel ordinateur. Aucun n’a su se médiatiser aussi rapidement auprès des milliers de petites mains « nouvelle génération » qui développent pour le web, et aucun ne s’est montré autant « nouveau » et « ouvert » à leurs yeux. C’est le petit qui l’emporte, sans marketing et sans stratégie à long terme, seul contre tous. Il est probablement là le succès (relatif pour l’instant) d’AJAX : la simplicité et le bricolage dans le navigateur, sous couvert de révolution technologique.

Car Javascript n’est pas encore portable (il faut encore développer certaines fonctionnalités en double ou triple selon le navigateur qui l’exécute), pas très rapide, pas plus dédié qu’un autre langage procédural pour gérer les particularités de la programmation client/serveur appliquée au web. Les applications AJAX qui ont médiatisé le concept ont été montées de toutes pièces avant que de véritables frameworks permettent de développer rapidement et de façon fiable. Il faut, comme cela est en train de se faire avec PHP, réinventer les poudres d’un véritable environnement de développement. On voit déjà différentes solutions^[2] pointer leur nez, souvent plus pour solutionner de nouveaux problèmes que pour jeter les bases théoriques d’un véritable outil de développement du « web 2.0 » (pour parler à la mode !).

En ce sens et d’un point de vue technique, c’est une forme de retour à la préhistoire, pas une révolution. Mais les « geeks » aiment reconstruire, la puissance Google est là, et les concurrents mastodontes ne leur ont rien proposé de plus séduisant sur les atouts évoqués. En attendant AJAX prend donc la place qu’on lui laisse…

L’association BrailleNet publie un manuel méthodologique pour aider les développeurs et gestionnaires de sites web à évaluer l’accessibilité de leurs sites, et à défaut corriger les points défaillants. Les critères utilisés sont ceux du référentiel AccessiWeb, composé de 92 critères, référencés sous forme de fiches au sein du « Guide AccessiWeb ». Par exemple le critère n°1 est « Chaque élément graphique possède-t-il une alternative textuelle ? ». Chaque fiche donne des méthodes pratiques pour évaluer le point abordé.

Les retours des utilisateurs ont montré la nécessité d’avoir des outils concis et pragmatiques pour aborder le travail d’évaluation. Ce manuel en 4 volumes constitue donc des « méthodes opérationnelles » spécifiques selon l’approche souhaitée par l’évaluateur. Il couvre l’évaluation par le code source, l’évaluation par la barre d’accessibilité AIS, l’évaluation par la barre d’accessibilité Web Developer, l’évaluation par le logiciel JAWS.

Méthode

Selon la méthode de travail souhaitée, il suffira de choisir un des 4 volumes du manuel et de vérifier les 92 points du référentiel. Par exemple pour le point n°1, avec une approche par le code source, le guide préconise : « 1. Identifier tous les éléments IMG en faisant une recherche dans le code source. – 2. Vérifier que chaque élément IMG a un attribut ALT qui lui est associé. »

Notons qu’Hervé Chuzeville a réalisé un tableau récapitulatif des points à vérifier (sur deux pages), displonible en plusieurs formats sur son site.

Plus d’excuse donc pour ne pas se lancer dans une évaluation profonde de l’accessibilité de ses sites…

Références

• Le manuel AccessiWeb.
• Le guide AccessiWeb et ses 92 critères.
• L’association BrailleNet, a l’initiative des ces outils. Voir également les formations accessibilité.

Enervé par des commentaires répétitifs de spammers (pipi, caca, etc), j’ai légèrement modifié Dotclear de façon à berner ces messieurs. Les systèmes antispam que j’avais testés ne me convenaient pas, puisqu’il fallait rester aux manettes pour effacer les commentaires indésirables.

En fait les spammers sont assez feignants (sinon ils ne feraient pas ce métier). Ils cherchent à automatiser à moindre frais pour poster sur les systèmes de blog les plus populaires. Il suffit d’introduire une petite modification dans le fonctionnement de son gestionnaire de blog pour débusquer les trompeurs. Quand un spammer réussi à passer j’ajoute une nouvelle méthode de détection. Pour l’instant ce petit hack de Dotclear suffit à tromper ceux qui nous ennuyaient. C’est simple, plus aucun commentaire de spam !

Pour les sceptiques, voici le log des messages de spam reçus sur ce blog (vidé de sa moitié de temps en temps). MAJ : ce blog fonctionne maintenantavec Wordpress.

IMPORTANT : Il faut appliquer successivement les modifications (méthodes de détection) proposées ci-dessous, et non pas en choisir une au hasard (à moins de comprendre ce que l’on fait). Ou bien vous pouvez télécharger les fichiers modifiés, en bas de page. Et surtout, n’oubliez pas de tester vos modifications en vous envoyant un commentaire.

Méthode de détection 1

Dans le fichier /themes/votredossiertheme/form.php, ajouter cette ligne :

<!-- <input type="hidden" name="name" value="value" /> -->

juste avant le dernier champ fieldset :

</fieldset>

Et dans /layout/prepend.php, chercher la ligne contenant :

if ($blog->addComment($post_id,$c_nom,$c_mail,$c_site,

et transformer en :

if (isset($_POST['name']) or     $blog->addComment($post_id,$c_nom,$c_mail,$c_site,

Voilà. Un navigateur respecteux ignorera le commentaire (et n’enverra donc pas le champ caché), un spammer irrespectueux ne prend pas le peine de tester le commentaire HTML et son message sera ignoré… Très facile à contourner, mais en attendant ça filtre les ballots.

Methode de détection 2

Si le spammer n’analyse pas le contenu HTML de la page, le hack ci-dessus est inefficace. Mais dans ce cas, il doit connaître la nature des champs à envoyer au serveur pour poster le message. Changeons un peu le code de façon à rendre son automatisation obsolète :

Toujours dans le fichier /themes/votredossiertheme/form.php, chercher la ligne contenant :

<textarea name="c_content" id="c_content" cols="35" rows="7">

et transformer en :

<textarea name="c_content_blabla" id="c_content" cols="35" rows="7">

Ensuite dans /layout/prepend.php, remplacer c_content par c_content_blabla (à deux endroits, lignes 226 et 232).

Si le robot spammer automatise son envoi, il utilisera c_content comme nom de champ. Mais votre DotClear customizé s’attend à recevoir le message dans c_content_blabla, qui sera vide. Plouf !

Methode de détection 3

Certains spammers bourrent les champs TEXTAREA du formulaire avec leurs infamies. Trompons un peu plus l’ennemi avec cette méthode 3. Pensez également à appliquer les méthodes 1 et 2 ci-dessus.

Dans le fichier /themes/votredossiertheme/form.php, ajouter cette ligne :

<p class="field" style="display: none">Commentaire :
  <textarea name="c_content" cols="35" rows="7">Ne pas modifier ceci !</textarea> </p>

par exemple juste avant :

<p class="field"><label for="c_content">Commentaire :</label>

Ensuite dans /layout/prepend.php, modifier la même ligne que dans la méthode 1 pour avoir :

if (isset($_POST['name']) or $_POST['c_content'] != "Ne pas modifier ceci !" or
  $blog->addComment($post_id,$c_nom,$c_mail,$c_site,

Normalement ce champ de formulaire n’est pas affiché par le navigateur (s’il connait CSS) et n’est donc pas modifié. Les robots devraient tomber dans le piège en remplissant ce champ, chose à ne pas faire pour que le commentaire soit pris en compte… Et comme le nom du champ est celui normalement utilisé par Dotclear (c_content), cela donne une chance supplémentaires aux spamikazes de tomber dans le panneau.

La suite

Quand les robots contourneront ces tests, il faudra en inclure un autre, puis un autre, etc. Au mieux on élimine les messages dont on est sûr qu’ils sont un spam, au pire on les laisse passer, et dans ce cas un plugin antispam peut prendre la relève, comme d’habitude. A l’inverse, une méthode supplémentaire basée sur JavaScript pourrait confirmer que le message n’est pas un spam. Le tout est de s’adapter plus vite que l’ennemi. Mais comme les spammers ne consultent jamais les sites qu’ils poluent, nous sommes tranquilles !

Sinon, d’autres solutions techniques contre le spam des trackbacks sont proposées dans les commentaires ci-dessous.

Les fichiers modifiés

Vous pouvez obtenir les fichiers en service actuellement sur ce blog : form.php et prepend.php (attention, un fichier de log spamlog.txt est créé sur la racine du site pour enregistrer les messages ignorés). Même si ce serait plus pratique, il n’y aura probablement jamais de plugin Dotclear clef-en-main, car l’uniformisation amènerait rapidement des contournements de la part des spammers. Restons isolés pour éviter les tirs groupés !

Le 23 janvier, Google annonçait sur son blog une mise à jour importante de son service Google Maps. Notamment, la qualité des cartes a été améliorée sur certaines parties du globe, permettant d’avoir deux niveaux de zoom supplémentaires et donc de voir encore plus de détails de la surface terrestre. 1 pixel à l’écran correspond ainsi à 15 cm sur le terrain.

Google était déjà accusé d’être indiscret et suscite une certaine crainte depuis que l’on a découvert qu’il pouvait révéler des documents confidentiels ou des informations nomminatives grâce à d’habiles requêtes, l’obligeant à permettre le désabonnement à ses services (ici pour le web, là pour les groupes de discussion, et là pour la numérisation des livres).

On peut se demander, pour Google Maps, quand apparaîtra la première affaire de violation de la vie privée, et quand Google devra proposer, à l’instar des autres services, de déréférencer sur demande un individu qui se reconnaîtrait sur une carte. En attendant, allons flaner un peu au dessus des pelouses et des serviettes de Central Park…

(Voir le billet en français)

This patch is deprecated.

Here is a patch to enable article restriction under MediaWiki. Pages can be articles or categories. It adds a new |restrict| tab link allowing members of the group restrict to restrict pages. Users member of the group viewrestrict can read (and modify) the restricted pages. Others users cannot see, search, export, etc, the restricted pages. You can still |protect| them for editing. A restricted page is distinguished by a red background tab, and you have a special page (Special:Restrictedpages) to list the restricted pages. All restriction/unrestriction actions are loggued in the wiki log. It is also possible to restrict pages or namespaces by providing a regular expression array matching titles, and to restrict new pages by default. Optionaly the user’s pages can be restricted to their owner. Currently it is localized in English, German, Dutch, Swedish, Catalan, Finnish, Russian, Hebrew, Polish, Czech, Spanish and French.

This feature is mainly useful for intranet relying on WikiMedia as a non-encyclopedic content management system, like e-learning platforms or informational systems. To respect the wiki philosophy, it is not appropriate to use it to restrict public access!

To install restriction-patch, download MediaWiki (do a security backup if you patch your own installation), or see below to dowload a pre-patched archive.

Apply patch

mv restriction-version.mediawiki-version.patch ./mediawiki-version cd ./mediawiki-version patch -p0 < restriction-version.mediawiki-version.patch

Configure

First, install MediaWiki as usual (to create the database and the LocalSettings.php file). Once your wiki works fine you have to enable restriction. It is disabled by default. So add in your ./LocalSettings.php file (at the bottom of the file) :

/**
  * If true, a new menu action allows to restrict pages access to 'restrict' group users.
  * If false, all previously restricted pages are accessible again.
  */
  $wgEnableRestrict = true;

  /**
  * If true, new pages are restricted by default for 'restrict' group users.
  */
  $wgRestrictNewPages = false;

  /**
  * If true restrict user pages to their owner (as well as viewrestrict/restrict members)
  */
  $wgUserPageRestrict = false;

  /**
  * when wgUserPageRestrict and this option are true, allows user pages to be read but not edited by others?
  * added to restrict version beta-0.8.2
  */
  $wgUserReadRestrict = false;

  /**
  * Regular expression array to restrict matching pages
  * eg. $wgRegexRestrict = array("^Secure:", "^Secret ");
  *     restrict all pages where title is like 'Secure:...' or 'Secret ...'
  * with restrict version beta-0.8.1 you can also use Inverse regex matching
  * eg. $wgRegexRestrict = array("!!Public.*", ".*");
  *     any pages starting with "Public" is un-restricted and all others are restricted.
  */
  $wgRegexRestrict = array();

  /**
   * If true do not add recent changes entry for restricted pages
   */
  $wgNoRecentChangesRestrict = true;

  /**
   * If true hide log entries related to restriction, except for 'restrict' or 'viewrestrict' users (Special:Log page)
   */
  $wgHideRestrictLog = true;

  /**
   * MediaWiki permissions setup
   */
  $wgGroupPermissions['restrict']['restrict'] = true;
  $wgGroupPermissions['restrict']['viewrestrict'] = true;
  $wgGroupPermissions['viewrestrict']['viewrestrict'] = true;
  // with restrict version beta-0.8.2 when $wgUserPageRestrict and $wgUserReadRestrict is true
  // 'authors' group members get 'edituser' rights and can edit other users pages and sub pages.

  $wgGroupPermissions['authors']['edituser'] = true;

By default nobody is able to restrict page. Go to the User rights management page (in special pages) and add users in group restrict (allow to view and restrict pages) or viewrestrict (allow only to view restricted pages). Here is a FAQ on metawiki.

If $wgUserPageRestrict is true, user pages are restricted to their respective owner, as well as members of the viewrestrict group.

Don’t write sensible information in page titles, they could be retrieved in some cases. This is beta and GPL, test and feedback welcome !

Get the patch

• Download the patch for MediaWiki version (patch version) :
  • For MediaWiki 1.4.x see this article (deprecated)
  • 1.5.8 (beta 0.62) (deprecated)
  • 1.6.3 (beta 0.64) (old version, quite stable)
  • 1.6.6/1.6.7/1.6.8 (beta 0.72) (new version)
  • 1.7.1 : An unstable version (not verified by me) is proposed in a comment below (thanks to JesperZedlitz).
• If you have problem to patch (eg. windows users), here is the full pre-patched archive : mediawiki-1.6.8-restriction-patch-beta-0.72.tar.gz (install as usual, but do not forget to enable restriction feature, read the doc above)
• Some screenshots (MW 1.4)
• MediaWiki home page and the page about the patch

Mailing list and contact

You can subscribe to the mailing list to discuss about this patch, receive news, etc. Send an empty mail to restrict-mediawiki-list-subscribe@… and reply to the confirmation mail.

To contact me (no personal support, use this blog) : restrict-mediawiki/at/conseil-recherche-innovation.net (Jérôme Combaz)

Changelog

Version beta-0.72 for MW 1.6.6/1.6.7/1.6.8 (09-01-2006)

• Spanish translation (thanks to Victor Fariña from Queres tecnologias)
• Czech translation (thanks to Michal Ciza)

Version beta-0.71 for MW 1.6.6/1.6.7 (07-13-2006)

• Two bugs in Articles.php and Skin.php (thanks to Owen, see here)

Version beta-0.70 for MW 1.6.6/1.6.7 (06-06-2006)

• SQL requests are not modified anymore to check the restriction (better sustenability of the patch)
• Now restricted pages and *regex* restricted pages are treated in the same way. So none of pages title should be listed whatever the protection mechanism choosed, nor during a search request
• Regex restriction include the namespace, so it is now possible to restrict whole namespaces (eg. « ^Talk: » restrict all talk pages)
• Image partialy restricted (not listed but file accessible via HTTP)
• The SpecialVersion page informs that MW is patched
• Correction of text error on the unrestrict page (thanks to Mathaba)
• Polish translation (thanks to Janusz ‘Ency’ Dorozynski)

Version beta-0.64 for MW 1.6.3 (05-01-2006)

• Bug in SpecialCategories page (thanks to T O X I N)
• Hebrew translation (thanks to Yuval Hager)
• Bug in OutputPage.php (thanks again to Yuval Hager)

Version beta-0.63 for MW 1.6.3 (04-20-2006)

• Upgrade for 1.6.3 (thanks to Anthony for his help)
• Russian translation (thanks to T O X I N)
• Finnish translation (thanks to Tuomas Helin)

Version beta-0.62 for MW 1.5.5/1.5.6 (02-13-2005)

• Catalan translation (thanks to Pau Cabot)
• Small mistake (comma) in swedish translation

Version beta-0.61 for MW 1.5.5/1.5.6 (01-18-2006)

• Swedish translation (thanks to Samuel Lampa)
• Dutch translation (thanks to Peter De Baets)

Version beta-0.6 for MW 1.5.3 (12-15-2005)

• $wgHideRestrictLog option is back

Version beta-0.59 for MW 1.5.1/1.5.2 (10-31-2005)

• Allow to restrict new pages by default ($wgRestrictNewPages option)
• Bug : ‘ArticleProtectComplete’ hook function remplaced by ‘ArticleRestrictComplete’ (stupid mistake !)

Version beta-0.58 (10-07-2005)

• Restriction by regular expression test on title.
• Bug which avoided to view restricted pages in special pages (only ‘restrict’ group can see it, not possible to add ‘viewrestrict’ group) (thanks to Karen O’Flaherty)
• German translation updated (thanks to Hugo Wirz)
• French and english translations updated.
• Bug in Broken Redirects special page SQL request
• Categories special page hide restricted categories for non allowed users
• No more modifications in monobook stylesheet than one style added (see bottom of /skins/monobook/main.css file).

Version beta-0.57 (09-18-2005)

• Stupid cosmetic bug which avoid patch working if user page restriction enabled (thanks to Christophe Berger)

Version beta-0.56 (09-11-2005)

• Bug « variables can be passed by reference in mediawiki\includes\Article.php on line 1703″ with some PHP configurations (thanks to Chunho Lee)

Version beta-0.55 (09-07-2005)

• First public release for MediaWiki 1.5

Les 2 et 3 juin 2005 se déroulaient les journées GreCO organisées par les services TICE de Grenoble Universités. Conférences, débats, ateliers forum ou découverte, présentation de projets, le programme était exhaustif et accueillait une belle palette de spécialistes (voir le programme). Le CRI/Greta du Velay était invité comme intervenant de l’atelier « Étudier avec les technologies, ça se paye ! », l’occasion de rappeler l’existence de la Charte pour l’Inclusion Numérique et Sociale. Débat très riche, pendant lequel nous avons essayé de répondre à la question « qui paye et pour quoi ». Un compte rendu détaillé sera disponible sur le site des organisateurs. J’ai noté quelques réflexions personnelles et initiatives intéressantes issues de ces 2 journées de rencontres.

(Lire la suite…)

Wiki est un concept de site web, dont la principale particularité est de permettre aux visiteurs de modifier eux-mêmes les pages, sans aucune formalité. L’encyclopédie Wikipédia est le plus bel exemple de ce que l’on peut obtenir comme effort collectif. La philosophie wiki repose sur un principe fort, celui de l’ouverture maximum et du non-secret. La plupart des wiki ne demande pas d’être authentifié pour modifier les pages (la confiance prime), toutes les modifications faites sur le wiki sont enregistrées et visibles de tous. Ainsi les centaines de milliers d’articles de l’encyclopédie Wikipédia peuvent être modifiés par les anonymes de passage… Les restriction existent pour gérer certains conflit, mais cela reste anecdotique. L’ensemble des pages reste accessible à tous.

MediaWiki est le logiciel qui permet de gérer un wiki à-la-façon Wikipédia. Ce logiciel (libre) peut être téléchargé et installé pour d’autres besoins, par exemple pour monter une plate-forme de formation à distance. Le principe wiki est particulièrement adapté, il apporte de la souplesse et permet à des non-spécialistes de composer un contenu avec une présentation logique et graphique homogène. Mais il peut être nécessaire de restreindre l’accès à certaines pages, comme les pages de suivi des stagiaires, ou le journal de bord des formateurs. Cela n’est pas possible (de façon simple) avec MediaWiki. Je me suis donc attaqué à modifier « la bête » afin de pouvoir restreindre l’accès à n’importe quelle page en deux clics.

Caractéristiques

• Possibilité de restreindre les articles ou les catégories à un certain groupe d’utilisateurs (sysop, bureaucrat, etc)
• Une page bloquée possède un onglet rouge pour bien la repérer.
• Il reste possible de protéger une page en édition, en plus de restreindre son accès.
• Une Page spéciale permet d’afficher les pages restreintes.
• Impossibilité d‘exporter, de rechercher les pages restreintes si l’on a pas les droits.
• Enregistrement des restrictions et autorisations dans le log de MediaWiki, avec éventuellement un accès restreint aux logs.
• Pour respecter la philosophie wiki, l’option n’est pas activée par défaut !

La modification est en version beta, à vos risques et périls ! Si vous voulez modifier une version en fonctionnement, faire une copie de sécurité.

Installation

Reportez-vous au billet suivant (en anglais, désolé)

Contact

Laisser un commentaire dans ce billet (en français) pour donner vos impressions, bugs, etc.

Le CRI a co-publié un article sur l’environnement distribué expérimenté dans la plate-forme Diogene. L’article a été présenté au cours de l‘International Kaleidoscope Learning GRID SIG Workshop qui s’est déroulé du 14 au 16 mars 2005 à Naples.

Les Grid technologies (technologies de grille) sont une évolution du principe des clusters et du peer-to-peer. Ces deux technologies permettent de mutualiser puissance et capacité de stockage en mettant un ensemble d’ordinateur en réseau. Les grids veulent étendre et formaliser ce principe, en permettant de mutualiser au maximum toutes les ressources disponibles au sein d’un réseau de machines hétérogènes et indépendantes. Le principe n’est pas complètement nouveau (voir par exemple distributed.net), mais pour qu’il s’étende à des usages moins spécifiques et de manière transparente, il a besoin de standards : pour les échanges de données, pour les langages utilisés, pour les droits d’accès, etc. Les grids devraient aussi mettre à contribution d’autres domaines de recherche, comme les algorithmes génétiques ou les réseaux de neuronnes.

La Commission européenne veut encourager le développement des Grids et lance des appels à propositions dans le cadre du 6st Framework Programme. Une brochure de vulgarisation est disponible en ligne.

• L’article A Virtual Organisation for e-Learning (PDF, english version)
• Brochure et informations sur les Grids technologies, site de la Commission européenne.

DIOGENE est financé par le 5ème programme-cadre de recherche de la Communauté Européenne – Technologies de la Société de l’Information (contrat IST-2001-33358). L’objectif est de concevoir et de réaliser un environnement innovant de courtage de services de formations en ligne puis de l’évaluer en situation réelle. Dans un premier temps Diogène s’adressera aux professionnels des TIC mais la plate-forme sera indépendante des contenus. Diogène soutiendra les apprenants pendant tout le cycle d’apprentissage, depuis la définition des objectifs jusqu’à la validation des résultats en passant par la construction de parcours de formation personnalisés.

En utilisant les métadonnées et les ontologies, Diogène offrira des fonctionnalités innovantes: modélisation probabiliste des apprenants, adaptation personnalisée des parcours de formation, apprentissage coopératif et tutorat en ligne, définition assistée et intelligente des objectifs de formation, stratégies dynamiques d’apprentissage, ouverture sur le web sémantique, gestion des objets d’apprentissage (Learning Object) et du copyright, génération de CV, intégration de formateurs indépendants.

Diogène sera accessible sur le Web par un ASP. Une fois inscrit, l’apprenant pourra choisir des thèmes organisés à partir d’une ontologie avant de se voir proposer un cours sur mesure. (cette individualisation sera basée sur la détermination du profil des apprenants). En complément, Diogène proposera les services suivants :

• Des formateurs indépendants pourront s’inscrire dans Diogène et décrire d’une manière formelle leurs capacités professionnelles. Ainsi, les apprenants pourront, s’ils le désirent, solliciter les formateurs pour être guidés et soutenus dans leur parcours.

• Les apprenants avec des besoins ou des profils identiques seront repérés afin de leur fournir un environnement coopératif facilitant les échanges et le « mentoring ». Ce même environnement sera utilisé comme interface de communication synchrone et asynchrone avec les formateurs.

• Une modélisation de l’apprenant basée sur un format émergent (PAPI , LIP , etc.) représentera les résultats obtenus afin de construire, pour chacun, l’équivalent d’un CV électronique diffusé dans le respect de la vie privée. Un moteur de recherche opérant sur cette base de CV permettra aux entreprises intéressées de recruter des compétences spécifiques.

• Les stratégies d’apprentissage en ligne seront basées sur les besoins des individus et leurs styles d’apprentissage. Elles seront automatiquement améliorées en exploitant l’information résultant des évaluations réalisées au cours de la formation (prise en compte des connaissances acquises).

Une autre fonctionnalité importante de Diogène sera la possibilité d’utiliser, dans la composition dynamique du plan de formation, aussi bien des contenus adaptés et « taggués » par des producteurs de cours enregistrés, que du contenu librement accessible sur le web. L’adaptation des contenus exploitera les capacités offertes par la nouvelle génération du web sémantique annoncée par le W3C: le contenu numérique décrit formellement par des marqueurs XML peut être compris par une machine.

Pour tester les capacités et les innovations de Diogène, six cours seront adaptés: Analyse orientée objet et UML, XML, Amélioration des processus d’ingénierie, Amélioration de la performance des organisations, Php et pages web dynamiques, Images numériques et multimédia. Les tâches sont prévues selon la chronologie suivante :

• identification et formalisation des besoins des utilisateurs,
• élaboration d’une méthodologie de représentation du savoir pour décrire les objets d’apprentissage d’une manière compréhensible par la machine,
• élaboration d’une modélisation des apprenants pour les profiler de manière formelle en terme de savoirs maîtrisés, de préférences et de styles d’apprentissages,
• réalisation d’outils logiciels pour modéliser les objets d’apprentissage qui seront utilisés pour l’adaptation des contenus,
• élaboration de l’ontologie couvrant les domaines des technologies de l’information,
• adaptation et indexation des contenus pour profiter pleinement des fonctionnalités de Diogène (métadonnées),
• élaboration du système principal à partir des besoins exprimés dans la phase d’analyse et à partir de la modélisation des apprenants et de l’ontologie définie,
• intégration des modules de formation dans Diogène,
• expérimentation du premier prototype en situation réelle sous le contrôle d’experts en évaluation,
• amélioration du premier prototype en fonction des résultats de l’expérimentation,
• évaluation du prototype final.

Un modèle commercial viable sera défini et comparé avec les concurrents potentiels. Les activités de recherche et les résultats du projet seront largement diffusés.

Le projet a commencé le 1er avril 2002 pour une durée de vingt-quatre mois.

A consulter

• http://www.capuano.biz/diogene/ (mirroir du site expiré http://www.diogene.org)