I’m still undecided whether I find monospace necessary or not, but the updated font is a clear improvement over the previous one (in contrast the previous situation, I tend to say, now it could be slightly larger again).
But in any case, it’s nice that the good old ASCII art can make a return now
|-----------|
| LONG LIVE |
| THE BUNNY |
|-----------|
(\__/) ||
(•ㅅ•) ||
/ づ
I mentioned this earlier in the topic, we need the change to breath for a bit longer, lets give it at least another week.
The answer here is absolutely maybe. Keep the feedback coming, good or bad, we are reading it all.
One issue I am battling with internally is the targeting of different “personas”/“audiences”
General public → just use “rich composer” 99% of the time, none of this is an issue
Highly technical users → just use “raw markdown” - generally used to this type of view and many happy with the change
Non technical BUT do not want to use rich editor → monospace irks them - eg: @Jagster - prefer a different font
It is a tricky problem, we are always reticent to add more user settings, but I do acknowledge that there is something here, I just want to see how we feel in a week.
I was trying to figure out different non-intrusive visual cues, but it’s tough.
The only one that seems acceptable is a label somewhere, like:
And maybe with a color change to help better the visual memory:
It’s pretty visible without being intrusive. It has its share of cons, for sure. It takes some space, but it’s okay in the context of a temporary transition. I’m not 100% convinced, but it seems like an interesting alternative. I just wanted to share the idea. (feel free to open the gifs in a new tab to see in full size; it misses a fullscreen button)
this for some reason is one of the best arguments against I’ve heard so far. I just had to go check the font in my VS code editor, so see, I am a coder. I had a code editor open on my desktop, and sure enough, it is a mono-space font. I never even noticed. But for some reason, it just feels weird here and my own instance. I’ll give it a week, like Sam is asking, change is jarring, maybe in a week I won’t even notice.
I agree. I just wrote a really long post, and honestly the monospace font is giving me a headache. I proofread my posts very thoroughly, and I tend to go back and forth between reading the raw markdown and reading the formatted post while doing so. Now it’s very difficult to do so in the editor section.
I also generally don’t like WYSIWYG. In my experience they are very janky, and I have no intention of using it. So for me, the markdown editor that has existed forever needs to continue to be a smooth user experience.
I agree with @schneeland. I’m a software engineer and regularly use IDEs that of course use monospace font, but this is simply a different context. It would indeed be very jarring if Jira started using a monospace font.
I’m not sure I’ve ever had a problem working with tables in markdown. And besides, even in monospace the vertical bars between each column won’t align since each cell is likely to have a different number of characters in it.
In any case, I know you want to let the change breathe a bit, but hopefully this feedback helps. Note that my comments are based on the most recent monospace font and I didn’t see the previous version. So I’m only comparing my experience to the one that has existed for years, not to the first monospace font used a couple days ago.
How many people will actually use tables on a forum reply that justifies this? Also, Obsidian uses markdown and uses tables with monospace inside, while the text outside it sans-serif:
I don’t see why the whole composer has to change to monospace when they could co-exist?
I would say 99% of what we write is “normal” text, not markdown.
My honest opinion is that this is not a great feature to be “forced” on users, even if we let it breathe. It’s not a change that users are relieved to have, and that’s visible in most comments. It should be a user preference.
I don’t really see any issue with the composer having the same typeface as the preview. It’s pretty easy to understand what’s happening. It’s been for many years, right? “If it’s not broken, don’t fix it”, they say. And it applies here, I believe.
Ik vond het monospace-lettertype niet fijn (het is goed voor coderen, maar niet om op een forum te typen), dus heb ik het terug veranderd door dit CSS aan mijn thema toe te voegen (laat het me weten als er een betere manier is om dit te doen alstublieft!)
Ik vind echt dat dit een gebruikersinstelling zou moeten zijn. Ik zou niet gedwongen moeten worden om de wysiwyg-weergave te gebruiken om een leesbaar lettertype te gebruiken. Monospace-lettertypen zijn voor mij in feite onleesbaar voor normale (niet-code) tekst. Dit is vooral storend op mobiel, waar je niet tegelijkertijd een voorbeeld naast elkaar kunt zien, maar het is nog steeds niet geweldig op desktop. Ik denk niet dat een site-instelling of CSS-override voldoende is, aangezien niet alle sitebeheerders reageren op gebruikersfeedback voor dit soort dingen.
Absolutely (and I agree strongly enough to have created an account for the purposes of posting agreement!)
Markdown automatically word-wraps lines and has other properties that blurs the line between “word processing” and “code”. On a discussion forum, it’s certainly much more a word processor…and I’ve been quite happy with the historical behavior. I’ve appreciated being able to freely copy and paste without ambiguity. I like being able to hit enter and get a newline, instead of some WYSIWYG imagination of what I might have meant.
Markdown editing does not become more functional or enjoyable by using a fixed-width font. It gets worse…and I’d think anyone who actually uses it would agree.
So Markdown is being made a second-class citizen, for the purpose of strengthening the visual cue of which mode you’re in.
I’d ask the UX designers among you if there’s a better way to emphasize the mode… that doesn’t ask you to make the nearly-never-good tradeoff of using a fixed width font to edit what is mostly non-code text.
If a good answer to that were found, there’d be no need for an option to toggle fixed-width vs. non, because it would always be a proportional font.
Er is veel tijd verstreken sinds ons werd verteld “let it breathe”. Zoals we kunnen zien, is deze verandering niet iets waar we allemaal “geweldige verandering!” tegen zeiden.
Zoals iemand anders zei, was er een enorme vraag naar dit? Ik weet het niet… Ik betwijfel het, maar misschien heb ik het mis.
Ik denk dat het bekijken van markdown als een “codeer” taal om de monospace te rechtvaardigen, voor mij niet veel zin heeft. Ik zie markdown als een manier om tekst op te maken, niet noodzakelijk als een “codeer” taal. Ik hoef geen ontwikkelaar te zijn om markdown te gebruiken, in tegenstelling tot bijvoorbeeld VS Code, Cursor, etc., waar monospace passend is.
Wanneer we nieuwe onderwerpen of antwoorden maken op een forum, zijn we niet aan het “coderen”, we zijn aan het “teksten” en tekst moet leesbaar zijn. Monospace is gewoon niet zo leesbaar. Ik kan een paragraaf van 150 woorden typen in een markdown-editor zonder ooit enige markdown “syntax” te gebruiken (als dat zo heet?). Dus ik zie markdown als een extra ding dat we kunnen gebruiken om tekst op te maken, niet noodzakelijk een “formaat” waar alles op moet zitten, als dat logisch is?
Voeg dit toe aan je CSS @seanblue & @alltiagocom. Het zal de composer terugzetten naar de standaard van je site.
/* Wijzigt het lettertype in de composer van monospace terug naar de standaard sans-serif */
.d-editor-container .d-editor-textarea-wrapper textarea.d-editor-input {
font-family: var(--font-family);
font-size: 1rem; /* of gebruik 16px, of je specifieke standaardgrootte */
}
Ik geloof in het geven van voorkeur aan gebruikers. Misschien willen sommige gebruikers monospace. Ik weet het niet. Ik heb een aantal waanzinnige VS Code-thema’s gezien (groene achtergrond met zwarte tekst, of erger), en ik zou die nooit gebruiken, maar ieder mens is anders.
Ik verander de mijne zeker naar sans-serif, maar mijn punt hier is dat we de opties aan onze gebruikers zouden kunnen aanbieden. Dat is alles. Sommige gebruikers willen markdown met monopace, sommigen met sans-serif. Sommige gebruikers geven niets om markdown en willen alleen rich text. Het hebben van die opties native zou naar mijn mening een betere optie zijn.
I’m biased as a Discourse employee, but I much much prefer the new monospace font. So there’s a good chance that the people that go “ah yeah, nice” or even “huh, never noticed” don’t speak up.
(But among ordinary people monospace isn’t counted as a readable font. For me and my users the CSS-trick did the job, so for me as an admin this is more an academic question. But let’s stop to say this change is done for majority and is widely in use, because that isn’t true.)
Ik ben het ermee eens - de monospace is onverwacht en lelijk. Ook onnodig. Er is al een schuifregelaar in de werkbalk die ons vertelt in welke modus we ons bevinden.
Well, I didn’t, because everything wasn’t about or by you.
Anyway. Keeping two options as a composer was a wonderful solution. Monospace not that much, but as long as the CSS change works, I’m happy. But I understand the point of having a user setting for that — but I don’t like it, because there is already quite a bit to set up. But I’m not so sure how many ordinary users ever even change settings… and then it doesn’t matter how crowded it is