The Table of Contents feature is very well done—better than GW’s, I think. (I expect we’ll take inspiration from this for future modifications to our version of the ToC feature, in fact.) Kudos, guys!
(A quibble, and quite a minor one: the animated scroll-to-section is rather too slow for my taste. I’d prefer it scroll to the clicked section at least twice as quickly.)
the animated scroll-to-section is rather too slow for my taste
I agree. The catch is, the browser API we're using (window.scrollTo) doesn't have a speed option, so we have to either live with its choice of speed, or implement the animation ourselves.
An element that is entirely bold counts as a heading
So, I have a problem with this. My problem is that this is deeply antithetical to best practices of semantic HTML and web standards in general.
Now, my understanding is that the motivation for this behavior is that many people find it easier and more intuitive, in the Less Wrong editor UI, to bold some text than to figure out how to make a proper heading. This is understandable. However, if this is indeed the reason, then let me propose a solution:
When someone makes an all-bold element in the LW editor, convert that element into an actual heading when saving the post or comment. (Use whatever heading level is the lowest available level in the given editing context—post or comment.)
That way, the HTML content can better conform to standards and best practices, and the ToC features on both LW and GW can stick to using only actual HTML headings as sections.
Converting a bold-only paragraph to an HTML heading in the editor seems like a decent improvement to me. I do think that there are some constraints that we have that make stuff like that difficult, and which cause me to think that we do want to have the "interpret bold paragraph as heading" feature activated (while the HTLM we save in our editor would be semantically different):
- Most of the content on LW is historical content, where editor features like that weren't available. I want to make sure the ToC works well for that content, but I feel hesitant to edit all the HTML of those posts, in case that does change the semantic meaning of the text in some cases (obviously we introduced some of that confusion already with the ToC, but I think editing the old content feels a bit more violating than that).
- I think users that are used to Markdown will often use single bold words as heading, and I feel hesitant to deviate too much from the standard Markdown conventions of how you should parse Markdown into HTML.
- Some content is submitted to us via RSS feeds from people's blogs, where we obviously have no control over their HTML, and I would also prefer to not modify it.
I strongly endorse editing the HTML of old LW posts.
I’ve looked at that HTML, and almost invariably been horrified; it’s often an absolute mess. I don’t think that changing the semantics of the post is a serious danger, for three reasons:
- It’s usually quite clear what it should be.
- The way it’s displayed currently is already not the same as the way it was displayed back then, and there’s no remedy for that; better to make it right and proper going forward, than to compound old mistakes and the effects of an awkward transition.
- You can (and should) archive the un-corrected version, in case there’s a need to revert anything.
I think users that are used to Markdown will often use single bold words as heading
Really? I haven’t seen this… but if it’s true, it shouldn’t be encouraged!
Some content is submitted to us via RSS feeds from people’s blogs, where we obviously have no control over their HTML, and I would also prefer to not modify it.
This is understandable, but in general I think it’s better to do it right in the majority of cases and to either make an exception or to allow imperfect outcomes in a minority of cases, than to do it wrong in the majority of cases for the sake of consistency. (How much of this RSS’d content is there, anyway?)
1. It’s usually quite clear what it should be.
Are you imagining a manual process where you look at each post and edit it? I was assuming Oliver had in mind an automated script.
Would you expect it to be easy to script the conversion?
Some aspects of the conversion can, and should, be scripted. Some should be manual.
There is no reason to go through each post. Prioritize them: if someone comments on an old post, clearly it’s active, so edit that. If a post is getting a lot of traffic, edit that. Otherwise, leave it alone until there’s a reason to edit it, or you have time to do so.
(Also: crowdsource this stuff. Let trusted volunteers submit edited HTML, then drop it in as a replacement if it’s good.)
Most of the content on LW is historical content, where editor features like that weren’t available. I want to make sure the ToC works well for that content, but I feel hesitant to edit all the HTML of those posts, in case that does change the semantic meaning of the text in some cases (obviously we introduced some of that confusion already with the ToC, but I think editing the old content feels a bit more violating than that).
Also, I just want to point out that one obvious compromise would be to both treat all-bold elements as headings (for compatibility with as-yet-un-updated old content), and convert all-bold elements in newly-created content (that is written with the Draft.js editor) to proper headings. That way, you would not be creating any new standards-violating HTML, while not being under any pressure to edit old content, and having the ToC work as expected for said old content.
Oh, yeah. That's what I meant to say above. Adding that behavior to our editor seems relatively low-cost.
I think users that are used to Markdown will often use single bold words as heading, and I feel hesitant to deviate too much from the standard Markdown conventions of how you should parse Markdown into HTML.
Don't know where you got this notion from, but absolutely not. Markdown has syntax that's used for headings, and I've never used bolded text as a replacement for a proper heading.
(As a wider point, Said Achmiz is as usual correct in his approach and it would be much appreciated if you didn't inflict any more appalling HTML practices on API consumers)
We just serve the historical HTML for practical all posts, and all new HTML is really as straightforward HTML as you can imagine (with some exception for blockquotes, which we currently split into block-level elements, though that will be fixed soon). Happy to hear about any other problems you have with the HTML, but I am not aware of any.
Just because markdown has a heading syntax, doesn't mean that everyone follows it, and depending on context you might not want to follow it. I literally googled "Markdown bold" and among the first few results this tutorial uses bolded headers as an example.
I literally googled “Markdown bold” and among the first few results this tutorial uses bolded headers as an example
Huh? I just went to that link; I don’t see where it says to use (or uses) bold-as-header.
Edit:
Just because markdown has a heading syntax, doesn’t mean that everyone follows it, and depending on context you might not want to follow it.
That not everyone follows it is, clearly, technically true (though I don’t at all share your impression of this practice’s prevalence). But I’m curious to know why you would ever not want to follow the heading syntax, if what you want to produce is a heading? (Other than cases of “this particular parser and/or renderer exhibits bizarre behavior, so I unfortunately have to produce non-standard Markdown in order for what I write to look sane when displayed”—but that, obviously, does not apply here, since we’re talking about determining what the parser and renderer do!)
I’m curious to know why you would ever not want to follow the heading syntax, if what you want to produce is a heading?
I've sometimes used regular bold for headings, I think mostly because it's lower friction. I don't need to think about what level of heading I should use semantically, or how that level actually renders.
But that’s not a heading, nor would it be correct to treat it as such! (Note that lower down on the page you linked, the tutorial specifies how to make actual headings!)
Oh, I think if a user enter that text into a text editor, they would prefer it to show up in the ToC rather than not. Or at the very least have the option to add it to a ToC (though I think if they had to choose, most users would prefer to add it).
I think that if a user is thinking about these sorts of things at all, then they can, should, and do have the capacity to make an actual heading element. (And if this is at all difficult or unintuitive in the UI, then that is the flaw that needs to be rectified!)
I'm the one who implemented this. While it's partially about making it intuitive in LessWrong's GUI editor, the decision was mostly based on trying it out on historical posts, and seeing what seemed to work best. All of that content pre-dates our current ToC implementation, and some of it was imported from quite far back in time. (This is also why <h5> and <h6> aren't considered headings.)
While we could write a migration script and also modify the editor to save as headers, we're reluctant to do that because it could change the semantics of old imported content, and we're reluctant to invest in LessWrong's Draft-JS editor right now, since we're planning on replacing it with something better.
Feedback on sub-question posts: Their visibility is way too low. They don't show up on the front page either as a post or under discussion (although I'm not sure about the latter). They do not show in the parent question author's inbox/notifications. On the main question page they have less visibility than a comment because they show as only titles (which is easily missed) and requires a clickthrough to view the body.
(Posting here because I can't find the post where the sub-question feature was announced.)
Yeah, the Related Questions feature doesn't currently really do it's job.
Curious about your preferences between:
- Make them more prominent (any combination of "they show up on frontpage, they show up more visibly on the question page, and give the OP author a notification")
- Just deprecate the feature (it originally was trying to do an oddly specific thing that I thought made sense, which I'm currently less confident was worth it)
Aside from opportunity cost (which you're in a better position to judge), I don't see a reason not to try making them more prominent.
(I originally posted this as a response to the wrong post.)
Some feedback on the new features:
It doesn't seem possible to retract answers. This seems to be a bug, especially since attempting to retract them results in the listed number of comments decrementing (eventually to negative values). This decrement vanishes upon reloading.
This post describes certain guidelines for answers. The commenting guidelines are posted above the comment box. Could the answering guidelines be posted similarly?
Re: the post page redesign: I rather like the new layout of the title / post-meta section. However, the new sticky heady is not great. Sticky headers in general are really quite annoying, especially on desktops or, worse, on laptops (where vertical space is at a premium).
(There is also what appears to be a layout bug where the appearance of the sticky header shifts the ToC down, even though it really seems like it shouldn’t.)
However, the new sticky heady is not great.
Not 100% sure which thing you're referring to – the fact that the header-section (at the very top) re-appears when you scroll up has been there for about a year. It disappears when you scroll down. Are you referring to something else?
Not 100% sure which thing you’re referring to – the fact that the header-section (at the very top) re-appears when you scroll up has been there for about a year.
Hmm. I never noticed it before. No, something about the behavior of the header has changed. I don’t use LW.com enough to tell you exactly what, but I’m almost sure it’s something…
In any case, change or no, my comments about the current behavior do stand.
After a couple months of work, we're ready for a significant update to LessWrong:
Post Page Redesign
The first thing you probably noticed is that we redesigned the post page. This was more of an incidental change, which turned out to be necessary in order for both Table of Contents and Question posts to work nicely.
Table of Contents
We wanted a Table of Contents that not only helped you orient at the beginning of a post, but provided a frame of reference while reading a post, that would help make longer, more complicated posts more skim-able.
Features:
There are some additional nice-to-have features we plan to add soonish, such as the ability to collapse the ToC, and the ability to preview it while drafting a post.
In general we'll probably experiment a bit more with the format.
Props to GreaterWrong for implementing a Table of Contents quite a while ago. :)
Open Questions
I wrote a couple weeks ago about our new Questions and Answers system. We're now ready to deploy the minimum-viable-version of this.
Current Features
For the time being, questions are subject to the same frontpage guidelines as anything else. If a question seems productive, well-specified and not-too-political, we'll promote them to frontpage, and otherwise they'll be visible in the All Posts or Daily views.
Upcoming Goals
There are many additional features we expect to be necessary for Q&A to flourish.
What Makes a Good Question?
We want people to feel comfortable asking a range of questions, from "What caused the scientific revolution?" to "wtf is Moloch?"
Some concrete examples include:
You can also add more detail about your epistemic state in the post body. Examples:
Comment Guidelines
Finally, we've also added some new features to your personal moderation guidelines. Previously, we gave users with 2000 karma the ability to moderate posts (whether on their personal blog or on frontpage). Along with that was the ability to set their moderation guidelines.
We also want people to be able to use their personal blog section roughly the way they would any other blogsite, which includes setting moderation policies. So, if you have 50 or more karma, you will now be able to set and enforce moderation guidelines on personal blogposts.
If your post guidelines are compatible with the frontpage guidelines, we may promote it to frontpage. There, you won't be able to moderate it yourself (if you have less than 2000 karma) but the normal site admins will attempt to enforce the spirit of your intended rules.
In the future we will build out some features to make this process smoother and clearer to new users, and to give them options about which posts they want to move to frontpage. For now, send us a PM if we've moved a post to frontpage that you want to retain direct moderator control of, and we'll move set it back to personal-blog.
You can also use the 'report comment' tool if you think we missed a particular comment that should be moderated while leaving it on frontpage. (We'll be using our judgment about which cases are actually compatible with the frontpage guidelines)
Note: Due to a quirk of codebase, users won't receive their new moderation permissions until they receive an vote. So, if you have 50+ karma now, it'll kick in when a comment or post is voted on. Send us a PM if you really want to get going right away.
How to Setup Moderation Guidelines
After having done that, you'll also have the option to set the moderation guidelines for individual posts. By default, they will be the guidelines you set in your user profile, but you can change them if you'd like a particular discussion to go a certain way.
[1] Note, "Easy Going", "Reign of Terror", etc, are just rough suggestions. They don't have a direct impact on what you're allowed to do as a moderator.
Go Forth and Be Curious!
We're looking forward to people asking questions and cultivating new types of conversations. Let us know if you have any thoughts or feedback. :)