Police monospace dans l'éditeur exclusivement Markdown

Annonces
43

Mon objectif n’est pas de me concentrer sur « ajoutons ou supprimons la police monospace ». Différentes personnes, différents goûts.
Je pense que lorsqu’une entreprise propose quelque chose depuis longtemps, si elle veut le changer, cela ne devrait pas être obligatoire, mais facultatif.

Vous préférez le markdown avec la police monospace. Bien.

Je préfère le markdown tel qu’il a toujours été avec la police sans-serif. Bien.

Mais maintenant, je suis obligé soit d’utiliser le texte enrichi, que je ne me vois pas utiliser, soit d’utiliser une nouvelle version du markdown que je n’ai jamais utilisée et que je n’aime pas.

Le markdown avec la police sans-serif ou monospace devrait être proposé en option, au lieu de forcer tous les utilisateurs à s’habituer à quelque chose dont certains d’entre nous ont déjà montré que ce n’était pas à leur goût.

Justifier ce changement en disant « c’est un environnement de codage » n’a pas de sens, car nous ne codons pas dans le compositeur. Nous tapons du texte normal et parfois nous le formatons en utilisant le markdown. Ce n’est pas un environnement de codage.

Encore une fois, le débat pour moi est de savoir si la police monospace doit rester ou non. Il s’agit pour moi d’avoir la possibilité de choisir ce que j’aime. Et la solution de contournement CSS ne fonctionne que pour ma communauté. Qu’en est-il de toutes les autres communautés qui utilisent Discourse où je suis maintenant forcé au nouveau changement ? Cela n’a aucun sens pour moi.

4 « J'aime »
44

En effet, pour tous les utilisateurs de tous les forums qui n’ont pas encore proposé le nouveau compositeur, la monospace est un changement. Et je pense que ce n’est pas génial.

3 « J'aime »
45

Gardez à l’esprit que ce changement permet aux utilisateurs de savoir rapidement s’ils sont en mode code source ou en mode riche

IMG_9777
IMG_97771179×2556 193 KB

Ma préoccupation concernant le retour en arrière est que cela optimise pour les utilisateurs qui ne veulent jamais utiliser l’éditeur de texte riche et qui sont réfractaires au changement. Une option « pas de texte riche pour moi » n’atteindrait-elle pas le même objectif ?

3 « J'aime »
46

Seulement s’ils connaissent cette différence et quoi faire à ce sujet. Le mode riche est là pour les personnes qui ne peuvent pas faire **gras**.

Tout ce qu’ils voient, c’est une police de caractères difficile.

Et encore une fois, si un administrateur utilise le mode riche par défaut, cela n’arriverait que si cet utilisateur clique ou touche au mauvais endroit, et ne peut pas comprendre ce qui s’est passé.

Et une deuxième fois, la monospace est difficile pour les yeux :man_shrugging:

Mais nous avons tout cela

IMG_2455
IMG_24552360×920 141 KB

Je ne sais pas si

Activer monospace en mode code source (vraiment… l’appeler ainsi révèle quelque chose :smirking_face:)

serait une chose si terrible (si c’était raisonnablement facile à construire).

3 « J'aime »
47

… et ils peuvent facilement cliquer sur un bouton pour le faire disparaître :slight_smile: ils sont donc encouragés à utiliser la police « facile », qui est superbe. 99,9 % des utilisateurs devraient simplement opter pour cela pour la création occasionnelle.

Je comprends que certaines personnes insistent pour une préférence utilisateur, nous en discutons également en interne. C’est délicat, nous n’ajoutons généralement des préférences qu’en dernier recours, c’est peut-être l’un de ces cas.

De plus… je ne considère pas notre comportement comme une exception :

Reddit, le 6e site le plus consulté sur Internet, fait exactement la même chose :

image
image1205×601 122 KB

image
image777×696 37.7 KB

Il ne fournit aucune option pour remplacer cela…

5 « J'aime »
48

Et qu’en est-il d’un plugin ?

Les administrateurs devraient alors investir activement du travail dans cette fonctionnalité et les chiffres d’utilisation montreraient si cette option est vraiment nécessaire.

1 « J'aime »
49

Je suis curieux : qu’est-ce qui plairait davantage aux administrateurs ?

  • Composant de thème - changer la police globalement
  • Plugin - réglage par utilisateur pour la police
0 voters
50

Comme la route du composant de thème est si ouverte, je ne comprends pas pourquoi vous verriez un vote pour celui-ci comme un vote contre un plugin.

1 « J'aime »
51

Donc, les options sont, lorsqu’une police pose problème, alors

  • ne pas utiliser markdown, ou
  • utiliser cette police difficile

Donc…

