重新设计 SGS 的七级导航系统：案例研究

SGS（前身为Societe Generale de Surveillance ）是一家全球服务组织，提供跨 14 个行业的检验、验证、测试和认证服务。 SGS 的网站（连同 60 个本地化网站）主要宣传该组织的核心服务，并提供对大量有用服务、补充内容和工具的访问。 我们的目标是将 sgs.com 从仅桌面版转变为响应式。

这带来了一系列独特的挑战，尤其是在传统导航系统方面，该系统在区域中的深度可达七层（分为两部分），由大约 12,000 个单独的可导航项目组成。

SmashingMag 的进一步阅读：链接

• 设计案例研究：展示以人为本的设计过程
• 适应响应式设计
• 产品设计统一案例研究
• 75个有启发性的案例研究——这就是我们建造它的方式

我们第一次看到和使用 SGS 的导航系统时的自然反应是，由于可导航链接和内容的庞大数量，信息架构 (IA) 肯定必须简化。 然而，考虑到在该项目之前，导航已经针对搜索引擎和 IA 进行了优化，并且考虑到 SGS 为许多行业提供了广泛的服务选择（反映在内容量上），很明显，重构 IA 不会成为解决方案的一部分。

简单地说，导航树的结构必须保持不变。 即便如此，这并没有阻止我们对 IA 进行一些小的调整。 例如，“新闻、媒体和资源”和“SGS 办公室和实验室”被移到顶层，以提高知名度。 对于前者，重要的是更清楚地反映 SGS 定期发布新闻和举办活动。 对于后者，至关重要的是，它以及联系页面可以从网站结构中的任何位置轻松访问。 因此，关键问题是如何让这样一个庞然大物的导航系统在不同视口之间轻松转换同时仍然可用？

制定项目政策

健康的客户-设计师关系对于每个项目的成功都至关重要。 设定明确的期望并提供有效的指导不仅可以确保关键利益相关者始终保持专注，而且随着项目的进展，各方之间的信任也会得到发展。 这个项目绝对是这种情况。 各方之间的合作以及对彼此角色和专业知识的相互欣赏确实非常了不起。

但是，为了确保各方保持专注，我们在启动会议上制定了一些重要的指导方针和要求，我们也可以在这些指导方针和要求中发挥创造力（其中一些是我们坚持的，另一些是客户坚持的）：

• 内容平价。 内容应该可以在每个设备和平台上访问，并且在任何情况下都不应隐藏在移动设备上。
• 性能。 该网站的运行速度至少应比竞争网站快 20%。 这在决定每页应该包含多少信息时特别有用。
• 可访问性。 该网站必须遵守 WCAG 2.0 AA 级可访问性指南。 由于公司的品牌，我们成功地实现了这一目标，除了边缘颜色对比问题。
• 可用性。 内部团队必须广泛验证概念并进行现场和远程可用性测试。
• 不间断的业务。 重新设计根本不应该破坏公司的业务。 显然，任务不是优化公司的服务，而是优化网站，同时考虑到已建立的业务流程。 例如，我们可以自由优化 Web 表单，但 CRM 中的数据结构必须保持不变。

三大挑战

建立了关键指南并且知道导航的重新设计不需要对 IA 进行重大改革，我们将重新设计细分为三个关键但相互依赖的活动集：

• 布局放置。 这主要由内部团队处理，我们提出改进建议并确保任何决定不会对新响应式设计的其他方面产生根本性影响。
• 交互性和可用性。 这些都是与 SGS 的设计团队合作完成的。 通过电子邮件和现场研讨会交流想法，并定期根据用户、利益相关者和整体业务需求进行验证。
• 性能。 这完全由我们处理，因为它更多的是技术挑战，除了让我们快速制作新的响应式网站外，不需要任何战略决策。

布局布局

导航是页面布局的基本元素，无论网站的大小或复杂程度如何。 虽然当您处理如此大规模的导航系统时，屏幕外模式可能看起来很吸引人，但请记住，当导航对用户不可见时可能会出现问题。

SGS 的设计团队最初测试了各种概念，因为他们不仅要评估导航交互，还要与页面的其余部分建立适当的平衡并避免混乱。

