I am now very firm in my opinion that the continued lack of WYSIWYG will hold back Discourse from being a truly mainstream product. It doesn’t have to change now, but it has to be in the roadmap. I love this software, but the UX for actually creating content makes me sad. It’s already outclassed by other web apps, eg:
OK, so I asked my dad about this (he is an Anesthesiologist), and he asked around the hospital where he works. The general consensus he got is as follows (note, I am paraphrasing him, I did not get quotes):
There are always going to be some people who are resistant to change and anything that is “different”. I saw this a few years ago when we implemented our EMR (Electronic Medical Record) system. Many Docs (and nurses) who had been here for years wanted nothing to do with it. The hospital rolled it out carefully, and listened closely to feedback. While it was “seamless”, it was pretty “smooth”. Now, I can laugh at those same Docs who forget how to do paperwork if the EMR goes down.
I think that most Docs will be able to figure it out. A lot of what Docs do is find patterns and relate them to previous experiences, or make other connections. I think most Docs would be able to learn without too much difficulty the connection between some random-looking text and a picture.
Patients on the other hand, particularly elderly patients, or those who do not have full mental capabilities due to medications they are taking may not learn so easily. That being said, elderly patients did not grow up with any type of technology like this, and many will not have used it at all. We still see many patients come in with a basic flip phone, and they don’t have a computer at home. Some don’t even understand what the internet is. I think you will find this is an issue regardless of what program you use, whether it has random lines of text, or is simply drag-and-drop.
Edit: The above quote is the opinion from my dad and staff he works with in the hospital, specifically related to a system for use with Doctors and Patients. My own opinion of this is different, and while I personally have no issue with Markdown, I would not object to a WYSIWYG editor as a user configurable option, even if defaulted to WYSIWYG. That being said, Discourse is forum software for discussions, while certain things in markup might be unclear to non-technical users, like images, I don’t want to see the forum fill up with colorful, multi-sized text, and all sorts of other crazy formatting.
I have a reasonably technical group on my forum, but not really devs as such (more science types). They adapted to markdown extremely fast, and I’ve gotten lots of positive feedback on it.
Most prefer it over Wordpress’s “Nearly WYSIWYG (but not really)” for example.
I love markdown myself. Especially since I often flip between markdown and html in a given post. The little toolbar on the default editor covered everything even my less-technical users required.
I’m not suggesting that at all. I think that the only styles that should be allowed are ones that have clear semantic meaning - boldface, block quotes, bullet points, etc.
OK, that makes me feel a lot better. So if I am understanding correctly now, you essentially want to be able to type into what is currently the preview pane, and have it look exactly as it will when posted. You want Discourse to handle all the markdown in the background, without displaying it to the user?
I agree with this completely, and moreover, I think that making editing more accessible fits in with Discourse’s mission statement: “civilized discussion”. There’s a crying need for more polite, thoughtful, deliberative conversation in the world, especially in the fields of politics and science where its important that the average citizen be informed. I think it would be contrary to that mission to exclude parts of the potential audience.
And the ability to add style and class attributes. For example allowing an image to float right with text to the left would make a significant difference to the appearance of the post and would help those wanting to make some posts look more article (read blog) like in appearance.
Edit - ok, maybe not styles, else we’d get back to the themepark appearance that might result. But certainly the ability to add classes to images and text blocks to deliver the inline-block (or float left/right) appearance that I referred to above.
No, it is not a goal, and it is not on our roadmap for the forseeable future.
Your opinion is fascinating, but according to our growth metrics, it isn’t.
If “true” WYSIWYG is a deal breaker for anyone reading this, I suggest you look elsewhere and save yourself a lot of angst.
Meanwhile, people will continue to type words and sentences like these and they will continue to look remarkably the same in both the editor and the live preview.
Notwithstanding that, allowing folks to style their content a little more than is currently possible, for example using floats, inline blocks and perhaps classes to achieve same, would be very useful. And wouldn’t that be a whitelisting issue, or am I simplifying things too much?
You got to have some perspective on the enormity of the problem.
A forum that has been, from day zero, WYSIWYG is probably reasonably straight forward to build and would only take 2-12 weeks of development as a plugin, there are real challenges around quoting, but quite a few options to shop from and you can strip out lots of features.
However, a WYSIWYG editor that co-exists with our Markdown hybrid editor is an impractical project to embark on. Going back and forth from Markdown to WYSIWYG is just too big of a project, and would always cause annoying reformatting of Markdown.
As it stands we have huge amounts of debt with our editor we got to repay, multiple weeks of engineering are required to move us to CommonMark, this is where we are going to invest our efforts. It would spread us way too thin to be also building a “WYSIWYG” option.
I much prefer investing effort in refining our current solution than jumping ship. There are tons of refinements left: “synchronizing” preview, to interacting and resizing images in preview.
Indeed, ProseMirror by @marijn seems by far the best option if anyone ever wants to take a stab at a WYSIWYG plugin. It’s based on the markdown-it library that we’ll soon be depending on as well for CommonMark conformance.
Never lost sight of it. I guess my position is more philosophical than practical - the choice for user-facing markup has been made (with good reasons) and change would be very hard. I just think it’ll feel very weird to be typing markup in 2025.
My popular non-tech sports fan forum audience migrated from SMF (Wysiwyg-ish) to Discourse (Markdown) with zero complaints. Just couple of questions on how to create polls, which were easily resolved. Forum is thriving - we did not migrate any data or user accounts, and we are already more popular than ever.
Summary: Current Markdown solution is fine, even for non-techies.
I spend a decent amount of time over at https://discuss.elastic.co/, a developer focussed discourse. It makes it easier for me when discourse behaves just like github and I suspect this is true for lots of folks over there.
I, a programmer, easily master Markdown.
But it’s a nightmare for our users… almost all of them.
Mods had to learn some Markdown basics to get well formatted posts at least in their own messages. The rest just write normal text with no paragraphs, no headings. Very few use “bold” and “italic”, nothing more.
I’m not sure what is the benefit of using Markdown from a non-tech-user point of view. Why should one see two texts instead of one - why not a final version only, which they are editing right in place?
Non-tech people are used to Word, Google Docs and GMail. I suppose Markdown makes the implementation of the composer easier, but not its usage. So if you ask me, I’m against Markdown as a primary editing means.
)