Je pense que c’est nécessaire lorsqu’un forum mélange des trucs de développeur et des discussions plus courantes. Si un développeur acharné veut utiliser la police dactylographique partout, je comprends, mais je ne comprends pas pourquoi je suis obligé d’utiliser la même.

Mais c’est une situation quelque peu étrange : nous écrivons en utilisant une police qui n’offre aucun avantage, mais qui sert de marqueur pour le type de compositeur qu’un utilisateur utilise, et après cela, nous lisons et la police est totalement différente.

Vous savez très bien qu’il existe des exemples opposés beaucoup plus nombreux. Et je ne suis pas sûr que Reddit soit un bon exemple. Si c’est le cas, nous devrions aussi adapter Facebook.

2 « J'aime »
52

Facebook n’a pas de double mode. Je ne peux pas penser à beaucoup d’autres éléments qui ont un double mode, pouvez-vous donner quelques exemples ?

CKEditor fait aussi la même chose que nous :

image
image1177×1330 193 KB

Le code source en monospace est une convention très bien établie.

… avoir un markdown plus FACILE à éditer

Par exemple :

```
un
   deux
      trois
```

:up_arrow: un exercice de futilité en non monospace.

Parce que vous voyez

image
image260×148 1.47 KB

3 « J'aime »
53

Ce n’est pas important. L’important est que si vous utilisez Reddit comme exemple d’UX utile, parce qu’il est grand, alors vous devriez utiliser la même logique avec Facebook.

Reddit n’est pas vraiment si populaire en dehors des États-Unis et du monde anglophone natif.

Si je comprends bien, pour vous, une police monospace difficile à lire est un indicateur de l’éditeur markdown ? N’est-ce pas une façon un peu dure ? Ceux de mes utilisateurs, et moi, qui utilisons markdown, savons quel éditeur est utilisé, peu importe que la police soit la même.

Encore une fois — CSS est le sauveur. Mais pas ici. Dans Meta, j’ai deux et seulement deux options :

  • souffrir d’une police de machine à écrire vieille de 100 ans, parce que peu de sites l’utilisent
  • ne pas utiliser l’éditeur markdown

Alors… :man_shrugging: Peut-être que ce réglage est nécessaire, car vous ne me forcez pas non plus à utiliser des listes intelligentes.

(Hors sujet, je sais — mais les utilisateurs ordinaires ont seulement besoin d’une barre d’outils à un bouton : pour le téléchargement d’images)

54

Certains utilisateurs, comme moi, n’utiliseront probablement jamais le texte enrichi, donc ce n’est pas vraiment une fonctionnalité qui fait une différence. Si ma valeur par défaut est le markdown, c’est tout ce dont j’ai besoin pour le “savoir”.

Bien sûr, il y a les autres utilisateurs qui n’ont probablement aucune idée de ce qu’est le markdown et pour qui le texte enrichi est utile. Je comprends, tout comme tous les utilisateurs qui sont “contre” le changement. Nous ne rejetons pas ces utilisateurs. Nous demandons une option, pas une obligation.

D’après les commentaires que j’ai lus, absolument personne n’est réfractaire au changement. Vous utilisez cela comme justification de la décision prise par l’équipe. Je ne suis pas réfractaire au changement, et je dirais que d’autres utilisateurs sont dans le même cas. Nous demandons qu’une préférence soit accordée à ceux qui ne veulent pas de markdown + monospace ensemble.

C’est la même chose. Vous avez du mal à comprendre que “pas de texte enrichi” et “pas de texte enrichi AVEC sans-serif” sont deux choses différentes, étant donné que “pas de texte enrichi” signifie maintenant = monospace, qui est une mauvaise police.

N’est-il pas aussi “délicat” de forcer soudainement des milliers d’utilisateurs qui utilisent des forums depuis des années, en utilisant Discourse, à s’habituer à quelque chose qui s’est avéré ne pas être idéal pour la lecture ?

Par exemple, Facebook, X/Twitter, YouTube permettent des liens cliquables dans les publications. Instagram et TikTok ne le font pas.
Chaque entreprise est une entreprise. Ce n’est pas parce que Reddit ou CKEditor fonctionnent d’une certaine manière que vous devez les copier. Vous devez faire ce qui a du sens pour votre produit. Et encore une fois, personne ne vous demande de supprimer le texte enrichi ou le monospace. Nous demandons que ce soit une option. Certaines personnes aiment les thèmes clairs, d’autres les thèmes sombres. Certaines personnes aiment avoir un fond noir pur avec du texte néon pendant qu’elles codent, d’autres préfèrent les couleurs atténuées. Chaque personne est différente.
Cela n’a pas à avoir de sens pour vous, cela doit avoir du sens pour l’utilisateur.