决定概念

鉴于网站的复杂性，导航始终保持可见并告知用户他们在树结构中的位置至关重要。 我们不希望在 UI 中将导航分成两部分，而是希望新的导航系统是无缝的（从顶层到底层）。 因此，它必须使用户能够轻松地上下浏览导航树，以及横向浏览主要部分。

为了测试和验证所有这些组合，我们为八个初始导航概念中的每一个开发了一个原型。 原型证实了内部团队已经怀疑的事情：就可用性、维护、跨屏体验、视觉混乱和吸引力而言，最可行的选择是将导航放置在大屏幕的侧边栏中，并显示为小屏幕上的下拉菜单。 本质上，导航模块在功能和视觉上都是独立的，无论屏幕大小如何。

虽然我们将在一分钟内专注于特定的交互决策，但值得指出的是，一旦原型概念经过测试和验证，交互原型不一定要被丢弃。

智能原型

我们总是使用语义、可访问和健壮的标记直接在 HTML、CSS 和 JavaScript 中开发原型，因为这样我们通常能够在设计过程的后期重用初始原型。 这意味着我们新导航系统的初始原型成为最终完整网站原型的基石，其中包括所有页面模板和模块。

在交付完整原型时，我们还确保为 SGS 团队自动生成样式指南。 通过让 SGS 的设计团队考虑设计和开发模块，而不是完整的页面，生成的样式指南将需要很少的持续维护。 样式指南本身引用了所有使用的独特模块，每个模块都包含精确的描述、代码示例和自动生成的指向使用它的页面模板的链接。 我们选择自动化任务和功能的技术是 PHP，但只要输出是语义 HTML，就可以使用任何服务器端语言来实现自动化。 （我们为我们的原型开发了一个特定的文件系统框架，但这是另一个场合的主题。）在本文后面，我们将解释服务器端脚本如何帮助我们维护和测试多个版本的导航。

尽管从语义、可访问和健壮的 HTML 开始是至关重要的，但“内容优先，导航第二”的原则同样重要，因为它可以帮助您考虑任何可能的未来异常。 在这个项目中，“内容第一，导航第二”的规则有一个例外：主页。 根据分析，我们发现导航被视为主页上最重要的元素，这意味着它必须位于页面上的任何核心内容之前。

交互性和可用性

一旦决定设计和开发一个独立的、与屏幕大小无关的导航模块，就该专注于导航交互了。 考虑到我们在设计导航时采用了移动优先的方法，导航模块本身不仅可以自然地在小视口中正常运行，而且还可以轻松扩展以在大视口中工作。

三个互动版本

由于导航的大小和嵌套级别的潜在数量，我们不得不消除一些更常见的移动导航模式作为选项——例如，选择下拉菜单和优先级+模式。 我们专注于对导航的三个交互式版本进行原型设计：滑块、手风琴以及手风琴和滑块。 每个都有其优点和缺点，这自然影响了我们的决定。

手风琴

手风琴可能是移动设备上最常见的模式。 它逐步披露，随着用户在主题或操作中的进展，揭示更详细的信息。 它还确保用户不会不知所措，这就是我们想将其用作基线解决方案的原因。

以下是手风琴的优点：

• 用户对它很熟悉。
• 用户可以展开整个导航树来预览多个选项（毕竟七级导航可能有点让人不知所措）。
• 它可以在没有 JavaScript 的情况下工作，使用:target伪类。
• 开发它很容易。

手风琴的缺点：

• 深层类别的扩展祖先会将当前范围推离屏幕顶部太远，因此需要大量滚动。
• 七级导航需要所选视觉提示的七级，无论是七种基本颜色（灰色）、七级印刷层次还是七级缩进。

滑块

这最初是我们最喜欢的解决方案，但它错过了一个重要元素：允许真正横向浏览主要部分。 如果用户总是从主页开始浏览就不会出现这样的问题，因为他们会越来越熟悉主要部分。 但是，对于登陆导航树深处页面的用户来说，这肯定是一个可用性问题。 例如，登陆第三层、第四层或第五层的用户必须遍历树才能到达联系页面。 无论用户有多积极，遍历七个级别都不是一件有趣的事情。

