Discuter:Poissonix

Un article de Wiki Judo, l'encyclopédie du judo.

Sommaire 1 Jeet : Droits, BDD et multilingue 2 Stephbleu 3 Jeet : Base de donnée 4 Stephbleu 5 Jeet 6 st 7 Jeet 8 Stephvert 9 Jeet 10 Stephrouge 11 Jeet 12 Stephjaune 13 Jeet 14 Stephvert 15 Jeet : aspect graphique 16 Stephjaune

Jeet : Droits, BDD et multilingue

Je pense que prendre en compte les problèmes de droits (images et descriptions) est nécessaire.

Les tables de la base de donnée prendront forcément beaucoup de place, surtout si le site est multilingue (multiples descriptions). Le mieux est d'avoir une table avec tous les poissons où on stocke les infos identiques (noms scientifique ? je ne sais pas), puis on remplit une autre table avec une ligne par langue, chacune de ces lignes étant liée par un id. Tout ce qui pourrait être rajouté (hiérarchisation des familles, etc.) se baserait sur l'id unique de la table Poissons, le reste c'est que du texte. Pour résumer, tous les poissons, familles, images, etc. sont identifiés par un id dans la table. Puis, on lie ces ids correctement à du texte (français, anglais) : ça fait des grosses tables de correspondance qui lient des paires d'ids (en SQL on appelle ça une clé étrangère). C'est la manière la plus simple et modulable pour bien séparer l'info (les ids) du contenu (les textes). Comme ça les traductions peuvent être rajoutées n'importe quand. Si on cherche à lier un poisson qui existe déjà, la famille, l'image, etc. sont déjà paramétrés, il ne suffit que d'ajouter le nom et la description. Si on s'est planté de famille, il suffit de ne modifier qu'une seule langue pour tout modifier. Pareil pour l'image et d'autres éventuelles informations.

Poissons

id
1
2
3

Description Poissons

id	poisson_id	langue_id	nom
1	1	1	Saumon
2	2	1	Thon
3	2	2	Tuna

Langues

id	locale	langue
1	fr_FR	Français
2	en_GB	English (GB)

Là, par exemple, le saumon n'est pas défini en anglais. Mais ça n'empêche pas de le définir plus tard. Les informations sont découplées, donc souples d'utilisation. C'est d'autant plus important pour un site multilingue justement.

Dans tous les cas, il faut savoir quelles sont les informations à stocker, ainsi que le dénominateur commun entre les différentes langues. Pourquoi ne pas avoir une image identique par site par défaut lors de l'ajout d'une nouvelle entrée, mais autoriser chaque site à avoir sa propre image par exemple ?

Concernant l'inscription, pas forcément utile pour jouer, mais pour chatter, etc. si (spam). Pour l'ajout de nouvelles entrées, attention également au spam (embêtant pour les validateurs). Un simple catcha facile à lire dans lequel il faut écrire 4 lettres -à l'envers- doit bien casser touts les robots je pense, mais je n'ai jamais vu personne le faire, ça.

Stephbleu

Je pense que tu peux décider seul de la partie "technique" du site. Si j'y touche, ça te fera le double de travail. Pourquoi ne pas faire une table avec les ids, une avec les mots clés correspond aux ids, une avec les "classements". Par contre tout ce qui est descriptions dans des fichiers qui se créeront au fur et à mesure de la création d'id ? Pour les descriptions pourquoi ne pas se limiter à une description générique utilisant les mots clés ?

Du genre : ID est un FAMILLE, DESCRIPTION FAMILLE. Il est reconnaissable par son PHY1, son PHY2 et ces PHY3. On le retrouve GEO1.

o)

Jeet : Base de donnée

Je ne peux pas modéliser la bdd alors que je ne sais pas à quoi ressemble une description, et quelles sont les différences entre les langues. Si je m'occupe de la partie technique, tu es le seul à pouvoir décider du contenu. Donc sachant que l'on peut associer tout par id comme je l'ai montré en exemple, tu peux avoir une meilleure idée concernant leur structure.

