All about Ken Hawkins

A fresh coat of paint and making information actionable for 24 years

2026-08-08T00:00:00.000Z

Over the last months, I've been reflecting on my career, how I position what it is I do and how I use this site to communicate it. ("Person who is good at translating between technical and non-technical stakeholders" is a useful skill, but not what I do, nor a marketable term.) I decided to scratch that itch by looking through some of my old online presences, the websites and the photo archives, expecting mostly nostalgia. But I found new clarity on the same question I work on now: how should information be arranged so someone can find it, understand it and connect it to something else?

The record I can recover runs from 2002 to 2026. The tools changed from static HTML and Flash to content models, semantic embeddings and server-rendered SVG. Reading it back gave this blog a structure it has always needed.

Brace yourself for some meditative navel gazing#

My first website was a GeoCities page I made in high school around 1997. I may never find it again. My memory is that I first edited HTML in HotDog, a Windows editor released in 1995.

What I remember is not the page but the reaction. A friend (Melissa, who I don't think I've spoken to since graduation) and I found it genuinely mind-bending that we could make a thing and have it be there, addressable by anyone, without asking permission or paying a gatekeeper.

The first substantial site I can recover is Environmental Media. The Wayback Machine kept a 2002 snapshot of the site, which I built in 2001 with search, Flash video and an online shop. The implementation is very much of its time; the interest in helping people navigate different kinds of information is less so.

An October 2002 snapshot of Stuffed in a Box preserves a mostly "Coming Soon" site for my tiny web-design service. By April 2003, an online résumé listed Stuffed in a Box Design as a self-owned business and used proper em dashes — way before AI killed being a cool kid who knew how to.

The blog arrived on 5 September 2003. Its first post, "I've done and will do," promised observations about newspapers, infographics, technology, politics and history. A post the following September admitted that it had been nearly a year since the last one, but the intended subjects are recognizable.

Flickr supplies more breadcrumbs, two of them a month apart. In November 2006 I posted a newspaper page I had laid out: every school in five South Carolina districts, rated across four years of state report cards.

South Carolina published words rather than numbers: excellent, good, average, below average, unsatisfactory, for every school, four years running. Words do not stack up. You cannot skim two hundred of them and come away with a shape. Stars you can count, and counting is what a parent looking for their own school actually does.

A month later I uploaded a close-up of a pinched letterform: I was already stopping to admire ink traps in 2006. Something I found myself dwelling on again twelve years later, when considering fonts for digital data.

The next many years would be consumed by TheDigitel.com, an excellent if poorly timed idea for hyperlocal news that I co-founded (2008 was bad for the entire economy, advertiser budgets included). I won't digress into that; it is a full-on post of its own.

Reading the archive instead of scrolling it#

I finally parted ways with TheDigitel in 2011, taking a job offer in Germany, and resurfaced writing on this site in 2013. It now contains roughly a hundred entries written on and off across different jobs, tools and versions of the site. That is a mineable pool: enough to compare topics and surface passages that resemble one another. It is also enough for a conventional reverse-chronological blog to hide most of what is there.

This 2026 redesign began with typography, graph paper and a more technical datasheet vocabulary. Posts gained document references. The archive gained a timeline, while topic pages and small activity charts made it possible to browse by subject rather than only by publication date.

The same entry, before and after. The head now reads like a datasheet: a document reference, a length gauge against the corpus median, and topics with the number of other entries filed under each. Drag to compare, or focus the slider and use the arrow keys.

A blog normally asks, "What did I publish most recently?" A register asks, "What is here, and how does one thing relate to another?"

The newest entry is not necessarily the best way into the work. A 2017 post about information architecture leads more naturally to a 2026 argument about content delivery than to whatever happened to be published between them. A type experiment from 2018 makes more sense beside later work on data fonts and embedded SVG text.

The same pairs, drawn. Each tall arc joins two entries at least three years apart: the 2017 information-architecture post reaching the 2026 content-delivery argument, the 2018 data-font experiment reaching later font work. Height is the years between two entries, never strength. The Story Lab has the interactive version.

My little demo that I've called the "Corpus Story Lab" tests those readings. One view stacks every topic as its own line, so it is possible to see when each was active and which ones came back. Another view assembles "biographies" from a few editorial anchor posts and the entries closest to them in meaning.

Every topic as its own line, offset and overlapping, after Kevin Marks's The Joy of Sparks. Each row is normalized to its own peak, so height compares timing and shape within a row and never volume between rows; the number at the right is that topic's total in the semantic corpus the lab draws on, which runs smaller than the full topic index. The Story Lab has the interactive version.

That typography biography currently begins with writing from 2017 and 2018. The Flickr photograph shows why the larger archive matters: the visualization is not wrong, but its corpus is incomplete.

Three assembled biographies, each a row with its own small timeline. The "Typography and data" trail begins in 2017, so the 2006 ink-trap photograph is nowhere in it; the archive the lab reads only starts in 2013. Notice how every trail's marks bunch toward the recent end. The Story Lab has the interactive version.

Similarity, meaningfully#

This site has a semantic search index which I've used to connect repeated language and adjacent subject matter. It does not show that one idea caused another, that an employer shaped a topic, or even that I consciously remembered an older post while writing a newer one. It also only knows what I have published here: drafts, navigation and everything off-site never enter it, so its totals sit below the topic counts and the decade before 2013 barely registers. The map is candid about its own gaps, and that turns out to be the useful part.

Compounding this, much of the meaning I'd like to draw from still lives elsewhere:

more than a thousand photographs in my Flickr archive, which should not remain their only home;
writing published through employers, projects and publications that now lives on sites I do not control;
small tools and experiments spread across my GitHub repositories;
older versions of this site preserved unevenly in Git history and the Wayback Machine.

The role I want for this site is an index across them: photographs, projects and recovered articles, each carrying its date, its original context and a link back to where it first appeared.

Photography is the part I most want to bring back as an active practice, not only a rescue operation. The current archive is heavily weighted toward words and software.

The site has been rebuilt several times, each migration about the machinery: Drupal, Gulp, Panini, Eleventy, then a much simpler Eleventy stack. This rebuild started with a question about myself instead: how to say what I do without reaching for "person who translates between technical and non-technical people," which is a real skill and a hopeless title.

I have settled, for now, on Digital Platforms & Audience Engagement Lead, but the longer winded, and truer, version is the through line the record keeps showing me: not a platform, not a publishing habit, but repeated efforts to make information legible, navigable, impactful and connected, for the people reading it and increasingly for the machines reading on their behalf.

The fresh coat of paint is fun. The datasheet vocabulary, the timeline and the Story Lab are there to make this collection legible, not just recent.

Twenty years ago I turned two hundred words the state would not add up into a column of stars a parent could count at a glance. This is the same move, pointed at myself: taking a career that only ever arrived one post at a time and arranging it so the shape is finally countable. That is why the archive is worth keeping: enough context to see the shape, and enough structure to keep following it.

I look forward to refining this, and hopefully that refines me.

Field notes on Mac OS 9.2, New World ROMs, and Apple Silicon

2026-06-26T00:00:00.000Z

SheepShaver is a legendary Mac OS emulator (fast, compatible, beloved), but it cannot boot Mac OS 9.2. Iirc, you can coax it to run 9.2 through hacks, but you still won't get all the features.

I really wanted SheepShaver + 9.2 back in the early 2000s.

Twenty-five years on, it is still a nope. You can use QEMU (on Apple Silicon, UTM is the best practical option for 9.2.2 today), but that is not SheepShaver, and you can feel it when using it.

What I still want is SheepShaver's particular trick running classic Mac OS: a thin emulation layer with a JIT. The JIT was only part of why it is fast, translating PowerPC instructions to native at runtime, but the bigger idea SheepShaver offered was what it declines to emulate. Rather than simulating a whole Macintosh, SheepShaver emulates the PowerPC CPU and patches the Mac ROM to route everything else (I/O, memory, threads) straight to the host.

Guest memory is just a region of the host's address space at a fixed offset, so a memory access is pointer arithmetic rather than a simulated lookup. It is not quite Wine on Linux, which translates an OS's API calls without running its kernel at all, but it sits much closer to that tightly integrated end of the spectrum than to a fully virtualized machine.

QEMU JIT-translates PowerPC too: its TCG engine dynamically recompiles guest code to native ARM64. So the gap is not really JIT versus interpreter. It is everything around the CPU. QEMU simulates every piece of hardware the original Mac would have seen (the VIA chips that handle timers and interrupts, the ADB controller behind the keyboard and mouse, the SCSI bus that talks to disks, the whole stack) rather than patching the OS to use host services directly. That means translating every guest memory address in software (a TLB lookup) and calling out to C helper routines for low-level system instructions. Community benchmarks put SheepShaver at roughly 5× QEMU's overall score on comparable hardware, with the floating-point gap closer to 10×.

In practice QEMU/UTM on classic Mac workloads feels like running on a ~300 MHz G3: usable and stable, but noticeably slower than SheepShaver at 9.0.4. SheepShaver avoids most of that overhead because it was never a full-system emulator: it runs guest threads as real host threads and uses a JIT that skips supervisor-mode emulation entirely. That architecture is also why it tops out at 9.0.4: the New World ROM that 9.2 requires actually needs the hardware emulation layer SheepShaver has always refused to implement.

Getting SheepShaver's speed and Mac OS 9.2 together, without hacks, turned out to be a much harder problem than it looked.

