Extraits et chapitre

Bonjour les dev,

J'arrive avec une question/suggestion un peu "importante" donc je vais tenter d'expliquer ça clairement

Contexte

Pour moi la production du contenu est la partie la plus importante du site. C'est celle qui tracte notre visibilité et notre existence sur les internet. La partie rédaction doit être agréable pour les auteurs. Rédiger un contenu est déjà assez compliqué comme ça, l'outils de rédaction doit lui réduire au maximum les nuisances.

Malgré toutes les capacités du backs et du système assez souple que l'on a, la rédaction n'est pas spécialement connu pour être le module le plus policé du site. Donc j'aimerai qu'on hésite pas à discuter de ce module car c'est vraiment important.

Ma remarque

Je vais faire une première remarques et suggestion. La première chose qui m'a toujours gêné est fondamentalement le découpage en extrait. Je trouve ce découpage trop fort. Un extrait est régulièrement court. Les peu de fois où j'ai rédigé j'ai trouvé pénible de devoir switcher d'extraits si souvent.

A mon sens l'unité atomique devrait être le chapitre. Je trouve ça sur-découpé que pour faire un mini-tuto ou un chapitre ou un article, je doive éditer plusieurs extraits. Pour moi tout un chapitre/article/mini-tuto devrait s'éditer sur une même page.

Questions

Avant tout, pour la communauté, suis-je le seul à penser que ce découpage est trop important et qu'éditer un chapitre d'un coup serait plus pratique ?

Après, pour les développeurs, mis a part les raisons historiques, quels sont les raisons techniques qui peuvent justifier ce découpage ? J'en vois 2 :

1. Avoir les titres du contenu pour générer le sommaire,
2. Permettre de déplacer/supprimer les extraits depuis l'interface de visualisation du contenu.

Suggestion

Vous vous en douter, je propose de supprimer ce découpage. Concernant les 2 raisons techniques pré-cités :

1. La dernière version du markdown permet d'extraire la table des matière et d'ajouter des ancres sur les titres donc ce point peut facilement être réglé.
2. Je pense, personnellement, qu'il est aussi simple de faire ces manipulations à la main dans la zone de texte plutôt que d'utiliser la mega-combobox qui devient vite complexe.

Migration technique

Le plus gros problème pour moi là dedans et la migration du contenu car "coller" les extraits demanderait de décaler proprement les titres du markdown pour rattacher les extraits. C'est pas simple mais je pense que je peux faire un script temporaire même si on a pas encore d'AST.

Vous en pensez quoi ?

Tu proposes donc que l'édition d'un mini-tuto fasse éditer tout le tuto plutôt qu'une sous-partie ? Si c'est le cas, je suis contre. Je trouve déjà pénible de devoir gérer la mini-boite qui sert à taper (je la ragrandis, mais elle retrouve sa taille lorsque je fais une prévisualisation), alors si elle doit contenir trois ou quatre fois plus de choses…

Si je grossis la zone d'édition pour qu'elle prenne toute la hauteur de la page, j'observe qu'un extrait fait typiquement 5 écrans chez moi. C'est déjà pas mal. Tu proposes de la passer à 15. C'est trop.

De plus, cela aurait un effet de bord très gênant : augmenter les conflits d'édition. Le système d'édition à plusieurs mains de ZdS n'est pas génial, et j'ai régulièrement eu des conflits d'édition lors de mes rédaction. C'est-à-dire qu'on a modifié en même temps le même extrait. Ai-je vraiment besoin de justifier que si on modifie tout un chapitre, ça va encore empirer les choses¹ ?

Bref, à titre purement personnel, je préfère largement la solution actuel.

Personnellement je partage l'avis de Kje, je trouve que l'outil actuel fait un peu usine à gaz et je trouve assez pénible de changer sans cesse d'extraits.

Mais la remarque de Gabbro sur le conflit d'édition n'est pas bête, j'y aurai pas pensé étant donné que j'ai jamais vraiment écrit en mode collaboratif. Cela dit ne s'agit-il pas de deux problèmes différents, qui demandent des solutions différentes ?

En attendant de trouver une réponse au second problème, la question serait d'arbitrer entre le gain en facilité de rédaction apporté par ce que propose Kje et les problèmes supplémentaires que ça apporte pour le contenu en multi auteurs. A titre personnel et n'étant pas multi auteur je pense que l'avantage l'emporte sur inconvénient.

