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

[Akka]

J'avoue que le "furtherance" me fait tiquer. C'est un mot qu'on réserve plutôt à une intention, une stratégie, un plan, un objectif, pas à une création.
S'il s'agit de l'avancement de l'écriture, "progression" serait bien plus adapté.
"gender" est effectivement plutôt utilisé pour le sexe, donc je verrais "type" à la place.

[Skarn]

J'ai pas tout capté sur ton histoire de tag_category. Enfin si, mais je vois pas trop ce qu'elle peut contenir. Thème, univers ? What else ?

C'est à peu près tout. En fait, la structure de ce morceau dépend de ce que l'on autorise, pour optimiser les requêtes. Supposons que l'on permettre aux auteurs de créer leurs propres tags, en-dehors d'un contexte prédéfini. Par exemple, un tag « Expérimental » pour L’Homme qui Goûtait à ses propres Macédoines. Dans ce cas, on a obligatoirement besoin d'une table tag, et d'une table de jonction avh_tag. Inclure directement dans cette même table le genre et l'univers évite de devoir faire une jonction supplémentaire.

avh_tag_category risque d'être une donnée servant rarement, mais qui serait utile si l'on décide d'inclure des listes de recherche rapide par genre comme dans mes premiers essais graphiques. Elle n'augmentera pas la complexité de la requête pour remonter une avh, puisque celle-ci ira chercher tous les tags sans les ordonner par catégorie (pas de jonction).

[Dayne]

J’avais donné quelques idées rapides sur un post précédent. Voici un autre exemple concret de données en table :

Table AVH
=========
Id | Nom
=========
1 | AVH1
2 | AVH2
3 | AVH3

Table Tags_Classes
=======================
Id | Nom | Nb_Occurs_Max
=======================

1 | Règles | 1
2 | Genre | 10
3 | Univers | 10
4 | Difficulté | 1
6 | Linéarité | 1
7 | Yaz | 1

Table AVH_Tags (= table d’association)
=============
Id | AVH_id (FK) | Tag_id (FK) [| User_id (FK)]
=============
1 | 1 | 1
2 | 1 | 35
3 | 1 | 84
4 | 1 | 38
5 | 3 | 4
6 | 3 | 37

Table Tags
================
Id | Nom | Tag_Class_Id (FK) | Icône | Description
================
1 | Loup Solitaire | 1
2 | Défis Fantastiques | 1
3 | Sans Dé | 1
4 | Règles Originales | 1
…
35 | Aventure | 3
36 | Humoristique | 3
37 | Horreur | 3
38 | Fantasy | 4
…
83 | Facile | 4
84 | Difficulté Moyenne | 4
85 | Difficile | 4
86 | Très Difficile | 4
…

Ici on a trois aventures :
- L’AVH 1 qui a les tags : « Loup Solitaire », « Aventure », « Fantasy » & « Facile »
- L’AVH 2 qui n’a aucun tag (elle vient d’être mise en ligne).
- L’AVH 3 qui a les tags : « Règles Originales » & « Horreur»


Un avantage (1) : c’est que c’est plus uniforme donc plus simple à programmer au niveau php/html.
Pouvoirs d’un auteur :
- ajout/suppression d’un tag
Pouvoir d’un archiviste :
- ajout/suppression/modification d’un tag
- ajout/suppression/modification d’une catégorie de tag

Un avantage (2) : c’est que si jamais les xhoromagiens veulent ajouter une catégorie quelconque (exemples au hasard : Niveau de grammaire faible/moyen/soutenu ; TopList Alendir/Skarn/Oiseau), ils n’auront pas à passer par l’ajout d’une nouvelle table et autres ALTER TABLE mais auront simplement à faire appel au mécanisme, déjà en place, d’ajout de classe de tag (pas besoin d’administrateur de BdD). Il n’y aura aucun changement non plus à apporter au niveau de l’interface.

