Who would prefer a standard wysiwyg to markdown?

[Nikolas_Everett]

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.

[meglio (Anton)]

My 2 cents:

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.

[meglio (Anton)]

For Wysiwyg you have to put a keypad full of buttons somewhere,
No, I like it as it is.

In wysiwyg mode, what other buttons would you add besides the ones that exist already?

[purldator (mountain)]

In defense of markdown and the end users not “jiving” with it, I can say from experience that a little hands-on instruction does work.

I taught an end user how to use markdown. Did it in a real-time discussion via Mattermost.

She tripped up first; I could feel the frustration.

Then, I went a different approach.

This is some bold and here are some italics.

Then I typed:

**This is some bold** and _here are some italics_.

She got it immediately. And even when showing her how to do links, then later on images, she got those too.

A similar approach was taken with another, same type of end user–no IT experience or background whatsoever–who only needed an example as I posted.

The real-time aspects, I surmise, helped too. That is what wysiwyg provides in my stead.

I am all for markdown. I am also all for a compromise regarding wysiwyg too.

Who would prefer a standard wysiwyg to markdown?

You too? Yeah, I know those feels. 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…

(Incidentally, it was Stackedit’s type of markdown-flavored wysiwyg I used to easily teach the second end user regarded above.)

[Talin]

Well, I think that the real cognitive hurdle is that Markdown involves a level of abstraction - that is, the text that you are typing is not what will be presented, but rather something that will be transformed into what is presented. I’m less concerned about teaching the specifics of the syntax.

There’s a classic work on UI design Tog On Interface that talks about different personality types and their approaches to using software. In the Jungian / Myers-Briggs model, 1/4 of people are “intuitives” who enjoy thinking about complex mental models, and the other 3/4 are “sensables” who live more in the world of the senses (I’m oversimplifying this a lot). Intuitives prefer powerful user interfaces that require memorizing functions that they can invoke (think command line), whereas sensables prefer everything “up front and in your face” (think of a print preview dialog.) Note that most programmers are intuitives.

What I’d like to see is some anecdotes involving people over 60 learning to use the system - without being coached by an expert.

[simon (Simon Cossar)]

our main user base is going to be doctors and cancer patients, many of the latter group being elderly and not particularly computer-literate

I can see your point in trying to make adding content to a forum as easy as possible. Eventually there will probably be plugins that offer different ways of doing this for Discourse. For a user who has little experience with computers, any editor, even a WYSIWYG one, that allows them to create formatted content with headings and images might seem very complex.

I wonder if a possible approach for starting a community for non-technical users could be to train a few members of the community in how to use the software. They could then contact new members of the community who seem to not be engaging with the forum and practice using the software with them in private messages. For working with elderly users it could be helpful to contact them first in person, or over the telephone. As users learn to use for forum they could be moved into the ‘teacher’ group and get the chance to reinforce their learning by teaching others.

[meglio (Anton)]

@purldator

She got it immediately. And even when showing her how to do links, then later on images, she got those too.

The question remains: why should we introduce some difficulty and then teach users to overcome it? Why not just click the “strong” button and see the text strong in place. Why need for two versions of text? What is the benefit from user’s point of view.

Any markup can be used internally, but why should users deal with it at all? What’s the win for them?

[mcwumbly (Dave McClure)]

If someone want’s to experiment with this, an interesting first step would be to attempt to allow the “preview” on the left side to be writeable, instead of read-only.

[purldator (mountain)]

@purldator

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.**

Learning markdown is not difficult. True wysiwyg only masks the real problem.

Many techniques and strategies exist to introduce markdown, in a way to mitigate a high resistance to change.

The way I see it, if a user base is not willing to use a markdown-flavored wysiwyg as I demonstrated above, then there are more problems to consider that have nothing to do with this situation. It has to do with any kind of change. But, only my opinion on the matter.

[Tom_Newsom]

@purldator

Learning markdown is not difficult. True wysiwyg only masks the real problem.

It seems to me that it’s a solved problem, many times over, in every major word processor and email client in the world.

[purldator (mountain)]

If you are referring to wysiwyg, then I already made my answer.

If you are not referring to that, may you elaborate on what you mean?

[codinghorror (Jeff Atwood)]

Argue all you want, this is not changing any time in the next couple years. So if it is a showstopper for you, let me be blunt: you should leave. Use something else that is more to your satisfaction.

[mcwumbly (Dave McClure)]

this is not changing any time in the next couple years.

I realize there are enormous technical hurdles here, but if the community were able to come up with compelling proof-of-concept – after the CommonMark integration – would you be more open to taking a closer look at this?

[codinghorror (Jeff Atwood)]

There is 0.0% probability of that happening, the technical hurdles are quite severe. Lots of assumptions about the pipeline. So I feel this is a harmful fantasy.

If you really “need” wysiwyg you should choose some other software. Full stop.

[mcwumbly (Dave McClure)]

There is 0.0% probability of that happening

[Mittineague]

I think there is some misunderstanding about the composer’s purpose here.

If a member is a complete non-tech there is nothing preventing them from entering plain text.

Some characteristics of speech can translate to the written word. i.e.
bold and italics with emojis helping to add various “emotions”

Quotes, links, code blocks, images, lists, headings, and rules, aren’t so much about “discussion” but are used often enough that being able to use them is helpful.
But IMHO they aren’t essential for discussion, and if a non-tech wanted to they could always post a link as a text URL or inidicate A MAIN POINT in some other way. or

• a list
• of items
• that isn’t
• a true list

So if the current editor is too complex for non-techs I’m thinking maybe it should have the number of features reduced

In any case, a forum post is about discussion, not about creating a web page. There is no need for adding features that are purely for style. eg. positioning, font families, etc.

True, they are “nice to have” but not essential for discussion.

The buttons in the toolbar make the more common formatting easy, “what you see” in the preview pane is “what you get” so I fail to see what more is needed that could be done other than removing the possibly confusing features so non-techs won’t get confused by them

[sam (Sam Saffron)]

There is 0.0 chance of a hybrid solution where there is both WYSIWYG and CommonMark living today in some sort of happy family.

There is a non 0% chance that someone can build a WYSIWYG plugin that would require a blank forum as a starting point and disables direct CommonMark everywhere. However, this would be a mammoth effort and definitely not something core will be working on in the next year.

[meglio (Anton)]

WYSIWYG plugin that would require a blank forum as a starting point and disables direct CommonMark everywhere.

What about a plugin that converts WYSIWYG to Markdown, so that it doesn’t break anything but rather is basically a wrapper.

[sam (Sam Saffron)]

You can not go from markdown hybrid to wysiwyg and back reliably

Anyway I feel we have said enough on this topic now, time to either build some proof of concept (which will not come from the Discourse team) or start talking about something else