KAZENAKAZENA
All posts

We folded the 5 rows that worked, and they read as gone

September 11, 2026 · Taro — Founder, KAZENA

There was 1 row on the screen. The file that had been read in had 6. The question that reached me was where the other 5 had gone. It came from E, an Indonesian colleague who has been with us since the founding and who looks after how our screens are built and how they behave on real devices. He does not live in Jakarta; he is in a small town some way out from here.

The answer first. All 6 rows had been read. Not 1 row had been thrown away. The import preview was built to list only the rows that needed attention, and the 5 rows that had been read cleanly were folded into a small line under the table. It said: 5 more rows.

Here is why we built it that way. What we had in mind was a large file exported out of an accounting package. The file we tested with had 214 rows, 3 of which needed attention. Lay out all 214 and the 3 that have to be fixed are buried. A screen that lifts only the problem rows to the top worked well on that file. We had never once tried it with a file of 6 rows.

It is worth saying where that folded line sat. Under the table, and below the import button. Small type, grey. On E's device the line was off the screen; you had to push the page up with a finger before it appeared. What he was looking at was a table with 1 row in it and a button that said import.

Here is what he did next. First he imported it 3 times. The same screen each time. Then he split the file into single rows: 6 files, 6 imports, hunting for the row that was being dropped. They all went through. That much took about 20 minutes. The bug he was looking for in that time had never existed.

People read what they cannot see as absent. It is an obvious thing, and we forgot it while building the screen. A screen that shows only the problem rows also erases the evidence that the rest were read correctly. Inside the part we folded away out of kindness sat the fact the person wants first: how many rows were read.

There is something worse. On that screen a row read correctly and a row not read at all look the same. Neither appears in the table. Which means that when rows really are dropped, the screen wears the same face it wore that day. A screen that looks broken when nothing is broken looks no different when something is. We were calling a screen that works in neither direction a confirmation screen.

Here is the shape we settled on. Every row that was read is listed. The order stays the order in the file, and the row number is shown alongside it. Rows needing attention are marked, and the sort that gathers them at the top is still there, but the state where only those rows are displayed is gone. And above the table we write it in words. We read 6 rows from the file. 1 of them needs attention. Importing as it stands will create 6 entries.

We rebuilt the counting itself into a feature. 3 numbers are always shown: the rows in the file, the rows that were read, and the entries that will be created. When the 3 do not line up, we write where the loss happened. Before, the count was something you inferred from how many rows the table held. A number you are left to infer has not been counted.

We added tests. Import a file of 1 row, 2 rows, 6 rows and 214 rows, and check that every row that was read appears on the screen. Our tests until then were all large files. The files that actually arrive are more often small; the most common thing is someone exporting 4 rows out of their own books to try it. Our test data was not our users' data.

We changed how we handle this sort of report as well. Before, a report like this meant checking whether the thing worked, replying that it works, and closing it. Nothing is broken, so there is nothing to fix. Now we record it as a defect. If it works and still looks broken, the thing to fix is not the behaviour but the screen. E's 20 minutes were not time spent by his misreading. They were time our own design made him spend.

A request. If a screen in KAZENA ever looked to you as though rows had vanished, or as though the numbers did not add up, please tell us. Whether anything actually vanished is ours to count. As long as we leave the counting to the person using it, we have not counted at all.

Tell us what you think

How the KAZENA apps feel to use, what we should fix, features you wish existed — if you run a small or medium business or work freelance in Indonesia or the Philippines, your voice is exactly what we want to hear. Messages in Bahasa Indonesia or English are answered by teammates who know your market from the inside. KAZENA Books is already set to launch in the Philippines and Indonesia — and if your company would like to bring it to other countries as a partner, or is interested in acquiring the system, we would love to hear from you too. We also take on new system development. We are a small team, so we cannot always start right away — but what we build carries made-in-Japan quality and stays close to how business really works here, one project at a time.

Get in touch

More from the blog