设计完美的手风琴

有时我们甚至不考虑就使用这些模式，这是有充分理由的：每次遇到界面问题时都想出一个全新的解决方案既费时又冒险，因为我们只是不知道有多少实施一个新的解决方案需要时间，以及它在可用性测试中是顺利成功还是惨败。

设计模式非常有用，主要是因为它们可以节省时间并更快地为我们提供更好的结果。 我们不需要将它们完全按原样应用于我们遇到的每个问题，但我们可以在它们之上构建，利用我们的经验来指导我们的决策，因为我们知道它们在其他项目中工作得相当好。

在过去的几年里，我花了很多时间与多家公司合作，尝试各种方法并在可用性测试中研究它们。 本系列文章是对自始至终所做的观察和实验的总结。 系好安全带：在这个关于 SmashingMag 的新系列文章中，我们将研究从轮播到过滤器、计算器、图表、时间线、地图、多列表、全能定价计划一直到座位选择的所有示例在航空公司和电影院网站上。 但在我们开始处理复杂的界面问题之前，让我们先从看似简单明了的东西开始：手风琴。

手风琴的准系统

手风琴可能是响应式设计中最成熟的主力，这是有充分理由的。 对于渐进式披露来说，这是一种非常有用的模式——突出显示某个部分的重要细节，并在必要时通过点击或点击来揭示更多细节。 因此，设计保持专注并首先显示关键信息，而其他所有内容都可以轻松访问。 事实上，如果您遇到任何类型的问题——太多的导航选项、太多的内容、太详细的视图——一个很好的起点是探索如何利用优秀的手风琴来解决这个问题。 通常情况下，它的效果出奇的好。

然而，即使是像手风琴一样可预测和经常使用的组件也有很大的解释和歧义空间。 现在，不要误会我的意思：上下文很重要。 用于导航的手风琴将需要与问答部分不同的方法。 但是在所有不同的情况下，我们必须彻底考虑两件事：手风琴的视觉设计和交互设计，以消除所有的混淆和误解。

现在，如果我们更仔细地研究一下手风琴的准系统，就会不难看到它的所有原子元素。 手风琴始终包含类别标题、展开和折叠状态、指示展开的图标以及它们之间的间距。 类别展开后，图标应更改以指示正在折叠。 但是，如果用户在另一张卡片打开时点击折叠的卡片怎么办？ 扩展卡是否应该自动关闭？ 如果不能显示所有项目怎么办——用户是否应该自动向上滚动？ 让我们一一仔细研究这些以及相关问题。

选择一个图标来表示扩展

现在，让我们开始吧。 我们知道什么？ 好吧，显然，在大多数从左到右的界面中，类别名称也将左对齐。 假设像许多手风琴一样，子项目将在两个部分之间滑动，你会选择什么图标来传达这种行为？ 一个向下的箭头，一个向右的箭头，一个向下的 V 形，一个加号，一个带圆圈的加号——也许完全不同？

根据我的经验，图标的选择似乎并不重要，只要它在同一个 UI 中没有过多的含义。 例如，您可能会使用带圆圈的加号来表示定价计划中的扩展、缩放和两个项目的捆绑——这可能会引起混淆。 但是，在手风琴的上下文中，用户似乎明白，如果某些导航项有图标，而其他部分没有，则表明单击或点击时可以使用更多内容。 我们没有发现任何迹象表明一个图标比其他图标更容易识别。 但是，这并不意味着某些选项可能不会比其他选项引起更多的混乱。

例如，Slack 使用指向右侧的箭头，尽管手风琴项在类别标题之间垂直滑动，而不是从右侧滑动。 现在，在这一点上值得问一下图标的方向应该有什么目的？ 它可能应该作为移动方向的指示器，或者更具体地说，一旦点击或单击图标，用户的视图将被移动到哪里。 例如，在 iOS 上的 Apple Mail 中，指向右侧的 V 形表示用户视图从左到右的移动。

