Pas plus tard qu’un jour, j’étais sur ce BBS, et j’ai cherché partout,
mais je n’ai trouvé aucun bouton d’aide Markdown pour expliquer les règles de mise en forme.
Non, je ne demande pas quelles sont les règles.
Je ne demande pas non plus de lien.
Je dis que vous devez fournir un lien aux personnes qui publient,
juste à côté de la zone de texte, lorsqu’elles l’éditent.
Bon, d’accord, peut-être que toute documentation n’est pas encore prête pour les utilisateurs moyens,
La barre d’outils du compositeur propose des options qui mettraient le texte en forme pour vous et vous montreraient comment cela fonctionnerait si vous vouliez ajouter le Markdown [1] manuellement. N’est-ce pas plus utile qu’un lien qui vous mènerait à une documentation extérieure au message que vous écrivez ?
»
Eh bien, il finit par découvrir la bonne façon de le faire ressembler à « https://www.openstreetmap.org/, pas https://www.openstreetmap.org/edit
».
Mais il n’y a absolument aucun moyen qu’il ait pu le découvrir s’il n’avait pas eu à le découvrir par lui-même, car, là dans l’éditeur, c’est un grand mystère, avec zéro documentation. Zéro.
Vous avez une façon assez intéressante d’utiliser un utilisateur, lui ou vous chaque fois que vous voulez dire moi. Je dis ça, je dis rien.
Il existe trois types d’éditeurs sur le Web pour la création de contenu dans un service :
Style CMS comme WordPress, Drupal, etc., où il y a des tonnes de boutons (bon, WordPress fait tout ce qu’il peut pour casser son éditeur, mais c’est une autre histoire)
SoMe minimaliste, comme Facebook, Twitter, etc., où il n’y a pas de boutons ou juste quelques-uns
Le monde des développeurs ancien, qui sont principalement des générateurs de sites statiques, etc., et Discourse
Le premier groupe essaie d’utiliser la même logique que les suites bureautiques nous ont enseignée avant même le Web. Il n’y a pas de vrai bouton d’aide, car tout le monde devrait savoir ce que fait un bouton. Ou quelles sont les raccourcis. Et si un utilisateur ne sait pas, il/elle/ça doit trouver cette information.
Les médias sociaux ont compris que le commun des mortels n’a pas besoin de ces boutons, car ils ne les utilisent pas – et sur mobile, il n’y a tout simplement pas de place. Et il n’y a pas de bouton d’aide, car il n’y en a pas besoin.
Les éditeurs basés sur le développement offrent un service à ceux qui savent marquer les choses sans avoir besoin de le voir se produire, se souvenir d’un tas de code et ne veulent pas lâcher leur clavier. Et il n’y a pas de bouton d’aide, car tout le monde doit lire la documentation et mémoriser comment faire des tableaux, par exemple.
Mais il y a des utilisateurs différents. Sur mon forum, les gens ordinaires parlent de sujets ordinaires et ont principalement de faibles compétences techniques. Ici, sur Dev ou sur GitHub, les besoins sont totalement différents, et on suppose que tout le monde a des compétences très élevées. De plus, le contenu créé est totalement différent. Je suis membre d’un site où l’écriture elle-même est mise en avant. Là, encore, les besoins sont totalement différents.
La question de l’UX n’est pas un bouton d’aide dans la boîte à outils. Personne ne l’utilise, car il est impossible à créer et à utiliser. Et même un lien de style GitHub est trop. C’est un composant totalement non pertinent qui est rarement utilisé et tout le monde sait qu’il y a de la documentation et des manuels.
La vraie solution UX/UI est de donner la possibilité aux :
administrateurs de créer des valeurs par défaut pour les utilisateurs
utilisateurs de modifier les valeurs par défaut
Et ce dont la grande majorité des utilisateurs a réellement besoin, et ce qui manque maintenant, c’est un moyen de masquer cette barre d’outils. Ce serait plus important que la possibilité de la modifier.
La question de l’éditeur est presque un sujet de FAQ ici, et un bouton d’aide n’en est qu’une partie. Et soyons clairs à nouveau. Dan a son propre agenda et le bouton d’aide n’en est qu’un autre signe, pas le but. J’espère que Dan essaie en fait de dire qu’il ne savait pas comment faire quelque chose et qu’il n’a pas trouvé d’aide pour cela. Ce devrait être un problème de ce site, pas de Discourse en tant que plateforme en soi.
et les deux aperçus de liens étaient identiques, ce qui rendait mon message ridicule.
J’ai donc lutté avec l’interface (Discourse) pour essayer de trouver un moyen de désactiver
toute cette magie — sans aucune documentation sur la façon de le faire.
qui, oui, a sa logique, mais ce n’est pas mon propos.
Ce n’est toujours pas ce que je voulais que mon message ressemble pour les autres.
À ce moment-là, je me suis dit : “Je vais juste consulter la documentation officielle au lieu de passer des heures à faire des essais et erreurs.”
OK, j’ai cherché et cherché et trouvé Formatting posts using markdown, BBCode, and HTML .
OK, cela mentionnait le format [url]http://bettercallsaul.com[/url], mais avec
Tout
ce
que
je
dis,
c’est
qu’il
devrait
y
avoir
un
document
officiel
quelque
part
qui
indique
aux
utilisateurs
ce
qui
se
passera
quand
ils
taperont
tel
ou
tel
caractère.
Ils
ne
devraient
pas
avoir
à
lire
le
code
source
pour
le
savoir.
Merci.
Bien, mettez-le dans une FAQ, puis liez la FAQ à l’interface quelque part.
OK, disons que vous mettez la future FAQ sur le formatage sur le site Discourse. Problème résolu…
sauf que l’utilisateur sait-il même qu’il utilise Discourse ? Oui, je parle des utilisateurs, pas des administrateurs. Merci encore.
C’est un épouvantail. Il y a peut-être quelques développeurs très dévoués qui ont mémorisé les règles de formatage et n’ont pas besoin de documentation, mais tous les non-débutants n’ont pas mémorisé toutes les règles de formatage.
Avec les différentes saveurs de markdown, BBCode et html prises en charge par différentes instanciations de Discourse, il n’y a pas de manuel dans la documentation.
Si quelqu’un crée un manuel pour l’ensemble particulier de codes de balisage valides sur un site, et souhaite placer un lien d’aide de style github sur la page du compositeur, comme ci-dessous, comment pourrait-on y parvenir ?