The rabbit hole went deep.

My history with classic Mac OS was in desktop publishing: Quark 4 on Mac OS 7, PostScript ads that could lock the whole system, the peculiar texture of cooperative multitasking. By the time I was doing web work seriously, I was already on Mac OS X. What I had never touched was the programming side of it: what classic Mac development actually felt like, the toolchain, building something for the platform from scratch. I had always been curious about that.

I have a Quicksilver G4 and a few iBooks in the basement that could theoretically address this. But they are loud, take up space, and draw significant power. So I have been approaching it from modern conveniences instead.

Over the past year that has meant several experiments at once. Classic-vibe-mac compiles C source to a 68k Mac binary and runs it live in System 7.5.5 via WebAssembly Basilisk II; writing Mac programs without leaving the browser. Scriptoscope is a Mac OS-style window manager and Kaleidoscope theme engine for the browser. PDF-A-go-slim borrowed the floating palette paradigm from the 1995 Mac OS Human Interface Guidelines and applied it to a modern browser utility. All of that was aesthetics and runtime at arm's length from the actual software.

Macsurf pushed it closer — a classic Mac app I wanted to compile on QEMU. But that was slow, which led me back to SheepShaver, which led to the problem above.

The detour to Apple Silicon, and then 9.2#

SheepShaver for ARM carries a fork chain:

the original cebix/macemu,
community-maintained by kanjitalk755,
then an ARM64 JIT backend by rcarmo targeting Linux ARM boards.

Nobody had yet taken it to macOS Apple Silicon. Getting there first meant porting that JIT backend to a platform with tighter constraints: MAP_JIT for executable pages, Mach exception handling instead of POSIX signals, address space limits that interact with SheepShaver's unusual architecture in specific ways.

SheepShaver was designed in the late 1990s to run native PowerPC Mac code on native PowerPC Linux. There was originally nothing to emulate at all, just the Mac-specific hardware. That cooperative design is still baked in everywhere, and a lot of its assumptions about address space and memory layout needed rethinking for a modern macOS host.

Getting to 9.2 is a different layer of the problem and one that isn't done yet for any flavor of SheepShaver.

I've put a lot of time into understanding how the nanokernel interacts with the MMU, figuring out what needs to be properly modelled versus what can be safely sidestepped, and then circling back to do real implementations after those investigations proved the shortcuts would not hold. I had expected to draw more directly on existing work, and dingusppc in particular taught me a great deal. It takes the opposite approach to SheepShaver: full-system, device-accurate emulation of older PowerPC Macs (the SCC serial, VIA timer, and ADB controllers SheepShaver skips entirely), with a focus on Old World and beige-G3 hardware. That accuracy-first model is much closer to what the New World ROM actually expects, so it was a valuable reference for the hardware layer even though I was not trying to build the same kind of emulator. QEMU was the other early reference, but it turned out to be most useful as a diagnostic tool rather than an architectural model. The biggest unexpected source of inspiration was Dolphin, the GameCube and Wii emulator: a completely different platform, but the same class of problem.

Much of this has been done in collaboration with an AI coding partner. I wrote about that working pattern in let the AI worry about the code, you worry about the work. This project pushed it further than I expected: less about delegating implementation tasks, more about managing a technical investigation across sessions: knowing when to go deep, when to step back, when a hypothesis had been falsified and it was time to try something else. Project management skills translate into this kind of work more directly than I would have guessed.

The result: SheepShaver boots Mac OS up to 9.0 to the Finder desktop on M-series Macs, with a native AArch64 JIT on by default. There is also preliminary AltiVec support, opt-in for now, because Mac OS 8.6 and 9.0 do not save vector registers across task switches.

I'm still not yet there for 9.2 support, but I am getting incrementally closer. Keep reading...

What is next#

The Apple Silicon JIT work was the prerequisite. Mac OS 9.2 is the actual goal. It is worth being honest about why 9.2 specifically: the features it adds over 9.0 (preemptive multitasking, proper memory protection, 128-bit file encryption) are not things I actually need. Nobody is running production workloads on a classic Mac. But most ambitious hobby projects do not have a compelling real-world justification; that is more or less what makes them hobby projects. The point is getting the thing right. That said, if this all comes together, Final Cut Pro 3 on SheepShaver becomes possible. Which is entirely unnecessary and, I think, quite cool.

Running alongside it: SiliconSheep, a native macOS launcher for SheepShaver that makes the day-to-day experience less of a configuration exercise.

Neither is done. This post is less an announcement than a status note: here is what has been happening, here is what is in progress.

More than nostalgia#

While a lot of this is nostalgia, there is a less sentimental case, and it comes down to how software gets written now.

Building for classic Mac OS was always a grind: period hardware, a finicky toolchain, slow edit-build-test loops on machines that are rare and getting rarer. That friction is most of why the development scene faded. Coding agents change those economics. The same kind of AI partner that helped port this emulator can write 68k and PowerPC code and find its way around an unfamiliar toolchain, which collapses the loop that used to make this work tedious.

Put a genuinely easy-to-run environment on modern hardware next to that, and a path opens up: writing new classic Mac software again. Some of it would run inside Mac OS 9 on an M-series laptop; some could compile down to the real beige hardware still humming in basements. Classic-vibe-mac was a first hint of this; a fast SheepShaver is the other half. I am not promising a renaissance. But the thing that always killed it was friction, and removing friction is exactly what these tools are good at. Get the development experience right and the rest becomes possible.

I do not have formal domain expertise in emulator development. What I have is curiosity, some stubbornness, and an AI partner that turned out to be a good collaborator on gnarly low-level problems. AI will not be to everyone's taste, and I understand that. It is a hobby project; I am sharing it back in case any of it is useful, not because anyone has to approve of the method.

How far this goes, I am not sure yet. But the Finder boots on my M-series Mac with JIT, and I think I could crack 9.2, too.

CADI: a prescriptive path for slop-free AI in content work

2026-06-09T00:00:00.000Z

Recently I was in a meeting with colleagues talking about how people across the organisation are using AI in their writing. What I heard:

"I just prompt it and ship. We don't have time to fuss."

"I use it for ideas, but I still write the piece myself."

"I rewrite every line. I'm honestly not sure I'm saving any time."

"It's infuriating."

"I see other people using it and I see the same repetitive AI tells bleeding through."

"I'm not convinced any of this is worth it. The old way was quieter and probably better."

"Other organisations are using it. We can't be the only ones not."

—

"Should I just get better at prompting?"

"Should I write a style guide?"

"Should I build an agent?"

"Should I document my preferences somewhere?"

"Should I upload my existing content?"

The honest answer is always some version of "yes, but in a specific order, and most of the value comes from the combination." Helping colleagues do better is frustrating as it's a repetitive conversation and it's far too conceptual for many to put in practice.

So I documented it. This is CADI — Collect, Analyze, Document, Iterate — a prescriptive path through the confusion.

The name nods to a caddie in golf: carries the load, doesn't take the swing. It's designed to be followed roughly in order, at least the first time through.

An experienced editor with access to your content can produce a first usable version of the guidance in a few hours by feeding curated examples to a language model and shaping what comes back. Then it's an editorial process: share it with colleagues, use it for a few days, fold their reactions in. Each round sharpens the guidance; the work doesn't get heavier, the picture gets clearer. It works for any content type or language, as long as you have enough of it to learn from.

The problem: every prompt starts from zero#

Most AI writing assistance starts cold every time. No memory of what worked last time. No sense of your voice, your standards, your audience. So it gives you something generic and confident, and you spend the rest of your time correcting it.

The fix isn't a better prompt. It's giving the AI a documented picture of what good looks like for you, and building a way to improve that picture as you learn what works. Done right, the AI gets more useful over time rather than requiring the same effort on every task.

There's a failure mode that persists even after you think you've solved this: confident wrongness + silent drift. The AI sounds authoritative but cites a source incorrectly. It hits approximately the right word count but adds a paragraph that subtly changes your meaning. These are harder to catch than obvious nonsense, and they accumulate faster.

Where you probably are: supervised co-writing#

Most people using AI for writing aren't doing "autonomous AI publishing." They're doing supervised co-writing: AI handles a first pass or a tedious task, a human reviews and corrects, a human publishes. That's normal; it's also where most of the real value is right now.

CADI is for teams who want to move from "AI is something we sometimes use" to "AI is something our editorial standards reliably shape." That transition doesn't happen through better prompting alone.

Before you start: five things to check#

This framework works best when you can answer yes to these:

You have ideally 50+ published items you consider high-quality (not just recent). 10–20 from a tight, high-quality domain still works; you'll overfit a little, but the discipline of running the loop is what compounds
You have some signal for quality: engagement data, editor picks, longevity tags, or even manual curation
At least one person has time to own the guidance doc and keep it current
You have some way to export content from your CMS in text form (Markdown, HTML, CSV)
Editors are willing to log failures rather than just silently fix them

You don't need a data science team, a custom CMS, or a formal AI strategy. But if no one will own the guidance document, the method breaks down.

Pick your tool#

Before you start, decide how you'll feed your content to an LLM. The choice shapes every step that follows.

NotebookLM or similar. Best if your content is web-accessible. Drop URLs or PDFs as sources; run prompts in the chat. Zero file handling.
A local agent (Claude Code, GitHub Copilot CLI, or similar). Best if you've exported your content as files. Point the agent at the directory and ask it to run the prompts. Handles iteration and cleanup for you.
Manual pipeline (browser-only). Fallback when the other two aren't options. You'll preprocess HTML, concatenate, and paste into a browser tool. The starter kit has the prompts.

The rest of the post assumes you've picked one. When a step says "run the Analyze prompt" or "feed the corpus to your model," substitute your chosen tool's mechanics.

The CADI framework: Collect → Analyze → Document → Iterate#

CADI is a four-phase loop. You build it once, then run the last phase continuously. Each cycle makes the guidance sharper, and the AI more useful.

The bit most AI-writing advice misses: the guidance document is something you test and revise. C, A, and D get you a first version. I is where it earns its keep.

I've arrived at this through practice, and written about the pieces separately. This is the first time I've named it.

C — Collect: Extract your best examples#

Your best content already embodies your patterns: word counts, title structures, tag usage, narrative flow. Don't grab the latest 50 published items; curate the exemplary 50.

Start with one content subtype, not a mix. Most organisations publish several things that look similar but follow different patterns: press releases, news briefs, feature reports, donor updates, blog posts. Each has its own voice and structure. Mixing them gives you average patterns that fit none of them. Pick the subtype that matters most to you right now and run CADI on that. Repeat for other subtypes later.

Don't default to top-traffic items. That's the obvious choice and the most common mistake. High traffic often correlates with topic timeliness, social-share luck, or audience reach, not with the qualities you'd want to reproduce. Three signals to combine instead:

Editorial investment — items your team spent the most time on. Effort is a quality signal even when the numbers aren't there.
Aspirational fit — items you'd want more of your output to look like.
Performance for type — a press release that did 5× the median for press releases tells you more than a feature that hit Hacker News.

Document the criteria you used. It will matter when you audit later.

Bring your existing reference materials too. Your best content shows the agent what good looks like by example. Your existing editorial handbook, brand guidelines, glossary, terminology and spelling lists, institutional style memos — these tell it the rules you want enforced. Add them as sources alongside the corpus. The agent should be able to cite them when producing drafts ("per our spelling guide, we use 'organization' with a z") and link to them when justifying its choices. If your handbook says "no Oxford comma," the corpus pattern alone might not surface that as a hard rule.

Getting the files to your tool. With NotebookLM, add the URLs or PDFs of your 50–100 best items as sources. With a local agent, export your content as HTML to a directory and point the agent there. With the manual pipeline, follow the four steps in the starter kit. One-time setup per content subtype.

👉 Ready to move on when: you have 50–100 items in a single consolidated, cleaned document; you've written down why they qualify; and an editor has spot-checked for obvious outliers.

For implementation detail, including Drupal export code and a worked UNDRR case study, see Improving AI chatbots with an editorial handbook from your best content.

A — Analyze: Find quantitative patterns#

Feed your curated examples to an LLM with a structured prompt to extract:

Average word counts (with ranges, by content type)
Title formats and syntactic shapes (% using colons or question marks; whether titles assert claims, ask questions, restate the source headline, or use first-person observation)
Heading and structural patterns (do longer pieces get H2s? At what word-count threshold? Lists vs. prose?)
Voice markers (first vs. third person, contractions, hedging language, sentence-length variance)
Source treatment (% linking sources inline, % using blockquotes from the source, whether the source is named in the first paragraph)
Opening and closing patterns (does the first paragraph name a topic, a scene, a source? Does the last forward-link or name a broader pattern?)
Cross-linking density (internal links per piece; what fraction connect to other content on the site)
Metadata usage (tag counts, co-occurrence patterns)

This list isn't exhaustive. Your subtype will have its own tells — repeated structural moves, signature phrasing, specific rhetorical positioning. Add the signals that matter for your content; document what you watched for. It'll be the first thing you revisit on the next cycle.

LLMs handle this extraction well; the interpretation is still yours. The output is not guidance yet; it's empirical description of what your best content actually looks like.

👉 Ready to move on when: you have a written summary of patterns with numbers, and at least one editor has reviewed it and flagged anything that looks wrong or unrepresentative.

D — Document: Turn patterns into working instructions#

Combine what the analysis found with your existing institutional knowledge (style guides, brand standards, domain constraints) into a single document your AI tool can use as its standing instructions. Link or embed any existing reference docs your team already maintains; the guidance doc should point at them rather than restate them, so editors and the agent can both trace any rule back to its source.

If your existing style guide already addresses this subtype, the Document step isn't to re-derive from scratch. It's to tighten the existing guidance with the numbers the Analyze step produced, and override only where you have evidence the guidance was wrong.

This step requires editorial judgment: observed patterns and existing style rules will sometimes conflict. If the analysis says your best titles average 8 words but house style caps them at 6, decide which wins and log why. Write it down; that decision belongs in your change log, not left implicit.

You end up with instructions concrete enough to act on ("180 words ± 10%") rather than vague ("be concise"). Bonus: the same document works for human editors too.

👉 Ready to move on when: the instructions have been reviewed by at least one editor who wasn't involved in writing them, and they've been uploaded or integrated with your AI tool.

I — Iterate: Build confidence over time#

Iteration done badly is just tweaking in the dark, which is how we started. Done well, it's hypothesis-driven:

"IF we add explicit numeric targets ('180 words ± 10%'), THEN first-pass acceptance rises from 40% to 70%" (illustrative)
"IF we show exemplars of title styles, THEN AI chooses appropriate titles 85% of the time" (illustrative)
"IF we run oppositional review (a second model critiques our guidance), THEN we catch biased rules 80% of the time" (illustrative)

Then test them: run a simple before/after comparison on real content, measure outcomes with a concrete metric, and document what changed and why.

For a small team (2–3 editors), 20–30 items per condition is enough for an honest qualitative comparison: better than tweaking blind, not a statistical signal. Anything closer to statistical rigour needs much larger samples and blinded review; most editorial teams won't reach that, and that's fine. The bar is qualitative honesty: what changed, and why.

Mid-cycle revision trigger: if more than 20% of outputs in a week fail the same check, don't wait for the quarterly audit. That's a pattern worth investigating now.

None of this is invented from scratch. Other disciplines have been at versions of this for decades:

Writer and Jasper will both reverse-engineer a voice profile from examples of your own content; worth knowing about, and worth using if they fit your stack.
ChainForge (CHI 2024) formalized treating prompts, and the evaluation criteria themselves, as testable hypotheses.
Medical guideline development (AGREE II and GRADE) assess whether guidelines are evidence-based and implementable. The Australian COVID-19 living guidelines went further: revised and republished weekly for 24 weeks as new evidence arrived, a continuously iterated guidance document running in production

But a software subscription isn't a method, and a research paper isn't a guide. What I haven't seen elsewhere is the connected discipline: deriving guidance from your own curated corpus, then keeping the failure log and test record that make that guidance revisable on evidence rather than vibes. That combination is what CADI names. If reading this sends you off to subscribe to one of those tools or build your own loop from the research, good; that's the point. Prior art still welcome.

👉 Ready to move on when: you have at least one completed hypothesis test, a documented decision (kept or rejected), and a failure log that someone is actually adding to.

CADI in practice: how it played out at UNDRR#

One case illustrates the full loop:

Collection: 122 publications flagged as "evergreen + high-engagement" in Drupal
Analysis: LLM extracted patterns. "169 words average; 56% use colons in title; all use 2–4 themes"
Documentation: Guidance doc drafted and uploaded as standing instructions in Microsoft 365 Copilot
Iteration: Quarterly audits checked whether new AI drafts matched patterns; a shared change log recorded what was adjusted and why

The honest version of the result: before CADI, none of these pieces (curation, pattern extraction, guidance docs, iteration) reliably produced anything usable on its own. They were ad-hoc, inconsistent, and each task started over. Running them as a connected loop turned a set of one-off attempts into a process that ran continuously and got better. The framework's value wasn't a single big number; it was making something repeatable that hadn't been. The longer case file (the original methodology, plus what the guidance doc looked like in practice) is in the UNDRR impact story.

And I'm not pretending what I have is rigorous yet. What would make the next version genuinely rigorous is a prospective A/B test that quantifies which guidance changes move which outcomes by how much. That's the piece most teams skip; writing this down, sharing it, and letting it be challenged is part of how I keep tightening the loop.

Using CADI in the writing workflow#

CADI gives you the guidance layer. The day-to-day writing that uses it has a shape of its own:

Ideation — what are we writing, for whom, why now? AI helps brainstorm; the editorial decision is yours.
Scaffolding — outline, key points, source material. CADI's guidance doc steers tone and structure; the agent helps assemble.
Drafting — produce the first pass with the guidance doc as the agent's standing context.
Review — apply role-based passes for the checks this piece needs.

The review step is where you pick agent roles that match the piece's risk and shape. The ones I've found useful:

Copy editor — grammar, flow, voice consistency against the guidance doc
Adversarial reviewer — does the argument hold? What's the strongest counter?
Legal / compliance check — for content with regulatory exposure
Copyright check — for content with quotation, imagery, or external sourcing
Technical reviewer — for content making claims about systems, code, or data
Sanity check — final read for "does this make sense, end to end?"

Not every piece needs every role; pick what fits the content type and its risk profile. The CADI guidance doc gets stronger when failure-log entries name which role would have caught the failure — that's how you learn which checks belong in which subtype's workflow.

