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

Bonjour à tous,

comme je l’ai dit plusieurs fois, côté développement on travaille au fur et à mesure à améliorer l’interface du site pour le rendre plus utilisable et plus intuitif à l’utilisation.

La version 28.0 a amené l’ajout d’image par glisser/déposer, et je pense que ça a facilité la vie de beaucoup de monde ainsi qu’une nouvelle bibliothèque. La version 28.1 a ajouté quelques raccourcis dans l’interface de rédaction, notamment pour clarifier la différence entre section, partie, chapitre et ce qui peut être fait. La version 28.2 va changer la page de profile pour la rendre plus attractive et navigable, et ajouter quelques éléments d’accessibilité.

Alors que faire pour les versions suivantes? A l’heure actuelle, rédiger sur zds bien que de plus en plus facile reste assez rebutant, alors, étape par étape, nous allons modifier notre interface. Afin d’éviter les longs tunnels de travail, comme on l’a connu avec la page de profile, je propose de faire un petit découpage. Je considère que le plan de changement de l’interface de rédaction se fait en trois partie, la première contenait la partie relative aux galeries et la clarification des termes, la seconde, la voici, elle concernera la création du contenu en lui même ainsi qu’un revive de la ZEP-3.

Voici les composants que va contenir cette phase 2/3

en amont (rédaction)

• (fonctionnalité v29): une interface de prise de note pour la validation (et peut être pour la béta).
• un ravalement de façade pour la (les?) pages de rédaction (c’est ça qui va être discuté ici).
• la possibilité d’importer un contenu (article et billet dans un premier temps) à partir d’un markdown à plat.

en aval (lecture)

• (fonctionnalité v29): les parcours
• (en discussion) : les listes de lectures

Je vous pose donc la question suivante

Le but de ce topic est d’obtenir une page de création la plus facilement compréhensible possible. Le but est donc d’avoir une maquette de cette page (ou de ces pages). Ne vous sentez pas contraints, on peut tout à fait si c’est justifié imaginer une page en plusieurs étapes plus simples.

Aujourd’hui nous avons trois problèmes majeurs:

• la sélection des licences qui n’est pas vraiment bien amenée pour les auteurs, le but est de faire de la pédagogie pour que les auteurs choisissent une licence libre (philosophie du site) tout en leur laissant le choix de ne pas le faire. Mais encore faut-il leur expliquer les conséquences de leurs choix.
• la sélection des catégories : c’est long, ça force à scroller et on sait pas vraiment ce que chaque catégorie représente
• la sélection des aides : a-t-elle besoin d’être là? peut être présenter ça de manière plus sexy?

Deux autres problèmes annexe peuvent être aussi maquettés ici :

• 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)
• comment montrer aux gens le corpus qu’ils s’apprettent à rejoindre (x contenu dans telle catégorie, avec tel tag etc.)?

Sans avoir de maquette, je pense qu’il serait bien d’avoir une interface en langage naturel ; plutôt qu’un "Titre : …" qui rebute, on pourrait imaginer des phrases du style "Je souhaite rédiger [un tutoriel/un article] dont le le titre serait …, et que je pourrait décrire comme suit : [textarea de description". C’est un confort que je trouve non-négligeable pour les personnes n’ayant jamais rédigé sur Zeste et qui n’enlève pas d’éléments aux habitués.

Pour les catégories, on pourrait imaginer quelque chose de similaire dans le style "Ce contenu portera sur [de l’informatique/des sciences naturelles/…], et plus précisément sur [la bureautique/les sites web/…]".

Note : les éléments entre crochets sont des dropdown et les points de suspension des champs de texte libres. En ayant des dropdown, on évite d’afficher toutes les catégories et de prendre trop d’espace vertical. Je suis conscient que ça enlève la possibilité de sélectionner plusieurs catégories en tant que tel ; mais je me pose la question du réel besoin d’en choisir plusieurs. Si il le faut, on peut avoir plusieurs fois la phrase ci-dessus avec des modifications légères, du style : "Il pourrait aussi être décrit comme contenant [de l’informatique/des sciences naturelles/…], et plus précisément [de la bureautique/des sites web/…]".

