Reading & Writing. Software that gets out of the way of words.

Warm-up: what do you already notice?

Before we start, spend five minutes with the reading app you use most: Kindle, Apple Books, a read-later app, an RSS reader, or just Safari's Reader view. Read one page of anything. Then answer the two questions below without looking anything up. They are not a test. They tell you which chapters to read slowly.

How to study this guide: read one Part per sitting. Do the exercise at the end of each chapter on your own product if it has any reading or writing surface (most products do: settings pages, help docs, notes fields, onboarding text). If yours does not, use the reading app you use every day and redesign it on paper. The labs are there to be played with; drag every slider to its extremes before reading the caption.

In reading software the user's attention is not a resource you spend on your interface; it is the thing you are protecting. Every pixel of chrome, every animation, every prompt is paid for out of the reader's concentration.

Think about how most software is used. You open a banking app, do a task in 40 seconds, and leave. The interface is the experience, so it is reasonable for it to be visible, labelled and explicit. Reading is the reverse. A reading session lasts 20 minutes to two hours. During that time the reader is building something fragile in their head: a model of an argument, a world, a set of characters. Psychologists call this a situation model. It takes minutes to build and seconds to collapse.

That gives you the mechanism behind every rule in this guide. Any element that pulls the eye away from the text, even for a quarter of a second, forces the reader to put the model down and pick it back up. One interruption is cheap. Ten interruptions in a chapter turns reading into skimming, and the reader blames the book, not your app. They just feel that reading on your app is tiring.

Naoto Fukasawa's "without thought" idea is useful here: good design fits behaviour people already have, so they act without stopping to think about the object. For reading, the behaviour already exists and is centuries old: eyes move along a line, hands turn a page, a finger keeps a place. Your job is to fit that behaviour, not to teach a new one. Kenya Hara's idea of emptiness (an empty vessel that can hold whatever the user brings) is the other half. A reading screen should be close to empty, so that the text can fill it.

The three jobs of a reading interface

Strip it down and a reading interface has three jobs. Get the reader in (open to the right place, fast, with the text already set well). Keep the reader in (stay out of the way, never surprise them). Get the reader back (when they leave, make return effortless: same place, same settings, maybe a reminder of where they were). Almost every reading feature belongs to one of those three jobs. Features that belong to none of them, like streak badges or social prompts mid-chapter, deserve hard suspicion.

Web Design is 95% Typography.Oliver Reichenstein, essay title, iA, 2006

Reichenstein's essay title was a provocation, but for reading products it is close to literal. If the text is set well and the chrome is hidden, you have most of a great reader. Everything after that is about not breaking it.

In the wild

• Kindle (e-ink)Amazon, 2007 to now
  A tap at the top of the page brings up the toolbar; otherwise the screen is text, a small chapter title and a progress line. Turning pages is a tap or a side button. The default state is pure text. Chrome is a mode you enter on purpose.
• iA WriterInformation Architects, 2010 to now
  A writing app, but built on the same idea: a blank window, one typeface tuned for the size, and almost no visible controls while you type. The same "interface disappears" rule applies to writing as to reading.
• Safari ReaderApple, since 2010
  One button strips a web page down to headline, byline, images and body text. Readers want this so much that browsers built it in. Your product should not need it.

Pages give the reader a fixed place and a rhythm; scroll gives them continuity and speed. Choose by the length and purpose of the text, and if you offer both, make each one complete rather than half of each.

The page is the oldest reading interface we have, and it does three useful things. It gives every word a fixed place on a fixed rectangle, so your memory can attach to it ("the quote was near the top of a left page"). It creates a rhythm: read, turn, read, which gives the mind small rests. And it makes progress countable: page 112 of 300 means something.

Scroll does different useful things. It never cuts a paragraph in half. It lets you glance back at the previous line without a gesture. It handles text of any length without the machinery of pagination, which is why the web is a scroll. And on a phone, a flick of the thumb is less effort than a tap per screen for skimming.

The weaknesses mirror the strengths. Scroll's position is fuzzy: the same sentence sits at a different height every time you return, so spatial memory has nothing to hold. Continuous motion also asks the eye to track moving text, which is tiring over hours. Pages force awkward breaks (a heading at the bottom of a page, a single line at the top) and, on screens, a turn animation that can become a toy.

The page turn is a micro-interaction, not a show

Apple's iBooks launched in 2010 with a realistic page curl that followed your finger. It was a beautiful demonstration of the iPad's touch screen, and it was also skeuomorphism at its most literal. In the 2022 redesign of Apple Books the curl was replaced by a simpler slide, and enough readers missed it that Apple brought the curl back as an option in a later update. The lesson is not "curl good" or "curl bad". The turn is felt hundreds of times per book. It must be fast (under about 250 ms), it must follow the finger if you drag, and it must never be the thing you notice. Some readers love the curl because it gives the turn a physical weight; others find it slow. That is a legitimate preference, which is why it is a setting.

On e-ink, the turn has no animation at all: the screen just redraws. That turns out to be fine. Readers stop noticing the redraw within minutes, because it is consistent. Consistency matters more than smoothness.

If you offer both, finish both

Many readers offer pages and scroll as a setting: Kindle's phone apps, Apple Books, and Instapaper all have had both at various points. That is fine, but each model has its own requirements, and teams often build one properly and the other as an afterthought. A complete page model needs widow and orphan control, headings that never sit alone at the bottom of a page, images that fit a page, and stable page numbers for a given text size. A complete scroll model needs a position that survives rotation and font changes, a meaningful progress indicator, and a way to page by screen (space bar, a tap at the bottom edge) for readers who like the rhythm without the animation.

In the wild

• Apple BooksApple, 2010 to now
  The page curl was a signature of the original iBooks; the 2022 redesign replaced it with a slide, and the curl later returned as an option alongside slide and scroll. The turn is felt hundreds of times per book; readers have strong preferences, so make it a setting with a calm default.
• Kindle e-readersAmazon
  Pages with an instant redraw. Tapping most of the screen turns forward; a narrow left strip turns back. The tap zones are lopsided on purpose: forward is the action you take hundreds of times.
