摘要：本文作者直指苹果《iOS人机界面指导手册》中的设计在测试中可能会造成可用性问题的pattern，结合实际应用案例总结出页面控制、顶部的表格提交按钮、加号（+）图标、Move icon这四种应该比打破的iOS设计规则。

大的软件公司，比如苹果、微软和谷歌都为用户和设计师发布了设计指导手册。一方面，设计与开发人员可以提前建造界面，而无需创造（与测试）全新的UI元素。另一方面，在所有设计人员都遵守这些指南的情况下，同一个OS系统上所运行的不同程序会带给用户一致性的观感。

在本文中所列的风格设定都是被频繁推荐的。但有些情况下，“官方”设计在实践中表现欠佳。尽管如此，出于未知原因——也许只是权衡利弊，并未深入研究，或许推荐的pattern对一个很有难度的设计挑战来说，似乎算是最好的解决办法了——这个pattern仍被列入风格设定中。

下面这四种常见的iOS pattern都是苹果官方在其设计的App中所广泛采用的，同时也受到很多其他设计师的追捧。其中一些摘自《iOS人机界面指导手册》（HIG,iOS Human Interface Guidelines）一书。我们一次次看到这些设计所造成的可用性问题，冒着被苹果大神劈的危险，在此声明：不推荐下面这些模式，因为它们没能通过可用性测试：

• 页面控制（Page Control）：标明页面的圆点（Dot）
• 
  顶部的表格提交按钮（Submit button）
• 
  加号（+）图标
• 
  Move icon

页面控制：标明页面的圆点

很多iOS用户都很熟悉页面控制。iOS页面控制是一行水平排列的圆点，代表打开view或页面。当前选中的页面以不透明的圆点表示，而其他页面以透明圆点表示。

iOS主屏幕使用圆点（页面控制）指明current view，还有其他view页面的数量。这是圆点使用中认可度最高、也最为常见的案例之一，也是其中少数运行良好的案例之一，因为用户了解：有多个充斥着杂七杂八icon的页面，只管一页页扫过去，找到想要的app就行了。（整体定位icon的用户体验并不理想，但页面圆点不算问题。）

一些App与网站使用这个界面元素来表明内容页可滑动，还有一些将它用在页面上，表示content可以水平滚动（carousel）。在移动web与应用中，这是一个流行的设计方式，但用户也经常会忽视掉那个圆点。在可用性测试中，这些圆点在整个界面中太不起眼，无法明确指示出还有其他可用的content view。因此，不应使用在像是功能导航之类的关键功能上，或作为访问信息的唯一方式。

在这款iOS App “Stock Market HD：Stocks and Shares”中，在“Watchlist”、“Wishlist”、“Sold”和“My Holding”这些views之间切换的唯一明显方式就是：发现页面底部的圆点，然后通过滑动来探索额外的功能。

虽然设计与开发人员可以选择使用什么颜色的圈圈，想要设计出一个精致而醒目的半透明小圆点十分困难。很多设计在花哨的图片上也使用了这些圆点，导致这个本来就很细小的设计元素进一步融进背景中。如果用到圆点，为了帮助用户注意到它们，可以加强圆点与背景之间的色彩对比，或将圆点尽可能放在纯色背景上。

“Zappos”这款iOS App在页面的上半部分运用了圆点来标明有多个content view。在第一张图中，圆点在以鞋子为背景的图片上依稀可见，而在第二张图中，完全与背景中的椅子融为一体。

一些网站与App甚至打破了现有的iOS惯例，使用正方形、其他形状或者在页面四周随意挪动圆点。即便遵循iOS指南中的设计惯例来使用这些圆点，用户想要找到它们也十分困难。背离标准改变这些元素的话，只会更难识别或理解。如果使用圆点，将它们置于控制元素的底部中间。

Android版的“Fab” App借用了iOS的圆点，但将它们放在了轮播元素的右侧，而不是放在中间。