Concernant la façon de faire de géographix avec des fichiers, c'est une grosse connerie. On a 30000 fichiers de connexion dans un même dossier, c'est n'importe quoi. Heureusement que je peux accéder facilement à tout ça en ssh (ligne de commande, connexion à distance), en ftp c'est impossible. Utiliser sqlite aurait été préférable dans ce cas, car peu de modifications, et peu de données. Sqlite devient problématique lors d'accès concurrents, on ne peut pas avoir deux accès en écriture simultanément sans risquer de bousiller le fichier. En lecture, tant que ça reste petit, c'est très rapide. On pourrait effectivement séparer les infos poissons dans sqlite (vu que seuls les validateurs peuvent les valider, les accès simultanés en écriture sont peu probables), et les utilisateur dans MySQL. Par contre diviser les poissons dans sqlite et MySQL c'est pas possible. L'utilisation d'ids réclame des "jointures" (= coller les tables ensembles) pour que tout se fasse en une seule requête (très rapide), et pas en plein de petites. Séparer l'ensemble serait ingérable. L'autre point à considérer, c'est la configuration du serveur. OVH a configuré le mutualisé pour optimiser MySQL, pas une bdd telle que sqlite.

D'autre part, les tables de géographix ne prennent pas tant de place que ça. Tout mettre dans MySQL dans une table très peu utilisée ne serait pas si problématique je pense. Le tout est de savoir si en changeant la formule d'OVH, les tables seraient aussi grosses que marqué dans le mail que je t'ai envoyé une fois le transfert effectué. Si elles le sont, pas besoin de réfléchir, tout part dans MySQL.

Stephbleu

La description sera un petit texte avec 200 caractères max,... ...le truc est de penser que ça risque d'être un point qui risque d'évoluer. 1 petite description, style résultat de recherche et une description "fiche poisson".

Oki, les fichiers uniques sont une erreur, à oublier.

La base de données si le site fonctionne bien, sera de 10 à 20 000 ids. + 2 noms (fr + eng + ???) + 2 descriptions courtes (peut être juste utiliser les mots clés) + une description longue (à voir) + stats. Je commence aujourd'hui le site (brouillon), pour essayer de tester et voir quel solution semble le plus sympa (besoin de ton avis ^^)

http://www.poissonix.wiki-fr.net/

Jeet

Je suis contre l'utilisation des www devant le nom du wiki, c'est moche. Un simple poissonix.wiki-fr.net est plus joli.

Je suis également contre la configuration de ton éditeur de texte. T'as déclaré ta page en utf-8, alors qu'elle a été créée en iso. Et le pire, c'est ton éternel problème de sauts à la ligne : y en a pas ! Je reforme le fichier qui est juste illisible. Même la pub ne s'affiche pas tellement elle a honte. Si tu utilises Notepad++, veille à ce qu'en bas à droite il y ait écrit ANSI as UTF-8.

La meta keyword ne sert plus à rien, pas besoin d'y réfléchir.

Je viens de finir de réarranger le code. Faut passer à html5 qui est beaucoup plus simple. C'est index.html (l'ancien est resté index.php).

Comme précisé sur l'autre page, faut revoir le nom Poissonix. Ça ne colle pas forcément avec la partie flore, et ça fait bizarre à entendre.

st

Euh, je ne comprend pas tout... J'ai commencé cette page juste pour me faire une idée plus précise et commencer un peu la mise en page. Ça m'a permis de régler pas mal de dimensions. Le wiki ne sert juste à s’entraîner mais si t'es motivé, je passe en 100 Go, on trouve un .com ou un .fr et on se lance :o)

Cool d'avoir nettoyé un peu le code de ma page ^^. Je galère depuis tout à l'heure pour le titre,... Le mettre en gros et mettre une petite phrase en dessous en moins gros. Faut que ça corresponde à l'image.

Si t'as une idée pour le nom ou autre, ne te prive pas.

Que penses-tu des dimensions ?

Ne t’inquiètes pas, la déco risque de fortement évoluer. C'est juste pour découper la page et faire un brouillon ^^

Jeet

Je disais ça pour rigoler. Je sais bien que c'est juste pour voir à quoi ça ressemble. C'est juste qu'en allant changer l'encodage du fichier, j'ai vu le désastre (et c'est pareil pour les pages d'autres sites que tu as modifié, y en a plusieurs qui n'ont plus qu'une ligne). C'est également pour ça que je n'ai pas modifié le code en lui-même, afin de garder la même apparence.

