TL;DR: LessWrong now has similar features to Google Docs. Warning! Still rough around the edges. To enable the collaborative editor, you must check "Opt into experimental features" in your account settings and then press the green "Share" button that appears when editing your post.
You can experiment with commenting and suggesting on this post with this link.
It's been a loooong time coming[1] but at last, we are ready to unveil collaborative editing features for the LessWrong text editor. These features will be familiar to those used to working in Google Docs:
- Multiple users can edit a document at once
- Fine-grained permissions for viewing/commenting/editing by link or username
- Inline comments (only viewable while in edit mode)
- Making and accepting suggested edits
- Automatic saving
- Version history viewer
Some advantages of using LW-Docs with collaborative editing:
- LW-Docs supports LaTeX, unlike Google Docs.
- If you use entirely LW-Docs, you won't have broken footnotes, unlike with copying from G-Docs.
- While writing your post, you'll know what the end result will look like (same font and line width) which helps you optimize paragraphs and layout for looking good when published.
- You can continue to get inline feedback and suggestions on your post even after you've copied it over to LessWrong.
- These can then be seamlessly integrated into your live post.
INLINE COMMENTS AND SUGGESTIONS ARE ONLY VIEWABLE IN EDIT MODE TO THOSE WITH PERMISSIONS
How to enable collaborative editing on your post
Step 1: Opt in to experimental features in your account settings.
Step 2: While editing your post, click the green "Share" button in the top right. Enable permissions for some other users. Boom! Your post is now in collaborative mode.
Step 3: Users explicitly shared on your post will receive a notification. Send the url to anyone else you want to grant access.
Step 4: When in collaborative mode, the text of your post is automatically saved. To view how your post will look when published, press the Preview button. To make the current state of your document live, press the Publish button.
The collaborative editor allows you (and others) to continue editing and commenting on a post even once it's been published. Edits aren't automatically published to the live version. To update the published version to the current state of the document in editing, press "Publish".
Step 5: Leave comments and suggestions.
To enable track changes, use the track changes button in the popup menu (third icon from the right) or set your Mode to Commenting in the header bar.
Step 6: Leave feedback about the feature!
This feature is still under development. Any feedback from early-adopters is hugely helpful. Just leave a comment on this post or message us on Intercom.
Warning! Rough around the edges
We're releasing this feature in beta mode because it still requires a few more finishing touches and might be a little confusing to use in places. As above, any feedback is greatly appreciated.
Why collaborative editing?
When developing features, there's always a question of "does anyone want this?" In the case of collaborative editing features, there's good evidence of demand from Google Docs. There's a common workflow that goes: (1) write a draft in Google Docs, (2) invite some close friends or collaborators to give feedback, (3) incorporate feedback, (4) copy to LessWrong, (5) publish.
Drawbacks of this workflow are (a) overhead of copying and reformatting the post, (b) enforcing a hard break between the feedback stage and the publication stage, (c) Google Docs does not support LaTeX, (d) valuable comments left in the feedback stage never get published to the wider world.
By introducing collaborative editing to LessWrong, we address (a), (b), and (c). We haven't yet made it so in-line comments in editing mode can be published in the final version, but we'll look into ways to allow for that. I also expect that we'll add additional features[2] to our editor that Google Docs doesn't have, such that users will benefit from the possibility of doing all their writing on LessWrong.
Having collaborative editing features on LessWrong also lets us start to build programs that rely on easy ways to give people feedback on their drafts. For example, I'd like to run a writing and research workshop for students that involves peer and mentor feedback. With collaborative editing on LessWrong, that will now be much more convenient to do.
What's your writing workflow?
If you're an author, I'd love to hear how collaborative editing features do or don't help you with your workflow, or what you'd really like to see us build. Feel free to comment on this post or message us on Intercom.
Thanks and good luck!
- ^
It's been ~18 months since the first steps towards this were taken.
- ^
One feature I'm particularly excited about is "link-searching". In the same way that one can @-mention people on Facebook, I'd like to make it so you can easily link to post and wiki-tags by typing @ or # and then using a few letters to search for the resource you want to link to.
Writer feedback partially unrelated to these changes: I find myself getting increasingly sold on the roam-style tree-structured writing format. Basically, if you've ever written code, you know why we need indentation sometimes. Sometimes a large number of things pertain to one previous thing, or they're grouped together in some way, and then there is often further nesting inside of that, and more nesting inside that, but it's important that the reader can easily see how it's all structured from an overview.
And that's just how concepts generally are. I'm going to argue that we need tree-structuring in prose just as much as we need it in code or in proofs.
Though I'm not sure. Disclaimer: This all only started when people started getting into Roam, so it's hard to say whether this is going to work out yet.
So this argument might not be convincing. Regardless, I think this is something we should talk about.
So, in conventional prose, you'd use naming and the occasional repetition to linearize a tree structure into a flat series of paragraphs, but if you've made anything halfway complex you start to realize it's sort of unnatural to do it that way, it makes everything more verbose, it means you have to cut anything you don't know how to flow in there elegantly, and it makes the overarching structure of the concept less visible.
Tree-structuring also seems like a somewhat more reasonable UX for footnotes, for the web. A nested section could be expanded in-line, instead of taking you to this place where all the footnotes are gathered together which is... not a coherent way to group that information (footnotes usually have nothing to do with other footnotes). Expanding a collapsed section is effectively the same as clicking a footnote, but with more reasonable spacial grouping.
We nest whenever part of the text should be optional.
A traditional writer might say, "that should be exceedingly rare: Everything in the text should be important, none of it should be optional". I think that is kinda paternalist hubris, in a way. You don't know what the reader knows or doesn't know, you don't know quite what they need to hear or what they should be allowed to easily skip. If your text has very little structure, if it's been collapsed down to a linear presentation, they're not going to be able to skip any of it, they just have to read it all. Unless you're limiting yourself to saying only the most contrarian or esoteric or entertaining stuff (and those sorts of writers sure do disproportionately flourish, in our scenes), but that's not always what people need.
It's beneficial if we can allow some form of interactivity and let the reader decide whether a piece of text is for them. Right now people are too passive. When you tell them something they already know they just not along finding satisfaction in agreement. They should be bored. They should follow their boredom. They should be looking for something better to do. They should be asking for clear indications as to whether they can skip this paragraph, but traditional writing formats couldn't fit those in, so they don't know to ask for it.
But linearized series' of paragraphs really are what people are used to, right now. I suspect that most people would effectively not be able to read tree-structured texts. For instance, you need to have the habit of, on reaching the end of a branch, looking back up the stack to remember its nearest parent context, before proceeding to the next one, or else it just wont make sense. You should develop that habit. It's a good habit to have when you're trying to traverse a complex conceptual structure. Most people don't have it. Even people who have it from programming or reading proofs or reading legal documents, it might not occur to them to apply it to reading prose.
An example of a document written this way would be the Venture Granters design. My impression is that very few people really read it. Though I'm not sure how whether that was due to the tree structuring or just because I wasn't at the point where I could justify the complexity succinctly, relative to regular retroactive public goods funding, at the time of writing.
I mostly use it from the computer so that missed me but it seems like a very good idea as well!