Vibelog on Leon Mika

Vibelog: Well Read - A Fable Moment

Wed, 15 Jul 2026 22:30:02 +1000

Today, I had what I could probably describe as a true “Fable” moment. I was asking Claude Code to make some changes to Well Read (yes, I’m still using it) when I considered throwing it a problem that Opus was unable to solve. This Flutter app renders a post within an embedded WebView, and since day one, this WebView had some pretty janky scrolling. For small pages it was fine, but as it grew, or when more images were present, the refresh rate will drop like a stone.

I had Opus take a look at this a while ago. It suggested a few minor things like adjusting the styling, but none of these seemed to helped. I have had Fable look at tasks that Opus did poorly in the past, I have heard others say that Fable was capable of solving problems that prior models had trouble with. It seemed to work for them, and since I had Fable open doing other things, I wondered if it could work for me. And besides, this scrolling jank was really bugging me. If Fable couldn’t solve it, ah well, I’m left with what I have. But if it could…

So here was my prompt to Fable:

I’m experiencing issues when browsing pages within the web-viewer. Scrolling is particularly choppy when there are images or when the article is too long. It would be nice if the scrolling was smoother. Is there some way in which this could be improved?

Short and sweet. Here was its response:

Fable’s diagnosis of the issue

Good question — and I can point at some likely culprits in the reader’s code itself. This is an assessment; nothing’s changed yet. The honest caveat up front: scroll jank can only truly be diagnosed on the device (I can’t reproduce it in this VM), so these are ranked by likelihood based on reading post_reader_screen.dart, not by measurement.

The content-visibility CSS in the injected HTML is doing nothing useful and possibly harm. The article body is wrapped in a single <div class=“content”> styled with content-visibility: auto; contain-intrinsic-size: 0 2000px; (post_reader_screen.dart:179-182). That CSS feature only helps when applied to many small sections so the engine can skip rendering the off-screen ones — on one wrapper div it renders everything the moment any part is visible, and the 2000px size guess can cause layout jumps and scrollbar weirdness on long articles. Removing it (or applying it to the article’s child elements instead) is a two-line change.

Images have no lazy loading, so every image in the article loads and decodes eagerly. Feed HTML arrives without loading=“lazy” or decoding=“async” attributes, and JavaScript is disabled in the WebView so nothing adds them. Decoding several large images while you scroll is a classic source of exactly the choppiness you describe. Since the app already assembles the HTML string, it could rewrite <img tags to add those attributes before loading — both work in the Android WebView engine even with JS disabled. Images also arrive without dimensions, so the page reflows as each one loads; that’s harder to fix fully, but lazy loading confines it to the part you’re actually reading.

The platform-view rendering mode. The WebView renders through Flutter’s platform-view compositing, and Android has two modes with very different scroll-performance profiles (texture-layer vs. hybrid composition). The app currently uses the default. Toggling displayWithHybridComposition in the WebViewWidget creation params is a small experiment that sometimes transforms scroll smoothness on particular devices — worth trying if 1 and 2 aren’t enough.

The bigger option: drop the WebView for native rendering with something like flutter_widget_from_html. Scrolling becomes a native Flutter list — generally the smoothest outcome and it would also fix the WebView’s other quirks — but it’s a real feature change with its own rendering trade-offs (complex embeds, tables, code blocks may render differently), so I’d only go there if the cheap fixes disappoint.

My recommendation: try 1 + 2 first — they’re small, low-risk, and directly target “choppy with images” and “choppy when long”. Then evaluate on your device, and escalate to 3 or 4 only if needed. Want me to design and implement those first two?

Option 2 and 4 were no-gos, and option 1 is essentially undoing an attempted fix by Opus, which was amusing. But what looked interesting was option 3, which Opus never brought up. I ended up going with that and option 1, and it seemed to have done the job. Scrolling is… well, I wouldn’t say it’s buttery smooth, but it’s significantly improved. I’ve been trying it for a few hours and I’m no longer experiencing any jank.

So the stories of Fable being a more capable model are definitely true.

As for the rest of the tool, it’s coming along. I’ve asked Claude to clean up the handling of “Mark as Read” in the feed viewer. Prior to today, opening an item would start a 1 second timer before marking the item as read. Moving away prior to the timer timing-out would cancel this. This was functionality I requested, as it was a way of allowing me to quickly “peak” at an item without changing its read status. But this delay turned out to be more trouble than it’s worth though. If you time your actions right, you can actually hit the “Mark as Read” button at the same time the app tries to change the read status itself. This induces a conflict of some sort, and the screen goes blank, requiring a restart of the app. Now, items are marked to be read immediately.

