Look at the simplicity of articles on The New Yorker, for example, which are very long but very readable because there's very little cruft to distract you and the design is so simple. My experience there is almost interchangeable with a "reader view" of the page, a feature that by its very existence should communicate that the modern web has lost its way in thinking about these things.
It's not that every site needs to be minimalist, but if you're writing essays or text of substance, caring about this kind of stuff goes a long way. "Engagement" is not just how long I stick around but the mental investment I put into what's there, and when it comes to writing, less design is often more.
Most people (rightfully) are letting the frameworks handle this. The creators should be experts at typography, which includes line-heights and various rules. It's not a pure science though, so there will always be variation.
The New Yorker is indeed pretty solid, but it's funny that that's the standard because - as you say - it's still not quite as good as most "reader modes." The margins contain ads and I feel like I'm seeing "suggested articles" (aka pictures of AOC) every 5 minutes - which is a lot of AOC since some of the articles take up to an hour.
>> A block of text or paragraph has a maximum line length that fits a determined design. If the lines are too short then the text becomes disjointed; if they are too long the content loses rhythm as the reader searches for the start of each line.
>> Wikipedia entry on “Measure (typography)”, 2019
> The optimal width of a paragraph of text is anywhere from 50–80 characters per line, depending on which of the many studies you cite. If a paragraph is too wide, your eye loses its place when tracking back to the beginning of the next line. This decreases reading comprehension—and increases my irritation when I realize I’m re-reading the same line.
OK, so have the text flow into multiple columns on wide displays.
For a computer, even if you could fit 4-8 text columns on a 5K monitor... What do you do if the content demands a 5th-9th column? You'll have to scroll.
As someone else pointed out in the first iteration of my design here, using non-standard behavior for the margin notes in the mobile view meant it took experimenting to figure out that tapping on a cross-in-a-circle icon would expand additional flavor text. A distinctly un-cool surprise.
When presented with a multi-column text layout, would a user know how to intuitively use the site? They're trained to look for a scrollbar on the right side of the screen to indicate "Hey, friend! More content below." Would you keep adding columns and scroll horizontally indefinitely? There are a lot of challenges to overcome in that design.
The appeal of the Tufte-styled site, for me, is the side notes/margin notes. The whole site is ~1200px wide in three columns. 200px nav, 600px text body, and 315px side notes--the rest is padding between columns. The design takes advantage of the "wasted" space to add in delicious flavor text that I'd otherwise cram in with loads of em dashes and lengthy parenthetical asides.
I designed the page on a/for a 1080p screen, assuming most 4K+ users are used to seeing websites hang out in the middle of their massive TV-sized displays.
Someday, though, it'd be interesting to see if there's a way to combine more information density on a high resolution display without sacrificing readability/usability.
If WP for DOS could format multi-column pages, I can't imagine that it's that hard. Scrolling sideways is pretty intuitive. And it's become common for image slideshows. Or one could replace continuous scrolling with jumping to the next page.
I think my next blog redesign might incorporate a 'book-ish' horizontal scroll, rather than the infinite vertical scroll...
> If WP for DOS could format multi-column pages, I can't imagine that it's that hard
Funnily enough browsers have this support already (using column-width, or a prefix version of it), so for the web it's basically free, and trivial to add to a site:
Bound books (codexes) existed before Gutenberg.
This would allow more content to be displayed for users with larger screens without overly penalizing users who could only view one column at a time.
The challenge would be to convert the normal vertical scroll to a horizontal scroll in an intuitive way (ie not too jarring for the user).
But you can get display size, and paginate with ~80 character columns. So there's no need to scroll. As you say, scrolling really only works with one column. When I need to read lots of stuff that's hard-coded with two columns, I rotate my monitor to portrait.
It's a nice reminder, however, that search engines suck up the margin notes and inject them in the text where they find them. I noticed my site is indexed in Bing/DDG with the circle-cross icon in the middle of the text. I've been placing them so they line up nicely with the paragraph they're found in, but that doesn't lend to a very mobile-friendly reading experience.
A solution where I use eg cornflowerblue underlined icons, as suggested in the sibling comment, would be a solid solution for my personal use-case.
At least, that's why I did it the way I did at https://two-wrongs.com.
The original design of Tufte CSS is good, but even that won’t convince a reader to take a super bloggy blog seriously (and I’m a fan of super bloggy blogs). The design has to match the ideas and the writing.
For comparison, here’s a one-off article of mine that I published using Tufte CSS: https://thelocalyarn.com/excursus/secretary/posts/web-books....
It’s my own thing, so obviously I’m biased. But I can say objectively: A) I didn't dick around with the original Tufte design, B) I rewrote it for a year until I felt it was telling a coherent message, C) to me it is much easier to look at than the above (why would that be?) D) it was very well received E) in the 3 (?) years since I wrote it, I haven’t written anything else for which I felt like Tufte CSS would be a good fit.
(Another thing to consider: the ET Book font in Tufte CSS just doesn't look very good on low-DPI displays.)
And yet, it's also demotivating to the point of being depressing. Clicking through the chain of links culminating with Polen and Racket, the sheer depth of the stack required, the learning & work, to create beautiful digital+printed books, feels like it has much to be desired :-/
Design+publishing is inherently complicated and that complexity is conserved; you make one part of it simpler, you necessarily make another part harder. This is true of print publishing and it is true of web publishing, and they each have their own stacks. Any attempt to combine the two is going to have its own complexity. For this reason most people aren't interested in going there, so the tooling can seem very rudimentary compared with the tools that exist in either medium in isolation.
Pollen and Racket seemed arcane at first. But both are elegant, well-documented tools with extremely helpful communities. Delving into them has been probably the most rewarding experience I’ve had with anything computer-related, and that experience is still ongoing.
Your header interacts unexpectedly with the sidenotes and some of the images -- https://imgur.com/a/bgLRcvD
I tested on Safari 12 and Firefox 66; The book flipping video did not demonstrate that behavior.
In regards to font sizes, there are 5: H1s, H2s, H3s, body text, and captions.
Edit: Ahhh, and the paragraph lead ins makes 6 different sizes. That should be adjusted.
Here’s a link to one article on my blog as an example:
h3 seems to similar to body text. Maybe because the top and bottom margin is almost identical
Maybe reduce/remove the paragraph gaps inside the block quotes and brighten up the citation.
For my own web site I gave up for the time being and am living with DokuWiki's default theme. But I'm planning to give it another try over Easter.
I am slowly working my way through Web Typography by Richard Rutter (http://www.book.webtypography.net/) as I redesign my website. You may find it helpful as well. Another inspiration is Craig Mod's (https://craigmod.com) site (of which I took more than a few suggestions from).
Looking forward to reading your other articles! Good luck with the writing practice.
Edit: Change 'first article' to 'most recent article'.
I put together a project to be able to make new Tufte CSS sites with Jekyll:
It makes it easy to use Tufte CSS with markdown (including side notes!)
Regardless, we've implemented almost identical end-results (I also chose Solarized light, heh) for two different languages' static site generators. All we need is the creator of the Lisp equivalent to chime in...
Edit: Oh, I used Solarized Dark. Thought I swapped that for light at one point, as there's not quite enough contrast across all display qualities.
I've found https://outline.com/ to be great for reading content on the net regardless of the original layout, as it basically extracts the text and places it in a centered page with really legible line-height, letter-spacing, font-size & family. Evernote used to have a similar extension but it was sunsetted a couple of years ago.
Does anyone know if there’s a preferably open source alternative available that I could host on my own server?
I would love to know as well if there's an alternative.
Tufte-style presentation really shines when trying to convey very complex ideas that require a lot of text. For example, this is my attempt at explaining HTTP from the ground up. The side-notes really help to add additional information without breaking the flow of text.
That said, I don't think it looks that great on mobile devices in portrait mode. I still haven't found a good solution to this.
Usually I'm with you, except for a few fonts like Google's EB Garamond (https://fonts.google.com/specimen/EB+Garamond) and the one used here, ET Book. I think these are better than Times New Roman or Georgia, the two serif fonts I have to choose from if I don't go with web-imported fonts.
"Pelican static site generator config for Lawler.io":
My favorite feature is the one-click deployments. Through the power of SSH keys, the site is deployed with a simple `make rsync_upload`. No Chef scripts, no AWS CodeDeploy pipeline, just plain ol' rsync over SSH.
But perhaps it doesn't make sense when reading on the desktop.
In desktop, you can easily scroll the page to keep track of your spot. You can also use the mouse cursor for to keep your spot in difficult areas. The gains of having long line lengths likely outweigh the occasional difficulty in keeping your spot. The eye reads across faster after all.
So... Why does the blog format the main text body to be around 40 characters per line on my default window size? If you want to put the focus on this range of line lengths, you'll have to be more flexible with font sizes.
My thinking is that most programmers love information-dense displays. But designers have shown that empty space is vital to creating a truly usable design.
If a website used some minor CSS to add a bit more line-height and slightly-larger font than most browsers ship with, then fills 3840 pixels with wall-to-wall-text, you'll successfully achieve the most information-dense possible site, but utterly sacrifice readability.
Again, I don't think it's accidental that books don't use multiple columns of 66 characters in a landscape-style aspect ratio.
In true HN fashion, commenters are searching for a local maximum (use more of my big monitor) that defies how ordinary people interact with the written word. :)
I think you'd love what my best friend and I have been building for the last two years. It's like Hacker News except no commenting on articles you haven't read (and no skimming allowed!)
Check us out: readup.com
It might be a better policy to show visitors the top e.g. 5 - 10 trending articles on readup to get them 1.) to get a taste of what's shared and 2.) see if that's any better / different to what they'd find on hacker news (which can be read freely).
Anyway, good luck!