#wysiwyg

J’ai regardé un peu hier, le fonctionnement, la doc API, etc, et de ce que je comprends, ce projet est en gros le principe de l’éditeur Gutenberg de WP mais en autonome. Et pour l’instant de ce que j’ai vu, il a beau avoir un format pivot JSON abstrait au milieu, il n’est conçu que pour générer du HTML au final. Mais peut-être que j’ai mal cherché…

Ce qui n’est pas le cas de ProseMirror, dont le but c’est bien d’éditer en web un format pivot JSON mais en pouvant produire n’importe quoi en sortie du moment qu’il y a un générateur de tel type (html, ou markdown, ou SPIP, ou etc).
Cf
►https://seenthis.net/messages/693664
et
▻https://seenthis.net/messages/651447

Il y a 3 ans… avec détails et roadmap des choses à faire dans l’ordre :
►https://core.spip.net/issues/3720

très bien ce cahier des charges, merci!

Ouh là comment cela a l’air vraiment trop bien cette affaire. Il faudrait que je trouve un peu de temps pour le tester un peu sur la longueur (textes longs et foisonnants). Un jour. Je mets de côté donc.

Moi aussi je n’ai pas encore teste. En fait j’utilise Typora qui est vraiment très bien, mais qui n’est pas libre...

▻https://typora.io/img/beta.mov
►https://typora.io

@aris Et moi j’utilise Word (comme traitement de texte) qui n’est pas hyper libre non plus ! Un jour.

Eh bé, encore et encore un… (suivre le tag markdown). Ça a l’air cool que ce soit en wysiwyg (souvent ya deux panneaux). Même si en electron donc possiblement un peu lent à la détente suivant les ordis. À tester

►https://seenthis.net/messages/693664

#prosemirror

C’est exactement ce qu’il faut et que j’attends depuis des années, même après que Wikipedia ait codé son éditeur wysiwyg mais qui enregistre en une autre syntaxe après (càd ça ne produit pas du html). Sauf que wikimedia l’a codé que pour eux, pas en lib générique.

Or là Prosemirror est vraiment une lib générique qui montre à l’utilisateur un éditeur #wysiwyg MAIS qui produit un format pivot intermédiaire en JSON, de données structurées, qui peut donc ensuite être utilisé pour produire n’importe quoi, et alors enregistrer en SPIP en Markdown ou n’importe quoi d’autre…

This is the future !

#idée_pour_SPIP

Le site officiel du « moteur » sous ce projet : ProseMinor
►http://prosemirror.net

Et pour en rajouter une couche sur les possibilités de ProseMinor vis à vis des fonctionnalités d’édition de SPIP : ▻https://prosemirror.net/examples/dino
qui donne un exemple d’intégration d’un nouvel objet éditorial (ici un dinosaure) tout à fait similaire aux modèles SPIP...

#json #ProseMirror #éditeur #SPIP

@rastapopoulos paye ton ticket ? (tant que core.spip.net tourne toujours ^^)

J’avais fait un ticket sur le développement d’un éditeur basé sur CodeMirror déjà, mais pour faire du WYSIWYM donc. Là c’est une autre piste du coup. Donc autre ticket… ou bien transformation du précédent en complétant pour présenter les deux pistes (et peut-être même que les deux pourraient être bien à la fois, car quand on a un éditeur WYSIWYG, il faut toujours avoir aussi un éditeur de source en parallèle, et alors autant qu’il soit WYISWYM tant qu’à faire…)

►https://core.spip.net/issues/3720

▻http://www.revue-backoffice.com/numeros/01-faire-avec/eric-schrijver-culture-hacker-peur-wysiwyg

Depuis la révolution de la publication assistée par ordinateur [PAO] des années 1990, les designers graphiques sont capables de réaliser leurs propres mises en page sans l’intervention d’ingénieurs. Dans la plupart des cas, ce qui se passe sur le Web est d’un tout autre ordre : l’exécution des sites Web est in fine prise en charge par des développeurs. Ces derniers ont donc souvent leur mot à dire dans le choix de la technologie employée pour créer un site. Rien de plus normal, dès lors, que les valeurs et préférences des développeurs se reflètent dans ces décisions. […] Ainsi, à l’inverse du design de supports imprimé, les technologies de programmation utilisées pour la création des sites Web (langages de programmation, bibliothèques logicielles, systèmes de gestion de contenu, etc.) sont presque toujours des logiciels libres et/ou disponibles en opensource ; les systèmes de gestion de contenu commerciaux intègrent même fréquemment des éléments de code open source. […]