But the biggest change was adding a way to make a Micro.blog post about the item from within the app. This was lifted wholesale from Inkwell, and supports features like pre-populating the link with the page title, and including any selected text in the quote as a block quote. It’s also possible to set a prefix that’ll appear just before the link (I usually use the link emoji for this) and a post category. And despite some funky selection behaviour in the web-view, it works well enough.

From left to right: the "New Post" menu item, the post authoring screen, and the settings screen.

Oh, and I would say it’s still pretty amazing being able to vibe-code most of this directly from my phone. The agent does the work, then pushes it to Forejo as a PR, which kicks off a build of an APK, which I can download and install directly onto my phone. I’m not looking forward to Google’s locking down this form of side-loading in any capacity.

Vibelog: Weatherpatch - UI Improvement

Sat, 04 Jul 2026 16:13:28 +1000

A few weeks ago, I vibe-coded a web-app called Weatherpatch. This is an app that is designed to receive email newsletters and produce them as an RSS feeds: basically what Feedbin does, but without needing to use Feedbin. The app was vibe-coded with Opus, and while functional, it is hardly an example of good design (unless you’re a fan of Cubism). To wit:

Yeah, Opus just threw the feed management controls all over the place. And I tolerated it for a time. I was more interested in having something functional, rather than pretty. But the thing about a bad UI is that it makes using the app feel bad. Sure I’m not in there managing feeds, but I would like to go in there are copy-paste the email address when setting a new one up.

Seeing that Fable is available again (thanks, US government, I guess?) and that I haven’t given it a proper shakedown test last time, I figured it was worth throwing it at the problem, and seeing if it could fix the design Opus threw together. I also wanted to try out the frontend-design plugin. Here’s the initial prompt:

The UI design of this webapp is quite primitive. While functional it doesn’t make it pleasant to use. Can you propose an improved design? Don’t change the underlying technology: just the UI and styling.

It took a while, but came up with the following diagnosis:

Fable’s diagnosis of the issue

What makes the current UI feel primitive

Looking at the templates, three things stand out:

It’s stock Pico. Default palette, default type — it looks like every Pico demo, with no identity of its own.
Every feed card shows its full management UI all the time. Each card carries a rename input, rename button, delete button, merge dropdown, and merge button — with ten feeds that’s fifty always-visible controls for actions you perform maybe once a month. The thing you actually want from a feed (its URL) is buried among them.
Raw 60-character URLs dominate every card. The random slugs are unguessable by design, which means they’re also unreadable — printing them in full conveys nothing.

Proposed direction: “Synoptic chart”

The name weatherpatch is a gift — the app is essentially a weather station for newsletters, with feeds as stations reporting in. The direction leans into meteorological chart vernacular, kept quiet and instrument-like, since this is a tool you visit briefly, not a marketing page.

