Xhoromag 4 - Présentation de la base de données et des critères appliqués aux AVH

[tholdur]

C'est clair qu'en ce qui concerne l'évaluation, la possibilité de donner des notes est pleine de désavantages: subjectivité, effet boule de neige des premières notes (les négatives d'entrée risquent "d'enterrer" des AVH: elles ne seront presque pas lues, donc peu d'espoir de "renverser la tendance" un jour...).
Mais je crois qu'il est incontournable de proposer quelque chose qui soit lisible immédiatement (par exemple des étoiles), en plus des critiques développées.
Pourquoi ne pas prévoir d'instaurer ultérieurement un système (intitulé par exemple "AVH sur le grill"), où tous les mois, chacun serait incité à lire et critiquer une de ces AVH "oubliées". Ainsi si certaines sont injustement tombées dans l'oubli, elles pourraient se voir offrir une nouvelle chance.
Plus il y aura d'AVH, plus il faudra pouvoir les différencier. Je pense qu'on peut déjà mettre des demi-points (ou demi-étoiles), et offrir un panel comprenant 0; 0,5; 1; 1,5; 2; 2,5; 3; 3,5; 4; 4,5; 5. Si on se limite à 0,1,2,3,4,5 je crains que cela ne soit pas suffisant.

Le défaut des notes tient surtout dans le fait que ce n'est jamais sympa de se voir attribuer une note moins bonne que le copain. Des feeds, même "négatifs", sont constructifs, avec tout ce qu'ils peuvent comporter comme aides, conseils et encouragement. C'est une dynamique intéressante, qui tire tout le monde vers le haut et donne à l'auteur envie de s'améliorer. Mais une note, ça restera un verdict sans appel, un jugement de valeur qui ne sera pas forcément facile à accepter. Il ne faut évidemment pas des notes seules, mais même accompagnées de critiques détaillées, elles vont introduire quelque chose de délicat à appréhender. Par exemple je ne pense pas que ce soit si évident de voir qu'on tourne autour de 2 ou 3 de "moyenne", alors que dans le même temps d'autres ne descendent pas en dessous de 4...
Il faut pourtant que chacun soit prêt à cette éventualité.

[Skarn]

Pourquoi ne pas prévoir d'instaurer ultérieurement un système (intitulé par exemple "AVH sur le grill"), où tous les mois, chacun serait incité à lire et critiquer une de ces AVH "oubliées". Ainsi si certaines sont injustement tombées dans l'oubli, elles pourraient se voir offrir une nouvelle chance.

Ce ne sera effectivement probablement pas pour la version 4.0, mais très bonne idée.

[Fitz]

Pour les notes, je suis également très tiède.

Concernant les évaluations, je préfère l'idée d'une appréciation collégiale ou par moyenne. Ce n'est pas toujours évident de s'auto-évaluer en tant qu'auteur, la perception peut être biaisée ou peu objective.
Peut-on essayer avec les 5 AVH qui ont servi de base au modèle de grille fait par Caïthness?

[Skarn]

Pour les notes, je suis également très tiède.

Concernant les évaluations, je préfère l'idée d'une appréciation collégiale ou par moyenne. Ce n'est pas toujours évident de s'auto-évaluer en tant qu'auteur, la perception peut être biaisée ou peu objective.
Peut-on essayer avec les 5 AVH qui ont servi de base au modèle de grille fait par Caïthness?

Tu peux toujours tenter. L'expérience demeure le meilleur moyen de valider une théorie.

[Alendir]

Bof pour les notes. Les Yaz, ça va de soit qu'ils seront mis en avant, mais pour les autres, ça me paraît irrelevant (faible nombre de votants, ne donne pas sa chance à toutes les AVH). A la rigueur, pour les non étoilés, on pourrait aussi se baser sur les résultats de Yaz, mais bon, l'AVH qui a terminé dernière risque d'être purement ignorée

[Fitz]

5 AVH ont été choisies un peu au hasard sur celles de l'année dernière pour servir de base-test aux nouvelles données de Xho 4.
Il s'agit de :

Le Château du Sorcier
La Pyramide de Gath
La Légende de Namin le Gnome
Le Métro du Cauchemar
Traque dans les Montagnes

