在手机上写完一段话，回头发现中间少了一个字。你点向那条窄窄的缝，手指却正好把文字挡住；光标落在前一个字旁边，再点一次，又越过了目标。
鼠标有一个清楚的尖端，手指没有。屏幕接收到的是一小片接触区域，文字间的落点却可能只有几像素宽。手指还会遮住目标，轻微晃动也会被当成移动。手机屏幕越小，想在一行字中精确落位就越难。
妙盒笔记没有要求用户反复点中那条缝，而是在键盘上方的工具栏里提供了光标控制面板。按住中间的光标按钮并拖动，编辑区会出现一根跟着移动的浮动光标。它先告诉你“如果现在松手，会落在这里”；松手之后，真正的输入位置才移过去。
手指在下面移动，落点在文字里预览
这个操作不要求手指盖住正在修改的文字。手指可以留在下方的控制面板，视线则看着正文中的浮动光标。移动幅度经过放大，小范围拖动可以跨过更多距离；需要细调时，再慢慢把预览移到两个字之间。
在长笔记里，浮动光标接近编辑区上下边缘时，内容还可以继续滚动。目标文字进入视野后，继续调整位置，松手即可落位。需要选择一段文字时，同一个面板也能保留一端，再移动另一端。
从使用者的角度看，过程只有两步：
- 拖动时看预览，找到想要的位置。
- 松手时确认，接着输入或删除文字。
预览始终要跟手，最终落点则只需要确认一次。这正是这项交互的关键。
为什么不让真实光标一路跟着跑
真实光标不是屏幕上的一根装饰线。它决定下一个字写在哪里，也会影响输入法、文字选择和页面滚动。如果手指每移动一点，编辑器就立刻改一次真实位置，这些行为也可能被连续触发。反馈看似更“真实”，结果却可能是抖动、跳动，或者正在输入的文字受到干扰。
所以，妙盒笔记把“让我看到意图”和“真的改变文字位置”拆开了：
- 拖动时，浮动光标负责提供连续的视觉反馈；
- 松手时，编辑器才把预览位置变成真正的输入位置。
这不是让反馈变慢。恰恰相反，预览可以立即响应，因为它不必在途中把每一个经过的位置都当成最终决定。
这种做法也不只适用于光标。拖动排序、裁剪图片、调整滑块或移动地图上的标记，都可以先展示“将会发生什么”，等用户结束动作后再修改真正的数据。普通话说，就是：过程要及时给反馈，结果要等确认再落定。
看得准，也必须落得准
把光标分成预览和落位之后，又会出现一个更隐蔽的问题：屏幕上看到的位置，怎样准确变成文字里的位置？
开发过程中曾出现过一个很典型的故障。浮动光标看起来已经到了目标位置，松手后，真实光标却经常跳到整篇文字的开头。原因不是手势不准，而是同一个位置被换算了两次。编辑器收到了一组已经转换过的坐标，又按自己的规则转换一次，最后误以为目标在开头。
修复方式并不华丽：明确每一步接收的是什么位置，只转换一次，并让预览与最终落位使用同一个目标点。
这个故障提醒我们，两阶段交互不能只做到“拖起来很顺”。如果预览在 A，松手却落到 B，再流畅的动画也没有意义。用户不需要知道背后的换算过程，但必须能够相信眼前那根浮动光标。
这项取舍没有消除所有问题
拖动期间显示的是未来落点，不是已经改变的真实位置。依赖真实光标的系统能力，不一定会随着预览逐步更新。对需要朗读光标位置的辅助功能来说，这一点尤其值得继续验证。
浮动光标也不能让手机拥有鼠标一样的物理精度。它解决的是手指遮挡、落点难控制以及连续更新容易不稳定的问题，让小范围修改少一些反复点按。
它保留的是一种更朴素的确定感：拖动时，让你清楚看到准备去哪里；松手时，再让文字输入真正从那里开始。