滑块优点：

• 层次分明。
• 动画很流畅。
• 它遵循移动约定。
• 它相对容易开发。

滑块缺点：

• 无法横向浏览。
• 动画效果不佳。

混合（手风琴和滑块）

我们真的想保持滑块的吸引力，同时仍然允许横向浏览。 因此，我们开发了一种混合解决方案，结合了两种导航模式的最佳元素。 顺便说一句，这也是我们确定的解决方案。

混合优点：

• 可以横向浏览。
• 动画很流畅。
• 层次分明。

混合缺点：

• 它需要一些初步的学习。
• 它的开发很复杂，需要考虑许多活动部件。
• 它有一些性能问题。

如前所述，用户应该能够向上和向下浏览导航树，始终知道他们来自哪里以及接下来导航会将他们带到哪里。 然而，这只是基本交互——为了开发一个可用的导航系统，我们必须解决很多额外的问题。

八种不同类型的链接

除了当前和祖先的导航项在设计上有所不同（谢天谢地，这是一种成熟的做法），我们通过帮助用户了解他们在哪里以及他们正在探索什么，进一步改进了导航和一般可用性。 帮助用户了解当前页面及其父级以及任何相关的子级关系是远远不够的。 还需要采取其他重要行动：

• 能够直接进入父页面；
• 能够预览父级和子级，同时保持原始 URL；
• 快速了解他们当前的浏览位置，同时能够探索导航。
• 快速了解他们在页面上的当前位置。

注意：我们使用面包屑导航来确保用户始终清楚当前页面位置。 因为我们想完全避免跳过关卡，所以面包屑和导航中的信息必须一对一匹配，即使是伪关卡（即没有实际页面的关卡）。

上面的用户需求导致了五种语义不同的导航项，带有额外的帮助链接，允许用户在不离开当前页面的情况下上下遍历树。 您可以想象如此多的活动部件带来的复杂性和相互依赖性。

动画细节

导航中的所有元素都使用 CSS 进行动画处理，每个动画都有两个不同的部分：

• 水平动画关卡，
• 垂直动画包装。

首先，通过更改主包装器的类来切换滑块中的不同树级别。 例如，封闭的导航包装器有一个.depth-0类。 展开顶级项目时，类更改为.depth-1 。 When a second-level item from within that top-level item is selected, the class changes to .depth-2 , and so on. 这会产生一组相当简单的 CSS 规则，这些规则应用于单个元素——滑块中的最高排序列表：

 .depth-1 .l-0.nav-open > ol { left: 0; } .depth-2 .l-0.nav-open > ol { left: -100%; } .depth-3 .l-0.nav-open > ol { left: -200%; }

在上面的示例中， .l-0对应于零级列表项，而.nav-open则在手风琴设置为open时切换。 这意味着open的手风琴列表项中直接子项的有序列表绝对偏移到负左位置。

其次，考虑到每个级别包含可变数量的列表项，任何两个相邻级别之间的转换必须是平滑的。

为了实现这一点，我们确保始终有足够的垂直空间让水平动画顺利运行。 通过检索即将进入屏幕的元素的垂直偏移量来计算和应用高度。 这意味着我们必须考虑总共四种可能的情况，但实际上只需要解决两种情况，每种情况的执行顺序略有不同：

• 短列表项到更长的列表项。 水平和垂直动画同时开始。
• 长列表项到较短的列表项。 导航停止水平滑动后，垂直动画开始。

两个动画同时启动，但第二个动画在 300 毫秒延迟后启动，这正是第一个动画的持续时间（在 CSS 中使用transition-duration属性指定）。 造成这种情况的原因是，当多个图层在“幕后”消失之前重叠时，功能较弱的设备上的动画性能并不理想。 简化的代码如下所示：

 if (newHeight < oldHeight) { heightTimeout = 300; } else { heightTimeout = 0; } setTimeout(function() { $('.l-0.nav-open').css('height', newHeight); }, heightTimeout);

进一步的改进

