HistoiresDeChoixWiki

Cette page a démarré sur WikiChoosingStories

Cette page est destinée aux histoires racontant les manières dont les personnes ont choisi leurs MoteursWiki à utiliser pour héberger leur wiki.

Si vous voulez une vue plus consensuelle sur la façon de choisir un wiki, ou si vous voulez une liste de wikis, voir ChoisirUnWiki.


BayleShanks : Quel logiciel utiliser pour mon site web ?

NOTE : Comme vous le constaterez, je n'ai pas encore amassé l'information dont j'ai besoin pour prendre ma décision. Je place cela ici au cas où des développeurs seraient intéressés sur les critères qui me traversent l'esprit pour choisir un MoteurWiki. Si cela ne vous intéresse pas, vous voudrez bien zapper ce billet.

Bien avant avoir découvert les wikis, je me suis demandé quelle famille de logiciel choisir pour mon site web personnel (on peut arguer qu'installer mon site personnel web n'est pas vraiment en ce qui me concerne une priorité).

A ce jour j'ai un site web "temporaire", mais quand je pense au contenu que je veux placer sur mon site web, je le colle par habitude simplement dans un fichier, parce que je ne veux pas avoir à tout migrer dessus une fois choisi mon "vrai" logiciel de site web. Probablement, ce qui se passe est que je prolongerai la WikiPasserelle durant cette période, et implémenterai une translation de balisage UseMod<-->MoinMoin, et implémenterai une fonction CopyEntireWiki?, avant de me décider ; à ce stade je déverserai tout mon contenu dans l'un ou l'autre (UseMod ou MoinMoin), chose plus sûre parce que peux changer d'avis à tout moment et laisser la WikiPasserelle déplacer le contenu, et puis switcher en arrière et en avant pendant plusieurs semaines jusqu'à ce que je sache enfin lequel je préfère vraiment.

Je suppose que je m'installerai probablement sur un wiki, bien que je veuille encore aller plonger dans la liste des autres choses que j'ai accumulées avant de découvrir les wikis.

Je n'ai pas totalement écarté d'autres familles de logiciels wiki, mais je sens que je m'installerai soit sur UseMod (ou, à ce jour OddMuse) ou MoinMoin

Le plus expansible

Un critère majeur est de choisir le logiciel qui soit le plus expansible. Je ne veux pas dire dans le sens WikiProgrammableParLaCommunauté mais plutôt dans le sens qu'il est programmé dans un sens où les nouvelles fonctionnalités peuvent/seront ajoutées. Bien sûr, le fait de déterminer cela est une prédiction/affaire de goût, plus qu'une question de fait.

Je ne me suis jamais retrouvé autour de quelque révision du code source de UseMod(/OddMuse) ou MoinMoin, et ce sera définitivement un grand facteur dans ma décision, de telle façon qu'on pourrait dire que je n'ai même pas commencé à démarrer quelque processus de prise décision entre les deux.

J'apprécie vraiment que MoinMoin soit doté de plugins (même si je n'ai jamais regardé le système de plugin pour voir combien il peut être facile de les installer ou de les écrire, et juger de leur puissance). Sur le weblog de LionKimbro, j'ai vu un lien vers un plugin d'affichage de graphe pour MoinMoin, qui me confirme bien la dimension vraiment cool de ces plugins). Dans UseMod, si vous voulez ajouter du support LaTeX (et sur à peu près la moitié des wikis que j'ai mis en place, j'ai finalement besoin de LaTeX), vous avez besoin de patcher le code source. Pas cool. Un point pour MoinMoin.

Aussi, ai-je entendu que Python est ce langage puissant et qu'il fait toutes ces choses agréables de programmation fonctionnelle orientée-objet. Je ne connais pas Python, aussi je ne peux confirmer. Mais maintenant que j'ai désormais écrit une petite librairie orientée-objet en Perl, je vois ce que les personnes ont pu rencontrer comme problèmes avec OOP dans Perl. Cela fonctionne, je suppose, mais c'est si difficile à lire ; et c'est un tel hack que je ne peux pas imaginer que ce puisse être aussi puissant que OOP dans un langage conçu pour faire du OOP.

