When you write notes on your phone, the formatting, cursor, and insertion tools you use most often usually sit above the keyboard. They're close to your fingers and don't cover the text you're typing.
But the moment you open a secondary panel from that toolbar, the experience can suddenly turn rough: the keyboard dismisses first and the toolbar drops down; then the panel appears and shoves the toolbar back up. Sometimes it leaves a blank gap that covers the body text, or the whole thing bounces back and forth when you switch input methods or connect an external keyboard.
These shifts are usually only a few dozen pixels, but they leave a very clear impression: the interface didn't keep up with what you just did.
A good transition shouldn't make the body text hunt for a new position
Abox Note has an editing toolbar above the keyboard. When you open a secondary panel, the ideal experience isn't simply "dismiss the keyboard, then open a different area"—it's letting the new panel take over the space the keyboard was already occupying.
From the user's point of view, the toolbar should stay roughly where it is:
- While typing, it sits right above the soft keyboard;
- When you open a secondary panel, the panel takes over from the keyboard from below;
- When you close the panel and go back to typing, the keyboard reclaims its original boundary;
- Through all of this, the body text shouldn't suddenly get covered or have its visible range change drastically.
The goal here isn't to make the two regions exactly the same pixel height on every device—it's to preserve a sense of continuity. The button you just tapped shouldn't leap somewhere else the very next instant, and the line you're reading shouldn't keep shifting just because the bottom region switched.
Keyboard height isn't a fixed number
The difficulty is that a phone's keyboard isn't a permanently fixed rectangle.
Keyboards animate in and out, and the height the system reports changes gradually during that time. An input method can switch between candidate rows and its own toolbar; once an iPad connects to an external keyboard, the bottom of the screen may shrink to a much shorter accessory bar; devices with a bottom gesture area also change the available space right around when the keyboard hides or shows.
If the toolbar chased every single height change immediately, it would end up treating an in-between animation value as the final result. The page is already adjusting to avoid the keyboard, and if the toolbar makes its own adjustment on top of that, the two movements stack up—producing jitter, flicker, or brief overlap.
The key idea Abox Note settled on is to remember the last stable bottom space right before a transition begins. While the keyboard is dismissing and the secondary panel is appearing, the toolbar doesn't chase every intermediate value; only once the new state has settled does it resume responding to changes.
Put plainly: during a transition, hold the boundary steady first, and don't take every number that shows up mid-animation at face value.
You also have to figure out what's actually at the bottom of the screen
"There's height at the bottom" doesn't necessarily mean the full soft keyboard is showing.
An external keyboard might leave only a short accessory bar, and the system sometimes keeps reporting a chunk of bottom space even after the soft keyboard is gone. If an app only checks "is the height greater than zero," it might yield space for a keyboard that isn't actually there, leaving a blank gap—or mistake a very short accessory bar for a full keyboard and incorrectly close the secondary panel.
So the toolbar needs to combine whether the keyboard is currently animating, the shape of the current height, and the external-keyboard state to judge whether a given number can be trusted. For the bottom gesture safe area, it also needs to account for space the page has already claimed, rather than mechanically subtracting it again just because the system reports some height.
Users don't need to understand any of this underlying state, but the outcome has to be something they can feel: through keyboard, toolbar, and panel transitions, there's no mysterious blank space at the bottom, no button suddenly jumping away, and the body text never gets covered by the new panel.
Stability matters more than frame-by-frame "real time"
Adapting the toolbar to the keyboard looks like a height problem on the surface, but it's really more about figuring out what state the system is in. The same height value, appearing mid-animation, during stable typing, or right after an external keyboard connects, can mean completely different things.
This approach also has limits. Split-screen, floating keyboards, third-party input methods, and unusual external-keyboard combinations can still produce new shapes that need to be verified on real devices. Locking the height temporarily for the sake of stability also means the app deliberately doesn't chase every single frame.
But for someone in the middle of writing, what matters most was never how precise a number the app managed to read—it's whether the interface stays coherent before and after. Pixels are just the outcome; what actually needs to stay steady is the boundary between your finger, the button, and the text you're writing.