Je n'avais pas pas pensé aux conflits d'éditions. Ceci dit :

• Le problème de la taille de la zone d'édition ne peut pas être réglé ? Il suffirait de la rendre plus grande par défaut quand on rédige dans un tuto, non ?
• Concernant l'édition un plusieurs, l'édition n'est pas bloqué durant une édition ? Ça peut ralentir la rédaction mais ça évite les conflits d'écrasement, non ?

Je crois qu'il y a certains contenus qui s'y prêtent bien au découpage en extrait, et d'autres au découpage direct en chapitre (c'était le cas des articles avant la zep12 par exemple).

Le plus sympa de mon point de vue serait d'avoir les deux modes. Je m'explique :

• Quand je clique sur « ajouter un chapitre », plutôt que d'avoir les zones de rédaction "introduction" et "conclusion", j'ai une troisième zone "extrait" dans lequel je peux tout rédiger.
• Si par contre j'ai besoin de plusieurs extraits, un bouton doit me permettre d'en rajouter un nouveau, et l'interface doit s'adapter en conséquence. Mais par défaut, on devrait être en mode "section unique", avec un affichage correspondant.

Cependant, les inconvénients de cette solution sont :

• les mêmes que celles de l'OP (et Kje énonce quelques solutions)
• auxquelles ont peut ajouter celles de Gabbro (rédac collaborative), mais la solution ça est la zep-08
• et aussi et surtout, qu'en tant auteur lors de la rédaction on aimerait bien pouvoir visualiser le rendu sans avoir à scroller tout le temps (ce qui risque souvent d'arriver si on peut modifier tout un chapitre d'un coup). La solution serait que le rendu soit à droite pendant que la zone de rédaction est à gauche, comme c'est le cas sur Zest Writer, sinon on perdra facilement en ergonomie avec ça.

Avant tout, pour la communauté, suis-je le seul à penser que ce découpage est trop important et qu'éditer un chapitre d'un coup serait plus pratique ?

Effectivement, le découpage est trop lourd.

Cependant il compense le fait que le markdown est illisible à la relecture (je pense notamment à mes cozesteurs qui rédigent des maths) et que sans coloration ou aide visuelle, c'est mission impossible pour se retrouver.

Il faudrait a minima de quoi indiquer la présence de titre dans le markdown (un peu plus gras ou gros, comme vous voulez), sinon on scroll sans cesse pour trouver un pauvre #.

Le problème de la taille de la zone d'édition ne peut pas être réglé ? Il suffirait de la rendre plus grande par défaut quand on rédige dans un tuto, non ?

Ce serait top …

Est-ce que déjà un simple éditeur de texte qui colore syntaxiquement le markdown saisi (sans le rendre) n'aiderait pas ?

Je suis d'accord, le découpage est lourd et ne donne pas envie de rédiger sur le site. Pire, quelqu'un qui rédige hors du site dans son éditeur favoris doit copier chaque extraits un par un, ce qui est fastidieux et donc à améliorer. Donc +1 pour l'idée.

Gabbro soulève deux problèmes contre le nouveau découpage moins fin : une interface déjà pas agréable avec des textes courts et une probabilité de conflits plus élevées. Dans les deux cas, ce sont des problèmes différents qui doivent être solutionnés de leur côté. Conserver un défaut pour contourner des problèmes existants ne va pas dans le bon sens à mon avis. Il faut penser la refonte du module de façon globale.

Donc si je résume les problèmes dans l'interface d'édition énoncés pour l'instant :

• Découpage trop fin, donc lourd à l'usage.
• Interface généralement non ergonomique (fenêtre trop petite, scrolls répétitifs pour voir le résultats, etc.).
• Conflits sur un tuto écrits à plusieurs (quel que soit le découpage, ce problème existe).

J'en ajouterai un qui pour moi est primordial :

• Pas de sauvegarde automatique (ou en tout cas rapide).

En effet pour sauvegarder il faut valider le formulaire, ce qui implique un rechargement de page, donc devoir rouvrir l'extrait si on veut continuer l'édition (donc retrouver où on en était…). Une sauvegarde automatique, ou au moins simplifiée (raccourci clavier, bouton qui ne recharge pas la page…) serait donc la bienvenue.

Mais ce sujet concerne avant tout le redécoupage en chapitre, donc tout cela est un peu HS. Mais je me répète, il faut penser la refonte de façon globale, les problèmes étant liés entre eux en général.

