Many of these suggestions are good. (I should make my subheds clickable!) But a couple of them, oh dear…
I really hate progress bars, they are incredibly distracting. One of the worst examples of front end programmers wasting their time reimplementing browser functions badly. I already have scroll bars! I do not need more scroll bars!
Also, link decoration: my browser already has a nice discreet indicator to tell me where a link goes, I don’t need or want mysterious dingbats in the running text. (It reminds me of websites that are so scared of hyperlinks that they send them via interstitial warning pages “YOU ARE LEAVING THE SITE!!!!1!1!”, or in a recent case via a $yber$ecurity box that broke the link completely.) And preview popups? Get in the sea, hostile obnoxious interruption.
I think progress bars are a logical consequence of the user-hostile shrinking of the scrollbar. Unusable, narrow things which are often hidden by default, and rarely have a visible elevator (or thumb) anymore. Of course, scrollbars are often entirely useless in pages which insist on loading content piecemeal -- another user hostile pattern.
Obvious solution is obvious: restore the fucking scrollbar.
I suspect a strong driver of scrollbar deprecation is the overwhelming dominance of small-screen touch-based mobile devices. An active scrollbar, that is, one which not only shows page scroll depth, but controls it via touch, is one more UI element to generate annoying behaviours given the already perilous state of touch-based UIs. (The inability to correctly distinguish tap vs. drag or scroll actions is one that's driven me to distraction for well over a decade.)
Unfortunately, what's at least arguable on mobile becomes the trendy fashion on desktop, which is just fucking stupid.
I have some 4k pixels of width on my desktop, and some 400 on mobile. It makes sense to not have a wide scrollbar on mobile. But it makes zero sense on desktop.
Scrollbars do two things. They let you scroll (duh), but they are also progress indicators. There are other ways of scrolling (e.g. swiping on mobile) which work by default. But there is no other default way of showing progress. I don't particularly like the progress bar example in the original post, something as unobtrusive as a percentage in the bottom right corner would work just as well. But I do want some indication of progress ...
Agreeing strongly, but I'd just like to point out that a probably more significant problem on mobile is that a scrollbar which you're likely to unintentionally hit with your fingers as you're clumsily and very imprecisely interacting with your device, or as Steve Jobs so famously declared, are "holding it wrong", absolutely is a valid reason to deprecate classic indicator-and-control scrollbars on mobile devices.
That is, a classic desktop scrollbar, dating back to Xaw widgets, the original Apple desktop, and even earlier[1] not only shows where you are within a text or display, but allows you to control where you are typically by clicking on elements of that scrollbar: the cursor, the bar itself, and the endpoint arrows. Several of these had interesting / quirky / annoying variants on interaction (those familiar with early X11 Xaw widgets can likely think of several).
There's an interesting static image comparison at Reddit:
Another point on swiping: my mobile device for the past three years has been an e-ink tablet. And I've learnt that swiping absolutely sucks. E-ink displays are much faster than people seem to believe, but there's still lag that an emissive display lacks, and it's far better to page through a long text or display than to scroll through it. I've all but entirely adopted an e-ink optimised browser that mostly does this, EinkBro (based on FOSS Browser), and I am constantly trying to page through other apps by tapping where EinkBro's forward/back touch zones are. People who've used other ebook readers will be familiar with the general concept as most have similar features. Having to imprecisely scroll through a document or app is exceedingly painful.
Scrollbars partially solve this problem as for most, tapping above or below the cursor will advance the display by about a page of text (some feature a few percent overlap). On desktop systems, there's an even better option: the space bar. For a whole slew of apps and tools, dating back to Unix's pg, more, less, most, etc., you can page through a long text one screen at a time by tapping the space bar, which is the largest damned key (and hence the easiest-to-hit target) on the keyboard (Fitts's Law[2]).
By contrast, scrolling on mobile:
- Is highly subject to the tap-vs-drag confusion: the GUI cannot consistently distinguish a tap action (interacting with the application) with a drag (changing the viewpoint).
- Is imprecise both by contact point (that is where you're interacting with the display) and displacement amount (how far you're moving through a text or app). You might scroll by more or less than a page, and it takes considerable time for the eye to recapture the reading point.
- Obscures what it is you're interacting with. Your finger is covering the display you're trying to manipulate. A desktop mouse cursor by contrast covers little or none of the text or app.
- Is subject to further confusion based on dynamic characteristics of the document or app you're dealing with (e.g., a Web page with progressively-loaded or rendered elements, or on Mozilla Pocket, inconsistent placement and textblock wrapping around image elements).
I come to desperately hate scroll-based interfaces these days.
I personally like disappearing (or shrinking) scrollbars, given they appear when I scroll with a wheel, or approach towards them. It allows me to understand where I am, allows me to grab and scroll quickly when I approach them, and they allow me to see more content.
Yes, I use a big screen, but borderless and clean windows allows me to fit more content into the screen and is less distracting in general.
I respect your view. This why we (should) have options. For example, Safari doesn't auto-show scrollbars like Firefox does, and it hinders its usability a lot, if you ask me.
The user agent hasn't worked users in quite a while now. They've become optimized to work for the website owner. Scrollbar behaviour is one example of this, but so are user-hostile input fields (e.g. not being able to paste email addresses in email confirmation fields, not being able to paste passwords, autocomplete being disabled for some fields and being unable to override it, etc).
At this point, I would pay good money for an actual user agent that is worthy of the name.
But this works only if you have a scroll wheel. And then it works only vertically. Horizontally you still have to click on the invisible scrollbar. To see where you are in relation to the whole document.
In Firefox, when I start to move my mouse right, vertical scroll bar appears. Same is true for horizontal one when I move my mouse down. It happens even before I get closer to any of the scroll bars. So, a wheel/trackpad is not required per se.
Moreover, almost all mice I used except the most basic ones have horizontal scrolling capability.
I'm #notafan of customising site scrollbars. But I've written my own CSS to do that (used only on my own, non-public, Web pages), and man is it a breath of fucking fresh air.
There are other apps which are similarly fucked in this regard. Mozilla's Pocket comes to mind.
It's possible to essentially reimplement the logic of how scrollbars look, where they are, and when they appear, in just CSS on modern browsers.
Ended up having to do part of that once because it was easier at the time than to figure out just why a mismatched browser scrollbar would show up due to complex layouting issue (in embedded world, so we didn't actually have to worry about end user preference there, otherwise I wouldn't dare use such a hack)
As much as I hate what browser devs have done to scrollbars, I tend to agree with you. The one thing worse that fucked defaults is everyone throwing their own fucked personal preferences at you. Which is why sane defaults matter so damned much.
There are browser configuration tweaks which can be done in at least some cases. On Firefox Mobile / Fennec, for example, there's a configuration hack which can be done.
I'm having trouble tracking that down but I think this might be it:
Most of these progress bars are as thin as the native scrollbars have gotten (or thinner). If these are solely a consequence to the shrinking of the scrollbar, you'd imagine that they'd actually be bigger.
I think that's a large contributing factor, but either most implementations are are as deficient [0] as what they are trying to augment or there are other things at play here. (Branding since websites haven't been able to consistently style browser scrollbars since the IE/early Firefox era; as the other comment points out, trying to counterbalance how long pages have gotten with "after-content" such as ads and comments and recommended articles and "infinite scroll" to more articles.)
[0] Or arguably worse deficient: Most of them seem to have no real accessibility themselves and are opaque to things like screen readers. Even if modern scroll bars are hidden by default and woefully tiny visually by default, they still have decades of accessibility baked in and accessible options (if you can find them).
To add to this, pages sometimes have comments or footers or other bells and whistles after the content that I’m interested in and it makes me think the post is longer than it is. This leads me to either leave the post for later or straight up close it because it’s too long.
uBlock Origin's element blocker is ideal for removing those. You can define global rules for anything from Taboola, Outbrain, RevContent, etc., and never see them again.
"Sharedaddy" is another element to nuke (social link litter crap).
Whether or not either of these is user-hostile is up to interpretation and preference, but you're stating it as if it is objective fact.
You see user-hostile shrinking of the scrollbar, someone else sees more room for content and hiding something that isn't necessary until you need it. You see loading content piecemeal as hostile, someone else sees blocking that 1kb of text from being displayed while you do more network-intensive work as hostile.
The problem is either (a) the scrollbar is hidden and the software doesn't allow to make it visible always or (b) the web page assumes there is no visible scrollbar (or, (c), only a "see-through" overlay scrollbar) even if there is one.
To be fair, the author notes this and offers an alternative:
> One immediate thought is that this is completely superseded by the regular browser scroll bar that’s ever-present at the side of the page. However, the scroll bar could be deceiving. If your page has a comments section, the comments could make the page look dauntingly long. Similarly, references to other pages and general “footer material” count towards the scroll bar, but would not count towards the progress bar.
> Combining the two, you could imagine an always-visible table of contents that highlights the current section you’re in. With such a feature, you can always see where you are (including a rough estimate of how far into the page you’ve scrolled), and at the same time see how the current section integrates into the broader structure.
Exactly this. When you're reading different news sites, you never have any idea which sites load hundreds of comments at the bottom and which don't. What you think is a long article actually turns out to be 80% comments by page length.
The same thing happens with books that include references at the end — a print book can be 20% endnotes. I've even encountered bizarre EPUB's where for some incomprehensible reason there's a page break between each endnote, so the actual content of the book ends somewhere around the 5% mark of total page count.
I actually really appreciate a super-thin (2px) progress bar in the header.
I don't like an always-visible table of contents because I find it really distracting. But I really like the way Wikipedia does it in their app, where it's a single tap to reveal the table of contents full-screen, centered on and highlighting your current section.
That is a relevant point, although still it shouldn't be necessary; proper semantic HTML commands should allow the browser to handle it automatically (in the way subject to user preferences), e.g. the <ARTICLE> command can be used if you want to delimit the article from the comments, and with commands such as <H1>, <H2>, etc you can delimit sections and automatically make a table of contents.
The browser could use this information in various ways depending on the preferences of the user. One example is the scroll bar map mode implemented in various text editors where a scaled down version of the content is shown to help you see where you are. Similarly a browser could visualize the size and location of certain elements (e.g. <article> and <section>) on the scroll bar. The key here is that it is the browser doing it so that you have a choice in wheter you want it or not on all websites.
So do I, which is why it can be a user preference. (One way might be to display marks on the scroll bar for the top and bottom of the article, therefore giving you both advantages at once.)
+1 on finding progress bars distracting. I personally feel like they also "hurry" you into reading faster. If I see a progress bar, my first instinct is to try to finish as quickly as possible, even if that means a poorer understanding of the text.
>I really hate progress bars, they are incredibly distracting. One of the worst examples of front end programmers wasting their time reimplementing browser functions badly. I already have scroll bars! I do not need more scroll bars!
And the icing on the cake - as demonstrated in the quanta link - is the horizontal rendering in combination with a generous sticky wasting precious space I'd rather use for, well reading content.
Right, knowing the scroll position makes no sense for websites - it's yet another feature added for apps which should really have been declared out of scope of webbrowsers.
> I really hate progress bars, they are incredibly distracting. One of the worst examples of front end programmers wasting their time reimplementing browser functions badly. I already have scroll bars! I do not need more scroll bars!
I'm just really glad that we seem to have mostly moved past headers that expand down in front of the content you're trying to read as you scroll down the screen. I can't think of a single justifiable reason for this behavior, but it was all the rage for a while. Also, I suspect the progress bars resurged because browsers became enamored with invisible or barely-visible scroll bars.
> I really hate progress bars, they are incredibly distracting. One of the worst examples of front end programmers wasting their time reimplementing browser functions badly. I already have scroll bars! I do not need more scroll bars!
This is addressed though in the following paragraph (indirectly), where a table of contents is rendered on the side. (Similar is a minimap, which I like for code or complex articles, but not for long text-heavy articles.) Maybe you also hate that, but it actually serves a purpose that scrollbar can never replicate and is much more useful than a scrollbar for many people.
Funny, I quite like progress bars! I agree that they can be too bold at times, but it's nice to have a visual indicator since scroll bars have disappeared (especially on mobile).
I think horizontal progress bars are annoying but I think I'm fine with vertical progress bar to the side on heading navigation, highlighting the currently reading sub-heading.
One micro feature I implement on my blog that I would like to see everywhere: a single-page index of all the posts, like at https://blog.zorinaq.com
Don't paginate this. I want to see at a glance the titles of all the posts the author wrote. I want to be able to ctrl-f to search these titles. Heck, even if you had 100k titles they could still easily be shown on one page, as it would compress to 1 or 2MB transmitted on the wire which is still more lightweight than the average web page size.
Another reason: I'll often come across a blog post from 12 years where the author writes "in my next post, I'll continue to discuss..."
And how the heck am I supposed to find that next post? They didn't add a hyperlink, obviously, because they hadn't written it yet. Sometimes a blog has posts you can navigate by month, but that's definitely a small minority of blogs I come across.
If there was just a single-page index, I could Ctrl+F the title of the current article, and quickly see what followed it chronologically.
> Another reason: I'll often come across a blog post from 12 years where the author writes "in my next post, I'll continue to discuss..."
Worse than that is the "part 3" blog post, where the opening paragraph of part 3 starts out with something like:
In part 1 we discussed "...one or two sentences on part 1..." and in part 2 we discussed "...part 2 quick overview..." ...
And there are no links at all in part 3 to either of parts 1 or 2 (yet, presumably, part 3 was written after parts 1 and 2, so links back to 1 and 2 could have been inserted). If one came across part 3 from a search, and landed on it for the first time, one just might want to start at part 1 and read forward.
Which has the 10 or 20 most recent posts, but not the post from 12 years ago. If it's a wordpress blog, you can use pagination tricks to get older posts, but, AFAIK, there's no standard way to say "Give me all of the posts" when fetching the RSS feed.
These days an awful lot of blogs don't have RSS feeds.
Especially blogs that are part of broader news publications, in my experience.
But yes you're right when there is a feed you can open that in Chrome and Ctrl+F, at least.
(Obviously my complaints come from blogs that don't have this. But also, opening an XML file isn't exactly user-friendly, and 99% of end users would never know to do it.)
…okay sure, technically yes, but not one I will be able to follow, or remember to read until it pops up in someone else's aggregator or links in the future.
A single-page index of all posts is hands down the number one feature every blog should have. Also, no images to clutter the index, and slow down the page.
I mean, just make sure that your blog is easily consumed by any web search engine.
And in addition to the full non-paginated index, I also have a full non-paginated tags page. Like categories, but with pages showing multiple times if they have multiple tags.
My pet feature I'll try to add is sidenotes. It does annoys me to jump back and forth to read them. Even as a popup (wikipedia style), it is still intrusive...
> One micro feature I implement on my blog that I would like to see everywhere: a single-page index of all the posts
I've got a variant of this on my own blog [1]. Full site contents generated automatically from (and grouped by) the content's tags.
To avoid the appearance of self-promotion, I'll balance this with an up-front warning that the actual content makes the opportunity cost of visiting debatable unless you're really curious ...
2013, Bitcoin hits $1k: https://blog.zorinaq.com/1-bitcoin-1000-us-dollars/ "Sure a crash that would bring it back down to below $1,000 is possible or likely, but it would not change its long-term prospect, a few years from now, from being valued between $5,000 and $50,000 and possibly more."
It's comforting to see blogging as a topic on HN front page, along with plenty of constructive comments. I'll take some of the ideas on board.
I've been working on a blogging service myself (here's my blog on it https://lmno.lol/alvaro), focusing on minimalism, hopefully enabling the content to shine on any kind of device (you can read from your favorite terminal too).
Service hasn't officially launched. You can play with https://lmno.lol (ephemeral posts) without signing up. Reach out if you'd like to register a blog (invite at lmno.lol).
ps. ASCII art is not displaying properly on Android (known issue). So far, I can only fix by including a monospace font. I'd love to know if this is still possible to fix using system fonts.
Nice list! I like many of these "microfeatures" too. Some I have on my site (https://evalapply.org), some I don't because I don't want to require Javascript for blog functionality. I think I have a few others not in that list.
This is my set of "microfeatures", which are all available in the post I linked below [1].
- All posts must have title, summary, dates (published, updated), one tag at least, and hot link to top of post (it's always #main)
- Open graph metadata for all pages (title + summary)
- All first-party content must be accessible as plain HTML
- Typography and separator elements to establish structure and distinguish functionally different areas of content
- In-page navigation (especially jump links to and from footnotes)
- Table of contents when needed, in a disclosure element
- Custom navigation to group a series of posts
- Markers for external links
- Captions for images and embeds
- Disclosure elements for extra context
- Footnotes (with links back to the referring text)
- Index pages with summaries (the main blog index, and each tag's index)
- RSS feed (global)
So far I'm reasonably happy with things as they are. At some point I'd like to participate in a webring.
What I notice reading some of features is that Markdown is insufficient for that. For example Markdown dosen't support captions or side notes. AsciiDoc would be a much better fit for such cases.
On the web, I like footnotes more provided they link back to the referencing text. On my blog, I love to use footnotes for little tangents and asides, apart from their usual task of providing references. Not every post/article needs them.
Sidenotes are cool, but they are a skeuomorphism not amenable to fluid layouts. I feel plain vanilla in-line disclosure elements work better, and they might be better for accessibility too.
In dead tree books, I enjoy both. Marginalia can elevate the text. Footnotes are always in context of the whole page, which I can view all at once. No scrolling needed.
Sidenotes can't be on the side on a small screen. You have to put them in between paragraphs, at which point they stop being sidenotes and just become part of the text. Then, how do you handle them in your RSS feed? What happens if the reader clicks on the reader view button in their browser?
Footnotes always remain footnotes, regardless of all of that.
Link previews don't really work on mobile. Also they just create UI land mines. If I mouse over some area of the page I have unexpected content jump up. If a link preview hits the external link that's also potentially leaking traffic or tracking data from me.
Maybe it's just me, but I'm not so much of a fan of Dialogs as demonstrated here, especially when there are a lot of characters, each of which have a different role that is only communicated by going to a separate page to read about them. If I wanted to explain something in an article I was writing, I would just explain it in the same way I'd do everything else, with a separate paragraph, maybe with some links to relevant sources that I used to become familiar with the topic too
It takes a lot of skill on the part of the author - I don't think I'd risk it personally.
But I like the way it's handled on fasterthanli.me enormously - the author there successfully anticipates a lot of my "wait, but..." thoughts and addresses them directly via this mechanism, or, conversely, makes me realise that I ought to have had an objection to the point they're making.
I've just read a couple of their articles, and I think an aside works nicely, just a note about something, but a full on dialog is a bit much. I suppose a lot of my concern was with how Xe Iaso does it, where it just feels over the top and unnecessary, and IMO distracts from the actual content of the article, which is otherwise largely enjoyable
It is a very hard thing to calibrate. I try to have my internal conflicts and the like get put onto the canvas. I imagine that part of the perceived distraction is because of the CSS being bad (I suck at CSS so much). I'll go dig through a few Tailwind examples and see if I can make the messages more compact.
Well I didn't expect you to actually read this haha. I hope I didn't cause any offence, I just struggle to keep your wide character roster in my head with all their specialised roles. The only reason I mentioned you specifically was because I was familiar with you as an example and the source mentioned you, I'm sure others do this to an even larger extent
Yeah, I try to compensate for this with a few rules that I undoubtedly fuck up:
* Each character has very visually distinct designs (ideally each is as distinct as I can reasonably make them, to the point where I have different artists do each one)
* The names have meaning (Aoi means blue, Aoi's hair is blue)
* Each character has an archetype that corresponds to a facet of how I understand technology, and their interactions are intended to reflect those internal disagreements or touch on the intentionally placed "learning lies" (the simplifications of how things work intended to give people a starting point for understanding an abstract thing that can later be discarded when they dig into the details and realize that shit's actually complicated)
I've been idly considering adding something to the message footer in faint text with a tl;dr like "(the student)" for Aoi, or "(the well-intentioned forum troll)" for Numa. Would that help?
I originally was kinda hesitant to do this under the axiom that if you have to explain your art, you fucked it up. I'm willing to concede that it's probably a bad axiom for me to follow here.
I was going to suggest having hover text for the characters that just summarises what you already have in the separate bios page, but I've just remembered that doesn't work on mobile haha. Adding faint text might help, though you have to keep accessibility contrast guidelines in mind :P Ultimately, this is just my viewpoint, and your website, so you should do what you feel is best haha
Dialogs are definitely an interesting form of writing, especially for technical writing. On the one hand, it's a deeply natural format with a long and complex history (the Socratic Method, especially, but certainly not alone). On the other hand, we've long disassociated it from "professional writing" which is to supposed to only have one proscribed argument and one direct viewpoint (likely, but not always, the author's).
Somewhere in the middle, is decades of the "…for Dummies" technical manual formula and its stock dialog characters and the love affair many had (or still have) with "The Poignant Guide to Ruby".
Dialogs can definitely be hard to read in the context of just reading a single blog post because you don't have a familiarity with that author's characters and most blog authors don't have a "shared universe" of characters. I wonder if there's an interesting world where for instance the Dummies characters were considered to be public domain at the right time or more blog writers felt confident with _why's unique voices to turn Poignant's characters into a modern "Punch & Judy" for technical writing. The Socratic Method worked because everyone had a shared intuition on the characters of the day (in part because many were famous Senators and/or Wrestlers): Plato, Socrates, Aristotle, etc. (Also, Plato was his wrestling name, these were absolutely characters.) Maybe if we want to use more Dialogs in blog posts easily we need better shared characters?
I'd always thought that inline dialogs with fictional characters were more for the author's entertainment than the reader's, so I was surprised OP and others in the thread like them.
I have nothing against them if people like them; just a matter of taste.
Agreed. I can rarely identify with the character(s) I’m supposed to identify with, and it’s virtually always a tedious read.
It’s also possible to use a question-answer style without having a dialog and characters. What would that look like? Well, similar to this very paragraph. Not that I would particularly recommend it either.
The microfeature I like is when posts have the full date. Blog authors want their content to be evergreen so they try to exclude it. Context is essential for me to interpret the perspective, especially for technical content. I end up having to go to the internet archive to see an estimate of when they wrote it anyway.
What I find so weird is that this is omitted from scientific papers as well. It's like not giving it a title (you just have to read its contents to see if you are interested in it) or omitting the number of study participants (who cares about the N, you just have to reproduce it to see if it's still relevant)
Almost all of these are pretty nice. I disagree with the preview-on-hover though. That sends off a request to a possibly unknown (possibly unwanted) destination. I often hover a link to look at what the URL popup says in the bottom corner, before following it. It's just not a very privacy-conscious feature, even if convenient.
With modern Content Security Policy restrictions and such most sites now have, previews almost entirely have to be implemented server side to make them work anyway, so no real privacy fears.
For some use cases (eg editing Wikipedia, so being able to see if something linked is a stub or not say) its useful, but not i think in general for external sites.
I've seen link preview solutions start to appear that I would assume are doing some basic moderation and logic to ensure consistency. I've recently seen on product hunt - Linkz.ai link previews SaaS .
Since this article mention's Gwern's site several times:
While I admire Gwern's work a lot, I often find his website is trying to do so much that my browser will really struggle. Especially on mobile. It's bad enough I usually avoid reading there, which is a shame.
I'm not sure exactly what causes it, but it might be a combination of page length with many layers of nested, richly formatted and embedded content.
It's an impressive looking site IMHO; but pretty much everything he's done is very user hostile and wasteful of the user's resources, like downloading 14 fonts.
He's doing everything you're not supposed to do if you care about your users or performance in general.
Every page is pretty much like this.
From cssstats.com:
Rules: 1,484
Selectors: 1,757
Declarations: 3,914
Properties: 243
Total Selectors by Type
Selectors are the part of a CSS ruleset that describes what elements in a document the rule will match.
I don't think any of the numbers you quote are really that meaningful. Like you are quoting IDs - what is the cost of an ID? If all the IDs were stripped, would that even make a measurable difference? Really now.
Similarly for those other numbers about selectors or classes. How much of a performance burden are those, really? Not the numbers punched out by some cargo cult calculator tool - what is the actual impact?
(I would try to compare cssstats.com's numbers for Gwern.net to sites we can all agree are "very user hostile and wasteful of the user's resources", like Medium.com or Substack... except it breaks and won't even report numbers.)
> It's an impressive looking site IMHO; but pretty much everything he's done is very user hostile and wasteful of the user's resources,
That seems like an extreme take. 'Pretty much everything'? There's no feature you like or find useful? It's all a waste? Your non-wasteful user-friendly version of gwern.net just throws out everything like the dropcaps, the code folding, the popups, the transclusions, the sidenotes, the backlinks, the link-icons...?
If that's not what you mean, can you point to a website which comes anywhere near Gwern.net in terms of supporting reading long, complex, heavily hyperlinked & annotated documents, and clearly outperforms it browser-wise?
> like downloading 14 fonts.
I'm not sure what page you are looking at, but what are these '14 fonts', exactly? It sounds like you're counting every font file without looking at them at all, and you are including, eg, the dropcaps which are subset to 1 letter per font file and so are efficiently only ~1-10kb each, or the link-icon font file, which is like 5kb compressed and saves requesting a bunch of SVG icon files, or the Quivira fallback (to avoid box Unicode garbage) which shouldn't be used in most pages but if it is, that's fine, because it's all of 3.5kb. Surely any performance woes do not come from downloading 5kb to draw a fancy 'A' at the beginning of the article, and is worth it for such a signature bit of visual style...
Even the regular font files are subsetted to save space. (I wouldn't be surprised if there are a lot of websites with just '1 font' which weigh more than those '14'.) So the font files do not seem like they are 'wasteful' to me.
The site design and content are great; the execution, not so much.
I only investigated because someone in the thread mentioned they had a bad experience on a smartphone; now I know why.
Each font is another HTTPS request to the server; doesn't matter if they're subsetted or not. However, the combination of all the JavaScript and the multiple CSS files creates a total blocking time [1] of 5266 ms according to WebPageTest.
The page is blocked from rendering for over 5 seconds due to all of the crap he's downloading and the way he's doing it.
I didn't count where he downloaded one character out a font by subsetting. There are actually 30 @font-face declarations for fonts, some subsetted and some not.
Where he saved on downloading fonts, he used it up (and more) on the JavaScript and the CSS.
Someone using a browser that doesn't support the latest HTTP 3.0 protocol on a fast connection isn't going to have a good experience.
Source Sans Pro is available as a variable font; instead of downloading each individual weight, he could have downloaded just a couple of files and have all of the weights.
Ironically, after all that, he didn't pick a font that supported true small caps; he's using synthetic small caps, which don't look as good. There are plenty of high-quality free fonts with true small caps. It doesn't make sense.
The experience isn't good on mobile; it's not cool to have those previews keep popping up that I didn't ask for and that icon bar is inappropriate for small screens.
He has dozens and dozens of media queries; how about let's not download the crap I don't need on mobile? If I'm on smartphone, I don't want the drop caps and the other flourishes that only make sense on desktop/laptop sized displays.
Like the fake small caps, the typography doesn't look great on a smaller, high resolution screen.
A little knowledge can be a dangerous thing; his code is full of selectors like this:
.TOC > ul ul ul ul ul ul > li::before {
counter-increment: htoc_6;
content: counter(htoc_1) "." counter(htoc_2) "." counter(htoc_3)
"." counter(htoc_4) "." counter(htoc_5) "." counter(htoc_6) "\2006 ";
}
Among other things, it's so specific, making it very fragile; it also explains why his CSS is so bloated because there are hundreds of lines just like this. As you can see from the Lighthouse report, he doesn't bother to minify his CSS or JavaScript.
Sure, for anyone on a recent device on a fast connection, it won't make a difference. But others on slower connections and older machines are going to wait noticeably longer and use more battery just to download and render his content. Hell, you could be on an iPhone 15 Pro in the middle of nowhere where all of you have access to is 3G or similar. Or on shitty coffeeshop wifi.
I left out the information from Lighthouse because I thought it was too inflammatory for HNers, but here goes:
On a scale 0-100, the performance score is a failing 44
First Contentful Paint 2.1 s
Largest Contentful Paint 2.6 s
Total Blocking Time 3,290 ms
Cumulative Layout Shift 0.461
Speed Index 3.6 s
Eliminate render-blocking resources Potential savings of 1,160 ms
Minify CSS Potential savings of 20 KiB
Minify JavaScript Potential savings of 82 KiB
Reduce unused CSS Potential savings of 52 KiB
Reduce initial server response time Root document took 680 ms
Avoid an excessive DOM size 1,555 elements
> The site design and content are great; the execution, not so much.
As I mentioned, I think it would be helpful to link an example (even just one) of a website you think is executed correctly and does similar things but much better.
> the multiple CSS files creates a total blocking time [1] of 5266 ms according to WebPageTest...The page is blocked from rendering for over 5 seconds due to all of the crap he's downloading and the way he's doing it.
I don't think that is what total blocking time means... You can see that just loading the page, or looking at the Pagespeed strips. To quote your own reference: "The Total Blocking Time (TBT) metric measures the total amount of time after First Contentful Paint (FCP) where the main thread was blocked for long enough to prevent input responsiveness." It is not blocked 'from rendering for over 5 seconds'. I would agree that not rendering for 5 seconds would be a bad thing. But it is not what that number means, because it is defined as after first rendering, and about something else entirely (user input).
> He has dozens and dozens of media queries; how about let's not download the crap I don't need on mobile? If I'm on smartphone, I don't want the drop caps and the other flourishes that only make sense on desktop/laptop sized displays.
Uh, no? There are reasons that user-agent sniffing is highly deprecated. Because if you snoop the user-agent (I'm not sure how else you propose that that crap not be downloaded), that is crack and aids, and extremely bad and fragile: even if you somehow mapped all user-agents to date to their full sets of undocumented unstandardized media-query equivalents, it will break with the next user-agent or browser decision to spoof user-agents for privacy etc and stop exactly this sort of snooping... It also means that you've broken responsiveness: if the user resizes the page, now everything breaks because they don't have the newly-matching media-queries.
This also underrates the difficulty of getting mobile/smartphone right. We have had problem after problem with iPads and iPhones, and that's with using media-queries which are supposedly supported & standardized; some sort of server snooping would be even worse. (Leaving aside the issue that it would be hard to implement this to begin with on a static website.)
> Ironically, after all that, he didn't pick a font that supported true small caps; he's using synthetic small caps, which don't look as good. There are plenty of high-quality free fonts with true small caps. It doesn't make sense.
Huh? We do use a high-quality free font with true smallcaps, Source Serif Pro and Sans. That in fact was a major reason we picked the Source family: because Frank did true smallcaps for it.
I am also not sure we actually need the new variable fonts for Sans, since we don't use much Sans.
> Like the fake small caps, the typography doesn't look great on a smaller, high resolution screen.
How so? I'm wondering if you broke the site with a plugin or something, if you think we are using 'fake smallcaps' and that it looks bad on high resolution screens...
> The experience isn't good on mobile; it's not cool to have those previews keep popping up that I didn't ask for
Obviously, I very strongly disagree that the previews are useless for reading my site, and I'm puzzled by the idea that there are people who are tapping away at links on smartphones and want them to open up the full link when smartphones barely even support tabbed browsing, but are frustrated by seeing excerpts or summaries instead and getting access to cleaned compressed archived snapshots etc.
However, for those who dislike them, they can be disabled by a single tap of the only icon attached to a preview (besides the 'X' to close it), the struck-eye icon, which is widely understood to indicate hiding/disabling things.
> and that icon bar is inappropriate for small screens.
I'm not sure what you mean by 'icon bar'. If you mean the theme toggle in the right-hand corner, which provides controls like 'disable previews', then it is not inappropriate; we started with a smaller toggle bar, but I and other users found that anything smaller is hard to interact with because the tap targets are too small.
> Among other things, it's so specific, making it very fragile; it also explains why his CSS is so bloated because there are hundreds of lines just like this.
Sometimes you need to be specific. You don't establish that that CSS is unnecessary to achieve the goal. (This is where a comparable site would be especially helpful in critique.)
> As you can see from the Lighthouse report, he doesn't bother to minify his CSS or JavaScript.
Whatever Pagespeed or Lighthouse might say, we haven't found minification to be a big benefit when we turn it on. And we have found it to make debugging harder and also sometimes break the site. (Cloudflare choked on, IIRC, inlined SVG at one point, completely breaking the site. That was fun to figure out.)
> Whatever Pagespeed or Lighthouse might say, we haven't found minification to be a big benefit when we turn it on.
Minify CSS Potential savings of 20 KiB
Minify JavaScript Potential savings of 82 KiB
The benefit is less data going over the wire. I get it--100 KiB doesn't sound like much these days, especially given the page weight of almost 800 KiB. But it's still an extra 100 KiB that doesn't need to be transferred and it adds up over time.
If you minimized your code and did a few more optimizations, you're talking about a more significant amount of data you could be saving your viewers.
> Sometimes you need to be specific. You don't establish that that CSS is unnecessary to achieve the goal.
That selector and the many others like it is a sign of poor CSS architecture. If your design results in you having to be that specific, it means you're doing something wrong.
It's a classic case of fighting the cascade instead of having it work for you. If there was an architecture (like ITCSS or OOCSS for example) [1], you wouldn't need to write such a deeply nested selector in the first place and the dozens more just like it.
Creating reusable components in CSS would reduce the amount of code dramatically and make it much easier to maintain.
> The benefit is less data going over the wire. I get it--100 KiB doesn't sound like much these days, especially given the page weight of almost 800 KiB. But it's still an extra 100 KiB that doesn't need to be transferred and it adds up over time.
How much does that save, after the Brotli compression, and how much does it contribute to your supposed TTB? And why would it affect the page performance once loaded? And how does your alternate of CSS grids change that? If it is responsive, it is still going to have to define a bunch of CSS to explain what the layout is and how it changes.
> If your design results in you having to be that specific, it means you're doing something wrong.
Does it really? You keep making these assertions like 'you're using fake smallcaps' and then not backing them or explaining them, or giving any examples whatsoever of a site doing it right.
> Uh, no? There are reasons that user-agent sniffing is highly deprecated.
I never mentioned user-agent sniffing nor would I ever recommend this outdated technique.
Using media queries for responsive design became a thing in 2010 with Ethan Marcotte's seminal article "Responsive Web Design" [1].
In the intervening 14 years, we have much better ways of adapting to different screen sizes. In fact, using CSS Grid for layout as it was intended results in responsive layouts without media queries and breakpoints.
Watch Jen Simmons' videos on intrinsic design [2] for the full run-down.
This seems to be a bait-and-switch argument. I can't see how any grid feature can handle all of the media-query things you highlighted as wasteful bloat like "the drop caps and the other flourishes". How does that handle dropcaps, sidenotes & margin-notes, popups vs popovers, utility classes like disabling on mobile vs desktop, the different styling of the header, plus all of the small adjusts like fonts or line-heights or justification...?
Nothing in your first link addresses that, and this grid approach sounds limited to just moving a few blocks around to be a rectangle instead of a square or something. (Like, I am looking at random moments in these 5 hours of videos, and it all seems to be like that, like "What do CSS features like CSS Grid, Flexbox, Multicolumn, Flow layout and Writing Modes mean for our design medium"? Well, for Gwern.net - they mean little. Most of the media queries have nothing to do with putting something into various kinds of grids...)
How is this is a general replacement for media-queries - as opposed to a minor technique good for rearranging some carousels or some columns?
Again, I think you would benefit from being specific. How, exactly, does CSS Grid free us from media queries and breakpoints for the things we use media queries & breakpoints for, like dropcaps or switching between popups & popovers? And what is an example of a site which uses just CSS Grid for all this and avoids downloading all that crap as you desire?
Dan's is the only one I recall visiting before. And it's memorable because of the maximally wide text width. Personally I would find Dan's site more usable, and visitable, if there was an ordinary text width. Some reasonable default that is more readable.
The "danluu layout" takes minimalism too far in my opinion, and getting in and out of some readability mode can be slow/annoying.
Just a lil bit of padding here and there could improve the presentation a lot, but I'm guessing the author consider this design kind of a trademark by now.
I don't mind Drew or Fabien's layout, which have a reasonable column width. But Dan's site is unreadable for me (at least on desktop) without reader mode. What would be the reason for choosing to have full-width text on a blog?
Dan's website is a great example of the pendulum swinging in the other direction to malicious non-conformism. Yes, UXers have made modern web design hell, but presenting a raw unstyled html isn't respecting your user much either.
I think that is not so simple to solve. Limit it to some column width? Someone will complain that it only uses one third of their screen. Unlimited width? Someone will complain about whole width text. But the good thing is, that there is reader mode and evem if there wasn't, you could zoom in or resize the browser window or send to new window and resoze only that.
Yeah, most browsers do have reader mode now. I honestly don't love them because they're typically not customizable, and are sometimes too narrow for my taste.
I wouldn't mind resizing the browser window except that with tabbed systems that means you're resizing all of the tabs at the same time.
I tend to think that if you make the width something in the neighborhood of what the NYT, Medium, or other well-known sites use, people won't complain. But I could be wrong!
Firefox reader mode is a little bit customizable. Font size column width and so.
Cumbersome, but one can change width of a single tab by using the inspector and using the responsive design mode.
Perhaps there is room for another Firefox feature to limit width of a page. Perhaps multi-column mode, where one can for example split the page in 3 columns and each column displays, what could not be fit on the previous column. And resizable columns maybe.
Huh: my browser is always maximized (the width of my monitor) as are all the other apps I regularly use -- similar to how an iPad worked before iPadOS introduced multitasking -- but then I'm scaling the UI by a factor of 200% and its not a HiDPI monitor, just a humble 1080p one, so the effective horizontal resolution of my browser's viewport is 960 pixels. At that resolution, line of text on danluu.com and in comment sections on HN are longer than
I would prefer them to be, but they're not so long as to be a significant annoyance.
Back when I used an OS that didn't let me scale the UI, I'd occasionally make the browser window narrower to make the lines of text on a site more reasonable, but I definitely appreciated it when sites made it unnecessary for me to do that, by specifying body {max-width: 45em;} or something.
I don't think Gwern's site is optimized for mobile viewing at all. It works great on a desktop and I think that's where such long form is best consumed.
Yeah, it used to be fast, but then you add features and have pages with a ridiculous amount of stuff in them compared to most pages (every DOM element costs you), and, well...
We plan to go back and optimize stuff once one last feature is in. (It's a novel feature I came up with I've never seen anywhere else: I call it the 'browsing history' feature. Every link you pop up will also be transcluded into a section at the end, so you can create your own bibliography as you go. This means you don't have to have FOMO about reading every popup or tab as you go, and you can rebrowse what might be interesting at the end, or even snapshot the page with a particular set of links having been browsed.)
Achmiz meant to get around to it a while ago but among other things, he got nerdsniped by studying high-dimensional geometry for modeling an extradimensional invasion in his current D&D campaign: https://blog.obormot.net/Extreme-D-D-DIY-adventures-in-hyper...
If you start from scratch, factor it in when deciding on a cms, platform or site generator. I think RSS/atom owes a lot to WordPress, which has it enabled by default since ages.
When you want to add it retro-actively, the specifications are relatively straight forward and don't have many mandatory properties. RSS is a tad simple than Atom, but I'd probably rather go for Atom if I were to start over.
Also, JSON Feed [0] is still better than nothing, many of the major RSS readers quietly support it, and does have the small advantage that JSON is much easier to work with in more platforms than XML today.
Most CMS/blog apps have it built in. You might need to look up how to enable it (Drupal) or you might already have it enabled, even if you don't realize it (Wordpress). Check the documentation for your blogging/site content framework of choice.
If you're super old school and do an actual manual HTML site, just create the RSS file and add entries to it, then link to it. This is well documented and not in any way complex. It's just a text file, after all.
> If you're super old school and do an actual manual HTML site, just create the RSS file and add entries to it, then link to it.
Make use to add an <link rel="alternate" type="application/rss+xml" href="feed.rss"> element and not just a normal hyperlink so that users can just paste your blog URL into their feed reader to subscribe without having to search for the feed link. Ideally this should be present in the page for both the index as well as every article.
That's OK though - it should be enough for text content. I think it's also OK to just have the RSS feed contain the title and summary of the article since I prefer to read the content in my browser anyway - but there are definitely different opinions here.
I might cop a lot of hate for saying this, but it's been 10 years, it's time to stop mourning RSS and move on.
I loved RSS, I sorely miss the protocol based internet rather than the web based internet we have now. I miss when my emails didn't have adverts pretending to be emails at the top of my inbox.
Advertising was a lot less prevalent when applications had protocols and you could simply move to a different client with fewer (or no) adverts.
WHOA! This is shocking ignorance for an HN user. RSS still exists for most of the web if you can be bothered to use it. It just isn't in your face anymore. I consume a lot of content through RSS to this day. You also don't need to look at those email adverts if you can be bothered to use real email apps. It's your choice to soak yourself in the dumbed down garbage interfaces.
They are not ignorant just for holding a different opinion.
My entire reading system is built on RSS but I don’t think it’s an invalid take to say that RSS is a thing of the past, or at the very least that the train has left the station. Every month I have some feed just randomly die because nobody paid attention or cares anymore. It’s pretty unfortunate.
Browsers should never have backed off exposing it, IMO.
> They are not ignorant just for holding a different opinion.
No, but this isn't a contest of opinions. The claim that RSS unsupported, no longer in widespread use, and/or is merely a remnant of a previous era is factually incorrect.
> don’t think it’s an invalid take to say that RSS is a thing of the past
Sorry, but it's an invalid take. I don't know what sites you're using that stopped offering RSS, but I have hundreds of blogs, podcasts, and aggregators, along with my favorite subrreddits, YouTube channels, etc. all subscribed via RSS, and the only time anything "dies" is when a blog or podcast changes its URL.
> The claim that RSS unsupported, no longer in widespread use, and/or is merely a remnant of a previous era is factually incorrect.
I did not say they were factually correct, merely that I'd lump RSS in with "things of the past" given how many sites and developers neglect it nowadays. I was pretty clearly saying that their opinion isn't unfathomable to me.
The slow decline of RSS is not some new topic and this very site has discussed the topic for the better part of a decade. You're free to feel whatever you'd like tho.
> I did not say they were factually correct, merely that I'd lump RSS in with "things of the past" given how many sites and developers neglect it nowadays.
I mean, I assume that number must be greater than zero, and yet I seem to be having a hard time identifying any sites or blogging applications that do indeed neglect RSS. All of the sites I frequent support it. Do you have any meaningful examples of this alleged lack of widespread RSS support?
> The slow decline of RSS is not some new topic
Unfortunately not -- people have been pretending it's happening for years without any real evidence to sustain the claim. If I were more of a conspiracy theorist, I'd suspect that maybe it's something they're trying to make happen.
In this case "moving on" means adding in social media "share beacons", which just so happens to load their 3rd party cookies and analytics scripts, and shuttle that web traffic information back to the motherships.
> I might cop a lot of hate for saying this, but it's been 10 years, it's time to stop mourning RSS and move on.
I can't comprehend where this notion that RSS is somehow "dead" is coming from. RSS is ubiquitous: every major blogging platform, aggregator, and other media site continues to offer feeds, including all of the major video sharing sites. The entire podcasting ecosystem is based on RSS.
I consume HN, Reddit, Lobste.rs, about a hundred blogs, a hundred podcasts, YouTube and lots of other sui generis stuff all via RSS feeds, subscribed in TT-RSS with Liferea as a frontend.
RSS hasn't gone away and is not going away.
> I loved RSS, I sorely miss the protocol based internet rather than the web based internet we have now.
It hasn't gone anywhere. If you miss it, consider the possibility that you yourself have followed the garden path away from it, and forgotten the way back.
Yeah I subscribe to everything from major tech news sites (Ars Technica, The Verge for example) to tiny blogs. RSS is very widely adopted, even if nobody is making noise about it or trying to hype it up. Anything but dead.
This take, popular though it is, seems to be more vibes-based than reality based. Most blogs I visit have RSS feeds. The site we’re both currently posting on has a fully functional RSS feed. It’s hardly dead.
I always thought HN doesn't have RSS, that's why https://hnrss.org was created if I'm not mistaken. I just saw there is actually a feed for the main page.
Most of my media content is podcasts, and I still consume all of my podcasts via RSS feeds. I have yet to run into a podcast where this did not work. RSS isn't the past, it's the future, and painting it as dead is an odd characterization in my view when it's alive and well.
> and I still consume all of my podcasts via RSS feeds.
Considering that a podcast is an RSS feed, it's not like there's any other option. People using fancy modern podcast apps might not be interacting with the RSS feed directly, but the software they're using certainly is.
Spotify exclusive "podcasts" aren't really podcasts any longer. They're Spotify Exclusive Content calling themselves something that's no longer valid. The same is true of any platform exclusive content.
The world's most popular podcast used to be The Joe Rogan Experience, but since Spotify acquired exclusive rights to it, it is no longer distributed as a podcast, and is only available as a Spotify channel. Despite continuing to call it a "podcast", it isn't actually a podcast anymore.
OpenRSS is a service that creates RSS feeds using web scraping. Unfortunately, it can't create enclosure links for audio content that's sitting behind Spotify's paywall, so this isn't a podcast feed.
JRE simply isn't a podcast anymore. It's just a Spotify channel.
Most major websites continue to offer RSS. Considering that some people apparently believed that HN itself did not have RSS, I suspect that some people just don't know where to look for feed URLs.
Time to move on to what? Time to move back to everything being a chaotic jungle of different designs & experiences? I think not. Even if sites themselves don't support rss, there's many tools out there to help res-ify various sources. If there was a way to move on maybe we might eventually drop rss/atom, but it seems highly highly unlikely we'll move back from rss.
I love the web & it's great solid platform. But rss holds a special place in my heart too. Calling rss "not the reality of the modern web", saying that we should just except captive experiences by the valent forces doesn't seem very web-like to me, doesn't bespeaks the user-agency that so critically distinguishes the web from everything else. The internet is for end users, rfc8890, and rss is a strong manifestation of that value.
If we do want to move on we have to make that new place.
Nowadays it's like every single blog and website will "popup" something everytime i select text. It annoys me to no end, because I select text as I read along and it's incredibly annoying.
Whether be it ChatGPT, medium articles, and recently even Google search!
UBlock Origin allows you to block JavaScript by default on all websites, and it's what I do. And Firefox has something called reader mode. Absolutely fantastic tools.
If you don't want to outright block all JavaScript you can just block 3rd party scripts, it usually lets you see if the website uses some fuckery or not.
I don't like side notes. It tries to separate the readers to two groups---one who wants more details and the other who doesn't, but the problem is that there's no such natural division.
When I read articles with side notes, I often find myself constantly checking the side notes and then regret doing it because the info is unnecessary. I prefer the author to carefully think through and choose what info to present instead of just dumping info to the side notes.
I think that just means the author is writing bad side notes. Structurally, they do have a place. You said that yourself - "I do like to see details and I'm curious". An author moving all their side notes into the main content would not make it clearer. An author deleting their useless side notes would make it clearer. Neither of those speak to the usefulness of side notes.
I use them a lot on allaboutberlin.com, because some readers are familiar with certain things and others are not. This lets me serve both audiences while keeping the guides short and straightforward.
I very rarely use footnotes except for citations, unless it's a precision that would be useless to all but the most erudite readers.
I treat sidenotes/footnotes like parenthetical expressions - too many are distracting. A strong writer should be able to convey his thoughts and asides without interrupting the flow of text.
But I'm not sure they can be eliminated entirely. At least sidenotes make use of empty space on wide screens.
The thing is, I do like to see details and I'm curious. That's why I check them in the first place. But we can't know beforehand whether it's useful or not.
This is true for both footnote and side note, but for footnotes I can give it a glance to see if I want to read it thoroughly after reading the whole page, whereas for side notes, they are so easy and tempting to be seen. I feel the point of notes is that they do not interrupt the main flow but side notes put them on almost equal footing in terms of attracting attention as the main content.
Besides, footnote/side notes should be kept minimal, otherwise the note becomes the main content. I find articles with side notes often overuse them. Yeah, if they are kept minimal I guess both approaches are fine.
There are some authors whose footnotes (even sometimes indices) I read before the main content, because in the past they've hidden all the best bits there.
I like most of these, but I'm on the fence about Link Preview. I find it gets in the way as often as it helps me. I end up triggering it by accident quite a bit, and especially the wikipedia version where there's no X in the corner to dismiss the preview can become annoying. The footnote pop-up bubble on substack can have the same problem.
On a slow and unreliable connection, it's also one more thing that I wish had a toggle to turn off.
Related to this, something I consider an anti-feature: any form of messing with a link to a different page that results in Control+Click not opening a new tab. Bonus negative points if you've scripted it to redirect the page in the current tab and there's no very good reason for it to be a single-page application (draw.io has a reason, the average blog does not).
Feels like many of these features should just be built into the browser. Why can’t the browser assemble a table of contents based on header hierarchy? Isn’t that the point of the number in h1-h6? Why aren’t elements with ids easy to link to by default? Add a “copy-link-to” to the standard context menu in the browser. Etc.
It feels like browsers over the decades have moved away from catering to power users.
Is something like Arc moving back? Without having used it (I plan to at some point), I've heard that at least its tab management seems catered towards "professional browser users".
I like the way Cory Doctorow puts it in this piece:
> A web browser that's a "user agent" is a comforting thought. An agent's job is to serve you and your interests. When you tell it to fetch a web-page, your agent should figure out how to get that page, make sense of the code that's embedded in it, and render the page in a way that represents its best guess of how you'd like the page seen.
Table of contents is the feature that, in my opinion, ought to be implemented as a part of the web browser instead of within the document (I was told that Dillo apparently did at one time (but no longer does, although I suggested to them to add it again), and it is commonly implemented in Gemini browsers, though). This would also be true of page progress, linkable headings (the document author would need to give it a ID, although the browser should then handle the rest), link preview, and markers for external links. This should also be true of fonts and colours, too; the document author should not need to specify them. Some of the other things they mention, are things that would be helpful for the document author to handle, though.
Printing CSS doesn't get enough love. The ability to easily create a PDF for later, or to simply print the blog post on a piece of paper to read it outdoors is something I value.
Also, I'm confused about some points. For example, is progress meter really necessary? I mean, isn't the scrollbar a good indicator for the progress?
The scrollbar is not reliable. On Apple platforms, they hide the scrollbar unless you’re scrolling. I think CSS lets us specify that it should be visible on our own pages, but I don’t know how that interacts through browsers to the native behavior.
> (btw, just checked for Firefox and Safari, and the scrollbar is visible at all times, unless the website explicitly hides it)
There is a setting for this called "Always show scrollbars" and I know it defaults to off for me. The underlying about:config rule is specific to GTK though, so this may be platform-specific.
I was checking this on macOS. I have system scrollbar setting set to "automatic". Never changed scrollbar settings in Safari/Firefox, so it works like this for me by default, not sure why.
But also I don't really get how people are fine with hiding the scrollbar, but prefering to see the progress meter always visible for text, when the scrollbar conveys mostly the same information (except some edge cases when the footer is long I guess).
Not that it's important at all, I'm just at loss and it's not the first time I'm getting a signal that sometimes I simply don't understand people. But of course that's fine.
The scrollbar is per-page, the meter is per-article. Lots of blogs where I see a progress meter also have multiple articles on one page, sometimes even infinite scroll. I personally find the meters kind of superfluous, but they don't bother me since they usually stay out of the way.
A progress meter may not be necessary, but as the article points out if you have comments or an otherwise large footer not associated with the content of the post, the scrollbar can be deceiving.
I'm personally a huge fan of the progress meter (having once thought it was redundant as well) - one other easy addition I didn't see mentioned is an "estimated reading time." Having a ballpark range for how long I should expect to spend with a piece of content greatly increases my chance of engaging with it, and the progress meter creates a tangible representation of that time (and how much of it I have left to finish consuming the content).
I'm not sure how "estimated reading time" works for non-english speakers.
As for "progress meter" being an optimization of websites with large footers or long lists of comments, I'd argue that a better optimization technique would be to remove the footer, or remove/hide by default list of comments (i.e. make it available with a mouse click somewhere).
> I'm not sure how "estimated reading time" works for non-english speakers.
>
Do you mean for non-native speakers reading English material or for material in other languages when read by native speakers with an average reading competence in their native language?
Anyhow, as a non-native English speaker, it implemented it on my site by showing both the word count, as well as an estimated time, which is simply calculated by dividing the word count by a constant number of assumed words per minute.
That number was guesstimated by doing some reading speed tests on myself and researching average reading speeds and rounding up to 10 wpm. I have to admit that my assumption of 240 words per minute does not hold up to any scientific scrutiny, but otoh it is an estimation.
It works ok for prose. As soon as other notation is mixed in (code, math, graphs, diagrams etc.pp) that begins to naturally to vary wildly in accuracy.
>I'm not sure how "estimated reading time" works for non-english speakers.
Do you mean people whose native language is not English? I assume it works the same way as for everyone else, i.e. it's always an approximation anyway. I'm not from an English-speaking country, but I'm pretty sure I read faster than the average English native.
The other interpretation is that you mean people who can't read English at all, but in this case I understand even less. They won't be able to read the article, if they don't speak the language. After automated translation, the reading time should be roughly correct again.
in the early days of blogs, i found comments to be interesting and engaging dialogs. the last decade, or so, i’ve found comments to be unhelpful nitpicking/personal disagreements, spam, or support requests, so i’ve completely stopped concerning myself with comments on blogs.
so i’ll agree that progress indicators are helpful for this use case.
I went pretty far in the direction of these features on my personal sites in the 2010s. They are fun coding and design challenges.
Nowadays I am going the other direction. For the most recent design on my personal site, I even have a “no footnotes” rule, on the theory that (for me at least) footnotes can be an indication of scattered thinking and/or insufficient editing.
My thoughts exactly. There is a time and place for footnotes, sidebars, and citations, but they take attention away from the body text and, when overused (gwern.net), the entire site can look cluttered and disorganized. Most people aren't going to read these things anyway, so you're better off focusing on concise, effective writing.
These features are all sage advice for any blog in my opinion, and this blog is a good example of one that is easy to follow as a result.
Regarding the Table of Contents feature, however, I believe this makes a big difference in larger blogs, but for medium sized or smaller blogs, it can be a distractor. I use Hugo as well for compositing my site, and find that using ample first level headings (e.g., # Heading name) for major components alongside a solid flow that contains visual graphics placed shortly after the heading offers an attractive and easy-to-navigate browsing experience.
> Regarding the Table of Contents feature, however, I believe this makes a big difference in larger blogs, but for medium sized or smaller blogs, it can be a distractor.
Ah. That resonates. Thank you for breaking it down like that. I've pondered adding ToC, but now realize it's only for a small subset of pages that it adds value, rather than distracts.
Tables of contents are tricky. My publishing logic is rather flexible in how I use them, so I used to put them into the margins of longer articles[1] and sometimes even shorter ones[2] although I wasn't great at always remembering to do it[3].
But the problem for me is that good headlines, that give a fair summary of the section they are for, make for really wide tables of contents which don't fit neatly into the margins[4], so sometimes the table of content has to occupy space in the main section[5] which seems to me like it distracts a bit from the actual content.
A ToC might be more distracting with a style that benefits less from a clear structure, like a personal essay. It can be important in a more technical-procedural style of writing, though.
Doing a direct mapping from Markdown Headings to Table of contents+Anchors via Eleventy [1] is what I went with for my blog [2], simple setup, works perfectly.
I think Notion has nailed it with the new design of their table of contents [1]. The problem with the current general approach is that if a blog post is very long and you are in the middle of it, you might forget what the content was. However, having a very small item on the right that you can quickly peek at is awesome.
Oh this is a great list. Thank you. A few things on here that I'm now going to spend the day bringing to my site. I like how you explicitly called out a few things Gwern does. I love that site but hadn't examined closely _why_.
Here is a few additional things not on your list that I love and have implemented on my blog:
- Plain text versions of all posts. Change the file extension on any page on my site from ".html" to ".txt" to view it as plain text (https://breckyunits.com/intelligence.txt). Makes it easy to copy/paste a whole post into an email or Reddit submission
- View source links at the bottom of every page. Every post is 1 file tracked by git, and I put a "View source" link at the bottom of each page. Even the static pages are also one file, and also have a View Source link.
- Keyboard nav. Use the left/right arrow keys to navigate through pages on my site.
- Helpful 404s. If you mistype a url, the 404 page compares it to working urls and shows you the closest match. All done using clientside JS (no web server needed). For example: https://breckyunits.com/pcr.html
- Download entire site and read offline. Everything is designed to work fine locally and you can download the whole thing as a zip. (The link is at the bottom of every page)
- Printable. Everything is designed to look decent printed. Nav elements are hidden via CSS when you go to print. I haven't added automatic generation of PDFS yet, but that is on my todo.
> - Keyboard nav. Use the left/right arrow keys to navigate through pages on my site.
Please don't, this is horrible and I've previously only seen it used by clickbait news sites.
It provides no real value, the only use case of somebody wanting to browse through just the start of each of your articles is going to be incredibly rare. But what you're doing is hijacking a key that normally has no effect into having a destructive one. All it takes is a minor keyboard fumble while trying to scroll, and you've just lost all context and confusingly taken to some totally unrelated article.
I was thinking about this recently as I added it to a site. The use case is slightly different because the site in question was more data-driven than a blog. One example is viewing an individual item and being able to navigate to the next item in alphabetical order. This uses link elements with the appropriate rel values.
The problem of losing context can be mitigated by having the page return to the previous location on back, something which browsers kinda already do, just not very well.
Alternatively, I assume you'd prefer some kind of modifier? This has problems of its own — e.g. shortcut clashes. YouTube uses comma and full stop as frame next/previous shortcuts — maybe we should standardise on those?
In theory is the same as in practice, in theory. But in practice, they're different.
> It provides no real value,
This is wrong. It provides a tremendous amount of value. Source: I use it many times a week, for many years, for many reasons.
> destructive one.
This is wrong. These pages are immutable with no state. If by chance you accidentally hit an arrow key on one of the rare long form pages with scroll, sure you lose about 50 milliseconds of time getting back to your prior scroll level. In years of doing this not a single person has ever complained, while instead a number have commented that they like it.
> In years of doing this not a single person has ever complained
I've never used your website, but if I did and the side arrow changed things, I'd immediately close it and never come back. You wouldn't get a complaint from me; you'd just lose me instantly and permanently.
It drives me absolutely nuts when sites do this, it is so disorienting.
> I'd immediately close it and never come back. You wouldn't get a complaint from me; you'd just lose me instantly and permanently.
Do you think this concerns me?
I don't make this site for you, someone who admits they've "never used" my site.
I make my site for my regular readers, some of whom have been reading the site for over 10 years.
The people who regularly email me comments and feedback on my posts. People who _love_ the fact that they can flip through the entire blog in seconds using the arrow keys.
> when sites do this
My site is not like other sites on the web. In fact, it is such an outlier, that I've recently started a new successor to the WWW, called the World Wide Scroll, to start aggregating more sites like mine.
My site is entirely public domain, has no advertising or trackers or cookies, can be downloaded in 1 click and used entirely offline, is written in a new language (Scroll) that is mathematically shown to be the simplest/most powerful language yet invented, that compiles to HTML/CSS/JSON/XML/RSS/plain text, is fully tracked by git so you can see the history of every line in every file.
> a new language (Scroll) that is mathematically shown to be the simplest/most powerful language yet invented
This is, at best, ambiguous. To show something mathematically, you have to have a precise definition of it, and neither "simple" nor "powerful" admits a precise definition that is widely agreeable enough for any mathematical proof based on it to be worth anything.
> - Helpful 404s. If you mistype a url, the 404 page compares it to working urls and shows you the closest match. All done using clientside JS (no web server needed). For example: https://breckyunits.com/pcr.html
I like Cassidy James' idea of linking a blog post to a Mastodon post[1], and showing the corresponding social interactions as a comments section at the bottom of the post. All static site client-side!
> Using Mastodon to power our comments means that every time someone visits the blog post, the user’s browser makes a request to your Mastodon instance. ... I’d proxy these requests through my server, but it’s yaks all the way down.
I do proxy these, and it's not too much work [1]. A major reason to proxy is so you can cache: if a blog post gets HN'd it could easily get more traffic than your Mastodon instance would like to receive.
I think by "proxy the requests", they mean, these are usually on a static site and the browser is directly pulling in the Mastodon content client-side. They want to be good citizens and add a caching layer that they run.
* Literally every article (with descriptions, author info, post date, etc) displayed on the homepage in chronological order with no pagination, great for ctrl-f, etc.
* Selected authors and category-based navigation available.
* Entire site is very fast and lightweight, text-focused, no superfluous javascript or CSS, good typography, works well on mobile, etc.
This is very nice; I think the same can be achieved with general footnotes (not just source links), though you'd have to be careful to keep them short lest you take up a lot of screen space.
It’s just nice to see folks wanting minimalistic but functional features. I’m ticking quite a few of these on a service I’m working on. You can see my blog running on it https://lmno.lol/alvaro
Not yet officially launched. Happy to share invites to use now (for early adopters).
Most of these ux enhancements should be browser addons, in my view. We have gone way beyond what a website should be responsible for versus what’s up to the reader experience to implement.
I agree; the website should not need to be responsible for most of this stuff (and even when it is, the way it works is too messy). (In some cases the document author would still need to specify, e.g. the IDs of headings so that they can be referred to in URLs, but the browser should handle the rest; the author should not also need to add links in the headers.) The table of contents might even be suitable as a built-in feature. Having a progress indicator for only the article and not comments would be possible by using the standard <ARTICLE> command; a browser might choose to (subject to user settings) display a progress bar or scroll bar for the article only. The user can disable the features that they do not want (and/or change the features that they want differently). (Some people will use other file formats and protocols to try to improve this; and, if you like to do, you can even make available multiple protocols and file formats)
Neat, although some of them are actually helpful for specific articles. One thing that I actually seen as a pattern is over engineering the blog so much that features need maintenance.
It has a really interesting navigation where there's an article, links to related articles, and references etc.
Part of what I really like about it is the format of having the main text and then an "Advanced Discussion" accordion at the bottom that can be folded out for more detail. It's not uniformly used across all pages but I do like the format a lot. It's sort of an alternative to sidenotes but less disjoint where it treats the first part of a page as the intro and then expands in detail directions. It lets the intro be a higher-level and then "corrected" below.
Example (just one I found, there are better ones but not all pages have them):
Anyway just chiming in that it's a microfeature that I like vs say wikipedia which can just be... massively overwhelming on some pages.
I don't necessarily think this feature is fully realized at mriquestions, but the MRI field suffers from multiple audiences (radiologists, technologists, engineers, etc) and its really difficult to pull content together that foster communication between these groups. mriquestions is by a radiologist so its a bit lacking on the engineering details side but its still pretty good but higher-level technologists use it well to get beyond the lies we tell them. It doesn't really get too far into the lies we tell radiologists though but sometimes it gets close (by lies I mean oversimplifications) and usually the references are good for the technical details.
Great list of things to think about for a good reading experience. Linkable headings is my favorite. I will often grab the IDs from source when needed. Hard pass on the external link decoration though. Please just don't break the back button and everything will be fine.
I used openring-rs for my Astro [1] site, but eventually replaced it with a TypeScript-native solution [0]. You can see it on my blog, e.g. at the bottom of this link [2].
If you're looking for an easy way to pull RSS feeds from TypeScript and show the N most recent posts, take a look at my library.
PS: I'm currently unemployed, so if you have any feature requests I will quickly oblige :)
PPS: if you haven't heard of Astro [1], do yourself a favor and check it out. You write JSX syntax and get static HTML/CSS out, with the option for JS only as needed.
For code blocks I created prism-remote. It’s a web component that highlights remote code snippets. Kinda like embedded gists but better, you can display snippets from any file in a repo:
The idea is great, though I think I personally would prefer for this to happen on the server side (during rendering a static site, perhaps), not in the user's browsers. Particularly if the user doesn't enable JS, or has a slow connection.
Your example makes the same mistake as the one in the article - linking to a (development) branch rather than a specific commit. Unless it is just example code written for the article (in which case why link to it) stuff is eventually going to move arount and your referenced line numbers will be stale.
Forcing opening in a new tab can go die in a fire. I don't understand how browsers even support that. It's so abused.
If I wanted it in a new tab, I'll bloody well open it in a new tab myself. The feature is right there. Don't overrule the user. That should be illegal.
Now instead i click, have to go back, close the old tab, and history is wiped. Thanks for nothing.
I tried figuring out whether Firefox can be made to never open a new tab in response to a normal left click on a link. The advice I found is setting `browser.link.open_newwindow.restriction` to 0 and `browser.link.open_newwindow` to 1 in about:config [1]. But it works a little too well: clicking on a link outside of Firefox also no longer opens a new tab.
My most important microfeature is center-aligned pages. Whenever I read something on a large screen and the content is left-aligned, leaving a large gap on the right, it really turns me off.
> Whenever I read something on a large screen and the content is left-aligned, leaving a large gap on the right, it really turns me off.
I’m curious, why do you find that an annoying? The alternative you’re advocating is ostensibly just shifting half that gap to the other side.
If I were to be fussy about the gap then I’d be more interested if they were a layout that could make use of that space rather than alignment. The example in that article about side notes is a great example of utilising otherwise redundant space on larger screens.
I haven't found a nice way to do this on both desktop/mobile. What I want is for every heading to have an anchor link that can be copied, similar to a hyperlink. I see a lot of sites do this with a [unicode chain symbol] which is present on hover, but that's not an option on mobile. Alternate option is to have it next to every heading (ugly), turn every heading into a hyperlink without styling, or make them look like regular hyperlinks which I think is confusing.
/* keep the icon hidden by default */
:is(h1, h2, h3, h4, h5, h6) .icon {
visibility: hidden;
}
/* show the icon on focus and hover */
:is(h1, h2, h3, h4, h5, h6):focus .icon,
:is(h1, h2, h3, h4, h5, h6):hover .icon {
visibility: visible;
}
/* show the icon on devices that don't have any accessory that can hover */
@media (pointer: coarse), (any-hover: none) {
:is(h1, h2, h3, h4, h5, h6) .icon {
visibility: visible;
}
}
The `pointer: coarse` media query checks if you are using a device with an input mechanism of limited accuracy (such as fingers on a touchscreen). The `any-hover: none` media query checks if none of the input mechanisms on your device support hover (such as a Surface tablet not attached with a keyboard).
Have an icon appear on hover, and make every heading a hyperlink (even without styling), and have a table of contents with links to each heading (with styling). No need to dumb down your interface just for smartphone users.
The anchor symbol can have JavaScript that copies the link to clipboard on click. And the heading can be a plain old link to itself. Gives a nice visual and interaction for desktop while providing a way for mobile users to get the link too (long-press the heading and copy link).
I don't think it looks that bad. My blog's anchors are hover-visible on desktop and always visible on mobile (with lower opacity). I used this query to check for hover event availability to decide whether they should be always-visible: `@media screen and (hover: none)`. I think it turned out pretty ok¹.
While I heartily agree with nearly all of the suggestions here - particularly ToC and Code Blocks With Origin (which I really should implement on my own website) - FWIW, I disagree on the need for Progress Bars and Dialogues.
Progress Bars seem like an eyesore to me, a distracting visual feature that's trying to goad me into finishing the article. As other commenters mentioned, the browser already has a scroll bar, which indicates the amount of content I have read. A progress bar just seems unnecessary.
As for dialogues - while they can be cute and interesting if done well, it usually just gets in the way of the content I'm trying to read. The problem that it solves - "ask[ing] questions from a less-experienced point of view" - can often be accomplished with regular prose instead eg. "But you might be asking..."
A feature that I'd like to see in more blogs is a 'Tech Stack' page[0]. I've often stumbled on websites that look very appealing, but have no description of how they were created. This page would describe the technologies and tools you use to write your website. Things like static site generators, CSS, JS framework (if any) could go in here.
I'd also like to add 'Site Maps'[1] to this, which I've implemented as a list of all articles on my website.
It is an interesting format, but a bit hard to discover. If it would not have been for your comment, it would not have occurred to me, that there is a second level which enriches the overall topic.
Is it essential to the format to open all secondary parts at once? Otherwise that would be a great use case for the details/summary tag, which also would come with affordances that indicate that there is more information available.
Thanks for that feedback - I will think about how to make the parts beyond the tip of the iceberg more obvious and discoverable. Philosophically, I want the "tip" to be as uncluttered as possible but ... we'll see what I can come up with.
Theoretically, if enough people began writing in this form it would then become obvious by virtue of familiarity ...
Only really works if one article takes up most of the space. If there's tons of ads/coments below, the scrollbar would show less progress than actually is the case, and vice versa with wasted space above the article.
I'm not a fan of sidenotes/footnotes. It's a writing style that's scatterbrained and quite irritating to me.
And on top of that, how is it going to work on mobile?
One who does a lot of writing should work on avoiding sidenotes and footnotes altogether. If there's something related to the article that is important or noteworthy, incorporate it into the main piece.
I appreciate when blogs include a "start here" section, like https://tomcritchlow.com/start-here/, or equivalent. Sometimes a bunch of content can overwhelm a new visitor, so entry points are appreciated. See also:
I really like "archive" and "tag" overviews. I don't want to scroll through every post in full as a way of finding an entry that interests me. Not really a blog but Hackaday on mobile is really bad at this. It's kind of hard to filter for interesting stuff without having something specific to search for.
If you have a blogroll, update it regularly. I get that blogs are passe (that's why I started one a while ago). It is annoying to go to one of the few active blogs and find that most of the blogroll links go to sites not updated in a decade or expired altogether.
It is a compilation of many great ideas. Thanks for putting it together. For my needs table stakes are lower, but as inspiration as well as aspiration certainly.
I found an enjoyable demo (can't find it now though...) of the animated table-of-contents feature mentioned here, and adapted for a website I maintain:
What if there were a standard <BlogEntry> object that everybody rendered to their taste? To some, these are nice features, to others it's just bloat that causes a 5mb download for 1kb of text.
Yes, although HTML is rather messy. It is why some people use Gopher, had made up Gemini and Scorpion file formats too. (You can also serve multiple protocols and file formats if you want to do.)
Ah the push and pull. In the beginning, scroll bars were a feature. Then proportional scroll bars were a major development. Then scroll bars were dynamic, auto-hiding, optional, or removed altogether. So designers put progress bars across the top of individual pages--some sites have them, most don't, all different ad-hoc implementations. It's a new feature all over again, going through the cycle of learning what works and what doesn't. People hate it. People love it. All this has happened before. All this will happen again.
One nice thing I've seen is separating out footnotes (additional comments) from references (citations/links to external contents). It's probably not applicable to all blogs, but I like it in Citation Needed, Molly White's blog/newsletter; see https://www.citationneeded.news/issue-60/ as an example.
On the link preview feature, both Wikipedia's and Gwern's implementations put the preview on top of the main content. I think this is much nicer to put to the side, where its less intrusive: https://www.jefftk.com/p/preview-on-hover
Hot take, but the microfeature I love in blogs and websites is a date at the very top. I know patio11's points against it, but from a user perspective it just adds so much context that for me it's a no-brainer.
Is this the man responsible for the popularity of dateless blogs? (I tried to check the date on the post but... alas! ;)
Just kidding, we still have the Internet Archive (for now) so I am able to get the same information ("2014") in a much less convenient way... (I suppose my willingness to do so removes me from the category "most readers?" Though that will depend on the blog!)
The argument seems to be "people will disregard the information in an article if they think it's old." I can't speak for other people, but I actually find the opposite is true. The older a post, the more likely I am to find it interesting, and take it seriously.
A commanding percentage of all citations of me on e.g. Twitter will apologize to the user's own audience for the age of the piece, in a way which is obviously suboptimal.
I have updated my opinion accordingly: I agree that in the case of actually timeless content, hiding the date benefits both the reader (who would otherwise discount the information) and the author (whose work would otherwise be perceived as less valuable than it actually is).
It doesn't matter if Marcus Aurelius wrote his Mediations in the 160s or 170s (or the 1700s for that matter) as they truly are timeless!
However, I've run into articles that were very much not timeless, e.g. technical tutorials which were hopelessly out of date, with no indication that this was the case (since they hid the date). In such cases, hiding the date benefits neither reader nor author.
Presumably you did not mean that date-hiding should be implemented universally. I'm just sharing those experiences, which led me to associate missing dates in articles with confusion and frustration -- since those are the only ones that elicited a strong response: when I needed it, and when it wasn't there! The cases when the date didn't matter, but was there, left no lasting impression.
I'm glad your proposed solution was "Spend a few hours monkeying around in Jekyll to make dates radically less prominent [and] somehow alter the URL structure to take them out of URLs" — my conscience is repulsed by the thought of removing the date information entirely. It should be there for people who are actively seeking it out.
My site (OP) actually has a content graph as well, though it has a dedicated page. I didn't want to force users to run arbitrary JavaScript on every page just for aesthetics.
The is one of the many features supported by Racket's Scribble, which is used to generate the online and print books for the Racket ecosystem. https://docs.racket-lang.org/scribble/ (Which I also used for API docs embedded inline in the code of various Racket packages I wrote.)
Link previews have been widely discussed and sometimes criticized. Some notable implementations include Wikipedia, Google Docs, and Obsidian. IMHO, a link preview adds value when it provides enough information for me not to follow the link and open another tab.
I've created a Linkz.ai link preview script for blogs & websites - it adds fast (no iframes) summaries that appear on hover, and, optionally, on-click, it extracts linked articles, videos & embeds and shows them within the blog. When fewer people follow hyperlinks, it's a win-win situation; the website owner improves its retention and visitors are not overloaded with new tabs.
I've been experimenting with encouraging rabbit holes within my notes by opening any note you click on under the current open note. That way you can investigate, collapse and close related things to what you are reading without having to leave the page or juggle tabs.
It's all based a static site and it relies on HTMX for this feature. I've also made sure the page works without JS. For now it is a bit rough and sometimes it may not be clear that it opened underneath but I want to explore this a bit more.
There was a post on here recently to a blog that had a multi player cursor, so you could see other user's cursor positions and type wee notes - wish I'd taken note of it because there was a photography exhibition in the V&A where 12 hours of footage of London had been commented over in a similar way, and they were replaying it - "this guy will trip soon" and "she's texting the guy over there and he's said no"
This is a really great list (well, maybe not link previews, but everything else).
Sidenotes in particular are something I want to see basically everywhere, not just blogs. Modern screens have tons of horizontal space, text is most readable in pretty fairly narrow columns anyway, and scrolling to the bottom just to read a footnote (or, worse, having it pop up in some janky pop-over) is really unpleasant. Happy to see them catch on the blog world at least.
I do not get why people are sceptical about link previews. When done right (without iframes), e.g. in Obsidian or via Linkz.ai , they actually add value.
I hate it when an animated header scrolls as I'm scrolling the page.
Not sure how to describe it but when I scroll down, the header disappears. But if I scroll back up even a tiny bit, the header comes down back into view.
It's annoying to me because I'm usually reading near the top of the page, and the appearing header is both distracting and often obscures what I'm trying to read.
Asterisk magazine (https://asteriskmag.com/) is the only site I know of that does the thing that the author couldn't find an example of with a progress bar that includes section headings (on hover) and thus shows your progress through the table of contents. On mobile, where there is less space, it falls back to just being an ordinary progress indicator.
I'm going to circulate this among the technical writing communities I frequent. Some of these microfeatures seem like great features to add to docs sites.
One thing I added to my blog, which is less "micro" but still quite important I feel, is syndicating articles on social media. I don't think static site generators have good support for this, so I had to roll my own: https://www.jeremykun.com/shortform/2024-05-12-2028/
I did something similar where I would be able to tweet the latest post if I wanted. It first breaks down the entire text into chunks and then uploads the relevant media as well. It also keeps track of the previous chunk that was posted and uses that ID to reply to it.
> One immediate thought is that this is completely superseded by the regular browser scroll bar that’s ever-present at the side of the page.
This is unfortunately too often not the case, as people see fit to hide the default scrollbar and have something of their own that doesn't always show or is barely obvious.
Though I agree with ToCs and showing progress that way, for pages long enough to make it useful rather than just extra visual noise, though this page itself doesn't actually do that with either of the techniques shown (an extra bar showing just progress through the actual content, or using the contents list as such a display), unless my content sanitisers have blocked some JS that would be doing such work (I see no evidence of such a problem).
> Easily Linkable Headings
Again, these are sometimes very useful, and when not are easy to ignore completely.
But again, the page doesn't make use of the feature it is extolling the virtues of!
> Grouping Series of Posts
Yes, though I might argue that such links, or a link to a ToC page for the group, belong in a more general list of related links.
> Dialogues
I can't say I agree there, but I think that sort of style point is very subjective so I'll agree to disagree :-)
> Code Blocks with Origin
Yep, can be very useful where relevant.
> Markers for External Links
Definitely, including local links that open in a new tab should also be visually indicated.
I'd stay away from an icon per target site/type though - that could quickly get confusing as you essentially have many icons for the same thing (an external link), and every site will use its own preferred set of icons, so the difference won't help generally identify things at a glance.
> Link Preview
For me, yes, though I'd be very careful where to use such things. It might confuse many non-technical users.
> Anything else
I'd like all articles to carry an obvious date of publishing and/or last update. That can be very useful in judging if the content is likely to be entirely relevant or should be verified where it may go stale.
> But again, the page doesn't make use of the feature it is extolling the virtues of!
I said I loved the feature, not that I had the energy to implement it -- though I definitely should. :-)
> Yes, though I might argue that such links, or a link to a ToC page for the group, belong in a more general list of related links.
This is a good idea, and in my ideal world my site (and others) would support this, but it's more difficult to do automatically. Stitching together a series TOC and connecting sequences of articles is easier to automate.
> I'd stay away from an icon per target site/type though - that could quickly get confusing as you essentially have many icons for the same thing (an external link), and every site will use its own preferred set of icons, so the difference won't help generally identify things at a glance.
Yes, I'm not sure that I'd advocate for this in general. Another issue is that I personally get a little confused by some of the icons (what does "SAMA" stand for, if you don't know about OpenAI / Sam Altman already?).
> I'd like all articles to carry an obvious date of publishing and/or last update
Definitely, though as others in the comments have suggested, it may be that Google downranks pages like this. Not that I care much for my search ranking.
> I'd like all articles to carry an obvious date of publishing and/or last update
Definitely, though as others in the comments have suggested, it may be that Google downranks pages like this. Not that I care much for my search ranking.
I've heard the same but I've not seen trustworthy documentation stating that is an issue. It might be plausible that a date older than a certain point will make something be considered out of date, or more so than an article with a newer date, but if you think about it deeper it could be a bad indicator. How do you compare to articles without dates? I'd argue a dated article is better all else being equal, because the extra context makes it potentially more informative, some information doesn't date badly (at least not quickly), and how would the algorithms know what to do with pages containing multiple dates?
> Yes, though I might argue that such links, or a link to a ToC page for the group, belong in a more general list of related links.
Indeed, in the salad days of HTML there was some way to put related page-links in the <HEAD/>, and Sir Tim's browser displayed UI that enabled navigation via them.
Unfortunately that feature was already lost by the mid-1990s.
Seamonkey and I think Firefox, as late as the early 2000s, would expose some of those like next (<https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes...>), but roughly nobody used them (either writing or reading) and so they got dropped or shoved off into a plugin.
There is a <LINK> command, although many of the possible link types seem to be ignored by common browsers; however, some of these can be used for <A> as <LINK> anyways.
Honestly, I am baffled that anyone ever writes code blocks for multi-file projects without specifying the file name and path. Especially in a tutorial. I would just... never do that? If you have an actual repo to refer back to, fine, but saying "Write this code" without saying where to write it is just not good instruction.
> If you want to show progress while the reader is somewhere in the middle of a page, you could use a page progress bar.
There used to be a great feature available in every scrollable window which showed one’s position: the scrollbar. The bar itself was nice and wide, and there was an indicator right there which showed where one was in the document. They were useful, and they were consistent.
Then scrollbars got skinny, and then they disappeared. And so now each page which wants such a thing has to reinvent it. Also, it’s very difficult to actually scroll windows anymore.
Edit: yeah, he does mention that it’s nice to know position in the article versus in the comments. Point, and while separate windows/panes/frames/whatever would be one way to handle it, his suggestion is probably better.
This is an example where I'm skeptical that AI will be able to "appreciate" craft. Situationally aware enough to identify and articulate what makes these features notable. There's so much context baked into identifying these features.
Great compilation! Lots of great usability nuggets that could go beyond just blogs as well.
I especially love the progress-oriented table of contents/nav highlighting which section(s) you're currently viewing using the Intersection Observer API.
interesting take from an academic practitioner who also runs a blog.
i find it fascinating though in terms of how tech literate folks from outside this space is changing the way they consume written (web) content.
from the llm-chat paradigm shift, most people are less likely to read the source material, if this was not already the case thanks to tiktok and google search summarization. while i might feel that most people outside of hn were not reading personal blogs anyways, how many would truly appreciate these quality-of-life features.
I like a microfeature of Dan Luu's blog where the content is so good that you don't give a shit about the aesthetics or microfeatures on the page and just read it.
I would like a more elegant way to share what other bloggers I'm reading on my blog. The linked article doesn't provide much in the way of a solution here.
I like the side notes feature, but the hiding feature ins't great. IMO They should go with responsive design to inline the side notes if the screen is small.
Taxonomies[0] are the way to go if you'd like to group content on your site by something like series (although you could "just" use tags, which Hugo enables out of the box). I use "series" as a taxonomy, for which an initial bit of code is here[1]. Given that, depending on how comfortable you are with Hugo templating, you could probably use `.Site.Taxonomies.series` to iterate over all the "series".
On the topic of showing page progress with table of contents, author's description matches exactly how it is implemented in Material for MkDocs [1]. I moved my blog from WordPress to it (for unrelated reasons) and I immediately liked how going through longer blog posts felt with highlighted entry in the table of contents moving together with the page.
Just to be contrary, I find things on the page updating as I scroll to be distracting. I consider that kind of thing to be like a modern <blink> tag. On sites I read frequently, I nuke those elements with uBlock Origin. I guess I'm sort of a HTML fundamentalist, though.
I celebrate the 20th anniversary of my 365 days/year Typepad blog on August 20, 2024.
For a long, long time it's appeared to me that I'm the last person on Earth still using Typepad, which since it started being bought and sold a decade or so ago has had gradual serious decrements in speed and functionality.
It takes on average 10 seconds to upload a photo, and usually 2-3 attempts because of broken links.
Many times a past post which was intact now appears with broken image links.
And yet, I'm still able to post even though I probably know as little about code as anyone who visits HN.
My technical deficiencies are why my blog looks almost identical today to its appearance at inception.
At 76, I'm too old to do anything but continue in the same fashion.
A question: Is there anyone else here who uses Typepad?
I still pay for my Typepad account but have only blogged sporadically for the last decade. I haven't particularly noticed any degredation of its capabilities but I haven't paid much attention to it either.
I did revise the template and looking at it now, it seems rather ugly :-)
Centered for me at my usual browser width, then jumps to the left when widened to make room for the single side note example. A note that, boo hiss, doesn't show up at all at narrower widths. Not that it was an important note, but we're talking principle here.
My mini-gripe is the typography: While I'm typically a dark mode guy, thin fonts are a lot harder to read in dark mode. But I've seen worse.
A feature I love while reading web novels is...music. Nothing like reading that scene about the main character eating noodles inside her tiny Zurich apartment and reminiscing and have a theme named "Alone with my ghosts" start playing. Additional kudos if the author composed the music themselves.
I don’t know if it’s a feature, but a summary/tldr/abstract at the top is imo better even than TOC. Not only are to-the-point abstracts amazing for the reader, but also for the writer. Oftentimes when you can’t summarize properly, it’s because the article isn’t focused and needs rework.
> Relatively often I come across pages that have unique IDs for each header, but no clickable links! I end up having to use inspect element to find the anchor points.
Chrome has a 'link to text fragment' feature for this which got standardized and which Firefox is supposed to support at some point. So not so necessary as it used to be. (The unique IDs are often not so unique anyway or unstable.)
> I’ve found the link processing code on GitHub , and even the list of websites that get their own icons . I could not find a verbal description, though.
> Gwern’s website has no shortage of cool ideas. Among them showing link previews on hover. When hovering over a link, the site displays a popup window that contains a view into that page. I suspect that this view is also archived somehow, so that it retains a view into the page that matches it at the time of writing.
The archiving is complicated. Most of what you are seeing there is the use of iframes for 'live' links. (I manually check that websites do not break in an iframe before whitelisting them for popups like that.) But we do make extensive use of archives: https://gwern.net/archiving#preemptive-local-archiving
> Links to Other Sites
Gwern.net has a blogroll, incidentally. But I've always found the traditional 'big list in the sidebar' to be clunky. More fun is the 'site of the day' approach. So we went with an 'X of the Day' approach: in the footer of every page, there is a quote, a website, and an annotation of the day. (It's not really 'daily', but every few days after a full site sync.)
> Gwern.net has it! It's just that because we use both margins already, there is usually not enough horizontal space.
Upon closer inspection, I do. I should say that I have missed it up until now, though. Some sort of selective blindness, probably.
> Chrome has a 'link to text fragment' feature for this which got standardized and which Firefox is supposed to support at some point. So not so necessary as it used to be. (The unique IDs are often not so unique anyway or unstable.)
Thank you for reminding me of this; I stumbled across it some time ago and was quite surprised. I myself use Firefox, so until it adds support for this feature, I don't think I'll be leaning on it myself (and thus will try to provide anchors).
I would say that another microfeature I love is having stable and unique element IDs :-)
> Links.js hasn't been used in years on Gwern.net.
Thank you, I was failed by GitHub search. I will update the post. I struggled to find the Lorem link when looking for it; I would've expected to at least find something on /about, but did not. I understand that it's a test page, but it does currently have the only description of what the icons mean, and as a reader I definitely could've used a description.
A feature that seems to have disappeared from a lot of blogs these days is date when a post was published. Sometimes date is required to put things into context and I can't understand why so many blogs these days don't have it.
I have actually three dates on my blog [1], (1) the date I started writing a post (hardcoded in the url/name), (2) the date it was first published (defined in the markdown frontmatter) and (3) the date a post was last modifed (based on git commits). I think all three are relevant.
I like the second and third date but I think the first is perhaps a little confusing to me without this context. If I didn't know this is what it meant I'd of thought they'd be some bug in your blog or you forgot to update the url
And even if you see dates, quite often they're relative. A year ago could mean a lot.
Oh, and while blogs are usually newest on top, relative dates break the ability to derive sort order by looking at multiple values, if they're all the same.
A similar thing that really perplexes me is that GitHub uses relative dates. You try to find the date a certain change was made, and you end up scrolling through page after page of "six years ago."
It feels like the sort of thing that is only really sticking around because it was a design trend many years ago when some of these apps were written.
Others have commented on it being SEO-related, but I think there might be a psychological component to it as well, where you don’t want people to bounce because they think it’s an old and irrelevant article.
It used to be that a book or magazine issue needed to have a copyright notice including the year of publication or it didn't get copyright protection. That was a good rule.
Google knows whether your content is recent or not regardless if you have a timestamp on it, because they crawl periodically and according to recent leaks they do store this information.
It's hard to tell if they use it. Most of SEO is just cargo-culting because of how difficult it is to experiment with it. Somebody once said it helped them to remove the date, and now everyone does it. Maybe google is using it, or was using it at some point. Maybe they use the date in structured data [1] because it's easier to get and potentially more reliable (telling content changes and theme changes apart isn't trivial), and people just noticed that if they turn off the date feature in their CMS their articles rank better.
Unfortunately, it's not hard to make a few tweaks though and have it look "updated" to the crawler. I imagine Google could change that (especially now with LLM tech possibilities) so I guess we'll see what happens, but so far it hasn't hurt the career "optimizers" that I know.
The for-profit web surfs the eternal wave of "now". Anything that happened in the past is disregarded by search indexes, social media, and people using them.
My URLs have the date in them, and all posts have the original date near the title. I do updates (and update internal metadata), but removed the modification date because it was confusing to people…
It's not a feature, but I like websites without sticky headers or footers.
I hate seeing it on mobile, but I don't like it even on desktop.
The worst is the sticky side button overlapping the main content.
A few years ago, I sometimes saw "share on social media" buttons obscuring the article, and that was so annoying.
I use the top of the page to track where I am reading.
When a header is hidden on scrolldown, and shown on scrollup, that breaks a core feature that I was actively using.
To make matters worse, scroll direction is incredibly finicky on mobile, so I can't even consistently decide whether your ridiculous header is shown or not.
I think that is a good default. A small number of sites seem to execute sticky elements that help with long content, but only add it if you are going to test it.
WordPress used to have a Links section in the sidebar by default. It was later criticised for the default links being to WP founders/devs. But it was there, and you could change it.
Links are the web for me. "If you like my site maybe you will like what I like".
Back in the day (late 90's to early 2000's), sites would have something called a webring where sites would link to similar sites in a circular fashion. It was a good way to find similar sites and kinda a fun adventure.
I hate all of these features except the index. I get about 12kbps on mobile. There are very few sites I can view. Hackers news is one of them. The more I use the modern internet the more I want to be left alone with my thoughts. I need th website equivalent of a sensorial faraday cage.
- Remote backhaul / Satellite / Offshore
- Subsidized/cheap wireless plan
- Going over data cap, some carriers fall into a "safety" mode instead of charging you extra. I pay for 8gb/mo and would get throttled to similar speeds
- Preference
My brand new OnePlus8pro was blacklisted in Japan for being under the oppo brand a couple years ago. (The system in japan works on whitelisting, its corrupt and stupid) Anyways I had a $1000 phone, and I was not about to throw it away. So I continued to use it via an American cell company, which gives me just enough internet for wikipedia. Google maps doesnt work about 70% of the time. Since then I have realized not having good internet is good for my brain. It keeps me reading gigamonkeys and downloading pdf's before I go places rather than doomscrolling twitter.
Plus all wireless transmissions of internet stuff that use TCP will experience random round trip time (rtt) leading to problematic and ever increasing TCP re-transmit delay after back-off.
They are hosted in the States, and I can't afford a CDN, unfortunately. But I made sure to split off the CSS and other assets so they could be cached. It seems to have helped.
My phone mostly functions as a text machine with encyclopedia attached, which I greatly enjoy. When I see unusual construction or some curiosities I do not understand, I look them up. angle-of-repose, hill reinforcement techniques, average lifespan of whale shark, salps, concrete blocks underneath vending machines, stacked wires on electric trains, staged turbos on desiel trains, those circular dimples in japanese concrete blocks, etc. This is what I have always mostly used the internet for. After reading about something like this I enjoy just stewing on the info. This is the mode of existence I enjoy the most.
Only in the past few years was there much temptation for forever scrolling. Turning off my phone is good but then I cant look up interesting stuff, which is the point of being alive for me.
This is typically my experience when driving on interstates in the western US. The speed varies enormously, but glacial speeds are very common. HN works well, most sites do not.
Good list, though here comes my Hacker News-style pesky comment:
Justified text on a screen is a feature that makes my eyes and brain hurt.
Ragged text is much easier to read. Uneven and beautiful, like a plant whose details you rest your eyes upon as you observe, rather than a uniform concrete structure where vision is lost.
Justified text is beautiful ... in narrow-ish columns with good hyphenation. But hyphenation sucks on the web, and without hyphenation you can't even do narrow columns even in the rare cases where it would make sense for the reader.
Browsers take hyphenation hints: insert ­ in a word to tell it that it can put a hyphen there. Either combined with css ´hyphens: auto´ to tell the browser to also choose where to put hyphens, or ´hyphens: manual´ so your hints are the only thing that counts. Then just do it all server-side. Browsers still aren't the best at actually using that, but it's better than not hyphenating at all. (and of course you could write your own layout engine that uses your soft hints)
But shipping a whole dictionary wouldn't even be that unreasonable. A reasonable English dictionary is about 1.5MB compressed or 4MB uncompressed.
This is absolutely it for me. It's also why I like paragraphs to have some level of spacing between them.
I'm currently reading a book that has quite minimal indentation on the first line of a paragraph, no spacing between, small font, and justified text. Every page is just a wall of text. It makes it noticeably more tiring to read than others that I've read recently. It seems to be a trend in more serious historical tomes. The last one I read, the Beauty and the Terror, was similarly typeset.
It's one of the reasons I like reading on my kindle.
And lowercase letters are easier to read than ALL CAPITALIZED LETTERS IN A HORIZONTAL LINE OF TEXT.
Justified text is the same thing, but vertically. Your eye reaches the end of the line, and the next one is likely slightly longer or shorter, so it is easier for your eyes to find the next line instead of reading the same line over again, and also easier to see the whole shape of a particular paragraph you want to refer to later.
I do like well-hyphenated justified paragraphs in print, that also let you fit more words per page. But even there, I prefer the organic, non-uniform look of ragged text.
Agreed! I wrote a blog post about this a couple years back.[1] A few things I think are going on:
- layout and hyphenation algorithms on the web are worse (or often disabled!)
- the lines are often too long
- the site's margins aren't as strong as with print design
These factors combine to produce the mess you're describing.
I've spent so much time reading justified text in print that I do like it in general. But I think until places like NYT or Medium adopt it on their websites, it's probably not up to snuff on the web.
> I would like to take this opportunity to complain that LaTeX iS cApItAlIzEd lIkE tHiS.
In case you were complaining because you don't know why, rather than because you knew why but don't like it, it's LaTeX because it's Lamport + TeX; and it's actually not really TeX but TEΧ (that last letter is a chi), which, when typeset properly (see https://upload.wikimedia.org/wikipedia/commons/thumb/6/68/Te...), was meant specifically to show off TEΧ's layout abilities.
Sometimes referred to as smilies, though IMO that word describes the 3ish character subset that look like a face at 90 degrees⁰, and predating emoji¹ by quite some time².
----
[0] Like :-)
[0] and many many others: ;-) :-( :-| :-p 8-) …
[1] the graphical alternatives
[2] first commonly used in the early 80s, even before my time online, where emoji turned up right at the end of the 90s
> Way back when, we used to call ASCII like ":)" smilies, didn't we? I'm so old I don't even remember clearly. x_x
I always thought that ~it's only called Champagne if it's from the Champagne region of France~ it's only called a smiley if it's smiling. But, according to https://en.wikipedia.org/wiki/Emoticon (and as confirmed by http://www.cs.cmu.edu/~sef/sefSmiley.htm), their progenitor Scott Fahlman gave :-( as a prototypical example, so what do I know?
And Windows actually has a library of them for easy insertion. It's part of the same interface as selecting emoji. Just hit Win+. (Win+{Period}) and switch to the ";-)" tab.
I came to the comments expecting more pushback but I'm surprised. What happened to the simplicity of reading articles without status indicators, link popups, notes, conversations, ...?
There's some of these that I think are overkill, sure, but I like the simplicity of some of them - sidenotes, progress bar, etc. Just little things that give you that much more information about what's going on. Gwern's page, to me, is too much.
My personal favorite mixture of style and implementation of these features is jefftk.com - simple, fast, but gives a ton of information in an unobtrusive way.
I also vote for turning plausible link targets into links, or at least giving them IDs so that they can be linked without cruft; and, ever so much, especially for posts in a group that are not consecutive, for links to the previous and next post in the group. I've seen some blogs that do backlinks but not forward links, which is very frustrating when they say something like "I'll finish discussing this topic in a further post when I have a chance" in a 2013 post, and now there's 11 years of archives to go through to find out whether they ever did ….
If it's not the kind of content you want to put on your site, well, don't. But they are they are there to inform you of something. (Well, except for the link preview. Link preview is not good. At all.)
The author's focus is on static-generated sites, so reader mode isn't super relevant since they don't have a bunch of junk to clean up in the first place.
I love adding random stuff to my personal website. It might not matter to anyone else, but I love doing it for the sake of doing it. i.e., programming not as a means for an end.
Recently, I added a dynamic chart that shows how frequently and how much I work on my website, similar to the GitHub contribution chart. Not the kind of features the author was mentioning, but fun regardless: https://navendu.me/about/#about-me
I really hate progress bars, they are incredibly distracting. One of the worst examples of front end programmers wasting their time reimplementing browser functions badly. I already have scroll bars! I do not need more scroll bars!
Also, link decoration: my browser already has a nice discreet indicator to tell me where a link goes, I don’t need or want mysterious dingbats in the running text. (It reminds me of websites that are so scared of hyperlinks that they send them via interstitial warning pages “YOU ARE LEAVING THE SITE!!!!1!1!”, or in a recent case via a $yber$ecurity box that broke the link completely.) And preview popups? Get in the sea, hostile obnoxious interruption.