[chantier]Interface de création de tutoriel, article et billet, lifting 2/3

Salut,

J’appuie @Amaury sur un point : il faut que la création d’un contenu ne demande que le strict nécessaire, c’est-à-dire dire, pour moi, rien. Idéalement, un titre laissé vide se verrait attribuer un titre par défaut ou un placeholder, et le choix d’un type de contenu se ferait plus tard, à la publication par exemple.

Évidemment, c’est assez éloigné de ce qu’on fait techniquement, donc avoir un titre et un type de contenu (avec possibilité de changer automatiquement) est un compromis acceptable.

Beaucoup d’informations à la création tiennent du travail d’éditeur de Zeste de Savoir (catégorie, tags) et peuvent attendre la publication (tout comme par exemple la licence). D’ailleur, cça pourrait être au validateur de remplir ça, sur suggestion de l’auteur. D’autres choses peuvent tout simplement être supprimées ou transformées, comme l’aide aux auteurs, qui ne sert virtuellement à rien en l’état.

Un éditeur avec coloration serait un apport bienvenu.

Ces avis sont renforcés par des retours que j’ai eu en discutant avec une personne intéressée pour écrire sur Zeste de Savoir qui a regardé le site. Elle m’a posé des questions du type :

• je ne sais pas quoi choisir entre tutoriel, article et billet ;
• l’interface est compliquée, j’ai du mal à comprendre le système de partie, section, chapitre ;
• je ne connais pas Markdown, j’aimerais bien utiliser Word ou un autre Wysiwyg pour éviter de me prendre la tête sur la syntaxe.

Je ne lui ai pas parlé des licences, mais à mon avis, on devrait mettre tout droit réservé par défaut (et sélectionné comme tel), aux validateurs de promouvoir les licences CC au cours du processus de validation. En prime le système actuel complique l’usage d’autres licences…

Pour rendre moins indigent le système actuel, on pourrait par exemple :

• avoir un mode plan pour déplacer facilement des passages, qui prennent en compte tous les niveaux de titre de manière égale,
• pouvoir convertir de manière transparente les types de contenus, ou ne choisir qu’à la publication, sachant qu’en fin de compte, c’est surtout un choix de structure technique plus que de structure intrinsèque du contenu et donc devrait être invisible.

Un gros +1 à mes voisins du dessus, sauf pour la licence en copyright par défaut.

La raison est que l’expérience a montré (et montre toujours, cf linuxfr.org) que les auteurs laissent massivement la licence par défaut si elle est pré-choisie. Or, le "tout droits réservés" n’est pas tellement dans l’esprit de ZdS.

Mais il faudrait pourvoir choisir cette licence seulement à la publication (beta incluse).

@Amaury je ping @Sandhose et @A-313 qui avaient justement bossés sur un éditeur pour zds sur base de codemirror.

Ou plutôt @A-312

