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?
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?