即使用户确实注意到圆点，还有一个重要的可用性问题。圆点仅允许顺序读取，并未指出页面的内容。无论圆点指示的是轮播元素（carousel），还是单独的页面，都有同样的可用性问题。尤其是以轮播元素代表页面，限制了用户的控制体验。用户无法知道下面会有什么，也没办法直接切换到感兴趣的页面。

作为替代，我们推荐：

• 想一下，甚至可以通过滑动来访问内容。可以通过导航或文本链接访问的话，体验更佳。
• 将内容截出一块（文本或图片），以便给用户直观的视觉提示，用户可通过滑动显示更多的信息。

iOS App Store没有使用圆点，而是使用要素切片为用户展示导航carousel是可移动的。顶部的“表单提交按钮”（或类似的东西）

在iOS中，“完成”按钮往往位于页面顶部的导航条上。有时候“表单提交按钮”（“提交”或者别的什么，比如“订购”）也放在顶部。这种模式也开始渗透到Android App中。

iOS的日历（左侧）：提交表单的“添加”按钮位于页面顶部右侧的导航条上。Android的Todoist——待办事项app（右侧）借用了iOS的模式，将“提交”按钮（选中图标）放在右上角。（还要注意，表单字段违背了很多指引：label在字段内出现，而且你能猜到GMT-8:00代表什么吗？）

即使在iOS App，我们也不建议使用这种模式，原因很简单，它违背了页面中从上到下的自然流程。用户填表单时一般是从上到下的。他们填到底部时，就希望能看到“提交”按钮就在他们刚刚填完的字段旁。大多时候他们是找不到“提交”按钮的，就会困惑地四处寻找，不知所措。

在下面的例子中（“Pinkberry”和“Nordstrom” app），用户需要在填完表单后点击“登录”与“下订单”按钮。将这些按钮放在屏幕顶部是违反填写表单的自然流程的：一旦填完所有字段，用户翻到了页面的底部，无事可做。即使在移动设备的狭小屏幕上，寻找到相应的“提交”按钮也得多费功夫，如果按钮在页面底部，就像大多桌面表单那样的话，是本可避免的。（适用于任何GUI的公认准则：操作与对象要靠近彼此，不要将action按钮放置地离它控制的数据太远。）

iPhone上“Pinkberry”（左侧）与“Nordstrom”的“提交”按钮（分别标着“登录”与“下订单”）与working area是分离的，它被放置在屏幕的顶部。

将“提交”按钮放在header的优点之一在于：由于header在iOS App中始终显示，用户任何时候都能很容易地点击按钮——无论是否填完表单所有字段并拉到列表底部。（对于日历App来说，在假定用户不会费心填完所有字段的前提下，这个设计可能是合理的，但是登录表单则不是这样。）任何情况下，想要设计始终能够访问的按钮，可以考虑在页面底部放一个始终可见的“提交”按钮，就像“Hotel Tonight” App做的那样。没错，你会牺牲掉一些屏幕空间，但换来更好更方便的交互流程。

“Hotel Tonight”：页面底部的“支付”按钮一直显示并可用。它允许用户需要时随时与“支付”按钮进行交互，同时按钮位置出现在可预期并符合逻辑的位置。

作为替代，我们推荐：

• 将表单“提交”按钮（或类似的东西）显示在表单字段的下方，而不是页面顶部。

加号（+）图标

在许多移动App中，加号用来表示各种各样的功能。放置在顶部导航栏时，通常表示“添加”，但放在table或item list中则要么表示将该项添加到某类列表或群组中，要么表示展开查看详情。当多种解释存在时，用户对该图标难以保持一致性的理解。

放置在顶部导航栏时，加号图标（右上角）大多表示添加新项目，就像“MyFitnessPal”app中添加朋友的操作。

加号图标的用法在很大程度上要取决于所在的位置。位于通用位置比如导航栏时，理解为“添加新项目”一般是正确的。但是，如果加号出现在界面的主要内容中，可能有多重含义，会让用户产生混乱。