Quelques autres idées comme ça :

1) J’avais également imaginé de pouvoir lier le tag à l’utilisateur : je ne sais pas si ça c'est la même chose pour vous, mais, de temps en temps, j’aime lire les feedbacks d’une personne en particulier et donc j’imaginais que, de la même façon, l’utilisateur pouvait se fier d’avantage aux choix d’un archiviste en particulier (parce qu’il apprécie ses critiques par exemples) plutôt qu’à l’ensemble des tags d’une AVH (pour peu que « l’archiviste » soit suffisamment prolifique dans ce domaine).
En particulier j’avais pensé à une popup javascript qui s’ouvrirait chaque fois que la souris passe au-dessus du tag avec les noms des utilisateurs ayant attaché le tag.

2) J’avais pensé à rendre visible dans la sélection le poids d’une AVH car :
- plus le tag est représenté et plus il plus il est légitime
- moins le tag est utilisé et plus il est pertinent/discriminant
=> J’ai vu que ça se faisait sur http://jeux-alternatifs.com/ par exemple

3) Je pensais aussi, en plus des icônes, à associer une couleur particulière à un type de tag (pour le visuel)

En combinant les idées 2) & 3), ça donnerait quelque chose comme ça:
Loup Solitaire, Défis Fantastique, Facile, Difficile, Horreur, Aventure, Science-Fiction
(+ des popups avec l’idée 1 mais seulement sur les icônes de la page de description de l’AVH )

[Alendir]

Voilou



EDIT: J'ai vu le post de Dayne après. A discuter.

[Skarn]

Dayne, si j'ai bien compris ce que tu proposes, c'est un système où la plupart des gens peuvent ajouter des tags à une aventure, et plussoyer ceux déjà présents. Ceux-ci sont ensuite classés par nombre d'occurrence. C'est bien cela ?

Pour l'instant, j'étais plutôt parti sur le choix des tags par l'auteur uniquement, avec éventuellement un rapport de poids : si une aventure a deux tags (fantasy et DF), elle sera plus haut dans le classement selon le tag DF qu'une aventure ayant 18 tags (je caricature), dont DF. Ensuite... à voir, comme tout le reste.

[Dayne]

Dayne, si j'ai bien compris ce que tu proposes, c'est un système où la plupart des gens peuvent ajouter des tags à une aventure, et plussoyer ceux déjà présents. Ceux-ci sont ensuite classés par nombre d'occurrence. C'est bien cela ?

