JavaScript Markdown Editor - SimpleMDE
▻https://simplemde.com
Un éditeur Markdown en javascript qui propose une vue « quasi » WYSIWYG tout en gardant le code des raccourcis syntaxiques visible. Le concept mi-chèvre mi-choux semble pertinent pour les débutants comme pour les « power-users »
Le dépôt Github : ▻https://github.com/sparksuite/simplemde-markdown-editor
#éditeur #WYSIWYG #javascript #markdown #SPIP
Il y a 3 ans… avec détails et roadmap des choses à faire dans l’ordre :
►https://core.spip.net/issues/3720
How to develop a WYSIWYG editor in #android just like Medium
▻https://hackernoon.com/how-to-develop-a-wysiwyg-editor-in-android-just-like-medium-30e0d4c8471f
How to develop a WYSIWYG editor in AndroidDevelop a WYSIWYG editor for Android in one day.If you are a developer, you may have tried out Medium’s editor. It is a world-class service for bloggers and its user experience is an industry standard for blogging sites.Index —What is WYSIWYG Editor?Internal Architecture of the editor.How to store the content?This blog will help you understand how to think when you want to build an editor, what are the building blocks, and basic rules that you must pay attention to.I’ve also given a link to my sample at the end of this blog for your reference in case you get stuck somewhere or you directly want to go through the code.So let’s begin,What is a WYSIWYG Editor?WYSIWYG is an acronym for “what you see is what you get”. A WYSIWYG editor is a system in which (...)
#medium-editor #build-medium-editor #wysiwyg-editor #text-editor-android
Mark Text
▻https://marktext.github.io/website
Mark Text is a Markdown editor for Mac, Windows, and Linux. It is a concise text editor, dedicated to improving your editing efficiency.
Mark Text supports both the CommonMark Spec and the GitHub Flavored Markdown Spec. Because Mark Text is a realtime preview editor text styles and formatting update automatically as you type.
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...
@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
Retour d’experience sur le developement d’un éditeur rich text, axé rédaction digital, pour le NYT.
manipulation DOM, Utilise ProseMirror, intéressant pour la structuration des blocs imbriqués de contenu…
Building a Text Editor for a Digital-First Newsroom
▻https://open.nytimes.com/building-a-text-editor-for-a-digital-first-newsroom-f1cb8367fc21
▻https://seenthis.net/messages/693664
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 !
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…)
No 1 : Faire avec
▻http://www.revue-backoffice.com/numeros/01-faire-avec
La revue Back Office interroge les notions d’outil, d’instrument et d’appareil, dans le contexte du design. Source : Back Office
▻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.
@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…)
document.execCommand - Référence Web API | MDN
▻https://developer.mozilla.org/fr/docs/Web/API/Document/execCommand
Edition directe d’un document HTML (designMode) ou d’un bloc de contenu (contentEditable) dans le navigateur : la doc des commandes pour manipuler le contenu de la zone modifiable. La plupart des commandes affectent la sélection du document (gras, italique, etc.), tandis que d’autres ajoutent de nouveaux éléments (ajout d’un lien) ou affectent une ligne entière (indentation).
Voir aussi :
– une démo simple : ▻https://codepen.io/eniotna/pen/OVZvMG
– le code d’un éditeur complet : ▻https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Editable_content
#édition #WYSIWYG #SPIP #crayons #javascript #contentEditable #execCommand
BlueGriffon 3.0 - <Glazblog/>
▻http://www.glazman.org/weblog/dotclear/index.php?post/2017/11/16/BlueGriffon-3.0 #html #editor #epub
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à)
BEd : un éditeur graphique pour Beamer (présentations LaTeX) - LinuxFr.org
▻https://linuxfr.org/users/jbd/journaux/bed-un-editeur-graphique-pour-beamer-presentations-latex
Je développe depuis quelque temps, épisodiquement et principalement pour mon utilisation personnelle, le logiciel BEd (Beamer Editor). Je profite de sortir la version 1.3 pour faire un peu de pub ici. Le logiciel est publié sous licence libre (GPL 3). Les sources (python, LaTeX) sont disponibles sur framagit, avec un script d’installation. Il existe aussi des paquets pour Arch Linux (bed-latex et bed-latex-git) et un paquet deb.
Du goût d’aller plus loin en LaTeX - Geekographie Maïeulesque
▻https://geekographie.maieul.net/212
Je suis en ce moment contraint, pour des raisons de relations avec un éditeur, d’utiliser Word pour écrire un texte. Je ne cesse de râler sur divers réseaux sociaux sur l’inefficacité de cet outil, que ce soit à cause du manque de souplesse de Zotero vis-à-vis de biblatex [1] ou de la lenteur de la bascule d’un style à l’autre [2]. Ceci rejoint plusieurs réflexions que je me fais et questions que je me pose depuis que j’utilise LaTeX, c’est-à-dire presque sept ans maintenant. À cet égard, j’aimerais bien l’avis de mes lectrice·cteur·s.
MediumEditor
▻http://yabwe.github.io/medium-editor
Un éditeur de texte en ligne sans textarea . Pur javascript (pas de lib compliquée/lourde). Nombreux modules complémentaires (ajout d’images ou vidéos, de code HTML, utilisation de Markdown...)
#SPIP #crayons #javascript #wysiwyg #editeur
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 :))
Squire
►http://neilj.github.io/Squire
Un éditeur wysiwyg simple et léger (en HTML 5) basé sur un iframe dont le <body> à pour attribut « contenteditable=’true’ » à la place du classique <textarea> (autorise aussi l’utilisation d’un quelconque noeud du DOM à la place d’un iframe)
Utilisé comme éditeur du webmail ProtonMail
Squire is an HTML5 rich text editor, which provides powerful cross-browser normalisation, whilst being supremely lightweight and flexible. It is built for the present and the future, and as such does not support truly ancient browsers. It should work fine back to around Opera 10, Firefox 3.5, Safari 4, Chrome 9 and IE8.
Unlike other HTML5 rich text editors, Squire was written as a component for writing documents (emails, essays, etc.), not doing wysiwyg websites.
If you are looking for support for inserting form controls or flash components or the like, you’ll need to look elsewhere. However for many purposes, Squire may be just what you need, providing the power without the bloat.
Installation
– Download the source from neilj/Squire
– Copy the contents of the build/ directory onto your server.
– Edit the <style> block in document.html to add the default styles you would like the editor to use (or link to an external stylesheet).
– In your application, instead of a <textarea>, use an <iframe src='https://seenthis.net/path/to/document.html'>.
– In your JS, attach an event listener to the load event of the iframe. When this fires you can grab a reference to the editor object through iframe.contentWindow.editor.
– Use the API below with the editor object to set and get data and integrate with your application or framework.
Voir la doc officielle sur ▻https://github.com/neilj/Squire/blob/master/README.md
Javascript WYSIWYG editors · cheeaun/mooeditable Wiki
▻https://github.com/cheeaun/mooeditable/wiki/Javascript-WYSIWYG-editors
Javascript WYSIWYG editors
Features | #WYSIWYG HTML Editor | Froala
▻https://www.froala.com/wysiwyg-editor/features
Le mythe de l’éditeur WYSIWYG
▻http://www.hteumeuleu.fr/le-mythe-de-l-editeur-wysiwyg
Je ne pense pas que créer une interface qui permette de résoudre ces problèmes soit impossible. Mais la complexité de ces problèmes rendrait une telle interface aussi complexe que les problèmes qu’on essaie de contourner. Et même si ça peut être difficile à avaler pour certains, je suis convaincu que la complexité de HTML et CSS est un bien nécessaire.
Froala WYSIWYG HTML text Editor
▻http://editor.froala.com
Froala Editor is beautiful jQuery WYSIWYG HTML text editor
High performance and modern design make it easy to use for developers and loved by users. It is one of the few rich text editors around with Retina Ready design which makes it a really cute editor.
What you see is what you… ? - romy.tetue.net
▻http://romy.tetue.net/wysiwyg-wysiwym-wysiwyc
Le WYSIWYG n’est pas une interface, mais un mode d’édition parmi d’autres :
– #WYSIWYG = édition avec aperçu du rendu visuel final
– #WYSIWYM = édition avec aperçu sémantique
– #WYSIWYC = édition directe du code source
Mieux qu’une barre d’édition : des raccourcis
▻http://romy.tetue.net/barre-outils-edition-raccourcis
Les barres d’outils d’édition ne sont pas accessibles. Pire, elles constituent des obstacles pour certain·e·s. Si elles sont utiles à d’autres, elles ne sont pas la meilleure aide qui soit. Elles ne constituent donc pas une aide suffisante, mais secondaire ; l’aide principale doit être autre. Enfin, dans le cas où une barre d’édition est disponible, celle-ci doit être absente par défaut et affichable à la demande. Et chaque fonctionnalité devrait faire l’objet d’un raccourci documenté.
Même s’ils causent certaines difficultés, les raccourcis clavier standards sont davantage utilisables. Mieux encore, les raccourcis de saisie ou syntaxe de rédaction à balisage léger, de type wiki, sont ce qu’il y a de plus utilisable par tous et toutes. Trop peu mis en avant, ces raccourcis sont méconnus. Ils nécessitent d’être expliqués par l’interface, en contexte. Il suffit d’une phrase explicative, avant chaque champ de saisie.
#toolbar #WYSIWYG #raccourcis #syntaxes_légères
#handicap #accessibilité #a11y #ergonomie #UX #clicodrome
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 :)
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
#WYSIWYG Round Up
▻http://www.uxbooth.com/articles/wysiwyg-round
Tags : #CMS WYSIWYG
WYSIWTFFTWOMG! | Mark Boulton
▻http://markboulton.co.uk/journal/wysiwtfftwomg
“The issue with #WYSIWYG for me is that by using them the content person is considering the content as what they see. But content is more than that.” Tags: WYSIWYG #WCM #CMS #gestion_de_contenu
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.
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 ! ;-)
Simplest HTML5 WYSISYG Inline Editor • Barney Parker
▻http://www.barneyparker.com/?p=122
pretty basic tools to be able to edit content, bold, italic, h1, h2 and so on.
Industry design trends
▻http://imperavi.com/blog/industry_design_trends
En 2012, chaque éditeur WYSIWYG était unique, mais la tendance est à l’uniformisation :
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) :
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 :
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
@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) :
Barre typo vue chez Opquast Community :
Aloha Editor (façon Word) :
Dans Redmine (avec Wiki formatting) :
Ui Parade - Live Tools
▻http://livetools.uiparade.com/index.html
générateur WYSIWYG pour boutons, formulaires et icones : permet de récupérer CSS (3) et HTML
#css3 #générateur #wysiwyg #web-based #bouton #formulaire #icone
Brûlons les « traitements de texte » embarqués
▻http://nicolas-guilhou.com/news/2012/11/07/Brulons_les-traitements_de_texte-embarques
Alors que normalement qu’est-ce qu’on veut, hmmm ? RÉDIGER DU TEXTE BORDEL
Pas chercher un pictogramme, se battre avec un JS qui a planté ta jolie interface TinyMCE ou mieux une implémentation de ce joyeux bordel qui ne fonctionne pas dans ton navigateur (si, c’est possible).
[…]
Et notre rôle — à nous concepteurs — est, avant d’être un poil feignants, d’éduquer correctement nos utilisateurs. Je parle d’utilisateurs dans un premier temps, pas de clients, mais les deux ne sont pas incompatibles. Et c’est là qu’interviennent les extraordinaires formats de texte structuré que sont Markdown et Textile.
[…]
Les formats de texte structurés appliquent ce modèle d’interaction depuis la nuit des temps, en y ajoutant la visibilité du changement de mode, la lisibilité en affichage dégradé et une structure syntaxique exploitable tant pour le formatage (usages actuels) que pour la gestion de documents longs, telles les publications en Setext des années 90, dont les lecteurs assidus disposaient d’afficheurs sophistiqués gérant bibliothèques de documents, tables des matières, chapitres, rappel de liens en bas de page etc., tout cela à partir d’un contenu lui-même parfaitement lisible en texte brut et surtout, surtout, sans attendre des rédacteurs la maîtrise des concepts de plan/structure/feuille de style.
[…]
Les gars de chez Textpattern ont presque fait l’interface de rédaction ultime. Un champ texte, point barre. Et une liste de commandes disponibles à côté. […] Le but est de laisser en permanence sous les yeux du rédacteur les commandes les plus usitées (dans son contexte de rédaction). Passées les quelques heures d’apprentissage, l’utilisateur n’aura même plus besoin de regarder cette aide et pourra se concentrer sur ce qu’il fait : rédiger.
#redaction #markup #MicrosoftWord #WYSIWYG #Markdown #Textile #Textpattern #clicodrome
Effectivement, comme tu le dis en commentaire, c’est un vieux refrain. On ne peut que plussoyer.
Et dans ce que dit le monsieur, j’aime particulièrement :
Mon métier, en plus de tout ce que je viens d’énumérer, c’est d’essayer de changer les usages.
Tout est dit.
je pense qu’il est temps de faire œuvre de pédagogie, de conviction.
Pourquoi faire ? Le boulot des contributeurs à un site web n’est pas de faire de la mise en forme mais de produire du contenu. Pourquoi leur prendre la tête avec des raccourcis typo alors qu’ils savent instinctivement utiliser un WYSIWYG ? Si c’est une question de qualité du code généré, c’est le problème des développeurs pas celui des utilisateurs.
Je suis en train de rédiger dans un WYSIWYG et c’est pénible : c’est beaucoup plus long et compliqué d’aller chercher le bouton qui fait des listes, deviner quand il faut le cliquer (avant ? ou après avoir saisie ma liste, pour la mettre en forme) alors qu’il est si simple d’aller à la ligne en commençant par un tiret !
Pour la saisie de texte simple (gras, liste, intertitre), il n’est pas nécessaire de tant se compliquer la vie.
On dit du mal de Word mais il transforme les tirets successifs en liste spontanément.
il transforme les tirets successifs en liste spontanément
Et quelle qualité ça lui fait là ! :)
Le boulot des contributeurs à un site web n’est pas de faire de la mise en forme mais de produire du contenu
Du contenu web, oui. Word, c’est fait pour faire du print, et du web « comme du print »...
à part ça, c’est un logiciel privateur, pas franchement interopérable et pas très « écologique » non plus...
Peut importe, Libreoffice fonctionne de la même manière. Le fait est que les utilisateurs connaissent ces interfaces. Les forcer à acquérir de nouveaux automatismes n’est pas leur rendre service aussi bien intentionné soit-on.
Rahh, l’article n’est plus en ligne :(
Quelqu’un a une sauvegarde ?