I'd love to implement this instead of a WYSIWYG into our platform, but the problem is our users (non-technical) are not going to take the time to learn markdown. Even if we had a guide on the right I have a hunch they would still be super confused.
Idea: Add buttons to the top (optional) that LOOK like a WYSIWYG (something they are familiar with), that simply apply markdown around text.
I think you'd see such much wider adoption with that addition, which is something I'd love to happen, because WYSIWYG's do indeed suck.
Agreed 100%. GitHub's wiki UI (example: http://cl.ly/2T2718220P1Y3h0M330r) would be a great place to take inspiration from, since that's almost exactly what you're talking about.
Github's button-bar is nice, but let me throw up another offbeat idea: a hybrid toolbar/cheatsheet. It'd have:
• a toolbar-like row of pulldowns: one for 'range/inline' markup (like bolding), one for 'block/paragraph' markup (like headers, blockquote, code-indent), and one for complicated inserts (like link+linktext, image+alt)
• each pulldown would be filled with side-by-side entries showing both markup and effect, like the best cheatsheet/reference pages are laid out
• selecting a bit of markup would do 'the right thing' with the existing insertion point or selection-range
Thus a user might momentarily click then dismiss the dropdown just to refresh their memory of the syntax, or actually pick from the dropdown for assisted inserts. (If they're regularly picking items, it could reorder by 'frecency' for convenience. If they're usually just looking, it might instead order by some form of 'infrecency' [1] – don't bother showing familiar constructs that have been recently typed.)
[1] At the moment while there are thousands of Google hits for ["frecency"] there are none for ["infrecency"]. It's an infrecently needed concept.
Your suggestion might be a good default for handling image insertion. I know markdown, but in instances where I'm specifying an image (e.g. a blog, a CMS page) I'd rather have a button that lets me select from available images than have to type it out using markedown (which would require that I know the filename and explicit path). Not to mention image alignment.
Why would you want to force users to use a markup language that, as you say, they have no desire to learn, rather than a simple WYSIWYG editor? How would that make things better for users?
What'd I'd love to see is something that is a WYSIWYG interface for editing Markdown. Markdown is fantastic and awesome because it limits what people can do, but expecting clients to learn it is a pain in the arse.
Looks great, but by default it subjects the user to the markdown gotcha of wanting to italicize text_with_underscores_in_it. EpicEditor, by contrast, has italicizing underscores_inside_words turned off.
One potential pitfall with JavaScript preview of Markdown (or Textile, or any other similar language) is that if you're not using the same script to transform the content at the server side, the final output can contain subtle differences. Not all implementations are precisely equal. If differences do occur, that can be frustrating for the user who just carefully previewed their work.
An alternative (albeit a more resource intensive one) would be to make ajax requests back to the server and have it perform the transformation and return it to the page. Unfortunately, that's probably not going to be satisfactory for realtime previewing.
I used to use MarkItUp but eventually moved away from markdown altogether. I found I had to keep tweaking the parser to allow stuff like inline, floated images, code blocks with language-tagging (for syntax highlighting) and so on. It came to be more work than just using a WYSIWYG editor.
Idea: Add buttons to the top (optional) that LOOK like a WYSIWYG (something they are familiar with), that simply apply markdown around text.
I think you'd see such much wider adoption with that addition, which is something I'd love to happen, because WYSIWYG's do indeed suck.