Rédiger sur zeste, c'est quand même un peu compliqué

Après c'est mon avis

a marqué ce sujet comme résolu.

En fait, est-ce qu’il existe une interface de rédaction sur un autre site qui vous plait bien ? Ca permettrait de savoir vers quoi on voudrait tendre.

Looping

@firm1 On se retrouve donc simplement avec un nouvel espace vierge comme un document Word si je comprends bien ?

Pas nécessairement avec un espace vierge, mais quelque chose de plus léger que ce qu’on a aujourd’hui. Le fait est que le code de ZdS actuel est très orienté, "on structure (création des parties, chapitres, sections, etc.), puis on rédige", contrairement à un éditeur comme Word sur lequel on rédige ce qui nous vient à l’esprit, et la structuration peut arriver plus tard.

firm1

Word justement, je trouve que c’est une bonne interface.

Il y a un document (= 1 testarea), ce qui change, c’est la vue. On peut afficher un document avec la mise en forme, en mode plan ou non. Il est très facile de modifier la structure du document en un clic dans ce mode. On écrit le texte à plat, puis on peut indiquer "telle ligne est un titre1, telle ligne est un titre 2, etc".

Image utilisateur

Sur le markdown de GitHub, je bosse de la même facon. J’écris mon texte à plat, puis j’ajoute des # pour indiquer les titres.

Sur l’éditeur actuel :

  • il faut faire plusieurs clics pour passer d’une partie a une autre. (HS : la distinction partie, chapitre et section sert a rien), on n’a pas le document en une seule page
  • le textarea est tout petit dans le fenêtre, on dirait presque que ce n’est pas la partie la plus importante. On devrait avoir l’inverse : la majorité de la page qui montre le document, le reste ne devrait pas prendre autant d’importance dans l’interface.

Concernant les images, je trouve qu’il est pénible de devoir charger les images sur une interface séparée. Cela necessite plusieurs clics et faire sortir de la rédaction du document.

Il faudrait un systeme comme sur GitHub issue, ou l’on peut simplement prendre une image sur son ordi, le glisser dans le fenêtre, ce qui lance l’upload automatiquement, en ajoutant le markdown pour afficher l’image.

+5 -0

En ce moment on a une grosse carence de disponibilité côté devs. C’est d’ailleurs pour ça que la v27 n’est pas encore déployée sur la béta et que je n’ai pas lancé les différents éléments pour la v28 (notamment car il y a un choix de la communauté à faire sur les priorités).

Je n’ai jamais pris le temps de me lancer dans le bain du développement de ZdS, mais j’ai les compétences (du moins, un début…). Je suis partant ! (J’aurai plus de temps d’ici un mois et demi par contre… les examens, tout ça… et je ne pense pas être le seul ^^)

Pour l’interface, on peut s’inspirer de ça ? https://simplemde.com/

qwerty

Ça rappelle un peu Typora. J’aime bien l’idée. Je trouve que l’éditeur de Grav est pas mal aussi, dans le genre, et il est également du type « un document (= 1 testarea), ce qui change, c’est la vue ».

Cela dit il n’y a pas que l’éditeur qui compte, son intégration aussi (notamment lui donner peut-être un peu plus de place, d’importance, dans la page… mais ce sont des choses qu’ont déjà été dites, inutile de recommencer).

+2 -0

Pour le choix de la licence, elle est d’après moi effectivement très complexe, et il faudrait probablement combiner les deux systèmes (une page métadonnées ainsi que des questions permettant de choisir sa licence) ; renvoyer vers le site CC et laisser une liste déroulante est finalement plutôt rebutant (niveau UX, c’est très mauvais : aller sur un autre site (clic), trois clics, regarder la licence, retourner sur ZdS (clic), choisir dans la liste (deux clics)), alors que des questions intégrées sont très simples, quitte à préciser la licence choisie à côté et ajouter un lien vers son texte intégral.