A deeper walk-through, with prompts and examples for each role, is coming in a follow-up post.

Trust but verify: the publication gate#

The trust-but-verify gate sits between any CADI-assisted draft and publication. Don't skip it, even once you trust the system:

Verify factual claims and sources independently
Verify hard constraints (word/character counts, required fields). Don't trust the model's own count
Verify meaning hasn't drifted from source intent
Keep human sign-off as the final release gate

For many teams, a parallel run is the safest transition: keep your normal manual editorial review while running AI-assisted output alongside it. Compare decisions, measure drift, then scale what proves useful.

This is also the spirit of the editorial AI policies emerging in newsrooms, where Ars Technica and Fedora make "reviewed" a protected verb with the human review step explicit and named. CADI takes the same position: the loop doesn't replace the gate; it makes the gate cheaper to operate.

Where this breaks down#

Iteration goes blind again when:

Encoding bias without inspection: a pattern like "short sentences good" might just reflect that your exemplars targeted beginners; applying it universally infantilizes advanced content
Optimizing for fit, not truth: "this tag co-occurs 26% of the time, so ALWAYS pair them" (should be "consider pairing")
No quality gate on source: including mediocre content in your "best" set skews guidance toward mediocrity
Stopping too early: 10 examples isn't enough; 500 might over-fit
Expecting voice cloning in informal genres: the style-imitation research is encouraging for structured formats like news and email, and much weaker for informal, personal writing like blogs and forum posts. Corpus-derived guidance reliably reproduces structure and conventions; a distinctive personal voice still needs the human pass

Prevention: transparent curation criteria, documented assumptions, human review between cycles, oppositional analysis (ask a second model to critique your instructions), and built-in escape hatches ("usually X, unless Y").

Where CADI doesn't fit cleanly: high-volume newsrooms shipping dozens of pieces per week across many content subtypes. CADI assumes one primary subtype at a time and a corpus you can read in full. Sampling methodology and per-subtype parallel runs are needed there. Out of scope for this post, but the same loop applies once you've made those decisions.

What you maintain alongside the loop#

These four documents are what CADI actually leaves you with. The starter kit has templates for each: cadi-starter-kit.txt.

A curation criteria note — why these items qualified as exemplary, and not others
Your working AI instructions — the guidance doc the AI uses as its standing context
A failure log — the one document that's more valuable than the guidance doc itself; it's where the next iteration starts
A test record — what you tested, what changed, and why

If no one is keeping at least the failure log current, you're not iterating; you're just running C/A/D once and hoping.

After your first cycle, go deeper#

These earlier posts go deeper on individual phases. You don't need to read them to start.

Improving AI chatbots with an editorial handbook from your best content: the C and A phases in detail, with Drupal export code and the full UNDRR case study (updated June 2026)
The power of the pause: How planning beats prompt tuning: structure over tweaking, with PROJECT_BRIEF → PROJECT_PLAN → PATTERNS workflow
Thoughtful AI integration beats bolted-on Clippy: product thinking for AI integration, when to use it, not just how to prompt it
Why context engineering was always the job: where CADI sits in the broader move toward context as the work
The four phases of AI adoption: the Complement / Integrate / Delegate / Orchestrate taxonomy; CADI lives around Integrate and Delegate

CADI is the loop we run at UNDRR. Think of it as a forcing function more than a magic generator: most of the work is still you reading your own content carefully. The framework just makes sure you do it, and write down what you learn.

It works for us; it might work for you; or it might need reshaping for the volume, content type, or constraints you're in. I'd be curious how it lands once you try it: what you change, what breaks, what surprises.

One direction I'm exploring: packaging CADI as a guided Claude skill (or similar) that asks where your content lives, walks you through the curation criteria, runs the Analyze prompt for you, and hands you a draft guidance document ready for editorial review. If that'd be useful, drop me a note.

The first run of this framework on this site is preserved as a worked artifact: CADI cycle 1 — digesting posts (June 2026). Future cycles will build on it.

References#

Bsharat et al., "Principled Instructions Are All You Need" (arXiv:2312.16171): a preprint reporting an average 57.7% quality boost from 26 generic prompting principles on GPT-4. Small, author-judged benchmark; read it as directional support for structured prompts, not as evidence for corpus-derived guidance specifically
"Catch Me If You Can? Not Yet: LLMs Still Struggle to Imitate the Implicit Writing Styles of Everyday Authors" (EMNLP 2025 Findings): exemplar-based prompting consistently beats instruction-only prompting for style matching; strong in structured genres, weak in informal ones
Wu et al., "ScatterShot: Interactive In-context Example Curation for Text Transformation" (ACM IUI 2023): systematic example curation beats ad-hoc hand-picking, which tends to capture only the most obvious patterns
Arawjo et al., "ChainForge: A Visual Toolkit for Prompt Engineering and LLM Hypothesis Testing" (CHI 2024)
Tendal et al., "Weekly updates of national living evidence-based guidelines: methods for the Australian living guidelines for care of people with COVID-19" (J Clin Epidemiol 2020)
Wei et al., "Chain-of-Thought Prompting Elicits Reasoning" (2022)
Yao et al., "Tree of Thoughts: Deliberate Problem Solving with LLMs" (2023)
Kohavi, Longbotham et al., "Controlled experiments on the web: survey and practical guide" (2009, Data Mining and Knowledge Discovery)
AGREE II — instrument for appraising the quality of clinical practice guidelines (the discipline of judging whether your guidance itself is sound)
GRADE — framework for grading the certainty of evidence and the strength of recommendations (separating "we're sure" from "we think")
Diátaxis — documentation framework organising knowledge by user need (tutorials, how-tos, reference, explanation) rather than by topic
PRISMA — reporting standard for systematic reviews (a checklist for how to describe what you did, so others can trust or replicate it)

A data font, from the inside out

2026-05-12T00:00:00.000Z

Datatype, by Frank Tisellano, is a variable font that renders inline bar charts, sparklines, and pie charts straight out of OpenType ligatures. Write {b:30,70,50,90} and get ; no JavaScript, no SVG, no charting library involved. It's also a total inversion of a 2018 piece of mine, A web font for data.

tl;dr

Datatype turns text like {b:30,70,50,90} into inline charts via OpenType ligatures: bar, sparkline, and pie, with weight and width axes.

It rhymes with a 2018 piece of mine, What if: A web font for data, but inverts it: my version was a font for reading dense data, this is a font that is the data.

The upstream project ships zero accessibility guidance; for any serious use, pair each chart with aria-hidden on the glyph span and a visually-hidden data table. There's a copyable pattern below.

A data font and font for data#

Back in 2018, while at EMBL-EBI, I wrote a long piece called What if: A web font for data. My problem was that life-sciences researchers stare at strings like ENSMUST00000032717 all day, and the tools they were using rendered those strings in fonts that had not been designed with that kind of work in mind. Sequential zeros were ambiguous (is 20000001 six zeros or seven?). Lowercase l, uppercase I, and numeric 1 could be hard to tell apart in body widths. BuMpy caPitiLiSation patterns were brittle to read at a glance. My sketch was a font where the ligature feature did the same kind of work Fira Code does for code, but pointed at scientific identifiers: chunking long zero runs, disambiguating glyphs, giving the reader's eye better handles.

Datatype is also a data font, and it's also built on the OpenType ligature feature. But it inverts every part of the goal. The text isn't there to be read in the normal sense; it's there to be drawn. The ligature substitution doesn't help you decode the characters — it replaces them entirely with a chart. The font isn't a better tool for the reader. The font is the data.

Clearly the aims are different, but the mirror universe aspect tickles my brain.

Datatype also credits IBM Plex Mono as the source of some underlying glyphs, and IBM Plex was the typeface I wrote about back in 2017 when we were evaluating it for EMBL-EBI's scientific data work. Neat.

Accessibility gap#

Data viz accessibility is always a challenge. Left alone, a string like {b:18,21,12,12,15,0,0,0,100,94} gets read aloud verbatim, brace by digit by comma. That's worse than no alternative at all.

This is made a bit better by the WAI pattern for complex graphics. Mark the glyph span aria-hidden, and pair each chart with a visually-hidden data table that assistive technology can navigate as proper rows and cells:

<p>
  Posts per year, 2017–2020:
  <span class="chart" aria-hidden="true">{b:60,70,40,40}</span>
</p>
<table class="kh-u-sr-only">
  <caption class="kh-u-sr-only">Posts per year, 2017–2020</caption>
  <thead><tr><th scope="col">Year</th><th scope="col">Posts</th></tr></thead>
  <tbody>
    <tr><td>2017</td><td>6</td></tr>
    <tr><td>2018</td><td>7</td></tr>
    <tr><td>2019</td><td>4</td></tr>
    <tr><td>2020</td><td>4</td></tr>
  </tbody>
</table>

Posts per year, 2017–2020:

Posts per year, 2017–2020
Year	Posts
2017	6
2018	7
2019	4
2020	4

I want an excuse to use it#

My enthusiasm for variable fonts as an expressive runtime is sitting at about (roughly 85 percent), while my likelihood of actually reaching for Datatype on the next chart I ship is somewhere around (roughly 25 percent). The gap between those two pies is basically the whole post.

Frank's specimen site is worth a visit on its own; the variable-axis sliders and live examples are a small showcase of typographic care.

Try Datatype on the project site →

Building a virtual garage for hobby projects

2026-05-09T00:00:00.000Z

