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