What arrived first was not a sentence but a photograph. E, our colleague, had taken a picture of his own phone screen with another device and sent it over. On the screen for recording an expense, the save button that should sit at the very bottom was showing only its top half; the rest had fallen off the edge of the display. The only words attached were a question: can you press this? He lives in a small town some way outside Jakarta, and he uses that screen every day.
Until then I had never questioned my own method. I develop on a 27-inch display, and when I want to see how something looks on a phone I drag the browser window narrow — down to about 390px — and if nothing breaks, I call it fine. A narrowed window does look like a tall rectangle. It just happens to be a rectangle on my desk rather than one in somebody's hand.
I asked him to measure his device. It is 360px wide in CSS units. The gap between that and 390px is 30px, less than the width of two fingers. And yet somewhere inside those 30px lay the line where several of our screens stop fitting. The width I had been checking was not the narrowest one; it sat just outside it.
I locked the window at 360px and opened every screen in KAZENA Books in order. There are 48 of them. 11 scrolled sideways, and on 3 of those the most important action — save, export, next — sat outside the screen entirely. A sideways scroll is reachable if you drag it with a finger. To someone who does not know it can be dragged, there is simply nothing there.
Almost all of it came from 1 component: a layout that puts the amount field and the tax-category selector side by side in 2 columns. Those 2 columns need 372px including their margins. On a 360px screen they overflow by 12px. It is only 12px, but when the thing hanging over the edge is the selector, that screen can no longer be used to select anything. And because the same component was reused on 11 screens, 1 oversight had become 11.
The harder problem was not the width but the height. When you tap the amount field, the on-screen keyboard rises from the bottom. On E's device it covers close to 300px of the 640px height. We had pinned the save button to the bottom of the screen, so the button ends up behind the keyboard, and scrolling does not move something that is pinned. That is exactly what his photograph showed. The button was not unpressable; it was not in a place where it could be pressed.
There was one more thing we had not looked at: text size. Plenty of people turn the system font up. Setting it to 1.3 and opening the same screen, the label inside the button wrapped onto 2 lines, the button grew taller, and the note beneath it was pushed out of view. We had only ever looked at 100%. Enlarging text is the ordinary thing a person does when text is hard to read. If the layout breaks the moment they do it, the failure is ours.
Let me be honest about the rest. A similar report had already reached me in June — a short message from someone in the Philippines who uses KAZENA Books, saying a button was cut off. I decided at the time that it was something specific to that person's device, and I closed it, because narrowing my own window did not reproduce it. It failed to reproduce because I was narrowing it wrongly, not because of their phone. For 2 months we shipped something we could have fixed.
One afternoon this summer, waiting to pay at a food stall in Jakarta, I watched the person beside me holding a plate in one hand and finishing a payment with the thumb of the other. In the daylight the screen was washed out to white, and the only part of it the thumb could reach was the lower half. The conditions have nothing in common with the checking I do at my desk. Taking my handwritten receipt, I found myself wondering whether our save button could be pressed while holding a phone like that.
Here is the order in which we fixed it. First, the primary actions we had pinned to the bottom of the screen went back into the flow of the page. Reach the end of the form and the button is there; when the keyboard is up, the page carries it above the keyboard naturally. Second, the 2-column layout now collapses into a single column below 380px. Where it is narrow, the surest thing is not to place things side by side.
Then we changed how we check. Instead of relying on my own eyes, we now capture screenshots of 12 key screens automatically at 360px by 640px, and take the same 12 again at a text size of 130%. Anything overflowing is visible in the picture. While we were at it, we found 2 places where the tappable area was under 44px and made them bigger; both were the small chips for choosing a tax category.
What I took from this was not technical. The width of the screen I develop on is not a preference — it is a decision about who I am building for. My browser now opens at 360px by default, and I widen it only when I deliberately want to see more. If a button is cut off or text is clipped on your screen, a single photograph is enough; please send it. Because E did, I was finally able to doubt my own desk.
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