En fait, pas tout à fait (mais ça aussi c'est une idée) : dans mon raisonnement le poids des mots-clés ne serait intervenu qu'au niveau de la fonction de recherche (exactement comme dans le lien que j'ai donné ; c-à-d le nombre d'AVH où le tag apparait) : ce serait juste visuel.

Pour ce qui est d'avoir plusieurs fois un même tag pour une même AVH, là par contre, c'était dans la continuité de l'idée où il y aurait plusieurs niveaux d'utilisateurs, dont des archivistes (repris directement du poste organisation humaine) : on pourrait alors rajouter un filtre permettant de sélectionner ses chroniqueurs préférés.

En bref, par niveau décroissant de pouvoir on aurait :
- 1 ou 2 administrateur(s) (pour la partie technique)
- 7/8 archivistes (c'est eux qui mettent les tags & gèrent les catégories)
- les utilisateurs (qui ne peuvent mettre des tags que sur leur propre avh mais qui peuvent aussi commenter celles des autres)

[Alendir]

J'ai testé le code généré par Mysql workbench et ça a l'air de bien fonctionner sous PHPmyAdmin, c'est cool

Remarque : je n'ai pas fait les ON UPDATE CASCADE et ON DELETE CASCADE (ou pas, ça dépendra des cas) sur les clés étrangères. Donc si on utilise le code de workbench, faudra que j'y pense.

Question pratique : finalement, on utilisera le code de Workbench, ou on créera (enfin, je) les tables à la main sous PHPMyAdmin ?
Est-ce qu'il y a des options à pas oublier avec workbench quand on génère le script (j'en ai vu des tas, j'ai fini par faire next, next...), du code à nettoyer ?
Si on utilise PHPMyAdmin, il faut nettoyer le code généré à l'exportation ? (faudrait le faire à chaque fois, donc je vois pas l'intérêt, mais tu m'en avais parlé - si c'est pour la gestion des clés étrangères, je sais faire sans retoucher le code et réimporter le script sql).

Donc vu que ça a l'air bien de fonctionner, je propose de réutiliser le code de Workbench. Juste que j'aimerais savoir si y'a pas de boulette à ne pas faire avec ce code.

Pour les tags, j'ai l'impression que la structure de BDD telle qu'elle permet pas mal de choses pour les recherches ciblées.

[Skarn]

Ma méthode avec MySql Workbench est extrêmement scientifique : je mets les options au pifométre, je jette un œil au code final, et regarde si des trucs me choque. Si c'est le cas, refaire un export avec des paramètres modifiés en fonction. C'est un peu pareil avec phpMyAdmin : tu peux tout faire, mais t'oublie toujours des trucs (des clés étrangères, des encodages, des indexs...), une relecture est donc nécessaire. Et comme le code ne ment jamais, c'est toujours lui qu'on regarde.

Pour en revenir à la présentation générale, je verrais bien une icône pour indiquer que l'aventure possède au moins une illustration, de façon à pouvoir l'indiquer même si la micro-vue de la page d'accueil. Et j'ai complétement oublié de relancer ce débat : plutôt que dé/pas dé, je verrais plutôt une séparation hasard/sans hasard, avec une icône pour ce dernier cas (un panneau interdit aux dés ou quelque chose comme cela, avec le sens expliqué au survol via la balise title).

Je me rends compte que si l'on est bien avancé sur la sortie des données, on l'est moins au niveau des entrées, et que clarifier permettrait sans doute de fixer quelques points encore flous de la base.

Pour une aventure donnée :

• Qui peut attribuer des tags ?
  
• Est-ce que les tags ont un poids ou est-ce qu'ils sont en tout ou rien ?
  
• Combien de tags différents au maximum ?
  
• Est-ce que le genre et l'univers sont mis au même niveau que les autres tags (un simple champ texte, avec éventuellement une autocomplétion), ou est-ce qu'ils ont une section réservée ? Dans ce dernier cas, impose-t-on de choisir dans une liste des possibilités existantes ? Qui peut ajouter des éléments à cette liste en ce cas ?
  

[Alendir]

Mis à jour le schéma avec la table random et surtout les ON CASCADE.

Par contre, pour le stockage de fichiers, je suis un peu newbie. On socke juste le chemin dans les tables, ou carrément l'image/le fichier du livre ?

Bon pour les fameux tags, je pense qu'il ne faut pas qu'il deviennent 50% de ce qu'il faudra coder pour le site.

•Qui peut attribuer des tags ?

Les auteurs : genre, univers... On peut leur faire confiance là-dessus.

•Est-ce que les tags ont un poids ou est-ce qu'ils sont en tout ou rien ?

Même poids, tu choisis SF et starwars et tu as toutes les AVH du genre en ordre alphabétique qui s'affichent. Si tu as sélectionné plusieurs genres dans ta recherche, l'ordre dépend du nombre de genres auxquels correspondent les AVH, qui peuvent en avoir plusieurs.

•Combien de tags différents au maximum ?

On peut avoir plusieurs genres (2, 3) et un seul univers.

•Est-ce que le genre et l'univers sont mis au même niveau que les autres tags (un simple champ texte, avec éventuellement une autocomplétion), ou est-ce qu'ils ont une section réservée ? Dans ce dernier cas, impose-t-on de choisir dans une liste des possibilités existantes ? Qui peut ajouter des éléments à cette liste en ce cas ?

C'est la question que je me posais en répondant. En fait comme seuls tags proprement dit je mettrais le genre et l'univers : si on multiplie les tags, bien va valloir gérer cette multiplicité, pour pas grand-chose (trier par règles, genre, univers c'est suffisant je pense, d'autant qu'on peut ajouter série ou pas série, liberté d'action, difficulté, aléatoirité...). Je pense qu'on aura une liste pré-établie de genres, y compris les moins connus (uchronie...) et d'univers. Si jamais un auteur veut en rajouter, il en fait la demande à l'admin. Sinon, à la création de son AVH, il a 2 listes déroulantes pour choisir ses genres éventuels, et une pour l'univers.

[Skarn]

Oh, et tiens, pour relancer le débat : va-t-on gérer les aventures dans plusieurs langues, ou seulement en français. En particulier, pour les traductions, devons-nous proposer la VO et la VF ?

Alendir, pourquoi faire une table séparée pour avh_comment_link plutôt qu'un champ facultatif "feedback_link" dans avh_comment ?

Dans avh_available, il manque également un "external_link", là aussi facultatif, pour renvoyer sur un site extérieur (exemple : Nils Jacket, les avh de Héros). Si ce champ est vide, la procédure standard pour récupérer l'aventure sur le site sera appliquée... d'ailleurs, il va aussi falloir y réfléchir. Les fichiers seront sans doute sauvegardés dans un dossier du type public/avh/:id/, où :id est l'id de l'aventure dans la table avh. Mais ensuite, cela dépend de plusieurs critères. Est-ce que l'on fait du versionning, en conservant une copie des v1.0 d'une aventure en même temps que la v1.1. Est-ce qu'on les remplace ?

C'est quoi le booléen "equipment" dans avh ? Et la table "random" ?

[Alendir]

Ok pour ces modifs (je te laisse faire).

Ah merde, pour equipment et random, c'est un doublon. C'est grosso modo pour dire s'il faut des dés ou pas, y'a des gens qui en avaient parlé.

Je pense qu'on remplace les versions : aucun intérêt de conserver les anciennes (ça peut même aller contre les désirs de l'auteur), gain de place pour le stockage, et petite simplification du truc.

