Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

EpicEditor: An Embeddable JavaScript Markdown Editor

oscargodson.github.com

Post reply on HN
Print view View original

11–20 of 31 posts

Re: EpicEditor: An Embeddable JavaScript Markdown Editor

#11

Post by subpixel »

cwilson wrote: post #4

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 wi…

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.

Re: EpicEditor: An Embeddable JavaScript Markdown Editor

#12

Post by lazerwalker »

cwilson wrote: post #4

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 wi…

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.

Re: EpicEditor: An Embeddable JavaScript Markdown Editor

#13

Post by johnmdonahue »

cwilson wrote: post #4

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 wi…

Yep, this is planned once we get cross platform support (still need IE8 and mobile) https://github.com/OscarGodson/EpicEditor/issues/41

Re: EpicEditor: An Embeddable JavaScript Markdown Editor

#14

Post by johnmdonahue »

guptaneil wrote: post #6

This looks cool, but unfortunately does not work well on touch devices. It looks like the preview and maximize buttons depend on the hover event.

This is the next thing we'll be tackling after IE8 support actually. It'll have a totally custom look for mobile. https://github.com/OscarGodson/EpicEditor/issues/27

Re: EpicEditor: An Embeddable JavaScript Markdown Editor

#17

Post by [deleted] »

lazerwalker wrote: post #12
cwilson wrote: post #4

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 wi…

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.

[deleted]

Re: EpicEditor: An Embeddable JavaScript Markdown Editor

#20

Post by drewmclellan »

This is similar in many ways to MarkItUp (http://markitup.jaysalvat.com/), which I've had good experiences with.

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.

Post reply on HN