You finish typing a paragraph on your phone, then notice a missing word in the middle. You tap the narrow gap between two characters, but your finger covers exactly the spot you're aiming for. The cursor lands next to the wrong character; you tap again and overshoot.
A mouse has a sharp point. A finger doesn't. The screen only receives a small patch of contact, while the gap between two characters may be just a few pixels wide. Your finger blocks the very target you're trying to hit, and the slightest tremor reads as intentional movement. The smaller the screen, the harder it is to land precisely within a line of text.
Instead of asking users to keep tapping that narrow gap, Abox Note puts a cursor control on the toolbar above the keyboard. Press and hold the cursor button in the middle, then drag—a floating cursor appears in the body text and follows your finger. It tells you "this is where you'll land if you let go" first; only when you release does the actual insertion point move.
Your finger moves below; the landing spot previews in the text
This interaction doesn't require your finger to cover the text you're editing. Your finger stays on the control panel below, while your eyes track the floating cursor in the body above. Movement is amplified, so a small drag covers more distance; when you need fine control, you slow down and ease the preview into the gap between two characters.
In a long note, the content keeps scrolling as the floating cursor nears the top or bottom edge of the editing area. Once the target text comes into view, keep adjusting, then release to land. When you need to select a range, the same panel lets you anchor one end and move the other.
From the user's perspective, it's just two steps:
- Watch the preview while dragging to find the position you want.
- Confirm by releasing, then type or delete.
The preview always tracks your finger; the final landing spot only needs one confirmation. That's the core of this interaction.
Why not have the real cursor follow along the whole time
The real cursor isn't just a decorative line on screen. It determines where the next character goes, and it also affects the input method, text selection, and page scrolling. If the editor updated the real position every time your finger moved even slightly, those behaviors could fire continuously too. The feedback might look more "real," but the result is often jitter, jumping, or interference with text you're actively typing.
So Abox Note separates "show me the intent" from "actually change the text position":
- While dragging, the floating cursor provides continuous visual feedback;
- On release, the editor turns that preview position into the real insertion point.
This doesn't slow feedback down. Quite the opposite—the preview can respond instantly, precisely because it doesn't have to treat every intermediate position along the way as a final decision.
This approach isn't unique to cursors, either. Drag-to-reorder, image cropping, slider adjustments, or moving a pin on a map can all show "what will happen" first and only update the real data once the user finishes the gesture. Put plainly: the process should give feedback right away, but the result should wait for confirmation before it's final.
Seeing it clearly isn't enough—it also has to land accurately
Once you split the cursor into a preview and a landing step, a subtler problem shows up: how does the position you see on screen turn into the correct position in the text?
A pretty classic bug surfaced during development. The floating cursor looked like it had reached the target, but on release the real cursor would often jump to the very beginning of the whole document. The cause wasn't an inaccurate gesture—it was the same position being converted twice. The editor received a set of already-converted coordinates and then converted them again by its own rules, ending up mistakenly pointing at the start.
The fix wasn't glamorous: be explicit about what position each step receives, convert only once, and make sure the preview and the final landing point use the same target coordinate.
That bug is a reminder that a two-stage interaction can't just feel smooth while dragging. If the preview shows position A but you land on position B, no amount of animation polish matters. Users don't need to know the conversion logic behind the scenes, but they do need to be able to trust the floating cursor in front of them.
This trade-off doesn't eliminate every problem
What you see while dragging is a future landing spot, not an already-changed real position. System capabilities that depend on the real cursor may not update incrementally as the preview moves. This is worth continuing to verify, especially for accessibility features that need to announce cursor position out loud.
A floating cursor also can't give a phone the same physical precision as a mouse. What it solves is finger occlusion, hard-to-control landing spots, and the instability that comes from constant updates—cutting down on repeated tapping for small edits.
What it preserves is a simpler kind of certainty: while dragging, you can clearly see where you're headed; on release, text entry actually begins from there.