Je suis pas contre, bien au contraire, mais c'est pas non plus simple. Pour ça il faut :

• prendre un éditeur existant qui fait ça,
• rajouter le support de nos extensions,
• faire converger les parseurs pour qu'il y ai le moins d'incohérences possible entre les deux.

C'est pas impossible mais clairement je pourrais pas le faire seule. Je fais du js mais j'aurais du mal à rester motivé. Par contre clairement je peux aider.

Zestwriter aide pas à ce genre de problématique ?

Si, mais c'est un client lourd, là on parle de l'interface du site.

Mais ce sujet concerne avant tout le redécoupage en chapitre, donc tout cela est un peu HS. Mais je me répète, il faut penser la refonte de façon globale, les problèmes étant liés entre eux en général.

Perso je n'ai rien contre le faire diverger. Le truc est que si on discute d'une refonte globale, d'un seul coup, on va :

• Avoir un débat et un sujet qui fait 50 pages,
• Accoucher de specs qui vont nous obliger à tout revoir.

Ces deux points font qu'au final rien ne sera fait. Je pense vraiment qu'il faut faire évoluer ce module mais on a pas trop de solutions que de le faire de manière itérative si on veut que ça arrive. J'ai parlé du découpage mais si les conflits est un problème qui le bloque, travaillons sur ce point avant. Si c'est l'éditeur qui le bloque, allons dans ce sens.

Dans l'idéal on arriverai à identifier le premier point bloquant qu'on peut corriger indépendamment du reste sans que ça soit trop gênant.

En tant qu'implémentateur de la ZEP-12 je … M'en fout. Effectivement, ce découpage a ces avantages et défauts.

