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.
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.
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.
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?
Honestly, it was a random name I made for the directory it was in while I was experimenting. I put my very-super alpha on github and it got picked up by thechangelog and started trending for the month and so I decided, meh, I'll just keep it. But, personally I hate the name too :)
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.
Code blocks with syntax highlighting is super easy to implement. Styling images should be done with CSS, no? Also, you can add HTML in Markdown so you could easily just do:
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.
30 comments
[ 2.4 ms ] story [ 77.0 ms ] threadIdea: 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.
I wonder how you could add such help on top of a Markdown editor.
• 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.
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.
< img src= "..." class="align-right" >
http://hallojs.org