Aussi, je suppose que je devrais vraiment apprendre Python avant de prendre quelque décision :), simplement pour pouvoir vraiment décider si cela est mieux. Mais à ce stade, il semble que ce soit comme ça. Tout spécialement si vous voulez que le système soit vraiment expansible, et avoir beaucoup de plugins qui ajoutent des fonctionnalités et outrepassent les choses ; il semble que l'héritage comme OOP est un langage interprété et ce devrait être le moyen d'y parvenir.

Ainsi, une raison pour MoinMoin.

Mais qui sait, peut-être qu'une fois que je regarderai le code de MoinMoin, je déciderai de détester la façon dont ils l'ont structuré et je hais la manière dont fonctionnent les plugins et je ne voudrais pas écrire de plugins qui se collent à l'intérieur de cette structure.

Une autre raison est que ce soi-disant MoinMoin de même pour tous ces trucs comme les nouveaux standards XHTML et l'internationalisation, et soi-disant UseMod ne le font pas. Je ne sais pas mais apprécie vraiment de me soucier de ces détails (peut-être qu'OddMuse a déjà fait tout ça ; je ne le saurais pas), mais j'accepte que le logiciel wiki doive se conformer/s'arranger avec tout ça. Ainsi MoinMoin a une longueur d'avance s'il le fait et qu'OddMuse ne le fait pas.

Quelle est l'Interface Utilisateur que j'Aime Vraiment

Un autre critère majeur est quelle est l'interface la plus propre pour l'utilisateur. Je suis bon à l'intérieur d'interfaces utilisateurs propres, simples qui je pense ne sont pas confuses et qui j'imagine n'effrayeraient pas trop les nouveaux utilisateurs (étant moi-même un programmeur occasionnel, je peux seulement supposer ce qui est une interface effrayante pour la plupart des personnes ; mais si je suis effrayé ou confus, c'est probablement un mauvais signe. Twiki et Zope m'effrayent par exemple).

Trois choses m'ennuient à propos de l'Interface Utilisateur de MoinMoin

  1. Si vous éditez une page, la sauvegardez, puis pensez à une chose supplémentaire que vous voulez modifiez, vous devez cliquez à nouveau sur le bouton éditer et éditer à nouveau. Vous ne pouvez pas utiliser la flèche arrière, revenir au formulaire précédent, et produire votre modification et la sauvegarder à nouveau (cela enregistrera un ConflitÉdition -→ traduire EditConflict). Sur UseMod/OddMuse, vous pouvez faire cela. Un petit détail ; peut-être. Mais cela fait gagner un temps significatif si vous éditez beaucoup. Je doute que quelque ajout de prévisualiser-avant-sauvegerde m'aiderait vraiment à éviter cela.
  2. Je pense qu'elle est confuse. Beaucoup trop d'options à des endroits variés.
  3. Je n'aime pas la petite ligne d'icônes dans le coin en haut et à droite de chaque page pour faire des choses comme diff, etc. Je pense que cela embrouille les nouveaux utilisateurs. Je pense peut-être que vous pouvez les épancher vers le texte quelque part, mais alors c'est confus/intimidant.

Aussi, des petits détails qui ne semblent pas être aussi bien conçus que les choses sur UseMod/OddMuse. Les modifications à la style Tavi, par exemple, sont magnifiques. Cela prend deux clics (et un peu de scrolling, je crois) pour obtenir des Modifications Récentes de MoinMoin une historique de page où vous pouvez comparer une version produite il y a une semaine vers la version la plus récente ; sur UseMod/OddMuse, le lien des Modifications sur Modifications Récentes vous emmène là droit dedans.

Je pense que quoique la communauté des développeurs UseMod puisse être plus petite, elle a attiré en quelque sorte un groupe de personnes qui sont simplement compétentes pour produire des interfaces utilisateurs simples et concises.

Un point pour UseMod/OddMuse.

Exigence pour Database backend

