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) :
-
-
