Every table wanted a different press

There are tables you open by pressing anywhere in the row, and tables where you have to aim at the text. That was the message E sent me on 19 August. It was not a bug report. He had simply noticed something and written it down as he saw it. Reading it, I thought that was a fair way to put it, and sent a short reply. That one line became 2 days of rework.

Here is what he was doing. E lives in a small town some way outside Jakarta and works through KAZENA Books on his own phone. He had the counterparty list open. Pressing a row did nothing. He pressed a few more times, decided the screen had frozen, and closed the app. When he opened it again and happened to press directly on the company name, the detail opened. Nothing was unresponsive; he had been pressing in the wrong place.

I counted our own screens. We had 10 screens shaped like a list. On 4 of them, pressing anywhere in the row opened it. On 3, only the text of the company name or the number worked. On 2, there was an Open button at the right-hand end of the row. And on 1, nothing happened unless the row was pressed 2 times in a row. Ten screens, 4 conventions. Nobody had decided this. Each screen was written on a different day, for a different need, in whatever shape looked most natural that day.

I thought about why no report had reached us in 3 months. People do not report that the conventions differ from screen to screen. What reaches us takes the form of this screen does not open. Reading back through 3 months of messages, I found 6 reports saying a list would not open. All 6 were on one of the 3 screens where only the text works. We had closed 4 of them saying we could not reproduce it, because at our desks, with a mouse, we happened to be pressing on the text. The reports had arrived. We were the ones who misread them.

I asked V about it as well. She is an accountant here in Jakarta and has tested KAZENA Books with her firm's live data more than 20 times. When I described this, she said she does not remember which table is which, so she always aims for the text. She had been hitting the narrowest target on every screen, to be safe. She did not call it inconvenient. She said she was used to it. A habit a user picks up in silence never reaches us as a report, and while it does not, it takes a little of their time every day.

I remembered that over lunch at a nasi padang place. You point at the dishes laid out along the counter. You do not have to say the name, and you do not have to aim at the small print on a label. Point at the thing itself and it arrives. What you are meant to point at is simply out there, at full size. On our screens, the thing you wanted was written right across the row, and only part of the row could be pressed.

Here is the rule we settled on. A row in a list opens wherever you press it: the whole height of the row is the target. It opens inside the same screen, in a way that makes the way back obvious. A row has exactly one main destination. Written out, those 3 lines are obvious. Until that week they were written down nowhere.

We fixed the dangerous part at the same time. On 3 screens, a delete button sat inside the row. Once the whole row opens, that delete button is right beside the target you press to open. On a phone they end up in nearly the same place. Delete moved into a menu at the right-hand end of the row, including on the screens where deleting is routine, such as drafts. The confirmation now shows the name of the thing about to be deleted.

We settled the exception too: tables that are for choosing. They have a column of checkboxes at the left, and pressing a row toggles the selection. Rows in those tables do not open. There are 2 kinds of table, one you open and one you choose from, and no single table may be both. We made them look different as well: the checkbox column on the left, and a count in the header of how many rows are selected right now.

Some text inside a row still leads somewhere else. In the invoice list, pressing the counterparty name takes you to that counterparty. That is a different destination from the row's own, so it is underlined and it stops the row's action when pressed. We cut this down to the 2 places that genuinely need it. Before, plain explanatory text was underlined in places as well, so there were spots that looked pressable and did nothing.

The cost: 10 screens, 2 days. Most of the work was building 1 shared component and moving each screen onto it. The hard part was not the rewriting but deciding which convention to keep. Once decided, we wrote the conventions on a single page and put it next to the code, so whoever builds the 11th list screen does not have to invent a shape again.

What I had wrong is not subtle. I had treated matching conventions as tidying up the way things look, the kind of work you can postpone on a day when something is urgent. It is not. A screen whose conventions differ from its neighbours is read as a broken screen. Each of our screens had been built correctly, on its own day. Gathered together, they were still wrong. Correctness is not settled inside 1 screen on its own.

One request. If you press something in KAZENA and nothing happens, tell us as it is — including the cases where you have already found your own way of pressing it and are getting by. A bug you have learned to work around will never reach us on its own. This one reached us through one line from a teammate pressing at a table on his phone, and it was not even a report.