Il est hors de question de changer l'hébergement tant que le site n'a pas au moins une maquette, la recherche comprise. Jusqu'à fin mars, je n'ai pas beaucoup de temps. Si j'arrive à créer le simulateur tel que je le souhaite, je pourrais très rapidement faire des simulations à l'avenir. Tant que je n'ai pas mes résultats, je suis bloqué.

Pour les dimensions, j'en sais rien. Je n'ai pas de téléphone pour les tester, et tant que l'on ne connais pas le contenu c'est dur de se dire si c'est serré ou non sur ordinateur (on peu changer le css selon que l'on est sur mobile ou non).

Si tu cherches à allier image et texte (bannière), faut arrêter de faire comme actuellement. C'est mieux de directement intégrer le texte dans l'image. Il suffit de changer de système d'exploitation ou de navigateur pour que la police soit modifiée, et que tout soit décalé n'importe comment. Un texte alternatif servira pour renseigner les moteurs de recherche et doit être prévu pour les personnes utilisant un lecteur d'écran (accessibilité).

Tu comptes séparer la faune et la flore (description, site, etc.) ? ou non ? C'est à prévoir dans la bdd aussi.

Sushix, le site qui vous permet d'identifier les ingrédients de votre prochain sushi. :-p

Stephvert

Un désastre !! Aïe. Peut être que c'est parceque je récupère à chaque fois les codes d'autres sites que je modifie. Qu'une ligne, je comprends pas, tu peux me donner un exemple que j'arrête de faire n'imp'...

Oki pour l'hébergeur, j'attend ton feu vert. Ton boulot au japon est un simulateur, de quoi ?

Les dimensions, c'est un soucis. Je m'adapte à mon écran mais ça se trouve c'est affreux chez les autres. J'ai fait des recherches sur le web, il y a en effet plein de sites regroupant un max de ceux-ci. Mais aucun site n'a simplifié la recherche donc le petit poisson bizarre reste à jamais un petit poisson bizarre pour le néophyte.

Plus j'y pense, plus je me demande si c'est une bonne idée de mettre des admins. Je crois que non,, il faut que les utilisateurs fassent le tris et que le site détecte les erreurs. As -tu pensé à un système qui ajoute des mots clés au fur et à mesure que la Bdd grossit ?

Une idée : outils comparateur de poisson. Une idée de génie.

Pas mal comme idée Sushix... :o)

Jeet

Ben l'index.php était un exemple. Si ton éditeur de texte ne voit pas la différence, affiche la source depuis le navigateur. Par exemple va voir le code de bon-reduction. Dans le dossier pages/views/, t'as conditions, contact et mesvoyages qui ne tiennent que sur une ligne. Par contre le site n'est plus accessible. Essaie d'ouvrir les fichiers avec un autre éditeur de texte sinon. Avant quand t'avais deux retours à la ligne au lieu d'un, c'était surement à cause d'un problème d'encodage windows/unix. Mais tout sur une ligne, je vois pas. Je ferai une recherche plus tard.

