- Editorially is a new product mainly for collaborative writing. Hides the markdown a little bit. You can enter it or use a toolbar.
- MarkdownMail for iOS
- Markdown Pad (Windows)
- 35+ Markdown apps for the mac: http://stefgonzaga.com/2012/11/markdown-mac/
What does a markdown editor need for science publishing?
- Figure metadata
- Tables are messy
- Math is not such an issue if you wrap LaTex or MathJax
- Pandoc (command line tool to convert markdown to HTML, XML, PDF, etc.) could be hooked in for outputs and rendering
- It may need a local instance to solve the psychological security of writing locally vs. writing in the cloud
- In this case the idea of packaging the paper's files comes into play (figures, etc.) the way something like knitr can do
- Track changes and comments (a real solution, not what GitHub can offer). CriticMarkup does this but via markdown - it's not enough
The hundred-year view
- Many science publishers archive XML for the long haul - how can markdown address this? Strictly by transforming to NLM at the end of authoring?
- We suspect markdown will be more human readable than Word in 100 years
Is WYSIWYG or some flavor of that essential to adoption?
- We believe that a strong percentage of smart authors will need to see a visual representation of their writing in order to be comfortable in an authoring environment, so yes.
- But a good thing about markdown is that formatting is not at all a consideration.
- One of the problems of a WYSIWYG editor is about copy/paste from Word. Either allow only plain text paste or you have to clean it up. WYSIHTML5 does a good job with copy/paste from Word.
Bottom line: We have not solved this issue, but what we do know is:
- The more you move towards an editor that will hide the Markdown, the less it makes sense to use Markdown in the first place.
- Ideally, for whatever format the industry adopts, it must be a simple thing, possible to pick up the basic functionality immediately and intuitively, and learn the advanced features over time.