[…]

Le manque d’intérêt pour les nouveaux éditeurs WYSIWYG implique que les futures interfaces de ce type présenteront les mêmes problèmes d’instabilité que ce qui existe actuellement, renforçant d’autant plus la méfiance des développeurs. [C’est un cercle vicieux.] Il n’existe, à ma connaissance, que deux moteurs d’édition basés sur l’attribut contentEditable : Aloha 19 [2010] et Hallo.js 20 [2013]. Aloha est très mal documenté et sa masse de code le rend difficile à appréhender. Hallo.js prend une direction plus légère, mais reste trop limité puisqu’il n’est pas possible, par exemple, d’insérer des liens ou des images. […]

Si le WYSIWYG était un peu moins tabou dans la culture hacker, des solutions intéressantes croisant texte brut et mise en forme graphique émergeraient probablement. Un bon exemple est la fonction « révéler les codes » 21 de WordPerfect [1980], le logiciel de traitement de texte le plus populaire avant l’avènement de Word. Lorsque vous vous trouviez confronté à un problème de mise en forme, cette fonction permettait de révéler la structure des instructions de formatage — ce qui n’est pas sans rappeler l’inspecteur DOM des navigateurs Web récents. Des exemples d’interfaces plus radicales combinant l’immédiateté de la manipulation directe d’éléments et la puissance de la programmation existent dans certains logiciels. Le programme 3D Blender [1995] propose ainsi une intrication intéressante entre interface visuelle et interface texte 22. Toutes les actions sont consignées sous la forme d’une suite de lignes de commandes qu’il est facile d’utiliser pour créer des scripts d’automatisation. La sélection d’un élément via l’interface graphique permet également de visualiser ce dernier dans la structure interne du document [DOM] et d’en faciliter ainsi l’accès par voie programmatique.

[…]

Le potentiel de ce langage est obtenu au détriment de la concision : pour être suffisamment flexible et permettre de travailler dans des situations variées, le langage HTML est relativement verbeux. Même si le standard HTML5 a d’ores et déjà apporté de nombreuses améliorations, ce dernier n’est toujours pas assez concis pour les adeptes de la culture hacker : d’où l’existence de solutions comme le langage de balisage Markdown. Cependant, imposer l’utilisation d’un format austère en texte brut revient à en refuser l’accès à des personnes de cultures différentes.

C’est faux ! @tetue a montré avec une camarade qu’une syntaxe légère correcte était plus facile à comprendre et à utiliser au quotidien qu’une interface graphique, pour une personne ayant un handicap. Et ça doit sûrement valoir pour les différences culturelles, hors handicap. Car une interface visuelle est à priori plus dépendante des différences culturelles que les quelques caractères utilisés dans Markdown (dièse, astérisque, tiret basique…) qui sont sur tous les claviers du monde.

L’interface appropriée pour un écrivain pourrait ne pas être adaptée à une maison d’édition ou à un designer. […]

Ça par contre c’est très important, sauf que la phrase ne correspond pas à la réalité. Ce n’est pas l’interface différente le problème, mais comment est stockée l’information.

Le HTML c’est pour un affichage web et ça inclut des trucs précis propres au web. Or tous les éditeurs WYSIWYG dont parle l’article fonctionnent uniquement avec HTML et enregistre en HTML. Qui n’est pas du tout un format « pivot » idéal donc, puisqu’il est uniquement pour des pages web.

Le fait d’enregistrer en Markdown (même si l’interface peut être WYSIWYG ou au moins WYSIWYMean) par exemple, permet ensuite de générer ce qu’on veut comme format de sortie, pas uniquement du HTML.

#wysiwyg #interface #ergonomie #éditeur #texte

Toujours pas de markdown dans #SPIP d’ailleurs ; tous les 2-3 mois je me dis qu’il faudrait s’y mettre pour de vrai.

@fil bah si, ya un plugin Markdown, et il permet soit de l’activer en surplus de la syntaxe SPIP avec un marqueur, soit l’inverse (notamment pour un nouveau site), avec le Markdown par défaut, et la syntaxe SPIP en surplus avec un marqueur.

(Mais il faudrait dans ce cas avoir SimpleMDE en éditeur, qui est WYSIWYMean avec CodeMirror derrière.)

►https://github.com/Cerdic/markdown
(Il y en a un autre sur la zone, de Cédric aussi, mais qui est donc en doublon puisqu’il n’est pas à jour et c’est celui sur Github qui est maintenu…)

