Evolution #3909 : Rendre optionnels les boutons d’édition - Porte-plume

#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

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