I've been building hobby projects for years. Normally I'll give the better ones a write-up here and a link to GitHub Pages, but the project itself lives at khawkins98.github.io/project-name/.

I wanted to bring them on-domain without the obvious headaches: dozens of subdomains is more infrastructure than any of these deserve, subdomains still confuse people, and copying build output into the main repo defeats the point of keeping them separate.

Could I just have my site do what GitHub Pages already does: proxy /repo-name/ to whatever GitHub is already serving?

Before: khawkins98.github.io/PDF-A-go-go
After: AllAboutKen.com/PDF-A-go-go

Same project, same deploy pipeline, better home.

See the garage

Keep reading if you want to see exactly how I wired it up.

tl;dr#

Vercel rewrites proxy /project-name/:path* to the GitHub Pages origin — no deploy changes required

A naive rewrite 404s on the project root; two redirects entries (bare path and trailing slash → /project-name/index.html) fix it

Each project keeps its GitHub Pages URL; a hostname-check script redirects those visitors to the canonical URL

CORS headers on proxied paths cover shared JS assets loaded via fetch()

A /garage/ index page on the main site ties all the projects together

What I didn't want to do#

The obvious path is a merge: monorepo, or move each project to Vercel as a separate deployment. Both mean real work per project: consolidated CI, shared dependency trees, combined issue trackers. Hobby projects earn their independence precisely because they're free to be messy and self-contained. The right fix is a smarter routing layer in front, not a restructuring underneath.

How the proxy works#

My site was already on Vercel and each project already served from https://khawkins98.github.io/repo-name/.

Vercel rewrite rules can proxy a path prefix to an external origin. Minimum viable vercel.json:

{
  "rewrites": [
    {
      "source": "/PDF-A-go-go/:path*",
      "destination": "https://khawkins98.github.io/PDF-A-go-go/:path*"
    }
  ]
}

Requests to allaboutken.com/PDF-A-go-go/anything forward to khawkins98.github.io/PDF-A-go-go/anything. The GitHub Pages deploy keeps working at its original URL unchanged.

This works for every path except the project root.

The trailing-slash problem#

Going to allaboutken.com/PDF-A-go-go/ still gave a 404, even with the rewrite in place. The reason is Vercel's processing order: filesystem matching (including a directory-index check for build/PDF-A-go-go/index.html) runs before rewrites. That file doesn't exist in the main site's build, so Vercel 404s before the rewrite ever fires.

Two redirects entries fix it. Redirects run before filesystem matching:

{
  "redirects": [
    { "source": "/PDF-A-go-go",  "destination": "/PDF-A-go-go/index.html", "permanent": false },
    { "source": "/PDF-A-go-go/", "destination": "/PDF-A-go-go/index.html", "permanent": false }
  ],
  "rewrites": [
    {
        "source": "/PDF-A-go-go/:path*",
        "destination": "https://khawkins98.github.io/PDF-A-go-go/:path*"
    }
  ]
}

Visiting /PDF-A-go-go/ now redirects (302) to /PDF-A-go-go/index.html. No directory-index ambiguity; the rewrite fires and proxies to GitHub Pages. The browser ends up at /PDF-A-go-go/index.html, where relative asset paths like ./app.js resolve correctly to /PDF-A-go-go/app.js.

Not burning the old address#

GitHub Pages keeps serving at khawkins98.github.io/project-name/. The Vercel setup is additive: the personal domain gains a route, the original URL stays live. Rolling back is two deleted lines in vercel.json.

For now I've only moved two projects across — PDF-A-go-go and pinment — while I confirm that existing embed links aren't affected. The redirect from khawkins98.github.io to the proxied URL could in theory break things for anyone who has embedded the old URL directly. Once it's clear nothing is breaking, adding the rest is a few lines in vercel.json.

But visitors arriving at the old URL should reach the canonical one. A small script at the top of each project's <head>:

<script>if(window.location.hostname==='khawkins98.github.io'){window.location.replace('https://www.allaboutken.com/PDF-A-go-go/')}</script>
<link rel="canonical" href="https://www.allaboutken.com/PDF-A-go-go/">

The hostname check is essential. Without it, the redirect fires on the proxied page too: allaboutken.com proxies to github.io, github.io redirects back to allaboutken.com, repeat. The check breaks the loop.

Don't forget: CORS for shared JS assets#

Pinment is a bookmarklet tool. Its install snippet builds a script URL from window.location.origin at runtime, so it always points to whichever domain the user is visiting from. Through the Vercel proxy, that becomes allaboutken.com/pinment/pinment-bookmarklet.js, which the rewrite proxies correctly to GitHub Pages.

<script src> tags don't trigger CORS, but fetch() does. A headers block in vercel.json covers it:

{
  "headers": [
    { "source": "/pinment/:path*", "headers": [{ "key": "Access-Control-Allow-Origin", "value": "*" }] }
  ]
}

Worth adding for any project that exposes public JS assets loaded programmatically from other pages.

The full configuration#

{
  "buildCommand": "yarn build",
  "outputDirectory": "build",
  "headers": [
    { "source": "/PDF-A-go-go/:path*", "headers": [{ "key": "Access-Control-Allow-Origin", "value": "*" }] },
    { "source": "/pinment/:path*", "headers": [{ "key": "Access-Control-Allow-Origin", "value": "*" }] }
  ],
  "redirects": [
    { "source": "/PDF-A-go-go",  "destination": "/PDF-A-go-go/index.html", "permanent": false },
    { "source": "/PDF-A-go-go/", "destination": "/PDF-A-go-go/index.html", "permanent": false },
    { "source": "/pinment",  "destination": "/pinment/index.html", "permanent": false },
    { "source": "/pinment/", "destination": "/pinment/index.html", "permanent": false }
  ],
  "rewrites": [
    { "source": "/PDF-A-go-go/:path*", "destination": "https://khawkins98.github.io/PDF-A-go-go/:path*" },
    { "source": "/pinment/:path*", "destination": "https://khawkins98.github.io/pinment/:path*" }
  ]
}

Adding another project#

Confirm GitHub Pages is enabled and serving at USERNAME.github.io/repo-name/.
Check asset paths: ./-relative or prefixed with the repo name. Bare /styles.css will break.
Add two redirects entries and one rewrite to vercel.json.
Add the hostname-check script and <link rel="canonical"> to the project's index.html.
Add the project to the garage page.

For SPAs with client-side routing: the project needs a 404.html on GitHub Pages that loads index.html. The proxy can't route to paths the GH Pages deploy doesn't know about.

The full configuration and checklist live in vercel.json and docs/DEPLOYMENT.md. Nothing about the project deploys has to change: GitHub Pages stays the origin, Vercel becomes the routing layer. See what it looks like in practice at the garage. If you've proxied projects this way — or found a cleaner approach — I'd be glad to hear about it. The projects just get to live at home.

I think this is a clean way to bring web projects back home without adding server complexity.

Eye-tracking heatmaps in your browser, no lab needed

2026-05-03T00:00:00.000Z

At some point in most design or content reviews you find yourself trying to answer a question you can't answer cleanly: not "is it pretty?" but "will users actually notice the call to action, or are they going to get distracted by the hero image first?"

The honest answer is usually "Based off my knowledge and experience: I think so." That only holds until a stakeholder who disagrees says the same thing.

Foveacast gives both of you something to look at instead. Drop a screenshot of a UI — a web page, an app screen, a mockup — and it produces a predicted attention heatmap: a color overlay showing where a typical user is likely to look, and how that attention evolves over time. Nothing leaves your machine; the model runs entirely in your browser.

Try Foveacast View on GitHub

tl;dr

Drop a UI screenshot, get a predicted attention heatmap with fixation sequence, attention zones, and centroid trajectory.

Three viewing durations: first glance (1 s), quick scan (3 s), full viewing (7 s) — modeled separately, so you can see how attention evolves as users spend more time on the page.

Runs entirely in your browser. The model (~57 MB per duration) downloads and caches on first use; nothing is ever uploaded.

Built on MSI-Net fine-tuned on real UI eye-tracking data. Not a natural-scene model that doesn't know what a button is.

It's a probabilistic estimate, not a user study. The reading-your-results guide in the tool covers what it can and can't tell you.

The analysis report#

The output is a scrollable analysis report.

Warm colors show where a typical user's attention is predicted to concentrate. Cool tones indicate lower predicted attention density.

The heatmap overlay uses the inferno colormap: warm colors where attention is predicted to concentrate. Three viewing durations (first glance, quick scan, full viewing) are each backed by a separate model.

Below the heatmap: a rule-of-thirds grid with attention shares per region, a fixation sequence showing the predicted scan path as numbered dots, attention zones with contour rings at 10%, 25%, and 50% attention mass, and a centroid trajectory tracking where the attention center moves from first glance to sustained viewing.

In a design review, "the CTA doesn't appear until fixation 5, and 42% of initial attention lands on the hero image" is a different kind of conversation than "I think users will miss it." It's not proof. But it's a concrete starting point, and it gets you past the stage where everyone is arguing from intuition.

It's also useful as a self-check before publishing. Before you ship a redesigned landing page and find out three weeks later that the primary action was invisible.

Fixation sequence (left) and attention zones (right). The numbered dots show the predicted scan path order; contour rings mark where the densest fraction of attention falls.

Trained on real UI gaze data, not natural scenes#

