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