设计完美的手风琴折叠面板吧！

　　设计模式：这是一个总会引起敬畏感也或许是怨恨感的几近神秘之词语。作为设计师的我们倾向于把设计模式看作是可以被机械地应用到各种环境中的那种既通用又现成的解决方案，但这么做通常没经过适当地考虑。导航怎么搞?就用Off-canvas吧!(ps. Off-canvas指的是抽屉式滑动导航设计模式)金盒特价的展示怎么搞?就用Carousel吧!(ps. Carousel是用于内容循环显示的jQuery旋转木马插件)你慬的。 甚至有时我们会想都不想就去使用这些设计模式，对此情形有个很好的理由是：每次遇到界面问题时，我们都要想出一个全新的解决方案的话是既费时又冒险的，因为我们确实不知道需要多少时间来实现一个新的解决方案，以及它会在可用性测试中是会顺利地成功还是悲惨地失败。 设计模式也许是非常有用的，主要是因为他们能节省时间，更快地让我们获得更好的结果。我们不必把它们完全应用到我们遇到的每一个问题上，但是我们可以将想法建立在他们之上，利用以往的经验来让决定更加明智，因为我们知道这些设计模式曾在其他项目中运用得相当好。 在过去的几年里，我用了很多时间与许多不同的公司合作来尝试各种方法，并在可用性测试中研究它们。这一系列文章都是在观察与实验的整个期间内写出的总结。各位!请坐好咯：写在SmashingMag网站上的一系列新文章中，我们将从carousel、过滤器、计算器、图表、时间轴、地图、多列表单、全能的定价计划一直到在航空公司和电影网站上选择座位等各个方面进行案例研究。在此之前让我们先来看看那些复杂的界面问题，就从看似简单又平淡无奇的手风琴折叠面板开始吧!

　　手风琴折叠面板的结构

　　有一个很好的理由可以说明手风琴折叠面板大概是响应式设计中最成熟的主要设计模式。这是一种用于渐进展开信息的极其有用的模式，突出显示某部分的重要细节，并在必要时通过点击或敲击来展现更多的细节。因此，当其他所有内容都很容易访问时，设计应首先保持专注于显示关键信息。事实上，如果你遇到了任何问题之一太多的导航选项, 太多的内容, 太详细的视图，那么一个好的起点将会是探索如何利用好排序的手风琴折叠面板来解决这些问题。

设计手风琴折叠面板有多难? 嗯，你得考虑很多事情。这是一个在Schoolfinder上很好的例子。

　　然而，即使是这样一种可以预见的并经常被使用的手风琴折叠面板组件，也有大量的不明确并需要解释的地方。现在，不要误解我的意思:环境很重要。用于导航的手风琴折叠面板与问答环节相比则需要采用不同的设计方法。但在所有不同的环境中，为消除所有的混淆和误解，我们必须仔细考虑两件事: 手风琴折叠面板的视觉设计以及交互设计。 现在，如果我们更仔细地研究手风琴折叠面板的结构，那么要看到其所有的元素并不难。一个手风琴折叠面板常常包含分类标题，一种展开的情况及一种折叠的情况，一个提示可展开的图标，还有他们彼此的间隔。一旦分类被展开了，那么图标则会改变为指示可折叠的状态。可是，如果用户在一张卡片处于打开状态时再去单击展开另一张折叠的卡片会怎样?那个展开的卡片应该自动收起来吗?或者不是这样?如果不是所有的项目都能显示出来，那么用户要查看更多信息的话是否应该让其自动地向上滚动显示呢? 让我们一个一个地仔细看看这些相关问题。

　　Nsb.no上的一个关于挪威旅行计划的经典手风琴折叠面板案例，带有一个与横条右边缘对齐的图标以及整体被用作触发展开功能的横条。

　　选择一个图标来表示扩展

　　现在，就让我们开始吧! 我们知道什么? 恩，很明显，在大多数从左到右布局的界面中，类别名称也将是左对齐的。假设子条目会在两个部分之间滑动，正像许多手风琴折叠面板那样，你会选择什么图标来表达这个行为?是一个向下的箭头?还是一个向右的箭头?是一个向下的V形图标?或是一个加号?亦或是一个带圆圈的加号?也许全都不是?

