A tab bar that scrolls away can only be tapped from the top
Two habits every phone user has — tap the tab you are on to jump back to the top, and return to a list exactly where you left it — turned out to be impossible in our staff app for one structural reason, and no amount of code was going to fix it without moving the tabs.
Our staff app is where a chef clocks in, reads the rota, checks their hours and books time off. It is used one-handed, mid-service, on a phone that is not clean. It is not the kind of app anybody is willing to learn.
So it should behave like every other app on that phone. Two of those behaviours are so ordinary nobody names them: tapping the tab you are already on jumps you back to the top of it, and leaving a list and coming back puts you exactly where you were rather than at the beginning.
Building one of them, and watching it do nothing
We built the second — remember the scroll position per tab, restore it on return. Then measured it in a real browser, and every position came back zero.
Not a bug in the remembering. The tabs were a row at the top of the page, inside the page, scrolling with it. Which means two things at once. First, the thing doing the scrolling was the whole document rather than the list, so the position we were carefully storing per tab was never a list’s position. Second, and worse: by the time a chef has scrolled far enough for the memory to matter, the tab row is a screen and a half above them. To switch tabs they scroll all the way back up. Having got there, the restore has nothing left to restore.
The same structure kills the first behaviour outright. Tapping the current tab to return to the top is only useful when you are deep in a list, and that is precisely when the tab is not on screen to be tapped.
The honest move was to stop and ask
We had working code for a feature that could not work. The choice was to ship it — green tests, no visible change, a line in the notes claiming a thing the app does not do — or throw it away and raise the actual question, which was about the shape of the app and not ours to decide.
We threw it away and asked. The answer was a fixed bar along the bottom, which is where phones have put this since about 2013, and the rest followed from rules worth stating plainly: at most five tabs, Home at the far left, the personal one at the far right, the action you take most often as a button in the middle. For a kitchen that action is clocking in and out, so it is the middle button — and on an account that cannot clock in, it is not a disabled stub, it simply is not there and the fifth tab takes the space.
Why it is worth the rebuild
Every one of those is a habit your staff already have from apps they use all day. None of them has to be taught, and none of them is noticed when it is right. They are only ever noticed when they are missing — as a vague sense that the thing the manager made everyone install is awkward, which is not feedback anybody will give you in words.