Ça ne sert à rien de changer de formule pour un site non fait. Je connais les caractéristiques du serveur, ça me suffit (grrr... on n'a pas de cache d'op code, style APC - c'est normal sur un mutualisé).

Simulateur de réseau à fibre optique. Je dois étudier et comparer les performance de mon réseau à d'autres déjà existants. Comme j'ai créé un nouveau protocole de transfert, je dois tout créer à la main. Mon but c'est de créer ma propre bibliothèque (.dll) qui me servira à tester rapidement de nouveaux algorithmes : plus besoin de faire des copier-coller de code, j'ai juste à coder l'algorithme et changer un fichier de configuration pour faire mes tests.

Sur mon 1920*1080, ça va. C'est le problème de faire un site à taille fixe. C'est pour ça que je parlais de changer le css selon que l'on soit sur téléphone ou non. Le contenu reste le même, mais le css se charge de tout réarranger et faire disparaitre ce qui est inutile. Pour l'instant, pense avec des images, pas avec du code html/css. Si besoin, crée le code d'un élément particulier, copie d'écran, puis réarrange sur un logiciel de dessin. Puis dans l'index.html, affiche l'image. Ça te permet d'utiliser les calques pour gérer les boutons, le fond, etc.

Je comprends pas ton histoire d'admin. Les admins, c'est nous, personne d'autre. Faut bien que l'on ait une interface pour tout gérer. Tu parles des validateurs ? Ce qui m'inquiète surtout, c'est la provenance des images et des descriptions. Faut prévoir d'associer les images à leur source si besoin est. C'est le rôle d'un validateur pour moi. La vérification de l'orthographe aussi.

J'ai pas compris l'histoire de mot-clés. Tant que t'as pas défini de façon claire les infos à afficher et la façon d'effectuer une recherche, je ne peux réfléchir à rien. C'est pour ça que je parle de maquette.

Concernant les infos. Mon problème est de savoir si on peut réellement faire des équivalences entre plusieurs langues. Selon les pays, on n'a pas autant de vocabulaire (mots différents) pour définir telle ou telle chose. Qu'en est-il pour la faune et la flore marine ? Y a-t-il besoin de différencier la description d'une "famille" (par exemple, pour les oiseaux, "corbeau" est un nom générique, dans d'autres langues on ne distingue pas les mots "corbeau" et "corneille"), ou c'est ça les mot-clés ? La question est donc de définir si oui ou non on doit établir une correspondance entre les différents sites. C'est cool, mais ça peut être casse-tête.

Bref, cahier des charges avant maquette, et maquette avant conception.

Stephrouge

Bizarre cette histoire de tout en une ligne... Ce problème n’apparaît pas chez moi. J'édite avec Notepad++

Oui je parlais de validateurs. Mais c'est une erreur. Il faut qu'on ait rien à faire. Les premières données que je vais mettre, il faut que je puisse les mettre en tant qu'utilisateur. Le truc est que si le site marche moyen, en bien on aura juste quelques milliers d'Id, mais s'il marche très bien... Le nombre de fiche peux se compter en 10aine de millier, ingérable par un petit groupe de modo.

Les mots clés : Imagine le premier poisson que je mets, Poisson lune et je mets poisson comme mot clé. Un utilisateur vient juste après et lance le "jeu", la question est : est ce un poisson ? Il répond oui, et le jeu lui propose le poisson lune. Il dit non est remplit la fiche de son poisson. Du coup le jeu pourra trouver son poisson mais avec le temps le poisson lune n'a pas assez de mot clé. Il faudra que le jeu fasse évoluer sa description...

Il y aura plusieurs type de mot clé. Pour la description physique, pour la famille, la location (exemple poisson mer rouge), et pleins d'autres...

Comme c'est l'utilisateur qui remplira la bdd, le problème de la langue n'en ai pas une puisque les erreurs se corrigeront d'elles même.

Que veux-tu dans ton cahier des charges ? Je crois avoir tout dit,... L'image décrivant succinctement le site me paraissait clair.

Le site : http://www.souslesmers.fr/ a été créé dans le même objectif que le notre en moins ludique. Il a fait un travail très sympa mais on voit clairement qu'en 5 ans, il a vite été limité à cause de la quantité d'info à filtrer. Pour les photos, je pense qu'enregistrer l'IP du donateur + un nom, prénom et email est une bonne chose + lui faire lire un texte du genre il est responsable si ce n'est pas sa photo bla bla bla. L'image doit pouvoir être effacé par le vrai propriétaire (sur demande).

Les photos de wikipédia sont elles libre de droit ?

Jeet

J'ai compris. C'est normal que t'enregistres tes fichiers au format Mac ? Va dans les préférences et change les retours à la ligne pour au moins du Windows pour ne plus avoir le problème. Tu peux également convertir ton fichier dans le bon format depuis le menu (format de sauts à la ligne). Une fois qu'il a été enregistré/converti dans le bon format, il n'y a plus de problème par la suite. Notepad++ s'adapte. Le problème c'est à la création de celui-ci.

Si tu laisses les données en libre accès en écriture comme ça, il est hors de question de faire du sqlite. C'est obligatoirement MySQL. Ça veut également dire qu'il faut un système complet d'historique style Wikipédia, ou au moins des backups régulières pour éviter une destruction inopinée des données. L'intérêt d'avoir des validateurs, c'est justement de filtrer l'accès en écriture, et dans ce cas, sqlite est nickel. Si c'est trop libre, je ne connais pas assez sqlite pour juger. Je comprends le problème d'avoir trop de données à valider.

