(c) Google Docs does not support LaTeX

I'd make this point much more prominent, I almost missed it! This point changes the feature from 'likely much worse than Google Docs + copying later' to 'actually probably worth using' for me

This looks like a great feature!

Suggestion: For this post, enable at least the inline-comment-mode (and share the link if required) so users can try it. I would love to give feedback on this feature, but don't have an easy way to test it right now.

Feedback on the editor commenting feature:

• Love it.
• When I try to close the page on which I've submitted comments, the browser (desktop Firefox v97.0.1) sometimes displays the standard warning "please confirm that you're exiting the page; your changes may not be saved". After exiting and reloading the page, it appears that everything was indeed saved.
• Inline commenting is supposed to be usable via the shortcut Ctrl+Alt+M, but this doesn't work for me. Maybe the shortcut is not implemented correctly; maybe it's a language problem (I use a German keyboard); maybe it's a problem with one of my gazillion Firefox addons...
• Apparently you get notifications if someone responds to your comments, but the notification text is wrong. I made a typo suggestion, Ruby replied, and then the notification said: "Ruby commented on your draft [Beta Feature] Google-Docs-like editing for LessWrong posts", even though it's neither a draft nor my post.
• At the very top of the document, next to "Share draft with users", are a bunch of names (like jimrandomh) with "X" buttons next to them. In commenting mode, I can ostensibly remove all these users by clicking their "X" buttons, but they reappear when I reload the page.
  • Other related things:
  • In commenting mode, I can change the text of Ruby's moderation guidelines, though these changes aren't saved.
  • I see the "Get Feedback", "Move to drafts", and "publish changes" buttons. Pressing any of them displays the errors "app.operation_not_allowed" and "Error submitting form: Post.update", though the "get feedback" button does load Intercom with the default "Hey MondSemmel,
    I'm glad you're interested in getting feedback on your post." text.
  • I can't use the "track changes" button (it's grayed out), but I can load the post's Version History, though I somehow only see versions 1.5.1 or newer. (Note: It's probably desirable to make specific past versions inaccessible or invisible, e.g. if you by accident briefly published a version with private information.)
• The notifications for getting a reply on your inline comment link to the entire post, not the specific inline comment, so it's currently difficult to find which comment was replied to.

Nice! Can't wait to use it. Will it be possible to let send someone a link to a draft and have them view it without a LessWrong account? Cause one of the reasons I use gdocs is for non-lesswrongers.

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.

Nice work!

Regarding my own workflow, unfortunately I would still have to go through external software most of the time. This is because most of my posts are latex-heavy, and it's impractical to wait for LessWrong to render a latex-heavy post every time you make and edit and want to see how it came out. Instead, I write the post in LyX^[1] while using (inoperative) markdown syntax (e.g. asterisks for italics) and copy it to LessWrong in the end, with appropriate editing (mostly a bunch of "replace all").