Hacker News new | past | comments | ask | show | jobs | submit login
Sidenotes in Web Design (gwern.net)
109 points by 12_throw_away 1 day ago | hide | past | favorite | 20 comments





This article would be a lot more persuasive if it's footnotes on mobile weren't a total mess of a system that's going in my bookmarks of bad design.

Everything is in black with white borders so the layers of pop over is hard to distinguish from everything else. The close button is also only at the top which isn't immediately obvious to find when you've read the text and is hard to reach on big mobile screens. (it's also in black with white borders and looks visually more part of the page then the pop over).

It also scrolls the back page to the link, so when you close the article now looks different then it did. At least when a link scrolls down to a footnote then back there's visual indication it did some scrolling. Here the scroll is obscured by the popup so it's very disorienting that it changes when you close the modal. (Again compounded by the fact everything looks the same colour and design)

Conversely the preview links (?) suffer from being too different to each other - the top block on mobile (starting "Sidenotes/margin notes are a typographic convention..." has three links. The first tufte link pops up a decent text that has better typography then this source article. The second tufte link (that uses the same anchor text and looks like it goes to the same place!) shows an identical pop up style with totally different text, now in a tiny size with a screenshot of even tiny text to add to the confusion. Just in case you can squint to read it's all made slightly transparent so you can still read the 4x larger original article text underneath.

There was an article on hacker news a couple of weeks ago where a guy was looking into the history of the Bloomfield bridge. I commented then that that article had some wonderful "footnotes", they just expanded inline you could read or not the extra info very easily. This is just an ugly and frustrating experience and certainly not anything that instills me with confidence in their articles advice.


If an "ad hominem" is what you call it when someone criticizes a person instead of their argument, what do you call it when you criticize someone's webpage instead of it's content?

I don't think the author's goal here is to persuade anybody of anything, but rather to inform people of design options, which I am very grateful for.

Personally I also find the website to have a fantastic design, and that a source of inspiration in terms of design.


I think both sides simultaneously have a leg to stand on. In terms of self-conduct, I try to skip past the noise and go for what I think is informative, and if complaining about a dentist's teeth is not informative then I skip past it. In this case I think there's more than enough value to skip past all the noisy complaints.

At the same time I understand there is a part of how human judgment works that cannot help but develop a story on why the dentist has bad teeth, and thus it is an informal burden on a proponent to also be an exemplar of what they say.


That's a really good point, and I agree with you fully. What I do not agree with and am not sure if you agree with either, is that the dentist has bad teeth to begin with. Furthermore if you where to say that 1+1=2, isn't in fact 2 because a dentist with bad teeth said it was then you are simply plain wrong.

Personally I find gwern to produce exemplary content*, and on a page that is really well designed. Which very much might be a matter of taste obviously, but this is very much the type of taste that makes me visit HN frequently, both in terms of aesthetics and content.

I would highly recommend anyone reading this, to have a look at the rest of the content on gwern's webpage.


I did some sleuthing to look into the footnotes implementation done by that guy looking into history of the Bloomfield bridge. Here it is for anyone else who’s interested as well: https://www.stevans.org/inline-footnotes/

Like pretty much all CSS interactivity hacks, those footnotes are not accessible; you can't operate them with a keyboard and screen readers only read the footnote number as a part of the text (even if the screen reader user guesses it's meant to be interactive, they can't click it).

What's the best way to handle footnotes, from a accessibility point of view?

I don't know of a better option than what a number of blogs, like Daring Fireball [0] do, link the footnote number to to the footnote, end each footnote with a link back to the footnote number (typically using the ↩ character).

Kitty Giraudel wrote about a version that's a bit "extra." [1] They make a whole word or phrase the footnote link text but style automatically inserted CSS counters so only numbers have the appearance of a link. Plus, each link has a description, "Footnote," to make it more clear to screen reader users where it goes.

[0] https://daringfireball.net/2023/08/whats_the_deal_with_senso...

[1] https://www.sitepoint.com/accessible-footnotes-css/


Interesting, thank you very much!

(I am the website author & tech co-creator with Said Achmiz.)

> Everything is in black with white borders so the layers of pop over is hard to distinguish from everything else.

They have double-white borders and drop shadows. It looks reasonably distinguished to me, but I suppose we could try one of the very light grays to see if that helps.

> The close button is also only at the top which isn't immediately obvious to find when you've read the text and is hard to reach on big mobile screens.

...Where else would the 'X' close button be?

> it's also in black with white borders and looks visually more part of the page then the pop over

The 'X' is right next to the title, it definitely does not look like it's 'more part of the page than the pop over'.

> It also scrolls the back page to the link, so when you close the article now looks different then it did.

If it didn't do that, then the anchor & context for the pop-over wouldn't be visible or the pop-over would have to be absurdly small whenever the tapped-link wasn't at the top of the screen already. So the shifting-to-top is good.

I think you're right that it should restore the position. It was originally a pop-in, so that didn't come up before we recently swapped to pop-over.

> that uses the same anchor text and looks like it goes to the same place!

I'll modify the text to be clearer.

> now in a tiny size with a screenshot of even tiny text to add to the confusion. Just in case you can squint to read it's all made slightly transparent so you can still read the 4x larger original article text underneath.

That is not how it's supposed to look, and doesn't on other pages - just here. Amusingly, it's caused by an interaction between the .sidenote class, and the page URL being 'sidenote'. (Nor is this the first time! JS and web browsers, man.) If you had tried it on any other page, like the section links of the abstract in my most recent page, https://gwern.net/suzanne-delage , it would've been fine. We've pushed a fix.

> I commented then that that article had some wonderful "footnotes", they just expanded inline you could read or not the extra info very easily.

It's a good essay (https://tylervigen.com/the-mystery-of-the-bloomfield-bridge) but the footnotes are not the highlight of that page.

- The zebra-stripe blockquote styling is annoying and makes them hard to read with visual moire (but can be fixed). - The fact that you have to opt into them with no indication of whether they are worth reading means cognitive burden (and while some are quite lengthy and worth reading, many are not). The author alleviates this a bit by sometimes specifying 'long note', but that increases the authoring burden, and doesn't solve the problem much (short notes can be interesting too). - 'Note' for each anchor is verbose & repetitive. - The footnotes are not aggregated at the end, so you can't skim or check them en masse. (And did you think you could just read or search the HTML source? Not without additional processing or word-wrap options to fix the ultra-long lines.) - The lack of a real hover popup is made up for with the hack of using tooltips - an idea I tried and abandoned very early on, because it strips formatting & cannot be made interactive or accessible; in his case, his tooltips are actually worse than useless because they silently, without indication, strip out large parts. For example, one tooltip at least bails out and tells you to click on it to see the email he sent, so at least you know you're losing everything, but then a later one ("The feds would pay up to 90% of the costs") silently drops an entire chunk! - The tooltips + default collapse also means that they aren't searchable: C-f 'pro-rata' will turn up nothing, because it's hidden in a footnote. (This is solved by aggregating or display by default; if one chooses not to do that, one should do something - for example, detect the search event, uncollapse all of them to make them visible for search, and then recollapse.)

I can't fault it on some issues like mobile handling or multiple+large footnote handling, but that's only because it avoids the problem of desktop sidenotes entirely, and is just the mobile version. (Which is why I didn't bother to link it: it doesn't do anything better than the examples already on the page, although now that I've looked closer, it may be worth linking as an example of the problems with trying to stuff footnotes or annotations into tooltips.) You like it because you don't want desktop footnotes at all, apparently, not because it represents a good solution.


> (I am the website author & tech co-creator with Said Achmiz.)

I recently spend some time reading some parts of your website and found myself a little bit frustrated by the experience. I'm hesitant to criticise, since your site is of course your personal Memex, but count me as a n+1 with the opinion that there is room for improvement.

I too struggled with the hover popups. The boxy design isn’t very aesthetically pleasing – at the same time too much chrome, I think, and like the OP wrote, too less differentiation from the body of the page. For a casual reader the whole window management of those popups seems too much. And there is a certain lack of predicability of them. For one, only some links seem to have them, second, the delay to pop is just the right time of infuriating. A common occurrence of mine, when reading your pages, is the following: I'm scrolling down, start reading the next paragraph, then, without me doing something, suddenly a popup pops up. What did I do? Did I do something wrong? Why is that happening? Of course, the explanation is simple: while scrolling, my cursor landed on a link which has a link preview popup and the delay happens, presumably, because the network request fetched the preview. But it is still an UI change without any real and conscious user action on my part. The effect is that one has to be careful to read you page, knowing where one's cursor is, and where to put it as not to trigger anything. I ended up deactivating the popups and later using Reader mode, first your site's own, then later my own browser's.

(Aside: The gear icon in the top right seems invisible in my browser [Safari, MacOS]. There is still a clickable spot of white background, the rest of the menu works. I only found out that there is a setting because I was reading your site design pages, learned about that feature and compared with Chrome.)

I am, sorry to say, also not the biggest fan of the design. The main body imitates in a lot of ways a classical printed product. That, I think, is great. But the specialised parts – the examples, the backlinks, the digressions, the blockquotes, even the inline <code> fragments – are all in that boxy sub-design, sometimes even in boxes inside of boxes, which, I think, clashes with the book aesthetic. A common cited quote by designers is Design is perfect when there is nothing more to take away. In that vein I'd try to use far less boxes but more typography and whitespace for differentiation.

And: I'd use far less interactivity. Maybe that's just me, but my preferred interaction with web pages is simply scrolling, not clicking. That is both on Desktop (space bar) and on touch. Click to expand something, click to turn a carousel, etc. is always a touch annoying. My preferred textual web page is simply static, has no reflows, and has no other need for interaction other than scrolling down.

All of these changes are of course not necessary – there are far worse pages on the web. But maybe, if you sometimes in the future have time, interest and energy, you'll keep iterating. gwern.net has very good bones; but there is room for improvement.

Oh, and since this thread is about sidenotes: When I, in a default HD desktop viewport resolution put the zoom level up a notch, because I find the font size too small, the sidenote implementation decides that the sidenotes have less room and the sidenotes are gone. I can understand that at higher zoom levels, but at a simple 110% it's frustrating. Stuff like that is why me preferred sidenote implementations are a simple float:right with the notes displayed inline at a break point for smaller viewports.


There's a maximum width that humans are comfortable with, reading paragraphs of text - usually measured in characters rather than inches though. Designers disagree on the precise limit, and how to count "characters" in variable-width fonts, but "don't go over 80" is a good start as a rule of thumb.

That is why newspapers print in multiple columns, novels are printed on smaller page sizes than the usual Letter/A4 (depending on continent) and why the default margins for TeX' article and related classes are so large compared to your average word document. It's also why variations on `main {max-width: 800px; margin: 0 auto;}` are so common on the web (along with all kinds of multi-column layouts).

If you're on a medium that's wider than this limit, then sidenotes are absolutely a good use of space - like a 1000+ pixel wide browser window, or physical textbooks (Crafting Interpreters, whose author gwern also mentions for their previous book on game design, is an especially good example of this).

If your medium is a mobile device, then you don't have that much "side" to put the notes in, so you have to get creative another way (you also don't have the same "hover" semantics as on desktop).

(End note: personal hobby horse of mine, but I hate "let's increase the width of our code from 80 to 120ish as everyone has widescreens now". Not only do I find a single file harder to read that way, but the main benefit of a wide screen for me is that I can have two panels open side by side at the time.)


> If your medium is a mobile device, then you don't have that much "side" to put the notes in, so you have to get creative another way (you also don't have the same "hover" semantics as on desktop).

When I designed my site (https://two-wrongs.com) I figured you don't have to get creative at all. A person reading on a small screen will likely want a more condensed text, with less of the semi-relevant asides.


Since the article mentions the sidenotes package for LaTeX, I would like to mention the sidenotesplus and snotez packages as well.

Both aim to improve over some perceived shortcomings of the original sidenotes package. The snotez-package is probably easier to use, while sidenotesplus has more batteries included.


I'm always endlessly mesmerized by this website's design.

It also shows a glimpse of what document-heavy hyperlinked web could've been, and never became.


Since most of the hyperlinked web is not document-heavy today, as opposed to what it was 30 years ago, form followed function and we have distracting visuals and annoying UX over mostly shallow content :)

Most of the web is still document-heavy, but yeah, it's mostly ads and annoying UX over a sea of nothingness

looks like a really deep analysis of side notes in web design. Super interesting.

However, I do not see a discussion of side notes and SEO (search engine optimization), and the implication of using this or that technique on SEO


There are no SEO implications, AFAIK.

it is not that simple. If you are using JS generated sidenotes, they are invisible for SEO engines.



Applications are open for YC Winter 2024

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: