Je prend ma casquette de staff car je vois que ça s'échauffe un peu sur le topic, si on peut discuter comme de grandes personnes ça serait super. Donc je vous encourage à éviter de hausser de ton (il y a les MPs pour ça) . Pensez un peu à ceux qui vous lisent.
Sinon, pour en revenir au sujet.
Je vais utiliser un exemple. Prenons le cas du tutoriel Développer et publier une app Android Material Design. Le chapitre 2 à la particularité d'avoir des prérequis, je trouve moins élevés que le reste. ça serait dommage que le chapitre soit surestimé parce que le tutoriels est d'un trop haut niveau.
De plus, on arrive très souvent sur les chapitres de ZdS en cherchant de puis google. Quand je cherche par exemple Intégrez un menu latéral en Material Design sur Google on me propose directement la vue sur le chapitre. Si le chapitre à été surestimé a cause des autres chapitres, ça risque d'introduire un biais du point de vue du lecteur.
Pour finir, séparer les contenus parce qu'ils ont des prérequis différent n'est pas forcément une bonne chose (cf. les tutoriels de MicMacths par exemple)
Étant donné que cette ZEP nécessite peu de dév, peut-on envisager de lancer une première version rapidement, quitte à mettre les parties qui font débat facultatives jusqu'à consensus ?
Je pense en effet qu’on peut lancer une première version partielle dès maintenant. Au vu des retours, je dirais ceci :
les blocs de prérequis sont rendus désormais obligatoires sur les tutos, simplement conseillés sur les articles et tribunes libres lorsque cela s’y prête, et les auteurs sont fortement encouragés à mettre à jour leurs anciens contenus ;
la question des ceintures est reportée en attendant plus ample discussion ;
le sceau « adapté aux jeunes lecteurs » est adopté, les auteurs qui souhaitent l’adopter sur un de leurs contenus n’ont qu’à demander aux relecteurs/validateurs de vérifier qu’il respecte effectivement ce critère ; dans l’idéal, il faudrait un joli logo à mettre dans l’intro, genre, à la fin du bloc de prérequis ;
l’idée d’un sceau « conforme aux programmes » est abandonné ; si les auteurs veulent s’organiser pour faire des cours correspondant aux programmes, ils restent bien évidemment libres, mais ZdS n’apportera pas sa caution à la validité de leurs affirmations.
Est-ce que cela vous semble correct ? Votez, et dites ce qui ne va pas si vous votez -1.
les blocs de prérequis sont rendus désormais obligatoires sur les tutos, simplement conseillés sur les articles et tribunes libres lorsque cela s’y prête, et les auteurs sont fortement encouragés à mettre à jour leurs anciens contenus ;
J'arrive après la bataille, mais pourquoi rendre le format bloc obligatoire ? Quand je vois tes tutos mis à jour, ça fait trop "liste scolaire" pour moi.
Je dirais plutôt que les prérequis doivent être présents, d'une manière ou d'une autre, dans l'introduction. De même que les objectifs, la démarche si elle est originale… Enfin, plutôt que de parler d'objectifs, je dirais au moins dire jusqu'ou va le tuto dans le domaine considéré (est-ce une introduction, un exposé exhaustif ?). Donc si ces infos sont dans l'introduction, ça devrait être bon non ?
Par exemple, sur "la conjugaison de l'allemand", le bloc fait carrément doublon avec l'introduction, où toute ta démarche est déjà bien expliquée, et même mieux expliquée. Par exemple, l'avertissement
"Ce cours s'adresse essentiellement à des gens qui ont déjà une certaine connaissance de l'allemand et voudraient la renforcer. Non pas en raison de la complexité de son contenu, mais parce qu'il serait contre-productif pour un débutant total d'ingurgiter toute la morphologie verbale d'un coup sans maîtriser d'autres aspects de la langue. "
n'est absolument pas visible dans le bloc prérequis, qui devient inutile lorsqu'on a déjà lu l'intro.
Dans un cas comme dans l'autre, les validateurs auront de toute façon la charge de demander à l'auteur de préciser ces infos.
J'arrive aussi un peu après la bataille avec 3 remarques :
je suis d'accord avec looping : pourquoi le rendre obligatoire ? Si l'intro joue bien le rôle ?
une semaine c'est court pour décider de ça.
Cette décision pour moi tiens plus de la ligne éditoriale que du dev et ne devrais pas avoir lieu dans une zep. Ce n'est pas le bon forum. Les membres de l'association et, surtout, les premiers concernés que sont les auteurs ne les lisent pas forcément.
Donc à titre perso je suis contre : c'est une décision prématuré et le débat devrait avoir lieu ailleurs qu'au fond d'une zep
Pour préciser un peu mes propos : je ne suis pas fondamentalement contre la zep. J'aime l'idée de champs sémantiques fort. Je m'interroge un peu sur le coté obligatoire mais j'en ferai pas une crise.
Ce qui me gène c'est de prendre la décision en une semaine dans un sujet censé concerner les dev et non les auteurs qui sont les premiers concernés.
Moi j'aime bien l'idée du bloc. Ça permet de rendre visible (grâce au fond bleu du bloc) facilement ces informations au lieu d'avoir à les trouver éparpillées dans l'introduction.
Faut pas abuser, une intro fait rarement plusieurs paragraphes. Lire quelques lignes (qui devront être lues de toute façon si on poursuit la lecture) me paraît pas très contraignant pour le lecteur.
Un petit point sur le fait d’en parler en ZEP, avant de passer aux choses sérieuses. Je rappelle que la ZEP-20 est également une ZEP qui concerne plus les auteurs que les devs, et que la ZEP-25, bien qu’elle demande un peu de dev, concernait surtout les auteurs quant à la liste des catégories à conserver.
En ce sens, cela ne me paraît pas aberrant de passer par ce format pour la discussion qui nous intéresse. D’autant que j’ai annoncé l’existence de la ZEP sur les trois sujets qu’elle synthétise, prévenant ainsi ceux qui y avaient participé, et apparaissant en haut des listes de nouveaux messages dans Le Bar à Smoothies et Bugs et Suggestions. À part une apparition sur la page d’accueil, je pouvais difficilement faire plus.
Maintenant, revenons à nos moutons, concernant le format bloc.
Oui, c’est « scolaire ». Oui, ça se répète avec l’introduction. C’est le but.
L’introduction et le bloc de prérequis ne s’adressent pas aux même personnes. L’introduction est prévue pour être agréable à lire, être rédigée, avoir de belles phrases, etc. Mais du coup, d’une intro à l’autre, les informations clés ne sont pas au même endroit, dans le même ordre, etc. Le bloc de prérequis, lui, est formalisé, avec des champs bien balisés, pas de fioriture, et un accès direct à l’information que recherche un lecteur qui cherche à déterminer en dix secondes s’il va lire votre contenu ou non.
Cette version formalisée des informations essentielles de l’introduction facilite en outre la comparaison de deux contenus similaires.
Malheureusement, c’est ce genre de remarques qui nous (oui, je m’inclus dans le lot) font traiter d’élitistes par une partie de la communauté…
Maintenant, si vous avez une meilleure solution pour que les informations soient clairement repérables et organisées et plus jolies que le bloc bleu (perso, j’aime bien), libre à vous de faire une proposition.
C'est le caractère obligatoire et le style imposé qui m'ont fait tilter.
Oui pour les rendre visible, mais a la limite je peux vouloir mettre un bloc Erreur (du genre "Attention, si vous n'avez pas lu le tuto sur les navets, vous ne comprendrez absolument rien a ce tuto sur les betteraves").
A l'inverse si l'introduction parle d'elle-même, inutile d'en rajouter (surtout si le code ceinture couleur est adopté, idée que je trouve très cool)
Voir par exemple le blog "Image des maths", ou on a piste verte, piste rouge et piste noire pour les niveaux des articles.
Donc code couleur + introduction bien faite, ça me semble suffisant dans la majorité des cas. Après pour les cas spécifiques, à l'appréciation du validateur, on peut en mettre plus.
Malheureusement, c’est ce genre de remarques qui nous (oui, je m’inclus dans le lot) font traiter d’élitistes par une partie de la communauté…
En l'occurrence je préfère être traité d'élitiste que de produire du contenu à la forme contestable. Se répéter deux fois en l'espace de 5 lignes pour d'autant plus avoir un bloc moche et mal rédigé (mais court), je ne suis pas pour.
Sur le fond je suis pour indiquer clairement les pré-requis. Mais je ne comprends toujours pas pourquoi ça serait une nécessité d'en faire un bloc supplémentaire et contraignant.
Pour ma part, je suis plutôt pour imposer une indication claire des prérequis dans les introductions, mais plus sous forme de texte séparé que sous forme de bloc (ou alors il faudrait un bloc léger et préformaté, qui ait son propre bouton d'édition).
En fait, je pense à quelque chose semblable à ce que j'ai fait sur mon tuto sur les disjoncteurs (https://zestedesavoir.com/tutoriels/1052/comment-marchent-les-disjoncteurs/), en rajoutant pourquoi pas les connaissances qu'apporteront le tuto, et pourquoi pas un bloc "Erreur" comme l'a suggéré Looping si c'est pertinent.
Pour le code couleur, ce serait vraiment cool, mais il faudrait trouver un moyen de bien l'intégrer dans les listes des tutos.
Contrairement aux réactions précédentes, je trouve que placer les pré-requis et autres informations pédagogiques du même genre dans un bloc séparé est une bonne idée. En effet, elles n'ont rien à faire dans l'introduction. L'introduction d'un cours doit introduire le sujet du cours, et non du cours lui-même. On doit y retrouver un aperçu des connaissances abordées dans le cours, introduire le sujet du tutoriel d'une manière qui complète et développe le titre, éventuellement poser le contexte du cours, etc. Mais les informations sur les pré-requis, l'approche et le reste sont des informations purement pédagogiques, non-liées au sujet du cours : il est ainsi possible que deux cours abordent le même sujet avec des pré-requis ou des objectifs différents, tout en gardant la même introduction.
A titre personnel, j'ai commencé à modifier mes cours pour y placer un cartouche (une balise attention) pour les pré-requis et autres. Je trouve que cela rend bien et que ce n'est aucunement redondant avec l'introduction. J'ai aussi remarqué que les sections objectifs et démarche sont souvent très dépendantes et que les fusionner me parait souvent pertinent.
Techniquement les notions de pré-requis et objectifs ont des définitions sémantiques fortes. Il faudrait que d'un coté ce soit des champs dans les options du tuto (une zone de texte comme intro et conclusion). Après c'est à la charge du template et du CSS de les rendre proprement et au bon endroit. Ce qui peut être juste après l'intro, dans une partie dédié, sur un bloc de coté, etc.
On ne s'occupe pas des programmes scolaire officiels. Vraiment. Jamais. C'est un bordel sans nom et ça change tout le temps ; et surtout ce n'est pas l'objectif de ZdS. Si un auteur veut se baser sur un programme scolaire, OK, mais il assume de bout en bout. Quant à mettre un « sceau » ZdS, ça a trop d'implications (en terme de vérifications et de suivi) qu'on ne peut pas se le permettre à court et moyen terme. Déjà qu'on a du mal à valider les tutos sans ça…
+10'000. ZdS n'est pas un truc français. Si vous voulez pas vous prendre la tête à adapter cette section en prenant en compte les spécificités d'une vingtaine* de programmes scolaires francophones, on ne reparle plus jamais de programme scolaire dans ce topic.
*Oui, une vingtaine. Parce que des pays francophones y'en a un certain nombre, et dans au moins un de ces pays le programme scolaire est cantonal et pas fédéral et varie donc de 50km en 50km. (Je ne vise personne, suivez mon regard.)
Je vais me répéter, mais l’intérêt d’un bloc de prérequis, c’est de permettre au lecteur de se faire une idée le plus vite possible du contenu. Pour atteindre cet objectif, il est indispensable :
qu’il soit immédiatement repérable ;
qu’il soit concis ;
que les infos essentielles y soient systématiquement présentes ;
que les infos soient toujours organisées pareil, pour ne pas avoir à aller à la pêche.
Voilà pourquoi ce bloc de prérequis doit être imposé à tout le monde, et avec un même formalisme, parce que entre ceux qui estiment que leur intro suffit, ceux qui estiment que les objectifs ne sont pas utiles, ceux qui préfèrent une balise attention, ceux qui préfèrent un tableau, ceux qui préfèrent un paragraphe spécifique, etc. on se retrouve avec le même bordel qu’avant et le gain en termes de lisibilité pour le lecteur lambda est nul.
L’idée de champs spécifiques, avec une mise en forme plus glamour que l’actuelle, éventuellement dans la colonne de gauche, etc. est intéressante, mais… elle nécessite du dev. Et c’est bien pour ça que je propose plutôt un bloc d’information : ça peut être mis en place immédiatement, et sans difficulté.
Mon problème dans cette histoire, c’est que ça fait au moins sept mois que la question des prérequis et objectifs a été soulevée, et que toujours rien n’est fait1 alors même qu’une première solution pourrait être rapidement mise en place, à la simple condition de ne pas faire d’obstruction.
Vous préféreriez une solution qui demande du dev ? Soit, c’est recevable ! Mais la v16 est encore en bêta, la v17 ne concerna que Django, donc dans l’hypothèse la plus exagérément optimiste, il y en a pour au moins un mois et demi avant que quoi que ce soit ne soit possible. Et rien ne dit que cela suffise à lever les réticences de ceux qui estiment que leur intro suffit…
D’autant plus que si tout le monde a le même formalisme (un même bloc, rédigé pareil, systématiquement placé à la fin de l’intro), lorsqu’un système intégré au site sera éventuellement développé, ce formalisme unique et simple permettra de transformer automatiquement les blocs existants en leur équivalent plus glamour. Donc pas de problème d’avoir à faire le travail deux fois !
Mes excuses à ceux qui ont accepté de mettre en place le bloc de prérequis, ma remarque est évidemment une généralisation grossière. ⋅⏝⋅ ↩
Mon problème dans cette histoire, c’est que ça fait au moins sept mois que la question des prérequis et objectifs a été soulevée, et que toujours rien n’est fait alors même qu’une première solution pourrait être rapidement mise en place, à la simple condition de ne pas faire d’obstruction.
Vous préféreriez une solution qui demande du dev ? […]
Toujours rien n'est fait parce que manifestement ça ne fait pas si consensus que ça. Je pense que la question du dev N'A RIEN A FAIRE LÀ. Oui c'est mieux pour tout le monde si le dev est simple mais ce n'est pas le fond du problème ici.
Si je suis bien les derniers arguments c'est le coté obligatoire et au style imposé qui gène le plus. On peut être d'accord, ou non, peut m'importe. Mais c'est la question à régler. On ne va pas imposer une solution "parce qu'elle est facile à développer".
Avec les quelques tutos qui utilisent le système de bloc (notamment ceux de Karnaj), on peut déjà voir un peu comment ça rend. J'étais un peu mitigé sur l'idée au départ, mais le voir en œuvre m'a convaincu que c'est la bonne direction.
Je rejoins Dominus Carnufex sur la nécessité d'avoir quelque chose d'harmonisé et visible au premier coup d’œil, donc les blocs me paraissent une bonne première approche pour éviter le dév. Cependant, toutes les infos sont juste des métadonnées, et ne devraient pas vraiment se trouver dans le contenu. J'ai l'impression que c'est ça qui coince.
Connectez-vous pour pouvoir poster un message.
Connexion
Pas encore membre ?
Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte