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

a marqué ce sujet comme résolu.

Reprise du dernier message de la page précédente

Perso ce que je trouverais bien, c’est une interface vraiment centrée sur le contenu. (Ça rejoint un peu l’histoire de grandes zones de texte.)

Mine de rien, dans l’interface actuelle d’édition, le contenu, c’est presque un élément mineur dans une toute petite case. Je pense qu’il faudrait vraiment que l’éditeur prenne la majorité de la place. Ça ne me choquerait pas d’avoir une page avec une mise en page un peu différente et comportant un éditeur pleine page (et par exemple les métadonnées dans une colonne latérale). Un peu dans le style du nouvel éditeur de WordPress, à la réflexion, que je trouve très bon dans le côté « centré sur le contenu ».

Concernant l’éditeur lui-même, la coloration du Markdown serait je trouve aussi, vraiment un plus. Le CMS Grav utilise un éditeur (codemirror) qui le colore et c’est très agréable — on est à la limite de WYSIWYG mais tout en restant dans du Markdown, ce dernier ayant l’avantage d’être très lisible même en texte brut, donc il ne faut pas grand chose.

Pour référence, leur éditeur ressemble à ça
L'éditeur du CMS Grav, basé sur CodeMirror et personnalisé à leur style
L'éditeur du CMS Grav, basé sur CodeMirror et personnalisé à leur style

L’éditeur ultime pour Markdown en terme de confort d’écriture, cela dit, c’est un éditeur à la Typora (que j’utilise pour rédiger mes contenus d’ailleurs) qui mêle l’édition Markdown et la prévisualisation. Mais Typora n’est pas open source et développer nous-même un tel éditeur serait certes intéressant mais long et complexe, je ne pense pas qu’on puisse se le permettre à court terme.

Oh et : des raccourcis standard dans l’éditeur. Ce serait extrêmement agréable. Ctrl + B, I, K

pourquoi la création (et l’édition) demande-t-elle de donner l’intro et la conclusion? n’y aurait-il pas quelque chose de mieux à faire? (proposez)

Concernant ce point, je crois que ça a déjà été mentionné sur un autre sujet dans les limbes du forum mais je reste convaincu que la page de création d’un contenu ne devrait demander qu’un titre en plus du type de contenu. On partirait sur une page très épurée avec juste un champ de texte et un sélecteur de type stylisé avec des explications simples sur les différences.

Et éventuellement, laisser un droit à l’erreur en permettant de changer le type après coup (typiquement, article transformé en billet ou en mini-tutoriel et ce dans tous les sens, car la structure est la même et que le code supporte déjà ça, mais uniquement via l’import d’une nouvelle version du contenu). Mine de rien, psychologiquement, savoir que le choix de type de contenu que l’on fait n’est pas définitif, c’est rassurant. Et sur un processus déjà complexe de rédaction de contenu (car écrire, c’est pas si simple), rassurer, c’est bien.

Je ferai des maquettes de ce que j’ai en tête quand j’aurai un peu de temps pour :) .

Édité par Amaury

#JeSuisArius

+12 -0

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.
+6 -0

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).

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.

Édité par Alex-D

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.

Édité par SpaceFox

À 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.

SpaceFox

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.

+1 -0

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.

+0 -0

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.

gasche

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.

La tero estas nur unu lando | Géographe de service | Cliquez 👍 pour dire merci

+6 -0

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.

Il y a bien des façons de passer à l’acte. Se taire en est une. Attribué à Jean-Bertrand Pontalis

+0 -0

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).

SpaceFox

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.

“Your manuscript is both good and original. But the part that is good is not original, and the part that is original is not good.” Samuel Johnson

+1 -0
Auteur du sujet

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ément fonctionnel simplicité du code 0 - 5 rapidité à coder 0 - 5 prévu en v29
licence à la validation/mise en béta 1 2 oui
licence avec une explication pédagogique 1 1 oui
Pouvoir créer/renommer une section/une partie depuis la page de sommaire (avec rechargement) 0 1 à voir en fonction de la suivante
Pouvoir créer/renommer une section/une partie depuis la page de sommaire (sans rechargement) 1 2 à voir avec la précédente
Pouvoir déplacer une section/une partie avec un drag & drop 1 - 1 à décider
Les aides à la rédaction dans le volet de gauche 0 0 oui
Les boîtes de texte plus grande 0 0 oui, faudra juste un consensus sur la taille à choisir1
Coloration syntaxique en temps réel 5 5 non, et on verra si ça vient un jour en fonction de la suivante
Aperçu en temps réel (zmd client side) 3 3 non, et on verra si ça vient un jour, en fonction de la précédente
Rédaction à plat d’un billet, d’un article 3 4 best effort, si côté zmd on arrive à avoir un parser double sens assez rapidement
Import d’un simple fichier md 3 4 best effort, si côté zmd on arrive à avoir un parser double sens
Une double vue Rédaction/plan inconnu inconnu J’ai pas de maquette

  1. notons que dans mon POC que j’ai chez moi 30 lignes c’est ce qui permetde garder le formulaire complet sur un seul écran

+2 -0

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

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.

A-312

Des avis sur la possibilité d’avoir l’editeur dans une deuxième fenêtre (popup) et l’aperçu/prévisualisation dans la fenêtre principale? +1/-1 à mon message ci-dessus.

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.

+1 -7

@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 ?
  1. 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 ?
SpaceFox

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

+0 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

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