[Fitz]

Pour les versions multilingues, je ne suis pas sûr que cela soit très utile. Je pense que les anglophones savent où trouver sur les sites d'origine les versions initiales.

[Alendir]

D'accord avec Fitz.

[Skarn]

Encore quelques questions : qui pourra estimer la difficulté, la linéarité et les règles ? L'auteur uniquement, ou les lecteurs pourront donner leur avis ?

Enfin, un dernier point : inclue-t-on la possibilité pour le lecteur de noter une aventure, sur une échelle de 0 à 5 ? Je sais que cela fait débat, mais à l'heure actuelle, les aventures n'ayant pas reçu de prix Yaztromo sont sur un étrange pied d'égalité. Ainsi, une aventure ayant reçu une floppée de critiques négatives sera au même niveau qu'une encensée, mais n'ayant cependant remporté qu'une médaille en chocolat. De plus, les notes fournissent une information visuelle immédiate, avec sa floppée d'étoiles jaunes immanquables, ce qui permet au lecteur d'avoir une estimation instantannée sur ce qu'a pensé la communauté de l'aventure. Cette information ne serait visible que sur la fiche détaillée, tout comme les critiques correspondantes, à l'inverse d'un véritable Yaz', qui donne des avantages bien supérieurs (apparition sur la page d'accueil, liste réservée etc.).

[Akka]

J'ai déjà donné mon avis sur les notes : c'est généralement une mauvaise idée, les avis étant trop souvent binaire ("c'est génial !" ou "c'est nul !" avec pas grand-chose entre les deux).
Je trouve qu'une appréciation non numérotée est plus adaptée.