Tu parles du jeu par mot-clé, mais on n'a aucune idée de l'implémentation du jeu encore. Au niveau des mot-clés, y a toujours le système de tags comme sur les blogs et tout qui sont rajoutés à la main. J'ai toujours peur pour l'orthographe. Mais on peut faire en sorte que les tags puissent être modifiés et fusionnés.

Rajouter des mots automatiquement c'est bien, mais je ne vois pas comment éviter les fautes sans avoir un dictionnaire interne qui vérifie et propose un tag adapté (par exemple Google remplace en interne un mot féminin pluriel par son penchant masculin singulier - ou encore un verbe conjugué par sa forme à l'infinitif pour avoir plus de résultats). Si il y a une faute d'orthographe, on propose le mot le plus proche dans le dico. On peut aussi avoir un dico réduit qui enlève plein de mots inutiles (articles, verbes ou mots trop communs). Par exemple "poisson" n'est pas forcément pertinent s'il n'y a que des poissons dans les fiches.

Pour l'instant tout n'est qu'idée. Comme tu le dis, c'est "succinctement". Je n'ai toujours aucune idée d'à quoi ressemble une fiche dans le détail, si tu sépares faune et flore, est-ce qu'il y a des catégories à exclure, etc. Je ne parle pas d'apparence globale, mais de description du contenu. Les mot-clés sont apparents (contenus dans la fiche), ou ils peuvent être non apparents ? La structure de la base de donnée, c'est juste le point le plus important du site. C'est le point de départ de tout. Je ne demande même pas encore de penser aux mot-clés ou autres qui peuvent être rajoutés dans une table supplémentaire par la suite, je parle simplement des données de base que l'on met dans une fiche. Bien sûr que ça peut évoluer par la suite, mais je n'ai même pas la moindre idée des infos de base. Quelle est la longueur d'une description ? C'est un Wikipédia ou des fiches ? T'as défini la limite à ne pas franchir dans les informations données ? Si c'est clair dans ta tête, ça ne l'est pas dans la mienne. Si tu regardes une fiche dans le site souslesmers, c'est pas quelque chose qui tient dans ton petit cadre. Taille du poisson, photo (dimensions ?), profondeur, durée de vie, localisation, nom scientifique, classification, etc. Tu prévois un site normal pour ordinateur où plein d'infos sont affichées, et son pendant mobile où tu vas à l'essentiel, où les deux sont identiques ? Peut-être que tu prévois qu'une fiche soit scindée en onglets, qui permettent d'accéder au type d'info voulue : tout tient dans ton petit cadre comme ça.

Autant je vois très clairement comment mettre en place le quizz pour l'adapter à ton cadre et sans recharger la page à chaque question, autant la description c'est vraiment -le- truc qui n'est pas clair pour moi.

Pour les questions du test, il suffit d'associer automatiquement des questions aux mot-clés par exemple. On montre par exemple une image du poisson, et la question est : "Est-ce que le/la {nom du poisson} est {couleur du poisson} ?". Réponse binaire.

Concernant les photos, l'IP, le nom, le prénom et l'adresse email peuvent être falsifiés facilement. Donc d'un point de vue responsabilité, c'est pas si simple de gérer quelqu'un qui veut vraiment être relou.

Pour la gestion des images par Wikipédia, va par exemple ici http://fr.wikipedia.org/wiki/Fichier:Tuna.jpg. La licence de l'image des thons est copyleft. Par contre, en lisant le cadre rouge, il est clairement noté que sa vraie licence est à débattre. Donc il faut faire gaffe de préciser la provenance d'une image pour au moins pouvoir vérifier en cas de problème.

Stephjaune

Comprends pas, le format n'est pas mac et saut de ligne... Il faudrait qu'on test des fichier pour comprendre parce que c'est vraiment chiant ce problème.

J'ai compris ta demande d'image par calque :o) C'est une magnifique suggestion, ça me permettra d'éviter de perdre un temps fou. Je passe plus de temps avec mon pseudo html css que sur le graphisme.