Je rajouterais que l’interface complète est à revoir, d’après moi, pas seulement la page de création / administration d’un contenu, avec au moins des possibilités comme :

  • la gestion rapide des sections (sérieusement, c’est un calvaire de cliquer sur "monter" ou "descendre" pour les changer de place), il faut un système de drag’n’drop sur la hiérarchie globale ;
  • l’ajout d’images facilement (drag’n’drop aussi, le système de galeries devrait disparaître à moyen terme, ou être caché quelque part) ;
  • la mise en avant de mot-clés pour le référencement, choisis ou non par l’auteur ;
  • un véritable moyen d’ajouter du MD facilement, car là c’est une misère (je ne parle même pas des liens qui ne s’insèrent pas quand on presse "Enter" au lieu de cliquer sur OK) ;
  • un système WYSIWYG, pour voir ce qu’on écrit directement, parce que appuyer sur "Aperçu" tout le temps rebute, ou à défaut (car on en a déjà parlé, ça saturerait le serveur…) un aperçu actualisé automatiquement et mis à côté du champ texte ; notons que seul Wikipédia avait gardé jusqu’il y a peu un système en code et il s’en sont débarrassés récemment pour laisser place à un système ou il est possible de voir ce que l’on fait.

Si certaines choses ont déjà été mentionnées, tant mieux, je ne serais pas seul à le demander.

EDIT : Rien n’exclus de faire un système "avancé" pour les auteurs qui veulent garder une interface moins simplifiée.

+1 -0

J’estime que le markdown fait très bien son travail sans WYSIWYG et que le markdown et conçu pour être utilisé sans.

Je ne souhaite donc pas de WYSIWYG mais on ne sait pas si ça rebute des gens.

please pas de WYSIWYG, c’est une usine à perdre son temps dans des problèmes incompréhensible.

artragis

-1 pour cet argument (tout dépend de l’outil, c’est mal de généraliser OC aux autres WYSIWYG. Les CMS de type PHPBB s’en tirent bien).

Mais sachant que le zmarkdown comporte des particularités, il serait nécessaire d’avoir un WYSIWYG personnalisé, ce qui demande beaucoup de travail de mise en place et de test, ce qui est difficilement réalisable, car on a du mal à trouver des contributeurs, surtout en front et en JS spécialisé. Ajouter un WYSIWYG obligerait à l’équipe de zeste de savoir d’avoir les moyens humains pour le faire et à suivre la compatibilité avec les différents navigateurs. Par exemple : https://github.com/sandhose/zds-editor un simple éditeur ne trouve pas repreneur.


Pour revenir à l’argumentation, l’une des véritables raisons à la non-adoption d’un WYSIWYG (que j’ai appris en janvier 2015) c’est que l’équipe du site ne veut pas cloner, c’est-à-dire avoir deux versions, de leur parser autre que leur zmarkdown en phyton, au cas où le markdown de zestedesavoir changerait. Ce qui selon l’ancien DTC du ZDS, si je prends note de ce qu’il m’a dit durant l’intégration des smileys Clem’ (mi-2017), est impossible car il y aurait beaucoup trop de messages à traiter pour le changement. Il ne peut donc avoir que des ajouts de nouveaux markdowns et quasi aucune modification du markdown existant. Pour les ajouts, il y en a pas eu après 3-4 ans et il suffirait juste de suivre une procédure d’ajout. Après réflexion je pense que l’équipe du site est resté marqué au WYSIWYG d’OC.

Ensuite ça vaut un peu pour tout le monde, dont l’équipe du site (même ceux dans l’espace). Je voulais en arriver à :