#idée_pour_spip #éditeur #wysiwym

Certaines choses intéressantes, mais l’éditeur qui ne fait toujours pas d’autocomplete des classes CSS connues détectées, en 2017, WTF, ça se faisait déjà il y a 15 ans. Que ce soit dans le champ « Classes » en mode graphique, ou dans l’éditeur de code. Un peu léger quand on vante un éditeur dédié au html-css…

(Il est aussi très bugué aussi, en tout cas sur ubuntu là, j’ai passé beaucoup trop de de temps à le tester en galérant…)

Clairement je m’en sers pas, j’ai jamais aimé le #wysiwyg mais j’ai tendance à soutenir toute initiative alternative à Adobe. Pour l’apprentissage il doit faire le job.

Moi non plus et je comprends l’idée, mais quand même, ya des trucs qui existent depuis des années et des années, en libre et en pas libre, et qui ne sont toujours pas là dans un logiciel qui se dit dédié au html-css. Je veux dire commencer à taper « col- » et avoir la liste des classes qui commencent par ça, suivant ce qui a été détecté dans les feuilles déclarées, c’est un truc de méga-base quoi. En plus le pire c’est que le logiciel détecte bien la liste des classes déclarées, donc elle existe, juste à l’appeler dans un autocomplete quand on commence à taper…

Du coup hier j’avais fait une petite recherche sur les trucs actuels existants hors Adobe et pendant ce temps ya des petites boites (pas adobe donc) qui font des trucs pas libres non plus (Bluegriffon il manque des trucs si on achète pas la licence aussi) mais mille fois plus complets, didactiques aussi (avec le DOM dans un panneau sur le côté, on peut tout déplacer en drag n drop, ça fait du code correct, etc) :
►https://pinegrow.com
Et qui fonctionne avec l’éditeur Atom( libre) en synchro :
▻https://pinegrow.com/pinegrow-atom.html

Bref pour un projet de maquettes ergo, je voulais voir si on pouvait utiliser Bluegriffon avec un framework css déclarant des classes, et du coup avoir le meilleur de plusieurs mondes (ne rien styler soi-même un par un, mais avoir une interface graphique immédiate) mais c’est tellement laborieux… j’ai abandonné. C’est dommage, yorait du potentiel s’il ne manquait pas 2 ou 3 trucs vraiment de base pourtant… :
– autocomplete des classes
– dragNdrop facile du DOM (dans le wysiwyg et dans l’explorateur de DOM) : celui de Bluegriffon est NUL, il ne sert à rien, celui de Firefox est mille fois mieux alors que c’est pas un éditeur, tu peux y déplacer un nœud en 2s et tu peux « créer un nouveau nœud » quelconque pareil
– impossible d’encapsuler la sélection courante dans un nouveau div…

(ce sont juste des notes après test hein, j’en profite pour les mettre là)

cool

Comme je l’avais expliqué ici :
▻https://seenthis.net/messages/161212#message161373
quand il s’agit de produire et d’enregistrer directement du HTML, c’est immensément plus facile de créer un éditeur WYSIWYG puisqu’on édite directement le HTML dans le navigateur, et basta. C’est exactement ce que fait cet éditeur, et quelques autres.

Quand il s’agit d’enregistrer dans un autre format, afin d’avoir un truc plus neutre qui permettre de générer ensuite d’autres choses (PDF ou autre), et bien il faut passer par un format pivot, et ensuite à la fin l’enregistrer dans le format final. C’est ce que fait l’éditeur WYSIWYG de Wikipedia, mais qui ne sait apparemment générer QUE leur format Wiki à eux (je n’ai vu nulle part que ce soit modulaire et que l’étape final format pivot => format wiki soit un plugin et puisse être surchargé).

Vu que l’éditeur ne sait tripoter que du HTML, là pour Markdown, ils choisissent du coup d’utiliser le HTML comme format pivot, et à la fin de transformer le HTML en format texte brut markdown (comme sale() en gros). Ça ne me parait pas toujours praticable ni très propre, il doit y avoir des approximations.

D’après moi, il n’y a toujours que l’éditeur de la fondation Wikimedia qui fait les choses de manière complète et propre (y compris pour les « modèles » avec arguments et tout !), mais sauf qu’ils n’ont pas codé leur librairie de manière à pouvoir générer d’autres formats que le leur apparemment…

(Sinon ça ne parle pas de SPIP, c’est plutôt le tag #idée_pour_SPIP :))

#WYSIWYG

#idée_pour_SPIP

Et avec une capture de @seenthis en tant que bon exemple !

entièrement d’accord pour les virer ; la méthode seenthis est bien mieux :)

