I don’t understand the outright need for a WYSIWYG editor. The preview pane is on my right and I can easily futz and go pedantic-crazy on my markdown formatting just the way I like it.
I have said elsewhere that Markdown adoption boils down to two things: association with the IT crowd and the tenacity against change. AKA, “if it ain’t broke don’t fix it” and other cop-outs to say when something does the job but it could be a little bit more (or a lot more) efficient, lightweight, less work to maintain and generally easier in the long run to maintain.
The Medium style is a good option. I prefer how [Stackedit][1] does it:
Stackedit has the same Markdown buttons as Discourse, but the editing field offers some slight styling so a user knows the Markdown syntax is correct. For bold and italics it shows both outright while maintaining the raw Markdown that caused it.
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 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?
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…
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.
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.
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.
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.
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.
