La page GestionDeGroupeDePages expose la problématique des groupes de pages et des solutions techniques pour l'implémentation dans Wikini. Pour faire bref, les groupes de pages permettent de classer les pages afin d'organiser le contenu d'un wiki. Le problème classique d'un wiki pour le lecteur est le foisonnement qui engendre une difficulté à se situer ou même à trouver quelque chose. Une meilleure capacité d'organisation du moteur de wiki est certainement la principale clef.

Nous considérons désormais que le sujet a été suffisamment analysé sur cette page, le passage à l'action nécessite un vote pour décider quoi implémenter, ça se passe sur ErgonomieGroupeDePagesVoteFonctionnalites.

Ailleurs
Dans d'autres moteurs de wiki, blog, CMS, etc., la notion de groupes de pages est souvent appelée catégorie et c'est une fonction désormais courante. Le fonctionnement des catégories dépend bien sûr du moteur.

Attribution d'une catégorie
L'attribution d'une catégorie à une page est un acte volontaire de la part du rédacteur de la page. Cependant certains moteurs obligent les pages à appartenir à une catégorie par le biais d'une catégorie par défaut. Certains moteurs permettent aussi l'emploi de multiples catégories. Les catégories multiples essaient notamment de gommer les différences de perception des êtres humains : on ne pense pas tous pareil donc on ne range pas tous pareil. En outre, on n'arrive pas forcément à une même information par le même chemin.

L'utilisation des catégories varient d'un moteur à l'autre :

• dans MediaWiki?, les catégories sont attribuées à l'aide d'un code dans le texte brut de la page par exemple
• dans PlumeCMS??, DotClear? et WordPress?, la catégorie est sélectionnée dans une liste déroulante lors de l'édition de la page

Dans le modèle MediaWiki?, les catégories sont crées au fil de l'eau par l'insertion du code qui va bien. Ceci pose deux problèmes :

• il faut connaître les catégories existantes et ne pas faire d'erreur de frappe
• il faut que le rédacteur ait connaissance préalable de ce système de catégories

Dans le modèle des trois autres, les catégories sont créées dans une page spéciale d'administration du site. L'inconvénient est que seuls ceux qui ont des droits d'administration du site peuvent ajouter des catégories, ce qui, certes, peut être un avantage dans certains cas mais n'est pas le cas général.

Concernant les catégories multiples, seul MediaWiki? gère d'emblée cette fonctionnalité (il suffit d'utiliser autant de fois que nécessaire le code servant à attribuer une catégorie). DotClear? possède un plugin qui ajoute cette fonctionnalité.

Sous-catégories
L'intérêt des sous-catégories se fait sentir sur des projets volumineux où il faudra plusieurs niveaux de détail dans le rangement. Parmi les moteurs évoqués précédemment, seul MediaWiki? gère les sous-catégories par défaut. Il suffit d'inclure la page d'une catégorie dans une catégorie parente, par le biais du même code que celui de la catégorie d'une page (car chaque catégorie possède une page).

Visibilité et contenu des catégories
Pour lister le contenu d'une catégorie :

• dans DotClear?, WordPress? et PlumeCMS??, il suffit de cliquer sur le nom de la catégorie dans la barre latérale et on accède à une page qui rassemble les articles ou billets de la catégorie
• dans MediaWiki?, il faut aller dans les pages spéciales et trouver celle qui liste les catégories

Les items sont classés par date pour les trois premiers, par ordre alphabétique pour le dernier.

Par ailleurs l'appartenance d'une page à une (série de) catégories est clairement affichée par un texte et un lien.

Description d'une catégorie
Classer les pages c'est bien, mais le nom d'une catégorie n'est pas toujours suffisamment explicite pour les nouveaux rédacteurs. Il peut donc être utile d'associer un texte à une catégorie.

• Dans le cas des moteurs de blog DotClear? et WordPress?, la question ne se pose pas vraiment car le panel de rédacteurs est souvent réduit à une personne. On ne peut donc consulter le descriptif d'une catégorie que dans la page d'administration des catégories.
• Dans le cas de PlumeCMS??, la description d'une catégorie est modifiée dans l'interface d'administration mais affichée dans la barre latérale lorsqu'on entre dans la catégorie concernée.
• Dans le cas de MediaWiki?, chaque catégorie possède une page éditable comme toute autre page. En dessous du texte de la page apparaît automatiquement la liste des pages ou sous-catégories de la catégorie.

Bilan
Globalement les catégories sont un outil désormais incontournable qui permet au lecteur de s'y retrouver plus facilement. Ce qui semble intéressant dans les différentes variantes exposées :

• les sous-catégories
• les catégories multiples
• la page de description de la catégorie qui liste automatiquement ce qui lui est rattaché
• la liste déroulante des catégories existantes
• la possibilité d'ajouter une (sous-)catégorie en éditant la page
• le menu des catégories (éventuellement principales) dans la barre latérale

Finalement, c'est un mix des quatre solutions décrites !

Comment cela pourrait se concrétiser ?

L'idée est ici de discuter de l'aspect pratique des choses et non de leur codage - ni même de la faisabilité de ce codage. Il ne faut pas que le contributeur potentiel soit effrayé par la notion de catégories et sous-catégories mais au contraire, que cela paraisse naturel. Ceci favoriserait ainsi le classement correct des pages dès leur rédaction.

Choix de fonctionnalités
Avant de commencer tout travail sur l'ergonomie (et l'implémentation), il est important de choisir quelles fonctionnalités doivent être retenues: certaines sont facultatives, d'autres sont contraignantes ou en conflit (entre elles ou avec ce qui existe déjà)