• InstapaperMarco Arment, 2008
  Built around scroll for articles, and over the years experimented with alternatives such as pagination and tilt-to-scroll. Even a scroll-first reader benefits from offering the page rhythm to those who want it.

A long text is read line by line, so the line is your unit of design. Its length (measure), the space between lines (leading) and the quiet around the block (margins) decide whether the eye moves without effort for an hour or tires in ten minutes.

You met these in Typography. Here we tune them for long sessions, where small errors add up. The mechanism is the return sweep. At the end of each line your eye jumps back to the start of the next one. If lines are too long, the jump is far and the eye sometimes lands on the wrong line (you reread a line, or skip one). If lines are too short, the eye jumps constantly and phrases get chopped. If lines are too tight vertically, the next line crowds the target and the sweep misses. If they are too loose, the block falls apart into stripes.

Numbers to start from

Robert Bringhurst's The Elements of Typographic Style gives 45 to 75 characters as the satisfactory range for a single-column page, with 66 widely regarded as ideal. Matthew Butterick's Practical Typography suggests 45 to 90 characters and line spacing of 120 to 145 percent of the point size. On screens, long-form reading tends to want the upper half of that leading range or a little more, because screens are read at varying distances and in varying light. A good starting point for a desktop reading column is 17 to 21 px text, 1.5 to 1.6 line height, and a column of about 34 em (roughly 65 to 70 characters in a typical serif).

Leading and measure are linked: the longer the line, the more leading it needs, because the return sweep has further to travel and needs a wider target. If you let readers widen the column, nudge the leading up with it. Good reader apps do this quietly.

Margins are not wasted space

Book designers spent five centuries on margins. Classical page proportions, like the Van de Graaf canon reconstructed by Jan Tschichold, put the text block high and toward the spine, with the largest margin at the bottom. On screen there is no spine, so symmetric side margins are normal, but two old lessons still apply. First, margins frame the block so the eye knows where the text ends; text that touches the edge of a screen feels like it is spilling off. Second, the bottom margin should be generous, because the last line on a screen is where the eye pauses before turning, and controls placed there compete with it.

On a phone, side margins of 16 to 24 px are typical; reading apps often go wider (24 to 32 px) because the measure is already short and the frame adds calm. On tablets and desktops, the margin is whatever is left after you cap the measure. Do not widen the text to fill a wide window. Centre a column and let the margins grow.

/* A calm long-form column for the web */
article {
  max-width: 34em;          /* ~65-70 characters in most serifs */
  margin: 0 auto;
  padding: 0 clamp(16px, 5vw, 32px);
  font-size: clamp(17px, 1rem + 0.3vw, 21px);
  line-height: 1.55;
}
article p + p { margin-top: 0.9em; }   /* or indent, not both */

In the wild

• Medium2012 to now
  Built its early reputation on a single narrow serif column with generous leading on a white page, at a time when most blogs were cluttered. A well-set column was a brand in itself.
• Kindle and Kobo marginse-readers
  Both offer a few margin widths and line spacings rather than free sliders on most models, with the defaults set to a moderate value. A handful of good presets beats a continuous control for something readers set once.
• Wikipedia (Vector 2022)Wikimedia, 2023
  The 2022 Vector skin, rolled out on English Wikipedia in early 2023, introduced a limited content width on wide screens after years of full-width text. Even the biggest reference site on the web moved to a capped measure for readability.

A typeface for hours of reading is not chosen for personality. It is chosen for stamina: generous x-height, open shapes, sturdy serifs, moderate contrast, and spacing that survives small sizes, low resolution and e-ink. Justification is only worth it if hyphenation comes with it.

Display typefaces are judged in a glance. Book typefaces are judged after the 300th page, when every small irritation has been seen 100,000 times. The qualities that matter are boring and physical. A large x-height makes lowercase letters bigger at the same point size, so text reads larger without taking more lines. Open apertures (the gaps in c, e, a, s) keep letters distinct when blurred or rendered with few pixels. Sturdy, slightly blunt serifs survive e-ink and low-resolution screens where hairline serifs break up. Moderate stroke contrast avoids thin strokes vanishing in dark mode or at small sizes.

Justification needs hyphenation

Books are usually justified: both edges straight. Justification works by stretching the spaces between words on each line. In a wide print column with good hyphenation, the stretch is small and invisible. In a narrow screen column without hyphenation, a long word that cannot be broken pushes to the next line and leaves huge gaps behind it. Gaps stack vertically into "rivers" of white that the eye follows down the page. That is why early e-readers and many apps looked worse justified than ragged.

Amazon's 2015 Kindle typography update paired the new Bookerly face with a new layout engine that added hyphenation and better spacing. That is the right pairing. The rule for you: justify only when you can hyphenate well and the measure is at least about 45 characters. Otherwise use left-aligned ("ragged right") text, which never makes rivers.

These three are live HTML, so your browser does the setting. If the middle one looks like the first, your browser lacks English hyphenation dictionaries, which is itself a lesson: you cannot rely on hyphens: auto everywhere.

/* Long-form web text, book-like when supported */
article { text-align: left; text-wrap: pretty; }   /* fewer short last lines */
@supports (hyphens: auto) {
  article.justified { text-align: justify; hyphens: auto; }
}
/* never justify below ~45 characters per line */

Widows, orphans and the last line

A widow is a paragraph's last line alone at the top of a page; an orphan is a first line alone at the bottom. In scroll they hardly matter, but on pages they look like errors. A related screen problem is the runt, a single short word on the last line of a paragraph. Browsers now offer text-wrap: pretty, which rebalances the last lines of paragraphs to avoid runts, and text-wrap: balance for headings. They cost nothing to add and degrade gracefully.

In the wild

• Kindle 2015 updateAmazon
  Introduced Bookerly, drawn for reading on screens, together with a new layout engine with hyphenation and improved spacing. A face and its setting engine are one decision.
• Google Play BooksGoogle, 2015
  Commissioned Literata from TypeTogether as its reading face, later released openly. If you cannot commission a face, the open result is now free to use.
• iA Writer's fontsiA
  iA built its own monospace, duospace and quattro faces (based on IBM Plex) specifically for writing at screen sizes, and publishes them free. Writing faces have different needs from reading faces: they must show every character clearly while you edit.