La crainte c’est que le Markdown change. Après 3 ans, j’attends encore ce changement. Si un jour, un membre qui ne fait pas partie de l’équipe du site, vient poster une PR avec un WYSIWYG conçu spécialement pour le zmarkdown attendait un peu avant de le descendre. Essayez sa solution avant de lui dire non avec des arguments discutables.
Si sa solution fonctionne, ne bogue pas et que vous ne la voulez toujours pas, jouez la fine. Proposer une option activable dans le profil/paramètres, désactivée par défaut. Ajoutez une même mention "EN BETA" si ça vous fait plaisir. Mais je vous en pris ne dite pas non par réflexe. Je suis sûr qu’une tel fonctionnalité peu plaire à des internautes.

En fait, les WYSIWYG que je connais produisent directement du HTML, qui est généralement moche (y compris celui d’un logiciel aussi utilisé que Wordpress). Pire : le WYSIWYG est souvent prétexte pour y coller un contenu issu d’un éditeur de texte, et là le résultat passe de moche à ignoble.

On ne peut donc pas se permettre de proposer un système partiel là-dessus : par exemple, un utilisateur de Markdown ne pourra pas pas citer un message écrit par un utilisateur de WYSIWYG, puisqu’il n’y a pas de Markdown à citer… et ce n’est qu’un exemple.

Bref, il faudrait un WYSIWYG qui génère du markdown pour que ça fonctionne. Ou une combine dans le genre.

(Au-delà de ça, j’ai l’impression que tu es resté coincé sur ta PR refusée. Passe à autre chose, ça fait plusieurs années !)

-1 pour cet argument (tout dépend de l’outil, c’est mal de généraliser OC aux autres WYSIWYG. Les CMS de type PHPBB s’en tirent bien).

bizarrement je pensais justement aux WYSIWYG de phpbb, ou même de wordpress, techniquement, j’évite de comparer OC car il y a trop de passion à propos de ce site.

LE système affichage en live me semble le bon compromis (je me répète). Ou un affichage type simplemde qui est hybride. C’est du markdown mais en un peu plus travaillé (difficile à expliquer, faut le voir).

+3 -0
  • la gestion rapide des sections (sérieusement, c’est un calvaire de cliquer sur "monter" ou "descendre" pour les changer de place), il faut un système de drag’n’drop sur la hiérarchie globale ;
Titi_Alone

Si tu regardes l’image que j’ai donné plus tôt sur le mode Plan de Word, je trouve que avoir des boutons n’est pas forcément gênant. (Je ne sais plus si Word autorise le D&D en mode plan).

Ce qui me semble problématique surtout, c’est d’avoir des boutons pour changer le plan sans avoir de vue globale sur le plan. Dans Word, c’est une interface spécifique pour le mode Plan, on voit la hiérarchie complète du document.

En premier lieu, je pense qu’il faut mettre en place ce mode Plan, pour faciliter la création et l’organisation du plan d’un article. Des boutons sont plus simples à mettre en place pour commencer. Puis, dans un second temps, ajouter le D&D si besoin.

please pas de WYSIWYG, c’est une usine à perdre son temps dans des problèmes incompréhensible.

artragis

Il était question un moment d’héberger les articles sur GitHub (je crois), c’est toujours d’actualité ? Si oui, ca permettrait de ne pas s’embêter, dans un premier temps, à proposer sur ZdS des outils qui existent déjà la-bas (éditeur markdown en ligne, gestionnaire de version, PRs, etc).

Et donc laisserait du temps aux devs de ZdS de proposer une interface qui a une vraie plus value pour les auteurs (c’est à dire, pour moi, une interface pour attirer les auteurs qui ne sont pas à l’aise avec le markdown). Parce que, au final, pour les auteurs qui préfèrent le markdown, ZdS ne pourra rien proposer de mieux que ce qui existe déjà.

Personnellement, je préfère rédiger sur GitHub (c’est ce que je fais déjà pour mes articles qui ne vont pas sur ZdS) et copier-coller le markdown ici, plutot que d’avoir une interface markdown ici. (Voire, ce qui serait encore mieux, ca serait de donner directement un lien vers un dépôt ou répertoire dans un dépôt de mon GitHub pour générer un article sur ZdS). Ca m’apporte strictement rien d’avoir un éditeur MD ici.