在图标的方向和用户视图的移动之间进行映射似乎是合理的，但由于不同的界面表现不同（神秘的图标经常与用户玩心理游戏）并不是每个人都会期待这种行为。 所以最后，作为设计师，你做什么并不重要：无论如何，你将无法满足某些用户的期望。 在设计时，我们倾向于专注于我们正在设计的内容，但即使我们的 UI 非常一致，我们的用户也会受到他们在我们从未见过的网站上的体验的影响而产生期望。 因此，关键是尽可能保持弹性，并在未达到预期的情况下提供简单、直接的恢复。

因此，回顾一下图标的选择，如果手风琴项目垂直滑入，直觉上使用上面列出的任何图标似乎都是安全的，除了指向右侧的图标。 此处要考虑的唯一问题是，如果您选择的图标在不同的上下文中已经具有其他含义，例如，如果您使用加号图标突出显示定价计划中捆绑交易的部分（其中加号不可点击），然后使用完全相同的加号图标用于手风琴。 在这种情况下，最好避免将完全相同的图标用于不同的目的，因为这可能会引起混淆。

那么这一切都清楚了吗？ 嗯，不是真的。

让我们考虑一下预期的交互。 虽然箭头和 V 形通常用作指示方向变化的提示，但加号表示添加和扩展。 在这两种情况下，更改可能以多种方式发生：点击图标会导致内容上方出现导航项目的覆盖，或者项目垂直（而不是水平）滑入。 到目前为止，一切都很好。

然而，当用户登陆一个页面时，最初他们不知道他们是否登陆了一个带有跳转到页面某些部分的链接的长滚动页面，或者只是一个“常规”网站，其部分单独存在页。 很多时候，向下的箭头会触发跳转到页面内的部分，而不是扩展导航选项。 用户可能在过去迷失了方向，被带到长页面的一部分，然后返回到页面顶部，并从那里继续。

因此，如果您选择使用箭头，您最终可能会看到一些用户希望向下滚动到页面的该部分，而不是看到子项在类别之间滑动。 因此，雪佛龙似乎是一种更安全、更可预测的选择。 如果您选择使用它，则在折叠状态下将其指向下方，并在展开时将其指向上方。 对于加号图标，您可以在减号图标或关闭图标之间进行选择。

那么，作为设计师，这一切对我们意味着什么？ 首先，如果手风琴项目应该从左到右水平滑入，则使用指向右侧的箭头是安全的。 其次，如果手风琴项目应该从上到下垂直滑入，则 V 形向下（不是箭头！）或加号图标可能会很好用。

考虑到这一点，图标的选择应该是一个非常简单的决定。 但根据该图标与类别标题的接近程度，它也可能会引起混淆。 现在，在选择该图标的位置时，我们需要考虑哪些选项？

选择图标的位置

选项！ 不管您选择了哪个图标，您可以选择将其放置在 a) 类别名称的左侧或 b) 其右侧，或 c) 将图标沿整个导航项栏的右边缘对齐，间距出图标和类别名称。

职位重要吗？ 实际上确实如此。 根据 Viget 的“Testing Accordion Menu Designs and Iconography”，一些用户倾向于专注于点击图标，而不是整个导航栏。 发生这种情况的原因很简单：在过去，一些用户可能已经被手风琴的替代实现“烧死”了。 在某些网站上，类别标题不会触发扩展，而是直接进入类别。 在其他实现中，点击导航栏不会导致扩展，也不会跳转到类别——它绝对什么都不做。

虽然我们当然会将整个区域设计为命中目标，但由于并非每个导航都有这种行为，一些用户在实际点击之前不会知道您的导航是“坏的”还是“好的”之一在它上面（或悬停在它上面）。 由于悬停并不总是可用，点击图标似乎是一个更安全的选择——点击图标几乎总是会触发预期的行为。 这是设计手风琴时需要了解的重要细节。

在各种界面和实现中，似乎将图标放在类别标题的右侧，用户选择关注图标的频率高于将图标放在左侧（用户单击类别的标题或空白处）酒吧）。 但是，一些用户仍然倾向于选择图标。 因此，为了以防万一——至少 44×44 像素大小，让图标足够大以方便点击是一个不错的决定。

