The position didn’t change. Did the button work?

In an early version of my rebuilt trading demo, clicking Read F1 again left the position at one. That was the intended result. During review, the button still felt as though it needed a visible response.

The demo is a teaching model with made-up trades. It runs in the browser and has no broker connection. A reader follows a buy order for two units, sees one unit bought, and chooses whether the notification of that trade reaches the system. The provider keeps its own trade records; the system updates its books from the records it receives.

If the notification is dropped, the provider holds one unit while the books still show zero. Querying the provider’s position reveals a difference. Retrieving its trade history identifies the missing entry, F1, which the system can then record. F1 is the trade’s identifier. Receiving that same identifier again must not turn one purchase into two.

This gave the repeat button an awkward job: demonstrate a successful action whose important result was an unchanged number.

The comparison below starts after F1 has been recorded. On a wide screen, one button runs the repeat action for both layouts side by side. On a small screen, read F1 again, then switch layouts; the read count stays the same. This is a reconstruction of the feedback layouts using the current calculation rules. The shared button and large counter are later additions for this comparison, so it does not reproduce the full earlier experience.

Showing what the click did

The earlier interface updated its explanation and a reread count in the comparison area. It did not leave the entire page unchanged. But the position was the most prominent number, and another click left it at one. The reader had to look elsewhere to distinguish a skipped duplicate from an action that had not run.

In the revised pane, the incoming F1 sits beside the F1 already in the books. Each click briefly moves the incoming record and highlights the match, then leaves a visible result: Duplicate skipped · +0 units. This shows which record was checked and why it added nothing.

I also made the reread count a separate, prominent number beside the button. It starts at zero after the original trade has been recorded and advances on every repeat click. The holding stays at one. The two numbers answer different questions: how many times the reader repeated the check, and how much was bought.

The motion draws attention to the check; the record ID, count and result explain it after the motion stops. With reduced motion enabled, those details remain visible. Repeated clicks also keep the button and scroll position in place, so the feedback does not move away from the action that caused it.

That made each repeat visible. It also gave the repeat action more weight within a demo that still had an order to finish.

Giving the order an ending

The same review exposed a larger omission. The demo began with an order already accepted and ended when the missing record had been repaired. That was enough to examine recovery, but it left both the order’s origin and its remaining quantity outside the experience.

I extended it in both directions. The reader now starts with no holdings and a target of two, then submits the order. After the first trade and its record have been checked, the reader can buy the remaining unit or cancel it. Both paths end with a fresh position comparison.

The cancellation path makes the distinction useful: the final holding is one, the target is still two, and no order remains open. The books can accurately report that result even though the target was not reached. Buying the remaining unit instead ends with a holding of two and a fully filled order.

Those endings made the account more complete, but they also lengthened the sequence. A reader could understand each instruction and still have no sense of how much remained. Repairing the missing record had become an intermediate step rather than the finish.

The opening now explains the choices and what the reader will compare at the end. A three-stage strip stays in the interaction: Place order → Check records → Finish order. Before the reader drops the notification, the page explains that this choice adds a recovery branch. Finding and restoring F1 belongs to checking the records; it does not introduce another order or a new objective.

Choosing the next button

The stage strip locates the reader in the order, but several actions can still be available at one point. I reserved the white button for the next action I want to guide them toward. At the notification choice, that is Drop notification, because it exposes the difference between a trade happening and the system learning about it. Normal delivery remains available. After recovery, the white button leads toward filling the remaining unit; cancellation is another available ending.

Repeated reading is useful at that midpoint, but it does not advance the order. I initially put the check inside a collapsed panel, which also hid the new counter. The full demo now leaves its repeat button and count visible, uses an outlined button for that optional action, and folds away only the detailed matching diagram. In this Note, comparing repeat feedback is the main activity, so Read F1 again keeps the white button.

These changes came from reviewing and operating the demo during its construction. Browser checks cover the implemented paths, including repeated reads, both endings and navigation. They do not establish that someone arriving without this background will understand the example. The next useful check is whether that reader can finish the cancellation path and explain why a holding below the target can still agree with the books, without a separate explanation from me.