Most open-source saliency models are trained on the SALICON dataset: natural photographs scraped from Flickr. Those models have learned to predict attention on photos of mountains and faces and street scenes. Put a web page in front of them and they produce a diffuse centrality blob. They don't know that "Start free trial" is the most important element on the screen; they see a rectangular region with text and mild contrast and model it accordingly.

Same page, two models. SALICON — trained on natural photographs — produces a diffuse central blob that poorly "understands" content. Foveacast, fine-tuned on real UI eye-tracking data, concentrates predicted attention on the headline, navigation, and key text elements.

The foveacast-training pipeline fine-tuned MSI-Net (Kroner et al. 2020) on UEyes (Jiang et al. 2023). Much credit is due there: Jiang et al. collected 1,980 UI screenshots with real eye-tracking data from 62 participants across desktop, mobile, web, and poster UIs, then published the full dataset on Zenodo under CC BY 4.0. Without that open release, Foveacast wouldn't have been viable to build. Fixations were recorded at 1, 3, and 7 seconds of viewing time, which is why there are three separate models rather than one. The gaze pattern at one second ("where do my eyes go first?") and at seven seconds ("where does sustained attention end up?") are genuinely different questions with different answers.

Fine-tuning on UI content closes the gap. On a held-out test split, the fine-tuned model improves by +43% on correlation coefficient and cuts KL divergence by 44% compared to the stock SALICON-only baseline. The stock model produces diffuse blobs. The fine-tuned model picks up navigation elements, content headings, and interactive controls, matching where real users actually looked.

Limitations: what predicted attention can't tell you#

Foveacast shows a non-dismissible note in the UI that says this is a probabilistic estimate based on population-average gaze patterns. A few things worth keeping in mind:

It's not measured data. The heatmap is model output, not fixations from real users looking at your specific design.
Training distribution. UEyes is primarily Western-language desktop and mobile UI, collected prior to the 2023 publication. Right-to-left layouts, dark-mode UIs, and design patterns that weren't common then may produce less reliable estimates.
Not a click predictor. High predicted attention on an element doesn't mean users will interact with it.

If you need real eye-tracking data — measured fixations from real participants — there are commercial services: Attention Insight, Alpha.one (formerly expoze.io), Clueify. They're paid, and they send your screenshots to a third party.

Foveacast is great to quickly, freely and securely close the gap: faster than a study, more specific than the F-pattern heuristic, and more honest than "I think."

How it runs entirely in your browser#

Like SVGOMG-Font and PDF-A-go-slim, everything processes locally. Design screenshots often contain unreleased client work or internal materials. Uploading them to a third-party service to get a heatmap is friction many organisations can't accept.

Running ONNX inference in the browser at this scale had some practical problems. WASM threading needs cross-origin isolation, which requires a service worker injecting the right headers. ORT Web's WASM paths have to be pinned when the app serves from a GitHub Pages subpath. The model weights are gitignored and fetched from a GitHub Release at deploy time rather than committed to the repo (57 MB each across three duration variants; they'd bloat every clone). The full engineering log is in LEARNINGS.md if you want the details.

Training on consumer hardware: a personal note#

This was my first proper model training exercise. I'd worked with embeddings before, but never fine-tuned a vision model. A few things made it more approachable than expected.

The training ran entirely on a MacBook Air M4 — no cloud GPU, no cluster. About three hours per model, so roughly nine hours of compute total across the three duration variants. Slow in absolute terms, but not the data-centre job I'd assumed fine-tuning required.

The other difference was AI-assisted development. What I'd expected to be a multi-week slog — working through PyTorch docs, debugging ONNX export paths, figuring out why the WASM runtime was choking on FP16 weights — turned into a genuinely enjoyable weekend project. Claude and Copilot handled a lot of the "read the error and suggest a fix" loop that normally drains the fun out of this kind of work.

I learned a lot and I'd do it again. If you want to fine-tune a saliency model on your own domain-specific data, the training pipeline is open and the README documents what worked and what didn't.

Try Foveacast on your own UI#

If you're working on a UI and want something more specific than the F-pattern heuristic and faster than an eye-tracking study, Foveacast is a reasonable starting point. If you use it in a real design review — or find a case where the model is clearly wrong — I'd genuinely like to hear about it.

Foveacast is on GitHub Pages. The source is on GitHub, with the training pipeline in a companion repository.

Related posts:

Stop converting SVG text to outlines — another browser-only utility from the same build season
Your browser utility wants to be a floating palette — the "do one thing, entirely in the browser" design philosophy
Semantic search on a static site, no API keys required — the same pattern of ML inference running locally in the browser

Stop converting SVG text to outlines

2026-04-29T00:00:00.000Z

Check out SVGOMG-Font

Every so often I need to put an SVG with text on a website: an infographic, a diagram, a data visualisation with labels. Each time, I end up staring at the same bad choice.

Option A: Convert the text to outlines. The SVG renders identically everywhere. No font loading, no layout surprises. Done. But now the text is a pile of path data. Screen readers see nothing. Search engines see nothing. Language models see nothing. Translation is impossible.

Option B: Leave the text as text. Clean, accessible, editable. But on any device that doesn't have the font installed, the browser falls back to whatever comes first in the system stack, and your carefully spaced infographic turns into a broken layout that looks like someone used Times New Roman on a web 1.0 site.

I've been choosing Option A for years and feeling bad about it. Despite plenty of searching, nothing combined what I actually wanted: a tool that runs in the browser, doesn't upload anywhere, and is open source. The closest matches were CLIs or a paid cloud service. So I built SVGOMG-Font. Drop the SVG in, get the same file back with the font subsetted to the characters in use and embedded as a base64 data URI.

tl;dr

Drop an SVG in, get back a self-contained one with the font embedded. Runs entirely in the browser, nothing uploaded.

Converting SVG text to outlines makes it invisible to assistive tech, search, translation, and LLMs.

Leaving text as-is fails on devices without the font installed.

SVGOMG-Font subsets to only the glyphs you actually use, so file sizes stay sensible.

Works cleanly for general-purpose infographics, diagrams, and posters. Rich text layouts that lean on OpenType features (ligatures, contextual alternates, complex scripts) need a closer look.

Here's an SVG set in Playwrite DE SAS, a connected German school-handwriting script almost no reader will have installed:

Before. No font embedded. Most readers see a Times-like serif fallback.

After. Font subsetted and embedded as base64; about 30 KB total.

The text is still real text: selectable, searchable, translatable. The font travels with the file, so it renders the same wherever the SVG lands.