http://romy.tetue.net/local/cache-vignettes/L500xH145/barre-edition-syntaxe-8-a38ea.png

sinon je crois qu’@arno aime aussi la barre contextuelle de medium, qui ne s’affiche que lorsqu’on sélectionne une partie de texte, et flottant au-dessus, du moins laisse-t-il ici transparaître un appétit :
▻http://seenthis.net/messages/271377

http://i.imgur.com/5XIlWPv.jpg

Pour compléter :
►https://core.spip.net/issues/3909
▻https://classic.moqups.com/tetue/NbOp6vnH/p:ad287b8cc

So, that’s the challenge. How can we help people relearn how the web is now?

Just like when people have a content management problem, a lot of people are turning to technology for the answers. And just like content management problems, my experience is software can’t fix it. Because it’s a people problem, not a software problem.

#interface #pédagogie

Je note au passage que Mark Boulton a décrit exactement le même découpage des CMS que ce que j’ai écrit il y a quelques semaines : en trois espaces. Et qui plus est, dans le même ordre.

1) A space for writing. For writing and structuring.
2) A space for management. For adding meta data, workflow, configuration and managing roles and people.
3)The website space. Basically your website. A place where you begin the access user journey. Or preview your content. Generally the starting points for lots of little administration tasks.

Réflexions sur #SPIP, CMS, gestion de contenu
►http://rastapopoulos.artizanal.info/notes/reflexions-sur-spip-cms-gestion-de-contenu

Dans un logiciel comme SPIP, il y a plein de fonctionnalités différentes, mais si on prend un peu de recul, je pense que l’on peut découper en trois grandes zones :
– Édition de contenu : créer et modifier des objets éditoriaux
– Gestion de contenu : stocker, classer, versionner et gérer les droits d’accès
– Publication du contenu : rendre visible aux autres du contenu, que ce soit celui provenant de l’édition OU d’autre part (boucle DATA, etc)

Bon, il m’a grillé de 14 jours : il a publié ça le 3 septembre, et moi le 17 septembre. :)

et cc @tetue je pense que ça peut l’intéresser.

Pas mal cette phrase aussi (vraiment plein de trucs biens quoi) :

But for most use cases, a WYSIWYG is not useful for content people. It’s just familiar.

(Après cinq ou six commentaires j’aurai fini par citer l’article en entier, haha.)

Et 4) une zone d’échange, ou comment répondre à la publication, la commenter — ce qui invoque les réflexions en cours sur les commentaires décentralisés (ou pas).

D’accord avec le reste, oui. Je pense aussi que ces « espaces » doivent être des briques modulaires indépendantes : qu’on puisse rédiger avec un outil A et publier via l’outil B. Ce qui signifie que nos/mes contributions ne doivent plus se faire au sein de tel ou tel CMS, mais être autonomes pour être plugables sur l’un ou l’autre.

J’approuve vos commentaires @rastapopoulos et @tetue ! ;-)

thanks @speciale

et tu préfères lequel ? (question sérieuse)

Aucun ne me convient : tous ont des « erreurs », dans le sens où aucun n’offre toutes les possibilités de mise en sens d’un texte (citation, titraille, définitions ?), offrant pourtant des possibilités de mise en forme superficielle (couleurs, retrait).