Le libre accés des données ou la modification des images est un problème à résoudre avant de commencer. Je pense qu'on aura beaucoup de "donateur" d'image quand le site sera lancé. Il faut penser à mettre un lien vers leurs site ^^ J'imaginais en bas au lieu de admin un accès pour proposer une fiche, des fiches de mot clé et des fiches de poissons (ou autre truc sous marin). On ne sépare pas poissons et autres dans la recherche (identification).

Pour l'orthographe, je pense que beaucoup d'internautes (plongeurs + photographes) y sont sensible. C'est une couche socio professionnel +++. Je fais confiance à la correction par l'utilisateur. Maintenant le soucis est comment mettre en place un système permettant l'utilisateur de corriger en évitant les abus (spam et autres) ? A la main fiche par fiche, on va vite être confronté au problème souslesmers.fr

Alors, qu'entends-je par description ?... Et bien, euh. Rien. C'est très vague mais pas du tout un wiki. Même les fiches de sous la mer me semblent trop chargées. Je vois le jeu accessible par téléphone donc textes très courts, une image et c'est tout. L'idée des onglet est grandiose !! En tout cas les mots clés n'ont pas besoin d’apparaître.

Je vais essayer de te faire une mini maquette des pages. C'est plus simple. Tu pourras alors me donner ton avis.

PS : Si des idées nouvelles se dégage de cette page de discutions, j'essaye de les mettre sur la page de l'article. Peux-tu le faire aussi, j'ai l'impression d'oublier pleins de trucs...

Idée : installer un mode connection pour les photographes.

La recherche dans le site souslamer chie,... je tape requin blanc ça trouve rien, je tape requin, j'ai en premier une etoile de mer et 2eme un gobie...

Euh pour les photos il faut des petites images, taille à définir, poids aussi mais 100 ko me semble suffisant. (à tester)

Pour le caractère éducatif du site lors des questions, il pourrait y avoir : Est il de l'espèce X (X étant incompréhensible pour le néophyte il faut ajouter une brève description). Par exemple : appartenant-il à la famille des Sphyrnidae ? (espèce à tête très aplatie avec les yeux sur les côtés) avec une petite image explicative

...d'où l'intérêt des fiches familles ou fiches mot clés

Qu'est ce que t'en dis :

Jeet

Je suis occupé jusqu'à vendredi, pas le temps de répondre.

Les sauts de ligne c'est à la création d'un fichier. Donc crée un fichier, et regarde ce qui est marqué en bas à droite. Une fois que je l'ai modifié, ça ne bouge plus.

Les poissons peuvent être à deux profondeurs différentes, ou c'est toujours entre a et b ? Pense au choix de l'image de la description principale, et comment gérer 50 images différentes pour un même poisson.

Tu penses à un site sur téléphone, ce qui me pose problème c'est la largeur fixe. C'est -le- truc vraiment relou à gérer.

Comme cette page a été vue par Google, le site poissonix est référencé. J'ai rajouté un robots.txt, je ne sais pas quand il va être pris en compte.

Pour les images, ça se redimensionne à la volée en php. On peut toujours générer des miniatures, et changer la résolution selon que l'on soit sur ordi ou téléphone. Le problème c'est surtout la taille de l'original (prend trop de place sur le serveur ?).

Le bandeau supérieur est bizarre. Je ne sais pas ce que ça donne sous téléphone. Faut peut-être cacher le background dans le css pour les téléphones (faible bande passante), le garder quand on est sur ordi. Même plus radical, on ne garde que l'intérieur du cadre pour les téléphones (que l'information importante). Le reste c'est que de la déco, et me pose problème à cause de la largeur fixe. Pour un ordinateur, je ne pense pas que ce soit un soucis.

Concernant le contenu justement. Limiter les téléphones à la recherche de fiches éventuellement. Je ne sais pas si faire 20 questions de quizz c'est une bonne idée pour la bande passante. Au début je pensais faire ça en dur, puis rajouter du javascript (à chaque réponse, l’intérieur du cadre se translate vers la question suivante sans recharger la page). Le problème, c'est que les téléphones ne peuvent pas utiliser (ou rarement) le javascript. Ça oblige à recharger plein de fois la page, au lieu de récupérer tout en une seule fois. Ou sinon limiter les téléphones à des questions sans photos, pour afficher un questionnaire de 5 à 10 items d'un coup.

