Choose editor(s) as a basis for the authoring environment

[jmatsushita]

• Define criterias and list possible choices
• Invite contributors to comment
• Decide which are unavoidable editors
• Get started on easiest one to extend

	Markdown	Git	Inplace	Active
Prose	Yes	github	No	No
Gitbook	Yes	git	No	Yes
Dillinger	Yes	github	No
Aloha			Yes
Pen Editor	Yes	No	Yes	Yes
ContentEditable	No	No	Yes	Yes
Realms.io	Yes	Yes	Preview	Yes
Substance	No	No	Preview	Yes
PubPub	Yes	?	Preview	Yes
VisualEditor	No	?	Yes	Yes

See the current analysis at http://iilab.github.io/contentascode/technology/authoring/

[bsenyk]

I think the key features to consider (in rough order of importance) are:

• Support for image insertion (this seems to vary)
• front end API for saving that helps with handling images in some way
• front end API for loading/saving that helps with metadata (could directly support it like Prose, or could just allow manipulation of the file while loading and saving to separate out and recombine metadata with the file)
• direct integration with git/github for file storage

Image support would be the most annoying to get right when building on top of an existing product. Any of the other features could fairly easily be bolted on to most of the contenders, though.

[jmatsushita]

Thanks for the input!

• Support for image insertion (this seems to vary)

Indeed. Prose is pretty good at this, with a drag and drop upload, and the possibility to select a shared media folder (instead of files being uploaded in the current directory), but it could be slightly better for instance by allowing to configure where the upload occurs (under /images in the current directory would be cleaner for instance).

front end API for saving that helps with handling images in some way

Not sure I get your point completely, but right now drag and dropping in a Markdown file in Prose leads to (I think) instant commit of the image file to the current directory (or shared media folder if there's one). I guess that client side or server side processes (post-commit processes to generate image derivatives - resize, filter,...) would be really cool. Is that what you meant?

There's also browsing in existing uploaded images and moving images around in the frontend which would make things so much better. I'm wondering. Could we make image management so much better than say with Word, that it becomes an incentive to migrate to this approach?

front end API for loading/saving that helps with metadata (could directly support it like Prose, or could just allow manipulation of the file while loading and saving to separate out and recombine metadata with the file)

Yes, actually with our chats with other project partners (@houndbee @poser), the ability to manage metadata also of copy/pasted markdown is very important. I think there's a level of abstraction where images, and block of content are parse and assembled on the fly by drawing on either YAML, or files that are on the side and contain structured data and can be invisible to the user (but accessible if need be).

An interesting extension of that problem, in the case of markdown or text blocks, is to allow the parent document you're displaying to have some internal logic about how the children can be organised (like rules about which type of blocks can go in some slots).

I was wondering i some extension of Markdown to manage something that's quite close to microformats would be worth investigating.

direct integration with git/github for file storage

That's fairly common. It's out of the box for github and Prose. It's git (not just github) for Gitbook, and Dillinger throw in Google Drive and Dropbox as well. At some point, Substance was looking at OT over Git, which would mean real-time collaborative editing with Git storage. How sweet would that be!

[jmatsushita]

Also just having the frontend manage some metadata automatically, like content update datetime, is not the case now. We also discussed with @mayarichman that it could be a simple enough thing to develop that would allow us to delve into the code of the top contenders for the content editor, and try to implement it to see which development experience we come out of with the best impression.

[shulter]

Great point about image insertion support. I think Aloha is the least interesting, no image support out of the box, copy&paste doesn't work, home and end do not jump in the text.

[jmatsushita]

Oh ho! http://realms.io/ and http://gitit.net/

[jmatsushita]

Realms has:

• Built with Bootstrap 3
• Currently Markdown (w/ HTML) only
• Syntax highlighting (Ace Editor)
• Live preview
• Collaboration (TogetherJS)
• Drafts saved to localstorage
• Handlebars

Collaboration! Drafts saved to localstorage! Awesomeness.

[shulter]

Looks awesome. Could you test it? It was not possible for me to sign up for the demo.

[jmatsushita]

Added Substance from #12 (comment) and PubPub from #25 (comment)

The collaboration features of PubPub seem really really good. It's not clear whether it's using Git for versioning though. So it's not as compelling as Prose which just layers their app on top of Github (rather than having another app with which you need to authenticate...). It's really gorgeous though and I'll contact the author to get more info.

Ive had my eye on Substance for a few years and it was a very ambitious framework from the get go (I remember learning about Operational Transform there) then narrowed its scope somehow to focus on a specific product, and now going back to a Library approach. I'll definitely dig into it more.

[jmatsushita]

Adding the MediaWiki VisualEditor https://www.mediawiki.org/wiki/VisualEditor

Can be tested here: https://www.mediawiki.org/wiki/VisualEditor:Test?action=edit

https://phabricator.wikimedia.org/diffusion/GVED/repository/master/

[poser]

Added...PubPub from #25 (comment)

NodeJS, React and Firebase? Maybe there are straightforward alternatives to Firebase? But I have no idea how to make Git useful as a data store for such a creature. Some kind of Commit notification to sync downstream? (And a _Save_ button to sync upstream?)

[jmatsushita]

NodeJS, React and Firebase?

@poser You mean if we were to write it from the ground up?

[jmatsushita]

Wow ProseMirror is pretty awesome and there's talk of integrating it in Prose...

It has collaborative editing, change tracking (that could be tied to a git based backend), client side linting (!) and dinosaurs - i.e. an extensible document model.

[jmatsushita]

This issue on ProseMirror makes a good point about separation of concern between the editor and the backend. Substance might mean a slightly stronger coupling between document authoring, document metadata and project navigation and backend.

In that sense Prose could be a project navigation component with ProseMirror as the authoring component (there would probably need to be some integration between the two to help for instance with navigation within a project's media or link library). Prose would manage document metadata (in the YAML frontmatter or elsewhere) and connect to various backends (including local ones for offline editing).

This gitbook component Repofs (https://github.com/GitbookIO/repofs) is an interesting approach to integrating the project navigation (and common features currently not in Prose like moving files, creating folders or dealing with templates.

[jmatsushita]

There's also Facebook's draft-js https://github.com/facebook/draft-js

[jmatsushita]

The arc is to go towards Prose (and I've opened a new issue for this #47) and hopefully ProseMirror integration (prose/prose#935) so I'll close this issue and when proper Issue tracker integration is implemented #40 then this will appear somewhere on the content as code website.