( En effet, il y a : https://github.com/sandhose/zds-editor )

Quid de mettre en place de l’édition in-place ? C’est-à-dire supprimer l’aspect technique de l’outil et le rendre le plus transparent possible, et la bascule édition / aperçu la plus rapide et légère possible ?

Ajouter une partie ? Un clic et hop, on est partis.

Aujourd’hui, l’interface est trop liée à la technique qu’il y a derrière.

Pour ce qui est de l’éditeur basé sur Codemirror : c’est une bonne piste, il faut juste faire attention à lazy load tout ça pour éviter d’avoir 1Mo de code JS en plus partout, voire dev quelque chose de plus léger (ce qui prend plus de temps que les contributeurs n’ont pas nécessairement, j’en conviens).

EDIT : Le poids de l’éditeur zds-editor est de ~100kb minifié + gzipé

Il faut séparer les méta du contenu de manière claire, et comme déjà dit les rendre optionnelles.

De mon point de vue, il faut penser le système en réfléchissant au déroulé de l’écriture des contenus : si les utilisateurs commencent par faire le plan, alors l’interface première doit être l’arbo avec du drag’n’drop pour tout réorganiser comme on veut, ajouter, supprimer des parties sans changer de page, etc. Encore une fois, tout ça pour que ce soit le plus transparent et fluide possible.

Evidemment ce que je propose là nécessite beaucoup de travail sur le front (surtout JS). Ce qui veut dire qu’il faut peut-être d’abord voir si des gens sont dispos pour dev tout ça avant d’en décider.

J’avais fais ça qui permettait d’éditer dans 2 fenêtres mais je ne sais pas si c’est une fonctionnalité attendue/souhaitée.

Pour avoir envoyé un article en validation hier, je confirme que de mon point de vue, si on a un moyen simple et rapide d’avoir ne serait-ce que seulement :

• des zones de rédaction de taille acceptable par défaut, et
• la coloration syntaxique du Markdown (je parle bien de colorier le markdown, pas d’avoir un aperçu du rendu en temps réel)

ce serait un énorme progrès par rapport à l’existant. Bien plus que toutes les autres modifications ergonomiques.

À noter que normalement si on rédige, on fait ça depuis un ordinateur et donc à priori pour la plupart des gens avec une connexion meilleure que la 3G d’un portable. Donc si ça nécessite de télécharger 1 Mo de JS, tant que ce Mo est limité aux pages de rédaction et pas étendu à tout le site, ça me parait être toujours rentable.

Petit bémol tout de même quand cet ordinateur est connecté via un wifi public / dans un train / etc., où le débit n’est pas toujours au rendez-vous. Mais j’imagine que ce genre de choses se met très bien en cache.

Je rédige mes contenus offline et pas seulement pour le ZdS (co-publication sur un blog, comme un document interne, sur LinuxFR…). Aujourd’hui je fais un fichier tout en markdown (ou org-mode, fichier texte simple, etc.), je versionne en local, et après je cliquote dans l’interface pour obtenir un résultat  — c’est le moment de gérer l’hébergement des images aussi. C’est assez facile au moment de la première publication d’un contenu, mais plutôt pénible si on veut éditer un contenu existant (problème de divergence entre ma version locale et la traduction sur le site).

Je n’ai pas d’idée géniale sur une interface améliorée, mais je pense que c’est un cas d’usage à considérer.

Une chose utile serait de pouvoir "mettre à jour" un contenu en faisant simplement un import d’une version modifiée. Le workflow du coup serait d’utiliser l’interface web pour le premier port du contenu sur le site, je fais un export, je versionne l’export chez moi, je le modifie au fil de l’eau, et je ré-importe mes nouvelles versions au lieu de passer par l’interface web. Aujourd’hui je ne trouve de bouton que pour importer un-e nouve-au-elle chapitre/section, pas pour remplacer le contenu.

C’est assez facile au moment de la première publication d’un contenu, mais plutôt pénible si on veut éditer un contenu existant (problème de divergence entre ma version locale et la traduction sur le site).

Ce n’est pas encore optimum mais on pourrait dans la version brouillon ajouter un bouton sur l’image pour rediriger directement vers l’image dans la galerie : https://zestedesavoir.com/galerie/image/editer/312/312/

L’autre solution en plus du bouton, serait de pouvoir directement drag’n’drop dessus la nouvelle image.

Personnellement je fais cela avec le bouton « Importer une nouvelle version » sur la page principale d’édition d’un contenu, ça fonctionne bien. Ça utilise le fichier manifest pour remplacer l’intégralité de la structure du contenu, donc j’imagine que ça répond bien à ton besoin (qui a l’air d’être sensiblement le même que mon cas d’utilisation).

L’idéal serait une interface à la SimpleMDE : un affichage du code/prévisualisation dans le textarea, et un redimensionnement automatique du textarea quand on écrit. Je l’utilise pour l’un de mes softs, et c’est le pied.

Je viens de voir ce sujet grâce au MP de A-312, et je plussoie férocement l’idée d’une grosse zone de texte, avec coloration.

Pour une maquette, j’imagine un truc un peu à la overleaf : un colonne avec que la zone de texte, l’autre avec le texte mis en forme. Comme je ne suis pas limité par la technique pour ma proposition, je vais demander une mise à jour automatique. Dans l’idée, on peut conserver la modification de la section seule, mais l’affichage devrait être l’affichage réel, donc de la partie. On clique sur une section, ou bien l’intro / conclusion, et on peut éditer dans la colonne d’édition.

Concernant la création, rien qu’en virant intro, conclusion, catégorie et recherche aide, on divise la hauteur de la page par 4.

Que pensez vous d’avoir une licence privée par défaut, et au moment de la publication/envois en validation, d’avoir une petit pop up avec Clem qui dirait un truc du genre :

"Hey, on voudrait te parler d’un truc maintenant que ton contenu est prêt à être publier : ton contenu est actuellement en licence propriétaire, cela veut dire que personne ne peut le copier sans ton autorisation. Sur ZdS, on essaye de promouvoir le partage le plus large possible du savoir, à l’aide de la license X. En fait, Y% de nos auteurs l’utilisent ! Pourquoi pas toi ? Tu peux cliquer ici pour aussi utiliser cette licence et aider au partage du savoir libre, et cliquez ici pour en savoir plus."

Avec la possibilité éventuelle de désactiver cette pop-up quelque part dans les options, et de choisir une licence libre par défaut.

Je pense qu’un nudge du genre est la meilleure solution, étant donné qu’il me semble plutôt normal d’avoir l’option propriétaire par défaut.

Personnellement j’étais parti sur "pas de licence par défaut mais au moment de la mise en béta ou de la demande de validation une modale qui apparaît et qui fait de la pédagogie".

Bonjour à tous, je relance le sujet car j’ai commencé à réfléchir à tout ce qu’il y a à faire.

J’ai donc regardé la faisabilité de chaque chose que j’ai pu voir (j’en ai peut être oublié, si c’est le cas dites-le je modifierai le message).

L’éditeur dans une deuxième fenêtre

La gestion des popups (est vraiment efficace quand on sait s’y prendre). Notamment :

• Si la page parente change, on peut décider de fermer la popup, de continuer l’interaction avec la page parente (cibler un nouveau contenu à éditer ;
• On peu redonner le focus (mettre au premier plan) la popup à partir de la page parente (via un bouton ancrer dans le mouvement de la page cad reste visible)… Donc ça ne complexifie pas la gestion des fenêtres.
• Si on a 3 parties, on n’est pas obligé d’avoir 3 éditeurs de zmd mais juste une popup et sélectionner de façon automatique ou manuelle quelle partie éditer.

Etat pending en plus du brouillon

Si on ajoute de l’ajax, je verrais bien l’état pending.

(A partir d’ici je n’ai jamais fais ce que je propose ci-dessous, ni le temps de la mise en place).

Je pensais aussi à l’état "Pending" (c’est-à-dire actualisé mais non sauvegardé), en plus du brouillon. On pourrait même utiliser la fonctionnalité de stockage hors-ligne pour le pending du navigateur pour enregistrer le versionnage (de chaque aperçu ou après 2 à 5 minutes entre chaque changement) cette fonctionnalité de "undo" serait donc hors ligne pour éviter de saturer le serveur. Ainsi quand on change de page, on ne perdrait pas entièrement la faculté de revenir en arrière. Ca m’arrive souvent de changer de page involontairement et de perdre la faculté de CTRL+Z.

+ Faculté de comparer le pending et le brouillon.

@artragis merci pour le récapitulatif. Deux détails pour moi :

1. Concernant la taille de la zone de texte, pour moi elle ne doit pas être « en lignes » mais « en proportion de la taille de l’écran », pour gérer à la fois les écrans de petite et de grande taille.
2. C’est vraiment si complexe que ça d’avoir la coloration syntaxique du markdown ? Y compris une version 1 qui n’intègrerait pas les spécificités de ZdS ?

je pense que c’est plus compliqué que l’aperçu en temps réel, surtout si on doit mettre du style dans la textarea tout en restant accessible.

Dans l’état actuel des choses, Sandhose avait fait un gros travail la dessus et le plus compliqué : https://github.com/A-312/zds-editor

Il faudrait prendre le temps d’intégrer les boutons