My favorite microfeature: have a page which lists titles of all posts with dates in reverse chronological order. This makes it so much easier to read the entire blog, rather than just the hit piece of the week. Different ways this feature is typically messed up:
paginate by year or, worse, month, such that the median page has 0 entries and the largest has three.
include the first pageful of the post, so that you can’t actually see a compact list of titles, and have to use pagination
only allow viewing posts with a particular tag (with a median tag tagging a single post)
infinite-scroll pagination which loads a handful titles at a time.
infinite-scroll pagination which loads a handful titles at a time.
Wow did you hit a nerve here for me. I don’t know who came up with the idea that you can only have 10 or 25 things on a page but it’s so frustrating, especially if whatever pagination strategy isn’t stable (e.g. always resets to page 1 on page load). A long list of items or a long-scroll table is just fine thank you and means that Ctrl-F works to find things in the page.
I don’t know if that would scale or not. I currently have 5,547 blog posts across 24 years. I do have an archive page and clicking on a month will show that month’s post, although I might be able to do something different? I never did figure out a decent “show the archive” format.
I don’t see what wouldn’t scale about it. 5k blog posts times ~300 bytes of with hyperlink, date is 15kb, which is the size of the CSS file that loaded when I opened this page. (Your blog is commendably light, so it would still be a larger page than the resources you’re already loading, but it’s still not very much.)
Derp, yes, 1500kb. There must be some gzip compression in your numbers, because if I curl | wc that page I get 765kchar. So accounting for that, we’re probably still under a megabyte for GP’s blog archive.
My blog just has a list of dates and titles of all posts back to the dawn of time, though I am not as prolific as you! On my link log you can bop a year to get all that year’s links, which is generally about 1000 links.
I only choose not to list posts before 2009 because the “feel” of my blog was different back then. It was less an essay archive and more “quick updates,” which then got replaced (for me) by things like Twitter/X. Plus, 2009 is already a long time ago.
For those of you using WordPress, the simplest way to do this is the “Display Posts” and “Display Posts Date View” mini-plugins.
These are tiny (in terms of source code), focused, & auditable plugins. They simply add a WordPress shortcode [display-posts] that will generate a listing of all your posts, grouped / ordered / limited however you like. You then just use that shortcode on an “/archive” page. The original plugin is 800 lines of code and the date view extension to that plugin is another 150 lines of code.
It’s borderline for me :) I wouldn’t say it fully commits mistake number 2, as I still get more than one post on the screen at a time. So it is usable. That said, I think keeping just the titles (and maybe the word count) would be better, as that optimizers for the primary use-case — looking at the entire list to see if anything catches your eye. If a title is interesting, you can always click it to read the first paragraph or two!
I do this on my archive page. Below the posts I list the other pages on the site: my “about me” page, my feeds page, and so on. It’s a sitemap, just with a less-technical-sounding name.
I’ve been idly considering making something that would only show you the posts in the last year on my main blog index with a per-year archive list, but you’ve just convinced me to leave this alone in a big index of fun.
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.
Hey, author here. You’re right, not all of these work for every site, and a lot of the features I mentioned need some thought to be done tastefully. This is why two out of the three things you mention here are “bonus” features, which are more of an extension to a microfeature I like.
I definitely found that progress bars are a value-add for me, but I understand why others might not. Wouldn’t it be nice if there was some CSS analog to “prefers dark mode” that says “this user prefers to not experience quirky front-end features”.
I dunno, of course it’s not exact, but I added it in the div where the post’s date is, not sure how “5 minute read” in a 10 pages long article would be “distracting”.
As for the scientific background how it’s calculated…
Well, hugo has that feature and so I searched a bit and settled on a very basic algorithm. Count the words in the Markdown file, divide by 200. This was close to hugo’s output, but not perfect, so I am simply adding one minute and it seems to mostly match.
A quick search brought me to this page where it says that even if you just take the average reading speed for each age bracket for teenagers and older, it already ranges from about 200 to 300 words per minute. But it also casually mentions that fast readers can do 350 - 600 words per minute. Of course, it also depends on the text itself and a number of other factors. In other words, it varies. A lot.
not sure how “5 minute read” in a 10 pages long article would be “distracting”.
It does not take up much space, but it often trips me up and breaks my flow. My eyes glance over it, and then I need to go back and think about it because it doesn’t make sense to me. I start to wonder: is this just a very complicated way of telling how many words there are in the article? If so, how many then? How many do I want there to be? 5 minutes. Is that a lot? How long does it normally take for me to read an article? I realize that I never have a sense of time when I read. Etc. etc.
Of course, this side tracking becomes shorter the more often you encounter it, but eventually, it condenses to “Oh, there is that annoying time again. This author does not really think things through.”
Thanks for the explanation, althought I disagree. I’m tripped up by different things though, so I see where you’re coming from. I’m just a little surprised why it seems to confuse you so much. Even if the number itself is pretty much off, in my experience it saves you a quick scroll (or worse, checking out pagination) that is misleading with any image or embedded ads. 5min is a “short article”, 15-20 is “I’ll not just quickly read this when my next meeting is in 5”, doesn’t really matter how fast of a reader I personally am.
But let me clarify I’m not advocating for people to adopt it, I just think it’s a neat feature for personal sites. No opinion really on high-traffic sites.
It has changed recently, but not substantively. Here’s where it was first introduced in October 2013, under the name MinRead. When the CJK conditional was added in October 2015 it had already changed name to ReadingTime.
Same actually. I dislike progress bars when there are scroll bars (so maybe nice on mobile? Not sure what I think) and am also not sold on indicators for external links, given the tooltip on hover. But maybe this is another mobile-thing?
I wouldn’t say progress bars a mobile thing. Mobile phones have scroll bars too, and they work well for the most part. I guess the main reason that the progress bar adds value over the plain scroll bar is that it has more knowledge of how much of the page is the “core” content and how much is the “extra stuff at the bottom you don’t have to get through”. That’s what helped retain my focus in the Quanta Magazine case.
As for link indicators – you have a point. Some of us have a different threshold for visual fluff than others.
It’s probably too subtle, but on my blog I shade the links, one shade for offsite links, another shade for links to my blog. I thought this was a good idea at the time (2000 or there about) and I’ve kept it, but I don’t think it’s ever been that useful.
Some websites (this one included) also make such links open in a new tab automatically.
Please don’t do this. I already have a way to open links in a new tab and my browser can decide where each link should open. Don’t think you know better than me.
My least favorite feature of personal weblogs is that search engines prefer the blogs on Medium or post on Dev.to or microblog on Twitter & so on. Pretty sure with the Google leak showed a lack of prioritization toward places where the maker owns their content favoring centralized Web 2.0 places or big blogs own by corporate entities. I want to see more of these ideas from folks writing their own content on their own platforms with niche or eccentric designs… or even just personalized & not bland, but users are not often getting funneled away from them. I actually just looking for a old post on Lobsters using keywords from the post but I couldn’t find it & had to go thru my (luckily) saved posts to find it. :(
Have you checked out https://blog.kagi.com/small-web? It’s neat that kagi already does it, but I want to create an extension for other search engines so people who don’t want to pay $10 every month for search or can’t can also have these curated websites in their search results.
A small web movement should not be built on the backs of big proprietary tech in Microsoft & Discord. So you have a such you could fill right there too.
Main thing I really like in websites is “make headlines clickable/linkable”. I shall take note and implement it for my blog too (maybe this is just a setting in pelican? Will find out!)
Many websites make headers linkable, but not clickable, so to actually get the link you have to go into the browser’s debug tools to find the id tag and create the link manually.
Hugo generates link ids for headers automatically, but does not make them clickable. Changing this is easy though, which I recently did for gpanders.com.
I’ve been using https://github.com/brettz9/jump-to-anchor/ for the longest time and it is amazing how many sites have IDs for titles but don’t seem to have any way to show it to the user. The extension easily solves the problem. Just activate and share the URL.
I don’t disagree, but I have become so used to it. My own site is an offender since I don’t yet know how to best put in these anchors. I don’t really want them in the original markup for TUI browsers…
This discussion prompted me to update my blog generator. Previously I had a horrible regex that edited the markdown to add anchors to headings. Now the horrible regex turns the markdown headings into HTML headings containing self-links. (I had to adjust the CSS as well.)
sidenotes and hovernotes i just don’t love on aesthetic grounds, but it is a fine compromise. i use endnotes, but i acknowledge that they’re problematic—ideal is footnotes, but they only work in print, unfortunately
progress bar is annoying and distracting and gives me the feeling of a businessperson wanting to optimise every aspect of their life. (ditto ‘estimated reading time’)
Some websites (this one included) also make such links open in a new tab automatically
i hate this so much. SO much. (need to get around to dredging up enough js knowledge to make a usercript to fix it, and then maybe i can stop complaining.) as far as i know, this trend was started by social media companies trying to increase engagement by preventing you from leaving their platforms. the given motivation doesn’t even make sense
Code Blocks with Origin
Code Blocks with Clickable Links
this just makes me depressed w.r.t. the state of programming environments. i think the only one who’s actually trying to do anything useful since web/cweb is bracha/newspeak
regardless, the best feature a website can have is clearly oneko (sadly broken in firefox; use chrome/safari)
Some websites (this one included) also make such links open in a new tab automatically
i hate this so much. SO much.
Agreed. If your blog’s readership is more technically inclined—and if you’re a Lobsters reader, they probably are—they know perfectly well already how hyperlinks work, and they can open the links in new tabs if they want to. I think it’s user-hostile (and a little arrogant) to assume that the reader wants to keep your page open when they click on a link elsewhere.
I do like a lot of the other suggestions, though. I recently finished implementing sidenotes on my site, falling back to pop-open footnotes on narrower screens. I’m liking it so far.
I’m debating making it easier to find the ids of my section headings, but most of my articles that have section headings have a table of contents too, and you could just copy a hyperlink from there. Maybe that’s not a great solution though.
but most of my articles that have section headings have a table of contents too, and you could just copy a hyperlink from there.
I think the only downside there is having to scroll back up to the table of contents (unless it’s sticky). Personally, I wouldn’t think to do that; it just wouldn’t cross my mind.
Having given it some deeper thought, I think you’re right, at least for the context of blogs and personal sites. I’ll be pushing an update to disable this functionality on my blog (the OP).
However, I do think new-tab links have their place. The Kagi search engine uses them and though it was jarring to adapt to at first, I prefer opening each search result in a new tab. My personal ideal solution would be a “go back to the previous page but leave this page open in a new tab” button or shortcut.
Kagi uses them because free users are capped to a certain number of searches a month, so they are incentivized not to use the back button since it can count against their limit.
I would’ve imagined that going back to an old page does not re-submit the form (and thus, doesn’t perform another search).
I tested this with Google by searching for a term, clicking a link, turning off my internet connection, and going back. The search results were still there. Though perhaps it’s a browser-specific behavior, or perhaps browsers cache pages like that inconsistently.
I think the actual bcowser behavior matters less than the perception. If people think the results page might disappear they could be less likely to click links. Caching behavior can be unintuitive.
it ‘works’, but neko is often (not always) distorted, i think because firefox places her slightly off of a pixel boundary and then resamples weirdly (with an accurate sampling algorithm, being a tiny fraction of a pixel off should not affect the result significantly; but the same applies to basic stuff like nearest and linear so idk what’s going on). see here a screenshot: https://files.catbox.moe/62ab6o.png
sidenotes and hovernotes i just don’t love on aesthetic grounds, but it is a fine compromise. i use endnotes, but i acknowledge that they’re problematic—ideal is footnotes, but they only work in print, unfortunately
I’ve seen blogs where footnotes are placed in small print every few paragraphs.
I wonder how hard it would be to use js to render the relevant footnotes to the text on screen in a footer. Probably you’d want to disable it for smaller screens. I’d be interested at least to see how it feels to interact with.
i don’t like oneko on blogs. i love the idea of oneko, but i don’t like that it doesn’t scroll with the rest of the page (it’s an overlay, feels disconnected), and that i can’t just pet the kitty and let it rest on the negative space around the text
Oh, a lot of goodies in there. Nice collection. I’ve been regarding Gwern.net as a kind of a special beast from another www-verse.
Using dialogues — even for technical writing — is not a particularly novel idea.
Another fairly well known example is The Little Schemer book series.
I have three additions to propose:
An about page. Every time I follow a link on Lobsters and end up on a new personal website, I look for an author’s about page. It helps to put things in a context and level up with the author.
With a little more effort, though, the series-reading and series-writing experience could be nicer. Instead of manually inserting links, you could configure your website to automatically add a “next” and “previous” button to pages in a given series
Not just for series! Every post should have a visible next/prev link on it, plus a <link rel="next/prev">. (I know the latter doesn’t actually do anything with today’s garbage browsers, but I include it anyway in empty hope that some day browsers will be good.)
Every post should have a visible next/prev link on it
I do this but I label them “newer post” and “older post,” because I’ve always been confused about what “next” and “previous” mean in the reverse-chronological context of a blog. Does “next” mean later in time, or later in the page layout?
Tridactyl (and probably other similar webextensions) provide keybinds to try and navigate to the next/prev page. We look for a link with the appropriate rel attribute, and if it’s not present then we have some heuristics. It’s often useful :)
Opera used to do the right thing there. The forward button would take you to the rel="next" page if you clicked on it. They also had an two variants of the back button that you could put on the toolbar (either or both), one that took you back to the last page, one that took you to the rel="prev" page if one existed or to the previous page if not.
It’s been almost 20 years since I last used Opera, so I’ve no idea what happened after that. I liked having the same browser on OS X, FreeBSD, and Windows, but I didn’t like paying separately for each platform (or putting up with ads) and I really didn’t like how their click-to-select behaviour on OS X was different to every other text box in the system.
I’m relieved to see that the PDF of the original view looks good (IMO); on the other hand, the Firefox simplified mode leaves much to be desired. Thanks for bringing this to my attention, I will see what I can do to fix it.
Thank you! I enjoy simplified because it ends up essentially with “Reader Mode” but for the printed page. More words per page in a very readable form, fewer “decorations” around the outside of the article.
It’s a simple fact that most people design for the screen, which isn’t great for people who want to keep up with ideas but not feed their smartphone addiction.
If I were printing this instead of having read it on a screen, I would have elected for Original instead of Simplified.
Your reasoning makes sense! I’ve made a few tweaks:
When no CSS is loaded at all (which seems to be the case with “simplified” mode), I hide the link icons. I think this has made simplified view presentable.
In print, I apply the same styles that are applied when no margins are available. Sidenotes are displayed inline.
In print, sidenotes start expanded, since there’s no way to toggle them after the fact.
I also disabled page breaks in images, which in Original mode left them cut across pages. I hope this makes it work better for you!
I have spent a non-insignificant amount of time ensuring that my print CSS makes my website look adequately pretty (website link in profile, if you’re curious). It’s not particularly hard to do: just set background to white, borders and text default to black, and some other layout tweaks to look good on paper.
I have yet to figure out how to show hyperlinks properly. Using the CSS trick to put the hyperlink content after the text looks horrible in my opinion:
Sometimes the links are long and end up cut off, break the flow, etc etc. If you have any suggestions as someone who reads blog posts printed out, let me know :)
I don’t read blog posts printed out, but, if you generate the HTML and can control its generation, could you include in the HTML footnotes containing the URLs that have display: none except in print (and add footnote numbers “[1]” etc. to the links, with similar styling)?
One could also use full citations rather than bare URLs.
If I wish to click on a link, I go back to the original document (a google search of the exact article title often works) and find the link then click it. I don’t mind URLs printed out alongside text, nor as @5d22b suggested, as footnotes. Footnotes that actually print, with URLs, are probably the best of all worlds, since that way I can visually see “Ah, is link, ah, is footnote, if I care to break my attention I can do so later.”
Xe Iaso’s blog cuts off silently after a few pages of text if you try to print it.
Uhh, I was not aware of this! I’ll go try and figure out what’s going on. I’m fairly certain that it’s me fucking up something horribly. Do you have an example post where this breaks the most? Also what OS/Browser are you using so I can replicate this more controllably?
I printed the gokrazy is really cool article in recent weeks and it cut off just before the demo I believe (shortly after the “if you are making a vm” modal that I forgot to expand before printing). This is from memory, I can share the pdf I got. Linux, Firefox, probably simplified print mode
Edit: Though I have a saved PDF, it seems I can’t replicate it now! Perhaps you fixed it, perhaps you fixed it weeks ago and my information was already out of date. https://litter.catbox.moe/7ure31.pdf
I printed it in the second full week of May, so over a month ago. I had another one where I tried to print, it cut off, and I just gave up and read from a computer.
Surprised that nobody in this thread mentioned MDX and the remark/rehype/unified ecosystem. It seems like parsing markdown to content has become the de-facto way for writing blogs and documentation at a high level.
Most websites seem to be of the view that mobile users don’t want/deserve/benefit from table of contents, and if it is present, usually something you scroll past at the top rather than being summonable with a button. I’ve been trying to collect examples of people doing otherwise, with the hope of (when I eventually get time) stealing it for muxup.com.
I implemented a ToC in a similar way on my site, but I ended up inserting two different copies of the ToC: one for mobile (that’s closed by default) and one for larger screens (that’s open by default). Then an @media-query ensures that only the relevant ToC is shown, so if you’re looking at the rendered site, you only see one copy.
I did think about using JS to toggle the ToC open/closed depending on the screen size but that would have made things jump about when the JS got executed, which didn’t seem ideal. The duplicate ToC trick isn’t great (it would be really useful if you could set HTML attributes via media query), but it should at least be invisible to most users.
Thanks, that works pretty well though I was thinking more of cases where you always have access to the ToC without having to scroll way up to the top of a large article. That said, a button to scroll back to the top of an article on mobile is a lot more common, so combining that with a collapsible toc at the top could work reasonably well.
It has some downsides: it isn’t obvious that there is a ToC at all (due to ad blindness); the sticky button is distracting; it takes half a second for the ToC to appear (something is very broken there).
On balance I think I would prefer a plain ToC, because I can easily reach it with the standard scroll-to-top gesture and it doesn’t need an irritating overlay.
I’m not a huge fan of svelte-toc because it does it after the page load, so there’s a flash until the component appears. For SSG, it should be possible to do this during the build process, but I haven’t figured out how yet.
My favorite microfeature: have a page which lists titles of all posts with dates in reverse chronological order. This makes it so much easier to read the entire blog, rather than just the hit piece of the week. Different ways this feature is typically messed up:
Wow did you hit a nerve here for me. I don’t know who came up with the idea that you can only have 10 or 25 things on a page but it’s so frustrating, especially if whatever pagination strategy isn’t stable (e.g. always resets to page 1 on page load). A long list of items or a long-scroll table is just fine thank you and means that Ctrl-F works to find things in the page.
I don’t know if that would scale or not. I currently have 5,547 blog posts across 24 years. I do have an archive page and clicking on a month will show that month’s post, although I might be able to do something different? I never did figure out a decent “show the archive” format.
I don’t see what wouldn’t scale about it. 5k blog posts times ~300 bytes of with hyperlink, date is 15kb, which is the size of the CSS file that loaded when I opened this page. (Your blog is commendably light, so it would still be a larger page than the resources you’re already loading, but it’s still not very much.)
Math is off, that would be more like 1.5MB which is still plenty fine.
Here is a comparable example: the Dinosaur Comics archive with over 4K entries. 220KB transferred, loads under a second.
Derp, yes, 1500kb. There must be some gzip compression in your numbers, because if I
curl | wcthat page I get 765kchar. So accounting for that, we’re probably still under a megabyte for GP’s blog archive.Yep
content-encoding: gzip, that’s why I wrote “transferred” :)Here’s an example: https://akkartik.name/archives/foc
Try clicking around. The links go to lists of all the top level chat messages for each channel.
Not the person you replied to but I would bet they would accept a pagination after 100 entries as the second-best choice ;)
My blog just has a list of dates and titles of all posts back to the dawn of time, though I am not as prolific as you! On my link log you can bop a year to get all that year’s links, which is generally about 1000 links.
As long as it’s not a log file/log lines that get paginated at 100 that’s good enough for me.
sounds like a fun code golf (html golf?) problem to me!
Yes, agreed. I implement this on: https://amontalenti.com/archive
I only choose not to list posts before 2009 because the “feel” of my blog was different back then. It was less an essay archive and more “quick updates,” which then got replaced (for me) by things like Twitter/X. Plus, 2009 is already a long time ago.
For those of you using WordPress, the simplest way to do this is the “Display Posts” and “Display Posts Date View” mini-plugins.
https://wordpress.org/plugins/display-posts-date-view/
These are tiny (in terms of source code), focused, & auditable plugins. They simply add a WordPress shortcode
[display-posts]that will generate a listing of all your posts, grouped / ordered / limited however you like. You then just use that shortcode on an “/archive” page. The original plugin is 800 lines of code and the date view extension to that plugin is another 150 lines of code.(Why do I use WordPress? I’m a long-time blogger. Explained more in this comment on the orange site.)
Sounds like an RSS feed, no?
I guess these days Firefox makes you install RSSPreview to have the rendering functionality that used to be included.
Don’t RSS feeds typically include at least some of the content of posts and not necessarily include all posts throughout time?
It sounds more like a sitemap to me.
Typically, yes, but I do follow at least one RSS feed that has 1500 entries and 0 context.
Hmm I guess that’s true, but it’s up to the webmaster. Podcast RSS feeds at least tend to have all the posts.
I have something this on my posts page, though I’m not sure if fits your definition of “compact”. Do you think it’s more valuable to list titles only?
It’s borderline for me :) I wouldn’t say it fully commits mistake number 2, as I still get more than one post on the screen at a time. So it is usable. That said, I think keeping just the titles (and maybe the word count) would be better, as that optimizers for the primary use-case — looking at the entire list to see if anything catches your eye. If a title is interesting, you can always click it to read the first paragraph or two!
Ooh I do this https://www.bfoliver.com/articles/
I just kind of assume users can Ctrl+F
I do this on my archive page. Below the posts I list the other pages on the site: my “about me” page, my feeds page, and so on. It’s a sitemap, just with a less-technical-sounding name.
You’ll love https://elv.sh/blog/, although that’s because I didn’t bother implementing anything more fancy :)
I’ve been idly considering making something that would only show you the posts in the last year on my main blog index with a per-year archive list, but you’ve just convinced me to leave this alone in a big index of fun.
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.
Hey, author here. You’re right, not all of these work for every site, and a lot of the features I mentioned need some thought to be done tastefully. This is why two out of the three things you mention here are “bonus” features, which are more of an extension to a microfeature I like.
I definitely found that progress bars are a value-add for me, but I understand why others might not. Wouldn’t it be nice if there was some CSS analog to “prefers dark mode” that says “this user prefers to not experience quirky front-end features”.
Thank you for reading :)
https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-reduced-motion is sort-of that
Neat, thank you!
Adding to the list: include a “reading time” indication. You have no idea how fast I read. This time is meaningless and distracting.
I dunno, of course it’s not exact, but I added it in the div where the post’s date is, not sure how “5 minute read” in a 10 pages long article would be “distracting”.
As for the scientific background how it’s calculated…
A quick search brought me to this page where it says that even if you just take the average reading speed for each age bracket for teenagers and older, it already ranges from about 200 to 300 words per minute. But it also casually mentions that fast readers can do 350 - 600 words per minute. Of course, it also depends on the text itself and a number of other factors. In other words, it varies. A lot.
It does not take up much space, but it often trips me up and breaks my flow. My eyes glance over it, and then I need to go back and think about it because it doesn’t make sense to me. I start to wonder: is this just a very complicated way of telling how many words there are in the article? If so, how many then? How many do I want there to be? 5 minutes. Is that a lot? How long does it normally take for me to read an article? I realize that I never have a sense of time when I read. Etc. etc.
Of course, this side tracking becomes shorter the more often you encounter it, but eventually, it condenses to “Oh, there is that annoying time again. This author does not really think things through.”
Thanks for the explanation, althought I disagree. I’m tripped up by different things though, so I see where you’re coming from. I’m just a little surprised why it seems to confuse you so much. Even if the number itself is pretty much off, in my experience it saves you a quick scroll (or worse, checking out pagination) that is misleading with any image or embedded ads. 5min is a “short article”, 15-20 is “I’ll not just quickly read this when my next meeting is in 5”, doesn’t really matter how fast of a reader I personally am.
But let me clarify I’m not advocating for people to adopt it, I just think it’s a neat feature for personal sites. No opinion really on high-traffic sites.
Hugo appears to go for 213 per minute (501 for CJK languages), rounded up. Not sure where that comes from.
That code seems to have changed recently, pretty sure I had a look at the hugo codebase in January 2020. :)
It has changed recently, but not substantively. Here’s where it was first introduced in October 2013, under the name
MinRead. When the CJK conditional was added in October 2015 it had already changed name toReadingTime.Same actually. I dislike progress bars when there are scroll bars (so maybe nice on mobile? Not sure what I think) and am also not sold on indicators for external links, given the tooltip on hover. But maybe this is another mobile-thing?
I wouldn’t say progress bars a mobile thing. Mobile phones have scroll bars too, and they work well for the most part. I guess the main reason that the progress bar adds value over the plain scroll bar is that it has more knowledge of how much of the page is the “core” content and how much is the “extra stuff at the bottom you don’t have to get through”. That’s what helped retain my focus in the Quanta Magazine case.
As for link indicators – you have a point. Some of us have a different threshold for visual fluff than others.
Thank you for reading and sharing.
My mobile browser hides the scrollbar if there is no motion, so I often just swipe the post up/down to see where am I now.
It’s probably too subtle, but on my blog I shade the links, one shade for offsite links, another shade for links to my blog. I thought this was a good idea at the time (2000 or there about) and I’ve kept it, but I don’t think it’s ever been that useful.
Please don’t do this. I already have a way to open links in a new tab and my browser can decide where each link should open. Don’t think you know better than me.
Thanks for your feedback, I have disabled this functionality. I agree with your reasoning (and the reasoning of others in these comments).
https://css-tricks.com/use-target_blank/
My least favorite feature of personal weblogs is that search engines prefer the blogs on Medium or post on Dev.to or microblog on Twitter & so on. Pretty sure with the Google leak showed a lack of prioritization toward places where the maker owns their content favoring centralized Web 2.0 places or big blogs own by corporate entities. I want to see more of these ideas from folks writing their own content on their own platforms with niche or eccentric designs… or even just personalized & not bland, but users are not often getting funneled away from them. I actually just looking for a old post on Lobsters using keywords from the post but I couldn’t find it & had to go thru my (luckily) saved posts to find it. :(
Have you checked out https://blog.kagi.com/small-web? It’s neat that kagi already does it, but I want to create an extension for other search engines so people who don’t want to pay $10 every month for search or can’t can also have these curated websites in their search results.
A small web movement should not be built on the backs of big proprietary tech in Microsoft & Discord. So you have a such you could fill right there too.
a niche* you
Main thing I really like in websites is “make headlines clickable/linkable”. I shall take note and implement it for my blog too (maybe this is just a setting in pelican? Will find out!)
Many websites make headers linkable, but not clickable, so to actually get the link you have to go into the browser’s debug tools to find the
idtag and create the link manually.Hugo generates link
ids for headers automatically, but does not make them clickable. Changing this is easy though, which I recently did for gpanders.com.I’ve been using https://github.com/brettz9/jump-to-anchor/ for the longest time and it is amazing how many sites have IDs for titles but don’t seem to have any way to show it to the user. The extension easily solves the problem. Just activate and share the URL.
Am I the only one that just opens my dev tools to get the ID? 😅
Definitely not :)
It’s a lot more work. You need to open it, find the ID, copy it, edit it into the URL. This is right click and done.
But at the end of the day both methods work.
I don’t disagree, but I have become so used to it. My own site is an offender since I don’t yet know how to best put in these anchors. I don’t really want them in the original markup for TUI browsers…
This discussion prompted me to update my blog generator. Previously I had a horrible regex that edited the markdown to add anchors to headings. Now the horrible regex turns the markdown headings into HTML headings containing self-links. (I had to adjust the CSS as well.)
I know, I used to find the
idand generate a link by hand if I want to point people at stuff. But my blog generator doesn’t generate them.Yeah, I think for technical pieces that makes sense, probably less so for diary style rants (in my case). Same for a TOC.
Hmm, maybe my SSG could actually use two more features…
I chuckled at this. Settle down kids, and let me tell a story. Back in the day we had these things called scroll bars …
i dislike a number of these.
i hate this so much. SO much. (need to get around to dredging up enough js knowledge to make a usercript to fix it, and then maybe i can stop complaining.) as far as i know, this trend was started by social media companies trying to increase engagement by preventing you from leaving their platforms. the given motivation doesn’t even make sense
this just makes me depressed w.r.t. the state of programming environments. i think the only one who’s actually trying to do anything useful since web/cweb is bracha/newspeak
regardless, the best feature a website can have is clearly oneko (sadly broken in firefox; use chrome/safari)
Agreed. If your blog’s readership is more technically inclined—and if you’re a Lobsters reader, they probably are—they know perfectly well already how hyperlinks work, and they can open the links in new tabs if they want to. I think it’s user-hostile (and a little arrogant) to assume that the reader wants to keep your page open when they click on a link elsewhere.
I do like a lot of the other suggestions, though. I recently finished implementing sidenotes on my site, falling back to pop-open footnotes on narrower screens. I’m liking it so far.
I’m debating making it easier to find the
ids of my section headings, but most of my articles that have section headings have a table of contents too, and you could just copy a hyperlink from there. Maybe that’s not a great solution though.I think the only downside there is having to scroll back up to the table of contents (unless it’s sticky). Personally, I wouldn’t think to do that; it just wouldn’t cross my mind.
Yeah, in fairness, I don’t think it would cross my mind either :-)
Having given it some deeper thought, I think you’re right, at least for the context of blogs and personal sites. I’ll be pushing an update to disable this functionality on my blog (the OP).
However, I do think new-tab links have their place. The Kagi search engine uses them and though it was jarring to adapt to at first, I prefer opening each search result in a new tab. My personal ideal solution would be a “go back to the previous page but leave this page open in a new tab” button or shortcut.
At least in Firefox, Ctrl-clicking or middle clicking the Back button does basically this.
Strictly speaking, doesn’t it do the opposite of that? It the leaves the current page as is, but opens the previous page in a new tab.
The set of tabs produced is the same – the only difference is their order in the tab bar and which one is selected.
Kagi uses them because free users are capped to a certain number of searches a month, so they are incentivized not to use the back button since it can count against their limit.
I would’ve imagined that going back to an old page does not re-submit the form (and thus, doesn’t perform another search).
I tested this with Google by searching for a term, clicking a link, turning off my internet connection, and going back. The search results were still there. Though perhaps it’s a browser-specific behavior, or perhaps browsers cache pages like that inconsistently.
I think the actual bcowser behavior matters less than the perception. If people think the results page might disappear they could be less likely to click links. Caching behavior can be unintuitive.
Oh, that’s a good point, I hadn’t thought of that. Thanks!
If the search was reloaded within “a short time”, then Kagi does not count it toward the user’s search count anyway: https://help.kagi.com/kagi/plans/plan-types.html#how-searches-are-counted
It might depend on how the search was submitted. If I recall correctly, a
POSTisn’t cached, but aGETis.If you’re talking about the cat chasing the cursor it seems to work fine in Firefox.
it ‘works’, but neko is often (not always) distorted, i think because firefox places her slightly off of a pixel boundary and then resamples weirdly (with an accurate sampling algorithm, being a tiny fraction of a pixel off should not affect the result significantly; but the same applies to basic stuff like nearest and linear so idk what’s going on). see here a screenshot: https://files.catbox.moe/62ab6o.png
I’ve seen blogs where footnotes are placed in small print every few paragraphs.
I wonder how hard it would be to use js to render the relevant footnotes to the text on screen in a footer. Probably you’d want to disable it for smaller screens. I’d be interested at least to see how it feels to interact with.
i don’t like oneko on blogs. i love the idea of oneko, but i don’t like that it doesn’t scroll with the rest of the page (it’s an overlay, feels disconnected), and that i can’t just pet the kitty and let it rest on the negative space around the text
scrolling seems interesting, but a bit odd—xneko floats too. refusing to walk over text and pathfinding around it is really cute though
Oh, a lot of goodies in there. Nice collection. I’ve been regarding Gwern.net as a kind of a special beast from another www-verse.
Another fairly well known example is The Little Schemer book series.
I have three additions to propose:
Not just for series! Every post should have a visible next/prev link on it, plus a
<link rel="next/prev">. (I know the latter doesn’t actually do anything with today’s garbage browsers, but I include it anyway in empty hope that some day browsers will be good.)I do this but I label them “newer post” and “older post,” because I’ve always been confused about what “next” and “previous” mean in the reverse-chronological context of a blog. Does “next” mean later in time, or later in the page layout?
My next/prev links have the date (and maybe title) of the post they link to.
Tridactyl (and probably other similar webextensions) provide keybinds to try and navigate to the next/prev page. We look for a link with the appropriate
relattribute, and if it’s not present then we have some heuristics. It’s often useful :)I do that. I added that … 20 years ago? Back when you could get an extension to Firefox to generate a navigation bar based on those links.
Opera used to do the right thing there. The forward button would take you to the
rel="next"page if you clicked on it. They also had an two variants of the back button that you could put on the toolbar (either or both), one that took you back to the last page, one that took you to therel="prev"page if one existed or to the previous page if not.It’s been almost 20 years since I last used Opera, so I’ve no idea what happened after that. I liked having the same browser on OS X, FreeBSD, and Windows, but I didn’t like paying separately for each platform (or putting up with ads) and I really didn’t like how their click-to-select behaviour on OS X was different to every other text box in the system.
My favorite microfeature: I can print it out and consume it on paper.
Sidenotes and footnotes and and and and and… are often implemented so in Simplified firefox printing, they are gone.
Xe Iaso’s blog cuts off silently after a few pages of text if you try to print it.
One recent thing I printed had ad text injected after every header on page read. In fact it was suitably downvoted as spam: https://lobste.rs/s/zdyrgr/what_is_stun_server_complete_guide_nat
Some pages add huge icons whenever you have a clickable link.
Other pages scale images to a constant width, not 100%.
Gifs of course if essential are not printable, and I sometimes replace them with appropriate alt-text before printing.
Few images, or not-in-darkmode pictures. Some art looks great in black-and-white though.
Meanwhile Chris’s wiki is a great example, allowing you to provide a range of posts, and being very easy to print in Simplified layout.
I’m relieved to see that the PDF of the original view looks good (IMO); on the other hand, the Firefox simplified mode leaves much to be desired. Thanks for bringing this to my attention, I will see what I can do to fix it.
Thank you! I enjoy simplified because it ends up essentially with “Reader Mode” but for the printed page. More words per page in a very readable form, fewer “decorations” around the outside of the article.
It’s a simple fact that most people design for the screen, which isn’t great for people who want to keep up with ideas but not feed their smartphone addiction.
If I were printing this instead of having read it on a screen, I would have elected for Original instead of Simplified.
Your reasoning makes sense! I’ve made a few tweaks:
I also disabled page breaks in images, which in Original mode left them cut across pages. I hope this makes it work better for you!
I’m afraid you may have broken your site, I now get a cert only for the static subdomain, and when I ignore it, I get through to 404.
I’m looking forward to trying the changes!
I have indeed broken the site, but I have also unbroken it now. Sorry about that!
Now it looks great both ways!
I have spent a non-insignificant amount of time ensuring that my print CSS makes my website look adequately pretty (website link in profile, if you’re curious). It’s not particularly hard to do: just set background to white, borders and text default to black, and some other layout tweaks to look good on paper.
I have yet to figure out how to show hyperlinks properly. Using the CSS trick to put the hyperlink content after the text looks horrible in my opinion:
Sometimes the links are long and end up cut off, break the flow, etc etc. If you have any suggestions as someone who reads blog posts printed out, let me know :)
I don’t read blog posts printed out, but, if you generate the HTML and can control its generation, could you include in the HTML footnotes containing the URLs that have
display: noneexcept in print (and add footnote numbers “[1]” etc. to the links, with similar styling)?One could also use full citations rather than bare URLs.
This is what I do and I wrote about it here: https://www.bfoliver.com/2023/03/28/improvelinkdisplay/
If I wish to click on a link, I go back to the original document (a google search of the exact article title often works) and find the link then click it. I don’t mind URLs printed out alongside text, nor as @5d22b suggested, as footnotes. Footnotes that actually print, with URLs, are probably the best of all worlds, since that way I can visually see “Ah, is link, ah, is footnote, if I care to break my attention I can do so later.”
Uhh, I was not aware of this! I’ll go try and figure out what’s going on. I’m fairly certain that it’s me fucking up something horribly. Do you have an example post where this breaks the most? Also what OS/Browser are you using so I can replicate this more controllably?
I printed the gokrazy is really cool article in recent weeks and it cut off just before the demo I believe (shortly after the “if you are making a vm” modal that I forgot to expand before printing). This is from memory, I can share the pdf I got. Linux, Firefox, probably simplified print mode
Edit: Though I have a saved PDF, it seems I can’t replicate it now! Perhaps you fixed it, perhaps you fixed it weeks ago and my information was already out of date. https://litter.catbox.moe/7ure31.pdf
I printed it in the second full week of May, so over a month ago. I had another one where I tried to print, it cut off, and I just gave up and read from a computer.
I really need to add some of these to my site but I dread hacking on the old Hugo template css. Doesn’t help that I’m on a really old version of Hugo.
Join us at https://prose.sh – it supports many hugo front-matter settings
Good list, good post, even if I don’t agree with about half of them.
Surprised that nobody in this thread mentioned MDX and the remark/rehype/unified ecosystem. It seems like parsing markdown to content has become the de-facto way for writing blogs and documentation at a high level.
Most websites seem to be of the view that mobile users don’t want/deserve/benefit from table of contents, and if it is present, usually something you scroll past at the top rather than being summonable with a button. I’ve been trying to collect examples of people doing otherwise, with the hope of (when I eventually get time) stealing it for muxup.com.
Examples I have:
Does anyone have more, or experience trying to implement this?
I have an example of a table of contents using a simple
<details>tag on my blog here: https://deregil.es/posts/lorem.htmlIt was quite simple to implement, although the downside is that it’s collapsed by default unless you click on it.
I implemented a ToC in a similar way on my site, but I ended up inserting two different copies of the ToC: one for mobile (that’s closed by default) and one for larger screens (that’s open by default). Then an
@media-query ensures that only the relevant ToC is shown, so if you’re looking at the rendered site, you only see one copy.I did think about using JS to toggle the ToC open/closed depending on the screen size but that would have made things jump about when the JS got executed, which didn’t seem ideal. The duplicate ToC trick isn’t great (it would be really useful if you could set HTML attributes via media query), but it should at least be invisible to most users.
Wouldn’t adding the
openattribute to the tag fix that? Or am I misunderstanding your problem?Thanks, that works pretty well though I was thinking more of cases where you always have access to the ToC without having to scroll way up to the top of a large article. That said, a button to scroll back to the top of an article on mobile is a lot more common, so combining that with a collapsible toc at the top could work reasonably well.
New HTML format IETF RFCs have a popup ToC, eg https://www.rfc-editor.org/rfc/rfc9000.html
It has some downsides: it isn’t obvious that there is a ToC at all (due to ad blindness); the sticky button is distracting; it takes half a second for the ToC to appear (something is very broken there).
On balance I think I would prefer a plain ToC, because I can easily reach it with the standard scroll-to-top gesture and it doesn’t need an irritating overlay.
I’m not a huge fan of svelte-toc because it does it after the page load, so there’s a flash until the component appears. For SSG, it should be possible to do this during the build process, but I haven’t figured out how yet.
You can use media queries to hide the table of content to users with a small or narrow screen. You can also use media queries to create a pure-CSS hamburger menu for users with a small screen. (See also: https://janessagarrow.com/blog/pure-css-hamburger-menu/ and https://css-tricks.com/snippets/css/media-queries-for-standard-devices/)