　　Zvv.ch 结合了两个水平的带有相同图标 (带圈加号) 的手风琴折叠面板，其中之一表明旅行选项，另一个则表明起点与终点间经过的车站，他们二者用于相同的用途 (展开) 而且看上去很相似。他们清晰地表达出图标以及可预期的行为所既定的用途。

　　以我的经验看，图标的选择并不重要，只要其没有在相同的界面中包含不同的含义。例如，你可以用带圆圈的加号来表示展开、缩放、一个定价计划中一组交易的两个项目，那样也许会带来混淆。然而，在手风琴折叠面板的环境下，如果一些导航项有图标，而其他部分不具有图标，用户似乎能理解这就是一种符号，其表明在敲击或点击时就会有更多的内容呈现。我们没有发现任何迹象表明某个图标会比其他图标更容易辨认。然而，这并不意味着一些选择可能不会比其他选择引起更多的混淆。

　　Ableton.com使用了加号既表明一组交易(在上面)又表明展开(如果你向下滚动了页面)。面对这些有着多重意义的图标，会感到些许混淆了，因为用户要么会期望当点击上面的图标时是展开功能(实际上不会发生)，要么会认为当点击下面的加号时不会有交互作用(实际上是展开功能)。 例如，Slack使用指向右方的箭头，尽管手风琴折叠面板项目垂直于类别标题之间滑动，而不是从右边。现在，有必要问一下图标的方向应该是什么?它也许应该作为移动方向的指示器，或者更具体地说，当图标被点击或敲击时用户的视线将被移动到的地方。例如，在iOS上的苹果邮件中， V形图标正确地映射了用户从左到右视线的移动。

　　

　　在Slack中，定价计划在手机上表现为带着指向右边的V形图标并收起的手风琴折叠面板，而这一运动是从上到下发生的。

　　例如，在iOS上的苹果邮件中， V形图标正确地映射了用户从左到右视线的移动。

　　在图标的指向与用户视线的移动之间进行映射似乎是合理的，但是由于不同界面的行为方式不同(有些神秘的图标经常与用户玩智力游戏)，并不是每个人都期望这种行为。所以最后，你作为设计师做了什么并不重要，不管怎样，你都无法达到一些用户的期望。在设计时，我们倾向于关注我们正在设计的东西，即使我们在ui设计规范中是始终如一的，我们的用户也会伴随着受到他们在我们从未见过的网站上的体验所影响的期望。因此，关键是尽可能地保持弹性，并提供一种简单、直接的恢复方式，以防预期无法实现。

　　

　　加号图标可能有不同的含义。在 Leica上,加号触发后会打开用来显示产品图片的弹窗。一些用户可能不期望这种行为。在这里，用一个放大镜缩放图标来表达的话可能不会那么模糊不清。

　　那么回顾一下关于图标的选择问题，若是手风琴折叠面板项目是垂直地滑动，从直观上看除了指向右边的图标，使用上列提到的任何图标似乎都是安全的。这里唯一需要考虑的问题是，如果您选择的图标已经在另一个环境中被赋予了另一个含义例如，如果您正在使用一个加号图标来突出一个定价计划中一组交易的部分内容 (这里的加号是不可点击的)，然后恰巧使用了相同的加号图标在手风琴折叠面板上。在这种情况下，最好避免在不同的用途中使用完全相同的图标，因为它可能会导致混淆。 那么一切疑惑都解开了吗?好吧,其实不是。 之后让我们考虑一下预期的交互行为。通常箭头和V形图标用作指示方向变化的提示，而加号则用来表示添加和扩展。在这两种情况下，变化会以不同的方式发生:在图标上的点击会导致出现覆盖在内容上方的导航项，或者是垂直滑动的项目(不是水平的)。到目前还好。

　　在tifwe.org的导航菜单中看到箭头时，用户会期待什么行为? 很明显，导航项右边的图标表示子菜单，而设计充分利用了可用空间。类别标题是一个直接跳转到类别页面的链接，而箭头提示展开子菜单。

