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.
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.
In wysiwyg mode, what other buttons would you add besides the ones that exist already?
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.
(Incidentally, it was Stackeditās type of markdown-flavored wysiwyg I used to easily teach the second end user regarded above.)
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.
It seems to me that itās a solved problem, many times over, in every major word processor and email client in the world.
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?
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.
What about a plugin that converts WYSIWYG to Markdown, so that it doesnāt break anything but rather is basically a wrapper.
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