Je ne dis pas qu’il ne faut pas avoir un éditeur MD sur ZdS (ca reste mieux de ne pas devoir changer de site pour pouvoir rédiger), mais que dans un premier temps, un éditeur WYSIWYG serait une vraie plus value.

En fait, les WYSIWYG que je connais produisent directement du HTML, qui est généralement moche (y compris celui d’un logiciel aussi utilisé que Wordpress). Pire : le WYSIWYG est souvent prétexte pour y coller un contenu issu d’un éditeur de texte, et là le résultat passe de moche à ignoble.

SpaceFox

Je comprends l’argument du copier-coller qui fait de la mise en forme très moche. Mais je dirais que c’est un problème de validation, non ? Si l’article a une mise en forme qui ne respecte pas les standards de ZdS (parce que c’est un copier-coller d’une article HTML ou n’importe quelle autre raison), c’est à validateurs de refuser l’article et de demander que la mise en forme soit corrigée.

Par contre, en tant qu’auteur qui rédige sur plusieurs sites (et donc avec plusieurs formats), ca m’intéresserait de pouvoir facilement faire le transfert d’un article sur ZdS. Je préfère corriger les quelques erreurs produitent par le transfert automatique plutot que de me taper tout la mise a page en MD a partir de zero. On peut imaginer aussi un auteur qui utilise Word ou autre et qui voudrait importer directement son article sans passer des heures à faire de la mise a page.

Ce n’est probablement pas une priorité de mettre en place un tel système de transfert. Perso, j’utilise Pandoc quand je dois faire des conversions d’un format (wiki, word, html, etc) dans un autre (MD). Et ensuite je corrige les erreurs de transfert. Ca serait mieux que ce soit integré dans ZdS, mais ca peut etre fait plus tard.

Les auteurs ne veulent pas forcément se taper des heures de mise en page, d’importation d’image, etc. Si on perd un auteur a cause de ce type de problème technique, c’est dommage. (Anecdote : quand j’étais responsable C++ sur Developpez.com, je disais aux nouveaux rédacteurs d’écrire leur articles avec l’outil de leur choix, ce qu’ils préféraient. Et je m’occuper des merdouilles techniques à leur place. Et dans un second temps, quand ils étaient plus à l’aise avec la redacteur, ils pouvaient apprendre à utiliser progressivement les outils).

+1 -0

@Abdelazer Tu vas partir sur quoi ?

Je serais d’avis à simplifier en cachant le choix de la licence. Et expliquer par une phrase que la ou les catégories peuvent être choisies/modifiées plus tard. Sinon ton screen est parfait, surtout les schémas.


Bref, il faudrait un WYSIWYG qui génère du markdown pour que ça fonctionne. Ou une combine dans le genre.

Ma PR aurait été utile pour convertir du HTML en Zmarkdown. :lol:
(@SpaceFox : Oui)

bizarrement je pensais justement aux WYSIWYG de phpbb, ou même de wordpress, techniquement, j’évite de comparer OC car il y a trop de passion à propos de ce site.

artragis

Ah, j’ai du mal choisir mon exemple, je parlais de CKE_WYSIWYG. Je viens de voir que c’est un plugin de phpBB qui permet de l’intégrer.


@qwerty L’éditeur de code que sandhose a commencé doit pouvoir offrir ce genre de fonctionnalité (vu que c’est fait avec codemirror).

Le point que tu reprends en citation, à vrai dire, c’es un détail pour ZdS. Le vrai blocage, c’est que tout notre workflow tourne autour du Markdown : sans lui, je ne suis pas sûr qu’on puisse proposer les exports (PDF, epub…), pas sûr que l’historique soit encore utilisable, etc.

@A-312 : Je m’en souviens très bien de cette PR, c’est moi qui l’ai refusée…

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