• Catégories multiples
  • pour:
    • permet de placer une page dans plusieurs catégories, et donc d'accéder à une page via plusieurs "chemins"
  • contre:
    • Partant du principe que l'url d'une page contient le nom de celle-ci (et que c'est la seule chose qui permet de retrouver la page):
      • soit cela empêche deux pages du même nom de se trouver dans des catégories distinctes (adresse identique pour les deux pages)
      • soit cela donne plusieurs URLs à une même page (en plaçant le nom de la catégorie dans l'url)
• Catégories principale et secondaires
  • pour
    • résoud la plupart (tous ?) des problèmes apparaissant avec les catégories multiples
    • permettrait dans un premier temps d'implémenter un système sans catégories multiples et de les ajouter par la suite
  • contre
    • introduit un ordre d'importance (priorité) dans le choix des catégories
      • ceci peut tout à fait être perçu comme une fonctionnalité
      • ceci pourrait éventuellement être masqué par une implémentation et un affichage ne différenciant pas les deux...
        • ... mais l'utilisateur aura tout de même besoin de connaître la catégorie principale dans la plupart des cas problématiques évoqués dans les autres points
• Sous-catégories
  • pour:
    • permet de créer une véritable structure "en arbre" pour le site. Particulièrement utile pour réaliser un livre ou une documentation: Documentation > WikiNi 0.5.0 > Développeurs > Créer une action
      • cette structure devient un "graphe orienté" dans le cas des catégories multiples
  • contre:
    • nécessite un système ergonomique pour attribuer la catégorie sinon le contributeur potentiel ne pourra pas trouver facilement la bonne du fait de la ramification potentiellement importante
• Pages de même nom dans des catégories distinctes
  • pour:
    • très utile pour la réalisation d'une documentation:
      • permet de réaliser des pages différentes pour documenter la même chose mais en ciblant différents types d'utilisateurs ("normaux", développeurs, administrateurs...)
      • permet de maintenir une documentation concernant plusieurs versions d'un logiciel (ex.: sur WikiNiPointNet on voudrait avoir une documentation pour les version 0.4.x, 0.5.y et ainsi de suite)
    • résoud a priori le problème des ambiguïtés (fréquent sur WikiPedia: "bug" en tant qu'insecte ou en tant qu'anomalie informatique ? solution: Insects > Bug, Software > Bug etc.)
    • moins contraignant (on ne doit pas chercher un nouveau nom car telle page existe déjà dans telle autre catégorie)
    • permet de contourner l'absence (éventuelle) de catégories multiples "formelles" (c.-à-d. gérées en interne par le moteur): il suffit de placer une redirection ! (ex.: FAQ > FAQ Installation redirige vers Installation > FAQ Installation)
  • contre:
    • nécessite d'avoir une indication de la catégorie dans l'URL de la page. Une solution consiste simplement à utiliser comme valeur wiki=Categorie.NomDePage?
    • risque de création de plusieurs pages sur un même sujet, selon que l'un considère que ce sujet doit être dans une catégorie alors qu'un autre considère que cela doit être dans une autre
      • ceci relève plutôt de la discipline dans le choix des noms/catégories, à mon sens, et peut de toute façon être corrigé par après en plaçant une redirection. -- LordFarquaad
        • pas si évident : si je comprends bien, on risque de toute façon (indirection ou non), de créer des pages multiples sur le meme thème ! Or il suffit de voir le bourgeonnement -qui fait la richesse, mais aussi le labyrinthe- de ce Wiki pour penser a eviter ! Je reste sur mon idée de l'an dernier = utiliser les mots clés, ce qui permettrait aussi de proposer facilement un memnu pop-up de navigation transversale par MotsCles??, un peu de façon analogue au ActionTrail ou au MenuGauche?? : reste juste à l'intégrer en complement dans le Header (après le lien de RechercheTexte du titre par exemple... --JdX?
• Toute page doit appartenir à au moins une catégorie
  • pour:
    • force à classer les pages
  • contre:
    • risque élevé d'apparition d'une catégorie "foure-tout" ce qui permet de contourner l'objectif
    • risque de problème de compatibilité avec les versions antérieures de WikiNi (que faire des pages existantes lors d'une mise à jour ?)
    • contraignant pour ceux qui ne souhaitent pas utiliser cette fonctionnalité
      • on peut aussi décider qu'il y a une catégorie par défaut : à classer ! et laisser faire ceux qui connaissent le classement.
        • ça ou ne pas appartenir à une catégorie revient au même, il me semble... -- LordFarquaad
• Une page de description pour chaque catégorie
  • pour:
    • permet de réaliser une description libre en profitant de toutes les fonctionnalités offertes par WikiNi
  • contre:
    • ...
  • remarque: cette page doit-elle obligatoirement exister ?
    • pour:
      • assure qu'il y aura toujours une description de la catégorie
      • assure de pouvoir naviguer dans l'arbre ou le graphe du site
    • contre:
      • légèrement contraignant (message du type: "Vous ne pouvez créer la page Categorie.NomDePage? car la page "Categorie" n'existe pas. Créez d'abord cette page.")
        • on peut créer les pages de catégorie à la volée avec un texte standard du type catégorie non renseignée
• Choix de la catégorie lors de l'édition
  • pour:
    • très ergonomique, rend cette fonctionnalité bien visible
  • contre:
    • un grand nombre de catégories risque de perturber le rédacteur (choix difficile) alors que son objectif premier reste de rédiger son texte...
      • c'est là effectivement qu'il faut par défaut une catégorie à classer, mais ça ne résoud pas la suite...
    • incompatibilité avec la présence de la catégorie dans l'URL de la page: le choix de la catégorie modifie l'URL alors qu'elle est déjà "imposée"
    • incompatibilité avec la possibilité de créer deux pages du même nom dans des catégories différentes
      • risque de conflit(s) (deux pages du même nom dans la même catégorie)
      • les liens entre pages doivent indiquer la catégorie pour éviter tout ambiguïté (ex.: Categorie.NomDePage) ce qui impose a priori la catégorie d'une page nouvellement créée (et ne permet pas non plus de le changer par après).
• Affichage de la liste des catégories de la page
  • pour
    • très ergonomique, permet de savoir immédiatement "où on se trouve" et de naviguer vers les autres pages de ces mêmes catégories
  • contre
    • ...
• Affichage de la position dans l'arborescence
• (affichage de la liste des catégories/sous-catégories permettant de tracer le chemin jusqu'à la catégorie "racine", par exemple: La Documentation > WikiNi 0.5.0 > Utilisateurs > Actions > ActionListPages, avec des liens vers chacune des pages de description)
  • pour
    • très ergonomique, permet de remonter facilement dans l'arborescence (se rapproche de l'affichage de la liste des catégories)
  • contre
    • risque de surcharge d'informations en combinaison avec les catégories multiples: appartenance à plusieurs catégories "racine", nécessitant donc plusieurs listes à afficher
      • on peut peut être introduire la notion de catégorie primaire et n'afficher que celle-là dans ce cas
  • requiert
    • Sous-catégories
• Changement de catégorie
• (possibilité de changer la ou les catégories d'une page)
  • pour:
    • permet de corriger un mauvais choix (tout comme RenommerUnePage)
    • paraît assez évident lorsqu'on permet les catégories multiples (il faut pouvoir lier une page à de nouvelles catégories a posteriori)
  • contre:
    • incompatible avec un identifiant de catégorie dans les liens car cela implique un changement du lien à utiliser (ex.: Categorie.NomDePage devient NouvelleCategorie.NomDePage)
    • incompatible avec un identifiant de catégorie dans l'url car cela implique un changement d'url
      • peut-être réalisé tout de même via une redirection, de la même manière que pour RenommerUnePage
• Héritage des droits
• (une page d'une catégorie hérite des droits de la page de description de la catégorie)
  • pour:
    • gestion avancée des droits permettant aux utilisateurs de créer et d'éditer (etc.) les pages de certaines catégories mais pas d'autres
  • contre:
    • gestion complexe des droits avec un risque d'erreurs élevé ("pourquoi telle page a tels droits ? ah oui elle a hérité de ceux de la page "Categorie" ! Eh mais c'est pas les mêmes ! Ah oui c'est juste, ils ont changé entretemps...")
      • sauf si les droits des pages sont strictement identiques à ceux de la catégorie, au moins lors du changement des droits de la catégorie ?
    • incompatible avec les catégories multiples (plusieurs parents = conflits dans les droits hérités)
      • à moins d'une catégorie primaire ?
  • prérequis:
    • page de description obligatoire pour chaque catégorie
• Style et catégories
• (possibilité de définir un style particulier utilisé uniquement pour une certaine catégorie)
  • pour:
    • permet de différencier visuellement le type (la catégorie) de la page affichée, fournissant ainsi une indication à l'utilisateur sur le type et la qualité du contenu, le public ciblé etc.
  • contre:
    • incompatible avec les catégories multiples (quel style adopter dans ce cas ? ou alors il faut imposer qu'il n'y ait pas de conflits entre les styles, sinon le dernier chargé surpassera les autres...)
      • là aussi il faut une catégorie principale
    • utilité non avérée pour l'instant, plutôt une idée lancée comme ça... - mais cela peut tout à fait être prévu et implémenté par après, cela n'a pas d'influence sur le fonctionnement des catégories
• Toute page définit une catégorie
• (chaque page devient une catégorie à partir du moment où on crée une sous-page reliée à celle-ci)
  • pour:
    • permet de simplifier la création des catégories (il suffit de créer la page de description et ensuite on n'a plus qu'à faire des sous-pages)
    • permet de simplifier la gestion des catégories (pas de distinction entre pages normales et pages de description de catégories)
  • contre:
    • permet à n'importe qui de créer des catégories ou de transformer une simple page en une catégories (ce qui revient au même dans cette optique), mais cela va assez dans le respect des principes des WiKi...
      • la gestion des droits pourrait permettre de régler ça (par exemple: droit de créer une page: "*", droit de créer une sous-page: "@admins") - va de paire avec l'héritage des droits

Je pense que les choses sont suffisemment avancées et stables que pour organiser un vote sur les fonctionnalités. -- LordFarquaad

Choix de la catégorie d'une page
On pourrait simplement ajouter une zone de sélection de la catégorie avant la zone de saisie du texte wiki. Par défaut la page serait dans la catégorie Non classé. Le rédacteur aurait la possibilité de choisir une autre catégorie parmi celles existantes, ou d'en créer une. L'idéal serait que, lorsqu'on choisit une catégorie, on ait la possibilité d'afficher sa description. La page d'édition d'une page commencerait donc par un nouveau bloc de sélection de catégorie qui pourrait se construire ainsi :

• un texte Catégorie de la page
• une liste déroulante avec toutes les catégories et sous-catégories bien rangées
• un bouton ou un lien pour afficher la description de la catégorie sélectionnée (fenêtre popup ?)
• une case à cocher Créer une nouvelle catégorie
  • un bouton radio dans cette catégorie
  • un autre bouton radio comme catégorie principale
  • un champ de texte pour le nom de la nouvelle catégorie

Côté droits de création, il faut pouvoir inhiber le droit de créer des catégories principales ou n'importe quelle catégorie, pour certains utilisateurs ou pour tous (hors administrateurs bien sûr).

Remarque : ceci ne permet pas d'attribuer plusieurs catégories à une seule page. Pour ce faire, il faudrait un système plus complexe où un bouton Ajouter à cette catégorie permettrait d'attribuer à la page la catégorie affichée dans la liste. La liste des catégories déjà attribuées apparaîtrait dans une liste à côté et on pourrait enlever une catégorie en cliquant sur un bouton Retirer de cette catégorie. Ça complique notablement l'interface, mais on peut peut-être imaginer un mode d'édition avancé pour cela. Les discussions montrent par ailleurs que les catégories multiples compliquent aussi l'implémentation dans le moteur Wikini.

Il peut être intéressant d'intégrer le nom de la catégorie dans le nom de la page, autorisant ainsi le même nom de page dans chaque catégorie. Bien sûr cela pose alors le problème (technique) du changement de catégorie impliquant un renommage de la page. Parmi les moteurs évoqués précédemment, seul Mediawiki propose quelque chose dans ce sens, mais par le biais d'espaces de noms et non des catégories.

Descriptif de la catégorie
Le mieux est d'avoir une page portant le nom de la catégorie (éventuellement avec un préfixe ou suffixe) qui, à la manière de MediaWiki? :

• est éditable comme toute autre page
• rassemble automatiquement le sommaire de toutes les sous-catégories immédiatement contenues dedans (niveau +1)
• rassemble automatiquement le sommaire de toutes les pages de cette catégorie

Le texte de cette page servirait à aider dans le choix de la catégorie (voir le paragraphe précédent). Elle pourrait éventuellement être créée dès l'ajout d'une nouvelle catégorie avec un texte par défaut Editez cette page pour décrire cette catégorie par exemple.

Visibilité des catégories
La solution menu des catégories dans la barre latérale semble la plus naturelle. Cela permet d'avoir immédiatement une visibilité globale sur le contenu du site. Par ailleurs, chaque page doit clairement revendiquer son appartenance à une ou plusieurs (sous-)catégorie(s). Éventuellement une page spéciale représenterait l'organisation de toutes les catégories, mais ceci pose des problèmes dans l'éventualité de sous-catégories appartenant à plusieurs catégories parentes (par exemple la catégorie FAQ installation pourrait appartenir à la catégorie FAQ mais aussi à la catégorie Installation).

Style et catégories
Pour étendre la portée des catégories, il peut être intéressant d'affecter un style graphique à une catégorie. Imaginons un site qui souhaite introduire quelques catégories principales des pages : Documentation, Téléchargement, Extensions, FAQ, Support, Wiki, Développement. Pour ne pas que l'utilisateur se méprenne sur le contenu de la partie Wiki (il ne s'agit pas d'informations officielles mais de discussions), il serait intéressant de différencier visuellement les pages de cette catégorie. De même la partie documentation peut avoir un look plus bouquin.

Techniquement, il suffirait que chaque catégorie principale donne lieu à l'ajout d'une classe au tag BODY de la page. Le nom de la classe pourrait être déduit du nom de catégorie, ou simplement un code comme category1. Quelques styles CSS supplémentaires permettraient alors d'adapter l'allure de la page à la section du site.

Droits et catégories
Il peut être intéressant d'associer des droits particuliers à chaque catégorie. Par exemple une catégorie réservée à la présentation du site et de son contenu verrait ses pages systématiquement modifiables par les administrateurs uniquement.

Page de discussion et catégories
Comme évoqué sur la page OrganiserLesDiscussions, il semble que les catégories permettent aussi d'introduire simplement des pages de discussion comme celles que l'on trouve dans MediaWiki?. Celles-ci ne viendraient pas en remplacement des commentaires mais serviraient à éviter de "polluer" la page avec des discussions.

Résumé des discussions

Les catégories ont une fonction similaire à un système de classes basé sur des mots-clefs : extraire les sujets principaux des pages du site. La principale nuance est que les catégories sont faites a priori alors les classes sont réalisées a posteriori. Ainsi les catégories reflètent une volonté des administrateurs du site - un menu de navigation - alors que les classes reflètent le travail des contributeurs du site. Éventuellement les classes pourraient être modifiées selon les préférences de l'utilisateur, sur sa demande ou par des statistiques sur les pages consultées. On peut aussi imaginer que les administrateurs restreignent les classes en spécifiant des mots-clefs : ceci devrait permettre de générer un menu des pages fixe notamment.

D'un point de vue technique, les mots-clefs ne nécessitent pas d'adaption du moteur Wikini même car ils sont extraits du contenu des pages par un algorithme à définir - il en existe. Au contraire les catégories nécessitent d'introduire dans le moteur de quoi lier les pages à des catégories. On peut cependant proposer une solution intermédiaire pour les catégories sur la base de l'extension ActionTrail et d'un menu de barre latérale éditable (par l'extension ActionInclude ?) en attendant de mûrir le problème de l'implémentation des catégories.

Discussions

• Bonjour, bravo pour ce premier jet de synthèse,
  • Effectivement la notion de Catégorie est souvent mise en exergue, mais comme je l'indiquais pas ailleurs, elle reste strictement hiérarchique : je crois qu'une notion de mot-cles serait plus ouverte..... -JdX? (je reviendrai sur le sujet de facon plus construite)
    • Mon avis est très similaire à celui de JdX?: à mon sens les catégories doivent permettre une représentation en arbre du site, ce qui permet facilement de naviguer dans le site par "montée" ou "descente" dans l'arbre. Les catégories multiples vont ÀMHA à l'encontre de la simplicité recherchée, en représentant le site comme un graphe acyclique orienté (je parle ici bien sûr au niveau de l'organisation des pages et non des liens entre celles-ci, qui forment toujours un graphe orienté). Les catégories multiples ne présentent donc à mon sens pas d'intérêt en première approche, mais pourraient être introduites par la suite si cela s'avère nécessaire.
    • Je vois d'ailleurs plusieurs façons de gérer les catégories multiples:
      • soit toutes les catégories d'une page ont un rôle équivalent
      • soit ce n'est pas le cas, avec (par exemple) une catégorie principale et éventuellement plusieurs catégories secondaires (ce qui permet de maintenir une structure en arbre - et simplifierait sans doute l'introduction des catégories multiples puisqu'il serait inutile de retoucher au travail sur les catégories simples)
    • Pour finir, je pense qu'avant d'envisager des catégories multiples il serait intéressant d'envisager un système de mots-clés, comme le suggère JdX?. J'attends d'ailleurs de voir ce qu'il proposera en la matière car je vois deux façon de les envisager:
      • soit comme un critère de recherche, créé à la volée lors de l'édition d'une page (par exemple avec une action spéciale) et servant à améliorer le résultat des recheches
      • soit comme une véritable méthode de classement, comme les catégories multiples - et donc à utiliser avec parsimonie pour éviter que l'utilisateur se retrouve au milieu d'un amas de choix pour s'orienter. Mais n'est-ce pas ce que l'on fait en jouant sur l'ActionBackLinks avec des pages telles que LordFarquaadASuivre (je place discrètement mon lien ;-) ), PageASupprimer, AIntegrerAuCVS ou encore AFaire ?
    • - LordFarquaad
• À vrai dire je pense aussi que les catégories multiples ne sont pas adaptées à un classement complexe, parce qu'elles enferment les pages dans une structure figée qui ne va pas répondre à tous les cas (ou alors il faudrait avoir écrit tout le wiki avant d'introduire les catégories...). Mais ça peut aider dans certains cas, notamment mon exemple de la FAQ ne me paraît pas du tout superflu. Et effectivement il faudrait réfléchir à la pertinence d'une catégorie primaire, ce qui me paraît d'une valeur ajoutée assez faible à ce niveau du débat !
  • Je dois dire que je ne suis pas tout à fait d'accord avec ton exemple FAQ Installation: je trouve que créer des groupes FAQ et Installation ayant le même niveau dans l'arborescence serait un mauvais choix de par le fait que Installation est beaucoup plus spécifique que FAQ, et regrouper toutes les FAQ dans une même catégorie ne présenterait ÀMHA pas d'intérêt pour l'utilisateur (principalement au niveau de la navigation). C'est le genre de chose à laquelle je trouve qu'il serait préférable d'ajouter un mot-clef discret, qui permet éventuellement de faire une recherche sur l'ensemble des FAQ. -- LordFarquaad
    • Souvent les utilisateurs aiment bien accéder facilement aux informations qui leur semblent importantes. Dans le cas d'un portail d'un logiciel, l'installation et les FAQ sont pour moi 2 choses auxquelles ils peuvent vouloir accéder rapidement. Mais bon, ceci illustre bien que le classement dépend des personnes et qu'il s'agit là plus d'un problème de volonté des administrateurs du site (ce qu'ils veulent mettre en avant) que d'un problème de logique ou de cognitique ! Même dans le cas d'un wiki les catégories peuvent être utiles car elles permettent aux administrateurs d'orienter le site en mettant en avant des rubriques phares : on est moins tenté de digresser, notamment en entreprise. Encore une fois il me semble que catégories et mots-clefs ne servent pas le même dessein, ça vaudrait peut-être le coup de faire une page où on exprime tout ce qu'on voit derrière les mots-clefs, un peu à la manière de cette page pour les catégories. Elle existe peut-être déjà ? -- JmPhilippe
      • Je voudrais ajouter que mon commentaire au sujet de ton exemple avait entre-autre pour but (que j'ai oublié de préciser) de montrer que "quand on veut, on peut": il y a toujours moyen de décider dans quelle catégorie une page doit tomber, il faut juste se donner un critère et le respecter. (Par exemple: "on classe toutes les pages par thème [ex.: Installation] et ensuite par type [ex.: FAQ]"). Ceci permet en principe de déterminer une catégorie principale, et ensuite on peut éventuellement ajouter des catégories secondaires ou des mots clefs: l'important est de donner le moyen à l'utilisateur d'accéder à la page en question, en utilisant éventuellement ces outils. -- LordFarquaad

• Par contre tu fais bien de souligner que l'intérêt des catégories est la navigation car c'est justement l'application la plus concrète qui en résulte : le menu dans la barre latérale. Donc effectivement des mots-clefs seraient plus pertinents pour classer, le problème est que personne ne va jamais les renseigner : il faut un système automatique - j'imagine que vous y pensez ;-). Cela dit les mots-clefs ne servent qu'à la recherche et, par moments, on se balade sans chercher quelque chose de particulier. C'est là que les catégories sont utiles en balisant le chemin, le malheur étant qu'il peut y avoir plusieurs chemins pour arriver au même point... En somme ce sont deux outils complémentaires.
• NB: j'ai ajouté un petit paragraphe Style et catégories qui m'est venu entre temps. -- JmPhilippe
  • Oui, il me semble que l'idée d'associer style particulier une page/un groupe de page n'est pas nouvelle en soi (il doit y avoir des contributions à ce sujet). Le problème à mes yeux serait d'intégrer cela avec un choix de thème par l'utilisateur (ie.: la possibilité d'utiliser plusieurs thèmes): on risque de rebasculer dans le problème des templates puisque pour chaque groupe de page il faudrait définir dans chaque thème la classe de style qu'on veut y associer. -- LordFarquaad PS.: mais ne serait-on pas en train de basculer vers le côté implémentation ?
    • Effectivement ça pourrait poser problème pour ce genre de fonctionnalité même si l'idée n'était pas de faire N styles totalement différents mais plutôt une petite variation du genre on change un logo ou une couleur. Dans ce cas il faudrait l'écrire en gros pour ceux qui seraient tentés d'exploiter cette fonctionnalité. -- JmPhilippe

• Un autre point qui n'est pas discuté dans cette page et qui à mon sens devrait l'être (même si cela frôle de l'implémentation) est le choix des URLs à donner à une page appartenant à un groupe. Je trouve que la solution proposée dans GestionDeGroupeDePages est assez bonne (le "chemin" vers la page apparaissant complètement dans l'URL) puisqu'elle permet de distinguer deux pages ayant le même nom mais situés dans des groupes différents. Par contre cette solution impose un groupe fixe (qu'on ne peut changer) pour une page puisque son groupe est intégré à son adresse (en principe une page ne devrait jamais changer d'adresse...) et pose un problème si une page doit appartenir à plusieurs groupes (il faut éviter qu'une même page ait plusieurs adresses, que ce soit pour les moteurs de recherche ou pour les utilisateurs). Par contre si on ne fait pas comme cela, il est exclu que deux pages situées dans des groupes différents aient le même nom (puisqu'elles auraient la même adresse). Avez-vous d'autres idées à ce sujet ? Il me semble que ce point renforce l'idée de ne pas proposer de catégories multiples à moins d'utiliser le principe de catégorie principale... -- LordFarquaad
  • Tu as raison, cela incite plutôt à faire l'impasse sur les catégories multiples, au moins dans un premier temps. Par contre le problème du codage des catégories est important car c'est pratique de pouvoir utiliser le même nom de page dans des catégories différentes (ce qui est impossible dans MediaWiki?), par exemple si tu fais de la documentation sur différentes versions de logiciels ;-). La seule solution que je vois serait d'avoir une table de traduction : le nom interne de la page (dans mySQL) pourrait ne pas être le nom affiché dans l'URL et, dans ce cas, on ne pourrait pas accéder à la page par son nom interne pour éviter les noms multiples. Par contre ça complique énormément les choses pour les liens dans les autres pages parce qu'on fait référence à la page par le nom affiché et non le nom interne, donc en cas de changement de nom les liens ne sont plus valides... -- JmPhilippe
    • Il existe une autre solution qui est celle proposée dans la GestionDeGroupeDePages: permettre une décomposition du nom de la page en groupe / sous-groupe / ... (le séparateur proposé étant le point). Ceci donne à la fois un moyen visuel d'identifier les groupes (dans les URLs ou dans la page), un moyen pratique de créer des liens (il était proposé d'étendre la détection des MotsWiki à cette syntaxe) et un moyen technique de l'implémenter (on stocke le nom complet avec groupe / sous-groupe / ... dans la base de données, tout simplement - il faut juste prévoir des noms assez longs). Par ailleurs cette solution évite le proplème de correspondance nom interne/nom visible ainsi que celui des URLs distinctes. -- LordFarquaad
      • Sauf qu'on ne peut plus changer de catégorie après coup sans renommer la page, problème épineux en effet... -- JmPhilippe
        • Oui, à mes yeux catégorie mal choisie ou nom de page mal choisi c'est la même chose: de toute façon il faudra changer l'URL (et les liens qui se rapportent à cette page) mais on peut placer l'ActionRedirect pour que ce soit transparent. Donc ça ne me semble pas poser de problème s'il faut renommer la page pour le faire, et j'y vois même trois avantages:
          • cela incite les utilisateurs a bien choisir les noms et catégories des pages pour éviter les renommages
          • cela fait prendre conscience à l'utilisateur de l'importance de son acte (changer une URL ayant un impact sur les moteurs de recherches, les favoris etc.)
          • on conserve une relation simple (j'ai envie de dire "bijective" - si je ne me trompe pas de mot) entre le nom de la page et son URL. Connaissant le nom, on trouve immédiatement l'adresse (et vice versa). C'est particulièrement pratique lorsqu'on utilise des logiciels (tels que Mozilla Firefox) qui permettent de définir des mots-clés pour accéder directement à une page (je tappe "wikini DerniersChangements" et j'accède directement à la page que je veux)
        • Donc pour moi c'est une solution qui paraît tout à fait bonne, surtout qu'elle est très simple à mettre en oeuvre (à la base il suffit d'accepter les points dans les URLs). Ensuite rien n'empêche de proposer des outils pour faciliter le renommage des pages, les changements de catégories etc. (ce qui peut par ailleurs faire tomber les deux premiers avantages - ceux-ci pouvant parfois être vus comme des inconvéniants) -- LordFarquaad

• Désolé de n'avoir pas vraiment de solution, mais voici quelques éléments à l'emporte-pièce : d'une part les mots-clés offrent une facilité de navigation croisée, qui peut mieux s'exprimer par un menu de liens choisis (par exemple un critère de co-pertinence cumulée sur les memes mots-clés, et presence dans le texte), et je pense d'autre part que la gestion "catégories" au sens hierarchique pourrait faciement s'introduire par un menu principal a gauche, pointant ensuite sur des pages de liens ActionTrail (haut ET bas distincts) : ceci donne une très large souplesse d'organisation et de mise-à-jour, meme si elle relève (comme le précedent, les mots-clés) d'une initiation créée par le concepteur du site WikiNi. La vraie question : est-ce que les catégories, pour exister dans la navigation du Wiki, doivent avoir un statut programmé particulier : je ne pense pas ! Ce n'est qu'une organisation de "syntaxe utilisateur" plaquée en externe, d'une part sur les noms des pages (un prefixe commun, par exemple), et d'autre part sur les points d'entrée (outils syntaxiques de recherche de pages par un radical = préfixe ci-dessus), eventuellement complétés par un "titre de contenu" de la page (cf. une discussion sur la balise TITLE ) et l'usage intelligent des menus trail (une merveille, cet outil !).
• Reste alors a programmer : l'insertion de menus principaux par un Include dans le wakka-config, et la mise-à-jour en background automatique (tout a fait JmPhilippe je n'y avais pas revé) des occurences de mots clés, qui sont eux choisis explicitement, pour rapporter des liens en plus du menu d'appartenance....
  • L'avantage des mots-clefs est que l'on peut imaginer ensuite adapter le menu à l'utilisateur. D'abord sur son initiative (il indique ses mots-clefs), ensuite de manière automatique, par statistiques sur les mots-clefs des pages qu'il visualise. Les mots-clefs sont donc plus centrés sur les contributeurs et les utilisateurs, ce qui est très louable bien sûr ! Si je comprends bien, d'un point de vue implémentation, il est plus aisé de commencer par les mots-clefs que les catégories car il n'y a pas besoin d'ajouter d'information pour extraire les mots-clefs. Au contraire les catégories peuvent nécessiter des adaptations non négligeables du moteur de Wikini ? -- JmPhilippe
    • Je pense que pour ce qui est des mots-clés il n'y a pas de modification profonde à faire (s'il y a lieu de faire des modifications...) car on peut se baser sur la table des triplets et tout ce qui est implémenté sans tenir compte des mots-clés continuera de fonctionner (il n'en tiendront simplement pas compte...). Pour ce qui est des catégories par contre c'est une autre affaire car c'est ce qui permet d'identifier les pages: si une méthode ou un module est hard-codé pour un format de nom, il risque de poser problème. À ma connaissance ce n'est jamais le cas dans le package WikiNi officiel (et la version CVS), et l'implémentation (fonctionnelle bien que pas très propre) de VirtualDust? dans GestionDeGroupeDePages tend à prouver que cela ne pose pas de problème. -- LordFarquaad

J'aimerais rajouter un besoin à prendre en compte ! Un Wiki, c'est un super-concept, meme pour un SPIPien ; il suffit de voir les reactions de quelques utilisateurs auxquels je fais decouvrir ces deux concepts collaboratifs ! Mais comment voulez-vous l'intégrer à tout autre espace Internet, sans menu, et sans pouvoir revoir le design de la page : meme MediaWiki? est plus facile à intégrer.... ;-( -- JdX?

• Si par revoir le design de la page tu entends modifier la mise en page, on touche là au problème des templates. Sur ce sujet, il se trouve qu'en travaillant sur les MaquettesStyleWikiniParDefaut?, j'ai fait une preuve de concept que j'ai placée sur mon site. Elle montre que la mise en page peut être très largement modifiée sans aucun template. Du coup j'ai récemment développé tout un argumentaire sur mon blog : Template or not template?. -- JmPhilippe
  • Concernant le "Design" j'enetendais plutot l'organisation de navigation induite par les divers bandeaux et menus potentiels ! après un peu d'absence, je revenais en lisant FaireLeMenagePropositions : j'y retrouve ce dont je suis de plus en plus convaincu avec l'experience en cours : Wikini standard rompt trop avec les ergonomies courantes pour rendre familier et facile l'integration sans bcp d'effort des participants !

Il faut, d'une part avoir un menu latéral gauche (voir la Contrib ...) et d'autre part obtenir une ActionRecherche?? sur plusieurs mots (et au lieu de ou) ; enfin, je reçois bcp de remarques sur la complexité de la syntaxe (comme pour SPIP ;-) ) => proposer un ACEditor ou equivalent ! Après quoi, les mots-clés par triplet (et Action inconnue "ActionMotCle?" pour les inclure), enfin un peu de reorganisation avec les facilités de { {trail toc=}} voir les ActionInclure?? et l'utilisation deviendrait courante ! Il ne manque plus que la actionAttach souvent réclamé ! Un dernier point : ces pages a rallonges sont inutilisables en edition => induire une edition par blocs comme Wikipedia and co.... --JdX?

Discussion des problèmes liés au choix de la catégorie lors de l'édition
Les 2 derniers points sont résolus si le choix de la catégorie se fait à la création de la page par une interface n'existant pas actuellement -- JmPhilippe

• je ne comprends pas bien cette remarque, c'est justement dans le cas précis d'une telle interface que ces points son problématiques... -- LordFarquaad
  • j'avais oublié qu'on peut mettre des références à des pages inexistantes car l'idée était de passer exclusivement par une page de création de page avant de faire référence à la page; mais on peut imaginer que Wikini, au moment où il enregistre la 1ère fois la page, s'arrange pour que les références à cette page jusqu'alors inexistante utilisent le bon nom (je sais ce n'est pas super simple comme système...) -- JmPhilippe
    • En pratique le seul moyen simple (pour un utilisateur non-avancé) de créer une nouvelle page est d'abord de mettre un lien vers cette page puis de la créer. C'est d'ailleurs ce qui est recommandé pour éviter les PagesOrphelines. Je pense que ton idée n'est pas mauvaise mais elle pose cependant deux problèmes à mes yeux:
      • modifier toutes les pages à la volée semble une opération complexe, difficile à réaliser (en tout cas dans un premier temps)
      • comment savoir si une référence vers une page inexistante du même nom doit pointer sur la nouvelle page et pas une page de même nom dans une autre catégorie ?
        • -> une telle référence doit contenir aussi une référence vers la catégorie en question
          • -> ceci impose la catégorie de la page lorsqu'elle est créée (en supposant qu'on suit effectivement un lien, le cas de la modification d'URL ne m'intéresse pas pour l'instant) -- LordFarquaad
• Mmm, plus compliqué qu'il n'y paraissait au départ, je te propose de clore le débat et de le transférer dans la partie discussions de la page, pour mémoire. -- JmPhilippe
  • Voilà qui est fait, je n'ai pas altéré la conversation pour même si certaines choses peuvent paraître difficilement compréhensible hors-contexte. Pour rappel, il est à noter que cette conversation est une suite des remarques pour/contre de la fonctionnalité "Choix de la catégorie lors de l'édition". -- LordFarquaad

Je reviens sur ce problème du choix de la catégorie à l'édition. Pour résumer :

• soit l'URL de page ne contient pas de catégorie, alors tant que la page n'est pas créée, elle n'a pas de catégorie et, une fois créée et la catégorie attribuée, les références pré-existantes restent valides
• soit l'URL contient la catégorie (ou au moins la catégorie principale dans le cas de catégories multiples), dans ce cas il faut impérativement spécifier la catégorie dans une référence à une page inexistante sans quoi elle n'en aurait pas une fois créée ou alors, si on la spécifiait à la création, les références pré-existantes deviendraient caduques (je ne sais pas si c'est bien clair ;-) ) [ou elles risqueraient de ne pas pointer sur cette page -- LordFarquaad]

Le dernier point complique notablement la tâche de l'utilisateur novice qui, en plus d'avoir à apprendre comment créer une page, doit commencer par feuilleter les catégories. À moins que l'on ajoute une fonction dans le menu : Créer une nouvelle page. Ce serait d'ailleurs même peut être incontournable d'un point de vue ergonomique pour aider le débutant, indépendamment des groupes de pages. -- JmPhilippe

• Je ne suis pas tout à fait d'accord: jusqu'à présent, la "philosophie" en la matière a toujours consisté à dire qu'il fallait d'abord placer un lien vers la page à créer, et ensuite la créer, de sorte qu'elle ne soit pas une page orpheline. Je pense que conserver cette règle dans le cadre des catégories la renforcerait plus encore: bien souvent, la page à créer sera (à mon avis) une sous-page de la page où on veut placer un lien. De ce fait cette obligation faciliterait le choix de la catégorie, ce qui la rend donc d'autant plus utile. -- LordFarquaad PS.: merci d'avoir ramené à l'avant-plan l'idée des catégories principale/secondaires car elle me paraît vraiment intéressante et aurait été un oubli malheureux...
  • Effectivement c'est important d'avoir à la fois des pages qui ne sont pas isolées et qui sont spontanément classées. Dans ce cas on pourrait imaginer que le lien du menu soit plutôt Comment créer une page et ne mènerait qu'à la page d'aide décrivant cette opération. Ensuite, pour faciliter la création d'une page appartenant à la bonne classe, on pourrait faire une page d'aide qui serait un formulaire dans lequel on choisit la catégorie dans des listes, on entre le titre de la page dans un champ (en langage normal et non wiki), puis en postant le formulaire on obtient un nom de page du type Catégorie.SousCat?égorie.NomDePage? à utiliser dans une page existante. Un lien vers cette page serait placé systématiquement dans la page d'édition d'une page. Je sais que ce n'est pas fondamental mais il faut bien voir que de nombreuses personnes ne comprennent pas vite que le wiki peut s'éditer, alors autant les y aider... -- JmPhilippe
    • Oui, pourquoi pas, mais je pense que cela ne relève pas directement de la gestion de groupes de pages mais plutôt de l'ergonomie en générale. Il me semble d'ailleurs que des interfaces similaires ont déjà été proposées indépendemment des groupes de pages. Mieux vaut donc éviter de s'éloigner trop du sujet, cette interface pouvant de toute façon être créée par la suite. -- LordFarquaad
      • Bonjour a tous (desolé j'ai ete un peu distant/occupé/ ces derniers temps....et j'ai du mal a raccrocher ! ).
        • ajouter un bouton Action inconnue "CreatePage" dans le bandeau (lequel : haut ou bas ?) facilite les débutants OK ; le choix de la catégorie implicite serait hérité de la catégorie courante (avec une question pour valider, confirmer ou choisir une autre...) et l'action placerait automatiquement le lien en fin de page courante (avec une explication), ou demanderait de chercher la page d'accrochage cette REGLE me parait indispensable a conserver dans le Wiki .
          • Non. Une telle fonctionnalité n'est pas du tout requise, et nécessiterait aussi d'être discutée bien plus au préalable: il y a du pour et du contre, je l'ai encore dit récemment dans la RoadMapNouveauStyleWikiNi je crois. Jusqu'à présent on s'en passe très bien, et ceux qui la veulent quand même peuvent l'ajouter très facilement. -- LordFarquaad
        • je propose tout simplement de différer cette structuration GROUPE de PAGES explicitée dans les noms et structures, au profit d'une implémentation préalable des liens-mots-clés tels que je me souviens de l'avoir assez longuement discuté cet été, pour deux ensembles de raisons ! [il me semble que la seule discussion qu'on trouve sur WikiNiPointNet à ce sujet est celle présente sur cette page, qui me paraissait largement insuffisante pour se lancer dans quoi que ce soit... -- LordFarquaad]
          • + le "Groupe" induit une structure hiérarchique, inadaptée au foisonnement d'idées a la base du Wiki
            • Je ne suis pas du tout d'accord: la structure hiérarchique est exactement l'objectif recherché. Il est tout à fait adapté car le foisonnement d'idées à tendance à mettre du désordre dans toutes les pages, et la possibilité de structurer convenablement les choses est un atout primordial pour pouvoir s'y retrouver. WikiNiPointNet est sans doute un des principaux WiKis? basés sur WikiNi a avoir un énorme besoin d'une structuration et d'un hiérarchisation de ses pages (documentation...). -- Lordfarquaad
          • + le survol des idées/solutions avancées me fait craindre une grosse modification, lourde tant en termes d'interface d'usage que de programmation modifiée, alors que l'implémentation des mots-clés doit etre tres "superficielle" par rapport à l'existant, grace au travail lancé par LordFarquaad .... -> qu'en pensez-vous ?
            • Je n'ai encore lancé aucun travail au niveau des mots-clés, la seule chose que j'ai faite c'est la gestion des triplets qui pourrait effectivement servir de base (tout comme pour une implémentation des groupes de pages d'ailleurs). (il reste a definir une ergonomie : un bandeau/bouton annexe ? As-tu ouvert une page d'idées ? -- JdX? - Il y a une page VosSuggestions, accessible depuis la PagePrincipale. -- LordFarquaad) Il est impossible de dire si l'intégration des groupes de pages nécessiterait des modifications lourdes tant qu'on n'a pas choisi quelle solution est retenue (et le choix peut se faire en fonction de ça aussi...). Cf ErgonomieGroupeDePagesVoteFonctionnalites. La première solution envisage quelque chose de très simple et léger d'ailleurs. -- LordFarquaad ( La simple recherche que j'ai mené pour voir comment pouvoir integrer l'acceptation d'ancres nommées m'avait édifié ! --JdX? - Oui, je pense qu'il n'y a pas encore de proposition "propre" à ce sujet, et ce n'est d'ailleurs pas du tout intégré à WikiNi pour l'instant. -- LordFarquaad)
          • + N.B. la mise en oeuvre d'un Wiki est encore loin d'estre admise par les utilisateurs devenus "createurs de contenus" (du moins les 17 millions par rapport au 3 milions d'experts), surttout quand on veut l'utiliser en terme d'outil collaboratif, comme je le fais actuellement, pourtant avec un public de cadres ! ( Je ne vois pas trop ce que cette remarque apporte ? -- LordFarquaad ) J'explicite : de mon expérience, la notion voulue de "groupe de pages" ne doit absoluement pas compliquer la plus grande simplicité du Wikki ; or, à la lecture des idées plus haut, je crains une complexification de l'interface d'accès dans la création des pages..... -- JdX?
            • Les idées présentes dans cette page ne font que décrire un ensemble de fonctionnalités possibles. Certaines sont primaires tandis que d'autres sont tout à fait secondaires, c'est certain. Le but était d'étudier quelles sont les solutions possible, point de vue ergonomie, ce qui n'empêche pas d'envisager des choses compliquer et de les réfuter par la suite. La page ErgonomieGroupeDePagesVoteFonctionnalites vise à présent à retenir les fonctionnalités qu'on souhaite, et les solutions peuvent bien entendu jouer sur la simplicité. Si tu as des idées, n'hésite pas à proposer ta propre solution théorique dans cette page-là. Si tu as des idées de fonctionnalités manquantes, tu peux aussi les proposer ici. -- LordFarquaad
          • + AMHA ajouter "facilement" une version avec le paramétrage automatisable d'un menu-gauche serait un plus pour la diffusion/diversité d'usage du Wiki (la formule Wikipedia, bien que plus évoluée m'a paru plus lourde et confuse entre "menu de navigation/consultation" et "fonctionnalités d'enrichissement") c'est la résolution de ce conflit qui fera le veritable succes du Wikki -- JdX?
            • Je ne comprends pas ce que tu entends par "version" ? -- LordFarquaad
              • Bonjour, je suis "intoxiqué" par les plug-ins de SPIP ; en termes de version, je pense à, soit une version téléchargeable .zip pré-configurée modifiée pour avoir la présentation .css intégrant l'accès à une page "menu", soit à un outil tout prêt dans les ajouts ./contrib.... - JdX?
                • Je pense que ce que tu aimerais se rapproche assez du GestionnaireDeContribution et les GestionnaireExtension? (cf ContributionsWikiNi). -- LordFarquaad
        • la présence d'une gestion par mots-cléfs peut permettre des solutions plus souples pour resoudre certains des problèmes d'ergonomie ou de traitement des categories evoqués plus haut (je pense encore a SpiP?? ;-) dont beaucoup de fonctionnalités "accessoires" sont basées sur un usage particulier de mots-clés conventionnellement choisis) -- JdX?
          • Je pense que mots-clés et groupes de pages sont deux fonctionnalités distinctes (et éventuellement complémentaires). Je pense que baser les groupes de pages sur un système de mots-clés risque de s'avérer encore plus compliqué que toute autre solution, mais c'est juste mon idée. De toute façon, pour envisager une telle chose, il faudrait au préalable implémenter les mots-clés, et donc en discuter (ce qui ne peut se faire dans cette page, mais dans UsageMotsCles?). Apparemment tu as une idée assez précise de ce que devraient permettre les mots-clés, donc je te propose de créer une ou plusieurs pages à ce sujet. De même tu peux aussi faire une proposition de solution théorique basée sur des mots-clés pour la gestion de groupes de pages. (toujours dans ErgonomieGroupeDePagesVoteFonctionnalites) -- LordFarquaad

En "faisant le ménage" je suis tombé sur le rappel des possibilités de "inclure" : ne pourrait-on réactiver cette commande Action Table Of Contents qui devait -si j'avais bien compris- générer des liens internes sur la page grace aux titres

.. avec l'acceptation des Ancres (qui sait assez gerer les RegExp?? pour modifier le source ?) et ajouter peut-etre a ce moment une ActionDeGroup?? qui permettrait automatiquement de fragmenter une longue page en plusieurs sous-pages (générer les N enregs SQL correspondant) reliées par un TOC trail ajouté automatiquement en bas de page ? Solution automatique pour faciliter l'explosion combinatoire des ecritures multiples sur ces kilo-tonnes d'écrans defilants indigestes...... --JdX?
ActionsEnCoursDeDiscussion

---