Curious which part feels unwieldy and annoying. Navigating it feels definitely less straightforward than just scrolling a list, though it is also a lot denser and allows us to have 6 sections visible at the same time, which allows people to get an overview over the types of content we have on the site without needing to scroll up and down a lot.
I do still share a feeling that it’s less straightforward to navigate than other stuff on the site. My guess was that the benefit of interactivity and playfulness that comes from the UI choices outweighs that (especially for new users who would probably mostly just be overwhelmed by a huge amount of information, which this page is more aimed at), but not sure.
Ah, it’s an outdated browser issue. (Mac, Chromium 103.) (Lack of support for the :has() pseudo-class, specifically, in the selector .TopPostsPage-imageGridPostBody:hover:not(:has(.TopPostsPage-imageGridPostHidden)) .TopPostsPage-imageGridPostAuthor, is what’s causing the problem.)
Yeah, getting summaries would be nice, but the effort of writing a summary for each post would have been prohibitive (especially one that the authors would have been happy with). We tried showing the start of the post, but it wasn’t very helpful for deciding whether to read something.
My worry was that having summaries only inconsistently adds a lot of mental complexity to track to the page. Now only sometimes when you hover over something do you see some kind of preview, and if you have ~60 items on a single page, adding any kind of indicator for that quickly makes things very cluttered.
And you would have to redesign the page quite a bit to have a good place for summaries without adding a huge amount of clutter or flashing or movement on the page.
I think they wouldn’t work well for this the vast majority of time. I think if you see all the reviews and can quickly skim them they are useful, but they definitely are not that helpful for deciding whether to read a post. It’s either a pretty generic “this post was great and useful”, or a really in-depth review that definitely assumes you’ve read the post and is very hard to parse without having read it.
Well, just for example, I tried to find a post, so I did Cmd-F, and… it didn’t work because the post I was looking for was in a collapsed part. (That is, the browser reported a hit on the search, but nothing changed in the viewport.)
(This is an easy thing to forget to implement; I’ve forgotten this very thing a few times myself. The solution is to listen for the selectionchange event, such that the enclosing section is automatically un-collapsed when the search function highlights text within a collapsed block.)
Then there’s the fact that it can be hard to read the post titles against the beautiful backgrounds. Notably, this is hard to notice when simply looking at the page as it initially loads, as the initially displayed artwork is mostly dark-colored (though the “Rationality” section isn’t great in this regard) and the text is light-colored (with a dark shadow, as is proper). But when you hover over the sections, the artwork changes—often, to much lighter and/or busier imagery, which makes the text harder to read:
As I said, this stuff really is pretty, but as a way of navigating a list of text items, it leaves much to be desired…
Yeah, I also played around a bit with legibility before you posted this, and am likely pushing a change to make it so that when are hovering over something, the text contrast goes up a lot (instead of down). Here is your last screenshot with the new styling:
The text-legibility here seems a lot better. Will probably push in the next hour, curious about more comments from you after you see that change.
Well, just for example, I tried to find a post, so I did Cmd-F, and… it didn’t work because the post I was looking for was in a collapsed part. (That is, the browser reported a hit on the search, but nothing changed in the viewport.)
Ah, yeah, that’s a solid point. I’ll see how easy it is to fix something here (it’s a bit more complicated since the visual space of the sections overlaps, so if you search for a word that has a hit in more than one section on the same row, we can’t expand both, so I’ll have to think about how to handle that case).
Agreed, that’s an improvement. (Must you require hover for that, though? I’d make that change unconditionally, frankly.)
I would also suggest deepening the text shadow, changing it from text-shadow: 0 0 3px \#000 to, e.g., text-shadow: 0 0 3px \#000, 0 0 5px \#000, 0 0 8px \#000, which looks like this:
it’s a bit more complicated since the visual space of the sections overlaps, so if you search for a word that has a hit in more than one section on the same row, we can’t expand both, so I’ll have to think about how to handle that case
Note that the selectionchange event will report the currently selected hit for the searched text, not all highlighted hits, so this should not be a problem. (As the user presses Cmd-G [Find Next], or Enter in the search box, the browser will cycle through the highlighted hits, firing a new selectionchange event each time.) Thus, each time the event is fired, you can expand whatever section the currently-selected hit is in (and collapse its neighbors in the row).
Note that the selectionchange event will report the currently selected hit for the searched text, not all highlighted hits, so this should not be a problem. (As the user presses Cmd-G [Find Next], or Enter in the search box, the browser will cycle through the highlighted hits, firing a new selectionchange event each time.) Thus, each time the event is fired, you can expand whatever section the currently-selected hit is in (and collapse its neighbors in the row).
Update: I just checked, and it seems like this stopped being true at some point; I am now seeing selectionchange events fired only on the initial search (when the user first spawns the Search box, by invoking the Find command or the Find Next / Find Previous command) and also when that box is dismissed, but not on subsequent invocations of Find Next/Previous (or the Enter key) when the Search box is open. (It is still the case that only a single selected hit, and not all highlighted hits, are reported.) This reduces the usefulness of the technique I described, though does not entirely eliminate it. @habryka
(Must you require hover for that, though? I’d make that change unconditionally, frankly.)
Yeah, I might consider it. I do think it makes the initial pageload a lot more drab, and removes a lot of the beauty from the page (and logged-in users who haven’t read most of the posts already have much stronger text-contrast).
Note that the selectionchange event will report the currently selected hit for the searched text, not all highlighted hits, so this should not be a problem. (As the user presses Cmd-G [Find Next], or Enter in the search box, the browser will cycle through the highlighted hits, firing a new selectionchange event each time.) Thus, each time the event is fired, you can expand whatever section the currently-selected hit is in (and collapse its neighbors in the row).
Oh, that’s great, I didn’t realize that’s how it works.
I would also suggest deepening the text shadow, changing it from text-shadow: 0 0 3px #000 to, e.g., text-shadow: 0 0 3px #000, 0 0 5px #000, 0 0 8px #000, which looks like this:
Oh, this is also a pretty good idea. I had forgotten that you can do multiple text-shadows at the same time. I’ll give it a try.
Curious which part feels unwieldy and annoying. Navigating it feels definitely less straightforward than just scrolling a list, though it is also a lot denser and allows us to have 6 sections visible at the same time, which allows people to get an overview over the types of content we have on the site without needing to scroll up and down a lot.
I do still share a feeling that it’s less straightforward to navigate than other stuff on the site. My guess was that the benefit of interactivity and playfulness that comes from the UI choices outweighs that (especially for new users who would probably mostly just be overwhelmed by a huge amount of information, which this page is more aimed at), but not sure.
The art change is pretty distracting, and having to hover to see the author is also a bummer, plus no way to get a summary (that I can see).
It’s seemingly optimized for a “judge a book by it’s cover” type of thing where I click around until I see a title and image I like
How do you see the author? Hovering doesn’t do that, for me…
Huh, it definitely should do that. See my screenshot in response to you in this comment: http://www.lesswrong.com/posts/qvCMiwkBqdYjfiX6n/new-lesswrong-review-winner-ui-the-leastwrong-section-and?commentId=RDZAizo8EMSmYLAZs
What browser/device combo are you on?
Ah, it’s an outdated browser issue. (Mac, Chromium 103.) (Lack of support for the
:has()pseudo-class, specifically, in the selector.TopPostsPage-imageGridPostBody:hover:not(:has(.TopPostsPage-imageGridPostHidden)) .TopPostsPage-imageGridPostAuthor, is what’s causing the problem.)Ah, yeah, we do sure rely on that, and it’s really quite hard to work around without moving a lot of stuff into JS, which I wanted to avoid.
Yeah, getting summaries would be nice, but the effort of writing a summary for each post would have been prohibitive (especially one that the authors would have been happy with). We tried showing the start of the post, but it wasn’t very helpful for deciding whether to read something.
Maybe consider asking the authors if they’d want to volunteer a ?50? word summary for this purpose, and include summaries for those who do?
It’s a nice idea to have an optional field on posts for the author to submit a summary with a max-length.
My worry was that having summaries only inconsistently adds a lot of mental complexity to track to the page. Now only sometimes when you hover over something do you see some kind of preview, and if you have ~60 items on a single page, adding any kind of indicator for that quickly makes things very cluttered.
And you would have to redesign the page quite a bit to have a good place for summaries without adding a huge amount of clutter or flashing or movement on the page.
Why not show the top-rated review, like you do at the top of the page?
I think they wouldn’t work well for this the vast majority of time. I think if you see all the reviews and can quickly skim them they are useful, but they definitely are not that helpful for deciding whether to read a post. It’s either a pretty generic “this post was great and useful”, or a really in-depth review that definitely assumes you’ve read the post and is very hard to parse without having read it.
Well, just for example, I tried to find a post, so I did Cmd-F, and… it didn’t work because the post I was looking for was in a collapsed part. (That is, the browser reported a hit on the search, but nothing changed in the viewport.)
(This is an easy thing to forget to implement; I’ve forgotten this very thing a few times myself. The solution is to listen for the
selectionchangeevent, such that the enclosing section is automatically un-collapsed when the search function highlights text within a collapsed block.)Then there’s the fact that it can be hard to read the post titles against the beautiful backgrounds. Notably, this is hard to notice when simply looking at the page as it initially loads, as the initially displayed artwork is mostly dark-colored (though the “Rationality” section isn’t great in this regard) and the text is light-colored (with a dark shadow, as is proper). But when you hover over the sections, the artwork changes—often, to much lighter and/or busier imagery, which makes the text harder to read:
As I said, this stuff really is pretty, but as a way of navigating a list of text items, it leaves much to be desired…
Yeah, I also played around a bit with legibility before you posted this, and am likely pushing a change to make it so that when are hovering over something, the text contrast goes up a lot (instead of down). Here is your last screenshot with the new styling:
The text-legibility here seems a lot better. Will probably push in the next hour, curious about more comments from you after you see that change.
Ah, yeah, that’s a solid point. I’ll see how easy it is to fix something here (it’s a bit more complicated since the visual space of the sections overlaps, so if you search for a word that has a hit in more than one section on the same row, we can’t expand both, so I’ll have to think about how to handle that case).
Agreed, that’s an improvement. (Must you require hover for that, though? I’d make that change unconditionally, frankly.)
I would also suggest deepening the text shadow, changing it from
text-shadow: 0 0 3px \#000to, e.g.,text-shadow: 0 0 3px \#000, 0 0 5px \#000, 0 0 8px \#000, which looks like this:Note that the
selectionchangeevent will report the currently selected hit for the searched text, not all highlighted hits, so this should not be a problem. (As the user presses Cmd-G [Find Next], or Enter in the search box, the browser will cycle through the highlighted hits, firing a newselectionchangeevent each time.) Thus, each time the event is fired, you can expand whatever section the currently-selected hit is in (and collapse its neighbors in the row).Update: I just checked, and it seems like this stopped being true at some point; I am now seeing
selectionchangeevents fired only on the initial search (when the user first spawns the Search box, by invoking the Find command or the Find Next / Find Previous command) and also when that box is dismissed, but not on subsequent invocations of Find Next/Previous (or the Enter key) when the Search box is open. (It is still the case that only a single selected hit, and not all highlighted hits, are reported.) This reduces the usefulness of the technique I described, though does not entirely eliminate it. @habrykaYeah, I might consider it. I do think it makes the initial pageload a lot more drab, and removes a lot of the beauty from the page (and logged-in users who haven’t read most of the posts already have much stronger text-contrast).
Oh, that’s great, I didn’t realize that’s how it works.
Oh, this is also a pretty good idea. I had forgotten that you can do multiple text-shadows at the same time. I’ll give it a try.