Monospace lettertype in de alleen-Markdown-editor

Aankondigingen
43

Mijn doel is niet om me te richten op “laten we monospace toevoegen of verwijderen”. Verschillende mensen, verschillende smaken.
Ik ben van mening dat wanneer een bedrijf iets lange tijd aanbiedt, en ze willen het veranderen, dit niet verplicht zou moeten zijn, maar optioneel.

Jij geeft de voorkeur aan markdown met monospace. Goed.

Ik geef de voorkeur aan markdown zoals het altijd is geweest met sans-serif. Goed.

Maar nu word ik gedwongen om ofwel rich text te gebruiken, wat ik mezelf niet zie gebruiken, ofwel een nieuwe versie van markdown te gebruiken die ik nooit heb gebruikt en niet leuk vind.

Markdown met sans-serif of monospace zou als optie moeten worden aangeboden, in plaats van alle gebruikers te dwingen te wennen aan iets waarvan sommigen van ons al hebben laten zien dat het niet naar onze smaak is.

Het rechtvaardigen van die verandering als “het is een programmeeromgeving” slaat nergens op, omdat we niet in de composer aan het coderen zijn. We typen normale tekst en soms formatteren we die met markdown. Dat is geen programmeeromgeving.

Nogmaals, het debat voor mij is of monospace moet blijven of niet. Het gaat erom dat ik de optie heb om te kiezen wat ik leuk vind. En de CSS-workaround werkt alleen voor mijn community. Wat dacht je van al die andere communities die Discourse gebruiken waar ik nu gedwongen word tot de nieuwe verandering? Het slaat nergens op voor mij.

4 likes
44

Inderdaad, voor alle gebruikers van alle forums die de nieuwe composer nog niet hebben aangeboden, maar van plan zijn om standaard markdown te gebruiken, is de monospace een verandering. En ik denk dat dat niet geweldig is.

3 likes
45

Keep in mind, that this change allows users to quickly tell they are in source code mode vs rich mode

IMG_9777
IMG_97771179×2556 193 KB

My concern about reverting is that this optimises for users that never want to use the rich text editor and are averse to change, wouldn’t a “no rich text for me” option achieve the same goal?

3 likes
46

Only if they know that difference and what to do for that. Rich mode are out there for people who can’t do **bold**.

All what they see is a hard font.

And again — when an admin uses rich mode as default, that would happen only if that user clicks or touches wrong place, and can’t understand what the heck just happened.

And second again — monospace is difficult for eyes :man_shrugging:

But we have all this

IMG_2455
IMG_24552360×920 141 KB

I don’t know if

Enable monospace in source code mode (really… calling it in that way reveals something :smirking_face:)

would be that awful thing (if it would be resonable easy to build).

3 likes
47

… and they can easily click a button to make it go away :slight_smile: so they are encouraged to use the “easy” font, that looks great. 99.9% of users out there should just opt for that for casual authoring.

I get people are pushing for a user preference here, we are discussing this internally as well. It is tricky, usually we only add preferences as a last resort, maybe this is one of those cases.

Also… I do not see our behavior as an outlier:

Reddit, number #6 site on the internet does the exact same thing:

image
image1205×601 122 KB

image
image777×696 37.7 KB

It does not provide an option to override this…

5 likes
48

How about a plugin?

Then admins have to actively invest work towards this feature and usage numbers would show, if this option is really needed.

1 like
49

Ik ben benieuwd - wat zou meer aanspreken bij beheerders?

  • Thema Component - lettertype wereldwijd wijzigen voor alle gebruikers
  • Plugin - instelling per gebruiker voor letterwijziging
0 voters
50

Aangezien de route van het themaonderdeel zo open is, begrijp ik niet waarom je een stemming ervoor zou zien als een stemming tegen een plugin.

1 like
51

So the options are when a font is an issue, then

  • do not use markdown, or
  • use that difficult font

So…

I think it is needed when a forum blends dev-stuff and more common discussion. If a hard core dev want to use typewriter every where I get it, but I don’t understand why I am forced to use same.

But this is somewhat strange situation: we are writing using one font, that doesn’t give any benefits, but is acting as a marker what kind composer a user is using, and after that we are reading and the font is totally different.

You know very well that out there is opposite examples way more. And I’m not sure why Reddit would be a good example. If it is then we should adapt Facebook way too.

2 likes
52

Facebook has no dual mode. I can’t think of too many other pieces out there that have dual mode, can you provide some examples?

CKEditor also does the same as us:

image
image1177×1330 193 KB

Source code in monospace is a very well established pattern.

… have markdown that is EASIER to edit

Eg:

```
one
   two
      three
```

:up_arrow: an excercise in futility in non monospace.

Cause you see

image
image260×148 1.47 KB

3 likes
53

That isn’t important. The point is if you use Reddit as an example for useful UX, because it is big, then you should use same logic with Facebook.