J'aimerais pour mon site web personnel disposer d'un compte gracieux à faire tourner pour travailler un support technique dans un collège. De ce fait, je n'ai pas beaucoup de contrôles ou d'options dans l'environnement serveur. Je pourrais installer quelques modules Perl ou Python dans mon répertoire utilisateur, mais tout ce dont j'ai besoin n'a pas besoin d'être un daemon, comme une database mysql backend, hors de portée. Je ne pense pas que UseMod/OddMuse ou MoinMoin ait besoin de ça.

Effets Lock-in/gravitationnel

J'ai entendu que MoinMoin est si-oh-populaire et que leur communauté de développeurs est plus active/grande que celle de UseMod. Si c'est vrai, un point pour MoinMoin.

Fonctionnalités que j'aime

Maintenant, tout particulièrement avec OddMuse, la facette UseMod/OddMuse est en train d'obtenir toutes ces fonctionnalités très cools que j'adore, et qui, je pense, MoinMoin n'a pas encore à cette heure. Un point pour UseMod.

Mon affinité pour le code

Je n'ai pas regardé le code sur aucun des deux, ainsi je ne peux vraiment décider.

Je sais vraiment que quelques-unes des procédures dans UseMod sont quelque part encore confuses pour moi, au moins jusqu'à ce que je puisse consacrer du temps à les lires ligne-par-ligne. Je serais beaucoup plus à l'aise avec UseMod si c'était mieux commenté.

Je n'ai pas regardé le code OddMuse à cette heure. Mais je suis d'accord avec la philosophie d'Alex d'essayer de produire du code court, simple et clair. S'il applique cela à son code de la manière dont il le fait vers les wikis, je parie que j'aimerai beaucoup le code.

(pas de point délivré à cette heure, jusqu'à au moins ce que je parcoure le code de MoinMoin)

Choses spécifiques que j'aimerais dans le code :

Idée "Vague"

Il est difficile de dire de quelle façon cette chose se transformera jusqu'à ce que j'étudie le code plus en profondeur. Mais à cette heure, ce serait comme si je venais à préférer UseMod/OddMuse en termes de fonctionnalité, mais venais à préférer MoinMoin en termes de code (b/c de choix de langage + plugins, même si OddMuse peut finir en tête en étant plus court en longueur de code).

Dans ce cas, ce que j'aimerais vraiment faire est de prendre OddMuse et de le traduire exactement en Python. Puis le restructurer pour accpeter des plugins (si possible, même faire qu'il soit cross-compatible avec les plugins MoinMoin).

Bien sûr, ceci est infaisable pour un nombre de raisons ; je veux utiliser un wiki avec une plus grande communauté de développeurs ; je ne connais pas Python; je n'ai pas le temps de porter ou écrire ou maintenir un nouveau MoteurWiki.

BayleShanks

Addendum

Je n'avais pas réalisé que Jot était développé en Python. Ainsi Jot est maintenant aussi un combattant.

BayleShanks


Histoire d'EvanProdromou

Aussi pour le SonaUiki, j'ai utilisé le PmWiki, et je n'ai jamais regardé en arrière. Très beau, facile à utiliser, il dispose de grandes fonctionnalités extensibles (il existe un long Cookbook avec beaucoup d'extensions personnalisables, des trucs et astuces). J'aime aussi l'idée de savoir que je peux créer très rapidement une skin. C'est tout, simplement une suggestion.

Histoire de ParisCarnet LaurentGloaguen

Pour ParisCarnet c'est décidé… Après une longue période sur CraoWiki, puis sur FractalWiki, LaurentGloaguen semble enfin se décider de se lancer dans l'aventure d'un wiki autonome [1]. Après quelques suggestions, son choix dans l'InstantWiki semble encore hésiter entre MoinMoin et WackoWiki


Voir aussi ChoisirUnWiki.

PageTranslation LangueFrançaise WikiChoosingStories DossierWiki

Define external redirect: CopyEntireWiki

EditNearLinks: MoteursWiki FractalWiki MoteurWiki WackoWiki MoinMoin LaurentGloaguen LaTeX EditConflict DokuWiki UseMod CraoWiki ParisCarnet

Languages: