I followed a link to STET, a “A Writers’ Journal on Culture & Technology” and realized that STET also acts as the company organ for Editorially, a company that has created a co-editing application of the same name. Although I had signed up for the beta, I had either missed the email letting me know I was accepted to the beta (back in July, it turns out), or just never created a document.
So I thought the sensible thing would be to write my review of Editorially in Editorially, since I had read in a recent post at STET that it integrates with WordPress (see disclosure), so I could check out that as well. (Also integrates with Dropbox, so maybe I could start retaining versions of my GigaOM Research posts in my Dropbox account, too).
Some Words About markdown
Editorially is unlike WYSIWYG editors like Microsoft Word, Google Docs, or Apple Pages. It is also unlike Quip, an web-based co-editor which has an ideosyncratic approach to markup (see I want a social editor, but Quip isn’t there quite yet, and Quip 1.5 adds new features, but not the ones I want). Perhaps the tool it most resembles though is Draft (see Draft is a small and simple co-editor), but Editorially has a richer model of comment threads.
Editorially uses a text-based markup language called markdown to indicate text styling, bulleted lists, links, and embedded images.
In the screenshot below, you can see Editorially in edit mode. At the top is the document title, and a pull down menu showing that, yes indeed, Dropbox and WordPress are integrated. Just below the pulldown is a markdown link to the Editorially website, for example (‘
I have used markdown in several other tools, and find it fast and intuitive for the most part. Here’s the markdown cheat sheet Editorially provides:
Note that the Editor view provides a preview of images that are referenced in markdown, presumably to avoid confusion. There are also Preview and HTML views, which render the document in those formats. Here’s the Preview of this document:
Co-editing is based on inviting other people to share a document, and assigning them the role of either Reviewer or Editor:
Comments are created by selecting a section of the document, and then clicking on ‘New discussion’. Here you see that Other Boyd made a comment on this paragraph — could be as small as a single character, or as large as the entire document — and I replied.
Note that some comments here in yellow: that denotes that the comments have not been responded to. The one selected in this image has been replied to, so the default action is to close the comment, turning it gray. Note the ‘Reopen’ button at the bottom, so that the comment thread can be turned back to yellow.
When multiple discussions are going on in the document, you can rapidly switch from one to another by clicking on the arrow buttons in the image above, or see all discussions headings by clicking on ‘All discussions’:
This is where Editorially shines. It’s a first-class experience for editorial interactions.
A second aspect of co-editing is keeping versions, and Editorially does not disappoint. There are capabilities for creating a new version from the current one with or without comments, as well as going back to an earlier copy.
Best of all, Editorially provides a graphical comparison of any other version with the current selected version:
And the comparison looks like this, with content deleted from the current version grayed, and added material in blue:
The Bottom Line
I have not had the opportunity to use Editorially in an actual work setting as yet, but I plan to do so in the next weeks. In fact, I plan to migrate the materials for book I am writing — The Third Way Of Work — over to Editorially, and perhaps the next report for GigaOM Research.
While the color coding of comments is a good visual signal, it would be better if there was an integration approach with some task manager. It just so happens that each of the documents, and individual comment threads have unique URLs. That means I can use Todoist to create reminders in my already existing to do list if a comment leads to something more than I can do in a moment or two. This is much like the discussion I laid out recently in Small pieces, loosely joined: Why everything should be URLs.
I didn’t get to test out the WordPress integration because that works only at WordPress.com, or if your WordPress instance has Jetpack installed. I am unsure if GigaOM does have that, but will try to find out. As it is, I easily copied the HTML and pasted into GigaOM Research’s instance, and only had to make a few tweaks.
The Dropbox export is only in markdown as a text file, but I have all sorts of tools for converting markdown to other formats, or publishing to the web, if I ever want to do that. For the moment, I just like the idea of having a backup.
With those caveats aside, I like literally everything I have seen in Editorially, and I believe it will become a central part of my workflow going forward. Now, if I can only get the editorial staff at GigaOM to follow along.
(Disclosure: Automattic, the maker of WordPress, is backed by True, a venture capital firm that is an investor in the parent company of GigaOM. Om Malik, the founder of GigaOM, is also a venture partner at True.)