举个例子，比如“Any” app的上一版将加号显示在现有的待办事项标签旁。这种情况下，点击加号是会打开隐藏列表查看事项，还是触发“添加新待办事项”就不清楚了。这款App的现版本解决了这个问题，加号被放置在导航栏上：但现在是用来添加一个全新的待办事项。

“Any” 的上一版（左侧）的加号含义不明确，可以理解为展开列表或者为特定列表添加新项目。这款App的现版本（右侧）解决了这个问题，将加号放置在导航栏上，现在是用来添加一个全新待办事项的。

利用加号来触发动作很危险，用户可能会对触发的动作产生错误的预期。由于在web和移动app中加号经常用来表示列表可以展开（加上箭头与^符号），用户通常不会想到同样的加号实际会执行某种操作。在“LinkedIn”的移动App中，一个圆圈中的加号被用来代表关注一个公司，或者根据位置加入群组。在可用性测试中，一些用户在本打算查看更多信息，却不小心加入群组时非常惊讶。

“LinkedIn”App在整个应用中多次重复使用加号，并且用作实现各种功能。在上面显示的主页中，点击加号来关注一个公司（没有再次确认用户意图）。在这个App中，加号还被用来快速加入群组。幸好在用户或工作的搜索结果中没有用到这个含义模糊的图标，否则可能会导致一些有趣的结果。

由于根据具体情况不同可能会有多种诠释，请避免在应用中随意使用加号。

作为替代，我们推荐：

• 导航栏是比较安全的位置，在设计中运用在其他地方的加号必须经过用户测试，以确保含义正确传达。
• 完全避免这一问题的唯一办法就是避免使用加号图标，使用箭头或^来表示展开列表，使用带有文本标签的按钮来表示相关动作的触发。

Move icon

就像移动设备上的很多图标，move icon不能明确表示触发的动作。单看的话，你可能意识不到这个icon会移动列表中的一个项目。move icon上有三条水平直线，可能代表了列表，也可能就像一名读者指出的那样，是“禁止拖着东西时翻过的山脊”。这个图标出现在列表中时，是希望用户按住它不放手，并拖拽相关项目到列表中正确的位置。此模式下还有一些可用性问题。

一个项目在列表中可以移动时，用户希望直接按住相关条目并拖拽。他们不希望必须按住一个又小又难理解的图标来拽。这个图标比列表本身小多了，也难按多了。因此它会增加交互成本，并给用户点击拖拽时带来麻烦。此外在list view中，用户希望在同一行中的元素执行的操作相同：也就是说他们认为，拖拽item本身和icon是一回事。

雅虎财经采纳了苹果对于在iOS列表中移动item的建议。点击move icon（左侧），拖拽选中item。在移动时item显示出文本阴影（中间），变更生效（右侧）。列表项目本身的目标要更大一些，但是点击拖拽它们是无效的。

最终，与iOS风格指南几乎一模一样的图标出炉了，在移动web与其他地方所代表的含义却截然不同：hamburger menu看起来与move icon极其相似。

左侧是一个move icon，右侧是一个hamburger menu。

这可能会让人们感到不安与困惑：同一个东西或者看起来一样的东西，却调用不同的命令。如果hamburger menu吸引更多使用者的话，更多用户会习惯点击三条水平横线的按钮来打开菜单（即便他们可能还会经常忽视这一功能）。但这可不是move icon能做的事。这种不一致性会伤害用户，让他们想不起已经用它做了什么。

作为替代，我们推荐：

• 用点击拖动item本身取代点击特定的icon。
• 在菜单按钮上显示“菜单”文字，而不是单独放置一个hamburger menu。
  

总结

通常不推荐太过离经叛道的模式。最好是遵从“疑似”最佳的实践，了解其他iOS App的一致性与使用习得常识，这样才能最好地满足用户的期待。无论使用任何指南或风格设定，进行可用性测试可以证实或反证指南在你自己的设计中是否好用。通过对人们使用这些设计进行观察，我们见证了足够的案例，证明为什么不推荐这四种模式。