Bref, prévoir les différences pc/téléphone.

Stephvert

Poissons = fourchette de profondeur Largeur fixe ? Je ne pense pas qu'il soit nécessaire de faire un site spécial tél... Sauf si on fait une appli. Tu parles de bande passante mais ici on a généralement un assez bon débit avec le tél. L'image que j'ai mise au dessus s'affiche en moins de 2 secondes... Maintenant, si tu en as le courage c'est une bonne idée.

Pour le nom Poissonix, c'est provisoire. Mais j'ai pas d'idée. Le site que j'ai "fait", c'est juste pour avoir une idée graphique. Mais depuis que tu m'as parlé des calques. Je ne l'utilise plus. Je réactuliserai le site.jpg pour que tu vois la progression du design.

Le bandeau est bizarre ? site.jpg ou poissonix.wiki-fr.net ?

Toujours pour le tél, je pense à l'exemple Akinator. Son appli se connecte sur le net et recharge la page après chaque réponse. C'est sur qu'il y a une image qu'à la fin. C'est un dilemme, un des objectif du site est son caractère pédagogique. Apprendre les termes "techniques" de la bio avec une image est un meilleur outil qu'une simple explication. Mais une image peut être lourd et donc ralentir sérieusement la navigation... Je pense que des tests peuvent être bien venus.

Dans la partie tests 10 ou 20 questions, je pense qu'on peut laisser le choix à l'utilisateur.

Pour les mots clés... J'ai réfléchi (et oui ça m'arrive) et je pense que l'utilisateur ne doit peut être pas les créer. Il doit pouvoir créer des fiches mais les mots clés non. Ça risque d'être trop complexe à gérer. Enfin c'est toi le spécialiste. Par conséquent, il faut créer une zone Admin avec 2 niveaux : nous et des gens triés à qui on validerait l'accès. L'objectif de cette zone est une modérations ,donc nécessité d'alertes (alerte que l'utilisateur doit pouvoir activer avec plusieurs degrès suivant le nombre d'utilisateur ayant alerté), le second objectif étant la création de mots clés. Hormis les 3 onglets des fiches, il doit y avoir un 4ème onglet qui est l'onglet mot clé où on attribut toutes les caractéristiques du poisson permettant une recherche efficace.

Si je ne me trompe pas s'il y a 100 mots clés, il peux contenir 1267650600228229401496703205376 poissons (c'est faux mais bon)... Créer 100 mots clés c'est dans mes cordes :o) Pour commencer leur recencement, j'ai ajouté la partie Mot clés dans la page Poissonix

Nouvelle page wiki avec les pages : Pages poissonix

Jeet : aspect graphique

Toujours pas le temps.

Pour tout ce qui est design, réfléchis à un site extensible : si c'est plus petit que la largeur du corps central, faire en sorte que tout se réordonne. Le plus important, c'est qu'il soit extensible verticalement (suffit de modifier la taille de police par défaut pour que le design éclate sinon).

Grosso modo, lis les tutos de http://www.alsacreations.com/tutoriels/. Tout ce qui touche aux media queries (http://www.alsacreations.com/article/lire/930-css3-media-queries.html). C'est assez bien supporté actuellement (seul IE jusqu'à la version 8 fait chier : http://caniuse.com/#feat=css-mediaqueries). Le but serait de faire le CSS global, puis de le raffiner pour une largeur d'écran inférieure à la largeur de ton espace central dans un premier temps, puis pour quand les boutons sont trop proches. Le mode landscape peut être pris en compte. Je ne sais pas si qu'il se passe quand tu zoomes et dézoomes avec l'iphone. Regarde les exemples en redimensionnant ton navigateur pour comprendre. C'est assez flexible, donc faut y penser dès le départ. Si tu redimensionnes le site d'alsacréations, tu verras que des images disparaissent quand ça devient trop petit. Regarde son site à lui http://goetter.fr/, quand c'est trop petit, son menu se colle en haut pour prendre moins de place. Bien qu'il devienne déroulant, tout est en CSS, pas de javascript. Une de ses présentations qui peut te guider un peu : http://www.slideshare.net/goetter/adapter-un-design-au-web-mobile-grce-aux-css-confoo-2011.

