Two stories about the same second
When someone opens your page, two stories run at once.
The technical story runs bottom-up: type a URL, resolve DNS, open a connection, negotiate TLS, send a request, receive a response, parse HTML into a DOM, fetch and apply CSS, execute JavaScript, lay out, paint, and finally respond to input. Developers live here. Every course in this sequence touches a stage of it.
The user's story runs top-down, as a chain of questions. Each question only gets asked if the one before it was answered yes:
- Is it there? Availability. The URL resolves, the server answers, nothing in between blocks it. Fail here and nothing else you built exists.
- Did it arrive in time? Loadability. A page that needs thirty seconds on a slow connection is, for that user, down. Page construction and performance live on this rung.
- Can I perceive and operate it? Accessibility. It reached the device — can it reach the person? Eyes, ears, hands, and the assistive technology between them and your markup.
- Can I read it? Internationalization. The page is perceivable — is it in a language and in conventions the reader understands, or can the browser get it there?
- Can I use it? Usability. The reader perceives and understands the words — can they accomplish the task they came for? Conventions, feedback, logic, and expectations.
- Do I want it? Acceptance. The task is possible — is the experience one they'd choose again? Trust, satisfaction, personal and cultural fit.
Wrapped around all six: how would we know? Verification. The web is a highly variable, shared-ownership medium; even a page built right fails somewhere, for someone, today. Monitoring is where the client-side story hands off to the server-side one.
Where your choices meet their questions
| User question | Pipeline stages | Choices that hold it up — or drop it |
|---|---|---|
| Is it there? | URL → DNS → connection → TLS → response | Domain and certificate upkeep, hosting, link hygiene, every third-party dependency you let block the page |
| In time? | Response → parse → render | Payload weight, render-blocking resources, client-side rendering bets, image and font strategy |
| Can I perceive and operate it? | Parse → accessibility tree → assistive tech | Semantic elements, alt text, labels, keyboard support, focus, contrast, honoring user preferences |
| Can I read it? | DOM text nodes → translation layer | lang, real text, complete phrases, logical properties, unambiguous values |
| Can I use it? | Interaction → application logic | Conventions, feedback, error handling, task flow, predictability |
| Do I want it? | The whole experience, over time | Tone, craft, honesty, cultural awareness, respect for the person's time and attention |
| How would we know? | Beacons → collection → analysis | Field measurement, error reporting, analytics — the bridge to the server-side course |
The canyon
The gap between developer experience and user experience is a Grand Canyon of online failure. Choices made for the builder's comfort — a framework that renders nothing until its bundle executes, a component library that emits <div> soup, a build pipeline that ships four megabytes because it was easy — fail users on rungs the builder never tests. The build works on the builder's machine, on the builder's fiber, in the builder's language, with the builder's eyes and hands. Almost nobody else is that user.
This series exists to make the canyon visible. Each lesson pairs the concept with a demo you can break with your own hands: the same store, built with the grain and against it, viewed through one rung at a time.
The series
- PrequelVague but Exciting
Start here. A seven-minute narrated film on where the web came from: CERN in 1989, the three inventions every page still rests on (URL, HTML, HTTP), and what the web was built to be.
- IntroWho Fell Off the Ladder?
A six-minute narrated film: eight people open the same store in the same second, and the ladder decides who gets to buy the fleece.
- 01Availability: is it there, and did it arrive in time?
Rungs one and two, with a fragile and a resilient store you can sabotage in DevTools.
- 02Accessibility: can they perceive and operate it?
A failure catalog organized by ability, with broken and fixed stores to test by keyboard, emulator, and screen reader.
- 03Internationalization: can they read it?
What the browser's translator can and can't reach, a store to translate into German and Arabic before and after the fix, and how to opt out honestly.
- 04Usability: can they use it?
Where a technically flawless page still fails the task.
- 05Acceptance: do they want it?
Trust, satisfaction, and cultural fit at the top of the ladder.
- 06Verification: how would we know?
Monitoring the whole ladder, and the hand-off to the server-side and analytics course.