Verification, not trust: a notice board built in a day, and measured before it shipped

On the evening of 17 September 2026 my notice board looked finished. The cards rose in their columns, the ticker scrolled, and every announcement carried a neat QR code with the Ta’az emblem in its middle. Then I pointed a phone at one of the codes, and nothing happened.

The codes were beautiful and useless, and they had passed my own check. I had measured the editor and the scrolling earlier that day, so the rule was already there: nothing counts as working until I have measured it. That moment added its second half: the judge has to be independent.

The problem

TaazTV is a digital news and notice board for screens around Merkaz Ta’az. One 16:9 screen brings together the unit’s name, the clock with the Hebrew and Gregorian dates, a menu, today’s schedule, emergency and in-house phone numbers, a news ticker and a moving board of announcement cards. Staff run it from a Hebrew control panel in the browser.

Three things made it harder than it sounds:

• The network is closed. No internet, so every font, icon and QR code has to be made inside the project.
• The people who update it are not programmers. The editor has to be obvious.
• A screen can’t be tapped. If an announcement has a longer story, the only way to reach it is a QR code that a phone can read from a couple of metres away.

How I worked: layout first, then the tools

The design started with me. On 15 September I built a first prototype, “The Notice Board”: a single page with three scrolling card columns, an urgent strip and a clock. Then I planned the layout in four zones: a top bar, the main board, a side panel and a bottom ticker. Only then did the prototype, the layout and the Ta’az emblem go into Claude Design, which produced the display, the control panel and the card designs.

On 17 September, between 11:40 and 21:30, I turned those designs into the working product with Claude Code. 14 of the 15 commits carry its co-author line, and the commit messages record what was asked, what changed and how it was checked. I reviewed every change and set the requirements: the card as its own editor, one list for cards and slides, weekly time windows, and running fully offline.

AI tools make it fast to produce something that looks done. They don’t make it true. So the risky parts each got a measurement.

What I tried first: the QR codes

The first QR encoder was written from scratch inside the project. The codes it produced had the right squares in the right corners, with rounded modules and the emblem in the middle. They looked right, a decoder written alongside the encoder read them back correctly, and phones couldn’t read them.

I could have started debugging the encoder: the masking, the error-correction blocks, the bit order. Instead I asked a simpler question: why am I writing a QR encoder at all? Encoding is a solved problem. The part that is mine is the look.

What worked

QR codes: a proven encoder, and a decoder as the judge

I replaced the encoder with qrcode-generator, a proven open-source library under the MIT licence, kept inside the project so it works offline. My own rendering layer sits on top of it: it rounds each module according to its neighbours, draws the three corner patterns as whole shapes, and clears a space for the emblem.

The emblem is the dangerous part, because it covers modules the phone needs. A QR code can lose part of its modules and still be read, thanks to error correction, but only up to a point. So the rules are strict:

if the emblem is on:
    encode with error-correction level Q
    if the web address is too long for level Q:
        encode with level M and drop the emblem   # a long web address must still scan
    hidden = modules under the emblem / all modules
    while hidden > 15%:
        shrink the emblem and count again

On top of that, the style picker greys out the combinations of frame and centre shapes that scanners struggle with, so staff can’t choose a pretty code that doesn’t work.

Then came the measurement. I generated 254 test codes across every module shape, frame, centre and emblem size, with Hebrew and long web addresses, and had an independent decoder, the open-source jsQR library, read each one back and compare it with what was encoded. All 254 came back correct. The medium size is designed to scan comfortably from about two metres on a large screen.

The editor: the same rendering code, proven by computed styles

Staff edit a card by typing straight onto it. Click the title and type, click the picture to replace it, click the QR code to set it up. For that to be honest, the card in the editor has to be exactly the card on the screen, not a form that roughly resembles it.

So the display and the panel draw cards with the same script and the same stylesheet. “The same code” still isn’t proof, because the surroundings can change sizes and fonts. I compared the computed styles of the same card on both pages, property by property, and fixed the differences until they matched.

The scrolling: 1,681 frames

The card columns rise slowly and loop forever. Each column moves a card that has left the top to the bottom, so the loop never jumps. Endless scrolling is easy to get almost right: a stutter every few seconds, or a step backwards when a card is moved, is hard to spot in a quick look and very visible on a screen that runs all day.

I measured it over 1,681 frames, sampled with requestAnimationFrame in the browser. The median speed was exactly on target, and there were zero backward steps.

Design for people who are not programmers

Measurement keeps it correct. Design makes it usable. A few decisions I’m proud of:

• A new item starts from pictures. Adding an item opens a grid of wireframe pictures of the eight card styles, not a list of names. You pick what it should look like.
• The layout heals itself. A section that is switched off or empty disappears, and the screen rearranges itself with no holes. Columns whose content fits stand still; longer ones keep scrolling.
• Time windows. Any item can be limited to chosen weekdays between two times, like a going-home briefing that puts itself up on Thursdays at 15:00 and takes itself down at 19:00.
• Safe to operate. Drag-and-drop in every list, undo and redo up to 40 steps, and a one-file backup that includes the pictures. A damaged backup is refused with an explanation.

What I would do differently

I would start with the proven library. Writing the encoder myself saved nothing and cost me the evening’s last hours. The interesting work was always the rendering layer.

I would also pick an independent judge from the start. My first decoder was written from the same reading of the QR standard as the encoder, so it shared its mistake: the format bits, the first thing a scanner reads, were mirrored in both, and the two agreed. An established decoder, jsQR, rejected every one of those codes the first time it saw them. Now I ask the question at the start of any visual feature: what number tells me this works?

Where it lives

TaazTV was built from a first prototype to a finished product in three days, and the working product in one, in about 4,600 lines of JavaScript with no framework and no build step. The TaazTV case study shows the board’s design scheme and the finished screen, with two short videos of the board running and of a live edit.