Pour les licences, on peut partir sur exactement la même chose : "Je [souhaite/ne souhaite pas] que mon contenu puisse être redistribué" si "souhaite" est sélectionné, on rajoute un choix automatique de licence via : "Je [requiert/ne requiert pas] que mon nom soit cité lors de la republication. [J’autorise/Je n’autorise pas] la redistribution commerciale. [J’accepte/Je n’accepte pas] que des versions dérivées soient créées à partir de mon travail".

Pour la sélection des aides, ce serait peut-être bien de planquer un peu cette fonctionnalité dans le menu contextuel à gauche une fois le contenu créé.

C’est une très bonne chose de repenser à l’interface de rédaction qui peut être déroutant ! Par contre, j’ai horreur du langage naturel qui fait à mon sens faux.

Alors que faire pour les versions suivantes? A l’heure actuelle, rédiger sur zds bien que de plus en plus facile reste assez rebutant, alors, étape par étape, nous allons modifier notre interface.

Je confirme

• un ravalement de façade pour la (les?) pages de rédaction (c’est ça qui va être discuté ici).

Je pensais déjà plutôt à une possibilité de déplacer avec la souris les parties/chapitres/sections.

d’ailleurs le drag’n’drop devrait se faire où il y a le curseur

Je vous pose donc la question suivante

 quelle serait votre page de création de tuto idéale?

Je trouve que ce que dit @TAlone est une très bonne piste déjà.

Je pense que à côté du dropdown il pourrait y avoir un + pour ajouter une catégorie non ?

Ne vous sentez pas contraints, on peut tout à fait si c’est justifié imaginer une page en plusieurs étapes plus simples.

Si c’est pour la création, je suis contre si il y a rechargement de la page. En revanche, si c’est une histoire avec un bouton "Suivant"/"Précédent" pour les choix sans rechargement de la page (type swipe vers la prochaine étape), alors je serais pour

• la sélection des licences qui n’est pas vraiment bien amenée pour les auteurs, le but est de faire de la pédagogie pour que les auteurs choisissent une licence libre (philosophie du site) tout en leur laissant le choix de ne pas le faire. Mais encore faut-il leur expliquer les conséquences de leurs choix.

@TAlone a déjà très bien ratissé ce point, rien à dire

• la sélection des catégories : c’est long, ça force à scroller et on sait pas vraiment ce que chaque catégorie représente

Tout à fait d’accord avec ce point. Je l’ai particulièrement remarqué sur le zds-site local où il y a ~30+ catégories en lorem ipsum dolor. Du coup l’idée de @TAlone me paraît honnête

• la sélection des aides : a-t-elle besoin d’être là? peut être présenter ça de manière plus sexy?

Même avis que @TAlone. Qui a vraiment besoin d’un repreneur lors de la création d’un contenu ?

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

C’est assez contraignant au final ce principe d’obliger la rédaction d’intro et conclusion dès la création/édition. J’imaginerai plutôt un prepublish hook empêchant de publier un contenu sans conclusion/intro partout.

Développer avec une phrase ?

C’est assez contraignant au final ce principe d’obliger la rédaction d’intro et conclusion dès la création/édition. J’imaginerai plutôt un prepublish hook empêchant de publier un contenu sans conclusion/intro partout.

en soi à l’heure actuelle tu peux tout à fait publier un contenu sans intro ni conclusion.

Salut,

Au niveau de l’introduction et la conclusion, justement, je les verrai bien présentées comme des sections à part entière. Donc pour les modifier il suffirait de cliquer sur le bouton d’édition situé à côté d’un titre « Introduction » ou « Conclusion », pas sur celui du contenu / partie / chapitre.