Reddit isn’t actually that popular outside US and native english speaking world.

If I understand right, for you hard-to-read monospace font is an indicator for markdown editor? Isn’t that a bit harsh way? Those of my users, and I, who are using markdown, know which editor is in use no matter the font is same.

Again — CSS is the savior. But not here. In Meta I have two and only two options:

  • suffer 100 years old typewriter font, because few sites is using it
  • not to use markdown editor

So… :man_shrugging: Perhaps that setting is needed, because you don’t force me to use smart lists either.

(Off topic, I know — but ordinary consumer level users need only one-button-toolbar: for image upload)

54

Some users like myself will probably never use rich text, so this isn’t really a feature that makes a difference. If my default is markdown, that’s all I need to “know”.

Sure, there are the other users who probably have no clue what markdown is and rich text is useful. I get it, as all the users who are “against” the change. We are not dismissing those users. We are asking for an option, not a mandate.

From the comments I’ve read, absolutely no one is averse to change. You are using that as a justification for the decision the team made. I’m not averse to change, and I would say that other users are on the same boat. We are asking that there’s a preference for those who do not want markdown + monospace together.

This is the same thing. You are having a hard time understanding that “no rich text” and “no rich text WITH sans-sarif” are two different things, considering that “no rich text” now is = monospace, which is a bad font.

Isn’t it also “tricky” that suddenly you force thousands of users who have been using forums for years, using Discourse, to now have to get used to something that has been proven not to be ideal for reading?

For example, Facebook, X/Twitter, YouTube allow clickable links in posts. Instagram and TikTok don’t.
Each company is a company. Just because Reddit or CKEditor work a certain way, doesn’t mean that you have to copy them. You have to do what makes sense to your product. And again, no one is asking you to remove the rich text or monospace. We are asking that this is an option. Some people like light themes, some people like dark. Some people like to have a pure black background with neon text while they code, some people like muted colors. Each person is different.
It doesn’t have to make sense to you, it has to make sense to the user.

I don’t want to come across as rude or anything. I appreciate Discourse as a platform, especially being free for self-hosting options. I’m just finding it hard to accept that a team of people, including developers, etc, is having a hard time accepting that having a user preference is the route to go, after almost 4 months after asking us to “let it breathe”. I let it breathe and a lot of us just don’t like it and we want to at least have the option to decide what we want to use.

2 likes
55

This is the heart of my question, would a

  1. Don’t show me the markdown / rich selector
  2. Just give me good old markdown
  3. Leave the font as serif like it was before

Eg:

Markdown authoring mode user pref:

  1. legacy: just like it used to work in the old days. same font same everything.no RTE selector, no RTE
  2. rich text preferred: default me to rich text for every post I write
  3. markdown preferred: default me to markdown editing

I like this for quite a few reasons.

  • For new forum defaults I think having source code in a source font is better.
  • I like having an explicit setting for “how I like to author markdown”
  • With an explicit vs implicit setting, it resets me when I start a post, something I prefer. I don’t like the implicit memory.
3 likes
56

Ik zou een derde optie hebben: laat Discourse dit native doen. We hadden altijd al schreefloos en ik denk niet dat dat een probleem was. Meer plugins om te installeren en te beheren, lijkt me geen logische stap, geloof ik.

Maar van de twee lijkt een plugin logischer, anders is het hetzelfde: we dwingen alle gebruikers om één lettertype te gebruiken, in plaats van de mogelijkheid te hebben om te kiezen, waar ik tegen ben (nu we de rich text-optie hebben, natuurlijk).

1 like
57

De beheerder van de community kan de standaard markdown instellen op sans-serif of monospace. Vervolgens kiest elke gebruiker wat hij wil. Als de beheerder dit instelt op sans-serif, ziet de gebruiker:

Gebruik monospace lettertype in markdown weergave

Als de beheerder dit instelt op monospace, ziet de gebruiker:

Gebruik sans-serif lettertype in markdown weergave

Maak het niet ingewikkeld met woorden als “legacy” of iets dergelijks. Maak het gebruiksvriendelijk en to-the-point. Denk als een gemiddelde gebruiker, niet als een ontwikkelaar.

4 likes
58

Huh, we hebben dit gedoe in onze programmeertaalgemeenschap Discourse volledig gemist omdat we de rich text editor niet hebben ingeschakeld. We zien nog steeds het “legacy” gedrag met het schreeflettertype in de markdown-editor, en ik ben daar erg blij mee.

Als iemand die persoonlijk veel markdown en code schrijft (in monospaced editors en in veel HTML-tekstvakken), heb ik mijn gedachten.

