在本文中，我想专门研究响应式导航的问题。我们将首先讨论信息体系结构，然后讨论导航的目的，最后我们将讨论随着时间的推移效果很好的三种响应式导航模式。
信息架构挑战
在移动优先世界中，或至少应该受影响的第一件事是内容和信息体系结构策略。如果我们的应用程序主要是为了简化任务和共享信息，那么我们必须首先关注它。
整个行业经历了巨大的趋势和日益复杂的导航结构，但是响应式网页设计迫使我们重新考虑这种复杂性。为了保持有效，我们需要保持多少导航位置？一个应用程序确实需要几种不同类型的导航，还是仅需一种就可以正常工作？您会发现大多数响应式导航模式迫使我们简化和集中精力，这是移动优先方法的好处。
在创建导航时，有两个问题要问：
- 您是否痛苦地清楚了每个标签的含义，并且访客对它的价值主张（有时称为“ 信息气味 ”）是否清晰？
- 如何尽可能降低导航的复杂性？如果您的导航结构深七个级别，那么应对这一挑战的人就不多了。
- 您如何确保整个分辨率适应过程中导航都不会丢失？
- 您是否进行了彻底的测试，以确保导航与用户访问网站的目标相符？
导航的目的
让我们花点时间思考一下导航的目的。这似乎很基本，但是我看到太多的应用程序的设计师忘记了这些重要原理。我读过的最好的文章来自十年前Derek Powazek写的一篇文章（这表明问题的核心保持不变）。他写：
导航也分为三个部分，用于与用户交流其过去，现在和将来。任何良好的全局导航方案都应该一目了然地回答每个用户在任何页面上都想到的前三个问题：
- 我在哪里？（当下）
- 我可以去哪里？（未来）
- 我去哪了 （过去）
我们必须重新审视这些原则，因为我看到大多数响应式导航解决方案对这些原则的处理都不一致。大多数解决方案都很好地处理了“我可以去哪里？”这个问题，但是大多数网站甚至都不会在响应式解决方案中显示用户当前所在或去过的地方。当您调整我们将要查看的某些模式时，请确保将它们模制以满足这些重要条件。
斯蒂芬妮·林（Stephanie Lin）刚刚发表了一篇名为“ 现代航行规则 ”的文章，对本文进行了很好的补充。她介绍了导航中要考虑的重要交互设计组件。
响应式导航的首选模式
请记住，我们今天有很多用于响应式导航的选项，但这是我对最佳模式的看法。布拉德·弗罗斯特（Brad Frost）为我们提供了所有服务，并在他的网站“ This Is Responsive”上列出了大多数（即使不是全部）这些模式。他还写了两篇有关这些模式的文章：“ 导航模式 ”和“ 用于响应式设计的复杂导航模式 ”。
1.“很少做”模式
在UX London 2017网站上已很好地说明了这种模式。这是在小视口中的外观。
为什么有效
我喜欢这种模式，因为它从根本上使导航成为优先事项，并且不会将导航隐藏在任何渐进式披露之后。大多数响应式导航模式都涉及逐步披露，尽管披露是一个不错的选择，但只有在没有更好的选择时才应采用披露。我同意尼尔森·诺曼集团（Nielsen Norman Group）在此问题上的看法：如果可以显示导航，请显示它。没有人访问此网站，不必怀疑导航在哪里。一个额外的好处是，它没有客户端依赖性，因此您可以保持较低的依赖性并减少故障点。
但是，对于许多响应式应用程序来说，这是很难的。首先，它不能很好地处理复杂的导航。如果一次显示的应用程序中需要多个级别，则此模式不适合您。另外，它可能会占用应用程序中的许多重要垂直空间，因此请确保您可以像UX London网站一样实现它，并确保分配的空间受到控制。
2.多级切换
大多数应用程序可以脱离两个级别的导航，而我发现这是我的许多实现的最佳选择。在小型视口中，此模式使用户可以轻松切换小节并查看其中的内容。白宫的网站就是一个现代的例子。
为什么有效
它可能不是最华丽的解决方案，但我发现它非常稳定。这种模式对我需要支持的大多数导航都适用，并且可以有效地处理简单的两级导航结构（在大多数情况下，我很乐意超出此范围）。另外，我们必须始终逐步构建这些解决方案，以便即使支持它们的代码失败，它们也可以正常工作。
我曾经使用FlexNav来实现此效果，但是该项目已被其所有者放弃。一个有前途的替代方法是SmartMenus，但是我还没有使用过。如果您对纯CSS版本感兴趣，请查看CSS Script的代码示例。
3.简单切换
这是另一个不错的选择，实际上是以前模式的一种变体。在这种情况下，我们不需要多个级别，但是导航项仍然太多，以至于不允许“很少做”模式。在星巴克的网站上可以找到一个例子。
为什么有效
使用一些清晰的图标和颜色，此选项可以很好地实现，因为它的实现和使用非常简单。这种模式的变化会将内容压低或重叠，我认为两者都是可以接受的。如果您想要一个好的脚本，请查看Responsive Nav。
请记住，您不一定必须在响应解决方案中支持多个级别。例如，世界野生动物基金会在较高视口分辨率下的导航有一个下拉菜单，但是在最低视口中，它只是进行切换，顶层链接转到着陆页，其中显示了剩余的导航项。您还可以提供其他导航方式，包括面包屑，这对于任何视口大小都可能是有用的补充。
荣誉奖
如上所述，您可以从今天选择许多方法来满足项目的需求。即使我最喜欢以上三个，也有另外两种可能性。
画布外
这可能是最受欢迎的，但是某些实现比其他实现更好。它可以很好地完成，并且如果您需要脚本，我使用MMenu的效果很好。
优先加
在过去的一年左右的时间里，这已经蒸蒸日上，并且在某些情况下也可能很好。我在水平导航时间较长的网站上使用了它，以避免在视口缩小时过早隐藏菜单项。此解决方案的唯一大问题是，它迫使您对最重要的内容进行假设，因此请小心。我为此使用了PriorityNav.js脚本，并且运行良好。
可怕的汉堡图标
我简直无法谈论响应式导航，更不用说围绕汉堡图标的争论了（响应式“神秘肉”导航指示器还有其他变体）。真正的问题是：图标本身传达了足够的含义，还是需要文本指示符？辩论本质上是关于汉堡图标的普遍性和可识别性。对我来说，很少有图标具有普遍清晰的含义，而没有某种文字来支持它们，而汉堡包图标只是为什么最好不要仅依赖图标的另一个示例。问问自己，是否值得通过不包含访问者来使访客感到困惑，还是我应该仅仅包含它以增加被理解的可能性？我倾向于添加文字指示符。记住要始终评估应用程序的上下文，以回答此类问题。
如果您想了解更多，这里有一些谈论这个问题的文章：
- “ 显而易见总是赢家，”卢克·沃布洛夫斯基
- “ 作为出色用户体验的一部分的图标，” Smashing Magazine的Nick Babich
- “ 汉堡菜单和隐藏的导航按钮UX度量标准 ”，尼尔森·诺曼集团（Nielsen Norman Group）的卡拉·珀尼丝（Kara Pernice）和拉卢卡（Raluca Budiu）
- “ 测试汉堡包图标以获取更多收入 ”，CXL，Peep Laja
结论
好消息是，响应式应用程序中处理导航的选项比以往任何时候都多。只要您坚持明确的信息体系结构设计，测试和可靠的模式，就可以确保访问者现在和将来都可以轻松使用您的网站。下一步是开始尝试这些和其他模式，以了解哪种模式最适合您的特定应用程序。行为和需求会随着时间而变化，因此请不断重新评估您使用这些方法的方式。Smashing Magazine上的另一篇文章“ 复杂网站上的响应式导航 ”提供了案例研究和代码，以使您走得更远。
感谢Ben Callahan和Jacqui Olkin对本文草稿的反馈。
