• 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

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

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

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

      #clicodrome

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