Je ne veux pas paraître impoli ou quoi que ce soit. J’apprécie Discourse en tant que plateforme, surtout pour ses options d’auto-hébergement gratuites. Je trouve juste difficile d’accepter qu’une équipe de personnes, y compris des développeurs, etc., ait du mal à accepter qu’avoir une préférence utilisateur soit la voie à suivre, après près de 4 mois à nous demander de “laisser respirer”. J’ai laissé respirer et beaucoup d’entre nous n’aiment tout simplement pas ça et nous voulons au moins avoir la possibilité de décider ce que nous voulons utiliser.

2 « J'aime »
55

C’est le cœur de ma question, est-ce que :

  1. Ne me montrez pas le sélecteur markdown / riche
  2. Donnez-moi simplement l’ancien markdown
  3. Laissez la police comme serife, comme avant

Par exemple :

Préférence utilisateur pour le mode d’édition Markdown :

  1. Hérité : exactement comme ça fonctionnait autrefois. Même police, même tout. Pas de sélecteur RTE, pas de RTE.
  2. Texte enrichi préféré : par défaut, utilisez le texte enrichi pour chaque message que j’écris.
  3. Markdown préféré : par défaut, utilisez l’édition markdown.

J’aime cela pour plusieurs raisons.

  • Pour les nouveaux paramètres par défaut du forum, je pense qu’il est préférable d’avoir le code source dans une police source.
  • J’aime avoir un paramètre explicite pour « comment j’aime rédiger du markdown ».
  • Avec un paramètre explicite par rapport à implicite, cela me réinitialise lorsque je commence un message, ce que je préfère. Je n’aime pas la mémoire implicite.
3 « J'aime »
56

J’aurais une 3ème option : laisser Discourse le faire nativement. Nous avons toujours eu des polices sans-serif et je ne pense pas que ce soit un problème. Avoir plus de plugins à installer et à gérer, cela ne semble pas logique, je crois.

Mais parmi les 2, un plugin semble plus logique, sinon c’est la même chose : nous forçons tous les utilisateurs à utiliser une police, au lieu de pouvoir choisir, ce à quoi je suis opposé (maintenant que nous avons l’option de texte enrichi, bien sûr).

1 « J'aime »
57

L’administrateur de la communauté peut définir la police par défaut de markdown comme sans-serif ou monospace. Ensuite, chaque utilisateur choisit ce qu’il veut. Si l’administrateur le définit sur sans-serif, l’utilisateur verrait :

Utiliser la police monospace dans la vue markdown

Si l’administrateur le définit sur monospace, l’utilisateur verrait :

Utiliser la police sans-serif dans la vue markdown

Pas besoin de compliquer avec les mots « héritage » ou quoi que ce soit de sophistiqué. Rendez-le convivial, direct. Pensez comme l’utilisateur moyen, pas comme un développeur.

4 « J'aime »
58

Hein, nous avons complètement manqué ce remue-ménage sur le Discourse de notre langage de programmation car (je suppose ?) nous désactivons complètement l’éditeur de texte enrichi. Ce choix a probablement été fait en 2016, probablement lorsque l’éditeur de texte enrichi était bien plus médiocre qu’aujourd’hui. Et jamais réévalué. Ou peut-être que notre installation précède entièrement l’édition de texte enrichi et que nous ne l’avons jamais activée. Quoi qu’il en soit, nous avons toujours le comportement « hérité » avec la police serif dans l’éditeur markdown, et ce comportement me convient tout à fait.

En tant que personne qui écrit personnellement beaucoup de markdown et de code (dans des éditeurs monospacés et dans de nombreuses zones de texte HTML), j’ai des idées.

Je préfère de loin utiliser une police serif dans un éditeur non-RTE pour rédiger des publications sur Discourse. Je suis sûr qu’il y a une aversion au changement derrière cela, mais je pense qu’il y a aussi de bonnes raisons. La plupart des textes que j’écris sur Discourse et GitHub sont en fait du texte, pas du code. En fait, je n’appellerais pas le markdown du « code » du tout ! La seule fois où j’ai besoin d’une police monospacée dans cette fenêtre d’éditeur de texte (ou celle de GitHub) est à l’intérieur des délimiteurs ``` — car c’est du code. Ne confondez pas le markdown avec le code ; ce n’est pas du code. Et je n’aime pas les éditeurs de texte enrichi car ils se battent si souvent contre moi. Par exemple, ce paragraphe même obtient des comportements sauvagement bogués après avoir tergiversé pour écrire le markdown pour le délimiteur (c’est juste ```` ``` ````, mais maintenant je ne peux plus toucher la tilde sur mon clavier sans gâcher l’éditeur de texte enrichi).

Les polices serif dans un éditeur non-RTE correspondent également à GitHub — l’autre site avec une zone de texte HTML où j’écris beaucoup de markdown.