Palette — cool “chart paper” background (#F4F7F6), slate ink (#22303A), isobar blue for links (#33636F), and one accent: RSS orange (#D95B10). The orange is subject-grounded — the whole point of the app is producing RSS — and it’s used sparingly: the logo dot, the copy button, focus rings, the RSS chip.
Type — IBM Plex Sans for UI, IBM Plex Mono for everything machine-ish: the inbound address, URLs, section labels. Monospace is load-bearing here, not decorative — the app’s most characteristic artifacts are random strings. (In production I’d embed the woff2 files in static/ alongside the CSS so the single-binary, no-CDN property holds; system-font fallbacks if you’d rather add zero bytes.)
Signature element — the inbound address as a station call-sign: a hero panel at the top of the dashboard with the address in large mono type, one prominent “Copy address” button, and a faint set of isobar contour lines etched behind it (inline SVG, centre labelled “1013”). One place of boldness; everything else stays disciplined.

The UX changes (bigger win than the styling)

Progressive disclosure. Rename/merge/delete move behind a native <details> “Manage” disclosure per card — no JavaScript needed, and each card collapses to one line: title + two chips.
URLs become copy chips. RSS and JSON chips copy the URL on click (your existing data-copy handler works unchanged — the chips just carry the attribute). The full URLs remain visible as plain links inside the Manage panel for the times you want to open or inspect them. Copying is the primary use of a feed URL, so it gets the primary affordance.
A real empty state and a properly styled login card with a styled error alert (currently an inline style=“color:#b00020”).
Microcopy tightened throughout: “Give this address to every newsletter you subscribe to. New senders show up below as feeds.”

What stays and what changes

Everything server-side stays as-is: Go templates, Fiber, embedded assets, POST-redirect-GET forms, app.js patterns. The change is replacing pico.min.css (~80 KB) with a hand-rolled weatherpatch.css (~8 KB) — same delivery mechanism, and at three pages the custom stylesheet is small enough to own outright. Template edits are modest (the <details> structure, chips, hero panel).

Two optional extras that would touch Go code lightly (no technology change, just flagging since you said UI-only): per-feed item count and last-received date — the data is already in SQLite and would make the dashboard feel like stations actually reporting — and a favicon route using the RSS-arcs logo mark.

It also produced a mockup in a static HTML file, which was quite an improvement over what was there. I then went back and forth with it a couple of times, asking it to move command arguments to modals, and have it produce a mock with more than a handful of items:

Okay, that’s a good start. I do wonder if it’d be worth merging the actions onto a single line. Maybe have “Rename, Merge” on the left and “Delete” on the right. The Rename and Merge buttons will display modal dialogs prompting for the input: a text field rename, and a select list (not a drop-down) for the merge. Delete will be on the right, and show a confirmation dialog as a modal. Use HTML dialog elements for this. Add any JavaScript you need, but keep it vanilla JavaScript.

[…]

Can you demonstrate how this would look with 30 feeds? I just want to make sure the Merge feed can handle that many feed items in the modal. I’m think we need to make sure the list doesn’t grow too large.

I include in this gallery various screenshots in how the mocks evolved during this time.

First version of the mock which, while prettier, was quite similar to the old UI in that the controls were just present on each card.

The mock after I asked Claude to place input items in modals.

The rename modal.

The merge feed modal.

The delete confirmation modal, which previously used the browser's 'confirm' function.

A modified merge feed modal after I asked Claude to consider a large number of feeds.

After about half an hour of this, it was good enough to get Claude to implement it. I deployed the changes, and now the UI looks pretty decent.

So all in all, I’m impressed. I would like to know how much of this was down to Fable, and how much of it was the frontend-design plugin. I don’t expect to be using Fable often, given how expensive it is. But for a large job like this, it did a good job.

Vibelog: Show As Table - A DSL In a Hurry

Sun, 28 Jun 2026 11:36:12 +1000

I was asked to make a couple of diagrams for the purpose of showcasing a database design. These diagrams were mainly used to show the relationship between entities, so I chose to use TLDraw for this. But there was a need to add some example rows, which TLDraw does not make easy. Furthermore, there was a bit of a push to get this done quickly, as these were to be shown to various stakeholders the next day.

Given all this, I thought it was worth asking Claude to make a tool to generate a table as an image from a DSL.

The initial prompt

Please generate for me a Go application which takes a DSL of the following form:

```
Title

Name Value
“Name2” “Value2”
```

It is to render this as a “card” with Title appearing above a box which contains two columns: the left containing the name and the right containing the value. The columns are to be presented as two columns of a table that will rendered as this: [Image #1]

The result should be a PNG that I can include in another diagram.

In short, I was to provide the data in the form of a table, and the tool Claude wrote is to generate it as an image, that I could import into TLDraw. Here’s an example:

Key Value
First John
Last Smith
Address "123 Fake St."
City Melbourne

This was my first attempt at using the image upload for Claude Code, with the intent of producing something that that mimics it. I don’t have it handy with me but the image was of a table rendered in a GUI of a database client of some sort (I didn’t pick the table, someone else took a screenshot and said “make it look like this”). And Claude managed to get it looking pretty close. It originally chose to use the builtin Golang fonts, but switched Jetbrains Mono for the headers and Inter for the table cells, after I asked it to use a more “professional” font.

From there, the DSL evolved as the needs of the task arise, without any grand vision of it’s design. The diagram title was dropped, comments in the form of lines beginning with hash were added, and a row could be highlighted by prefixing it with a *. How Claude did this was up to it. It was given pretty-much free reign in many of details, including how to highlight a row (it chose to do so using a yellow background):

Key Value
First John
# Middle None
Last Smith
Address "123 Fake St."
City Melbourne
* Registered Yes

The DSL eventually extended to include tables with multiple columns.

Prompt to add multiple columns and highlights

Please also add support for multiple columns, i.e. more than 2. And any row that begins with a * should be highlighted, e.g *name value (do not include the leading star)

Key          "Person 1"      "Person 2"
First        John            Mary
Last         Smith           Smith
Address      "123 Fake St."  "456 Fake Rd."
City         Melbourne       Sydney
* Registered Yes             No

And multiple tables stacked vertically, with matching cell widths.

Prompt to stack multiple tables

Okay. I would also like you to support dividers between subsequent tables. When I have a line of the form “—”, it will indicate that I want two tables, positioned vertically, with a transparent gap between the two of about 1.5 times [since updated to be 1/2 that] the row height. The column sizes of both tables should be the same, in that they should be wide enough to fit whatever the widest cell of both tables.

Key          "Person 1"
First        John
Last         Smith
Address      "123 Fake St."
City         Melbourne
* Registered Yes
---
Key          "Person 2"
First        Mary
Last         Smith
Address      "456 North Fake Road, South"
City         Sydney
Registered   No

Finally, a dark-mode was added. The colours were taken from a fork of this where someone added a dark mode directly. I wanted the ability to invoke dark mode via a switch, and simply adopting the fork meant I would loose the multi-table features I asked Claude to add. So I copied their version of the source, and asked Claude to crib the colours from it:

Prompt to add dark mode

Okay. Someone has forked a version of this tool and implemented a dark version. They have shared with me the code located in @dark-version/main.go. Can you please adopt the colour scheme of this tool, and apply it when the flag “-dark” is present.

Key          "Person 1"
First        John
Last         Smith
Address      "123 Fake St."
City         Melbourne
* Registered Yes
"Dark Mode"  Yes

The results were decent, although you can guess that I didn’t actually run this tool in dark mode with a highlighted row.

So, why do I write about this? Not that I need a reason, but I always find these badly designed, hacked together DSLs fascinating. You can learn a lot about using something that’s truly terrible. Using this particular DSL for the task at hand is fine, but I can’t really see myself using it for anything else. Having the table cells defined as white-spaced table columns is not the easiest thing to maintain, let alone something easy to review when checked into Git. Yet it is obvious, and maybe with some better tooling it could be made to work better.

Vibelog: Blogging Tools - Some Post Authoring Work

Thu, 25 Jun 2026 08:12:14 +1000

I asked Claude to do some work on Blogging Tools.

I wanted a way to schedule the publication of a post. Well, in a manner of speaking. The scheduled post retains it’s original publication date. It just won’t get published until a certain time in the future, nor would it be cross-posted to anything. It’s sort of my attempt at allowing me to write about a topic without anyone else finding out about it. Yes, I know this sort of defeats the purpose of a blog, and that any bit of writing published here is theoretically world readable anyway. But there’s a sense of immediacy about certain topics that, with a bit of temporal distance between when it’s published and when it actually appears, does make it easier to write about. And as posts age, their reason for being changes. They become less about the “joining the conversation” and more a statement of record sitting in the archives. And in my experience, unless the piece gains some traction, very few readers venture into the archives. Or at least, few human readers do; the AI agents are all over there at the moment (hi, bots 👋).

Anyway, this was a perfect enough small thing for Claude to work on unsupervised. I have enough confidence that Claude will find it’s way around the code base. I have a very basic CLAUDE.md file which it tends to honour. So it had no immediate issues making the changes. But when I pushed it to the server, my immediate thought was that Claude can’t do UI design. I asked for a menu, and this is what it gave me:

That’s an unstyled disclosure HTML element acting as a menu, with the items being links within an unordered list. It turns out that it was a caching issue, as a day later, when I revisited the page, I got this:

Which is an improvement but not a whole lot better. So I went in and adjusted the CSS to make it look more like a link. It now looks like this:

Another request I had was to import a Micro.blog draft into Blogging Tools so I can use this new scheduling feature. This essentially calls Micro.blog’s MicroPub API to fetch the first 10 draft posts, and display them in a list. A pretty elemental feature, but I do have unfounded fears of missing something when I copy and paste things around.

Claude did a better job on the UI design here. I guess it had the existing post list to crib off of. Although each item does have this weird text area. It turns out Claude decided to surround each draft post in a form element which will submit it when the user clicks “Import”. The text area is essentially the draft post sent to the server. It’s a pretty old school way of doing it, but it works. They were simply showing up because Claude forgot to add the class="hidden" attribute, simply adding hidden as the attribute itself. This was another thing I fixed by hand.

So, a simple enough change. Now time for the more recent test. For you see, this post is a good example of the sort of posts I hope to use this scheduling tool for. I will publish it now, and hope to see it appear in four days time. That means it won’t actually be visible until the 29th. But it doesn’t take long for that time to fly by.