　　然而，当用户在页面上登录时，开始时他们并不知道自己是登录在了一个有着可以跳转到页面某些部分的链接的长滚动页面上，还是仅仅一个各部分位于自已单独页面的常规网站。通常，指向下的箭头会触发跳到页面内部分的行为，而不是扩展导航选项。很有可能，用户在过去会迷失方向，因为会被带到一个长页面的某个部分，接着再返回到页面的顶部，然后从那里继续。

　　图标通常模棱两可。在Qso.com上，用户如何确定点击屏幕底部的按钮是会将该区域扩展成手风琴折叠面板还是向下滚动页面?在这个案例中，用户视线在页面上会被向下滚动。这可能是一个问题，因为V形图标通常表明展开。

　　因此，如果您选择使用箭头，您最终会看到相当多的用户会期望可以滚动页面到某个部分，而不是看到子条目在类别之间滑动。因此，V形图标似乎是一个更安全、更可预期的选择; 如果您选择使用它，那么在收起的状态时将它指向下，并在展开的状态时将它指向上。对于加号图标，您可以在减号图标或关闭图标之间进行选择并与其搭配。

　　在 Papillons De Nuit上的箭头。当点击页面顶部的箭头和页面右侧的箭头时，您希望发生什么? 顶部的箭头作为提示(点击不会发生任何行为)，而右边的箭头则将用户视线滚动到页面的各个部分。并不是每个用户都期望这种行为。

　　那么，作为设计师，这对我们来说意味着什么呢? 首先，如果手风琴折叠面板的项目是要从左向右水平滑动的，则使用指向右的箭头是安全的。其次，如果手风琴折叠面板的项目是要从上到下垂直滑动的，要么选择指向下的V形图标(不是箭头!)，要么选择一个加号图标也可以达到好效果。 考虑到这一点，选择图标应该是一个相当直接的决定。但还还取决于图标与类别标题的位置关系，因为这也可能会导致混淆。现在，在决定该图标的位置时有哪些选择呢?

　　选择图标的位置

　　选择啊!不管你用了哪个图标，你可以做如下选择：a)把它放在类名的左边，或者b)放到它的右边，或者c)沿着整个导航栏的右边缘对齐图标，将图标和类别名称分隔开。

　　有时，点击一个文本标签则会引导去一个单独的类别页面，点击一个空白区域则什么都不会发生。这就是为什么，当希望展开时，一些用户会尝试点击图标而不是类别名称或空白区域。

　　这和位置有关系吗?实际上确实如此。根据Viget的测试手风琴折叠菜单设计和图标，大多用户会倾向于明确地专注点击图标，而不是整个导航栏。原因很简单: 在过去，一些用户可能已经被手风琴折叠面板的其他实现方式惹恼了。在一些网站上，类别名称并没有触发展开操作，而是直接指向类别页面。在其他实现方式中，在导航条上的点击不会触发展开，也不会跳转到类别页面完全是什么也不会发生。尽管我们当然会设计整个区域作为一个点击目标区域，但不是所有的导航都有这样的行为，直到他们真正的点击它时(或者在它上面悬停)，大多用户并不知道你的导航是坏的那个还是好的那个。 因为悬停操作并不总是可用的，点击图标似乎是一个更安全的选择点击图标将几乎总是触发预期的行为。在什么场合下设计手风琴折叠面板是一个重要细节。 在不同的界面和实现方式中，似乎将图标放在类别标题的右边比把图标放在左边(用户单击类别标题或空白处的地方)，用户会选择更频繁地关注图标。然而，无论怎样，一些用户仍然会倾向于选择图标。因此, 让图标足够大来获得舒适的点击体验是一个很好的决定,以防万一 至少44×44像素大小。 左对齐,位于标签文字右侧还是右对齐? 这似乎不太重要。但是，如果你有一组手风琴折叠面板(也许存在于导航菜单中)，其类别名称的长度变化很大，那么在许多区域间切换手风琴折叠面板的状态将比仅仅是沿着导航条从上到下来移动切换的情况需要稍微多注意些。只是觉得鼠标指针或手指总须重新定位，才能点击到那个奇特的图标! 另外，如果图标是位于标签文字右侧的，在窄屏幕上，手指需要穿越导航区域，会使视线错乱。要是这个图标定位在导航条的右边缘，那么这个问题就解决了。 但是如果图标是对齐到栏目右边缘的，我们仍然需要注意不要把它放置在距离类别名称太远的地方。从视觉上看，扩展与类别有关系应该是明显的; 因此，在不同规格的视窗中，图标的位置可以改变，以保持视觉上明显是连接的。此外，在更大的屏幕上，这个图标可能会变得稍微大一些。这个位置选择似乎对于一组手风琴折叠面板更可取，但对一个手风琴折叠面板来说并没有多大的差别除非你的数据证明不然。

