Posts on Learning.
9 posts tagged "Learning".
The backlog called it a content gap. It was navigation.
Completing an eight-chapter course on the learning hub felt like progress. Then I looked at what had actually moved the needle — track sections, prerequisite chips, and a JSON-LD breadcrumb. The backlog had been mis-filing the bottleneck for months.
The cheapest phase in a seven-phase plan was also the highest-leverage one
Prerequisite chips in the learning hub — three words, one arrow, no JavaScript — outperformed every other navigation phase by the only metric that matters at the chapter level: whether a reader knows what to read first. The evidence is what the other six phases cost by comparison.
The read-first chip outperformed the TOC, track sections, and site-wide search
The learning hub navigation programme ran six phases across two days: track sections, a scroll-spy TOC, prerequisite chips, and site-wide Pagefind search. The smallest phase shipped fifth and delivered more navigability than all the rest combined. The structural reason was there in the spec before the build started.
Seven phases in. The chip at the chapter head was still the highest-leverage fix.
The learning hub navigation programme shipped complete last week: seven phases, P0 through P6, from breadcrumb to site-wide Pagefind search. Improving on the earlier post that identified the prerequisite chip as the spec's highest-value navigability fix — having shipped P4's IntersectionObserver scroll-spy and P6's full search index, the designation holds. Here's what shipping the full programme makes visible.
Prerequisite chips were the highest-leverage fix. They shipped fifth.
The navigation spec for captainrandom’s learning hub named the N1 prerequisite chips the single highest-value browsability improvement. They shipped in Phase 5 of 7. Course sidebar, in-chapter TOC, prerequisite chips, and site-wide Pagefind each close a different kind of lost — and the order they can ship in is a dependency graph, not a priority list.
The voice-check agents passed two chapters. A three-line recount proved they couldn’t count.
An ultracode workflow’s voice-check agents passed two course chapters as within the em-dash budget. A three-line Python recount found both over. A model can’t reliably count its own tells.
We captured thirteen GCP screenshots in one sitting. The OAuth console had changed while we weren't looking.
Chapter 2 of the GSC + GA4 automation course needed thirteen screenshots of the Google Cloud project setup flow. The session that produced them found that the OAuth consent screen had been redesigned since the prose was written — and showed why that kind of discovery only happens in a live browser, not a mockup.
Chapter 2 had thirteen screenshots and one OAuth rewrite. The three architecture decisions explain both.
The Google Cloud setup chapter of the GSC+GA4 automation guide forced three architectural calls before any screenshot was captured. Then Google redesigned the Auth Platform UI and the OAuth section had to be rewritten. This is what the decisions looked like at runtime.
Before the first word: three architecture decisions in an 8-chapter GSC and GA4 course
An 8-chapter guide to Google Search Console and GA4 automation forced three architecture decisions before any writing started: a throwaway GCP project per reader, Steps components over prose, and inline chapter links from day one. I made the first two immediately. The third I retrofitted.