在我写iPhone 版 Safari 破坏了人们预期的“轻点回到顶部”手势那篇文章前后，社交媒体上的一场讨论又指出了这个标签页控件另一个奇怪之处。

在 Safari 的典型用法中，会有两组站点：右侧是常规标签页，左侧是“无痕”页面（也就是 Chrome 里所说的“无痕模式”）：

不出所料，你可以轻点任意一侧的标签，轻松切换到对应的分组：

它看起来也能滑动——也的确可以，只不过……

……你会立刻碰到“滚动锁定”问题。你拖动的不是那个药丸本身，而是药丸下面的内容。要切换，你得往相反的方向拖：

你能立刻感觉到整个系统那种与生俱来、令人不适的复杂性——不仅仅在于它“方向反了”，还在于它在你操作结束后，分两步先腾出空间、再把空间收回的方式。

原因在于，你实际上可以拥有不止最初那两个站点分组。你甚至可以拖到本该出现新分组的位置，直接用这种方式创建一个新分组：

我通常很欢迎这类快捷操作。但在这里，它却显得过度设计、令人困惑，就好像有人不是在拖动（drag）标签页，而是给它下了药（drug）。那个本应让人安心、把你带到“无痕浏览”的自然手势——向左轻扫——现在却会把你带进一个几乎永远用不上的、吓人的全屏/键盘弹出的新流程里。

这件事之所以与系统设计相关，是因为 iOS 最近把开关控件重新设计成了这种长条药丸的样式：

那些开关确实会如你预期那样响应拖动：

同理，在主屏幕的分页指示器上，向右拖动就意味着翻到下一页：

于是现在的系统就显得精神分裂——外观一模一样的设计基元，含义却截然相反。就好像电脑自己在随机地替你按下 Scroll Lock，让你首先无法对系统建立清晰的认知，其次也无法形成肌肉记忆。

我认为这里犯了两个错误。第一，设计为两件不必要的事情过度优化了：人们真的会去使用站点分组（其实并不常见），以及创建站点分组的便捷性（其实并不重要）。我略带讥讽的猜测是，这个设计在演示时呈现效果非常好——而这有时反而会把项目带偏。一个更讥讽的猜测是，这带来了某种“意外发现”，让站点分组的数据指标看起来更好了。

第二点，也是更重要的一点：这个特定的设计得到了一个它本不应得的例外。没有人注意到相似的界面元素却做着相反事情所带来的系统性挑战，或者注意到了的人也没能有效地提出反对。新功能被发现的指标很容易衡量；而用户困惑或沮丧的指标，通常根本就不存在。

交互系统就是这样慢慢瓦解的。正如我在第一部分中提到的，Safari 的这个例外很可能会被视为“正统”，并开始进一步蔓延。假以时日，会有越来越多的药丸在被拖动时朝着各自任意的方向移动——而人们最终会学会不再信任其中任何一个。

我知道这个功能实际上叫做“标签页组”，但我是有意把它叫做“站点分组”的，否则就会变成“用标签页控件来控制标签页组”，很快就会让人一头雾水。另外，感谢 Martin Hoffman 促成了这篇文章。