You can sort of sidestep this if you control the host page: load the font via the page's CSS, and the inline SVG inherits it. But that's another asset to manage, another caching layer, and it only holds while the SVG stays on that page. Once the file has to travel (attached to an email, dropped into someone else's CMS, sent over Slack) the font reference goes dead. Bake the font into the SVG itself, the way a PDF embeds fonts, and it just works wherever the file ends up.

The problem with outlines#

When you tell Illustrator or Figma to "create outlines," it replaces every character with the equivalent vector paths. The rendering is locked in. But you've also just destroyed everything that made the text text:

Accessibility: screen readers can't read paths. The text is gone from the accessibility tree.
Search: both on-page (Cmd+F) and crawlers. An SVG infographic full of outlined text is invisible to search engines.
Translation: auto-translate and localisation tools operate on text nodes. No text nodes, no translation.
LLMs: if a language model needs to understand what your diagram says, it now has to do OCR or get the content from somewhere else.
Editability: editing outlined text means going back to the design tool, making the change, re-exporting, re-optimising, re-deploying. Minor corrections become multi-step processes.

There's a file-size argument too. A few hundred outlined characters easily adds tens of kilobytes of path data. Subsetting the font is usually smaller than outlining it.

Try SVGOMG-Font

How it works#

The structural change is small. Before, an @font-face rule points at a remote URL the viewer may never load:

<style>
  @font-face {
    font-family: 'Playwrite DE SAS';
    src: url('https://fonts.example/playwritedesas-regular.woff2');
  }
</style>
<text font-family="Playwrite DE SAS" x="20" y="40">Hello, world</text>

After, the same rule, with the font subsetted and inlined as a data URI:

<style>
  @font-face {
    font-family: 'Playwrite DE SAS';
    src: url('data:font/woff2;base64,d09GMgABAAAA…') format('woff2');
  }
</style>
<text font-family="Playwrite DE SAS" x="20" y="40">Hello, world</text>

That's the whole shape of it. SVGOMG-Font scans your file for @font-face references, fetches each font, subsets it to the glyphs in use, and rewrites the rule. No installation, no account, no upload: it all runs in the browser.

Why browser-only matters#

SVGs with fonts are often used in sensitive contexts: client work, unreleased materials, internal tools. Uploading to a third-party service to fix font rendering is a non-starter in a lot of organisations.

SVGOMG-Font processes everything locally. Nothing leaves your machine. It's a single static page. Foveacast, my browser-only attention-heatmap tool, runs the same way for the same reasons (write-up coming).

Prior art#

To be fair, this isn't entirely new territory. A handful of tools cover the same ground:

svg-embed-font, Go CLI: base64-embeds the full font.
svg-buddy, Java CLI: WOFF2 embedding given a local font file.
svgfontembed, Python CLI: embeds and subsets.
Vecta.io Nano: browser drag-and-drop SVG compressor that also handles font subsetting and embedding, hosted as a cloud service.

The CLIs share the install gap. Vecta.io Nano is the closest match in spirit (same drop-the-SVG-in workflow) but it's closed-source freemium SaaS, processes your file server-side, and has free-tier limits on file count and size. SVGOMG-Font fills the gap I kept hitting: same drop-in workflow, but open source, fully client-side, no upload, no signup. It also auto-resolves fonts from Google Fonts and Fontsource URLs, and on Chromium can pull from installed system fonts via the Local Font Access API.

The subsetting part#

The naive approach (embed the whole font) works but produces large files. A single Latin-subset woff2 file is roughly 20 to 30 KB, base64-encoded to about 40 KB. Two weights, and you've added 80 KB to your SVG before doing anything else.

SVGOMG-Font subsets to the characters in the SVG's text nodes, plus a Basic Latin safety baseline (U+0020 to U+007E). For a typical infographic with a few hundred unique characters, the subset is usually 5 to 15 KB encoded. Often smaller than outlining the same text.

There's a toggle to skip subsetting, useful when text gets added or replaced after export.

What it handles#

Fonts referenced via Google Fonts CSS URLs
Fonts referenced via Fontsource CDN paths
Cases where the font can't be found automatically: it prompts you to drag the font file onto the relevant row
Local system fonts on Chromium-based browsers via the Local Font Access API (permission-gated)
SVGO optimisation (optional, off by default; SVGO's inlineStyles pass removes @font-face rules if you're not careful)
Stripping legacy <font> / <glyph> blocks that some editors still emit

Where it gets bumpy#

For the bulk of SVG-with-text use cases (infographics, charts, diagrams, posters, headlines exported from Illustrator or Figma) the workflow just works. Where it gets shakier is anything leaning on OpenType machinery or rich text layout:

CORS-blocked fonts: a font hosted without permissive headers can't be fetched from the browser.
Variable fonts: subsetting variable fonts is finicky in general. If your SVG depends on a custom axis, test the output before shipping.
OpenType features: ligatures, contextual alternates, and stylistic sets sometimes reach for glyphs that don't appear in the visible text. The Basic Latin baseline catches most cases; obscure feature-driven glyphs may still drop.
Complex shaping scripts: Arabic, Devanagari, and similar scripts depend on positional and contextual glyphs. If your SVG uses one, eyeball the output rendering before trusting it.

Try it#

The split-screen slider in the tool itself. Drag the divider to scrub between the broken fallback and the embedded version, with file sizes and font count surfaced in each panel's header.

SVGOMG-Font is live on GitHub Pages. Drop your SVG in; if its font references resolve, you'll get a fixed file back in a few seconds.

The source is on GitHub. Bug reports welcome; font name matching in the wild has a long tail.

Related posts:

Your browser utility wants to be a floating palette (same "do one thing, entirely in the browser" design philosophy)
Introducing Pinment (another tool from the same season)
PDF-A-go-slim: a browser-based PDF optimizer (stripping and compressing PDFs, no upload required)
Foveacast: predicted-attention heatmaps in the browser (another client-side tool, same do-one-thing philosophy; blog post coming)

Designing analytics infrastructure that measures audience quality, not just traffic

2026-04-22T00:00:00.000Z

Clarity | Audience Quality | Strategic Alignment

Context The United Nations Office for Disaster Risk Reduction (UNDRR) is the UN's focal point for disaster risk reduction, coordinating global policy and supporting Member States to reduce disaster risk and losses.

Traditional web analytics answers "how many people visited?" For a UN organization producing policy guidance, technical resources, and knowledge products, that's the wrong question. The right question: did the people who need this content actually find it?

I led the design and implementation of analytics infrastructure across UNDRR's web ecosystem (15+ domains spanning Drupal sites, Java applications, and static microsites) to answer that. The challenge wasn't primarily technical. It was conceptual: what does success mean for content where impact happens outside your analytics?

What was the actual problem?#

No analytics benchmarks exist for organizations like UNDRR. The widely-cited "16% social traffic" figure comes from fundraising nonprofits running emotional campaigns. For a technical policy organization where audiences search for "Sendai Framework implementation guidance," that benchmark steers you wrong. I needed to figure out what actually applied, and write down what didn't.

The measurement model was broken in a different way. A 50% bounce rate on a terminology definition often means the user found their answer. The same rate on a landing page means something failed. Without classifying content by type, aggregate metrics obscure more than they reveal.

Then there's the volume problem. 10,000 visits from random browsers isn't worth more than 100 visits from government ministries using the content to shape national policy. Traditional analytics gives you geography and device types. It doesn't tell you whether the right people showed up.

Some of the most important impact never touches analytics at all. A researcher downloads a dataset and cites it in a paper six months later. A ministry official reads guidance and it shapes a national strategy. Neither event shows up as a conversion.

How did I approach this?#

I started with benchmarks — or rather, with finding out they didn't exist for our context. I synthesized data from M+R Benchmarks, RKD Group studies (2,000+ nonprofits), First Page Sage, and Similarweb, then worked out which findings actually applied. One thing that came up: only 8% of nonprofit websites pass Core Web Vitals on mobile. I documented confidence levels for each benchmark category and noted the gaps: no UN-system analytics data exists anywhere.

Content-type classification underpins everything else. I established metatag conventions (vf:page-type) that tag every page by type. The tracking script reads these on page load and sends them to GA4 as a custom dimension, so you can apply different success criteria to different content. Reference pages get different expectations than landing pages, which get different expectations than event pages.

For audience quality, I built an ASN lookup: a server-side endpoint converts IP addresses to network categories (government, academic, intergovernmental, NGO, commercial) and sends the category to GA4. Not the specific organization, just the type, which keeps it GDPR-friendly while still answering the real question: are the visitors we're getting the visitors we're trying to reach?

I also classified 200+ referrer domain patterns into 14 strategic buckets (UN System, Government, Academic, DRR Community, Traditional Media, AI Chatbots, and others), each carrying a weight reflecting how much that traffic matters to the mission. An "impact score" multiplies sessions by weight. 100 government visits (5×) ranks higher than 400 unclassified visits (0.5×). Raw session counts stop being the main signal.

Topic-level analysis came from taxonomy metatags (vf:page-terms) covering hazards, themes, SDGs, and Sendai Framework priorities. The backend aggregates by topic, so you can ask "which hazards drive the most search demand?" rather than "which pages were popular last month?" A lightweight "Was this page helpful?" widget sends clicks to GA4 with page container context; it's most useful for low-traffic content where engagement metrics are too thin to read.

The architecture follows a three-layer model. Content layer: Drupal, Java apps, and static microsites all emit the same metatag conventions. Tracking layer: one shared script, one GA4 property, per-domain data streams. Consumption layer: dashboard, browser extension, and Looker Studio, all reading the same source. Adding a new site means implementing metatags. The infrastructure doesn't change.

The single-property decision took some defending. Separate GA4 properties per site would have been simpler to manage, but would have fragmented the data. With one property and hostname filtering, the same query answers "how's PreventionWeb doing?" or "how's the whole ecosystem doing?" Cross-site user journeys become visible for the first time.

What can we now answer?#

58% of traffic comes from identifiable institutions: government, academic, UN system, research networks. That answers "are the right people finding policy guidance?" in a way raw page views can't.

Topic aggregation surfaces patterns that page-level data hides. Flood content dominates hazard interest; Early Warning leads on themes. That feeds content planning decisions, not just retrospective reporting.

A terminology page with 40% engagement isn't "underperforming" — it's what quick-reference content looks like. Content-type benchmarks mean the dashboard compares each page against the right expectations, not a generic industry average.

On direct feedback: terminology pages run 78% helpful, publications 65%. Pages that drop below threshold get flagged. Not a perfect signal, but a real one for content where traffic is too low for engagement rates to tell you much.

What did I learn?#

I built 18 dashboard screens before asking which ones stakeholders would actually use. I should have done the user research first. That sequence mistake cost real time.

We also set targets before documenting baselines. Now we're establishing them retroactively. The order should have been: observe, then set expectations.

Some impact just isn't measurable through analytics. Download clicks don't tell you whether anyone read the PDF. Policy influence doesn't generate a GA4 event. I documented these gaps explicitly; better to set that expectation early than have people treat the dashboard as a universal answer.

I underestimated the research. Deciding which benchmarks apply, which don't, and writing down the reasoning became as useful as the tracking implementation itself. Without it, you're measuring against whatever number was easiest to find. That number is usually wrong for your context.

Links and resources#

Measuring success beyond the page view: the philosophy behind this approach
How to measure impact when analytics lie: implementing benchmarks, audience detection, and content-type classification for your own stack
UNDRR analytics overlay and MCP bridge, the next chapter: putting this data where the work happens, and making it queryable by AI agents

Let AI worry about the code, you worry about the work

2026-04-20T00:00:00.000Z

Early in 2026 I was in a hotel room during a team retreat, trying to work through a problem with all the context from our planning conversations still circling in my head. I had been using ChatGPT for coding help, then Cursor with the AI in the IDE sidebar; both useful, both essentially "AI helps me code." I was the one writing; the model filled in the gaps. What I realized in that hotel room was that holding the context in my head and passing it to the machine one chat turn at a time was not enough. I needed to put it somewhere the agent could read directly.

So I stopped asking an AI to help me code and started managing a project. I opened a fresh git repository, dropped in a short PRD of what I wanted, technical documents on the architecture of the data it would consume, and a folder of the business context behind it. I pointed Claude Code at the repo, described a bit how to begin, and let it stand up a local server. From there I worked through it the way you work through any project: branch, change, diff, commit, revise. My attention moved from the line and the function up to the project. The implementation work, which had been mine, became the agent's.

What changed was not the language model; it was the level of abstraction I was operating at.

tl;dr

The productive pattern: a coding agent working on a real project, primed with your business context via skill files, local MCP servers, and data on disk.

The literacy that matters: reading diffs, driving git, editing configs, judging what the agent produced, not writing code from scratch.

The dividing line: "do you work on a real project with a coding agent?" Chat windows and app-builders do not clear the bar yet.

Another thing I started doing in that session: dictating instructions instead of typing them. Speaking is looser and more narrative; when I type, I try to be concise, and concision turns out to be the wrong register for this. LLMs read people well: a messy paragraph of what you actually mean beats a tight sentence that asks the model to infer the rest.

That change in productivity is not from writing more code, and it is not from prompting a chatbot. It is the fusion of the two: a coding agent acting on a real project, with me operating one level of abstraction up from the code itself. A chat thread rewards turn-by-turn completion and quietly fights "step back and tell me what we are actually trying to build"; a project folder does not.

If you have comfort with the vernacular of code (reading a diff, trusting a commit, knowing what a repo looks like, noticing which file an MCP server is reaching into and why), the leverage is real and it compounds quickly. You do not need to write the code yourself; the agent is writing most of it now. If you do not have that comfort, most of the efficiency gains happening right now will pass you by, because they live where code lives: in a project folder, behind a git remote, wired to a handful of MCP servers you need to trust.

What this looks like in practice#

At UNDRR, our Google Analytics is, like many places, not generic. Twenty-two hostnames funnel into a property, download events are derived from URL patterns rather than clicks, engagement is tagged by page region, and referrers are bucketed by strategic category. I asked Copilot CLI to encode that business context in a local MCP server, so that a coding agent could reach GA4 already knowing what our data means. (The full write-up is in the UNDRR analytics overlay and MCP bridge piece.)

I also keep a local copy of our Drupal content database running on the same virtual machine. When the analytics are ambiguous about what a given URL is, the agent can cross-reference the content itself (taxonomy, body text, publication date) and resolve the question without asking me.

With that setup I can ask:

Tell me about the last ten news items we published on tropical cyclones and how they performed compared to a year ago.

In months past that investigation was an incredibly tedious cross-tool query: pull a filtered content list from Drupal, map each URL to its analytics row, compute year-on-year deltas by custom event, assemble the results into a table. The agent does all of it in one pass, because each of the pieces is reachable and each is already annotated with the context the agent needs to use them.

There is no off-the-shelf commercial tool that answers that question, and there probably never will be. The thing that makes the query answerable is the specific marriage of our content structure, our analytics configuration, and a coding agent fluent in both. The off-the-shelf option would only ever be one of the three. This is what priming an agent with business context looks like when it actually pays off.

Comfort with code, not fluency in it#

The people who benefit most from this moment are those comfortable around code, not necessarily those who write a lot of it. The agent is writing most of the JavaScript or Python now. What you need is enough fluency to read what it produced, point it at the right place, trust or push back on a proposed change, and know what is happening on your own machine. In practice that looks like: comfort with a filesystem and a project structure, comfort with git (commits, branches, diffs, PRs), comfort with a terminal, comfort editing a config file, comfort registering an MCP server. You may never stand one up from scratch yourself; you can ask the agent to, read what it did, and decide whether to keep it.

The floor used to be "can you create this code?" and is now closer to "can you direct what the agent writes?" That is a lower bar than before, and still not zero. The people on the wrong side of it will miss most of the leverage in this cycle, not because they cannot code, but because they will not open the terminal.

How to get there#

If you are already comfortable with code, build one project-attached workflow for something you do every week. Often that is just a folder with the right context files (a PRD, a few technical docs, a sample of your data) and a coding agent pointed at it with access to the tools you already use. A skill file or a tiny MCP server can help, but they are one path, not the only one. The first version will underperform the manual process; the second will surprise you.

If you are not comfortable with these tools yet, the investment is not "learn to code"; it is vocabulary. GitHub's introductory docs walk through commits, branches, and pull requests in plain language; GitHub Skills turns the same material into guided exercises. A week of either gives you enough to read what an agent is doing on your behalf.

From there, install a coding agent (Claude Code, Cursor, or GitHub Copilot CLI), point it at a real repo of yours or one you forked, and let it work. Watch the diffs. Register one MCP server. Edit one config file. You do not need to produce code yourself for any of this to pay off; you need to be a credible reader, director, and reviewer of what the agent produces.

If you are already running coding agents against real projects (with or without custom skills or MCP servers), I would like to hear what you have automated and what surprised you. Drop me a note; I am collecting examples for a follow-up.

Putting GA4 where the work happens: an in-browser analytics overlay and its MCP bridge

2026-04-20T00:00:00.000Z

Context | Self-service | Agent-queryable

Web analytics are most useful alongside the context of the pages you are reasoning about. Using AI agents to help also suffers as humans usually manually hand off data.

To help myself and the team, I built a Chromium extension that puts GA4 metrics on UNDRR pages as an overlay, and extended it with a local MCP server so humans can have agents query the same data through the Chromium extension's same authenticated session.

The overlay and the MCP bridge are the same tool wearing two faces: same auth, same config file, same measurement model. That is why neither had to be rebuilt to serve the other. This is the story of both pieces and why they belong together.

These are the three web pages I am responsible for. Can you tell me what links people are not clicking on?

Those sorts of questions used to take an age to answer, but now we have quicker, better and more understandable answers.

What was the actual problem?#

Context switching to Looker Studio is where curiosity dies. For editors wondering whether the policy page they just updated is getting traction, a five-step dashboard drill is slow enough that most of the time they skip it. The question gets answered only when the quarterly report lands, which is the wrong feedback loop for editorial decisions. We spent more time training editors on the tool than understanding the data.

UNDRR's analytics model is not generic. Twenty-two hostnames feed one GA4 property, downloads derive from URL patterns containing /media/, engagement is tagged by page region (main, header, footer, feedback widget), and referrers are classified into eighteen strategic buckets before query time. Off-the-shelf analytics tools either ignore that model or flatten it.

How did I approach this?#

Overlay first, where the work happens. The extension is a Manifest V3 Chromium extension. It authenticates through the Chrome Identity API, so there are no extra credentials. On any UNDRR page it can surface views, sessions, engagement rate, average duration, and a year-over-year comparison with an interactive daily chart. Tracked links and downloads get color-coded badges on the page itself; regions get rollups so editors can see which part of a page is actually doing the work.

Bridge second, on an auth boundary that already existed. The MCP server runs on a localhost port and talks to an offscreen document inside the extension over a persistent WebSocket. That offscreen document owns the OAuth session, so the MCP server never sees or stores a token. From the agent's side, fourteen tools are exposed: tactical ones (query_top_content, query_downloads, query_traffic_sources, query_geographic_reach, query_region_events), strategic composites (domain_overview, annual_report_extract), and a raw GA4 escape hatch (run_raw_ga4_query) for questions the composites do not anticipate.

One source of truth, shared three ways. domains.json holds the twenty-two hostnames, their measurement IDs, and the referrer bucket classifiers. The extension's content script, its popup, and the MCP server all read the same file, so there is no config drift between what editors see in the overlay and what an agent sees through MCP.

What were the outcomes?#

Context at the point of editing. Editors can now see how a page is performing while they are editing it. The question "is this working?" has a three-second answer instead of a five-step Looker Studio drill; editorial decisions close the loop on the same day rather than the next quarter.

Agent-speed analysis. "Extract the annual report for 2025" is a single agent turn instead of roughly a forty-click dashboard walk. Parallel GA4 query batching inside annual_report_extract roughly halves the wall-clock time on multi-section reports, which matters when a report spans a dozen sections.

One credential, not two. The agent reuses the overlay's OAuth session, so nobody is maintaining a second service account or rotating a separate key. For a small team inside a UN organisation, that is the difference between a tool that gets adopted and one that quietly stops being used.

Why did this work?#

A tailored solution made sense because the measurement model is non-generic. A general-purpose analytics MCP would expose GA4 as GA4. What editors and analysts actually need is GA4 shaped like UNDRR's referrer buckets, regions, and content types. Keeping the domain logic in domains.json rather than in prompts means every agent gets the same context for free.

The MCP was not a rewrite. It was a thin wrapper on an auth boundary that already existed. The extension already had an OAuth session, an offscreen document, and a query layer; MCP just made them addressable from outside the browser. Most of the hard decisions were security decisions: single-property lock, sender validation, passive failure modes.

The one thing that nearly broke it. A single bad Zod schema (valid in v3, rejected in v4) made tools/list throw at registration, and that error is global: all fourteen tools disappeared from the agent at once. A stdio smoke test calling tools/list as the first build step now catches this class of failure; without it, the MCP server would have shipped advertising capabilities it could not deliver.

What's next, and why this matters beyond UNDRR#

Self-service analytics inside the page is a familiar idea. Agent-queryable analytics that reuses an existing auth session is newer. This extension is one instance of the pattern I described in Let AI worry about the code, you worry about the work: a coding agent on a real project, primed with your business context. The MCP server is the specific shape that worked here; the shape that works for you might be simpler.