Build notes

I was waiting on an AI web chat and wondered: How often is this happening? What is this time?

So I thought about building a timer. But where could I know when the AI was thinking, and how could I act on that information? And, If I could do that, I could probably manage a payload, right? But what kind of payload would be practical? What would I do with them? With the time?

Among other things, I worked in television advertising. I know the power of fifteen seconds and of the commercial break. I spent the better part of a decade hoping to shepherd it into the future. This felt interesting, adjacent, and created an itch I wanted to scratch.

I started with the detector apparatus because it was the hinge. To start to answer that question, I focused on the environments I was building into. Doing it at the operating-system level felt too slow: picking camps, install friction, and too many unknowns. I haven't touched an OS-level API since 1997. RIP AOL warez/hacking community.

With the OS path closed, the web was the way forward. That meant choosing which AI providers to support—an easy decision to focus on ChatGPT, Claude, and Gemini. I opened each site and watched for the signals kicked off by a submission. This is where we fall in love with button state.

The button gave me a strong thinking-state signal simply through what it was saying about itself. After twenty minutes of tuning the detector, it was strong enough to move on.

Now, the time for payloads was upon us. Did I want video in here? Images? Something interactive? How interactive? Are we jamming three.js in here? New Flappy Bird? This was the harder part: the what of it all.

I built video with playhead sync across intermission breaks. I built a photo slideshow. I made an interactive quiz show. I ripped off Wordle. All of it did the job of filling the time, but all of it felt too distracting. As bad as a pause ad. And I hate pause ads.

After the sixth payload spike, I realized a payload isn't a product. I'd need to be more honest about this moment and not just build a mechanism.

I used to have a product at Viacom: an interactive trailer extender. We would put a ninety-second trailer into a fifteen-second ad slot with a “click to continue” for the interested viewer to get the payoff and for the trailer to shine. (This mostly turned a ninety-second trailer into a fifteen-second trailer for 99.8% of people. But that 0.2%...)

I thought of this because I was bumping into that territory. And, be2ween would not be a click-to-continue vehicle. It was an elevator wait screen.

This is where the honesty came into focus. This moment is between the real thing. It can't truly be a thing of its own. It's a sidekick that can't ask more of you than the time it has. Force a cross-intermission interactive experience and now the AI wait time and the programming are intermissions for each other. That isn't a pattern I was interested in, it wasn't honest.

What was honest is that you were between two floors, a bit of a hostage. So what did I really want? I wanted it light weight and requiring the least of its user. Just enough to catch darting eyes or a drifting mind.

No big graphic library deps. No big content delivery schemes. Pure browser stuff (html, js, css). Words on cards. Moving shapes.

I backed into the content size and pace from the time slot. My general testing (me pretending to be several other people as I clicked around the web) suggested that we had to worry about fifteen to thirty seconds. The average person reads around 250 words a minute—do I hear a user preference coming?—which gave me a rough estimate of what we could reasonably communicate in the available time.

After writing too much bad comedy—Brought to you by nothing. Ask for it by name.—I realized the opportunity was in wait-sized (my term) edutainment. Small enough to get out of the way, but big enough to stick to an inquisitive mind.

This opened up a box of worms around scheduling and editorial. To start, I needed a programming desk: a place to organize and group content into feeds for exposure and display. It would publish the feed consumed by the extension. It would need to ingest information and package it for display, control grouping and exposure, allow for editing, and handle the CRUD of it all.

I started on this before I had the content set. The apparatus would take longer to get right and shouldn't block on my figuring out the programming.

Knowing the final set would contain hundreds of disparate units with different formats and flavors, I wanted a UI that could handle some volume. That meant multi-select and pagination; search, sort, and tags; real productive surfaces I could use as part of the content-generation approach I was pulling together.

My content came from Wikipedia, agentic research with antagonistic fact checks, and a painful appreciation for how difficult it is to be a writer or content creator.

After the first packs, it was clear that content would be the biggest hurdle to repeatable value. I would also be the one pulling it together, so my taste would come through. I built channels around subjects where I thought I could apply some useful discrimination:

1. Expanding vocabulary: thesaurus, language learning, and etymology.
2. Software and development: jargon explainers and wait-sized domain knowledge.
3. General knowledge: misconceptions, headlines, and Reddit posts.
4. Semi-motivational, mildly entertaining humor.

The first season took the better part of a week and a half, with another season in the hopper. Along the way, I opened channel creation and content packs to outside submissions. They show up in be2ween master control and can be folded into the broader set of channels. Moderated by me.

The surprise came when I thought the product was done: detectors working, payload secure and delivering, display side parsing and displaying, control surfaces and systems working. The content flowing like water.

But my first beta users were confused or put off by the lack of ceremony and the pace of the exposure.

“It's so fast.”
“I forgot I installed this.”
“What am I looking at?”

In all my haste to build the kitchen, I had forgotten we were running a restaurant.

The product appeared inside a behavior people were already performing, occupied a few seconds, and disappeared. That was the point. But without some ceremony, the restraint just read as confusion.

That is where the four-step onboarding came from: first to answer what am I looking at? and how does it work?—then what choices do I have?

First was realizing that card-exposure speed wasn't a universal fit. The variability I had allowed at the card and content level wasn't enough to create comfort for every person or the pace at which they read and understand.

The system was already built, and jamming in another timing control was sure to be a reverse-Jenga effort I couldn't afford. I was delighted to find I already had the pieces I needed. I gave the scheduler a personal multiplier against the fixed exposure tiers, controlled by the user at the extension level where the schedule actually runs. Now choose your pace could be part of onboarding.

There are more bells and whistles throughout, particularly around making the moment actionable at the time of exposure: the remote, the sidebar, the channel view, even simple wait. Together they brought the product into focus as a useful encapsulation—and exploration—of something with this shape.

The apparatus works. It catches the wait, runs the schedule, gets out of the way, and gives the tab back when the real thing returns.

What determines whether be2ween lasts is the programming.

I can add more supported models, more controls, more ceremony, more surfaces. But none of that matters if what airs isn't worth the interruption. So the next work is mostly editorial: finishing the first language channel, keeping the house channels tight, and seeing whether other people want to make channels of their own.

The product is live. Now I get to find out whether the wait is actually a medium—or just another place I managed to hide some cheese.