CodePen - CSS clip-path Editor
▻https://cdpn.io/stoumann/fullembedgrid/abZxoOM?animations=run&type=embed
un outil simple pour créer des règles CSS clip-path
visuellement
Le #no-code, nouveau sésame pour les non-initiés à la #programmation ?
Le mouvement no-code est devenu en trois ans une vraie alternative à la programmation. Des solutions comme #Bubble, #Webflow, #Airtable, #Glide permettent de créer un #site_web ou une #appli_mobile sans pour autant être un développeur confirmé.
En gros,
Cette nouvelle méthode va aider à décharger ces ingénieurs de l’écriture de codes à faible valeur ajoutée, une tâche qu’ils considèrent comme ingrate et qu’ils ont tendance à saboter.
▻https://usbeketrica.com/fr/article/le-no-code-nouveau-sesame-pour-les-non-inities-a-la-programmation
donc ils créent des outils à « forte valeur » ajoutée pour que les utilisateurs et utilisatrices finales sabotent eux-même leur code, c’est ça ? Car j’ai du mal à croire que des applis #wysiwyg produisent un code aussi propre qu’un être humain qualifié. Sans parler de l’accompagnement.
Bref, c’est encore une fois sur le marché lowcost que ça tire vers le bas...
#développement #webdev (no-)#html #no_code
Le #wysiwyg en web, c’était Dreamweaver : le pur cauchemar quand tu passais derrière. Le truc qui imbriquait les balises en mode infini sans jamais rien réécrire. Pas de commentaires, bien sûr. Du code de merde.
Et Ad0b€ InDesign ! ! ! Bon sang ! DreamWeaver, c’était presque W3C par rapport à InDesign !
Toujours cette idée de nouveauté qu’elle est neuve et que c’est un nouveau sésame… C’est juste qu’on en a toujours bouffé sur le Web de ces promesses avec Dreamweaver, Director, Flash… depuis les années 90.
Un aspect vraiment flippant de ces trucs, c’est qu’on continue de fabriquer des jeunes professionnels dont on a encouragé l’incompétence informatique, et qui vont en chier toute leur vie dans des boulots de merde où il n’y a pas d’argent à gagner.
30 ans après, on continue à fabriquer des graphistes, designers, photographes… fiers d’avoir une maîtrise totalement superficielle de leurs outils informatiques. Des gens qui ensuite se lancent sur le marché en étant à la fois moins efficaces et moins « innovants » (y compris sur leur cœur de métier, c’est-à-dire les créations graphiques et visuelles) que leurs concurrents, et vont dépendre de prestataires informatiques qui vont la leur faire à l’envers systématiquement.
L’impossibilité de défendre ton boulot, parce qu’il est toujours plus ou moins approximatif/amateur au moment du rendu, et les clients seront souvent insatisfaits, parce que la fin de la prestation est toujours bordélique (ça marche pas, ça marche pas bien, personne ne sait pourquoi parce que personne n’a la moindre compétence…). Donc végéter dans des petits boulots mal rémunérés et peu gratifiants.
Et évidemment l’impossibilité de survivre quand le seul logiciel Wysiwyg que tu maîtrises disparaît (le massacre quand Flash a disparu, le massacre quand ton client peut s’acheter pour 5 dollars un template tout fait et que tu ne peux proposer rigoureusement aucune valeur ajoutée par rapport à ça…).
Ça fait 30 ans que je vois passer des gens qui galèrent parce qu’on leur a fait miroiter qu’ils pourraient devenir des professionnels avec des outils Wysiwyg, et qu’une fois sur le marché professionnel, c’est une catastrophe et ils sont cantonnés comme tu dis au low-cost, où il y aura toujours quelqu’un d’encore moins cher, et pas forcément plus incompétent (genre à se retrouver au bout de 5 ou 10 ans sur une « place de marché » en ligne en concurrence avec des boîtes low-cost installées en Inde).
Editor.js
▻https://editorjs.io
Un éditeur de texte pour appli web, structuré en mode « blocs » et avec une sortie en JSON (semblerait un bon candidat pour un éditeur moderne pour SPIP...)
Key features:
– It is a block-styled editor
– It returns clean data output in JSON
– Designed to be extendable and pluggable with a simple API
What does it mean «block-styled editor»
Workspace in classic editors is made of a single contenteditable element, used to create different HTML markups. Editor.js workspace consists of separate Blocks: paragraphs, headings, images, lists, quotes, etc. Each of them is an independent contenteditable element (or more complex structure) provided by Plugin and united by Editor’s Core.
There are dozens of ready-to-use Blocks and the simple API for creation any Block you need. For example, you can implement Blocks for Tweets, Instagram posts, surveys and polls, CTA-buttons and even games.
What does it mean clean data output
Classic WYSIWYG-editors produce raw HTML-markup with both content data and content appearance. On the contrary, Editor.js outputs JSON object with data of each Block. You can see an example below
Given data can be used as you want: render with HTML for Web clients, render natively for mobile apps, create markup for Facebook Instant Articles or Google AMP, generate an audio version and so on.
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
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 #WYSIWYG
@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…)
le ticket de @rastapopoulos est maintenant ici : ▻https://git.spip.net/spip/porte_plume/issues/3720
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
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.