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.
Et si possible avec js un raccourci ctrl+S.
Et si possible avec js un raccourci ctrl+S.
Ce raccourci a déjà une autre signification dans la plupart des navigateurs.
Tu as souvent besoin d'enregistrer le fichier html de la page d'édition ?
Ceci dit moi je préférerai d'utiliser la suite de touche Echap, :, w et enter mais ça ne me choque pas de surcharger ce raccourcis tellement je ne vois pas de cas d'utilisation du raccourcis du navigateur pour ces pages.
Bref, c'est presque hors scope, le plus important est la fonctionnalité.
Je suis pour toute modification qui donneront une meilleurs expériences a nos auteurs !
Le système de création de contenu est lourd et manque d'ergonomie ce qui a tendance à décourager…
Quand j'ai voulu créer un plan pour un tuto illustrator, toute ma motivation a disparue lorsque j'ai voulu déplacer une partie ou un chapitre.
Zestwriter aide pas à ce genre de problématique ?
C'est la solution qui ressort dès que le sujet de la difficulté de rédiger un contenu ressort. C'est bien qu'il y a un problème que nous devons absolument corriger sur le site.
Ok c'est surement pas simple techniquement, mais il ne faut pas repousser éternellement le problème, c'est quand même la partie la plus importante de notre site ^^.
Prévisualisation asynchrone (pas de rechargement de la page) Un bouton de sauvegarde (idéalement aussi asynchrone).
ne pas avoir à se faire chier à redimensionner la zone de texte à chaque fois, celle-ci évoluant en fonction de ce qu’on met dedans ;
Ouais il faudrait…
Parenthèse markdown (:
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.
Oui, mais bon là le traitement fait plus de dégât que la maladie :(. C'est effectivement une problématique mais il y a d'autre solution pour la résoudre…
Est-ce que déjà un simple éditeur de texte qui colore syntaxiquement le markdown saisi (sans le rendre) n'aiderait pas ?
Ou avoir directement le rendu… Aujourd'hui je trouve que le système Markdown ajoute une étape à un système de rédaction déjà très complexe… ).
Ou avoir directement le rendu… Aujourd'hui je trouve que le système Markdown ajoute une étape à un système de rédaction déjà très complexe… ).
Pour le coup, on tombe exactement dans les problèmes de temps de développement, d'outils et d'ergonomie. Pourquoi ?
Précisions que je ne pense pas que la majorité des membres, en particulier les actifs, soient pour la disparition du markdown. Je peux me tromper mais perso je préfère le markdown à du WYSIWYG.
Zestwriter aide pas à ce genre de problématique ?
Non, parce que c'est une application Java de 100Mo là où un script (Python, bash, ce que vous voulez) de quelques lignes devrait suffire.
Personnellement je ne suis pas du tout intéressé par l'interface du site, de ce que j'en ai testé elle est ok. Cependant, la plupart des efforts qui pourraient être fournis à ce niveau ne serviront en définitive qu'à réinventer un éditeur de texte, fût-il en ligne (même ça ça existe déjà).
Le fait de proposer un outil riche est peut-être intéressant pour quelques auteurs (je ne les connais pas, je n'en sais rien), et je crois avoir déjà lu qu'une quantité assez surprenante de gens aimaient bien rédiger en ligne. Cependant je pense que s'il était plus facile de rédiger hors-ligne (pas de manifest.json à écrire, pas d'archive à importer séparément en changeant les URL écrites dans le cours), tout le monde y gagnerait, vous pourriez encourager les gens à rédiger hors-ligne (avec leur éditeur préféré), le cours pourrait être versionné avec des outils externes (→ validation), les problèmes de panne seraient moins importants, etc.
Je peux me tromper mais perso je préfère le markdown à du WYSIWYG.
Je ne sais pas si tu as déjà essayé Typora, qui propose du WYSWYG avec support de latex, je le trouve vraiment pas mal.Tu peux vraiment éditer et prévisualiser en même temps, et modifier facilement ce qui est prérendu. Mais je ne crois pas que le code soit opensource et ça serait compliqué à reproduire…
Précisions que je ne pense pas que la majorité des membres, en particulier les actifs, soient pour la disparition du markdown. Je peux me tromper mais perso je préfère le markdown à du WYSIWYG.
Je ne parle pas du tout de supprimer le Markdown je sais a quel point il est important pour beaucoup de membre actif sur le site, je verrais plus un avec l'autre, pq pas avec switch d'onglet.
Précisions que je ne pense pas que la majorité des membres, en particulier les actifs, soient pour la disparition du markdown. Je peux me tromper mais perso je préfère le markdown à du WYSIWYG.
J'appuie ça aussi. En admettant qu'on trouve un WYSIWYG qui génère du code propre, personnalisable et intégrable sans difficulté, il reste tous les inconvénients inhérents au WYSIWYG :
En fait, on trouve même maintenant des extensions pour rédiger en Markdown là où il y a un éditeur WYSIWYG, comme par exemple Markdown Here, qui fonctionne par exemple dans GMail et qui a un meilleur rendu et est plus souple (blocs de code, etc) que ce dernier. Et pour voir tourner cette extension dans mon entreprise, c'est pas du tout les plus geeks qui l'utilisent le plus.
Sinon, on pourrait se servir du stockage local au navigateur pour une sauvegarde fréquente du texte (toutes les minutes, voire 30 secondes). Certes c'est pas synchronisé, mais AMHA ça peut rendre de bons services.
Je ne parle pas du tout de supprimer le Markdown je sais a quel point il est important pour beaucoup de membre actif sur le site, je verrais plus un avec l'autre, pq pas avec switch d'onglet.
Les deux me semblent compliqué dans l'état actuel. Ça demande un lien fort entre html et markdown qu'on a pas et qui me semble pas réalisable facilement à court terme. Si on veut viser ça on peut par contre commencer par faire de la coloration syntaxique du markdown comme proposé plus haut. Ça permet de commencer à mettre en place un parseur markdown coté JS qui soit compatible avec le back.
Ergonomie : il faut des boutons pour toutes les fonctionnalités, là où l'on peut limiter les boutons du Markdown aux fonctionnalités les plus fréquentes pour les débutants et les plus casse-pieds à faire à la main (et c'est ce qui est fait présentement).
<_< ouais ouais, enfin rien ne nous empêches de faire de même pour le WYSY. Il y a des sites avec des WYSY. totalement ergonomique, performant et totalement adapté smarth et tablet.
Sur "Markdown Here" je voie que des extensions de navigateur, et plutôt dans le sens markdown > preview, mais je suppose que ça peut marcher dans l'autre (?)
Quel est le deuxième point le plus gênant ? Si c'est l'éditeur on peut y travailler mais il est peu probable que j'ai assez de temps pour m'en occuper seul.
Je peux t'aider là-dessus.
J'avais il y a un moment commencé une refonte complète de l'éditeur markdown. J'avais à l'époque proposé de se baser sur CodeMirror pour profiter d'un retour visuel en temps réel. Du coup, ça donnait un truc comme ça: https://s.sandhose.fr/zestedesavoir/zds-editor/examples/codemirror.html
J'avais pas encore customisé le style de la coloration syntaxique, mais c'est tout à fait possible avec CodeMirror (genre, mettre les titres en plus gros, changer l'arrière plan des blocs info/warning/secret…).
Une des crainte qu'avaient certains quand j'ai montré ça, c'était l'utilisation sur mobile, notamment au niveau du poids de CodeMirror (c'est environ +250Kb, ce qui me paraît pas délirant, surtout en vue des 700Kb de MathJax). J'avais donc complètement séparé le cœur de l'éditeur (ce qui gère les boutons, l'upload d'image, les raccourcis clavier et tout le bordel) de l'affichage, en faisant une version avec et sans CodeMirror, avec même possibilité de switcher entre les deux à la volée.
J'avais aussi pensé intégrer un système de draft sauvegardé dans le localStorage du navigateur pour éditer offline & synchronisé avec le serveur quand on a de la connexion.
Je pense que si j'avais pas continué à l'époque, c'est probablement parce que j'étais seul dessus, et aussi parce qu'il fallait passer à l'étape « design visuel » de l'éditeur, où j'avais moyennement envie de repartir sur les icônes actuelles (qui sont honnêtement moches, et encore plus sur écran HiDPI), et que j'arrivais pas à me décider sur des nouvelles icônes.
Du coup si y'a des gens motivé pour m'aider à reprendre le truc, notamment d'un point de vue UI (jiyong, c'est à toi que je pense 
), je suis carrément chaud pour reprendre ce que j'ai commencé !
(Note pour Kje: y'a un plugin CodeMirror pour les bindings vim, au cas où 
)
EDIT: le code est dispo ici, et la discussion autour de cet éditeur commence la
Ça pourrait être une bonne base si tu as le courage. Il faut faire converger les parseurs de markdown.
Hello !
Tout d'abord je dirais qu'il ne faut pas mélanger la complexité de la technique et celle de l'UI. L'UI d'édition des tutos est pourrie (et je n'y suis pas pour rien… désolé :/) néanmoins le modèle de données derrière fonctionne plutôt bien.
Ce qui ferait énormément de bien à ZdS, c'est que des mecs qui aiment le front puisse s'amuser à travers une API. Ainsi on pourrait voir naitre des UIs full JS sur des sites/app à part dans un premier temps par exemple, puis intégré au projet zds-site si ça plait au plus grand nombre (ce qui serait dans l'idée de la ZEP 48, de mon point de vue).
J'ai bien conscience qu'une telle API serait un gros morceau, mais il faut bien avouer que le code back autour de tout ça n'est pas super excitant quand le but est de blinder sur le front.
La base de Sandhose me semble déjà être un premier grand pas. Le pas d'après serait de pouvoir gérer toute l'arbo facilement sans passer par 50 pages de config.
De fait, si l'UI est bien faite, la notion d'extrait pourrait devenir bien moins gênante de mon point de vue, en ce sens où on pourrait avoir l'impression d'éditer plusieurs extrait en même temps (sur la même page), avec quelque chose qui serait proche de l'édition en place.
Voilà ce que j'imaginais à l'époque, mais qui demande beaucoup de travail et de temps.
La refonte des articles + tutos et l'homogénéité qui a été apportée permet beaucoup plus de choses en front désormais.
Il y a vraiment moyen de faire des choses pratiques et plus claires qu'actuellement (encore une fois, c'est en partie ma faute, n'ayant pas pris le temps de creuser sur la partie édition des tutos).
Banni
+1 pour une API front. Ce serait vraiment super utile pour pas mal de monde.
Perso je suis pas convaincu car :
En vrai si quelqu'un veut s'en occuper personne ne l'en empêchera mais pour moi c'est pas la priorité. Déjà ça ne règlera pas notre problème tout en rajoutant du code à maintenir. Il se passe quoi si on se rend compte que le découpage important tel qu'il est actuellement défini doit être viré ?
l'API front permettrait à 3 personnes qui sont dev de s'amuser. Perso je préfère qu'on travail sur des améliorations qui aideraient directement les utilisateurs, ceux qui veulent rédiger sur le site. Et l'API me semble générer plus de contraintes que d'aide en ce sens.
Ps: mais encore une fois, si quelqu'un veut faire une PR qui l'ajoute et s'accorde avec le reste des API je ne pense pas que ça soit refusé
Ce que je veux dire, c'est coder la gestion des contenus en fullstack monolith ça me semble bien compliqué. Si on veut un truc cool sur le site, il sera nécessairement blindé de JS pour éviter un tas de rechargement de page. Et le mieux pour échanger avec une source externe, c'est une API.
En l'état, le front va être très fortement lié au back, donc s'il y a refonte du back, tout le front sera pété, API ou pas.
Je fais des API à longueur de journée, pour moi c'est la meilleure des logiques pour découper de façon nette front et back. Là en gros, ce qui gène, ce sont les extraits. Or, ils ont visiblement un sens dans la construction du sommaire et peut-être un intérêt dans la construction du HTML/PDF/ebook (là je m'avance) alors que le problème à la base, c'est que les auteurs ne trouvent pas ça pratique lors de l'édition. C'est pour ça que j'énonce cette possibilité que ce soit le front qui pallie à ce manque d'ergonomie/facilité d'usage.
Perso je préfère qu'on travail sur des améliorations qui aimeraient directement les utilisateurs, ceux qui veulent rédiger sur le site.
Je suis complètement d'accord. Une API qui permettrait à tous types de clients (lourd, web, mobile, que sais-je…) d'éditer les contenus à la guise de chacun n'en ferait-il pas partie ?
3 personnes qui sont dev et qui vont s'amuser peuvent amener des idées à intégrer par la suite dans le site lui-même une fois qu'elles sont testées et approuvées.
On a bien eu une extension Chrome puis Firefox pour avoir des notifications, des clients lourds qui permettent d'éditer des tutos, pourquoi pas des clients Web ou autres ?
Pour moi la plus grosse contrainte c'est toujours le fait qu'il faut trouver des gens motivés pour coder l'API :/
Une API qui permettrait à tous types de clients (lourd, web, mobile, que sais-je…) d'éditer les contenus à la guise de chacun n'en ferait-il pas partie ?
Clairement, non. Soyons honnête et pragmatique, 90% des utilisateurs utiliserons l'interface web primaire du site. Seul quelques power-user utiliseront un outils externe.
On a bien eu une extension Chrome puis Firefox pour avoir des notifications, des clients lourds qui permettent d'éditer des tutos, pourquoi pas des clients Web ou autres ?
Le client lourd pour éditer les tutos prouve bien que ça ne résous pas tout puisqu'il est disponible et manifestement ça n'a pas résolu nos problèmes.
On est d'accord cependant sur ta dernière phrase et je l'ai dit : si quelqu'un veut faire l'API pour le contenu (car c'est de ça qu'on parle), elle sera accepté (enfin je pense, c'est pas moi qui décide).
Ce sur quoi on est pas d'accord c'est sur son importance. Tu présente ça comme la façon la plus simple/importante/évidente façon de régler nos problèmes. Je ne suis pas d'accord pour plusieurs raisons. La première est que c'est un très gros morceaux. On a déjà eu l'expérience ici, que ce soit à la création du site, ou sur la zep qui concernait l'amélioration du module : au vue de nos effectifs et de leur logique volatilité (en terme de disponibilité), dans le meilleurs des cas cette API n'arrivera pas avant 6 mois (1 ans ou + me semble plus vraisemblable). Moi ça me gène franchement d'attendre encore 1 ans sans toucher à quoique ce soit dans ce module pour attendre une hypothétique API qui résolurai par magie tous nos problèmes (alors qu'en réalité, une fois l'API développé, il faudra attendre plusieurs mois que ces effets soit accessibles à tous).
J'ai rien, bien au contraire, que quelqu'un travail dessus. Mais il y a surement des améliorations qu'on peut mettre par évolution mineurs qui nous permettraient déjà d'améliorer les choses. On a déjà identifié un bouton "sauvegarder" et une pré-visualisation asynchrone. Si déjà ces deux actions qui peuvent être faites rapidement sont implémenté, ça aidera déjà nos utilisateurs. Ça ne résoudra pas tout mais je préfère qu'on améliore les choses que d'attendre 2 ans une solution miracle.
Les deux ne s'opposent pas. Des gens peuvent travailler sur une API contenu. Mais il y a certainement beaucoup de choses qui peuvent être amélioré sans.
PS: Tes propositions tu peux probablement déjà les expérimentés en rajoutant 2-3 vues assez faciles à faire dans Django. De toute façon un gros changement d'ampleur nécessitera plusieurs passes.
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