　　手风琴折叠面板的交互设计

　　然而，即使难得地注意了这些很好的细节，交互仍然会引发一些问题。假设类别标题为左对齐，图标对齐到栏目的右边缘。在以上讨论之后，当用户单击类别名称或图标或中间的空白区域时，会发生什么? 它们是否都应该触发展开，还是应该用于不同的目的? 嗯，我们可以肯定一件事: 当用户点击图标就会期待某种展开行为时，那么点击图标当然应该是可以触发展开行为的。但是，点击类别标题是可以用于直接跳转到类别页面的目的也或是用于展开的目的。 如果类别标题能触发展开行为，我们肯定需要在下拉菜单中提供一个到类别页面的链接，让用户直接跳到那个部分(例如所有项目)。这意味着用户从首页到某一类别页面的过程可能会引起混乱，因为在点击类别标题时，他们不会期望需要额外的点击才能进入类别页面。 如果手风琴折叠面板指向类别页面的链接是明显的，那么就不会感到混乱，然而跳转到一个类别页面，而不是扩展出导航项，然后再返回的流程可能会使人感到混乱。这就是为什么让图标和类别标题全能触发扩展是更合理的原因。这样就不那么突兀了。这种交互是否应该发生在类别标题和图标之间的区域呢? 一些设计师可能会说，当用户在浏览某个站点并点击该区域时，他们可能不希望展开，而是锚定鼠标指针并开始在页面上滚动，因此会感觉很混乱。当然，这是可能的，但是如果用户选择打开导航菜单来浏览导航选项，混乱是不太可能发生的。

　　点击越接近于图标，用户就越有可能期待扩展。不过，这并不意味着，点击越接近于分类标题，他们就越有可能跳到这一类别。

　　手风琴折叠面板通常用于卡片界面中，根据视窗的宽度，卡片可以很宽，因此，当一些用户拼命想要敲击这个图标时，你的另一些用户则习惯于敲击空白区域来收起和展开卡片。其他用户习惯于认为空白区域完全是没有任何目的性的，并将忽略它。只有少数人期望横条部分是作为类别页面的链接。在我们的测试中，证明了有能触发展开的空白区域很少会引发混乱，而不是嗯，坦白地说，除此之外，那也是我们选择的要使用的东西。

　　手风琴折叠面板不必只提供导航项。它还可以显示或多或少的细节内容，例如在PremierLeague.com. 上的一个表或排行榜表。

　　但是如果你想要将类别名称直接链接到类别页面呢? 有一个想法可以带来清晰思路，那就是通过设计两个在元素的边界上视觉鲜明的元素来暗示例如，为图标和类别标题使用不同的背景颜色(参见上面的示例)。在我们的实验中，我们没有注意到行为和期望的任何变化有些人仍然会点击类别名称，奇怪于所发生的事情。同样，在扩展的手风琴折叠面板中加上链接区域似乎是更安全的决定。 足够好了吗?嗯，我们还没做到。如果用户点击图标进行展开，但屏幕上没有足够的空间显示所有子项，该怎么办呢? 团队中的某个人可能会建议自动向上滚动页面，以确保扩展区域显示在屏幕的最顶端。这是个好主意吗? 每当我们试图控制用户的时候，这个决定必须经过彻底的测试和考虑。也许用户有兴趣同时查看多个部分，并希望快速跳转到这些部分的内容。但只要让事物保持原样也许就不会那么突兀，而不该让用户对自动滚动或跳转行为感到奇怪，然后再滚动回去恢复以前的状态，把决定权留给用户，如有必要，他们可以向下滚动。没有多少用户会期望跳转到顶部不要打断浏览流程，又或者是加一个指向某部分的固定链接(如果真的很长)，这似乎是一个更好的选择。