左对齐、右对齐还是右对齐？ 好像没那么重要。 但是，如果您有一组手风琴（可能生活在导航菜单中），类别标题的长度变化很大，那么在许多部分切换手风琴状态将需要比从上到下沿着导航栏运行稍微更多的关注. 只是鼠标指针或手指必须一直重新定位才能点击那个花哨的图标！ 此外，如果图标是右内联的，则在窄屏幕上，手指需要穿过导航区域，从而混淆视图。 图标位于栏的右边缘，此问题将得到解决。

但如果图标与栏的右边缘对齐，我们仍然需要注意不要将其放置在离类别名称太远的位置。 在视觉上，扩展与类别相关应该是显而易见的； 因此，在不同的视口中，图标的位置可以改变以保持视觉连接明显。 此外，在更宽的屏幕上，图标可能会稍微变大。 对于一组手风琴来说，这个选项似乎更可取，但对于单个手风琴来说并没有太大的不同——好吧，除非你的数据证明不是这样。

为手风琴设计交互

然而，即使所有这些细节都被排除在外，这种互动仍然会引发一些问题。 假设类别标题左对齐，图标与栏的右边缘对齐。 继续上面的讨论，当用户点击类别名称或图标或两者之间的空白区域时会发生什么？ 他们应该都触发扩张还是应该服务于不同的目的？

好吧，我们可以确定一件事：当用户点击图标时，他们可能期待某种扩展，因此点击图标肯定会提示扩展。 但是，可以单击类别标题以直接跳转到类别或以扩展为目的。

如果类别标题触发了扩展，我们肯定需要在子下拉菜单中提供指向该类别的链接，让用户直接跳转到该部分（例如“所有项目”）。 这意味着用户从首页到某个类别的旅程可能会引起混淆，因为他们不希望在单击类别标题时需要额外点击。 但是，这种情况下的恢复是显而易见的，并且不会真正强制用户恢复以前的状态，因为他们可以立即继续。

如果手风琴中指向类别的链接很明显，则不会造成干扰，而跳转到类别而不是展开导航项然后返回可能会造成干扰。 这就是为什么同时让图标和类别标题触发扩展可能更合理的原因。 这种方式不那么突兀。 这种交互是否也应该发生在类别标题和图标之间？ 一些设计师可能会争辩说，当用户在浏览网站时点击该区域时，他们可能不希望扩展，而是希望“锚定”鼠标指针以开始在页面上滚动，因此感觉很混乱。 当然，这是可能的，但如果用户选择打开导航菜单来探索导航选项，这不太可能发生。

手风琴通常用于卡片，并且根据视口的宽度，卡片可能会很宽，因此虽然有些用户会拼命尝试点击图标，但您的一些用户会习惯于通过点击空白区域来折叠和展开卡片在酒吧。 其他用户将习惯于完全没有任何用途的空白区域，并且会忽略它。 只有少数人会期望该栏用作该类别的链接。 在我们的测试中，事实证明，让空白空间触发扩展并不那么令人困惑，而不是 - 好吧，坦率地说，其他任何东西，所以这也是我们选择使用的。

但是，如果您确实希望类别标题直接链接到类别怎么办？ 一个想法是通过使用两个视觉上独特的元素来“暗示”元素的边界来提高清晰度——例如，图标和类别标题的背景颜色不同（参见上面的示例）。 在我们的实验中，我们没有注意到行为和期望的任何变化——有些人仍然会点击该类别并想知道发生了什么。 同样，在扩展的手风琴中链接该部分似乎是一个更安全的选择。

够好了？ 好吧，我们还没有到那里。 如果用户点击图标进行扩展但屏幕上没有足够的空间来显示所有子项怎么办？ 您团队中的某个人可能会建议自动向上滚动页面，以确保扩展区域显示在屏幕的最顶部。 这是个好主意吗？

每当我们试图从用户手中夺走控制权时，都必须对这个决定进行彻底的测试和考虑。 也许用户有兴趣一次查看多个部分，并希望在这些部分的内容之间快速跳转。 与其让用户对自动滚动或跳跃行为感到疑惑，然后回滚以恢复之前的状态，不如让事情保持原样，让用户做出决定，因为他们可以向下滚动如有必要。 没有多少用户会期望跳转到顶部——不中断流程或者可能有一个永久链接到该部分（如果它真的很长）似乎是一个更好的选择。

