Visually this is a noticeable improvement. Cleaner design. Larger body text with reasonable max-width. Less UI “noise”. I haven’t messed around much with the interface; there are probably other positives. Only significant visual regression is the lack of alternating colors on comments.
(a few people have noted that the new visual scheme isn’t all that site-distinctive; I’m not sure if I like it that way or not)
I see posts from names I haven’t seen on LW proper in a while, which is a good sign. Content is king.
That said, some preferences the new site violates:
Lag. I get it mostly when scrolling or doing text input, rather than loading. I am not sure how much of that is the site’s fault or my machine. I am tempted to blame it on the site, because...
Overly dynamic interface. I don’t know what your performance bottlenecks are (I assume you’re profiling and know better than me), but I see elements that could easily be static sidebars turned into foldouts, or the popup formatting overlay, or whatever it is that’s making the titles on my tabs change, and...well, it smells like lagbait. Code that doesn’t run can’t cause performance problems, and none of that stuff is necessary. (also I don’t like it stylistically, but I admit my tastes are technologically ascetic.)
Speaking of the formatting overlay: I see no way to compose in plain text with markup...any form of markup. I favor markdown, but the specific format is irrelevant, any of the modern LMLs will do. I want to not be fighting the editor (right now I’m fighting the list detection and undo), if I am thinking about the editor I am not thinking about my post,and I want the option of composing nontrivial posts in my editor of choice. If I can’t copy-paste marked-up text into the posting interface, it will be either enraging (if I use it) or useless (if I don’t).
There should be no topbar or bottombar, at least not on widescreen displays. I appreciate that the topbar here isn’t nearly as obstructive as many other sites. I can actually see the body text without scrolling first! But horizontal space is practically free and vertical space is priceless. UI chrome should eat the former, not the latter.
Sometimes you have to clear rubble before you can build, and I know that’s what this project is all about, so I’m not complaining too hard about regressions. The only dealbreaker for me right now is the editor. If I can’t compose in plain text without interference, I probably won’t be posting at all.
Agree with most of this. Here are more precise thoughts:
1. Agree that lag is bad. Performance and speed continues to be top priority. Our main performance branch with significant improvements in this area is currently blocked from merging by a bug in Meteor, but I will probably move a good chunk of them out of there in the next few days and implement them directly. That should improve lag a good bit.
2. Agree that a bunch of stuff is currently too dynamic. In the modern node landscape it’s a bit too easy for my taste to just download an npm package that solves all of your problems, while having subtle but significant long-term impacts, and I think this happened a bit too often in development. I’ve changed how we make design decisions significantly till then, and have spent a lot of time cleaning things up. Expect things to generally get a lot slimmer and less bulky over time.
3. We are working on a bunch of editor improvements, and one of the things I definitely want is just a markdown mode for our editor. We actually have all the relevant infrastructure, and would only need to build the relevant UI, though I do want to make sure that that is simple and not confusing. And also that you can translate between the two presentations of the content, without needing to redo the markup. But given what you said about the importance, and a few others who have expressed similarly strong preferences, I will consider just pushing a slightly less ideal version first, and then building one later. I.e. one thing that would only be an hour or two of work would be to add a profile setting that changes the comment editor to markdown.
4. Hmm, not sure what you mean by topbar. We don’t have a bottom bar at all, and we have a non-fixed app bar that’s only fixed on mobile devices, since that makes the navigation there a bit easier (though I will probably also make it non-fixed there). I don’t think we can easily do away with having a navigation bar at all, but I would also be surprised if you’re advocating for that. More elaboration would definitely be useful here.
Overall, thanks a lot for the feedback, and I think our qualms about the current version of the page are mostly aligned.
General strategic thought: I worry more about where we are a month from now than where we are a day from now. If the bug in Meteor will be fixed reasonably soon and it takes non-trivial effort to migrate the code to where you can implement it now, I’d be inclined to wait, even though I agree that would be the best improvement to make right now. In general I think one should be suspicious of short-term wins that slow down long-term progress.
Re: dynamism and lag, one thing that really makes me suspicious is the cycling of the tab title. Something is looping in the background after the page is done loading. I’m no web developer (I do python cantrips, mostly) but I might poke around myself. What do you use for profiling?
By topbar I think I mean the app bar. The one across the top. I would prefer if, on widescreens, it were placed along the side (where the foldout menu appears, perhaps) in order to maximize available vertical space. That’s an aesthetic preference, though. I do really like that it doesn’t chase my scrolling down the page, or pop up whenever I scroll back, like some sites I could name. Thank you for that.
Is there a documented API for the site, by the way? Is it in principle possible to develop a native client?
My own four cents:
Visually this is a noticeable improvement. Cleaner design. Larger body text with reasonable max-width. Less UI “noise”. I haven’t messed around much with the interface; there are probably other positives. Only significant visual regression is the lack of alternating colors on comments.
(a few people have noted that the new visual scheme isn’t all that site-distinctive; I’m not sure if I like it that way or not)
I see posts from names I haven’t seen on LW proper in a while, which is a good sign. Content is king.
That said, some preferences the new site violates:
Lag. I get it mostly when scrolling or doing text input, rather than loading. I am not sure how much of that is the site’s fault or my machine. I am tempted to blame it on the site, because...
Overly dynamic interface. I don’t know what your performance bottlenecks are (I assume you’re profiling and know better than me), but I see elements that could easily be static sidebars turned into foldouts, or the popup formatting overlay, or whatever it is that’s making the titles on my tabs change, and...well, it smells like lagbait. Code that doesn’t run can’t cause performance problems, and none of that stuff is necessary. (also I don’t like it stylistically, but I admit my tastes are technologically ascetic.)
Speaking of the formatting overlay: I see no way to compose in plain text with markup...any form of markup. I favor markdown, but the specific format is irrelevant, any of the modern LMLs will do. I want to not be fighting the editor (right now I’m fighting the list detection and undo), if I am thinking about the editor I am not thinking about my post, and I want the option of composing nontrivial posts in my editor of choice. If I can’t copy-paste marked-up text into the posting interface, it will be either enraging (if I use it) or useless (if I don’t).
There should be no topbar or bottombar, at least not on widescreen displays. I appreciate that the topbar here isn’t nearly as obstructive as many other sites. I can actually see the body text without scrolling first! But horizontal space is practically free and vertical space is priceless. UI chrome should eat the former, not the latter.
Sometimes you have to clear rubble before you can build, and I know that’s what this project is all about, so I’m not complaining too hard about regressions. The only dealbreaker for me right now is the editor. If I can’t compose in plain text without interference, I probably won’t be posting at all.
Agree with most of this. Here are more precise thoughts:
1. Agree that lag is bad. Performance and speed continues to be top priority. Our main performance branch with significant improvements in this area is currently blocked from merging by a bug in Meteor, but I will probably move a good chunk of them out of there in the next few days and implement them directly. That should improve lag a good bit.
2. Agree that a bunch of stuff is currently too dynamic. In the modern node landscape it’s a bit too easy for my taste to just download an npm package that solves all of your problems, while having subtle but significant long-term impacts, and I think this happened a bit too often in development. I’ve changed how we make design decisions significantly till then, and have spent a lot of time cleaning things up. Expect things to generally get a lot slimmer and less bulky over time.
3. We are working on a bunch of editor improvements, and one of the things I definitely want is just a markdown mode for our editor. We actually have all the relevant infrastructure, and would only need to build the relevant UI, though I do want to make sure that that is simple and not confusing. And also that you can translate between the two presentations of the content, without needing to redo the markup. But given what you said about the importance, and a few others who have expressed similarly strong preferences, I will consider just pushing a slightly less ideal version first, and then building one later. I.e. one thing that would only be an hour or two of work would be to add a profile setting that changes the comment editor to markdown.
4. Hmm, not sure what you mean by topbar. We don’t have a bottom bar at all, and we have a non-fixed app bar that’s only fixed on mobile devices, since that makes the navigation there a bit easier (though I will probably also make it non-fixed there). I don’t think we can easily do away with having a navigation bar at all, but I would also be surprised if you’re advocating for that. More elaboration would definitely be useful here.
Overall, thanks a lot for the feedback, and I think our qualms about the current version of the page are mostly aligned.
General strategic thought: I worry more about where we are a month from now than where we are a day from now. If the bug in Meteor will be fixed reasonably soon and it takes non-trivial effort to migrate the code to where you can implement it now, I’d be inclined to wait, even though I agree that would be the best improvement to make right now. In general I think one should be suspicious of short-term wins that slow down long-term progress.
Re: dynamism and lag, one thing that really makes me suspicious is the cycling of the tab title. Something is looping in the background after the page is done loading. I’m no web developer (I do python cantrips, mostly) but I might poke around myself. What do you use for profiling?
By topbar I think I mean the app bar. The one across the top. I would prefer if, on widescreens, it were placed along the side (where the foldout menu appears, perhaps) in order to maximize available vertical space. That’s an aesthetic preference, though. I do really like that it doesn’t chase my scrolling down the page, or pop up whenever I scroll back, like some sites I could name. Thank you for that.
Is there a documented API for the site, by the way? Is it in principle possible to develop a native client?