Fork me on GitHub

Comment ça se passe : « Pour faire un bon comparatif de modules »

200408
Décembre
  king76 Lettres d'informations 5650

Afin d'anticiper les remarques qui pourraient nous être faites en venant dire : « Pourquoi ne retrouve t'on pas de comparatifs plus régulièrement », j'ai eu envie de vous informer de la façon dont les comparatifs étaient réalisés.

Voici donc une recette afin de réaliser un «bon » comparatif, disons plutôt un comparatif qui sera vu comme bon par moi si vous me l'envoyez


1. Choisir le module à tester/comparer :
Il peut paraître assez simple de sélectionner un module afin d'en faire un comparatif, mais ce module doit avoir certaines caractéristiques, ainsi je pense qu'il doit :

– innover par rapport aux autres modules de sa catégorie, par exemple, proposer de nouvelles options qui n'existaient pas auparavant (SmartFaq, Xfguestbook..)
– avoir été bien traduit en français, pour pouvoir être utilisé par le plus grand nombre, cela semble logique, encore faut il dans certains cas reprendre la traduction pour la mettre à jour.
– recenser le moins de bugs possible, afin d'être opérationnel dès que le comparatif sort, le module ne « devrait » pas être en version béta ou release candidate, ce qui n'a pas été toujours le cas dans ceux de XM (XcGallery ou Soapbox par exemple)
– attirer l'attention du plus grand nombre, ce n'est pas toujours nécessaire de tester les meilleurs modules, on peut également en tester de moins connus, mais il est certes plus facile de réaliser un comparatif dont on est sur qu'il attirera les lecteurs (Icontent par exemple était assez connu avant d'être testé).
– être utile aux membres, tester un module qui ne va être utilisé que par une minorité, n'a pour moi aucun intérêt. Le module doit susciter l'intérêt du plus grand nombre de par ses fonctionnalités et sa prise en main.
– tout neuf, tout beau, vient juste de sortir des bacs
Le must c'est quand le module possède plusieurs des caractéristiques ci-dessus et qu'en plus de cela il vient de sortir et qu'il n'est pas encore trop connu, mais qu'on est certain qu'il va faire un carton. (Xcgallery lors de sa sortie n'était pas très connu, mais le comparatif a permis d'en savoir un petit peu plus sur lui)
– être un gagnant !
Dans le sens où dès qu'on veut le comparer à d'autres modules de la même catégorie, il faut être sur que ce sera le meilleur de tous !

Voici donc quelques caractéristiques pour qu'on prenne la peine de le tester, le nec plus ultra étant qu'il les posssède tous, mais ce n'est pas toujours le cas, ainsi ce sont de temps à autre des coups de coeur qui peuvent être testés (icontent ou edito par exemple). D'ailleurs à certaines périodes, il est assez difficile de faire son choix, tant les modules du moment sont tous aussi intéresssant les uns que les autres.

2.Rechercher les modules qui sont identiques :

Une fois que l'on est sur d'avoir trouvé la perle rare, il faut ensuite vérifier s'il existe d'autres modules qui peuvent être comparés avec lui. Ce n'est pas toujours aussi simple que çà, il faut parfois effectuer quelques recherches, télécharger et tester des modules que nous ne connaissons pas.
Je prend par exemple le module EDITO de Solo71. Je dirai qu'il a les caractéristiques suivantes :

– innovant avec son système de contenu lié au bloc
– peu connu, mais aurait le mérite de l'être.
– d'une grande utilité pour des sites « portails »
– un module 100% frenchy :)

Mais le problème avec ce module, c'est que du premier coup d'oeil on ne sait pas trop dans quelle catégorie le classer et surtout avec quelle module le tester. Surtout que dans la plupart des cas, lorsqu'un module est testé, il doit être le meilleur de sa catégorie, ce serait donc une erreur de classer un module dans n'importe quelle catégorie et dire : « allez hop on va le comparer au module de news de xoops », alors qu'il n'aurait aucune chance et que ce n'est peut être pas son but premier de gérer des articles postés par des membres. Dans ce genre de situation, la meilleure source pour détecter ce genre de chose est de voir directement avec l'auteur (la dans ce cas la, ce sont trois auteurs) ou de fouiner un petit peu sur les forums pour voir ce qu'il s'en dit.)