Readers differ: eyesight, light, device, habit. So reading apps must let them change the text. But every control is a decision you push onto the reader, so the default must already be right, and the controls should be few, layered and instantly previewed.

There are two failure modes. The first is too few controls: a fixed font size in a reading app excludes anyone whose eyes do not match yours, and that is most people over 45. The second is too many: a panel of fourteen sliders invites fiddling, which is the opposite of reading. People who start adjusting kerning at 11 pm are not reading.

The way through is to rank controls by how many readers need them and how often. Text size and theme (light or dark) are needed by almost everyone and change with the situation, so they sit on the first layer, one tap away. Font, line spacing, margins and alignment are set once and rarely touched, so they sit one level deeper. Expert controls, like Kobo's font weight and sharpness sliders, sit behind an "advanced" door. Each change previews live on the real text behind the panel, never in a sample box.

How many options per control?

For each control, offer steps rather than a continuous range when the reader sets it once: five to eight text sizes, three or four line spacings, three margins. Steps are easier to return to ("I like the fourth size") and easier to sync across devices. Text size is the exception that benefits from many steps, because eyesight varies so widely; Kindle and Apple Books offer many sizes, including very large ones.

For typefaces, four to eight is enough, as long as they differ in a useful way: a sturdy serif, a screen serif, a humanist sans, one high-legibility face (such as Atkinson Hyperlegible), and the publisher's font when there is one. Twelve similar serifs are not choice; they are homework.

Defaults are your design

Most people never open the settings. Whatever you ship as default is what most of your readers will see for their entire time with the app. So spend more time on the default than on the panel. Set it per device class: a phone default (17 to 19 px, 1.5 to 1.6 leading, 20 to 28 px side margins) is not a tablet default. Follow the system text size setting (Dynamic Type on iOS, font scale on Android) as the starting point, and remember the reader's choice per device, not just per account, because the same person wants different sizes on a phone and an e-reader.

In the wild

• KoboRakuten Kobo
  Offers the usual font, size, spacing and margins, plus "advanced" sliders for font weight and sharpness, which help on e-ink where thin strokes can look grey. Expert controls are fine behind a door; they serve a real e-ink problem.
• Kindle ThemesAmazon
  Lets you save a full combination of font, size, spacing and layout as a named theme and switch between them. Bundling settings turns ten choices into one, for people who read in two situations (say, day and bed).
• Instapaper2008 to now
  A compact panel: a handful of fonts, size, line spacing, margins and a few background colours, all previewed on the article. A small, well-chosen set covers almost everyone.

A reading theme is a lighting decision. Match it to the light the reader is in, keep contrast high but not harsh, and when the screen is e-ink, design for a display that is slow, grey and permanent rather than fast, coloured and glowing.

Screens emit light; paper reflects it. In a bright room, a white screen is about as bright as the paper around it and feels natural. In a dark room the same white screen is the brightest thing in your field of view, your pupils narrow, and the glare tires you. That is the real reason readers want dark themes at night: not taste, but light balance. Research on text polarity (for example, work by Piepenbrock and colleagues in 2013) has found that dark text on a light background tends to give better proofreading and legibility in normal lighting, partly because a narrower pupil sharpens the image. So the right default is light in the day and a dark option for dim rooms, ideally following the system appearance.

Dark, but not too dark