Je parierais que cela représente une grande partie de notre communauté de programmation en général. Les gens sur notre forum Discourse :

  • Écrivent du code source et utilisent des polices monospacées pour écrire du code source
  • Savent écrire et lire du markdown directement
  • Ne considèrent pas le texte markdown comme du code source
  • Préfèrent probablement utiliser des éditeurs non-RTE
  • Préfèrent probablement le taper/éditer comme de la prose — donc avec une police serif
7 « J'aime »
59

Ce n’est pas le cas. Il est plus probable que vous n’ayez pas mis à niveau vers une version qui inclut l’éditeur de texte enrichi.

3 « J'aime »
60

Peu importe, n’est-ce pas ? J’ai retiré l’aside de mon message original. L’important est que l’éditeur de texte enrichi sur notre instance est désactivé, et je suis heureux de le laisser désactivé tant que son activation (à mon avis) dégraderait l’éditeur markdown de cette manière.

image

1 « J'aime »
61

Je pense que la définition du texte atteint le fond du problème soulevé par @alltiagocom — je ne m’attendrais certainement pas à ce que cette case à cocher modifie le comportement du « mode Markdown actuel ». Je comprends le désir de limiter les préférences (et surtout celles des utilisateurs) — c’est un objectif très louable ! Mais il semble vraiment que ce soit une chose de style orthogonale qui est mieux gérée par les thèmes eux-mêmes.

2 « J'aime »
62

Dans mon CSS où ? Je ne suis pas administrateur, ce qui est justement mon propos. À moins que vous ne disiez qu’en tant qu’utilisateur régulier je peux remplacer le CSS d’une manière ou d’une autre (sans utiliser d’extension de navigateur).

Mais il y a littéralement un bouton qui indique le mode dans lequel vous êtes. Qu’avez-vous besoin de plus ? D’après votre capture d’écran, je suppose que ce n’est pas visible sur mobile, alors rendez-le visible et le problème est résolu.

Envisagez-vous de supprimer la version markdown à l’avenir ? Si oui, je comprends pourquoi vous voulez inciter les gens à utiliser cette vue. Mais je tiens à rappeler que les éditeurs WYSIWYG ne sont jamais parfaits et sont souvent incohérents. Un gros problème est que vous devez apprendre les particularités de l’éditeur WYSIWYG de chaque site/application spécifique. Teams, Confluence et Bitbucket utilisent tous des éditeurs WYSIWYG et ont tous leurs propres particularités auxquelles je dois m’adapter. Je n’en ai toujours pas pris l’habitude car ils vont à l’encontre de la façon dont fonctionnent les entrées/zones de texte HTML simples, et chaque particularité signifie plus de temps que je dois passer pour taper ce que je veux. Le Markdown, en revanche, fonctionne toujours et peut être écrit ou modifié manuellement, ce qui le rend moins sujet aux erreurs.

De plus, pour Discourse en particulier, votre logiciel a beaucoup plus de composants que les éditeurs simples n’en ont habituellement (sondages, citations de messages, détails cachés, spoilers, etc.) qui sont beaucoup plus compliqués. Je comprends que le fait d’avoir ces éléments visibles en ligne est un avantage pour les utilisateurs non techniques, mais c’est aussi plus d’endroits où l’éditeur WYSIWYG peut subtilement échouer de manière agaçante pour les utilisateurs expérimentés.

Je pense que Reddit a une fonctionnalité beaucoup moins complexe, ce qui signifie qu’il est moins nécessaire d’utiliser un éditeur markdown. J’ai remarqué récemment le bouton pour passer en mode markdown (et je l’ai immédiatement remis en arrière après avoir vu qu’il était en monospace), mais la différence est que sur Reddit, j’ai seulement besoin d’un comportement de base comme le gras et l’italique ou les liens, ce qui est tout à fait acceptable en mode WYSIWYG.

Je ne sais pas pourquoi vous continuez à utiliser le terme « code source ». Il semble que vous l’utilisiez pour dire que ce que nous écrivons est « de type code » et donc que le monospace a du sens. Mais ce n’est vraiment pas du tout comme du code. Le Markdown n’a absolument rien à voir avec l’écriture ou la lecture de code.

Bitbucket utilise une approche hybride où vous pouvez voir le markdown mais il montre également l’effet du markdown. Par exemple, vous verriez **texte**, mais les astérisques et « texte » seraient affichés en gras dans l’éditeur. Ils utilisent une police serif pour tout texte qui n’est pas dans un bloc de code, tandis que le texte dans un bloc de code est affiché en monospace. (Et oui, l’éditeur a des particularités qui me font souvent faire des erreurs lors de la modification d’un commentaire.) Je ne peux pas fournir de capture d’écran car je n’y ai accès que sur ma machine de travail.

Exactement ! Je n’ai jamais entendu un ingénieur logiciel dire « wow, j’aimerais vraiment que cet éditeur markdown utilise une police monospace ».

2 « J'aime »