Si le module est assez ancien (rappelons qu'il est préférable toutefois de tester des modules qui viennent de sortir), l'on peut également se référer à la catégorisation que certains sites ont effectués (voir le repository de xoops.org ou celui notre référentiel).

Une fois que l'on est sur d'avoir la lise des modules que l'on veut comparer avec notre module en test, il faut s'assurer que cette liste ne soit pas trop grande, enfin disons qu'il faut croiser les doigts, car si l'on se met à comparer l'ensemble des wikis, forums ou dans le pire de cas, les galeries photos il faut s'attendre tout de suite d'un minimum de 5 modules.

3.Tester le module sous toutes ces coutures :

Voici sans doute la partie la plus intéressante du comparatif et aussi une des plus longues, puisqu'elle consiste à installer le module, à tester toutes les fonctionnalités (j'ai bien dit TOUTES), mais aussi à dénicher les bugs, corriger si possible et voir à reprendre certaines parties de la traduction ou la quasi totalité si celle ci n'est pas impeccable ou inexistantes. Comme vous pouvez vous en douter tout ce processus prend du temps et dans la plupart des cas il faut l'appliquer à l'ensemble des autres modules qui sont testés. Souvent le test consiste à créer des catégories, uploader des images, déposer du contenu, paramétrer les blocs, etc... Il faut souvent fouiner pour découvrir des options qui ne sont pas toujours évidentes, ce n'est donc pas en 5mn que l'on effectue cette tâche la, mais en plusieurs heures afin d'être sur de ne pas avoir raté quelque chose sinon le comparatif ne serait pas crédible.
D'ailleurs en cas de bugs (pour un nouveau module à peine sortit des bacs), si on en a la possibilité, il faut en référer à l'auteur et attendre les correctifs, dans d'autres cas, on le test sans toucher aux bugs et on le fait savoir dans le comparatif, la plupart du temps ils sont corrigés assez rapidement par l'auteur lorsqu'il prend connaissance du test (Vivi pour Icontent par exemple à été très réactif sur ce point).

4.Traduire le(s) module(s) :

Comme je le laissais entendre dans le précédent paragraphe, la traduction d'un ou de plusieurs modules est une des parties à prévoir dans le cas d'un comparatif bien fait. Souvent l'on a tendance à croire qu'il suffit de tester un module à moitié traduit ou en anglais tout simplement, de fournir les résultats et de penser qu'on a fait son job. Pour ma part, la finalité d'un comparatif c'est de pouvoir proposer aux membres la possibilité de télécharger l'ensemble des modules qui ont été comparés et comme nous sommes une communauté francophone il est tout à fait normal de fournir des modules 100% français. Et si en plus de tout çà, vous êtes perfectionniste, alors autant bien faire les choses. D'ailleurs si je pouvais faire un reproche aux membres qui se lancent dans la traduction, je leur dirai de bien vérifier leur traduction en testant le module dans tous les sens. Une traduction ne consiste pas à prendre un fichier remplit de DEFINE et de les traduire en français, cela ne remplit que 70% du travail. C'est d'ailleurs ces 30% là que lors d'un comparatif, je dois reprendre et corriger. Une traduction se fait dans un contexte particulier, ainsi si je dois prendre un exemple plus parlant une phrase tel que : « Article proposé par AUTEUR pour 12-04-2004 » est faux et c'est pourtant une erreur que l'on rencontre assez souvent, il est alors préférable de reprendre la traduction ce qui devient : « Article proposé par AUTEUR le 12-04-2004 ».

5.Commencer la rédaction du comparatif :

Une fois que vous avez testé votre module et que vous l'avez traduit, alors vous pouvez commencer à rédiger les premiers paragraphes de votre comparatif. Ces premières informations peuvent être :

– brêve description du module : à quoi il sert, voire même expliquer pourquoi avoir choisi ce module
– informations de base : nom du module, sa version, son auteur, des liens webs, ...
– l'ensemble de ses fonctionnalités : vu que vous avez pris la peine de tester le module de fond en comble, alors autant établir une liste de toutes ses fonctionnalités.

Voilà, les points principaux que vous pouvez rédiger, pour donner votre avis par contre, il vous faudra bien retester l'ensemble des autres modules afin de détecter les points forts et les points faibles de votre module par rapport à l'ensemble des autres modules.

6.Etablir un tableau comparatif :

Afin de mettre en avant les points forts et les points faibles de votre module il est impératif d'établir une liste ou un tableau si vous avez plusieurs modules à tester. Ce tableau doit présenter l'ensemble des modules que vous avez testé et à vous de faire en sorte que le module « vedette » soit mis en avant par une couleur particulière par exemple. Pour établir la lise des critères, voici quelques trucs :