Tu dis qu'il y a un truc qui ne va pas dans le design, regarde par ici : http://www.alsacreations.com/article/lire/1196-grilles-framework-css-webdesign.html.

Ça aussi, mais tu connais déjà : http://www.alsacreations.com/article/lire/1183-mockup-rough-maquette-zoning.html.

Bref, lis un peu le site pour te faire une idée de la conception web actuelle, il s'est passé pas mal de choses.

Encore une fois, le plus important reste le contenu du site. Les inscriptions et classements ça vient après, si on estime ça utile. Il faut absolument définir de façon exacte toute la gestion du contenu, et son interaction avec l'utilisateur.

Concernant le réseau neuronal, je pense avoir une idée grossière de comment il a été fait. Quand j'aurai le temps, j'essaierai de me pencher sur les zones d'ombres. Y a quelques points qui ne sont pas très clairs pour moi. Ça me pose un gros soucis pour pouvoir le tester en fait (apprentissage automatique).

Stephjaune

Pour le design, c'est bien de cette façon que j'ai commencé à réfléchir :

1. cahier des charges
2. Espèce d'organigramme des pages
2. Gribouillage
3. test
4. re-gribouillage
5. Améliorage :o)

Après de multiples essais, j'ai fait cette page d’accueil qui me parait sympa. Propre, net et claire sans être austère...
...je suis content de moi en attendant tes remarques.

J'ai parcouru le site dont tu fais référence et c'est ça que j'essaye de faire ^^
Comme tu me l'as suggéré, j'ai arrêté de tester en html + css car ça me prenait des heures pour un résultat...
...disons, à la géographix. Sympa mais bof.
J'ai donc utilisé GIMP pour dessiner ce début de site. Chaque image est un calque, même chaque texte, tout est modifiable.
La partie "corps de page + titre" s'adapte très bien à un iphone. La taille du texte est bien adaptée.
Enfin, je te mettrai une image "vue de l'Iphone".

Je suis d'accord avec toi en ce qui concerne le contenu. C'est la partie la plus importante du site.
Par exemple le mode multilingue est à prendre en compte.

Je pensais que toutes les zones d'ombre ont été discutées.
Euh, je compte continuer le design des autres pages du site, peut être que comme ça je répondrai à tes questions.

Sinon, tu peux me poser des questions précises. J'essayerai d'y répondre précisément.

Pour la gestion du contenu... Si tu parles de la création des fiches et bien je pensais à une page création accessible soit en fin
de "jeu". Soit à partir de n'importe où, un lien en bas de page par exemple.
Cette page, je l'imagine très simple. Un peu du genre formulaire du site des volets avec en plus des menus déroulant.

Je conviens que la difficulté réside dans le traitement de ces données...
A la main, même avec des validateurs, on sera très vite limité.

Peut être une simplification des fiches est un premier pas...
...supprimer la description simplifierait peut être ce traitement.
Sans description, l'utilisateur supprimera les erreurs et avec le temps les fiches ne seront plus modifiées.
Il est possible d'automatiser la création du lien wikipédia (enfin je pense)
La seule source restante d'abus est l'image avec ces infos.

Perso, la description est un plus mais pas forcement intéressante en soit.
Un lien wiki permet une source d'info bien plus précise, l'objectif du site est l'identification et un peu la compréhensions de termes.
Ces objectifs sont réalisés sans description.
Plus j'y pense moins elle me parait nécessaire. C'est surtout une source de tracas qui disparaît ^^

Pour la suite, je pense continuer à faire les designs de toutes les pages. Bien sûr, des modifications auront lieu mais on aura un squelette.
Ce qui serait cool, c'est de transformer ces dessins en html css, dur dur, j'ai besoin de toi.
Ensuite, il faut remplir un peu la bdd. Je m'en occuperai comme ça tu pourras commencer à bosser sur les logarithmes du mode identif.
Une fois, cette mini base créé (100 ou 200 fiches), je poursuivrai l'amélioration du design.

Qu'en dis-tu ?

Ça avance :Pages poissonix  :o)