Au passage, ça rendrait obsolète les pages d’édition des parties et chapitres, dont le bouton « éditer » pourrait être remplacé par un « renommer ». Ça permettrait d’y voir plus clair dans l’interface entre ce qui est section de texte et ce qui est conteneur.

Pour ce qui est de l’import, encore une fois une URL de dépôt git à puller pourrait être utile en plus de l'upload d’archives zip. Aussi, pouvoir importer un fichier markdown simple pour une section de texte (plutôt que de devoir l’éditer sur le site et y copier/coller le contenu voulu) serait un plus.

Si des fonctionnalités de drag&drop voient le jour (je n’y suis pas nécessairement favorable), les fonctionnalités d’import pourraient aussi y être ajoutées (importer une section en glissant un fichier texte).

Je ne suis pas sûr d’avoir bien compris donc je demande : tu parles d’ajouter une synchronisation du tutoriel avec un dépôt Git ?

Mettre à disposition en gros un lien https://zestedesavoir.com/tutoriels/<ton_tutoriel_en_brouillon>.git et que tu puisses l’ajouter en remote origin pour faire des push ainsi que pull si tu as fais des changements directement sur le site. De cette manière, tu pourrais bosser sur ZestWriter en local et push de temps à autre.

ça serait chaud à faire : il faut mettre à jour la bdd quand on fait ça et c’est pas gagné d’avance d’autant qu’au moindre renommage du tuto, l’url changerait. Pour l’instant c’est pas à l’ordre du jour.

Après j’ai envie de dire qu’il faudrait déjà améliorer l’UI et UX pour le site. Les histoires de Git c’est pour une poignée de devpersonnes.

C’est exactement ça.

Est-ce que "le contraire" serait possible ?

Avoir un champ "URL de dépot git externe" et pouvoir pull/push à la demande depuis ZdS ?

L’avantage c’est que comme les actions sur le dépot de ZdS sont faites depuis ZdS, on peut faire les mises à jour de la BdD à ce moment là.

Après, je suis d’accord que ça concerne qu’une (petite?) partie des auteurs, mais il y a quand même une majorité de tutos en info non ?

c’est une solution à imaginer. Mais franchement pas dans le scope de cette partie du "lifting de l’interface".

Non, car cette demande-là a déjà était faite mais ça posait des contraintes techniques.

Là ce serait juste comme le dit @amael, ça fonctionnerait comme l’import d’une archive, sauf qu’à la place d’un fichier zip on mettrait l’url d’un dépôt. Au niveau de l’historique du contenu sur ZdS ça apparaîtrait juste comme un seul commit (un import).

Je ne sais pas quelle part des auteurs ça représente, mais je sais que ce serait une fonctionnalité utile.

/contenus/<content_pk>.git puisque le pk ne change pas au renommage ?

Je suis assez surpris de ne pas encore voire dans vos messages ce qui, de loin, ressemble à l’amélioration potentielle de l’interface de rédaction qui possède le meilleur intérêt par rapport au temps de développement :

des zones de rédaction de grandes tailles avec coloration syntaxique du Markdown

(aujourd’hui, elles font 10 lignes de haut… autant dire que les redimensionner est un pré-requis à la moindre utilisation).

Et, pourquoi pas, un affichage du markdown/rendu côte à côte en "temps réel" (donc côté client) parce que devoir cliquer sur Aperçu à chaque modification peut être désagréable pour les auteurs qui préfèrent le WYSIWYG.

Dans cet affichage on peut imaginer que les blocs secret soient dépliés par défaut pour faciliter leur édition.

des zones de rédaction de grandes tailles avec coloration syntaxique du Markdown

je ne suis pas trop surpris car ça c’est la troisième partie du chantier (du moins pour la colorations syntaxique, pour la taille du textarea, ça peut se changer).

Les navigateurs modernes ne proposent tous pas une possibilité de redimensionner les <textarea> ?

elle est redimentionnable, c’est juste que c’est lourd de redimensionner soi-même alors que de base le but c’est d’écrire un texte.

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