a)commencer par explorer la partie administration de votre module et extraire toutes les options une à une.
b)examiner les options présentes dans les autres modules et les extraires aussi.
c)vous rendre sur la partie publique de votre module et examiner chacune des options disponibles
d)vous réferrez aux fichiers textes mis à votre disposition avec le module pour vérifier s'il existe des options que vous n'auriez pas trouvé par vous même.
e)vous pouvez egalement si vous avez les connaissances requises mettre en avant certains aspects techniques (template propre, création de classes, prise en compte du register_global etc..)
f)vous mettre dans la peau d'un utilisateur et mettre en avant les plus et les moins de chaque module
g)ne pas oublier d'installer et de vérifier la qualité des blocs

Si vous respectez toutes ces étapes, vous devriez obtenir un tableau assez complet et un aperçu assez clair des possibilités de votre module en test. Surtout ne pas oublier de mettre les liens pour le téléchargement et vers les liens « support ».

8.Donner votre avis sur le module :

Une fois que vous avez terminé votre tableau, vous devriez connaître sur le bout des doigts l'ensemble des modules du comparatif et pouvoir mener à bien la partie « Avis personnel » du module que vous testez. Cette partie consiste à mettre en avant les points forts du module, mais aussi les points faibles. Une fois que vous avez terminé de rédiger tout ces points, il est bon de les rappeler à la fin sous forme de liste pour résumer le tout. N'oubliez pas que ceci représente l'avis personnel du rédacteur, mais qu'il peut être judicieux aussi de demander à sa team son avis, afin que l'article renvoi l'image du site ou se trouve le comparatif. Ainsi ce n'est pas : « Je trouve ce module comme ci ou comme cela », mais « Nous avons trouvé que ce module manquait de .. »

9.Les captures d'écrans :

Le petit plus, c'est de faire des captures d'écrans du module que vous glisserez à la fin de l'article. La il n'y a pas vraiment de règle, en fonction de votre mise en page, vous pouvez aussi glisser ces captures d'écran à n'importe quel endroit du comparatif. Toutefois je vous conseille de respecter quelques règles à savoir :

– taille des captures d'écrans de 800x600 au maximum, même si votre site est prévu pour fonctionner en 1024x768
– poids des images réduites. Par exemple j'ai été très étonné de voir qu'une image au format GIF prennait moins de place et était plus lisible qu'une image au format JPG pourtant compressé (dans la partie admin par exemple, il y a très peu de couleurs à vrai dire et cela peut jouer).

Ces captures peuvent être essentiellement sur le module que vous tester, mais si vous n'en n'avez pas assez et si vous avez du temps, vous pouvez effectuer des captures sur les autres modules comparés.
L'autre point important réside dans le contenu de vos captures. Souvent lors de mes tests, je tape un peu n'importe quoi et les captures apparaissent avec du contenu qui n'est pas souvent intéressant et qui ne met d'ailleurs pas en avant les fonctionnalités du module. Dans ce cas, il est préférable d'aller faire ces captures d'écrans sur le site de l'auteur qui présente souvent un site démo (ce que j'aurais du faire pour SmartFaq par exemple

10.Mettre en ligne votre comparatif :

Une fois que vous avez effectué tous ces points la, vous devriez être prêt à mettre votre comparatif en ligne, toutefois si vous n'êtes pas un fortiche en orthographe ou en grammaire, vous devriez vous faire corriger l'ensemble de votre texte part une personne compétente (et qui a du temps aussi), ce qui n'est malheureusement jamais mon cas
Surtout n'hésitez pas à émettre des critiques sur un module, critique bien entendu constructive, si l'auteur est consciencieux il pourra prendre en considération vos remarques pour les mettre en place dans les prochaines versions.

Et enfin, si vous lisez des comparatifs sur Frxoops prochainement, n'hésitez pas à laisser des commentaires, ça fait toujours plaisir et ça motive celui qui passe du temps, car je ne l'ai pas dit clairement, mais pour réaliser un bon comparatif en prennant en compte les tests, les traductions et la rédaction, c'est souvent plusieurs heures de travail, ce qui dans la vie quotidienne d'un webmaster bénévole se concrétise en plusieurs jours.

Note: 8.00 (1 vote) - Noter cet article -

Partager Twitter Partagez cette article sur GG+
Format imprimable Envoyer cet article à un ami
Les commentaires appartiennent à leurs auteurs. Nous ne sommes pas responsables de leur contenu.
Propulsé avec XOOPS | Graphisme adapté par Tatane, Grosdunord, Montuy337513

18 Personne(s) en ligne (1 Personne(s) connectée(s) sur Articles) | Utilisateur(s): 0 | Invité(s): 18 | Plus ...