Je préfère l’approche et l’interface suggérée ici (cf. ▻http://seenthis.net/messages/158560) :

http://nicolas-guilhou.com/img-articles/text-editor.png

Il est quand même plus aisé de rédiger son texte au kilomètre, les mains sur le clavier, sans devoir s’interrompre tous les trois mots pour cliquer un bouton ! Bref, je préfère les raccourcis clavier aux clicodromes.

Ceci dit, cette approche n’exclut pas l’ajout d’une barre de boutons cliquables. Dans ce cas je préfère sans hésitation la dernière, celle de Redactor : simple, sans filets superflus, en une seule ligne. Ce qui me rappelle le relookage que j’avais fait de la barre typo pour SPIP 3 :

http://i.minus.com/jbuBbC5ZdCvv4a.png

En y regardant de plus près, l’éditeur Redactor (dont il était déjà question ici : ▻http://seenthis.net/messages/108537) s’avère assez complet, ce que ne montrent pas les captures précédentes : titraille et citations sont bien disponibles, mais étonnamment cachées en sous-menu dépliant.

L’usage ne dément pas la simplicité apparente, c’est agréable. Par contre, c’est toujours aussi laborieux de faire une simple liste en WYSIWYG, là où des tirets à la ligne suffisent en texte brut… et je n’ai pas trouvé comment faire une liste imbriquée. Recalé ! Mais c’est très réussi pour les tableaux et l’insertion d’image : immédiatement visible, tout en restant simple. Nettement mieux que TinyMCE et CKEditor !

Râh, ça me donne envie de spécifier mon éditeur idéal !

Niveau ergonomie peut-être, mais ça génère encore uniquement du HTML, donc problématique quand on ne veut pas enregistrer ça (en base ou en fichier, enfin peu importe le mode de stockage).

Et sinon, la page d’accueil démarre par un livre d’Ayn Rand, #wtf ? :D

moi ça ne me dérange pas de stocker du html — on a des html2text assez efficaces maintenant quand on a besoin d’une version texte (indexer, envoyer un mail)…

@Rastapopoulos : oui, mes considérations étaient d’ordre ergonomique, d’abord UI puis UX. Le format de contenu stocké est une autre problèmique, sans rapport direct, puisque non dépendant de l’interface (barre typo, syntaxe ou WYSIWYG). Faut pas tout mélanger.

@fil Oui, c’est vrai, tant que le HTML est propre, sans imbrications bizarres ni classes utilisées pour des fonctionnalités.

Mais je ne sais pas si c’est vraiment le format pivot idéal (pour générer « pas que du web », à partir de ce qui a été rédigé).

On abandonne la piste Markdown aussi alors, et on revient à du HTML uniquement ?

Bon ça ne résout pas la question des « modèles » (inclusion avec possiblement des paramètres), fonctionnalité qui n’est pas propre à SPIP, utilisée dans d’autres système (entre autre les wikimedias évidemment).

@tetue ce n’est pas mélangé, ça a une incidence et un rapport. En effet, un éditeur qui n’édite que du HTML, c’est beaucoup plus facile de faire du wysiwyg (ce dont on parle ici) puisqu’il édite directement ce qui sera produit au final. Alors que quand on veut un autre format, il faut forcément passer à un moment dans un compilateur (que ce soit côté client ou côté serveur) qui va produire le HTML permettant de voir (le what you see).

Ce qui fait que quand on décide que le HTML produit nous suffit, il ne reste « plus que » l’interface, l’ergonomie, à étudier. La partie technique étant à peu près résolue (mise à part pour les inclusions/modèles).

Il est initialement question d’interface, pas tant de l’éditeur, plus précisément de la « barre typo » (ici WYSIWYG, mais pas forcément, comme c’est le cas de SPIP, et générant… peu importe). C’est-à-dire des boutons, des pictos (symbolisant les enrichissements possibles), de leur nombre, leur répartition, leur graphisme, etc.

L’article cité montre l’évolution dernière de cet élément d’UI. On remarque une nette tendance à la simplification : moins de couleurs, moins de boutons, moins de lignes, d’encombrement, moins d’effets… Ce qui est frappant dans cette uniformisation, c’est : niveaux de gris avec accentuation du contraste négatif ayant pour conséquence de valoriser le signe, mais aussi la persistance d’un effet de relief discret, façon métal brossé, délicat, presque étonnant en ces temps de flat design. Ça n’est pas anodin.

Quels boutons mettre à dispo dans une barre typo ? Dans quel ordre les ranger ? Comment préserver la simplicité ? Faciliter l’usage ?

Peut-être que l’aspect bombé continue de faire consensus pour signifier que ce sont des boutons, qu’on peut appuyer dessus. Mais ça ne marche pas forcément comme explication vu que toute la barre est bombée, alors que seuls les endroits où il y a des pictos sont cliquables.

Oui, ça m’intrigue. D’autres exemples contemporains :

Chez Dotclear (avec syntaxe wiki2xhtml) :

http://i3.minus.com/jbyCPkwZ6dxzwI.png

Barre typo vue chez Opquast Community :

http://i7.minus.com/jbkPK8cPZo5OI7.png

Aloha Editor (façon Word) :

http://i2.minus.com/jgW9AGQhvxWzk.png

Dans Redmine (avec Wiki formatting) :

http://i4.minus.com/jkFu7ZxpzuDgA.png

Pour compléter :
▻https://seenthis.net/messages/278492
►https://core.spip.net/issues/3909

Grillé : ▻http://seenthis.net/messages/159158

source #irc #spip
14:22 < paulgelo> _Amaury ►http://livetools.uiparade.com