Breakdowns: Reading. How the best reading products get out of the way.
Reading products are the purest test of product design: the job is to put words in front of a person and then disappear. This guide takes apart fifteen of them, from the Kindle to Wikipedia to a feed reader, decision by decision, so you can see what each one chose, what it cost, and what you can steal for your own software.
Reading timeAbout 4 hours, in 5 sittings
Practice time2 weeks, ending in a reading-app spec
TeachersMarco Arment, Craig Mod, Matthew Butterick, Oliver Reichenstein, Brent Simmons, Silvio Rizzi, the Kindle, Kobo, Wikimedia and Standard Ebooks teams
By the end you will be able to
Explain why a reading product succeeds or fails using ten concrete criteria, not taste (understand)
Score any reading app on a 30-point scorecard and defend each score with an observation (evaluate)
Spot the trade-offs behind features like page numbers, popular highlights, unread counts and reading time (analyse)
Name which product does each reading pattern best, and borrow it deliberately (apply)
Write a one-page spec for your own reading-focused product or reading surface (create)
Warm-up: what do you already notice?
You read on screens for hours a day, so you already hold strong opinions about reading products. Most of them are unspoken. This guide makes them speakable. Before we start, try two questions. Don't look anything up; the point is to find out what your eye already catches.
Diagnostic 1
You open a novel on an e-reader. Which single decision most affects whether you are still reading 40 minutes later?
Defaults decide the experience for most readers, most of the time. Usability research on software settings has long found that most people rarely change defaults. A great reading product earns its reader in the first screen. Settings matter, but they are the safety net, not the floor.
Diagnostic 2
A read-later app shows "347 unread" in red on its icon. What is the most likely effect on a calm reader over a month?
A count frames reading as a debt. That is exactly why several readers in this guide (Reeder's 2023 redesign, Readwise Reader's triage, Instapaper's quiet list) chose to soften or hide the number. You'll see the trade-off in detail in the RSS chapter.
How to study this guide
Each product chapter has the same shape: the one idea, a schematic drawing of its reading screen with numbered pins, the decisions behind each pin, the costs, and what to steal. Don't read it straight through in one go. Do Part one first, then one product per sitting with the app open next to you. Score each product on the scorecard in chapter 1 as you go; by Part five you'll have your own comparison table, built from your own observations.
Part one
The lens
Before we take products apart, we need a shared vocabulary. Two chapters: a scorecard of ten criteria you can apply to any reading product, and a method for watching a reading session as it actually happens rather than as the marketing page describes it.
1
What makes a reading product great
Taught by Oliver Reichenstein, with Matthew Butterick and Craig Mod
A reading product is great when it gives the text the best possible surface, then removes itself, and only comes back when you need to find, mark, move or keep something.
Most software wants your attention. A reading product wants you to give your attention to something else: the book, the article, the essay. That inversion is why reading products are such a good school for designers. Every pixel of chrome, every badge, every recommendation competes with the thing the person came for. The best ones are almost invisible, and the work behind that invisibility is enormous.
Oliver Reichenstein of iA put it in one line in 2006: web design is 95% typography. For a reading product the number is closer to 100% while you are reading, and then drops sharply in the other moments: opening the app, finding a book, looking up a word, coming back on your phone. A useful scorecard has to cover both: the surface (how the text looks) and the system (everything around it).
The ten criteria
Here is the lens we will use for the whole guide. Each criterion is scored 0 to 3. Zero means absent or harmful, one means present but weak, two means good, three means best in class: other products should copy it.
Two halves. Five criteria judge the surface you stare at for hours; five judge the system that carries you between sessions. Products usually excel at one half. Kindle is strongest on the system; Standard Ebooks is strongest on the surface; very few are great at both.
1 · Surface typography
Typeface designed for long reading at screen resolution, sensible size, a measure (line length) of roughly 45 to 75 characters, leading around 1.4 to 1.6, real hyphenation if text is justified, proper quotes and dashes, no widows of one word on a page. See Typography for the underlying rules.
2 · Defaults
How good it is untouched. Most people never open settings, so the default is the product.
3 · Controls
Can you change what actually matters (size, theme, spacing, margins, face) in one or two taps, with a live preview, without breaking the layout?
4 · Navigation & progress
Do you know where you are and how much is left, in units that mean something to you? Can you jump to a chapter and jump back?
5 · Annotation
Highlighting and notes that are quick to make, easy to find again, and travel with you.
6 · Sync & continuity
Your place, highlights and settings follow you across devices and even formats (text to audio).
7 · Library & collection
Finding, sorting, grouping and pruning what you own or saved. A library that grows past 500 items without collapsing.
8 · Discovery vs distraction
Helping you find the next thing to read without pulling you out of the current one.
9 · Accessibility
Wide size range, high contrast options, dyslexia-friendly options, screen reader and text-to-speech support, one-handed use. See Accessible & Inclusive.
10 · Ownership & export
Open formats, DRM-free where possible, highlights and saves you can export in a usable format. The test: if the company died tomorrow, what would you lose?
Lab: the reading product scorecard
12345678910
0 / 30Score each criterion from 0 to 3.
How to use it. Open the app next to this page and read for at least ten minutes before scoring. Score each criterion, write the app name and press Save. Scores are stored only in this browser. You will reuse them in the comparison chapter at the end. Hover or focus a criterion for its question.
Why ten, and why 0 to 3
Ten is enough to separate products and small enough to finish in a single sitting. A four-point scale forces a decision: there is no neutral middle to hide in. If you are tempted to give a 2, ask "would I tell another designer to copy this?" If yes, it's a 3. If you'd say "it's fine", it's a 2. If you'd say "it's there, but…", it's a 1.
Scores are not the point. The observations behind them are. A score of 1 on Navigation is useless; "the progress bar shows percentage only, and I can't tell how long the chapter is" is a design insight you can act on.
Don't
Scores without evidence. "Meh" and "great" can't be acted on, argued with or reused when you design.
Do
Observation, then score. Each number points at something you saw. The last line turns the review into a design move.
Do
Score after a real reading session of at least ten minutes, not a tour of the settings.
Write one observation per criterion before the number.
Score the product you would actually use (device or app), and say which.
Re-score after a week: the system criteria only show up over time.
Don't
Reward feature counts. Twelve fonts can score lower than three good ones.
Score from screenshots or reviews. Reading is felt over minutes.
Average away a 0. One zero (say, no export) can outweigh three 3s for some readers.
In the wild
KindleAmazon, 2007–
The strongest system in reading: sync, dictionary, notes across every device. Weakest on ownership and on keeping the store out of the library. Great systems can carry an average surface for years.
Standard EbooksVolunteer project, 2017–
Ebooks typeset with care to a public style manual, free and DRM-free. No app, no sync: they rely on your reader for that. A great surface with no system of its own.
Readwise ReaderReadwise, 2022–
Scores high on annotation, library and export; the surface is good but dense with power features. Power can be a 3 and a cost at the same time.
For the solo creator
You may not be building an e-reader, but almost every product has a reading surface: docs, onboarding, release notes, a help center, long settings descriptions, an email digest. Run the scorecard on that surface of your own product. Usually 1, 2 and 4 are cheap to fix in an afternoon (better type, better default size, a progress hint), and they're the ones people feel most.
Common mistakes
Confusing "settings" with "controls"
A long settings screen looks like control. But if changing the font requires leaving the page, you can't judge the result.
Score controls on how fast you reach the setting and whether you see the change live on the page you're reading.
Scoring the brand, not the product
We like or dislike companies, and it leaks into scores.
Write the observation first, with the device and the exact screen. If you can't write one, you can't score it.
Check yourself
An app offers 14 fonts, 6 themes and 30 sliders, but the default is 14px sans-serif at full screen width on a tablet. How should it score on Defaults and Controls?
A full-width line on a tablet can run to 120+ characters, far past a comfortable measure, at a size too small for long reading. That default fails most readers, who will never open settings. Controls are judged on whether the right changes are quick and visible, not on how many exist.
Exercise 1.1 40 minutes · on the app you read in most
Your first scorecard
Pick the app you read in most (Kindle, Apple Books, a browser, Substack, whatever is true).
Read in it for 15 minutes without opening settings. Note anything that bothers or delights you.
Now open settings and spend 5 minutes trying to make it perfect for you.
For each criterion, write one sentence of observation, then a score, in the lab above.
Circle the lowest-scoring criterion and write one sentence: "If I were the designer, I would…"
You're done when: the lab shows a saved score for that app and you have ten one-line observations plus one redesign sentence in your notes.
Beginner
Competent
Strong
Scores with adjectives ("good", "clunky").
Every score has an observation tied to a specific screen.
Observations include numbers (characters per line, taps to a setting) and the redesign sentence is specific enough to build.
2
How to take a reading session apart
Taught by Don Norman, with Craig Mod
A reading product is not a screen; it is a session with six moments, and each moment has a different design job.
When you take apart a reading app, the temptation is to look at the reading page and stop. But people don't experience a page; they experience a session that starts before the page and ends after it. Breaking the session into moments shows you where products actually differ. Two e-readers with identical text rendering can feel completely different because one opens straight to your book and the other opens to a store.
The shape of a session. Interface presence should rise and fall with the moment. Most bad reading products have flat chrome: the same toolbar, badges and suggestions at every moment.
The protocol
Cold open. Kill the app. Open it. Count the taps and seconds until you are reading the sentence you left. Note everything on screen in between.
Settle. Change one thing (size or theme). Count taps. Is the change previewed live? Does your place on the page survive the reflow?
Immerse for ten minutes. Don't analyse. Afterward, write what you remember of the interface. If you remember nothing, that's a compliment.
Mark. Highlight a passage, add a note, look up a word. Then try to find that highlight again from the library.
Leave mid-chapter. Close it while partway through a page.
Return elsewhere. Open the same item on a second device (or the web). Where does it put you? Does it ask?
Don't
Flat chrome. Toolbars and a recommendation sit on top of the text during the Immerse moment, when the reader needs them least.
Do
Chrome on demand. Text plus one quiet line of progress. A tap in the middle brings the tools back for Settle and Mark.
Key idea
Measure a reading product by what you remember of its interface after ten minutes of reading. The less, the better.
Do
Time the cold open and the return. They are the moments where products differ most.
Test with a real book or article you want to read; boredom hides problems.
Note the units of progress each product uses (pages, %, location, minutes).
Don't
Judge only the reading page.
Test on a fresh install only; libraries and highlights behave differently at 300 items.
Skip the second device. Continuity is half of modern reading.
In the wild
Kindle e-readersAmazon
The home screen has gone back and forth over the years between a plain list of your books and a mix of your library with store recommendations. The Arrive moment is where business goals push hardest into reading.
Apple BooksApple, 2010–
Opens to a Home tab with "Continue" at the top: the book you were reading is the first thing you see. Put the most likely next action first.
Reader modesSafari, Firefox, Edge
Exist purely to fix the Immerse moment on web pages that fail it. When a whole category of tool exists to remove your interface, your interface is too loud.
For the solo creator
You can run this protocol on your own app in 20 minutes with a stopwatch and a notes file. Do it on your phone, not your dev machine: you'll catch the Return moment (state restoration, scroll position, deep links) that you never see when your laptop keeps everything warm.
Common mistakes
Analysing while immersing
If you watch the UI while reading, you notice everything and feel nothing.
Read first, analyse after. Write down what you remember, then go back and look.
Forgetting state restoration
On your own device, apps stay warm in memory. Real readers come back after the OS killed the app.
Force-quit before every cold open test.
Check yourself
A news app shows a bottom tab bar, a floating "Listen" button and a "Related stories" carousel that slides in at 50% scroll. Which moment does it hurt most, and what is the smallest fix?
All three elements live in the middle of the session, competing with the text. Collapsing chrome on scroll-down (and showing it on scroll-up) and placing discovery at the natural end of the article restores immersion without removing features.
Exercise 2.1 30 minutes · two apps you use
Session map
Draw the six-moment timeline on paper.
Run the protocol on two reading apps you use.
Under each moment, write taps, seconds and what was on screen, for both apps.
Shade the moments where each app was louder than it needed to be.
You're done when: you have one page with two session maps and at least three shaded "too loud" moments with the reason.
Beginner
Competent
Strong
Notes only the reading page.
All six moments covered with counts for both apps.
Finds a moment where one app is clearly better and explains the mechanism (e.g. state restoration, opening to last-read).
Part two
Books on screens
Five products built around the book: a long, linear text you return to over days or weeks. Their problems are typesetting without a typesetter, progress without pages, and continuity across devices. Their business models (selling books, selling devices, lending books for free) shape every screen.
3
Kindle
Kindle's big idea is not the e-ink screen; it is the system around it: your place, notes and dictionary follow you everywhere, so the book becomes a service you can open anywhere.
MakerAmazon
Since2007 (first device)
CategoryE-reader device + apps
Study it forSync, progress units, reading aids, the store tension
When the first Kindle shipped in November 2007 it was an odd beige slab with a keyboard. What made it matter was the wireless delivery: you bought a book and it appeared in about a minute, with no computer involved. Everything Kindle has done since builds on that idea of the book as a live, connected object. Your reading position syncs (Whispersync). Your highlights live in the cloud. The dictionary is built in. The text knows what's in it (X-Ray). Each of these is a design decision with a cost, and Kindle is the best place to study those costs because it has been making them for almost twenty years.
Schematic, not a screenshot. A Kindle e-reader page in the style of recent Paperwhite models: drop cap (1), justified and hyphenated text (2), a popular highlight (3), a word with a Word Wise hint (4), time-based progress (5), percentage (6), a character name you can look up with X-Ray (7), and sync and tools hidden behind a tap at the top (8).
Typesetting that respects the book. In 2015 Amazon introduced Bookerly, a typeface it commissioned from Dalton Maag for reading on its screens, together with a new typesetting engine (marketed as enhanced typesetting) that improved spacing, kerning and later hyphenation, and added drop caps. Before that, justified Kindle text often had visible "rivers" of white space because there was no hyphenation. The cost: older books and badly made files don't benefit equally, so quality varies from book to book.
Justified text with hyphenation by default. Print books are justified, so Kindle matches the expectation. Justification only works well with hyphenation and a long enough line; at large font sizes on a small screen, gaps return. Kindle lets you switch to left-aligned (ragged right), which is the safer choice at big sizes.
Popular Highlights. Since around 2010 Kindle has aggregated highlights across readers and shows passages many people marked. It's a fascinating social signal, and it raised a long-running privacy question: your highlights are data Amazon collects. It can also steer your attention ("I should notice this"), which some readers find spoils the book. You can turn it off. The cost of a default here is ethical as much as visual. See Honest & Calm.
Reading aids at the word level. Tap a word for the dictionary and Wikipedia. Word Wise (2014) puts short definitions above harder words, with a slider for how many words get hints. Vocabulary Builder collects every word you looked up into flashcards. Together they turn a lookup into learning, without leaving the page.
Time left, not just pages. Kindle learns your reading speed and can show "time left in chapter" or "time left in book". This answers the question readers actually ask at 11pm ("can I finish this chapter before sleep?"). The estimate needs a few pages of data before it's good.
Locations, then pages. Reflowable text has no fixed pages, so Kindle invented locations: fixed positions in the file that don't change with font size. They are stable for citations and sync, but meaningless to humans. Many books now map to real print page numbers, shown when available. Percentage is always there.
X-Ray. Introduced in 2011, X-Ray shows the characters, places and terms in a book and where they appear. It solves "who is this again?" in long novels without spoilers past your position. It needs per-book data, so not every book has it.
Whispersync and Page Flip. Whispersync keeps your furthest page, bookmarks and notes in sync across devices, and asks before jumping you forward. Page Flip (2016) lets you peek at other pages in a thumbnail view while your place stays pinned, the digital version of keeping a finger in the book.
Lab: progress in units that mean something
The house was quiet in the way houses are quiet just before rain. She had read the letter twice and folded it into a square small enough to forget.
Location 2,214 of 5,83038%
Try it. The book is a 90,000-word novel with 22 chapters of about 4,100 words each. Change the unit and the speed. Notice which units help you decide something ("can I finish tonight?") and which only describe the file.
Trade-offs and criticisms
The store in the library. Kindle's home screen and lock screen (on ad-supported models) carry recommendations and offers. It pays for cheaper hardware, but it puts the store into the Arrive moment of every session.
Closed format. Kindle books are generally tied to Amazon's apps and devices. Amazon has added EPUB support to Send to Kindle (converted on the way in), but the purchased library stays inside the ecosystem.
Highlight export is limited. Notes and highlights are viewable on the web and some can be exported, often with publisher limits on how much. Tools like Readwise exist partly to fill that gap.
Don't
Rivers. With few words per line and no hyphenation, justification has nowhere to put the extra space except between words.
Do
Even texture. At large sizes, left-aligned text keeps word spacing constant. A good reader switches automatically or makes it one tap.
Steal this for your software
Progress in time, learned from the user's own pace, beats progress in abstract units.
When syncing a position forward, ask ("Go to page 212, the furthest you read on your phone?") rather than silently jump.
Lookups that stay on the page (popover, not navigation) keep people in flow.
Turn incidental behaviour into value: every looked-up word becomes a flashcard.
Make social signals (popular highlights, reading counts) opt-in or easy to switch off.
Do
Offer progress in at least one human unit (minutes or real pages).
Keep a "peek" mode that never loses the reader's place.
Give reading aids an intensity control, like Word Wise's slider.
Don't
Show a raw internal unit (locations, offsets) as the only progress.
Put commerce on the screen people see every time they open their book.
Collect reading behaviour silently.
In the wild
Kindle PaperwhiteAmazon, 2012–
Front-lit e-ink made the Kindle usable in bed without a lamp, and later models added warm light. Hardware decisions are reading-design decisions: light colour affects how long people read at night.
Kindle Vocabulary BuilderAmazon
Collects words you looked up, with the sentence they came from, as flashcards. Context is the memory hook; keep the sentence.
Kindle NotebookAmazon
A per-book list of highlights and notes, filterable, linking back to the passage. Annotation is only useful if you can find it again.
For the solo creator
The "time left" estimate is cheap to build: words remaining divided by a reading speed (start with about 230–250 words per minute, then learn from the user's actual pace). Any long page in your product (docs, a lesson, a changelog) can show "4 min" honestly. Don't fake precision: round to whole minutes and hide the estimate below one minute.
Common mistakes
Copying Kindle's justification without its engine
CSS text-align: justify looks bookish in a mock-up and terrible on a phone, because browsers hyphenate poorly or not at all unless asked.
On the web, use left alignment, or justify only with hyphens: auto, a correct lang attribute and a measure of at least 60 characters.
Jumping the reader without asking
Sync that moves you to "furthest read" can be wrong (someone else used your account, you peeked ahead).
Offer the jump; don't force it. Kindle and Apple Books both ask.
Check yourself
You build a course app with long lessons. Users complain they never know if they can finish a lesson on their commute. What do you add first?
The user's question is about time, so answer in time. Percent and word counts make the user do the conversion. Learning their own pace (as Kindle does) makes the estimate personal and more trustworthy.
Exercise 3.1 45 minutes · Kindle app (free) or device
Map Kindle's reading aids
Open any Kindle book (free samples work). Read for 10 minutes.
Use, in order: the dictionary, X-Ray (if present), a highlight, a note, Page Flip or the page scrubber, and each progress unit.
For each, write: what question it answers, how many taps, and whether you lost your place.
Pick one aid and sketch how you'd bring it into your own product.
You're done when: you have a six-row table (aid, question answered, taps, place kept?) and one sketch.
Beginner
Competent
Strong
Lists features.
States the reader question each aid answers and its cost.
Sketch adapts the mechanism (not the look) to a different domain, with a tap count.
4
Kobo
Kobo bets that serious readers want control and openness: more typographic settings than anyone, open EPUB files, library borrowing and read-later articles built in.
MakerRakuten Kobo (Rakuten since 2012)
Since2009 (as Kobo)
CategoryE-reader devices + apps + store
Study it forDeep controls, open formats, physical buttons
If Kindle is the system, Kobo is the toolbox. Its e-readers have long given readers controls that other makers hide or skip: font weight and sharpness sliders, fine margin and line spacing steps, justification options, and the ability to load your own fonts. It reads EPUB, the open standard most of the publishing world uses, so a DRM-free book from anywhere just works. It has built-in library lending through OverDrive in many regions. And for years its devices had Pocket built in, so web articles you saved appeared next to your books; when Pocket closed in 2025, Kobo moved that role to Instapaper in a software update later that year.
Controls with the page still visible. The settings sheet covers only the bottom half, so each slider change is judged against real text (1). Fine steps (2), Advanced weight and sharpness (3), physical page-turn buttons on models like the Libra (4), and fonts you can load yourself, part of its openness (5).
A half-sheet, not a settings page. Kobo's type settings slide up over the bottom of the page. The text stays visible, so you see the change as you make it. This is the single most important pattern for reading controls.
More steps, finer steps. Size, line spacing and margins each have many increments. A reader with low vision or a love of tight text can both get exactly what they want.
Weight and sharpness. E-ink renders thin fonts faintly, especially on older screens. Kobo's Advanced sliders let you thicken strokes and sharpen edges. It solves a real hardware problem with a typographic control rather than a hardware fix.
Buttons for one-handed reading. The Kobo Libra line (2019 onward) has physical page-turn buttons on a wide side grip, and the device flips its layout for left or right hand. Tapping a screen with a thumb stretched across it is a tiring, error-prone gesture; a button under the thumb isn't.
Open by default. EPUB support means DRM-free books from Standard Ebooks, independent authors or publishers like Tor work without conversion. Kobo also lets you sideload fonts. Openness is a feature for the reader and a moat-reducer for the company.
Lab: an e-reader's type settings
It was the kind of evening that asks nothing of you. The lamp was on, the tea was cooling, and the book had reached the part where the plot stops hurrying and simply lets you live with the people in it for a while.
She turned the page with her thumb and did not look up for an hour.
About 62 characters per line
Try it. Push size to 28 with small margins, then turn on justification and watch the word gaps. Then find a setting you would pick as the default for everyone. The line counter shows when you leave the comfortable 45–75 character range.
Trade-offs
Many settings means many combinations, and some of them are ugly. Kobo accepts that cost for its audience of keen readers. Its defaults are good, which is what keeps the controls from becoming a burden. The other trade-off is ecosystem: Kobo's store is smaller in some markets, and its sync between devices and apps has historically been less seamless than Kindle's.
Don't
Blind adjustment. Every change means going back to the page to check, then back to settings. People give up after two rounds.
Do
See as you change. The text stays on screen above the controls; every slider move is judged instantly.
Steal this for your software
Any appearance setting should preview live, on the real content, in a sheet that leaves the content visible.
Hide expert controls under one "Advanced" label rather than removing them or showing them to everyone.
Use open, standard formats for anything the user owns; it builds trust and lets other tools help you.
Partner instead of build: Kobo didn't make a read-later service; it integrated one, then swapped partners when one closed.
Do
Give fine steps for size; low-vision readers need large sizes that still lay out well.
Remember settings per device, and offer a reset to defaults.
Plan for partners disappearing: keep the integration replaceable.
Don't
Put type settings on a separate screen with no preview.
Expose controls you haven't tested at their extremes.
Treat physical ergonomics as someone else's job; in software, it's thumb reach and tap zones.
In the wild
Kobo Libra seriesRakuten Kobo, 2019–
Asymmetric body with page buttons; screen rotates for either hand. Design for how the device is held for an hour, not how it looks in a photo.
Kobo + OverDriveRakuten Kobo
Borrow library ebooks directly on the device in supported regions. Integrate the source people already use, not just your store.
Kobo + Instapaper2025
Replaced the Pocket integration after Pocket closed. Integrations are dependencies; design so one can be swapped.
For the solo creator
A preview-while-you-change settings sheet is one of the cheapest delights to build: it's a bottom sheet with three sliders bound to CSS variables. If your product has any theme or density setting, build it this way rather than as a list of options on a separate screen.
Common mistakes
Sliders without sensible ranges
A margin slider that goes to zero or a line-height that goes below 1.1 creates broken pages that users blame on the app.
Set ranges you have tested; every position should produce something readable.
Settings that lose your place
Reflowing text after a size change can drop the reader pages away.
Anchor on the first visible word before reflow and scroll it back to the top after.
Check yourself
Your markdown notes app has a theme picker on a separate Preferences window. Users rarely change it, and the ones who do often switch back. What is the most likely cause, and fix?
Appearance is judged on real content. A separate window forces guess-and-check. Kobo's half-sheet teaches the fix: keep the content visible and apply changes live.
Exercise 4.1 40 minutes · your own product
Find your best default
In the lab above, find the settings you'd ship as a default on a 6-inch screen. Write them down.
Now do it for a 13-inch laptop window. What changed?
Open your own product's main reading surface. Measure its characters per line and line height at your most common screen size.
Change one value toward your lab default. Ship it, or write why not.
You're done when: you have two default sets (small, large) and one change made to your product, with before/after numbers.
Beginner
Competent
Strong
Picks defaults by eye.
Defaults stay within 45–75 characters and 1.4–1.6 leading.
Defaults adapt to screen width, and you can say why each value is there.
5
Apple Books
Apple Books shows the full arc of a design idea: it began as a vivid imitation of paper books, stripped that away, and kept only what helped reading, ending with themes that bundle many settings into one choice.
MakerApple
Since2010 (as iBooks, with the first iPad)
CategoryEbook and audiobook app
Study it forSkeuomorphism's rise and fall, themes as presets, reading goals
iBooks launched with the iPad in 2010 and its demo was unforgettable: a wooden bookshelf, and pages that curled under your finger, following it in real time, with the next page showing through. It taught a whole generation that a tablet could hold books. Over the next decade the wood went away (the iOS 7 redesign of 2013 flattened nearly everything), the app was renamed Apple Books in 2018 with a "Reading Now" home, reading goals arrived in 2019, and in 2022 the reading view was rebuilt around a small set of themes. Following that arc is a lesson in when metaphors help and when they get in the way.
From metaphor to function. The shelf and the curl explained a new device; once people understood tablets, the metaphor became decoration and was traded for speed, consistency and focus on "what am I reading now".
The page curl as an explanation. In 2010, nobody knew how to read on a tablet. A page that bent under your finger made the gesture self-evident: grab the corner, pull. It was a teaching device as much as an animation. See Motion & Feel for why direct manipulation feels right.
Dropping the curl as the default. In the 2022 redesign the default turn became a quicker slide; after complaints, the curl came back as an option. Once a gesture is learned, a heavy animation costs more (time, visual noise) than it teaches. Keeping it optional respects people who love it.
Continue first. The home tab puts the current book (and audiobook) at the top with progress. The Arrive moment is one tap.
Themes as presets. Instead of asking readers to tune five settings, the 2022 reading view offers a handful of named themes that set face, weight, spacing and background together, each customisable. A preset is a decision made on the reader's behalf that they can still undo. Good presets carry a design opinion; that's the point.
Scrolling view. Apple Books offers a continuous vertical scroll as an alternative to pages. Some people (and some content, like technical books) read better in scroll; pages give stronger landmarks ("it was near the top of a left page").
Reading goals. A daily minutes target (5 minutes by default, changeable) and a streak. Small default, real habit. Goals are a calm motivator only if they are easy to switch off and don't nag. See Honest & Calm.
Books and audiobooks in one library. The same app holds both, with a shared "Continue" row. Listening is treated as reading, not a separate product.
Pages vs scroll
Paged: fixed landmarks (left page, near the top, page 212) help spatial memory and make progress feel chunked. A page turn is a tiny reward.
Scrolling: no breaks mid-sentence and natural for code, tables and long figures, but fewer landmarks; your place is a scroll offset. Offer both, default to the one that suits the content.
Don't
All knobs, no opinion. Every reader becomes a typesetter. Most just leave it, or make it worse.
Do
Opinionated presets. Each tile is a complete, tested design. Fine controls live one level down.
Steal this for your software
Use a metaphor while it teaches; drop it when it only decorates. Keep the beloved version as an option.
Bundle settings into named presets that each make a complete, tested design.
Put "continue where you left off" first on any home screen of a long-form product.
Offer pages and scroll; pick the default by content type.
Do
Name presets by feeling or purpose ("Quiet", "Focus"), not by values.
Keep goals small by default and easy to turn off.
Treat audio and text as two views of one item.
Don't
Keep a metaphor because it demoed well once.
Remove a loved animation without leaving an option; Apple had to bring the curl back.
Make streaks punitive.
In the wild
iBooks page curlApple, 2010
Followed your finger frame by frame, with text visible on the back of the page. Direct manipulation teaches a gesture faster than any tutorial.
Apple Books reading goalsApple, 2019
Daily minutes target and streaks, with the goal adjustable from the home screen. Make the habit visible, keep the pressure low.
Play BooksGoogle
Also offers a "flowing text" and "original pages" toggle for scanned or fixed-layout books. Let the content's nature pick the view.
For the solo creator
Presets are a solo maker's friend: three themes you tested thoroughly cost less to support than a dozen independent toggles that produce combinations you've never seen. Start with presets; add a "customise" panel only when people ask for it.
Common mistakes
Skeuomorphism as nostalgia
Paper textures and curls feel warm in a mock-up.
Ask what each realistic detail teaches. If the answer is "nothing anymore", it's decoration with a performance cost.
Presets that are just colours
A "theme" that only swaps the background misses what makes reading comfortable.
A reading preset should set face, weight, spacing and background together, as a coherent whole.
Check yourself
You're redesigning a journaling app that uses a leather-notebook look with paper texture and ring binders. New users find it charming; long-time users complain it feels slow. What do you do?
This is the Apple Books path. The metaphor taught first-time use; for daily users it's overhead. A plain default with an optional nostalgic theme serves both, and learned gestures can stay.
Exercise 5.1 35 minutes · your own product
Design three presets
List every appearance setting your product has (or should have).
Design three presets, each with a name that says who or when it's for, and the exact value of every setting.
Test each on your three longest real pieces of content.
Kill any preset you wouldn't use yourself.
You're done when: you have a table of 2–3 named presets with all values, tested on real content.
Beginner
Competent
Strong
Presets differ only in colour.
Each preset sets type, spacing and colour together.
Each preset has a clear use case and passes contrast and measure checks.
6
Libby
Libby makes a complicated system (library cards, licences, waitlists, loan periods, formats) feel like a friendly app anyone can use, by hiding the machinery behind warm words and very few choices.
MakerOverDrive
Since2017
CategoryPublic library ebooks and audiobooks
Study it forApproachable design for all ages, waitlist UX, voice
Borrowing an ebook from a library is a strange transaction. Libraries license digital copies, often one reader at a time, for a limited number of loans or months. So there are waitlists for ebooks, which surprises people. The older OverDrive app exposed much of this machinery. Libby, launched in 2017, kept the same back end and redesigned the experience around one person with a library card and a phone. OverDrive later retired its older app in favour of Libby. Its users range from teenagers to readers in their 80s, so it's a valuable study in designing for everyone.
Schematic of a Libby shelf. Loans, holds and tags as three simple filters (1), one primary action per item (2), books and audiobooks side by side, each with a plain "due in" (3), honest waitlist estimates and "deliver later" (4), and only four destinations in the tab bar (5).
Plain words for a complicated system. "Loans", "Holds", "Due in 9 days", "You're #4 in line". Libby's copy is warm and a little playful in its onboarding, but on the shelf it's plain and specific. Older readers don't need to learn library software jargon.
Honest waits. A hold shows your place in line, how many copies the library owns and an estimated wait. Uncertainty is shown, not hidden. People tolerate waiting far better when they can see why.
Deliver later. If a hold comes in when you're busy, you can let the next person go ahead while keeping your place near the front. It turns a rigid queue into a polite one. It's a lovely example of designing the edge case.
Tags instead of folders. You can tag any book you see, Libby adds a few automatic "smart" tags for things like books you have sampled or borrowed, and tags work across your libraries and searches. A flexible structure with almost no learning cost.
Read in Libby, or send elsewhere. Libby has its own reader and audio player. In the US, many ebooks can also be sent to a Kindle. Libby meets readers on the device they already love.
A queue with manners. The single extra branch (deliver later) removes the worst moment of library ebooks: a book arriving the week you have no time to read it.
System speaks. Accurate, complete and unreadable for most of the people who use a public library.
Do
You're #4 in line The library has 12 copies. Estimated wait: about 2 weeks. When it's ready: Borrow now or Deliver later
Person speaks. Same data, translated into a position, a time and two choices.
Steal this for your software
Translate system states into human positions and times ("#4 in line, about 2 weeks").
Design the "not now" branch for any arrival: snooze, defer, deliver later.
Limit primary navigation to four or five destinations for wide-audience apps.
Integrate with the reading device people already have.
Do
Write for your oldest likely user; it helps everyone.
Show estimates with their uncertainty.
Use tags when users' categories will vary.
Don't
Expose licensing, back-end or format jargon on primary screens.
Force an immediate decision when something becomes available.
Hide where the user is in a queue.
In the wild
Libby onboardingOverDrive, 2017–
Walks you through finding your library and adding a card in a friendly, conversational sequence. Onboarding can be a conversation when the setup really has steps.
HooplaMidwest Tape
Another library app, built on an "instant borrow, no waitlist" model with monthly limits. Business model shapes the core screen: no queue means no hold UI.
Kindle + LibbyUS
"Read with Kindle" hands the loan to Amazon's ecosystem. Let readers choose their surface.
For the solo creator
Any product with waiting (exports, generation, review queues, shipping) can borrow Libby's two moves: show position and time honestly, and add a "not now" branch. Both are small changes to copy and state, not big features.
Common mistakes
Writing status from the database
The words come from the enum names: PENDING, SUSPENDED, OC/OU.
Write each state as a sentence the user would say to a friend, and show the next possible action.
Precise-looking estimates
"Ready in 13 days, 4 hours" invites distrust when it's wrong.
Round and say "about". Precision should match the real certainty.
Check yourself
Your app generates long PDF reports that take 5 to 40 minutes. Users keep the tab open and refresh. What's the most Libby-like fix?
Honest position plus estimate plus a "not now" branch. Making it faster is great when possible, but the waiting design is what you can fix today.
Exercise 6.1 30 minutes · your own product
Rewrite your states
List every status your product shows (sync, export, payment, upload, queue).
For each, write the current text, then a Libby-style rewrite: position or time, and the next action.
Add a "not now" option to at least one waiting state.
You're done when: you have a before/after table of at least six states and one new "not now" branch designed.
Beginner
Competent
Strong
Rewords to be friendlier.
Each state says where you are and what you can do.
States include honest estimates and a graceful defer path, checked by reading them aloud to someone non-technical.
7
Standard Ebooks and Project Gutenberg
The same public-domain text can be a chore or a pleasure to read; the difference is a thousand small typographic decisions, and Standard Ebooks writes every one of them down.
MakersProject Gutenberg (Michael Hart, 1971); Standard Ebooks (volunteer project led by Alex Cabal)
CategoryFree public-domain ebooks
Study it forTypography as craft, style manuals, semantic markup
Project Gutenberg is the oldest digital library: Michael Hart typed the US Declaration of Independence into a mainframe in 1971 and shared it. Since then volunteers have transcribed tens of thousands of public-domain books. Its focus has always been access: get the text out, free, in simple formats. Standard Ebooks, a newer volunteer project, takes those transcriptions (and scans) and produces carefully typeset, consistently formatted ebooks with modern conventions, semantic markup and a public Manual of Style that explains every rule. Compare the same novel from both and you'll see what "typography is invisible" really means.
Invisible until missing. No single fix on the right is dramatic. Together they are the difference between a text that feels like a file and one that feels like a book.
Write the rules down. Standard Ebooks publishes a Manual of Style covering punctuation, typography, semantics, metadata and file structure. Every volunteer follows the same rules, so every book feels like part of one edition. A style manual is a design system for prose.
Semantic markup first. Text is marked up for what it is (a letter, a poem, a quotation, an abbreviation), not how it looks. That makes books work across readers, with screen readers, and when styles change later.
Modernised, consistently. Some archaic spellings are updated according to documented rules, so a reader isn't tripped by "to-day" or inconsistent hyphenation, while the author's words are kept. The rules say what is changed and what is left alone.
Covers from public-domain art. Each book gets a cover using a public-domain painting with a consistent title treatment. A library of them looks like a collection, not a pile.
Free, DRM-free, multiple formats. EPUB, Kindle-compatible files and others. The books scorecard a full 3 on Ownership.
Gutenberg's choice: access over polish. Project Gutenberg's plain-text-first approach meant texts survived decades of format changes. Its HTML and EPUB editions have improved a lot over the years, but its core value is breadth and permanence. Both choices are right for their goals.
The same paragraph, two editions
CHAPTER I.
"It is a truth universally acknowledged," said he--quoting, as he so often did, from _some book or other_--"that a man in possession of a good fortune must be in want of a wife." It was 1811-1812.
I
“It is a truth universally acknowledged,” said hequoting, as he so often did, from some book or other“that a man in possession of a good fortune must be in want of a wife.” It was 1811–1812.
Rough: hard line breaks from the source, straight quotes, double hyphens, underscores for italic, monospace. Every flaw costs a fraction of a second of attention.
Typeset: reflowing text, a reading serif, curly quotes, real dashes, italics, an en dash in the range and a clean heading. (Austen's opening line, adapted as a typesetting sample.)
Steal this for your software
Write a one-page style manual for your product's text: quotes, dashes, numbers, dates, capitalisation, units.
Automate the fixable parts (smart quotes, en dashes in ranges, non-breaking spaces before units) in your rendering pipeline.
Mark up meaning, then style it; your future redesigns get cheaper.
Make a collection look like a collection: consistent covers, consistent metadata.
Do
Use typographer's quotes and apostrophes everywhere text is shown.
Use en dashes for ranges, and real ellipses and multiplication signs.
Link notes both ways: to the note and back.
Don't
Render user text with straight quotes because "that's what they typed".
Encode styling into content (underscores, ALL CAPS for emphasis).
Fix typography by hand, one screen at a time.
In the wild
Standard Ebooks Manual of Stylestandardebooks.org
Public, detailed, versioned rules for every book. Write the decisions down once; let many hands produce one voice.
Project Gutenberg1971–
Decades of free texts in durable formats. Permanence and access are design goals too.
SmartyPantsJohn Gruber, 2002
A small tool that converts straight quotes and dashes to typographic ones, used in many publishing systems. Automate typography where you can.
For the solo creator
You can add a typography pass to almost any product in an hour: a small function that converts quotes, dashes and ellipses before rendering user-facing copy, plus a style list for your own writing. Your product will look more finished without a single visual redesign. See Words for the writing side.
Common mistakes
Smart quotes in code
A global "smart" conversion also curls quotes inside code blocks and breaks them.
Skip code, URLs and inputs in your typography pass.
Notes that strand the reader
Endnote links that jump to the end with no way back lose the reader's place.
Every note needs a return link, or show it in a popover (see Gwern.net in chapter 17).
Check yourself
Your blogging tool lets authors write in Markdown. Readers say posts "look amateur" but can't say why. Which change is most likely to help, with least effort?
"Amateur" with no named cause is usually a pile of micro-flaws. The Standard Ebooks approach fixes them systematically at render time.
Exercise 7.1 45 minutes · Gutenberg vs Standard Ebooks
Spot twenty differences
Download the same novel from Project Gutenberg and from Standard Ebooks (both free).
Open both on the same reader, same settings. Read the first chapter side by side.
List every difference you notice: punctuation, headings, spacing, notes, metadata, cover, table of contents.
Mark which ones your own product gets wrong today.
You're done when: you have at least twenty listed differences and a short "fix in my product" list.
Beginner
Competent
Strong
Notices covers and fonts.
Notices punctuation, headings, notes and structure.
Writes a draft one-page style manual for your product from the list.
Part two recap: connect the ideas
Five book products, five philosophies: Kindle builds the system, Kobo hands over the controls, Apple Books makes opinionated presets, Libby translates machinery into plain language, and Standard Ebooks treats typography as a public craft. Before moving on, check the links back to earlier guides.
Connect the ideas
Which earlier principle explains why Kobo's half-sheet settings beat a separate settings page? (Think back to The Human Mind and Structure & Interaction.)
Working memory is poor at comparing a remembered page with a setting value. Live preview removes the memory load and closes the feedback loop.
Connect the ideas
Libby's "You're #4 in line, about 2 weeks" and Kindle's "6 min left in chapter" share one principle. Which?
Both translate internal data into an answer to the question the person is actually asking. This is the "gulf of evaluation" from Norman, made concrete.
Part three
Read later, read better
The web was not built for reading. Pages arrive wrapped in navigation, ads, pop-ups and cookie banners, at a moment when you don't have time. A whole category of products grew to fix that: save it now, read it later, in a clean view. Their stories (an invention, a giant, a power tool, a couple of shutdowns) teach as much about business and trust as about typography.
8
Instapaper
Instapaper turned a habit (leaving tabs open to read later) into a product with one button and one beautiful text view, and proved that people would pay for reading done well.
MakerMarco Arment (2008); later Betaworks, Pinterest, now independent
Since2008
CategoryRead-later service and apps
Study it forOne-button capture, text view, paid simplicity
Marco Arment built Instapaper in 2008 as a side project: a "Read Later" bookmarklet that saved a page to a list, and a way to read that list later, especially offline on the then-new iPhone. The key insight was splitting reading into two moments that happen at different times: finding (at your desk, busy) and reading (on the train, in bed, unhurried). The app's text view stripped each article down to words and set them beautifully. Arment charged for the app instead of filling it with ads, and that business choice kept the product calm. He sold a majority of it to Betaworks in 2013; Pinterest bought it in 2016; since 2018 it has been run independently.
Two moments, split. One button at the moment of finding (1), a quiet list with source and length (2), a text view set like a book page (3), with nothing in the margins (4).
One button, no decisions. Saving asks nothing: no folder, no tag, no note. The moment of finding is the busiest moment, so the cost there must be near zero. Organisation can happen later, if ever.
A list that tells you length. Each item shows the source and an estimate of reading time. Length is the main thing you need to pick what to read now.
Text view as the product. The extraction (getting the article out of the page) and the typesetting of the result are the core. Instapaper offered a small set of good fonts, size, line spacing, margins and themes, in a compact settings popover over the text.
Paid, therefore calm. Arment's model was simple: people pay, so the product serves readers rather than advertisers. Instapaper later moved to a free tier plus Premium (with features like full-text search and unlimited notes). The business decision shows up on every screen as an absence of ads and engagement tricks.
Speed Reading. Instapaper added a speed reading mode that flashes one word at a time at a chosen pace. It's a fascinating experiment and a useful lesson: it raises speed by removing the eye's ability to go back, which hurts comprehension for many texts. A feature can be clever and still be a niche tool.
Don't
Decisions at the busiest moment. Every field is a reason not to save, or a guess you'll regret.
Do
Zero-cost capture. Saved immediately; an optional action stays available for a few seconds for people who want it.
Steal this for your software
Separate capture from processing. Make capture one action, with no required fields.
Show length (time) in lists of long items.
Let your business model protect your reading surface; if you charge, don't also sell attention.
Treat experiments like speed reading as optional tools, not the main experience.
Do
Make "save" work from everywhere: share sheet, browser extension, email.
Download content for offline reading by default.
Show the source domain so people can judge trust.
Don't
Ask users to organise at save time.
Show article images by default if they slow down reading or offline sync.
Fill the list with recommendations the user didn't save.
In the wild
Instapaper on Kobo2025
After Pocket closed, Kobo devices integrated Instapaper so saved articles appear next to books. A simple, stable product becomes the safe partner.
Things Quick EntryCultured Code
Capture a task from anywhere with one shortcut, sort it later. Same capture/process split, different domain.
Safari Reading ListApple, 2011
Built read-later into the browser, with offline saving. Once a pattern is proven, platforms absorb it; independents must go deeper.
For the solo creator
Instapaper is the archetype of a solo product: one person, one clear insight, one excellent screen, and a price. If your product needs a growth team to be viable, ask whether there is a smaller, paid version that does one thing perfectly. See The Solo Practice.
Common mistakes
Optimising for the save, not the read
Saving is easy to measure; reading isn't. Teams celebrate saves while the list becomes a graveyard.
Measure what gets read, and design the list to help choosing (length, source, freshness).
A text view that loses the article
Extraction fails on some sites, dropping images, code or tables that matter.
Always offer "view original", and flag when extraction looks incomplete.
Check yourself
You're building a bookmarking tool for designers. A teammate proposes a save dialog with board, tags and colour. What do you suggest?
Capture should cost nothing. Organisation belongs to a calmer moment. Removing tags entirely throws away value for people who want them.
Exercise 8.1 30 minutes · your own product
Count the cost of capture
Find the main "create" or "save" action in your product.
Count required fields, taps and decisions to complete it.
Redesign it so the first save is one action, with everything else optional or later.
Sketch where the "later" processing happens.
You're done when: you have before/after counts and a sketch of the capture and the later triage.
Beginner
Competent
Strong
Removes one field.
Capture is one action; processing has a home.
You built it, and you can show the before/after with real usage.
9
Pocket
Pocket made read-later mainstream, with saving from everywhere and a recommendation engine, and then its closure in 2025 taught millions of people what ownership and export are worth.
MakerNate Weiner (as Read It Later, 2007); Mozilla from 2017
Lifespan2007–2025
CategoryRead-later + discovery
Study it forUbiquitous capture, discovery, the end of a product
Pocket started as Read It Later, a Firefox extension, in 2007. In 2012 it was renamed Pocket and relaunched as a free app with a cleaner design. It grew huge by being everywhere: browser extensions, a share-sheet action in thousands of apps, an email address you could send links to, and built-in integrations (Kobo e-readers among them). Mozilla bought it in 2017 and put Pocket recommendations into the Firefox new tab page. In May 2025 Mozilla announced it would shut Pocket down; the service closed in July 2025, with a window to export data that ran into October. This chapter is half breakdown, half obituary, because the ending is the lesson.
Wide in, narrow out. Pocket's strength was the number of ways in. Its lesson is about the ways out: when a service ends, export is the only door that stays open.
Free and everywhere. Becoming free in 2012 and integrating with as many apps as possible made Pocket the default "save" target for a decade. Distribution was the design.
Discovery built in. Pocket used what people saved to surface popular and recommended articles, later inside Firefox. This helped people find good reading, and blurred the line between "my list" and "a feed".
Tags, highlights, listen. Pocket added tags, highlights and text-to-speech. Useful, but each made the data more valuable to the user, and therefore made export more important.
The ending. Mozilla gave notice, kept export open for months after the service stopped, and pointed people at alternatives. That's a decent ending as endings go. But many people discovered that their tags, highlights and years of saved reading lived in a format other apps imported only partly.
Don't
A locked room. Without export, the user's history depends entirely on your company surviving.
Do
An open door. Plain formats, everything included, and a scheduled option so a backup exists before anyone needs it.
Steal this for your software
Count your "ways in" and make each one work: share sheet, email, extension, API.
Ship export on day one, including the user's metadata (tags, notes, timestamps), in plain formats.
Write your shutdown plan now: notice period, export window, recommended alternatives.
Keep "my list" and "suggestions" visually and structurally separate.
Do
Test your export by importing it into a competitor.
Include everything the user made, not just URLs.
Give generous notice if you ever close.
Don't
Treat export as an admin feature hidden in support docs.
Mix recommendations into a personal list.
Assume a big parent company means permanence.
In the wild
Google ReaderGoogle, 2005–2013
Its 2013 shutdown pushed millions to Feedly and others; Google Takeout let people export subscriptions as OPML. An open export format (OPML) made the migration possible.
Pocket shutdownMozilla, 2025
Announced in May, service ended in July, with an export window into October. Notice and export are the minimum ethical ending.
ObsidianDynalist Inc., 2020–
Stores notes as plain Markdown files in your folders. The strongest export is no lock-in at all.
For the solo creator
As a solo maker, your users' biggest unspoken fear is that you'll stop. Export is your answer. A visible "Export everything" button, and a sentence in your FAQ about what happens if you shut down, can win customers who would otherwise choose a bigger company. See Honest & Calm.
Common mistakes
Exporting only the obvious column
A list of URLs feels like an export. It loses tags, highlights, dates and read status, which are the user's real work.
Export every field the user created or changed.
Proprietary-only formats
A JSON dump in your own schema is technically an export, but no other tool reads it.
Offer at least one standard or human-readable format alongside the full dump.
Check yourself
You run a small highlights app with 2,000 paying users. Which single change does most for user trust?
Trust in a small product rests on "what happens if it ends". Pocket's closure made this concrete for many readers. A visible, complete, standard export answers it.
Exercise 9.1 45 minutes · your own product
Write your exit plan
List every kind of data a user creates in your product.
Check which of it your current export includes. If there's no export, list that as zero.
Write a short shutdown plan: notice period, export window, formats, alternatives you'd recommend.
Ship or schedule the smallest export that covers everything.
You're done when: you have a data inventory, an export gap list, and a five-line shutdown plan.
Beginner
Competent
Strong
Lists data types.
Export covers every type in a standard format.
Export has been tested by importing into another tool, and the plan is published for users.
10
Readwise Reader
Readwise Reader treats everything you read (articles, newsletters, PDFs, ebooks, feeds, video transcripts) as one stream with one set of tools, and then helps you remember it through daily review.
MakerReadwise
SinceReadwise (highlights) late 2010s; Reader beta 2022
CategoryRead-later, feeds, annotation, review
Study it forUnified inbox, triage, keyboard-first power use, spaced review
Readwise began as a service that pulled your Kindle highlights (and later highlights from many apps) into one place and resurfaced a few each day by email or in the app: a Daily Review. Reader, launched in public beta in 2022, is the reading app built to feed that system. Its premise is that the boundaries between "articles", "PDFs", "newsletters" and "feeds" are artificial. To a reader they're all text to triage, read, mark and remember. Reader is dense and powerful, and it is a useful counterpoint to the minimal products in this guide: power done thoughtfully.
Schematic, three panes. Library split into triage states and a separate Feed (1), every format in one list with type and length (2), the reading pane with highlights (3), a notebook that collects highlights and notes as you go (4), and Ghostreader AI tools kept in the side panel, not the text (5).
Library vs Feed. Things you chose to save go to the Library; things that arrive by subscription (RSS, newsletters) go to the Feed. This draws a firm line between "I decided this" and "this arrived", which keeps the Library from flooding.
Triage states, not folders. Inbox, Later, Shortlist, Archive. Each item is in exactly one state, and moving between them is one key. It's email triage applied to reading: decide quickly, read deliberately.
Every format, one toolset. Highlighting a PDF, an EPUB, a web article or a video transcript works the same way, and all highlights flow to the same place. One mental model across formats.
Keyboard first, mouse welcome. Nearly every action has a shortcut, with a command palette to find them. Power users can triage dozens of items a minute; newcomers can still click. See Breakdowns: Software for the same idea in Linear and Superhuman.
AI at the side. Ghostreader offers summaries, definitions, simplification and questions about the document, using a language model. It lives in the side panel and in explicit commands, not as text injected into what you're reading. See Designing with AI.
Review as the point. Readwise's Daily Review resurfaces a handful of past highlights each day, with spaced repetition options for ones you want to memorise. Reading isn't finished when you close the article; it's finished when you remember it.
Why daily review works (illustrative). Memory fades fast without retrieval. Each review at a growing interval restores it and slows the next decline. This is the spacing effect studied since Ebbinghaus; the shape here is schematic, not data.
Steal this for your software
Separate what users chose from what arrived. Two inboxes are calmer than one flooded one.
Use a few mutually exclusive states (like Inbox/Later/Archive) instead of open-ended folders.
Give every action a shortcut, and a palette to discover them.
Put AI next to content, invoked on purpose, never mixed into the user's text.
Close the loop: resurface what users saved so it pays them back.
Do
Make one highlight model work across all content types.
Show type and length in every list row.
Teach shortcuts in context (tooltips, palette), not in a manual.
Don't
Let subscriptions flow into the same list as deliberate saves.
Ship power features without sane defaults for newcomers.
Let AI rewrite or summarise inline without a clear label.
In the wild
Readwise Daily ReviewReadwise
A short daily session of past highlights, with options to master, tag or discard. A small daily ritual beats a big archive.
Superhuman2017–
Email triage with keyboard shortcuts and a command palette. Reader borrows email's best interaction pattern for reading.
AnkiDamien Elmes, 2006–
The open-source spaced repetition app. Spaced review is a mechanism, not a feature; it can live inside any product with saved items.
For the solo creator
You can't build Reader alone, but you can copy its structure. If your product collects things (notes, bookmarks, ideas), give it three states (Inbox, Later, Done), keyboard shortcuts for each, and a weekly resurfacing email. That is a week of work and it changes how people use the product.
Common mistakes
Copying the density, not the structure
Power apps look impressive; their three-pane density overwhelms people who came to read one thing.
Copy the states and the shortcuts. Keep the default view as calm as possible; let density be opt-in.
Review that nags
A daily email you feel guilty ignoring becomes noise and gets unsubscribed.
Keep review short (a handful of items), let people choose frequency, and never use streak guilt.
Check yourself
Your bookmarking app's users subscribe to 30 newsletters that also land in their saved list. Saves are getting buried. What's the Reader-style fix?
The problem is mixing two kinds of intent. Separating "arrived" from "chosen" restores the meaning of the saved list. Filters treat the symptom; limits and auto-archive punish users.
Exercise 10.1 45 minutes · a week of your own reading
Triage like Reader
Collect everything you meant to read this week (tabs, saves, newsletters, PDFs) into one list.
Triage it in 10 minutes: Later, Shortlist (this week), Archive (won't read). No reading allowed.
Read only from the Shortlist this week, highlighting what matters.
Next week, review your highlights for 5 minutes. Note which ones you'd forgotten.
You're done when: you have a triaged list, a week of highlights, and a note on what review brought back.
Beginner
Competent
Strong
Triage takes longer than 10 minutes.
Clean triage, Shortlist read.
You turn the experience into one design change for your own product's collection features.
11
Matter and Omnivore
Matter treats listening and reading as one activity, with audio that follows the text word by word; Omnivore showed what an open-source reader could be, and how fast a free product can disappear.
SinceBoth early 2020s; Omnivore shut down in late 2024
CategoryRead-later with audio; open-source read-later
Study it forText + audio sync, highlight-while-listening, open source and sustainability
The read-later category got a second wind in the early 2020s. Two products are worth studying side by side. Matter, an iOS-first app, built its identity around natural-sounding text-to-speech: you can listen to a saved article with the current word highlighted in the text, switch between reading and listening without losing your place, and highlight while listening. Omnivore was a free, open-source read-later app with highlights, labels, newsletters, PDFs and plugins for note apps like Obsidian. In late 2024 the Omnivore team joined ElevenLabs and the hosted service was shut down within weeks, with a short window to export. Its code remained available, but most users don't self-host.
Schematic of text and audio together. The spoken word highlighted in the text (1), a highlight made while listening (2), a scrubber in time units (3), and skip and speed controls large enough to use on a walk (4).
One position for two modes. Reading and listening share a single place in the text. Stop listening on the street, keep reading at home, from the same sentence.
Follow-along highlighting. Showing the spoken word in the text helps people who want to read and listen at once (a big help for some readers with dyslexia and for language learners), and makes it easy to drop back into reading.
Highlight while listening. A tap marks the passage just spoken. Annotation shouldn't require eyes on the screen.
Omnivore's openness. Open source meant transparency, self-hosting and community plugins. It didn't guarantee continuity of the hosted service people actually used. Openness of code and continuity of service are different promises.
Don't
Audio as a separate product. Listening position and reading position diverge; switching modes means hunting.
Do
One text, two modes. The highlight shows exactly where the voice is; stop and keep reading from there.
Steal this for your software
If you offer audio of text, keep one shared position and highlight the current word or sentence.
Make key actions possible without looking (highlight, skip 15 seconds).
If you're open source, still publish an export path and a continuity plan for the hosted service.
Do
Offer speed control in small steps (0.1×).
Resume audio a few seconds before where it stopped, so the sentence makes sense.
Make the export easy before you need it.
Don't
Treat "it's open source" as an ownership guarantee for users.
Read image captions, ads and navigation aloud.
Make the player full screen when the text is the anchor.
In the wild
Matterearly 2020s–
Text-to-speech with word-level follow-along and highlighting while listening. Listening is reading by other means.
Omnivore2022–2024
Free and open-source; hosted service closed in late 2024 after the team joined ElevenLabs. Users experience the service, not the licence.
Podcast apps (Overcast)Marco Arment, 2014–
Smart Speed shortens silences without making voices sound sped up. Audio controls can respect the content rather than just speed it up.
For the solo creator
Platform text-to-speech APIs and hosted voice models make "listen to this" a weekend feature now. The hard design work is not the voice; it's sharing position with the text and choosing what not to read aloud. Start with sentence-level highlighting; it's far simpler than word-level and almost as useful.
Common mistakes
Resuming at the exact millisecond
Restarting mid-word is disorienting.
Back up to the start of the sentence (or 3–5 seconds) on resume.
Free with no plan
A free product with real costs and no revenue has an end date, even if nobody says it.
Be honest about your model; if it's free, say how it will last or how users will leave.
Check yourself
Your language-learning reader adds audio. Learners say they get lost when they look away and back. What's the highest-value change?
The problem is losing the link between sound and text. A follow-along highlight restores it; the others don't address the cause.
Exercise 11.1 30 minutes · any TTS reader
Read with your ears
Use any read-aloud feature (Matter, Readwise Reader, Speechify, Safari's Listen to Page, or your phone's Speak Screen) on a 10-minute article.
Switch from listening to reading twice. Time how long it takes to find your place each time.
Try to highlight something while listening.
Write three changes that would make switching seamless.
You're done when: you have two switch times and three concrete changes.
Reader modes are a public verdict on web design: they exist because so many pages bury the text, and they work by guessing which part of the page is the article, then handing typography back to the reader.
MakersArc90 (Readability, 2009); Apple (Safari Reader, 2010); Mozilla (Firefox Reader View)
Study it forHeuristics, semantic HTML, user-controlled typography
In 2009 the design studio Arc90 released Readability, a bookmarklet that turned a cluttered page into clean text with good typography. It used heuristics: score each block of the page by how much text it has, how many commas, how few links, and what its class names suggest ("article", "content" up; "comment", "sidebar", "ad" down). Apple built Safari Reader (2010) using Readability's open-source code. Mozilla maintains its own Readability.js library, which powers Firefox Reader View. Today every major browser has some reader mode. The interesting part for a designer is the mechanism: your page is being scored by a machine trying to find your article. Semantic HTML helps it, and helps everyone.
The same article, reader mode off and on
NEWSTECHOPINIONVIDEOSHOPLOGIN
Advertisement · 728×90
Why We Re-read the Books We Love By A. Writer · 6 min read · 412 comments
Subscribe for ₹99/month! Cookie preferences · Accept all
We return to old books not for the plot, which we know, but for the person we were when we first read them.
Recommended for you · 6 stories ›
Each re-reading is a conversation with that earlier self, and the book is the room where it happens.
Sign up for our newsletter ✕
example.com · 6 min
Why We Re-read the Books We Love
A. Writer
We return to old books not for the plot, which we know, but for the person we were when we first read them.
Each re-reading is a conversation with that earlier self, and the book is the room where it happens.
Original: two sentences of article among six blocks of navigation, ads, prompts and counts. The eye must find the text on every screen.
Reader mode: source, title, byline, text. The reader chooses font, size, width and theme. Same words; very different experience.
Lab: how a reader mode decides what the article is
Simplified, inspired by Readability-style heuristics. Each block's score is based on its word count and commas, reduced by the share of its text that is links, and nudged up or down by its class name. Turn off the hints and the penalty and watch navigation and comments leak in; raise the threshold too far and the short second paragraph disappears. Real implementations are more complex, but the trade-off is the same.
Guess, then let the user fix it. Extraction is heuristic, so it will sometimes be wrong. The reader mode button only appears when the browser thinks a page is article-like, and the original is always one click away.
Typography handed to the reader. Reader modes offer a few faces, sizes, widths and themes. They assume the reader knows best about their own eyes, a reversal of the usual web, where the publisher decides.
A narrow column by default. Reader modes set a comfortable measure no matter how wide the window is. This one decision fixes the most common reading problem on desktop sites.
Listen and translate. Many reader modes add read-aloud, and some add translation or line focus (Microsoft Edge's Immersive Reader is the richest example). Once the text is clean, other tools can work on it.
Don't
Anonymous structure. Reader modes, screen readers and search engines all have to guess.
Do
Semantic structure. article, h1, p, aside, time and author metadata make extraction reliable and help accessibility.
Steal this for your software
Write semantic HTML for any long-form content: article, headings, p, aside, time, figure.
Design your own pages so a reader mode would add nothing.
If you extract content (scrapers, importers), always show the source and a way back to the original.
Give readers a small set of typography choices on long pages.
Do
Test your blog or docs in Safari Reader and Firefox Reader View.
Put the byline and date in machine-readable markup.
Keep related links and comments outside the article element.
Don't
Split one article across many pages.
Inject subscribe prompts between paragraphs as article content.
Block reader mode; it tells readers you fear what they'd choose.
In the wild
ReadabilityArc90, 2009
The bookmarklet that started it; its heuristic approach lives on in many tools. A small open tool can set a standard for a whole platform.
Safari ReaderApple, 2010–
Appears in the address bar when a page looks like an article; can be set to open automatically per site. Per-site memory turns a fix into a preference.
Edge Immersive ReaderMicrosoft
Adds line focus, syllable breaks, parts of speech and picture dictionary. Reading support for learners and dyslexic readers is a design space of its own.
For the solo creator
Your product's marketing site, blog and docs are being read in reader modes right now. Open each in Safari Reader. If the extraction misses your title, picks up your newsletter prompt or drops your code samples, your HTML structure is the issue, and it's usually an hour's fix.
Common mistakes
Designing for the screenshot
Wide hero layouts with tiny text look striking in a portfolio and read badly.
Design the long-form column first; let decoration sit around it.
Code and tables lost in extraction
Content inside generic containers or rendered by script may be dropped.
Use pre, table and figure in the server-rendered HTML.
Check yourself
Your docs site in Firefox Reader View shows the sidebar navigation instead of the page content. What's the likely cause?
Heuristics score blocks by text and hints. A long sidebar with many words can win if the article isn't clearly marked. Semantic structure fixes it.
Exercise 12.1 30 minutes · your own site
Pass the reader-mode test
Open your three longest pages in Safari Reader or Firefox Reader View.
Compare: title, byline, date, all paragraphs, images, code, tables. Note what's lost or added.
Fix the HTML structure for one page and re-test.
Then ask: what does reader mode do better than my own design? Copy that.
You're done when: one page extracts perfectly and you've made one change to your own design borrowed from reader mode.
Beginner
Competent
Strong
Notes problems.
Fixes structure on one page.
Your normal page is now as readable as its reader-mode version.
Part three recap: connect the ideas
Instapaper split capture from reading. Pocket made capture universal and taught the price of no exit. Readwise Reader made triage and review the core. Matter joined listening to reading. Reader modes proved that the clean text view is what people want from the web.
Framing the job exposes the real design targets: zero-cost capture at the bad moment, and an excellent reading surface at the good one.
Connect the ideas
Pocket and Omnivore both closed. What single design property would have most reduced user harm in both cases?
Ownership (criterion 10 of the scorecard) is invisible until the day it's the only thing that matters.
Part four
Streams, pages and voices
Not all reading is books or saved articles. Some arrives as a stream (feeds, newsletters), some lives on a page millions share (Wikipedia, Medium), and some is heard. These products have to answer harder questions about quantity, attention and form: how to show a thousand unread items calmly, how to set one page for a billion readers, and when listening counts as reading.
13
RSS readers: NetNewsWire, Reeder, Feedbin, Feedly
A feed reader decides how you feel about the world's output: as a debt to pay down (unread counts) or a river you dip into (timelines). Each of these four made a different choice.
ProductsNetNewsWire (Brent Simmons, 2002; open source since v5, 2019), Reeder (Silvio Rizzi, 2010), Feedbin (Ben Ubois, 2013), Feedly (2008)
CategoryFeed readers and services
Study it forUnread counts, triage, platform fit
RSS lets any site publish a feed of new posts, and lets you read all of them in one app, in order, without an algorithm. It's the original calm technology for reading the web, and it survived the 2013 shutdown of Google Reader, which pushed millions of users to services like Feedly. The four products here show the main design choices. NetNewsWire is a free, open-source, very Mac-like app: three panes, unread counts, keyboard shortcuts, nothing extra. Feedbin is a paid web service with a clean reader and a private email address for newsletters. Feedly grew into a discovery and research platform, now with AI features. Reeder, by Silvio Rizzi, was rebuilt in 2023 around a single timeline with no unread counts, keeping the older design available as Reeder Classic. (Breakdowns: Software covers Reeder's interaction design in more depth.)
The same feeds, two philosophies
All Unread1,284
Tech News Daily612
Design Weekly48
A friend's blog3
Science Digest591
Mark all as read?…
A friend's blog · On learning to bake bread2h
Design Weekly · The case for fewer settings4h
Science Digest · Why sleep matters for memory5h
Tech News Daily · 14 more poststoday
You're up to date with the last 2 days ↑
Unread counts: precise and complete, ideal for feeds where you must see everything (work alerts, a few friends). For high-volume sources it turns reading into a debt, and the loud feeds drown the quiet friend with 3 posts.
Timeline: recency instead of debt. High-volume feeds collapse into one line; the quiet friend rises. The app remembers where you were; nothing scolds you for what you skipped.
Schematic of the classic three-pane reader. Sources with optional counts and smart feeds (1), a list with a small unread dot instead of a number (2), and the article set as text (3). NetNewsWire and Reeder Classic follow this shape; it maps directly onto Mail, which is why it feels native on the Mac.
Counts as an option, not an accusation. Unread counts are honest for low-volume feeds and corrosive for high-volume ones. Good readers let you hide counts, per feed or globally, and show a small dot instead of a red number.
Timeline with memory (Reeder, 2023). One stream, newest at the top, with the app remembering your position. It reframes RSS from "inbox zero" to "what's happening", much closer to how people actually read feeds.
Platform fit (NetNewsWire). Standard Mac controls, standard keyboard shortcuts, standard three panes. People who know Mail know NetNewsWire. Brent Simmons has written about building it to be fast and stable rather than feature-rich.
Newsletters as feeds (Feedbin). A private email address that turns newsletters into feed items. It rescues reading from the inbox, where it competes with work.
Open source as continuity (NetNewsWire). Free and open source, with sync through several services, it's unlikely to disappear in a way that strands users. Compare Omnivore in chapter 11: open code helps most when the app runs locally.
Don't
Badge as debt. The number grows faster than anyone can read, so it only ever communicates failure.
Do
Presence, not quantity. A dot says "new"; collapsing loud sources keeps the quiet ones visible.
Steal this for your software
Before showing a count, ask: can the user ever reach zero? If not, show presence (a dot) or recency instead.
Collapse high-volume sources so low-volume ones aren't drowned.
Fit the platform; on the Mac, behave like a Mac app.
Give newsletters and other "reading" a home outside the work inbox.
Do
Let users hide counts, globally and per source.
Remember the scroll position in a timeline across launches.
Support OPML import and export; it's the RSS world's open door.
Don't
Badge the app icon with an unread total by default.
Sort by algorithm without telling the user.
Mark everything read on open; it destroys trust.
In the wild
NetNewsWire 5+Brent Simmons, 2019–
Free, open source, fast, native. Restraint and platform fit are features.
Reeder (2023)Silvio Rizzi
Unified timeline across feeds and social sources, no unread counts; the previous app continued as Reeder Classic. You can change a product's philosophy without abandoning existing users.
FeedbinBen Ubois, 2013–
Paid, clean, with newsletter email addresses. A small paid service can stay calm and sustainable.
Feedly2008–
Absorbed many Google Reader users in 2013, later added AI-assisted filtering for professionals. Different audiences (casual readers vs analysts) justify different densities.
For the solo creator
Look at every number in your product's UI (unread, pending, notifications, tasks). For each, ask whether the user can reach zero in a normal day. If not, replace it with presence or recency. This is a small change with a big effect on how your product feels. See Honest & Calm.
Common mistakes
Counts everywhere because they're easy
A count is a database query; it gets added by default.
Treat every count as a design decision: what should the user feel and do when they see it?
Losing the timeline position
Reloading to the top on every launch throws away the reader's place in the river.
Persist the top visible item and restore it.
Check yourself
Your team-updates app shows "Unread updates: 87" to each user. Most users never get below 50. What should you do?
An unreachable count only signals failure. Recency framing and collapsing loud sources match how people actually read streams.
Exercise 13.1 40 minutes · NetNewsWire or any feed reader
One week of feeds, two ways
Subscribe to 10 feeds of mixed volume (one or two daily-news feeds, several personal blogs).
For three days, read with unread counts visible. For three days, hide counts (or use a timeline app).
Each day, note: minutes spent, how you felt opening the app, and whether you read the low-volume blogs.
You're done when: you have six short daily notes and one paragraph on which framing you'd ship and why.
Beginner
Competent
Strong
States a preference.
Compares time, feeling and coverage of quiet feeds.
Applies the finding to a number in your own product.
14
Medium and Substack
Medium made the single article page beautiful by default and gave it reading time and inline highlights; Substack moved reading into the inbox and then into its own app. Both show how a writing platform's reading page shapes what gets written.
MakersMedium (Ev Williams, 2012); Substack (2017)
CategoryPublishing platforms with reading surfaces
Study it forReading time, default typography, highlights as social reading
Medium launched in 2012 when most blogs looked like templates from 2005. Every Medium post got the same thing: a generous serif column, big images, a clean title, and nothing in the margins. Writers didn't have to design anything, and readers got a consistent, good page. Medium added an estimated reading time to every post. Its help documentation describes it as based on an average adult reading speed of about 265 words per minute, with extra time for images. Readers could highlight text and see the passages others highlighted most ("Top highlight"). Substack, founded in 2017, made the newsletter the primary format: posts arrive by email and also live on a web page and, later, in Substack's own reading app.
Schematic of the single-column article. A strong title (1), a byline that includes reading time (2), aggregated "top highlight" (3), a column of about 680–700px giving a comfortable measure (4), and a small sticky action bar outside the column (5).
One layout for everyone. Writers can't change fonts or colours. This removes bad design choices from the platform and makes every post feel like part of one publication. The cost is personal expression; Substack and others later offered more customisation.
Reading time in the byline. "7 min read" answers "should I start this now?" before the first sentence. It also changed writing: authors and editors began thinking in read-minutes, and Medium at times used reading time in how it measured engagement.
Highlights as social reading. Highlighting is private by default, but aggregated highlights appear to others. It turns a solo act into a quiet signal, with the same steering risk as Kindle's Popular Highlights.
Inline responses and notes. Medium experimented with notes in the margin next to paragraphs and later with responses as full posts. Commenting next to the text is precise; it can also clutter the column.
Substack: the inbox as the reading surface. Email arrives reliably and is owned by the reader. But the inbox is a work tool, full of competing demands. Substack's app and web reader try to give newsletters a calmer home.
Paywalls and prompts. Both platforms show subscribe prompts and paywalls. Where they sit (top, mid-article, end) is a reading-design decision with a business motive. Mid-article prompts break immersion most.
Don't
Ask in the middle. Breaks the thought at the moment of greatest immersion, before the reader has received the value.
Do
Ask at the end. After the reader got the value, when "more like this" is a natural thought.
Steal this for your software
Show reading time next to every long piece; round to whole minutes.
Constrain authors' styling when consistency serves readers better than expression.
Put asks (subscribe, share, upgrade) at natural endings, not in the middle.
If you aggregate reader behaviour (highlights, claps), make it opt-out and never shame low numbers.
Do
Keep the reading column around 600–720px on desktop.
Let images go wider than the text column for emphasis.
Keep actions in a quiet bar outside the text.
Don't
Insert modals or banners at scroll depth thresholds.
Show vanity metrics above the article.
Use reading time as a proxy for quality.
In the wild
Medium reading timeMedium
Based on about 265 words per minute plus an allowance for images, per its help documentation. Show the model, round the output.
Substack appSubstack
A dedicated reading app for subscriptions, separate from email. Move reading out of work spaces when you can.
GhostGhost Foundation, 2013–
Open-source publishing with themes focused on readable article pages and member newsletters. Ownership for writers is the same principle as export for readers.
For the solo creator
If you publish a blog or newsletter about your product, you are running a Medium-style reading page. Give it one fixed, excellent layout, a reading time, and one quiet ask at the end. That is a stronger brand signal than any landing-page redesign.
Common mistakes
Reading time that lies
Counting only body words ignores code, tables and images; or estimates pad to look substantial.
Count all visible text, add a fixed allowance per image or code block, and round honestly.
Highlight UI that fights selection
A toolbar that pops up on every text selection blocks copy and hides the text you just selected.
Show it above the selection, small, and never cover the selection itself.
Check yourself
Your product blog gets good traffic but few newsletter signups. A modal appears at 40% scroll. What change is most likely to improve both reading and signups?
Asking after value is delivered converts the readers who are actually interested, and doesn't punish everyone else mid-thought.
Exercise 14.1 30 minutes · your blog, docs or changelog
A Medium-grade article page
Take your longest public page.
Measure: column width, characters per line, body size, line height.
Add a reading-time estimate and move any mid-article asks to the end.
Compare before and after on your phone.
You're done when: the page has a 45–75 character measure, a reading time, and no mid-article interruptions.
Beginner
Competent
Strong
Adds reading time.
Fixes measure and moves asks.
Turns the result into a reusable template for every future post.
15
Wikipedia's Vector 2022
Wikipedia's 2023 desktop redesign shows how hard it is to change a reading page used by hundreds of millions of people: limiting line length, a sticky header and a persistent table of contents were well supported by reading research, and still deeply contested by the people who used the old page most.
MakerWikimedia Foundation, with community input
Default on English WikipediaJanuary 2023
CategoryReference reading, desktop web
Study it forMeasure, wayfinding, redesign at scale
For over a decade, Wikipedia's desktop skin (Vector, from 2010) stretched text across the full width of the browser window. On a big monitor that meant lines of 150 characters or more. Vector 2022, developed over several years and rolled out first on a number of smaller-language Wikipedias, limited the content width, added a sticky header with the article title and search, moved the table of contents into a sidebar that stays visible as you scroll, and collapsed the main menu. It became the default on English Wikipedia in January 2023, after a long and divided community discussion. Logged-in users can switch back to the old skin, and anyone can toggle full width.
Lab: the line-length decision
Typography
Typography is the art and technique of arranging type to make written language legible, readable and appealing when displayed. The arrangement of type involves selecting typefaces, point sizes, line lengths, line spacing and letter spacing, and adjusting the space between pairs of letters. Readers rarely notice good typography; they notice when reading feels tiring, when lines are so long that the eye loses its place on the return sweep, or so short that the rhythm keeps breaking.
Try it. At full width on a large window, count how often you lose the line. Then switch to limited width. The estimated characters per line updates as you go. On a phone this lab is already narrow, which is the point: the problem only existed on wide screens.
Limited width. A comfortable measure makes long reading less tiring. On wide monitors the old design was far outside the range typographers recommend. The cost: empty space on the sides, which some readers saw as wasted, and tables and images that had more room before. A full-width toggle keeps the choice.
Sticky header. Title, search and tools stay reachable while scrolling a long article. On a reference site, search is a primary action, often used mid-article.
Table of contents in a sidebar. Long articles become navigable: you see where you are and can jump without scrolling to the top. Wayfinding, the reference-reading equivalent of "time left in chapter".
Collapsed main menu. Links most readers never use moved behind a menu button, which saved space and reduced noise, and annoyed editors who used them daily.
Gradual rollout, with research. The Foundation deployed to smaller wikis first, tested features, and published findings and documentation. The English Wikipedia discussion still showed many editors opposed. The lesson: research can tell you what helps most readers; it doesn't remove the cost to experts whose habits change.
Same article, two layouts (schematic). The new layout trades horizontal space for a readable measure, and spends some of it on wayfinding (sticky header, TOC sidebar). Proportions are illustrative.
Steal this for your software
Cap the width of reading text on wide screens; let tables and figures break out wider.
For long reference pages, keep a table of contents visible with the current section marked.
Make search reachable from anywhere in a long page.
Roll out big reading changes gradually, with an opt-out for experts.
Do
Explain the reasoning publicly when you change a familiar reading layout.
Keep a width toggle for people who need tables or have special setups.
Highlight the current section in the TOC as the reader scrolls.
Don't
Assume "more on screen" means "easier to read".
Hide tools experts use daily without a fast path back.
Ship a redesign to everyone at once with no way back.
In the wild
Vector 2022Wikimedia, 2023 on English Wikipedia
Limited width, sticky header, TOC sidebar, full-width toggle. Readability research and expert habits can pull in opposite directions; give both a path.
MDN Web DocsMozilla
Sidebar navigation plus an "In this article" outline that tracks scroll. Two levels of wayfinding for long technical pages.
Stripe DocsStripe
Narrow prose column with code alongside on wide screens. Use spare width for related content, not longer lines.
For the solo creator
The Vector 2022 width decision is one line of CSS: max-width: 70ch (or similar) on the prose container. If your docs or help center don't have it, that's today's fix. Then add a sticky outline for any page longer than three screens.
Common mistakes
Limiting everything to the text width
Tables, code and diagrams get squeezed and scroll sideways.
Limit prose, not figures; let wide content extend or scroll inside its own container.
Ignoring the vocal minority
Experts are fewer but use the product most, and they create its content.
Give them preferences and fast paths; don't design the default around them.
Check yourself
Power users of your internal wiki complain loudly about a new limited-width layout. Analytics show the median reader spends more time reading. What do you do?
This is the Wikipedia resolution: a research-backed default for most readers, a preference for experts, and transparency about why.
Exercise 15.1 30 minutes · Wikipedia and your docs
Wayfinding audit
Open a long Wikipedia article on desktop. Use the TOC sidebar, sticky header and width toggle.
Open your own longest page. Note: max characters per line, is there an outline, can you search mid-page, do you know where you are?
Add the cheapest missing piece.
You're done when: your longest page has a capped measure and at least one wayfinding aid.
Beginner
Competent
Strong
Caps width.
Adds an outline or sticky title.
Outline tracks scroll and highlights the current section.
16
Listening as reading: Audible, Apple Books, Speechify
The best audio reading products treat a book as one work in two forms, so you can move between eyes and ears without losing your place, and use the text to support the voice.
ProductsAudible (Amazon since 2008), Whispersync for Voice (2012), Immersion Reading; Apple Books audiobooks; Speechify
CategoryAudiobooks and text-to-speech
Study it forCross-format continuity, audio controls, accessibility
Is listening to a book "reading" it? For a designer the useful answer is: it's the same book, in a different form, for a different moment. Amazon made this concrete in 2012 with Whispersync for Voice: if you own both the Kindle book and the matching Audible audiobook, your position syncs between them. Immersion Reading goes further and plays the narration while highlighting the text as it's read, on supported Kindle apps and Fire tablets. Apple Books keeps audiobooks in the same library as ebooks. Speechify, a text-to-speech app, reads any text (web pages, PDFs, scans) aloud with follow-along highlighting; its founder has spoken about growing up with dyslexia, and the product grew from that need.
One book, two forms, one position. Text alignment maps each moment of narration to a place in the text, so either form can resume from the other's furthest point. The confirm step matters because people sometimes listen ahead, re-listen, or share accounts.
Align audio to text. The underlying work is alignment: knowing which sentence is spoken at which second. Every feature (sync, follow-along, highlight while listening) comes from that one map.
Confirm, don't jump. Cross-format sync suggests the furthest position and asks, just like device sync on Kindle.
Controls for hands-busy moments. Big skip-back (15 or 30 seconds), sleep timers, speed in small steps, lock-screen and headphone controls. Listening usually happens while doing something else.
Text as support for the voice. Follow-along highlighting helps people with dyslexia, language learners and anyone who wants to read faster with audio pacing. It's an accessibility feature that many people simply enjoy.
Bookmarks by time and text. An audio bookmark should show the sentence, not only "2:14:07".
Don't
Time without meaning. A timestamp is the audio version of a Kindle location: precise and useless to a human.
Do
Meaning first. The aligned text gives each bookmark words you can recognise.
Steal this for your software
If content exists in two forms (video and transcript, audio and text), build one position map and share it.
Label time-based items with the words at that time.
Design controls for eyes-free use: big targets, headphone buttons, a sleep timer.
Treat accessibility features as features for everyone, and make them easy to find.
Do
Offer 15–30 second skip-back as the most prominent secondary control.
Remember speed per book.
Back up a few seconds on resume.
Don't
Keep separate libraries for listening and reading of the same work.
Show only timestamps in bookmarks and clips.
Auto-play the next item without a clear setting.
In the wild
Whispersync for VoiceAmazon, 2012
Switch between Kindle book and Audible narration at the same place. Continuity across forms, not just devices.
Immersion ReadingAmazon
Narration plus text highlighting on supported apps and devices. Two senses at once can help comprehension and focus.
YouTube transcriptsGoogle
Click any line of the transcript to jump the video there. The same alignment idea, applied to video.
For the solo creator
If your product has video tutorials or a podcast, a time-aligned transcript is a high-value feature you can build with off-the-shelf speech recognition: searchable, skimmable, accessible, and every line a link into the media. See Accessible & Inclusive.
Common mistakes
Speed controls in big jumps
Only 1×, 1.5× and 2× leaves many listeners between steps.
Offer 0.1× steps around the common range (0.8–2×).
Treating TTS as a checkbox
A robotic voice reading navigation and captions is worse than nothing.
Read only the content, in order, with sentence highlighting and natural pauses at headings.
Check yourself
Your course app has video lessons and written notes for each. Learners switch between them and lose their place. What's the core fix?
The problem is two forms with two positions. Alignment gives one shared position, which is exactly Whispersync for Voice.
Exercise 16.1 30 minutes · any audiobook or TTS app
Hands-busy test
Listen to 15 minutes of an audiobook or TTS article while walking or cooking.
Without looking, try to: skip back, change speed, bookmark something.
Later, find the bookmark. Is it recognisable?
Write three improvements and which one you'd copy into your product.
You're done when: you have pass/fail for three eyes-free tasks and three improvements.
Beginner
Competent
Strong
Notes the voice.
Tests eyes-free tasks and bookmark recall.
Maps the findings onto a feature of your own product.
17
The reader-friendly web: Gwern.net, Practical Typography, Craig Mod
A few independent websites show what reading on the web can be when the writer controls everything: sidenotes beside the text, previews instead of jumps, and typography argued for in public.
MakersGwern Branwen (with Said Achmiz on design); Matthew Butterick; Craig Mod
CategoryIndependent long-form websites and essays
Study it forSidenotes, popups, web typography, the idea of digital books
Some of the best reading products aren't apps at all. Gwern.net is a personal site of long, heavily referenced essays. Its design (developed with Said Achmiz) puts footnotes as sidenotes in the margin on wide screens, shows link and footnote previews in popups on hover so you don't leave the page, and offers a reader-friendly dark mode and other options. Matthew Butterick's Practical Typography (2013) is a web book about typography that is itself an example of its own advice: a narrow serif column, careful spacing, and a pay-what-you-want model. Craig Mod's essays, from "Books in the Age of the iPad" (2010) and "Post-Artifact Books and Publishing" (2011) to "Future Reading" (Aeon, 2015), argued that digital books should stop imitating paper and start using what screens can do: connection, annotation and the edges around the text.
Notes: at the bottom, or beside the text
Early readers of printed books often wrote in the margins14, and those notes were read by the next owner.
⋮ 2,300 words later ⋮
14. On marginalia, see the history of the annotated book. ↩ back
Early readers of printed books often wrote in the margins14, and those notes were read by the next owner.
14 On marginalia, see the history of the annotated book.
On hover or tap: a preview of a linked page or note appears in place; the reader never leaves the sentence.
Endnote jump: the reader leaves the sentence, reads the note 2,300 words away, and has to find their way back. Many simply skip notes.
Sidenote and popup: the note sits next to the sentence on wide screens, and appears inline on tap on phones. The margin becomes part of the reading, as it was in print.
Margins are for notes (Gwern.net, Tufte CSS). On wide screens, unused margins become a place for notes, aligned to the line that references them. This uses the space that a limited measure creates, the same space Vector 2022 left empty.
Preview, don't navigate. Popups for links and footnotes let readers check a reference without losing their place. They need care: delay before showing, easy dismissal, and a tap equivalent on touch screens.
Typography as argument (Butterick).Practical Typography explains each rule (line length, point size, spacing, quotes) and demonstrates it on the same page. The site is its own proof.
Pay what you want for reading. Butterick asks readers to pay if the book is useful (or buy his fonts). The model keeps the page free of ads and pop-ups. Business model as reading design, again.
Post-artifact thinking (Mod). Mod argued that the most interesting changes in digital books happen around the text: sharing, annotation, collective marginalia, the network of readers, not in imitating page curls. Many products in this guide (Popular Highlights, Readwise, Medium highlights) are versions of that idea.
Sidenotes put the reference where the eye already is. The layout has to handle collisions (two notes close together) and narrow screens (notes become tap-to-expand). Tufte CSS and Gwern.net each solve both.
Steal this for your software
Use spare width beside a capped text column for notes, definitions or related items.
Preview links in place in any reading surface; navigate only on a deliberate click.
Make your documentation demonstrate its own advice.
Look for value "around the text": notes, shared highlights, links between readers.
Do
Delay hover previews slightly (a few hundred milliseconds) to avoid flicker.
Give every popup a tap equivalent and an obvious close.
Fall back to inline notes on narrow screens.
Don't
Open popups on the slightest mouse pass.
Put critical content only in hover states.
Use sidenotes at widths where they squeeze the main column.
In the wild
Gwern.netGwern Branwen
Sidenotes, recursive popups for links and notes, extensive typography options. A personal site can out-design platforms because its writer cares about every detail.
Practical TypographyMatthew Butterick, 2013–
A free web book about typography, set to its own rules. The medium is the proof.
Tufte CSSDave Liepmann
An open stylesheet inspired by Edward Tufte's books, with sidenotes and margin figures. Patterns from print can be packaged for anyone to use.
For the solo creator
Your own site is the one reading product where you have total control. Use it. A capped column, good type, sidenotes or inline notes, link previews and no pop-ups will make your writing about your product more persuasive than any marketing layout. See Reading & Writing.
Common mistakes
Hover-only features
Popups designed with a mouse vanish on touch screens.
Every hover preview needs a tap path and a keyboard path.
Margins full of chrome
Spare width tempts us to fill it with share buttons and ads.
Reserve the margin for material that serves the text: notes, figures, definitions.
Check yourself
Your API docs link heavily to other pages. Readers open ten tabs and get lost. What's the best reading-product fix?
Previews answer "what is this?" without breaking the reading flow, which is the Gwern.net idea applied to documentation.
Exercise 17.1 45 minutes · read one essay deeply
Read like a designer, on the open web
Read one long essay on Gwern.net, one chapter of Practical Typography, and Craig Mod's "Books in the Age of the iPad".
For each, note three reading-design decisions you noticed and one you'd change.
Pick the one decision you'll apply to your own site or docs this week.
You're done when: you have nine observations, three critiques and one committed change.
Beginner
Competent
Strong
Describes the look.
Names mechanisms (sidenotes, popups, measure).
Connects Mod's ideas to a feature you could build.
Part four recap: connect the ideas
Feed readers taught the cost of counts. Medium taught reading time and the power of one good default layout. Wikipedia taught measure and wayfinding at scale. Audio products taught continuity across forms. The independent web taught what's possible when the margins work for the reader.
Connect the ideas
Vector 2022's empty side space and Gwern.net's sidenotes are two answers to the same situation. What is it?
Capping line length (see Typography) always creates leftover space on wide screens. Both answers are valid; filling it with chrome is the wrong one.
Connect the ideas
Unread counts, popular highlights and reading-time metrics all share a risk discussed in Honest & Calm. Which?
Each is useful in moderation, and each can become an attention trap. The calm answer: opt-in or easy opt-out, and never shame.
Part five
Synthesis
Fifteen products, one lens. This part puts them side by side, extracts the patterns worth stealing and who does each best, and ends with a capstone: a one-page spec for your own reading product or reading surface.
18
The comparison and the pattern library
Taught by every product in this guide
No reading product wins every criterion; the great ones choose which half (surface or system) to be best at, and refuse to be bad at defaults.
Below are illustrative scores using the chapter 1 scorecard. They are the opinions of this guide, formed from the decisions described in each chapter, not measurements. Your scores should differ; the value is in arguing with them. Under the table, if you saved scores in the chapter 1 lab, your own table appears too.
Product
Type
Dflt
Ctrl
Nav
Annot
Sync
Lib
Disc
A11y
Own
Total
Kindle
2
2
2
3
3
3
2
1
3
1
22
Kobo
3
2
3
2
2
2
2
2
2
3
23
Apple Books
2
3
2
2
2
3
2
2
3
2
23
Libby
2
2
2
2
1
2
2
3
2
1
19
Instapaper
3
3
2
1
2
2
2
3
2
2
22
Readwise Reader
2
2
3
2
3
3
3
2
2
3
25
NetNewsWire
2
2
1
2
0
2
2
3
2
3
19
Reeder (2023)
3
3
2
2
1
2
2
3
2
2
22
Medium
3
3
0
1
2
1
1
1
2
1
15
Wikipedia
2
2
2
3
0
0
1
3
2
3
18
Standard Ebooks, Gwern.net and the reader modes are left out because they are a surface without a full system (or a system you supply yourself). Pocket and Omnivore are left out because they no longer run. Annotation is 0 for NetNewsWire and Wikipedia because they don't aim to offer it, which is a valid choice.
Two axes, using the illustrative scores. Products cluster by strategy: Readwise Reader leads on system, Medium has the thinnest system, Wikipedia trades system features for a strong page, and Kindle, Kobo, Apple Books and Reeder cluster high on both. Nobody reaches the top right corner. Plot your own scores the same way.
The pattern library
Every pattern in this guide, with the product that does it best and where it belongs in your own work. Treat it as a menu, not a checklist: a good product picks the few that serve its job.
Pattern
Best at it
Why it works
Use it when
Progress in time
Kindle "time left in chapter"
Answers "can I finish?" in the reader's units, from their pace
Any long content: lessons, docs, articles
Live-preview settings
Kobo half-sheet
Judging a change while seeing it removes guesswork
Any appearance or density setting
Opinionated presets
Apple Books themes
Tested combinations instead of infinite knobs
More than three related settings
Sync that asks
Kindle Whispersync
Continuity without surprise jumps
Multi-device state
Cross-format position
Whispersync for Voice, Matter
One position, two forms
Audio/video plus text
Zero-cost capture
Instapaper
Busy moment costs nothing; organise later
Saving, clipping, quick add
Triage states
Readwise Reader
Few exclusive states beat folders
Any inbox-like collection
Resurfacing
Readwise Daily Review
Spaced retrieval makes saved things pay back
Highlights, notes, bookmarks
Honest waits
Libby holds
Position + estimate + defer path
Queues, exports, generation
Typography pass
Standard Ebooks
Many micro-fixes, applied systematically
Anywhere text is rendered
Semantic structure
Reader modes
Machines (and assistive tech) find the content
Any long-form web page
Presence, not counts
Reeder (2023)
No unpayable debt
Streams where zero is unreachable
Reading time
Medium
Decide before starting
Lists and headers of long items
Capped measure + wayfinding
Wikipedia Vector 2022
Comfortable lines; always know where you are
Reference and docs
Sidenotes and previews
Gwern.net
References without leaving the sentence
Heavily linked or annotated text
Lookup to learning
Kindle Vocabulary Builder
Incidental actions become value
Any lookup or search history
Complete export
Readwise, NetNewsWire (OPML), Standard Ebooks
Trust that survives the company
Always
Don't
The menu, ordered all at once. Each pattern is good; together they bury the text.
Do
Three patterns, chosen for the job. The others exist one tap away, in the moments where they belong.
Do
Pick the half (surface or system) you will be best at.
Get defaults to a 2 or 3 before adding anything else.
Map each pattern you adopt to a moment of the session.
Don't
Copy a competitor's feature list.
Put system features (counts, AI, social) inside the Immerse moment.
Leave Ownership at 0 because "nobody asks".
In the wild
Kindle vs Kobo2010s–2020s
The same job, opposite strategies: closed system and convenience vs openness and control. Strategy decides which criteria you sacrifice.
Reeder Classic and Reeder2023
Two philosophies from one designer, shipped side by side. Sometimes the honest answer to "which is right?" is "for whom?".
iA WriterInformation Architects
A writing app with a reading-grade surface: tuned fonts, measure and focus mode. Reading patterns transfer to any text product. See Breakdowns: Software.
Checklist: the reading surface of your product
Surface
Session
System
For the solo creator
You can't build a Kindle, but you can be a 3 at Defaults, Typography and Ownership in a weekend. Those three are where solo products beat big ones: you have no store to push, no engagement team to please, and full control of your CSS.
Common mistakes
Averaging away strategy
A total score hides that products choose to be weak somewhere.
Read the profile (the shape of the bars), not just the total.
Treating the pattern library as a roadmap
Seventeen good patterns become a two-year backlog and a crowded screen.
Choose three for your product's job and one moment each.
Check yourself
You're building a calm long-form newsletter reader alone. Which three patterns give the most value for the effort?
These cover the surface, the session and trust, and each is achievable by one person. The others are either expensive or work against calm.
Exercise 18.1 60 minutes · three apps you use
Your own comparison
Score three reading apps you use in the chapter 1 lab (save each).
Compare your table above with the illustrative one. Where do you disagree by 2 or more points? Write why.
Plot the three on the surface/system chart on paper.
Choose the three patterns from the library that your own product most needs.
You're done when: three saved scores, a list of disagreements with reasons, a plot, and your three chosen patterns.
Beginner
Competent
Strong
Scores without disagreements.
Disagreements are explained with observations.
Chosen patterns are tied to your product's job and a session moment each.
19
Capstone: design your ideal reading app
Taught by you, with everything above
A good reading-product spec fits on one page: who reads what, when; the six moments and what the screen does in each; the defaults; and the few decisions you will defend.
This is where the breakdowns turn into design. You'll write a one-page spec for a reading product, or for the reading surface inside your own product. Keep it short on purpose. A spec that fits on one page forces you to decide; a twenty-page spec lets you avoid deciding. The template below follows the structure of this guide: job, scorecard targets, session moments, defaults, decisions with costs, and what you deliberately leave out.
Six blocks, one page. The left labels show where in this guide each block's thinking comes from.
The template
READING PRODUCT SPEC · [name] · v0.1 · [date]
1. JOB
Reader: [who, specifically]
Content: [books / articles / docs / feeds / transcripts …]
Moment: [when and where they read; device; minutes per session]
Job: "When I [situation], I want to [motivation], so I can [outcome]."
2. SCORECARD TARGETS (0–3)
Must be a 3: [e.g. Defaults, Typography, Ownership]
Fine at a 2: [...]
Deliberately low: [e.g. Discovery = 1, we don't recommend]
3. SESSION MOMENTS
Arrive: [what opens first; taps to reading]
Settle: [settings reachable how; preview?]
Immerse: [what is visible; how chrome hides]
Mark: [highlight / note / lookup; where it goes]
Leave: [what is saved]
Return: [what another device shows; does it ask?]
4. DEFAULTS
Typeface [..] · size [..px] · line height [..] · measure [..ch]
Alignment [..] · theme [..] · progress unit [..]
5. DECISIONS (each with its cost)
D1 [decision] because [reason]. Cost: [...]
D2 ...
D3 ...
D4 ...
D5 ...
6. NOT DOING
[feature] because [reason].
[feature] because [reason].
A worked example
Here is how the first blocks might look for a small product: a reader for long-form engineering blogs, built by one person. Note how the scorecard targets make later decisions easy.
Reader: a working developer who follows 20–40 engineering blogs. Content: long technical posts with code and diagrams. Moment: evenings and weekends, mostly on a laptop, sometimes on a tablet, 15–45 minutes. Job: "When a great engineering post appears, I want to read it properly with its code and figures, so I can actually learn from it instead of skimming."
Must be 3: Typography (including code blocks), Defaults, Ownership (OPML in, Markdown highlights out). Fine at 2: Annotation, Sync, Navigation. Deliberately low: Discovery (1). No recommendations; the user's subscriptions are the curation.
Arrive: opens to a timeline of posts from the last 7 days, newest first, no counts. Settle: one half-sheet with three presets. Immerse: text, code and figures only; toolbar hides on scroll-down. Mark: select to highlight, highlights collect in a per-post notebook. Leave/Return: scroll position syncs; a jump of more than one screen asks first.
D1 Timeline, no unread counts, because volume varies wildly between blogs. Cost: completionists lose a sense of "done". D2 Code blocks scroll horizontally inside their own box, never wrap, because wrapping breaks code meaning. Cost: some scrolling on tablets. D3 No AI summaries in v1, because the job is learning, not skipping. Cost: a feature competitors list. D4 Highlights export to Markdown files, because the audience lives in text editors. Cost: no rich formatting.
Don't
A wish list. It decides nothing, so every later decision gets made under pressure.
Do
A spec. Short, specific, with costs written down so you can revisit them honestly.
Do
Write numbers for every default.
Write the cost of every decision.
Prototype the Immerse screen in HTML before anything else.
Don't
Spec features without a moment.
Leave "Not doing" empty.
Exceed one page in v0.1.
In the wild
Instapaper, 2008Marco Arment
A one-person product whose whole spec could be: save in one tap, read beautifully offline, pay once. Small specs make small, excellent products.
Reeder (2023)Silvio Rizzi
One designer rethought the whole model around a timeline. A single strong decision can define a product.
Standard Ebooks ManualVolunteers
The spec is public and the product is consistent because of it. Written decisions scale.
For the solo creator
Design in code. Once your one-page spec is done, build the Immerse screen as a single HTML file with real content and your defaults. Read on it for a week before building anything else. If the reading isn't great, no feature will save the product.
Common mistakes
Starting with the library screen
Lists, filters and settings are easy to design and fun to build.
Start with the reading screen; it's where the user spends 90% of the time.
Decisions without costs
Writing only benefits makes every decision look free.
For each decision, write who loses and what. If nobody loses, it isn't a decision.
Check yourself
You have two weeks to build a reading-focused v1 alone. What do you build first?
The reading surface is the product. Capture gets content in; export earns trust. Everything else can wait.
Exercise 19.1 3 hours over two sittings · capstone
Write and prototype your reading spec
Choose: a new reading product, or the reading surface inside your own product.
Fill the template above. Keep it to one page.
Steal three patterns from chapter 18; name the product you took each from.
Build the Immerse screen as one HTML file with real content and your defaults.
Read on it for 20 minutes on your phone and laptop. Score it on the chapter 1 scorecard (Surface criteria only).
Revise the spec once based on what you felt.
You're done when: you have a one-page spec (v0.2), an HTML reading prototype, and a scorecard entry for it.
Beginner
Competent
Strong
Spec lists features; prototype is a mock-up image.
Spec covers all six blocks with numbers and costs; prototype is real HTML.
Prototype scores 3 on Typography and Defaults, and the revision shows a decision you changed because of reading on it.
Wrap-up
Ten things to remember
A reading product's job is to disappear; judge it by how little of its interface you remember after ten minutes.
Defaults are the product. Most readers never open settings.
Settings must preview live on the real text, ideally in a half-sheet (Kobo).
Presets carry a design opinion; knobs without presets push the work onto readers (Apple Books).
Show progress in the reader's units: time, real pages, sections (Kindle, Medium).
Split capture from reading; capture should cost nothing (Instapaper).
If zero is unreachable, don't show a count (Reeder).
Translate system states into positions, times and choices (Libby).
Cap the measure; use the spare width calmly or for notes (Wikipedia, Gwern.net).
Export is trust. Products end; what users made shouldn't (Pocket, Omnivore).
Self-assessment: I can…
Practice assignment for the next two weeks
Days 1–3: score. Use five reading products you have access to (at least one e-reader app, one read-later or feed app, one web page). Save each in the chapter 1 lab with observations.
Days 4–5: session maps. Run the chapter 2 protocol on your two favourite and your own product. Shade the loud moments.
Days 6–7: quick fixes. On your own product: cap the measure, fix the default size and line height, add a typography pass. Measure before and after.
Days 8–10: one system pattern. Add one: reading time, live-preview settings, zero-cost capture, presence instead of counts, or export.
Days 11–13: capstone. Write the one-page spec and build the HTML Immerse prototype.
Day 14: reflect. Re-score your product. Write half a page: what changed in the numbers, and what changed in how reading it feels.
Reading list
Books in the Age of the iPad (2010), Post-Artifact Books and Publishing (2011)
Craig Mod · the clearest early thinking on which digital books should be "formless" and which need form, and on value around the text.
Future Reading (Aeon, 2015)
Craig Mod · why e-reading stalled and what was missing; a good critique to read beside the Kindle chapter.
The "Future Book" Is Here, but It's Not What We Expected (Wired, 2018)
Craig Mod · argues the real innovation happened in how books are made, funded and discussed, not in the reading screen.
Practical Typography
Matthew Butterick · free web book; the most usable rules for body text, demonstrated on its own pages.
The Elements of Typographic Style
Robert Bringhurst · the reference behind measure, leading and much of what good e-readers try to automate.
Web Design is 95% Typography (2006)
Oliver Reichenstein (iA) · short, opinionated, still right; read it with the Medium and Wikipedia chapters.
Standard Ebooks Manual of Style
Standard Ebooks · a real, public style system for prose; use it as a model for your own product's text rules.
Reader, Come Home (2018)
Maryanne Wolf · a neuroscientist on how screen reading changes deep reading; useful to remember what your product is protecting.
The Coming Age of Calm Technology (1996)
Mark Weiser and John Seely Brown · the origin of "calm" as a design goal; the frame behind counts vs presence.
inessential.com
Brent Simmons · decades of writing on building NetNewsWire: platform fit, restraint and open source.
Readability.js (Mozilla, on GitHub)
The code behind Firefox Reader View; reading it shows exactly how pages are scored for "article-ness".