Who would prefer a standard wysiwyg to markdown?

I think that’s a clever way to do things, but it seems a little redundant with the preview pane being present.

I agree with this.

Running communities on and off for several years I’ve come to see how much of a headache it can be… Most people stick to bold, italic, links, videos, images etc. That’s all you really need to convey yourself appropriately in a conversation.

Then there’s the people who want everything they write to be in 18px bright green Comic Sans for no other reason than because the option is there.


I fully agree with you 100%. That’s why I am still unsure the need for WYSIWYG. But my idea/inspiration is a compromise.

1 Like

For mobile, I think the pseudo WYSIWYG will make the post writing experience easier and enjoyable; regardless of this current topic.

1 Like

I love how it works on Medium and I think it would be also good for forums like Discourse. I love markdown (I’m a programmer), but my users find it confusing.

How is your current status here? Do you plan on implementing it, or are you happy with the rewritten markdown editor?

Possibly useful open source projects:


One more, and this seems to be pretty nice:


It is a WYSIWYG editor that generates Markdown under the hood. Could be a good starting point for a new Discourse’s editor.

Edit: I’m a bit lost in all the discussions about the editor (aka composer) and I don’t know in which topic should I post. There’s this and this and this


having the choice would be great.

Personally, I started to like marktdown, but at the same time several times got the impression, that it holds non-technical people away. We are a socio-technical project. For a substantial part of the non-technical people, it seems too complex and painful to learn.

There is so much beauty in discourse, and I see it a pitty, that the sole choice of the markdown editor is limiting the possibilities to integrate people. We noticed that especially with female non-technical contributors above 40 years of age.

Markdown isn’t the sole choice; BBCode and HTML also work.

There is also this, to teach people, with a quick reference and an easy “anyone can do it” 10 minute tutorial:


Spread the link far and wide!


Thank you @codinghorror

Of course, we will use the ressource, you provided and spread it, still, it is far from a solution to the challenge, I understand the coder´s mind, that it is sooo simple, and hey, it also supports BBCode and HTML, but for non-coders, that simply want to contribute to the topic of the respective forum, that information is of little help.

People don´t want to be educated, they simply want stuff to work : )

That is also, why WYSIWYG is so successful. Personally, I would not like to go back, but I also know, that many of our (possible) contributors would like to have an option.


Did you do some user testing? Or how did you arrive at this? It doesn’t really reflect our experience and we have many members who are non technical women and men of all ages. Also in many countries and using many devices, some with limited Internet access.

The editor is not hard to use to participate in discussions and is not excluding anybody.

It’s true that at the beginning decision makers in our organization complained and pushed back. But once they realized they can participate by email and that the editor is easy for basic posting those complaints have stopped.

We may not be excluding folks but we are offering something different from what many are being exposed to on mainstream systems such as Google Docs, O365 and most web mail editors. Not to mention the desktop experience.

And even if we all agreed Markdown was superior to WYSIWYG editors, and it’s widespread adoption became inevitable, in the meantime we are forcing a subset of potential adopters to undertake some cold turkey. This for many may well be a barrier to entry - and who here can hold their hand up and claim to be replete with community members?

Maybe for some communities the instructions in the editor could be simplified. Instead of saying ‘Type here. Use Markdown, BBCode, or HTML to format. Drag or paste images.’ It could say something like ‘Type here. Add a space between lines to create a new paragraph.’

A prominent, dismissible link to the markdown tutorial could be added to the editor, or added to the header when the editor is visible.

1 Like

Alternatively/Additionally, the tutorial link could be included in the new user PM. Over on my site we added the link in our Meta section under the title “Want to learn Markdown (how to format your posts)?”. If someone cares enough about formatting their posts, and understands the basics of how Discourse is organized, it is about as easy to find as it can be.


Oh that’s a good idea. Let me add that… ok added under Reply section:

Your reply can be formatted using simple HTML, BBCode, or Markdown:

This is **bold**.
This is <b>bold</b>.
This is [b]bold[/b].

Want to learn Markdown? Take our fun 10 minute interactive tutorial!


I think that the weakness of Markdown becomes most apparent when you start adding images to a post.

I agree that for most non-technical users, plain text gets most of what they need. The other style options are important for the more literate users (I’m fond of block quotes and bullet points) but most users aren’t going to be using them.

(I’m also strongly in favor of limiting styles to only ones that are semantically meaningful - section headings yes, arbitrary font changes no. So a WYSIWYG editor doesn’t need any more buttons than you already have. Most of the open-source embeddable WYSIWYG editors allow you to customize the toolbar and the set of HTML element types that are allowed, so you can ensure that users won’t go crazy with styles.)

However the one non-plain-text thing that “normal” users do a lot is embedding images. This, I think, is where Markdown becomes particularly confusing, especially when the ‘src’ attribute of the ‘img’ tag looks like a lot of garbage text to someone who doesn’t know about filename hashes.

BTW I’ve done some experiments with TinyMCE in my own coding and found it to be perfectly usable for a use case like Discourse. The widget can be attached to any textarea element and replaces it with an iframe with the editor inside. (I’m not saying you should adopt TinyMCE, I’m merely saying that it’s an example of what can be done.)

As I mentioned in the other thread, our main user base is going to be doctors and cancer patients, many of the latter group being elderly and not particularly computer-literate. Forcing them to learn Markdown is pretty much a deal-breaker for us.

1 Like

Have you played much with inserting images? Discourse does it pretty well, I don’t think I’ve ever had to actually type out img tags.

Dragging and dropping images in (with automatic upload) as well as automatically parsing image URLs takes care of your day-to-day image insertion more than well enough, in my experience.


I’m not talking about having to type them out. I’m referring to the fact that what you see in the preview window looks very different than what you see in the editing window. A lot of people are going to wonder why there’s this long string of characters in the middle of where they are typing. The association between the img tag and the image in the preview window may seem trivial to you, but that’s because (I assume) you are an abstract thinker.

Oh okay, I see what you’re getting at now, sorry for the misunderstanding.

I don’t know, it’s awkward to comment further here, I’m certain you understand the community you’re working with better than I do, and the discourse team is much better positioned to comment on whether reaching that sort of community is worth the coding pain.

I am curious though, why do you suppose that making the connection between img tag code and the image appearing on the right is going to be such an issue? A user doesn’t actually need to learn any Markdown to make the connection, just note that it happens consistently when they insert some image and results in an image appearing.

I know I’m just stumbling around your point about it only seeming trivial to me, but I don’t understand how your users will really make use of Discourse if this presents such a stumbling block. The intuitiveness and polish in Discourse’s image handling was one of the biggest positives for my community, it’s difficult seeing it from the other direction.

1 Like

Here’s an example of a text editor where you can read the markup language that transforms the text’s appearance. It’s over 20 years old.

There’s a very good reason why no modern word processor looks like this.

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:


Click the link and get options. Click the image and get options. It’s not even a contest IMO.

(I see it’s 6 months since my last rant on the topic. I’ll be back in the summer :stuck_out_tongue:)


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.