　　在Sony.com上，如果已经扩展了一个部分，此时用户单击另一个部分，则展开的部分会自动折叠。这种行为在网站上不一致，所以用户不能依赖，也不能期望在任何地方都能看到这种行为。

　　然后另一个问题出现了: 如果一个部分已经展开，那么用户点击另一个部分，第一个是该折叠还是保持原样? 如果第一部分自动折叠了，但这不是用户希望的，他们总是可以再次打开它，但是他们不会同时浏览或比较这两个类别。如果该部分保持扩展，他们则必须主动关闭不需要的类别。两个选项似乎都有合理的用例。 手风琴折叠面板的本质要求自动折叠，但在可用性方面它可能不是最好的选择。对于有很多项目的手风琴折叠面板，我们倾向于让之前展开的部分维持扩展状态，因为随着那些同时间自动关闭和打开的面板而发生的跳跃实在太混乱了。因此，做为选择，您可以提供一个折叠所有/扩展所有的按钮，这在设计时间表或详细表时非常有用。如果没有那么多项目，那么该部分可能会在默认情况下自动折叠，因为跳跃幅度并不大。(请注意，对于水平的手风琴折叠面板展开的部分肯定会自动收起保持它的展开状态是毫无意义的。)

　　

　　

　　在《卫报》的网站上，一个v形图标被放在左边，后面是分类标题和空白区域。整个横条都会触发扩展，而分类的主页入口被整齐地显示为手风琴折叠面板项目中的第一选项。

　　还有一些别的东西要提。不要在意图标的选择或它的位置，当手风琴被扩展时，它应该很容易立即折叠起来。这种交互不需要鼠标指针或手指的任何额外动作就像任何其他隐藏和显示的交互一样。这意味着在激活时，折叠和扩展的图标当然会发生变化，但是它的位置应该保持完全相同，这是考虑到手风琴折叠面板的状态是能立刻切换的。

　　总结

　　这是对一个看似显而易见的设计模式的漫长审视。我们选择一个图标来表示扩展(v形图标指向下或一个加号图标)，使它足够大以便能舒服地敲击，并将它放置在横条的右边缘。整个导航条触发扩展在横条周围留有足够的地方来切换状态，以及在手风琴折叠面板目录中添加指向类别主页的链接。 如果我们选择使用v形图标，其方向应该在点击时改变，如果它是一个加号图标，它应很容易转换成一个-或x表示可收起。为了使交互更加清晰，我们可以使用微妙的过渡或动画来体现滑入和滑出类别项。 当然，你的解决方案可能会非常不同，因为你的应用环境可能会非常不同，所以，如果你在寻找另一种解决方案，在下面你会发现我们在设计手风琴折叠面板时总会问的一些问题。

　　手风琴设计检查表1.你会选择什么图标来表示扩展?2.你会选择什么图标来表示收起?3.你会把图标放在哪里?4.你如何设计一个类别名称?5.你如何指示收起和扩展状态(除了图标)?6.如果用户点击类别名称，会发生什么?7.手风琴折叠面板应该包含一个指向类别主页的链接吗?8.如果用户单击空白空间会发生什么?9.当选择另一个部分时，已扩展的部分会自动收起吗?10.如果没有足够的空间来显示所有项呢?11. 你是否应该放一个收起全部/展开所有链接或按钮?

　　对于一个看起来已经建立的并可预测的手风琴折叠面板组件的考虑程度几乎是一个永无止尽的关于设计实验和可用性研讨的故事，因为只有少数几个确定的指导原则用于这个组件的外观和交互。虽然造出一个可达的手风琴折叠面板并不难，但设计一个被普遍理解的手风琴折叠面板并不那么容易。因此，用户经常感到迷失，因为他们的期望没有匹配，或者因为交互中断了他们的流程。我们的工作是减少摩擦和确保这种情况很少发生。有一个包容的并有弹性的设计，我们就能做到这一点。 也许你的经历与文章中提到的完全不同? 请在评论中告诉我们! 另外，如果你想到另一个乐意去谈论的组件，让我们知道，我们会看到我们能做些什么!

*请认真填写需求信息，我们会在24小时内与您取得联系。