3 critères pourraient être établis de manière collégiale (à savoir une moyenne des avis donnés par les lecteurs et l'auteur) : la difficulté, les règles et la linéarité selon les critères de la mouture établie par Caïthness soit :
Règles : sans, minimales, moyennes, avancées, complexes
Linéarité : restreinte, moyenne, libre
Difficulté : facile, moyenne, difficile, très difficile

Sur les posts consacrés aux feedbacks de chacune de ces AVH, les lecteurs et l'auteur peuvent donner leur propre appréciation. Dans un délai assez court (une semaine?), on fera une sorte de moyenne pour attribuer définitivement les critères.
Si l'expérience est concluante, on pourra à terme l'étendre à toutes les AVH.

[Skarn]

Bon, je suis donc repassé sur la base de données.



J'ai laissé tomber les notes des aventures pour l'instant. Il reste encore probablement des trucs à améliorer, j'attends donc vos commentaires.

Vu sa complexité grandissante, et le nombre de paramètres qu'elle gère, je suis vraiment content d'avoir pris le temps d'en parler sur le forum. Et aussi que le framework puisser générer automatiquement un maximum de fichiers php à partir de cela.

Quelques remarques en vrac :

Sur les clés des avh et des séries
Pour des raisons d'optimisation des moteurs de recherche, et aussi parce que c'est plus joli à l'œil, avoir des noms explicites, c'est bien. Pour cela, chaque aventure doit disposer d'une clé unique créée à partir de son titre. Par exemple, l'aventure Le Retour Des Xhâ Niâs : Le Portail de Tous les Temps, pourrait être à l'adresse http://www.xhoromag.com/avh/le-retour-de...temps.html (le .html est purement bidon par la magie de la ré-écriture d'url, c'est une page avec plein de php dedans) et sa série à http://www.xhoromag.com/collection/le-re...-nias.html. Je suis à peu près sûr que ce genre de clé est très utile, moins sur la forme exacte des url à appliquer. Si un(e) spécialiste en SEO pouvait éclairer ma lanterne...

Sur l'emplacement des images sur le disque
Soit un répertoire public/ à la racine du serveur. Les fichiers relatifs à une avh seraient alors dans public/avh/:id/ où ":id" est l'identifiant en base de l'aventure. Plus exactement, les couvertures, au pluriel car la même image serait en deux tailles différentes, l'une pour sa page dédiée et une autre réduite pour sa présentation courte, seraient dans le sous-dossier cover/, sous les appelations ":key.jpeg" et ":key_s.jpeg", où :key est la clé de l'aventure. Là encore, je ne cracherais pas sur des conseils, parce que cela me semble moyennement propre.

Sur l'emplacement des aventures sur le disque
Les deux formats d'aventure primordiaux sont le PDF et le HTML. Le premier s'explique de lui-même. Pour le deuxième, je pense que l'idéal pour opérer la migration des aventures déjà en ligne est de réaliser un petit script qui fusionne tous les fichiers HTML distincts d'une aventure en un seul gros bloc, avec éventuellement du javascript, que l'on peut stocker quelque part (un peu comme ici). C'est moins compliqué que cela en a l'air, vu que cela n'utilise que des propriétés très simples (ancre html #, style css display).

S'il n'y avait que ceux-là, on pourrait se contenter de les enregistrer à la racine du dossier de l'aventure, sous :key.pdf et :key.html. Mais même en partant du principe que l'on envoie se faire voir les .doc et autres .odt (effectuer la conversion en pdf demandant juste à l'auteur de cliquer sur un gros bouton), il faut aussi un format d'archivage (.zip par exemple) contenant plusieurs fichiers (comme pour 1930). Le truc, c'est qu'une archive peut contenir tout et n'importe quoi... Et quid des fichiers connexes, comme le bêtisier du marais 2 ? Je dois encore réfléchir à la question...

Sur les paramètres descriptifs des aventures
J'ai repris l'idée de Dayne de mettre tous les paramètres descriptifs de l'aventure dans une seule table tags, et de se servir ensuite des catégories de tags pour les trier. Cela limite considérablement les jonctions de tables nécessaires à l'extraction de ces informations. Ensuite, je conviens qu'il faudrait probablement renommer cette table, le mot tags n'étant plus assez générique, et évoquant un rendu graphique finalement indépendant de l'enregistrement. avh_parameters peut-être ?

Sur la place des statuts
Je m'interroge sur l'intérêt de réserver deux tables dans la base de données pour les statuts des membres (admin, modo, expérimenté, nouveau) et des avh (en cours, terminé, en cours de correction, abandonné), au profit de l'utilisation de constantes directement dans le php. Cela limiterait les jonctions de table, et simplifierait à l'extrême certaines fonctions :

Code :

public function isAdmin() {
    return ($this->getStatusId() === MemberStatus::ADMIN);
}

[sunkmanitu]

Même si je n'y comprends rien j'admire votre talent, à vous tous les codeurs ! Putain quel taff !

[Skarn]

Avant toute chose, un point sur les formats de lecture pure disponibles que j'ai vu sur le site :

• PDF
  
• HTML
  
• Archive statique (pack de PDF et d'images)
  
• Papier (achat externe)
  

Je pense que l'on peut ajouter à la liste les exécutables informatiques, comprendre les livres-jeu numériques, subdivisés par plate-formes (Windows, Linux, Android...).

Cependant, à côté, on trouve souvent les sources (.doc, .avh) qui ne sont utiles que pour ceux désirant travailler sur l'aventure. Je propose de les lister comme les autres pour l'instant. D'un point de vue base, c'est de toute façon la même chose.

À terme, il faudra quand même fortement inciter les gens à faire gaffe à ce qu'ils font. Un Word n'est pas prévu pour être lu tel quel, c'est un format destiné à être travaillé. Pour prendre un parallèle avec l'informatique, c'est le code source de votre aventure, pas le programme que l'utilisateur lambda utilise. Je n'ai rien contre le fait que vous mettiez votre .doc à disposition, surtout si vous êtes sous une licence incitant au partage (comme une Creative Commons), mais à condition que vous fournissiez aussi un format confortable pour le simple lecteur, comme un PDF.

/*****************************************/

Cat' travaillant sur la mouture finale du tableau à remplir, j'en profite pour imposer quelques règles de syntaxe :

NULL: quand un champ est normalement vide, comme le nom de la série pour une aventure indépendante, écrivez en toute lettre NULL. Pas une case vide, pas un /, pas un -, mais NULL.

Pour les questions fermée, comme par exemple « l'aventure est-elle illustrée ? », seuls OUI et NON sont des réponses acceptables. De façon général, les paramètres demandant des valeurs entières ne doivent accueillir que des entiers, les chaînes de caractères que des caractères alphanumériques etc.

Étrangement, le nom des colonnes est un point sans importance tant que l'on s'y retrouve. En effet, il s'agit au pire que d'un groupe de lettres à remplacer, alors qu'un tableau de 185 lignes avec des valeurs incohérentes, c'est horrible.

Faire plusieurs feuilles de calcul, avec un seul tableau sur chacune.

Évitez de dupliquer des informations (exemple : indiquer à deux endroits la taille d'une aventure).

N'oubliez pas les dates (première publication, année de participation au Yaz'...). C'est une information précieuse pour la machine.

Une seule information par case : la série est une colonne, le numéro du volume dans la série en est une autre. Pour les informations multiples, comme les auteurs, veuillez utiliser une table séparée.

Exemple :

Table générale des aventures

Titre | Taille | Série | Volume |Blabla...
Le Château du Sorcier | 100 | NULL | NULL | ...

******

Table des auteurs

Aventure | Membre | Rôle
Le Château du Sorcier | Outremer | Auteur
Retour au Marais des Scorpions | Caïthness | Chef de projet
Retour au Marais des Scorpions | Chimæra | Illustrateur
Retour au Marais des Scorpions | Aragorn | Chef de projet
Retour au Marais des Scorpions | Aragorn | Auteur

*******

Table des Yaz

Aventure | Année | Score | Rang
La Reine des Fleurs | 2006 | 19 | 2
1930 | 2011 | NULL | NULL

*******

Table des paramètres de l'aventure

Aventure | Paramètre | Valeur
Retour au Marais des Scorpions | Difficulté | Moyenne
Retour au Marais des Scorpions | NULL | Personnage principal féminin

(vous êtes libre d'ajouter des tags supplémentaires aux aventures, n'appartenant à aucune catégorie, tant que vous remplissez ceux obligatoires)

Cat', au niveau du nombre total de champs, n'hésitez à engranger des données simples supplémentaires, si tu penses qu'elles peuvent servir. Par exemple, dans ma maquette de base de données ci-dessus, j'ai mis à la fois un champ "Nécessite de l'équipement externe" et un champ "Utilise le hasard". Il est plus simple d'engranger trop d'informations maintenant, quitte à ne pas s'en servir, que se rendre compte à la fin que ces données auraient pu être utiles finalement et de repasser sur tout pour les récupérer.

[Caïthness]

Cat' travaillant sur la mouture finale du tableau à remplir, j'en profite pour imposer quelques règles de syntaxe :

NULL: quand un champ est normalement vide, comme le nom de la série pour une aventure indépendante, écrivez en toute lettre NULL. Pas une case vide, pas un /, pas un -, mais NULL.

Pour les questions fermée, comme par exemple « l'aventure est-elle illustrée ? », seuls OUI et NON sont des réponses acceptables. De façon général, les paramètres demandant des valeurs entières ne doivent accueillir que des entiers, les chaînes de caractères que des caractères alphanumériques etc.

Étrangement, le nom des colonnes est un point sans importance tant que l'on s'y retrouve. En effet, il s'agit au pire que d'un groupe de lettres à remplacer, alors qu'un tableau de 185 lignes avec des valeurs incohérentes, c'est horrible.

Faire plusieurs feuilles de calcul, avec un seul tableau sur chacune.

Évitez de dupliquer des informations (exemple : indiquer à deux endroits la taille d'une aventure).

N'oubliez pas les dates (première publication, année de participation au Yaz'...). C'est une information précieuse pour la machine.

Une seule information par case : la série est une colonne, le numéro du volume dans la série en est une autre. Pour les informations multiples, comme les auteurs, veuillez utiliser une table séparée.

Exemple :

Table générale des aventures

Titre | Taille | Série | Volume |Blabla...
Le Château du Sorcier | 100 | NULL | NULL | ...

******

Table des auteurs

Aventure | Membre | Rôle
Le Château du Sorcier | Outremer | Auteur
Retour au Marais des Scorpions | Caïthness | Chef de projet
Retour au Marais des Scorpions | Chimæra | Illustrateur
Retour au Marais des Scorpions | Aragorn | Chef de projet
Retour au Marais des Scorpions | Aragorn | Auteur

*******

Table des Yaz

Aventure | Année | Score | Rang
La Reine des Fleurs | 2006 | 19 | 2
1930 | 2011 | NULL | NULL

*******

Table des paramètres de l'aventure

Aventure | Paramètre | Valeur
Retour au Marais des Scorpions | Difficulté | Moyenne
Retour au Marais des Scorpions | NULL | Personnage principal féminin

(vous êtes libre d'ajouter des tags supplémentaires aux aventures, n'appartenant à aucune catégorie, tant que vous remplissez ceux obligatoires)

Cat', au niveau du nombre total de champs, n'hésitez à engranger des données simples supplémentaires, si tu penses qu'elles peuvent servir. Par exemple, dans ma maquette de base de données ci-dessus, j'ai mis à la fois un champ "Nécessite de l'équipement externe" et un champ "Utilise le hasard". Il est plus simple d'engranger trop d'informations maintenant, quitte à ne pas s'en servir, que se rendre compte à la fin que ces données auraient pu être utiles finalement et de repasser sur tout pour les récupérer.

Bon, je comprends vite, mais faut m'expliquer longtemps.

D'après ton histoire de table, on ne garde pas le tableau global que j'avais fait alors. S'il faut le diviser, je préférerais que tu nous fasses un modèle excel (juste les entêtes) avec une table par onglet et les données idoines. D'jà qu'je comprend rien au graphe, alors si je dois pêcher les tables là-dedans, on e na pour 6 mois lol. Dès que tu as fait le modèle, on cherchera des gens qui nous aiderons à le remplir (et si y'a personne, ben on retroussera les manches, mais bonjour le délai, surtout avec les fêtes qui se profilent en face, on risque de mettre de côté lol).

S'il nous vient des idées de nouvelles données lors du remplissage, on les signalerai et tu décideras dans quelle table on pourra la rajouter.

Ca te va comme ça, chef ?

[Skarn]

Dans la pratique, une base de données SQL ne peut accepter plus d'une information par case. On a donc besoin de faire plusieurs tableaux pour gérer ces cas-là. Mais tu as raison, le plus simple est encore de se référer au modèle ci-joint, en utilisant la même technique de faux .doc que Cat'.

Je propose que l'on fasse un pack commun pour les doc, docx, odt etc. en tant que support d'avh.

Pour la date de première publication, je me base sur la date du message de Oiseau indiquant que l'aventure est disponible dans les sujets de feedback. Je propose de laisser tomber les révisions passées de l'aventure, à moins que quelqu'un est le courage de trouver la date de chacune.

Par "équipement nécessaire", j'entends par là que l'aventure n'est disponible sous aucun support qui la gère intégralement. Le lecteur a toujours besoin d'un papier (ou d'un fichier texte), éventuellement de dés etc. Quasiment toutes les aventures du site tombent actuellement dans cette catégorie, mais ce n'est pas forcément pas le cas chez la concurrence, où des aventures intégralement gérées par la machine existent (exemple).

Pour tous les champs dont les valeurs sont à choisir dans une liste définie (genre, support, difficulté...), mettez-vous bien d'accord sur l'orthographe... et la casse. A et a sont deux choses différentes pour tout logiciel digne de ce nom (ie pas sous Windows).

Toutes les cases doivent être remplies. Au pire, trichez un peu en estimant à la louche.

Si vous avez des questions, comme d'habitude, je me tiens prêt à essayer d'expliquer clairement mes idées confuses.

[Caïthness]

je viens de jeter un oeil sur le fichier de Skarn et j'ai eu un malaise

c'est "pas glop" dans le sens où on va être obligé d'écrire 120 fois le même nom d'une même AVH qui est la donnée même "liante" de ces mêmes données. (c'est clair ? lol)

Je me demande si on ferait pas mieux de tout mettre sur un seul onglet, de remplir, puis de séparer au final par des copies d'onglet et suppression de colonne. Ce sera peut-être plus rapide, non ? Pour facilité, on pourrait mettre 1 couleur / onglet et mettre cette même couleur en fond des cellules concernées avant regroupement. Je ferais ça demain.

Ensuite on verra ce qui nous manque pour remplir convenablement ce foutoir lol

[Skarn]

De la façon dont vous travaillez, je n'ai cure. Vous pouvez utiliser des listes, des onglets, des fichiers textes, des allumettes et une corne de brume, tant que vous parvenez à vous organiser et à remplir les données. Tout ce que je demande, c'est qu'à la fin, vos résultats puissent être transformés au format ci-dessus, avec des informations atomiques. Les arcanes d'Excel m'étant inconnues, je vous fais confiance à ce sujet. Faites ce qui vous semble le plus simple et lisible d'un point de vue humain.

[Alendir]

Pour le liant, vous pouvez faire un id qui s'autoincrémente, non ? Genre dans chaque feuille, vous avez une colonne qui contient les numéros 1 -2 - 3 etc. Excel le fait automatiquement quand on déroule une colonne contenant deux chiffres qui se suivent.

[Caïthness]

De la façon dont vous travaillez, je n'ai cure. Vous pouvez utiliser des listes, des onglets, des fichiers textes, des allumettes et une corne de brume, tant que vous parvenez à vous organiser et à remplir les données. Tout ce que je demande, c'est qu'à la fin, vos résultats puissent être transformés au format ci-dessus, avec des informations atomiques. Les arcanes d'Excel m'étant inconnues, je vous fais confiance à ce sujet. Faites ce qui vous semble le plus simple et lisible d'un point de vue humain.

J'aime beaucoup ta façon de manager

@alendir : pas compris ton histoire d'incrément. De toute façon, je pense que ça ne marchera pas, car dans certaines tables la même AVH va générer plusieurs lignes, et ça un "compteur" ne pourra pas gérer (à part en utilisant des recherchev peut-être...)
On va rester sur mon idée. Après va falloir répartir les différentes étapes de remplissage entre ceux qui le feront.