Two details separate a good dark theme from an inverted one. First, avoid pure white text on pure black for long reading. The extreme contrast makes bright letters bloom into the dark around them (halation), which is worse for the many people with astigmatism. Soften the text to an off-white or light grey and lift the background slightly off black. Second, true black (#000) on OLED phones is a legitimate choice for night reading in a dark room, because black pixels are off and the screen emits almost no light around the text. But true black can smear when you scroll on some OLED panels, and the jump from a bright UI to it is harsh, so offer it as an option, not the dark default.

Night reading and warm light

Light in the evening affects sleep. A 2015 study by Chang and colleagues (PNAS) found that people who read on a light-emitting e-reader before bed took longer to fall asleep and had suppressed evening melatonin compared with reading a printed book. The strongest levers are brightness and timing. Warmer colour (less blue) is a plausible help and is how e-readers like the Kindle Oasis, newer Paperwhites and Kobo models with "ComfortLight PRO" handle bedtime, but the evidence that a warm shift alone fixes the sleep effect is mixed. Design for both: a dark or sepia theme, brightness that can go very low, and on devices with a front light, a warm tint that can follow sunset.

Designing for e-ink

E-ink (electrophoretic) screens move tiny charged pigment particles to form an image, and the image stays without power. That makes them wonderful for reading (reflective like paper, readable in sunlight, weeks of battery) and awkward for interfaces. A full refresh takes a few hundred milliseconds and often flashes black to clear the previous image. Faster partial updates leave faint traces of the previous image, called ghosting, which builds up until the next full refresh. Most screens show 16 levels of grey. Colour e-ink exists (for example the Kindle Colorsoft from 2024 and several Kobo models), but colours are muted and colour resolution is lower than black-and-white.

So the e-ink design rules are almost the opposite of phone UI fashion: no animation (each frame costs a refresh and leaves ghosts), no subtle greys (they become mush), no thin lines, no transparency, no spinners. Use solid black on white, thick enough strokes, clear boxes, and state changes that are big and instant. Design screens so that partial refreshes only touch the area that changed (for example, a menu drawn over a fixed region), and give the reader control over how often a full refresh flash happens. Kindle exposes this as a "page refresh" option.

In the wild

• Apple Books themesApple, 2022 redesign
  Replaced a few page colours with named themes that combine background, font and weight (for example Original, Quiet, Paper, Bold, Calm, Focus), each customisable. A theme can bundle colour with type choices, so one tap changes the whole mood.
• Kindle Paperwhite and OasisAmazon
  Adjustable warm front light that can follow a schedule, plus a dark mode on newer models. On e-ink, "theme" includes the physical light.
• reMarkablereMarkable, 2017 and later
  An e-ink tablet whose UI is drawn in solid black and white with simple line icons and almost no animation. A whole product designed for the medium's limits feels calm rather than slow.

Progress in a long text answers three different questions: where am I, how much is left, and how do I get back? Each indicator answers some of them well and others badly, so pick the one that matches what your reader is deciding.

A printed book answers all three questions without any design: you feel the thickness of the pages in each hand, you see the page number, and you can put a finger or a ribbon in it. A screen removes every physical cue. The reader has no idea if the chapter has three pages left or thirty, which matters because people decide whether to keep reading based on what is left ("I'll finish this chapter, then sleep"). That decision is the real job of the progress indicator.

Reflowable text makes this harder. When the reader changes text size, page 112 becomes page 140, so pages are not stable addresses. Kindle's answer, from the start, was the "location": a number tied to a position in the text itself, independent of size. Locations are stable but meaningless as a sense of distance ("Loc 2,341 of 6,020" requires arithmetic). So Kindle also offers percent, real page numbers for books that have them mapped to a print edition, and time left in the chapter or book, estimated from your own reading speed.

Chapter-scoped beats book-scoped

The decision readers make most often is "do I have time to finish this bit?", and the natural bit is the chapter. So chapter-scoped progress (pages or minutes left in the chapter) is usually the most useful default. Book-wide percent is better for the rarer question "how far through am I?", and belongs in the menu or as an alternative. Time estimates must be personal and humble: compute them from this reader's pace on this book, show them only after a few pages of data, and round generously ("about 10 minutes").

One subtle rule: progress must never move backward when nothing changed. If changing text size makes "page 112" jump to "page 140", say why, or better, use an indicator that does not jump. Readers who see numbers jump stop trusting all the numbers.

Tables of contents and scrubbers

The table of contents is the map. It should show the current chapter highlighted, allow jumping with one tap, and in long books, show progress within each chapter or at least which ones are finished. A scrubber (a slider across the whole book) is good for big jumps and terrible for precision, so it needs two things: a preview of where you will land (chapter title and page or location) shown while dragging, and a way back to where you were. Readers who scrub to check something and then cannot find their place again are a classic support complaint. Kindle's "Page Flip" (2016) solved this with a separate peek mode: you browse other pages in a panel while your reading position stays pinned.

Coming back: sync and "where was I"

Readers switch devices: phone on the train, e-reader in bed, laptop at lunch. Position sync (Kindle calls it Whispersync) means the book opens where they stopped, on any device. The design decisions are in the edge cases. When two devices disagree, which wins? Kindle's approach is to ask, offering to jump to the furthest or most recent page read on another device, rather than silently moving the reader. Silent jumps forward can spoil a novel; silent jumps back lose a place. Ask once, clearly, with both positions.

The second part of coming back is memory. If someone returns after two weeks, they may remember the page but not the story. A light "where was I" cue helps: the last sentence they read highlighted for a moment, the chapter title and a line on how long ago they were here. Some apps go further and offer a recap of previous chapters; if you do this (with or without AI), make it opt-in, clearly marked, and spoiler-safe by only using text before the reader's position.

In the wild

• Kindle reading progressAmazon
  A tap on the bottom-left footer cycles between location, page (when available), time left in chapter, time left in book, and nothing. One quiet slot, many answers, chosen by the reader.
• Kindle Page Flip2016
  Lets you browse other pages and a whole-book overview while your reading position stays pinned and one tap returns you. Separate "looking around" from "moving", and jumping becomes safe.
• Long-form web articlesvarious publishers
  Many show "12 min read" under the headline and a thin progress bar at the top while scrolling. Fine for articles; for books, the minute estimate must be personal and chapter-scoped to be useful.

Annotation turns reading into thinking. Make the mark fast and precise, keep the note next to its text, and treat export as a core feature, because highlights are only worth something when they can leave your app.

People highlight for three reasons: to remember, to come back, and to use later (quote, cite, write). The first two happen inside your app; the third happens somewhere else, in a notes app, a document, an essay. If your highlights cannot leave, the reader eventually learns that highlighting in your app is a dead end, and stops. That is why a whole company, Readwise (founded in 2017), exists to pull highlights out of Kindle, Apple Books, Instapaper and other apps and send them into tools like Obsidian, Notion and Logseq, with a daily review email that resurfaces old highlights. Readers paid for an export layer the reading apps did not build.

Selection on touch is the hard part

On a desktop, selecting text with a mouse is precise. On a phone, your fingertip covers several words, so selection needs help. The established pattern: long-press selects a word, handles appear at both ends, dragging a handle shows a magnified view (a loupe on iOS) of what is under your finger, and the selection snaps to word boundaries. Good reading apps add one more step: a single tap on the highlight action creates it immediately in the last-used colour, with colour and note as secondary options. Every extra tap between "I want to keep this" and "kept" costs highlights.

Margin notes versus popovers

Where does a note live after it is written? On a wide screen, the margin is best: the note sits beside its text, visible at a glance, the way a pencil note does. On a phone there is no margin, so notes become an icon or underline that opens a popover. Both are fine if the mark in the text shows that a note exists (a small icon, a different underline) and the popover never covers the highlighted text itself.

In the wild

• Readwise and ReaderReadwise, 2017 and 2022
  Readwise imports highlights from many readers and resurfaces them in a daily review; Reader (its own reading app) puts highlighting and tagging at the centre and exports to note tools. The value of a highlight grows when it leaves the app and comes back later.
• KindleAmazon
  Highlights and notes sync to your account and appear on Amazon's notebook page; on e-readers they are also appended to a plain text file, "My Clippings.txt". Kindle also shows "Popular Highlights" where many readers marked the same passage. A plain text file is the most durable export there is. Social highlights should be an option, not a default.
• HypothesisHypothesis, open source
  Web annotation in a sidebar beside any page, with notes anchored to text even if the page changes slightly. Robust anchoring (quote plus surrounding text) survives edits better than offsets alone.

Any help a reader needs mid-sentence (a footnote, a definition, a translation, who a character is) should appear next to the text, be readable in a glance, and disappear without moving the reader. Never send them to another page to get it.

The printed footnote was a clever answer to a physical problem: you cannot put the note next to the word, so you put it at the bottom of the same page, and the eye drops and returns. Endnotes, at the back of the book, were a cheaper answer that made notes much harder to read. On the web, the default became the endnote: a superscript link jumps to the bottom of the article, and a little arrow jumps back. That breaks the reading flow twice and, on long pages, lands you in a pile of notes with no sense of which is yours.

Screens can do better, in two ways. Popover notes open in place, right where you tapped, and close without moving the page. Sidenotes, which Edward Tufte uses in his books and which Tufte CSS and Gwern.net brought to the web, sit in a wide margin beside the line they belong to, so you can read them without any action at all. Sidenotes need a wide screen; on narrow screens they must collapse into popovers or inline toggles.

Definitions, translation and "who is this?"

The same rule applies to every in-text help. Kindle's built-in dictionary opens a card at the bottom of the screen when you long-press a word, with a link to the full entry. Its Word Wise feature (2014) goes further for learners, printing short definitions in small type above harder words, with a slider for how many words get hints. X-Ray (2011) lets you see characters, places and terms in a book, with every mention, which is a memory aid for long novels with large casts. Wikipedia's Page Previews show a summary card when you hover a link, so you can decide whether to leave the article at all.

The design principles they share: the card shows the answer in its first line; it appears near the word without covering it; one tap or Escape dismisses it; and nothing about the page moves. If the reader wants more, there is a link to go deeper, which is now a deliberate choice rather than a forced trip.

In the wild

• Tufte CSSDave Liepmann, open source
  A stylesheet that brings Tufte's sidenotes and margin notes to the web, collapsing them to tap-to-reveal on narrow screens. The responsive note is a solved problem; you can study the source.
• Gwern.netGwern Branwen
  Long essays with sidenotes on wide screens, and recursive popups for links and footnotes on hover. Deep reading sites can make every reference inspectable without leaving the page.
• Kindle Word Wise and X-RayAmazon, 2014 and 2011
  Optional hints above hard words, and an index of characters and terms per book. Context aids can be on by choice, with a dial for how much help you want.

Reader modes exist because publishers' pages failed readers. They work by finding the article in a noisy page and re-setting it with good defaults. Read-later apps add time: save now, read when you have attention. If you publish text, your page should not need either.

In 2009, the Arc90 lab released Readability, a bookmarklet that took a cluttered web page and showed just the article in a clean column. It spread quickly because it solved a pain everyone had. Apple built Safari Reader on top of it in 2010; Mozilla later wrote its own Readability.js for Firefox's Reader View, and now every major browser has some form of reader mode. That history is a verdict: given the choice, readers removed nearly everything publishers put around the text.

How does a reader mode know what the article is? It scores blocks of the page. Paragraph-heavy blocks with lots of text, commas and few links score high; blocks with many links, short text, or class names like "sidebar", "comment", "ad" or "footer" score low. The highest-scoring container is taken as the article, cleaned, and re-set with the reader's preferred type. The same heuristics tell you how to write pages that reader modes, read-later apps, and assistive technology handle well: put the article in an <article> element, use real paragraphs and headings, mark the byline and date, and keep navigation out of the main content.

Read-later: separating finding from reading

Marco Arment built Instapaper in 2008 for a problem he had himself: he found long articles during the day, when he had no time to read them, and wanted to read them later on his phone during idle time like a commute. The insight is that finding and reading happen in different states of attention. Finding is fast and fragmented (a link in a chat, a tab during work). Reading needs a quiet block of time. A read-later app is a bridge between the two: one tap to save, then a calm, offline, consistently set reading surface later.

The design of the save action matters as much as the reader. It must be instant and work everywhere: browser extension, share sheet, email forwarding, an API. Saving should confirm quietly and never ask questions (tags and folders can come later). Then the queue must not become a guilt pile. A list of 900 unread articles is a to-do list nobody can finish. Good read-later apps help you let go: archive with one swipe, sort by length so you can match an article to the time you have, and make it fine to never read something.

In the wild

• Readability to Safari ReaderArc90, 2009; Apple, 2010
  A lab experiment that extracted articles became a feature in a major browser within a year. When users build or install tools to remove your design, read it as research.
• InstapaperMarco Arment, 2008
  One-tap saving from the browser, then a clean, offline reader with a few typography settings. Separating capture from consumption is a pattern that applies to many products, not just reading.
• Pocket and Omnivoreshut down 2025 and 2024
  Two well-used read-later services closed (Omnivore in late 2024, Mozilla's Pocket in 2025), giving users a limited window to export. A reader's saved library is years of their life. Export is not optional; it is your promise that you are not a trap.

A feed can be a tool you use or a slot machine that uses you. Calm feeds are chronological, finite, under the reader's control, and free of counters that create guilt. They end, and say so.

RSS readers are the old, honest version of the feed: you choose sources, items arrive in time order, and you read until there are no more. Social feeds took the same shape and changed three things: an algorithm chooses what you see, the list never ends, and counters and badges invite you back. Those three changes are the mechanism of compulsive use, covered in depth in Honest & Calm and The Human Mind. Here we look at the practical design of a feed for reading that respects attention.

The unread count problem

Unread counts look like neutral information. In practice, a big red number is a to-do list you did not write. If someone subscribes to 80 feeds and is away for a week, they return to "1,284 unread", and the reading app becomes a source of guilt. Many people end up declaring "RSS bankruptcy": marking everything read and starting over, or quitting. Silvio Rizzi's 2024 redesign of Reeder took a strong position: no unread counts at all, a single timeline that remembers where you stopped, and the freedom to skip. Other readers keep counts but let you hide them, or show them in muted grey without a badge on the app icon.

Tools for a calm feed

Beyond counts, a handful of design moves change how a feed feels. Group high-volume sources (a news site posting 80 items a day) separately from low-volume personal blogs, or the blogs disappear. Offer a "since last visit" or "today" scope as the default view, rather than all time. Let the reader mute keywords and sources for a while without unsubscribing. Show reading time per item. Make "skip" and "mark older as read" gentle and undoable. And give newsletters a home: many readers now forward newsletters into their feed reader (Feedbin offers a dedicated email address for this; Readwise Reader and others do too), taking reading out of the inbox, where every newsletter competes with work email.

In the wild

• Reeder (2024)Silvio Rizzi
  A redesign around a single timeline without unread counts, which remembers your position and lets you scroll back in time; the earlier app continued as Reeder Classic. Removing a convention everyone else keeps can be the product's main idea.
• NetNewsWireBrent Simmons, since 2002; open source
  A free, native Mac and iOS RSS reader with a classic three-pane layout and a "Today" smart feed. The classic model, done carefully and without growth tricks, is still excellent.
• Instagram "You're all caught up"Instagram, 2018
  A marker shown when you have seen all new posts from accounts you follow since your last visit. Even an engagement-driven product found value in telling people they were done. (It then offered suggested posts below, which shows the tension.)

A writing tool should make starting easy, keep the writer's eyes where the words are being made, and keep judgement (editing, styling, counting) out of the way until the writer asks for it. Drafting and editing are different modes; design them as different modes.

The blank page is hard because writing is two activities at once: generating and judging. Generating needs momentum; judging kills it. Many writers' advice ("write drunk, edit sober" is a popular misattribution; the idea is older and widely shared) comes down to separating the two. Software can help or hurt. A toolbar full of fonts, styles and a live word count is an invitation to judge while generating. A calm window with one well-set typeface and nothing else is an invitation to keep going.

iA Writer, released for iPad in 2010, made this its whole product. It opened to a blank document in one carefully tuned typeface, with no font choice at all. Its Focus Mode dimmed everything except the current sentence (later also the current paragraph), so the writer's attention stayed on the line being made. Its typewriter mode kept that line at a fixed height on screen, so the eyes never drifted to the bottom edge while typing. Those ideas have since been copied widely, which is the best evidence they work.

Judgement on demand: syntax highlighting for prose

Once there is a draft, the writer switches to editing, and now the software can help judge. iA Writer's Syntax Highlight (introduced with iA Writer Pro) colours parts of speech: adjectives, nouns, adverbs, verbs, conjunctions. You can switch on just adverbs, for example, and see at a glance where you leaned on "very" and "really". The Hemingway Editor highlights long sentences, passive voice and adverbs. Both share a design principle: they are off by default, or easy to switch off, because their colours are judgement, and judgement belongs to the editing pass.

In the wild

• iA WriteriA, 2010 to now
  Focus Mode, typewriter scrolling, Syntax Highlight and Style Check, all switchable, around a single tuned typeface. Each feature serves either drafting or editing, and the two never fight.
• Hemingway Editor2013 to now
  Paste or write text and it colours hard-to-read sentences, adverbs and passive voice, with a readability grade. An editing tool, explicitly: it is most useful after the draft exists.
• Ulysses and ScrivenerThe Soulmen; Literature & Latte
  Both offer distraction-free and typewriter modes inside larger writing environments. Even complex tools need a "just the text" state.

Every editor makes a trade between seeing structure and seeing the result. Markdown shows structure as plain characters, WYSIWYG shows the result and hides structure, and block editors make structure into objects. Choose by who writes, what they produce, and where the text must go next.

John Gruber, with Aaron Swartz, released Markdown in 2004 as a way to write for the web in plain text that was readable as-is: *emphasis*, # heading, - list. Its genius is that the source is the document. Any text editor can open it in 50 years. Its cost is that you see the markup while writing, and newcomers do not know the syntax.

WYSIWYG ("what you see is what you get") editors, from word processors to Google Docs, hide the structure and show formatted text. They are easy to learn, but the structure is hidden in a format you cannot see, and it goes wrong in invisible ways: a heading that is really bold body text, a list that is really indented paragraphs, formatting that will not paste cleanly elsewhere.

Between them, hybrid editors (Bear, iA Writer's preview styles, Typora, Obsidian's live preview) keep Markdown as the source but style it as you type, often fading the markup characters. Block editors (Notion, and many tools since) turn each paragraph, heading, image or to-do into a separate object you can drag, convert and embed. Blocks are powerful for structured pages and databases; they make long flowing prose feel chopped, because selection, cursor movement and copy-paste work across block boundaries less naturally than across one continuous text.

In the wild

• BearShiny Frog, 2016; Bear 2 in 2023
  A hybrid Markdown editor with tags written inline as #tag, and markup styled as you type. Hybrid editing lets beginners and Markdown users share one surface.
• NotionNotion Labs
  Popularised the block editor with "/" commands, where any block can become another type or a database. Blocks shine for structured, mixed-media pages; prose writers often draft elsewhere.
• Google DocsGoogle, 2006 to now
  WYSIWYG with real-time collaboration, which later added Markdown auto-formatting shortcuts as an option. Even mainstream visual editors borrow Markdown's speed.

The first feature of a writing tool is that the words are safe. Decide where text lives (files the writer owns, or a library you manage), save continuously without asking, keep a history the writer can browse, and make leaving easy. Trust is the product.

Writers remember lost work for years. One lost paragraph changes how a person uses a tool forever: they start copying text to a second app "just in case", which is the opposite of calm. So safety is not a technical detail under the design; it is the design.

Where does the text live?

There are three broad models. In the file model (iA Writer, Obsidian, most code editors), each document is a plain file in a folder the writer chooses: they can open it in any other app, back it up with any tool, sync it with any service. The app is a lens on their files. In the library model (Ulysses, Bear, Apple Notes), the app manages storage itself, often a database or package, and offers organisation, search and sync that feel seamless; the cost is that text is less directly accessible, so export becomes essential. In the cloud model (Google Docs, Notion), documents live on a server, which makes collaboration and access from anywhere easy, but the writer depends on the service and the network.

The "local-first software" essay published by the research lab Ink & Switch in 2019 argued for a fourth path that combines them: data lives on the user's device first (fast, offline, owned), and syncs and collaborates through the cloud, often using data structures called CRDTs that merge concurrent edits without conflicts. For a solo creator, open-source libraries such as Automerge and Yjs make this far more practical than it used to be.

Autosave: never ask

"Do you want to save changes?" is a question the software should answer itself. Since Mac OS X Lion (2011), Apple's document model saves automatically and keeps versions; Google Docs saved continuously from the start. The design pattern: save after every pause (a second or two after typing stops) and on every blur or quit; show a quiet, truthful status ("Saved", "Saving…", "Offline, saved on this device"); and never show "Saved" when it is not true. If saving fails, that is the one time to be loud.

Versions the writer can understand

Autosave creates a new problem: the writer may want yesterday's paragraph back. A good version history is a timeline, browsable by time, with the ability to see a past version side by side, copy a paragraph out of it, or restore it as a new version (never destroying the current one). Automatic snapshots should be thinned over time (every few minutes today, hourly this week, daily after that), and writers should be able to name a version ("Sent to editor"), so the important moments stand out from the noise.

Export is a promise

For a library or cloud tool, export is how you prove you are not a trap. Offer full export of everything (not just one document at a time) in open formats: Markdown or plain text for content, with folders or tags preserved somehow, plus attachments. Offer publication formats (PDF, DOCX, HTML, ePub) for finished work. Ulysses, for example, is a library app whose export to many formats is a central feature. The read-later shutdowns in chapter 10 are the reminder: when a service ends, export is the difference between a nuisance and a loss.

In the wild

• Obsidian2020 to now
  Notes are plain Markdown files in a local folder (a "vault"); the app adds links, search and plugins on top, and paid sync is optional. Files-first can still feel like a rich app; ownership becomes a selling point.
• UlyssesThe Soulmen
  Keeps texts in its own library with iCloud sync, and can also add external folders of Markdown files; export to PDF, DOCX, ePub and HTML is central. A library model with strong export and an escape hatch earns trust.
• Google Docs version historyGoogle
  Continuous saving, a version timeline grouped by time, named versions, and restore. Collaboration made history essential; even solo writers benefit.

Writing happens in different places with different needs: a phone in a queue (capture), a desk with an hour (compose), and sometimes a shared document (collaborate). Design for the context: fast and forgiving for capture, deep and structured for composing, clear about who changed what for collaboration.

A thought that arrives in a queue has a life of about ten seconds. If your app needs five taps (open, pick a folder, new note, name it, type), the thought is gone. Drafts, by Agile Tortoise, is built on this observation: it opens to a blank text field with the keyboard up, every time, and decides where the text goes later through "actions" (send to email, append to a file, post somewhere). Apple Notes added quick notes from the lock screen and corner gestures for the same reason. Capture tools optimise for one metric: time from intent to typing.

The desk is the opposite. A novelist with a 90,000-word manuscript needs structure: chapters and scenes as separate pieces that can be reordered, research beside the draft, targets and progress. Scrivener's binder and corkboard are built for that; Ulysses' sheets and groups and its writing goals are a lighter version. Here the metric is how well the tool holds a big, changing structure.

Counts, goals and the danger of the number

Word counts help writers who work to length (articles, essays, books) and to habit (500 words a day). They hurt when they become the point. The design answer is to make counts available, scoped and quiet: a count for the selection, the document and the session; a goal the writer sets themselves; progress shown as a small ring or bar that fills, not a number that flickers with every keystroke. Ulysses shows goals as a small circle that fills as you write; Scrivener has project and session targets. Neither puts a giant counter in the text area.

Writing with other people: the basics

Collaboration adds three needs to a writing tool. Presence: who else is here, and where (named cursors and selections). Attribution: who changed what, and when (history per author). And negotiation: proposing a change without imposing it. Google Docs set the expectations: live cursors, comments anchored to text, and "suggesting" mode, where edits appear as proposals the owner accepts or rejects. Comments and suggestions are different tools. A comment discusses; a suggestion changes. Making that difference visible saves a lot of confusion.

In the wild

• DraftsAgile Tortoise
  Opens to a new blank draft with the keyboard ready; text is sent onward with configurable actions. "Where does it go?" is answered after writing, not before.
• ScrivenerLiterature & Latte, 2007
  A binder of documents and folders, a corkboard of index cards, research inside the project, and "compile" to produce the final format. Long works need structure tools that prose-only editors do not have.
• Google Docs suggesting modeGoogle
  Edits become proposals with author names, accepted or rejected individually. Separating "propose" from "change" lets people edit each other without fear.

Reading tools should let people take in text the way that works for them: by eye, by ear, or both together, with spacing and type they can adjust. Base these features on evidence, not on marketing claims, because some popular "reading hacks" do not work.

Accessibility for reading starts with the basics you already have from Part one: real text (never text in images), adjustable size, good contrast, themes, and support for the platform's screen reader and text size. Accessible & Inclusive covers the general principles. Here we go into what is specific to long reading.

Listening and read-along

Text-to-speech used to sound robotic; modern system voices are good enough for hours of listening, and many people now "read" articles while walking or cooking. Two design patterns matter. First, listening needs its own controls: play and pause, speed (people often listen at 1.2 to 2 times normal), skip by sentence or paragraph, and a sleep timer. Second, read-along, where the spoken word or sentence is highlighted as it is read, helps learners, people with dyslexia, and anyone following a hard text. Microsoft's Immersive Reader (launched in OneNote's Learning Tools in 2016 and now in Edge, Word and other apps) combines read-aloud with highlighting, line focus, text spacing and syllable splitting. Kindle's Immersion Reading pairs an e-book with its Audible narration and highlights the text as it plays. The EPUB 3 standard supports this through "media overlays".

Dyslexia: what helps and what is claimed

Dyslexia is a difference in how people process written language, and it is common: estimates vary with definitions, but a figure of around one person in ten is often cited. Several typefaces have been marketed as "dyslexia fonts", such as Dyslexie and OpenDyslexic, with weighted bottoms and distinct letter shapes. Controlled studies have not found that they help. Rello and Baeza-Yates (2013) found that font type affected reading for people with dyslexia, with sans-serif, monospaced and roman (upright) styles doing better than italic ones, but OpenDyslexic gave no advantage. Wery and Diliberto (2017) found no improvement in reading rate or accuracy with OpenDyslexic for students with dyslexia, and Kuster and colleagues (2018) found the same for Dyslexie compared with Arial.

What has stronger evidence is spacing. Zorzi and colleagues (PNAS, 2012) found that extra-large letter spacing improved reading speed and accuracy for children with dyslexia, likely by reducing crowding (letters interfering with recognition of their neighbours). Larger text, more line spacing, shorter lines, left-aligned text (no justified rivers), and avoiding italics and underlining for emphasis are all consistent with guidance such as the British Dyslexia Association's style guide. Many readers with dyslexia do say they prefer a specific font, and preference matters for comfort, so it is fine to offer one as an option. Just do not claim it treats anything.

"Bionic" reading and other speed claims

In 2022, "Bionic Reading" spread widely: bold the first few letters of each word, the claim goes, and the eye reads faster because the brain completes the rest. It is an appealing idea and a striking visual. But informal tests at the time, including one widely shared by Readwise, found no speed benefit, and the small number of studies since have not found reliable gains in speed or comprehension either. Speed-reading techniques like rapid serial visual presentation (one word flashed at a time) can push speed up, but research reviews have found that comprehension drops as speed rises; you cannot skip the work of understanding. Offer such modes if users ask, label them honestly, and never make them the default.

In the wild

• Microsoft Immersive ReaderMicrosoft, 2016 to now
  Read aloud with highlighting, text spacing, line focus, syllables and parts of speech, across Edge, Word, OneNote and Teams. A bundle of evidence-friendly aids, all optional, all on the same text.
• Kindle Immersion ReadingAmazon and Audible
  Plays the Audible narration while highlighting the e-book text, and keeps your place in both. Listening and reading can share one position.
• Kindle font optionsAmazon
  Kindle offers OpenDyslexic among its reading fonts, alongside its standard book faces. Offering it as a choice, without health claims, respects preference and evidence together.

The same text is a different reading experience on each device, because distance, size, input, light and session length all change. Design one model of the text and a different reading surface for each device class.

A phone is read at around 30 cm, in one hand, in short sessions, often at night, with a thumb. A tablet is held further, often in landscape, in longer sessions, sometimes with a stylus. An e-ink reader is a single-purpose object read for hours, in sunlight and in bed, with page buttons or taps and no motion. A desktop is read at 50 to 70 cm, with a keyboard and mouse, often alongside other windows, for research and writing more than for novels. Each changes the right measure, the right controls and the right defaults.

Same text, different surfaces

Keep one model of the text (content, positions, highlights, notes) and render a different surface per device. On the phone, the margin collapses, so notes become markers and popovers; on the desktop the same notes become sidenotes. On the tablet in landscape, two pages side by side give a book-like spread and a better measure than one stretched column. On e-ink, the same reader drops every transition. Readers who move between devices should find their place, highlights and preferences waiting, but with text size and theme remembered per device (chapter 5).

In the wild

• Apple Books on iPadApple
  Shows two pages side by side in landscape for reflowable books, one page in portrait. Orientation changes the right layout, not just the size.
• Kindle Scribe and reMarkableAmazon, 2022; reMarkable
  E-ink devices with a stylus, built for reading and handwritten notes. On large e-ink, annotation becomes handwriting, and the margin becomes a real place again.
• Readwise ReaderReadwise
  The same library across web, desktop and mobile, with keyboard-driven reading and highlighting on desktop. Desktop reading is a power-user surface; keyboard shortcuts are the calm path there.

Wrap-up

You have now seen reading and writing software from the line up: the length of a line, the light behind it, the way through a long text, the marks you leave, the feeds that bring text to you, and the tools that make new text safely. One idea ran through all of it: these products succeed when the person forgets about them and stays with the words.

Practice assignment for the next two weeks

About 30 minutes a day. The goal is one reading surface and one writing surface in your own product (or a small side project) that you would be proud to use for an hour.

1. Days 1 to 2: audit. Run the reading surface audit and the writing tool audit checklists on your product. Do the interruption log (Exercise 1.1) on your own app.
2. Days 3 to 4: the text block. Fix measure, leading, margins and alignment (Exercise 3.1). Run the three-page stamina test for your reading face (Exercise 4.1).
3. Days 5 to 6: settings and themes. Build reader settings as CSS variables with layered controls and per-device defaults; add sepia and a softened dark theme; test in four lights.
4. Days 7 to 8: place. Store position as a text anchor; add a "where was I" cue and a safe "back to" after jumps. Run the leave-and-come-back test.
5. Days 9 to 10: marks and notes. Add one-tap highlights (or improve yours), a Markdown export, and responsive footnotes on one long page.
6. Days 11 to 12: writing. Make one text field calm: autofocus, focus-friendly, continuous save with truthful status. Run the "try to lose your words" test.
7. Days 13 to 14: everyone. Add a spacing option and test with a screen reader. Then read a full chapter on three devices and write down what you changed and what you learned.

Reading list

• The Elements of Typographic Style
  Robert Bringhurst, 1992 and later editions · the classic on measure, leading, page proportion and the text block. Read the chapters on rhythm and proportion and on shaping the page.
• Practical Typography
  Matthew Butterick, free online · the most usable modern rules for body text, line length and spacing, with clear reasoning.
• "Web Design is 95% Typography"
  Oliver Reichenstein, iA, 2006 · the short essay behind the idea that the reading surface is the design. Then browse iA's blog on focus mode and syntax highlighting.
• Proust and the Squid, and Reader, Come Home
  Maryanne Wolf, 2007 and 2018 · how the reading brain works, and what screens do to deep reading. The mechanism behind chapter 1.
• Words Onscreen: The Fate of Reading in a Digital World
  Naomi S. Baron, 2015 · research on how people read on screens versus paper, and why long-form reading needs care.
• "Books in the Age of the iPad"
  Craig Mod, 2010 · an essay on which books belong on screens and what digital books should do differently. Still sharp.
• "Sidenotes in Web Design"
  Gwern Branwen, gwern.net · a survey of sidenote and footnote implementations on the web, with trade-offs. Pair it with the Tufte CSS source.
• "Local-first software: you own your data, in spite of the cloud"
  Ink & Switch (Kleppmann, Wiggins, van Hardenberg, McGranaghan), 2019 · the case for storage that is fast, offline, owned and collaborative. Essential before chapter 14 decisions.
• Calm Technology
  Amber Case, 2015 · principles for technology that informs without demanding attention. The foundation for chapter 11's calm feed.
• "Does Bionic Reading actually work?"
  Readwise blog, 2022 · a public test of a popular reading claim, timing more than 2,000 readers. A model of checking a claim before shipping it.

Next: Motion & Feel, which explains why the page turn and the typewriter scroll in this guide are timed the way they are. For product teardowns of Kindle, Kobo, Apple Books, Instapaper and Readwise Reader, see Breakdowns: Reading.