Ik geef er de voorkeur aan om een schreeflettertype te gebruiken in een niet-RTE om discourse-posts te schrijven. Ik weet zeker dat er enige weerstand tegen verandering achter zit, maar ik denk dat er ook goede redenen zijn. Het meeste tekst dat ik op Discourse en GitHub schrijf, is eigenlijk tekst, geen code. Sterker nog, ik zou markdown helemaal geen “code” willen noemen! Het enige moment dat ik een monospaced lettertype wil in dit teksteditorvenster (of dat van GitHub) is binnen hekken - want dat is code. Verwar markdown niet met code; het is geen code. En ik heb een hekel aan rich text editors omdat ze zo vaak tegen me vechten. Dit huidige paragraaf krijgt bijvoorbeeld wild buggy gedrag na wat gestuntel om de markdown voor het hek te schrijven (het is gewoon ```` ``` ````, maar nu kan ik de tilde op mijn toetsenbord niet meer aanraken zonder de RTE te verpesten).

Schreeflettertypen in een niet-RTE komen ook overeen met GitHub - de andere site met een HTML-tekstvak waar ik veel markdown schrijf.

Ik durf te wedden dat dit representatief is voor een groot deel van onze programmeergemeenschap. De mensen op ons discourse-bord:

  • Schrijven broncode en gebruiken monospaced lettertypen om broncode te schrijven
  • Weten hoe ze markdown direct moeten schrijven en lezen
  • Beschouwen markdown-tekst niet als broncode
  • Geven waarschijnlijk de voorkeur aan het gebruik van niet-RTE’s
  • Geven waarschijnlijk de voorkeur aan het typen/bewerken als proza - dus met een schreeflettertype

Natuurlijk is dit een zeer gespecialiseerde gemeenschap en is deze op geen enkele manier representatief. Maar mijn belangrijkste punt is: doe dit niet voor “programmeurs” omdat “zij monospace willen om te coderen”.

7 likes
Escaped tildes in the new rich text editor are buggy
59

That’s not the case. It’s more likely that you haven’t upgraded to a version that includes the rich text editor.

3 likes
60

It doesn’t really matter, does it? I’ve removed the aside from my original post. The point is, the rich text editor on our instance is off, and I’m happy to keep it off as long as turning it on would (IMO) degrade the markdown editor in this way.

image

1 like
61

Ik denk dat het instellen van tekst de kern raakt van het punt van @alltiagocom — ik zou zeker niet verwachten dat dat selectievakje het gedrag van “de huidige Markdown-modus” zou veranderen. Ik begrijp het verlangen om voorkeuren (en vooral gebruikersvoorkeuren) te beperken — het is een zeer lovenswaardig doel! Maar het voelt echt alsof dit een orthogonale site-stijl/look-and-feel ding is dat het beste kan worden afgehandeld door Thema’s.

2 likes
62

In my CSS where? I’m not an admin, which is pretty much my point. Unless you’re saying as a regular user I can override the CSS somehow (without using a browser extension).

But there’s literally a toggle showing what mode you’re in. What more do you need? From your screenshot I guess it’s not visible on mobile, so make it visible and that problem is solved.

Are you planning to remove the markdown version in the future? If so, I understand why you want to nudge people towards that view. But I want to mention again that WYSIWYG editors are never perfect and are often inconsistent. A big problem is that you have to learn the quirks of the WYSIWYG editor on every specific website/application. Teams and Confluence and Bitbucket all use WYSIWYG and all have their own quirks that I have to learn and adjust to. Some I still haven’t gotten used to because they are so counter to how plain HTML inputs/textareas work, and every quirk means more time I have to spend to type what I want. Markdown on the other hand always works and can be written or edited manually, which makes it less error prone.

Also, for Discourse in particular, your software has many more components than simple editors usually have (polls, post quotes, hidden details, spoilers, etc.) that are far more complicated. I get that having those visible in line is a benefit to non-technical users, but it’s also more places that the WYSIWYG editor can subtly break in ways that are annoying to power users.

I think Reddit has far less complex functionality, which means it’s less necessary to use a markdown editor. I only noticed the toggle to switch to markdown mode recently (and immediately switched it back after seeing it was monospace), but the difference is that on Reddit I only need basic behavior like bold and italics or links, which is perfectly fine in WYSIWYG mode.

I don’t know why you keep using the term “source code”. It seems like you’re using it to say what we’re writing is “code-like” and therefore monospace makes sense. But it’s really not code-like at all. Markdown is absolutely nothing like writing or reading code.

Bitbucket uses a hybrid approach where you can see the markdown but it also shows the effect of the markdown. For example, you’d see **text**, but the asterisks and “text” would be displayed bold in the editor. They use a serif font for all text that’s not in a code block, while text within a code block is shown in monospace. (And yes, the editor has quirks that frequently make me mess up when editing a comment.) I can’t provide a screenshot since I only have access on my work machine.

Exactly! I have never heard a software engineer say “wow I really wish this markdown editor used a monospace font”.

2 likes