• Une des critiques qui avaient été faites était justement qu'il s'agissait de zdsite aiguée (je vous laisse chercher) tout en proposant l’extrême inverse, à savoir tout le contenu dans un seul et unique fichier. La solution ici est un peu un entre deux.
• Niveau performance, c'est moins de fichiers à aller rechercher dans le git. Même si en pratique, quand le contenu est publié, c'est déjà reconstruit en un seul HTML pour chaque chapitre.
• C'est, au contraire, plus dur de réaliser un sommaire, parce que ça veux dire passer sur les fichiers à priori. Même si zMarkdown fait (ou ferra?) le taf quand on visite un "chapitre", c'est plus dur quand on affiche une "partie". Y'a toujours moyen de s'arranger avec le manifest (imaginons par exemple qu'à chaque fois que le chapitre est modifié, il sois parsé pour en ressortir le sommaire), mais ça reporte la responsabilité sur le back-end de ZdS ou ZestWriter de bien faire ça.
• Y'a effectivement le problème de la taille de cette textarea, mais je suis pas certains que l'agrandir sois une solution (parce que scrolling). Par ailleurs, dans l'espace actuel qui est alloué à cette partie dans le design, mettre sur deux colonnes me semble pas très efficace (là ou ZestWriter a toute la place), donc l'un dans l'autre, la solution actuelle me semble malheureusement la plus intelligente.
• Y'a peut être moyen de partir sur une solution à la Wikipédia, qui basiquement propose les deux (édition de sections en particulier et de la page en général).

J'aime beaucoup l'approche de Kje. En l'état actuel des choses, je pense que la proposition du premier message apporte plus de désagrément que d'avantage. Donc atomisons pour qu'elle n'engendre plus de désagrément afin de n'avoir que les avantages. À la liste de ShigeruM, il faut rajouter un 5^e point, la lisibilité pointée par Holosmos.

Comme je crains que la résolution des conflits d'édition ne nous emmène trop loin, et que je doute qu'il y ait beaucoup à débattre sur la sauvegarde automatique, je propose de parler de la lisibilité et l'interface.

Un truc qui serait super, ce serait la possibilité, comme dans Zest Writer ou sur la plateforme de FunMooc, d'avoir un mode de rédaction plein écran : d'un côté le texte, de l'autre le rendu. Même si ce n'est pas fait en direct (tant qu'appuyer sur le bouton nous laisse au même endroit). Ça résoudrai d'un coup la question de la lisibilité des maths et de l'interface.

Notez qu'actuellement, faire un aperçu remet la zone de texte en tout petit et nous fait quitter la position actuelle, et il faut descendre pour voir si ce qu'on a tapé fait bien ce qu'on veut.

L'idée du mode plein écran est pas mal. Ça ne change pas l'interface actuelle pour les cas où elle est pratique et ça permet d'avoir un espace de rédaction sans distraction cote à cote au besoin.

On a bien un mode zen pour la lecture, on peut l'avoir pour la rédaction.

Les dev front, un avis ? Ca me semble faisable non ?

Au passage j'ai rien contre déjà rajouter un simple bouton "enregistrer" sur la page pour éviter les rechargements.

Pour avoir écrit cette monstruosité à l’époque où les articles n’avaient pas d’extraits, donc dans une zone de texte unique, je suis résolument contre la suppression des extraits dans l’état actuel de l’outil. Si un jour il est possible de :

• sauvegarder sans quitter la page ;
• prévisualiser sans perdre la position et la taille de la zone de texte ;
• ne pas avoir à se faire chier à redimensionner la zone de texte à chaque fois, celle-ci évoluant en fonction de ce qu’on met dedans ;
• limiter les risques de conflits d’édition,

alors je serai beaucoup plus réceptif à l’idée.

Je relance.

Pour faire avancer le sujet je vois deux modifications itératives qui semblent faire consensus pour déjà faciliter les choses :

• Prévisualisation asynchrone (pas de rechargement de la page)
• Un bouton de sauvegarde (idéalement aussi asynchrone).

Cela permettrai déjà de faciliter le processus d'édition. Si quelqu'un a des objections, c'est le moment, sinon je crée des tickets dans la journée.

edit:

Concernant les autres points cités par Dominus :

ne pas avoir à se faire chier à redimensionner la zone de texte à chaque fois, celle-ci évoluant en fonction de ce qu’on met dedans ;

Ça peut poser des problèmes lorsque l'extrait devient long. Tu va avoir une zone de 3km de haut. Si la prévisualisation est asynchrone, déjà, elle ne se réduira pas ce qui permet à tout le monde de la mettre a la taille qu'il préfère. On peut aussi faire une zone qui augmente toute seule dans une certaine limite.

limiter les risques de conflits d’édition,

Ça je ne sais pas quels sont les contraintes actuels ni les problèmes que ça pose donc je ne peux pas vraiment proposer de solutions.

Je tenais juste à rappeler un historique technique qui risque d'être casse gueule en cas de "on met une seule zone" :

aujourd'hui un extrait peut contenir des "titre de niveau 1" et le moteur se charge de les transformer en niveau 3.

aujourd'hui un extrait peut contenir des "titre de niveau 1" et le moteur se charge de les transformer en niveau 3.

Ça c'est facile a mettre a jour (un caractère à changer coté markdown, que je peux faire ressortir dans zds). Pour moi le vrai problème est la migration : il faut assembler les extraits avec l'application d'un décalage des titres. Ça me semble un peu casse-gueule tant qu'on a pas d'AST dans le markdown mais je compte regarder ce qui est possible.

C'est pour ça que je ne l'ai pas cité dans mon précédent message.

Encore une fois je suis partit d'une proposition mais le fond est que je veux améliorer l'édition par petite étapes. La prévisualisation asynchrone et la sauvegarde sans rechargement ni changement de pages semble plus important, plus simple à implémenter et ne pas poser de contre-indication. Donc c'est sur elles qu'il faut se prononcer.

La prévisualisation asynchrone et la sauvegarde sans rechargement ni changement de pages semble plus important, plus simple à implémenter et ne pas poser de contre-indication. Donc c'est sur elles qu'il faut se prononcer.

Oui et oui. Attention ceci dit à la gestion de conflits (genre, au lieu de dire "dernière sauvegarde, 30 secondes", y'aurai un "un co-auteur a modifié cette partie, impossible de sauvegarder").¹ Attention aussi au cas idiot de l'internet qui se coupe en plein milieu de tout (pour les gens qui travaillent dans le train, par exemple). Finalement, attention de pas générer un commit toute les 30 secondes, ce qui demande probablement de travailler avec la BDD (ou un fichier temporaire, mais pour ça je préfère la BDD).

Je ne veux pas faire de sauvegarde automatique (du moins pour l'instant) à cause de ces problèmes, je veux juste rajouter un bouton "Sauvegarder" a coté d'envoyer qui enregistre sans recharger la page. C'est une première étape plus simple.