已经面临一系列复杂的相互依赖关系，我们在测试导航时意识到还有改进的空间。

首先，由于网页字体有时会比页面的其余部分加载稍晚，因此导航中原本应该在一行中的一些文本字符串会在网页字体完全加载之前扩展到第二行。 例如，顶级部分链接“新闻、媒体和资源”在以后备字体呈现时分为两行。

因为一切都必须非常紧凑（因为我们必须为滑动动画使用绝对定位），唯一的解决方案是在加载网络字体后重置受影响元素的高度。 这是使用由 Bram Stein 为 Adob​​e Typekit 和 Google Fonts 开发的 Web Font Loader 完成的。

 WebFont.load({ custom: { families: ['FONT_NAME_1', 'FONT_NAME_2'] }, active: function() { // recalculate things here }, timeout: 5000 });

注意：您是否注意到我们如何使用 5 秒超时？ 在我们的测试中，我们发现这是让它在我们的基准“良好 2G”（每秒 450 KB）连接上工作的最佳点！

其次，因为我们决定有条件地加载导航节点以提高初始加载性能（下一节将详细介绍），我们希望用户知道有多少导航项可用，以防出现延迟在加载导航树的一个分支。 我们通过重复一个类似于文本字符串的占位符背景图像来做到这一点。

最后，在请求导航分支之前，我们在 DOM 中使用 JavaScript 附加占位符代码。 这使 DOM 尽可能干净。

 element.append('<ol class="nav-loading"><li class="nav-placeholder"></li></ol>'); $.get('NAVIGATION_BRANCH_URL', function(data){ // replace the loader with the branch element.find('ol').replaceWith(data); });

表现

如果您还记得，我们在该项目中的主要目标之一是让网站的性能至少比竞争对手的网站好 20%。 我们不仅实现了这一目标，而且在这样做的过程中，我们还帮助 SGS 显着降低了整体页面重量和加载时间。 看一下以下前后统计数据：

您知道 12,000 个链接等于 3 MB 的 HTML 吗？

这是正确的！ 当我们第一次在原型中渲染完整的导航树时，它总共有 3 MB 的裸 HTML。 没有页眉、页脚和内容——只有包含 12,000 个单独链接的导航树。

在重新设计之前，每个页面都包含核心导航树，每个行业页面还包含一个行业特定的导航树，作为一个单独的模块实现。 然而，桌面优化的设计使得核心或行业特定的导航不仅难以在小视口上使用，而且也难以维护。 这就是为什么重新设计的主要目标之一是将树整合到一个单一且易于维护的模块中。

探索提高性能的选项

为了彻底测试导航的三个交互式版本中的每一个，并评估它们的性能，灵活的测试环境是必不可少的。 这将使我们能够快速进行更改，并维护并发版本，以便我们可以轻松地将它们相互比较。

考虑到完整导航树的大小（最多 7 级深度和 12,000 个可导航链接），能够测试导航树的部分以及完整的树本身非常重要。 SGS 的内部开发人员能够从他们的内容管理系统将完整的导航树导出为 CSV 文件，这使我们能够创建一个易于配置的 PHP 函数来输出完整的树或它的一部分，这取决于我们需要什么去测试。

我们的 PHP 函数还简化了导航树结构的 HTML 维护，因为前面提到的链接标记和类名可以在一个地方轻松更改。 使用服务器端语言来避免重复代码听起来很明显，但创建这种类型的环境不仅是一个受欢迎的补充，而且实际上是关键任务，因为它是敏捷实验和测试的先决条件。

有条件地加载链接

我们提到我们必须有条件地加载导航节点以提高初始加载性能。 然后需要回答的问题是，最初应该加载多少导航树，以后应该加载多少，以及何时加载？ 在测试和比较不同导航树分支的权重和大小，以及研究现有直播网站上的用户行为后，得出了一些有趣的结论。

首先，只对一种行业感兴趣的访问者很少访问其他行业。 一旦浏览了他们选择的行业类别，每个访问者通常会继续浏览其他几个页面。

其次（正如我们最初所想的那样），行业特定的分支造成了大部分的性能开销。 当我们完全删除行业分支时，HTML 减少到 70 KB，比 3 MB 好多了！ 尽管如此，这意味着 14 个行业分支中的每一个都在 300 到 500 KB 之间。 当我们进一步分割每个服务分支时，我们发现每个后续级别的平均大小约为 24 KB。

虽然我们知道可以通过优化类名和通过 JavaScript 添加 DOM 节点来进一步减少 HTML（稍后会详细介绍），但我们仍然必须确定在 300 左右启动单个 HTTP 请求是否最好500 KB 或在每个级别发起大约 24 KB 的 HTTP 请求。 最初，似乎每次用户在导航树中进一步向下移动时发送一个 24 KB 的请求会更有益。 然而，考虑到网络延迟通常是网站性能的最大瓶颈之一，这将导致通过网络发送多个 HTTP 请求，这远非理想。 预测任何行业分支的负载也没有任何意义，除非用户通过将鼠标悬停在行业链接上显示意图。

由于导航的复杂性和链接的数量，以下安排提供了迄今为止最好的折衷方案：

• 默认情况下在 HTML 中加载前三个级别。
• 显示意图时使用 JavaScript 加载行业导航，使用mouseover事件检测到。
• 缓存加载的分支以加快连续页面加载的加载速度。

更深页面的逻辑有些不同，因为导航需要在不启用 JavaScript 的情况下访问。 因此，如果用户（甚至是搜索引擎机器人）登陆深层页面，则会发生以下情况：

1. 在 HTML 中渲染前三个级别以及当前页面的祖先分支和页面兄弟，从而允许用户轻松访问父页面、祖先页面和兄弟页面，同时还能够按照相同的逻辑访问网站的其他部分。
2. 用 JavaScript 加载当前分支，并替换最初加载的当前页面的祖先分支。

优化 HTML

如果你真的想优化你的 HTML，所有非必要的项目都必须卸载到 CSS 和 JavaScript。 我们严格修剪除有序列表、列表项及其各自链接之外的所有内容。 所有非必要的链接（即导航辅助）也从 HTML 中删除，并使用 JavaScript 重新插入到 DOM 中（因为无论如何如果没有 JavaScript，它们就无效）。 这些非必要的链接使用户能够做几件事：

• 打开下一个级别（在内部，我们将这些称为“扩展器”）；
• 上升一个级别（我们将这些称为“支持者”——表明缺乏想象力）。

虽然生成的 DOM 仍然很大，但导航辅助工具不再需要通过网络单独传输。

最后，我们进行的最后一项优化是减少类的数量，以及缩短类名的长度； 例如， .very-long-class-name变为.vlcn 。 虽然后者产生了最大的收益，但这种优化很难证明是合理的，因为它通常不会显着修剪 HTML 文件的大小，更重要的是，它会降低代码的清晰度，从而可能使维护更加困难。 但是，即使从 12,000 个列表项中的每一个中删除一个字节，也使其成为一项值得的练习和可接受的权衡。

结果？ 40 KB 左右的初始 HTML（压缩和通过网络传输时为 8 到 9 KB），每个行业 200 到 300 KB 的 HTML（压缩和传输时为 15 到 25 KB）。

结论：边际收益很重要

我们喜欢用体育界的一个类比：将每一件小事改进 1% 会显着提高性能。 这适用于我们在 SGS 项目中所做的事情及其复杂的导航。 通过专注于更精细的细节，对每个细节进行一点点改进，我们显着降低了导航的复杂性并缩短了加载时间，同时保持导航对用户的吸引力和吸引力。 本来可能是一场噩梦和难以破解的难题变成了一个技术和交互相关的解决方案，足够灵活以适应进一步的改进。

最重要的是，不断进行原型设计、研究选项和完善最佳解决方案的设计过程被证明是非常有效的——以至于它为内部团队在开发其他产品时应用相同的基本原则提供了一个强有力的案例在组织中，更不用说它会帮助团队继续完善和优化新的导航系统。 没有一个 Web 项目是真正完整的； 待办事项清单上总是有更多的事情。 这完全没问题，只要我们不断测试、完善并为用户提供最佳体验。