然后另一个问题出现了：如果一个部分已经展开，并且用户点击另一个部分，第一个部分应该折叠还是保持原样？ 如果第一部分自动折叠，但它不是用户所希望的，他们总是可以再次打开它，但他们将无法同时扫描或比较这两个类别。 如果该部分保持扩展，他们将不得不主动关闭他们不需要的类别。 这两种选择似乎都有合理的用例。

手风琴的性质要求自动折叠，但就可用性而言，它可能不是最佳选择。 对于有许多项目的手风琴，我们倾向于将部分扩大，因为面板同时关闭和打开而发生的跳跃太吵了。 因此，或者您可以提供“全部折叠”/“全部展开”按钮，这在设计日程表或详细表格时非常有用。 如果没有那么多项目，则默认情况下可以折叠该部分，因为跳转将是最小的。 （请注意，对于水平手风琴，该部分肯定会折叠 - 保持它打开是没有意义的。）

然后还有别的东西。 不管图标的选择还是它的位置，当手风琴展开时，应该很容易立即折叠它。 这种交互不需要鼠标光标或手指的任何额外移动——就像任何其他隐藏和显示交互一样。 这意味着折叠和展开的图标在激活时当然应该改变，但它的位置应该保持完全相同，允许即时切换手风琴的状态。

包起来

唷，这是对一个看似明显的设计模式的冗长检查。 那么，我们如何设计出完美的手风琴呢？ 我们选择一个表示扩展的图标（V 形向下或加号图标），使其足够大以便舒适地点击并将其放置在栏的右边缘。 整个导航栏触发扩展——在栏周围有足够的填充来切换状态和到手风琴类别中类别主页的链接。

如果我们确实选择使用 V 形，点击时方向应该会改变，如果它是加号图标，它可以很容易地转换为“-”或“x”来表示折叠。 为了使交互更加清晰，我们可以使用微妙的过渡或动画来滑入和滑出类别项目。

当然，您的解决方案可能非常不同，因为您的上下文也可能非常不同，因此，如果您正在寻找替代解决方案，您会在下面找到我们在设计手风琴时经常提出的一些问题。

手风琴设计清单

1. 你会选择什么图标来表示扩展？
2. 你会选择哪个图标来表示折叠？
3. 你将把图标放在哪里？
4. 您如何设计类别标题？
5. 您如何指示折叠和展开状态（在图标之外）？
6. 如果用户点击类别会发生什么？
7. 手风琴是否应该包含指向该类别主页的链接？
8. 如果用户点击空白区域会发生什么？
9. 选择另一个部分时，展开的部分是否应该自动折叠？
10. 如果没有足够的空间来显示所有项目怎么办？
11. 你应该有一个“全部折叠/全部打开”链接或按钮吗？

像手风琴一样看似成熟且可预测的组件所需的考虑水平结果证明是设计实验和可用性会议几乎永无止境的故事，因为该组件的外观和交互只有少数既定准则。 虽然制作一个易于使用的手风琴并不难，但设计一个普遍理解的手风琴却不是那么容易。 因此，用户经常会因为他们的期望不匹配或者因为交互打断了他们的流程而感到迷茫。 我们的工作是减少摩擦并确保它尽可能少地发生。 通过宽容和有弹性的设计，我们可以做到这一点。

也许您的经历与文章中提到的经历截然不同？ 在本文的评论中让我们知道！ 此外，如果您有其他想要了解的组件，也请告诉我们——我们会看看我们能做些什么！

敬请关注！

这篇文章是关于响应式设计模式的新系列的一部分，在你真正的 Smashing Magazine 上。 我们将每两周在该系列中发布一篇文章。 不要错过下一个 - 在花哨（或不那么花哨）的日期选择器上！ 啊，对涵盖所有模式（包括上述模式）的（印刷）书感兴趣？ 在评论中也让我们知道——也许我们可以考虑将所有这些模式组合成一本书并在 Smashing Magazine 上发布。 继续摇滚！