【译】【UX】一个页面可以有多个面包屑导航吗?

原讨论地址

提问

面包屑导航可以让用户在网站中定位,展示了到达当前页面的路径。如果一个网页属于不同的类别,能用多个面包屑导航吗,或者有没有更好的展示方式?

例如一个作家可以有不同的归类:

Writers // Origin // England // William Shakespeare
Writers // Periods // XVI century // William Shakespeare
Writers // Schools // Dramaturgy // William Shakespeare

这时候放多个面包屑导航是正确的做法吗?

评论

#1 这个页面是怎么来的?直接打开还是一步一步点进来的?
比如莎士比亚的页面,是怎么进来的,是从

www.MyWeb.Site/Writers/Origin/England/William%20Shakespeare.php
还是
www.MyWeb.Site/Writers/Periods/XVI%20century/William%20Shakespeare.php
或者就只是
www.MyWeb.Site/pages/William%20Shakespeare_(writer).php
看路径就知道该展示哪一个了吧?

回答 1

面包屑路径只有一条,最好不要打破这个惯例。一般来说用户看到面包屑主要是为了这几件事:

  • 我现在在哪
  • 我怎么来到这儿的
  • 向后导航

如果有多个路径,完成上面几个任务就很麻烦,有的还做不了。

如果想要面包屑路径交互性更好,还想要多个分支,可以考虑下拉菜单。

breadcrumbs1

同级别的其他分类链接放到下拉菜单中,可以方便的导航到其他分类,还能保持页面展示的路径不变。

breadcrumbs2

这种做法也不常用,建议使用前做个用户测试。

回答 1 的评论

我觉得这已经不能叫面包屑导航了。

回答 2

你这种场景就不应该用面包屑。

你的问题已经描述的很清楚了,从ShakespeareWriter中间有多条路径,但是面包屑只有一条路径。

怎么办?
换成 tags,按照你的例子,莎士比亚应该会关联到英格兰十六世纪戏剧标签。

tag

用标签有很多优点:

  • 很容易识别,用户可以不用点击也不用离开当前页面,就直接看到所有的类别。
  • 还可以改进不确定的搜索,用户可以从多个标签中选择一个搜索
  • 标签占用的空间,不会超过原本类别需要的空间

总之标签不但可以提升作家页面的体验,还可以简化用户寻找其他作家的方式。并且用户在线上购物网站,早已经对这个体验很熟悉了。

面包屑最后变成了这样:

Writers // William Shakespeare

用来过滤和加书签的 url 使用类似这样的结构:

example.org/writers?origin=England&Schools=Dramaturgy

回答 3

维基百科已经解决过这个问题了
面向对象编程 举例,右侧的 编程范式 框中,有多个层级的链接指向当前页面。

实际上这已经不是面包屑导航了,而是一个网站地图,同时展示相关的其他类别。根据网站规模,可以适当缩减站点地图的范围,有必要的话,也可以默认隐藏一些分支,可以点击展开。

站点地图的有点是它包含了用户需要的所有信息,让这些信息尽可能的方便访问。如果用户想看波兰的作家,只需要点击一次就行了。此外,网站地图在整个网站任何页面看起来都是内容一致的,因此用户很容易熟悉使用。

用户在读关于莎士比亚的内容时,可能会参考一下网站地图,但是用户对莎士比亚以外的内容感兴趣的时候,就会去认真读网站地图。因此不应该只列出莎士比亚所在的类别,而是列出一些用户可能会感兴趣的其他类别。

什么是关键渲染路径

这是去年看过 pagespeed insights 以后做的一个简单的分享,重新整理发布。

回顾浏览器渲染过程

  1. 加载HTML
  2. 加载资源
  3. 解析
  4. 渲染

页面HTML结构 (http://jslab.pro/demo/critical_rendering_path/index.html

页面加载过程


(注:紫色是 DomContentLoaded,红色是 Load)

DOM树解析过程,Document Object Model (DOM)

  • Conversion字节码根据编码转换成字符
  • Tokenizing将字符串转化为特殊的标签,如“<html>”、“<body>”
  • Lexing将标签转换成“对象”,定义他们的属性和规则
  • DOM construction根据HTML定义的不同标签的关系(嵌套等),将创建的对象链接到一个树形的数据结构中:HTML对象是Body对象的父级,Body是P的父级等。

最终生成的DOM树

CSSOM 构建过程 CSS Object Model (CSSOM)

页面CSS样式

CSSOM 构建过程

CSSOM

生成渲染树,Render tree

  1. 从DOM树根节点开始,遍历每个可见节点。
  2. 每个可见节点找到并应用对应的CSSOM规则。
  3. 返回计算好样式的内容

Reflow(Gecko) Layout(webkit) 

根据设备的 viewport 计算每个元素该怎样展示。

<meta name="viewport" content="width=device-width,initial-scale=1">

最后一步,绘制页面,Paint

总结解析渲染步骤:

  1. 处理HTML标签构建DOM树。
  2. 处理CSS标签构建CSSOM树。
  3. DOM和CSSOM树被组合形成 Render tree 渲染树(渲染树只包含需要显示在页面的节点)。
  4. Layout(reflow)计算每个对象的确切位置和大小。
  5. 最后是绘制(Paint),把最终的渲染树对象渲染成屏幕像素。

优化关键渲染路径,Critical Rendering Path

  • Critical必需的,关键的
  • Render渲染
  • Path浏览器显示网页(初始视图initial view )所必须的一系列过程。(初始视图也称为首屏 above the fold,用户不需要滚动就能看到的内容)

所以关键渲染路径的定义就是:浏览器显示网页所必须的一系列事件

路径(the Path)

  1. 浏览器下载HTML文件
  2. 浏览器读取HTML,看到有CSS文件、JavaScript文件、图像(解析HTML,遇到CSS资源,加载CSS、解析CSS,继续解析HTML;遇到JavaScript过程相同)
  3. 浏览器开始下载资源
  4. 浏览器决定没有获取CSS和JavaScript的时候不能显示网页
  5. 浏览器下载到CSS文件并读取,并且没有调用其他内容
  6. 浏览器得到JavaScript之前,仍不会展示网页
  7. 浏览器下载JavaScript并读取,并且没有调用其他内容
  8. 浏览器现在决定可以显示网页

这只是一个最简单的网页加载过程,如果页面有很多资源加载过程就会很复杂。

渲染(the Render)

只有很少的资源会阻塞网页渲染,最常见的就是 CSS 和 JavaScript 文件。

浏览器必须把这些资源全部加载并解析完毕才回开始渲染页面。

举个例子:

1,页面有10个CSS文件,浏览器渲染前,会等待这10个CSS文件全部下载、解析完毕。此时浏览器在等待“关键”的步骤时空白页面。

2,页面还有20个JS文件,CSS都下载解析后,也不会开始渲染,还需要等待这20个JS的加载和解析。

(其他还有什么会阻塞?HTML,字体文件等)
(浏览器会逐步解析、逐步渲染,这就是首屏内容可以单独优化的原因)

关键内容(the Critical)(above the fold)(初始视图initial view )

关键内容 = 初始内容 = 首屏

只要保证首屏尽可能快的显示出来,就算页面有1000张图片,100个JavaScript也没有问题。

怎样优化关键渲染路径?

首先找到渲染(首屏)必需的步骤。然后尽可能的:

  • 减少关键的资源;
  • 减少关键的字节数;
  • 减少关键的路径长度。

1,HTML:精简、压缩、缓存
2,CSS:Render blocking CSS,media query 只加载需要的样式,内联CSS

3,Javascript:Parser blocking Javascript,延时执行,async

渲染步骤 DOM->CSSOM->运行(内联)JS->重新构建DOM

外链JS,要先等待下载,执行再继续解析页面。

<script src=”…” async></script> 不阻塞DOM和CSSOM构建

  • Blocking: <script src=”anExteralScript.js”></script>
  • Inline: <script>document.write(“this is an inline script”)</script>
  • Async: <script async src=”anExternalScript.js”></script>

另外:图片不阻塞DOM构建

下面来看一个实际的例子

<html>
<head>
<meta name="viewport" content="width=device-width,initial-scale=1">
<link href="style.css" rel="stylesheet">
</head>
<body>
<p>Hello <span>web performance</span> students!</p>
<div><img src="awesome-photo.jpg"></div>
<script src="app.js"></script>
</body>
</html>

 

第一次修改

<script src=”app.js” async></script>

第二次修改

<link href=”style.css” rel=”stylesheet” media=”print”>

不加载或者内联CSS

(PS:实际上,浏览器会提前下载资源,但是执行还是按照定义的顺序)

(PPS:浏览器会逐步解析、逐步渲染,这就是首屏内容可以单独优化的原因)

案例,分析一个网站的关键渲染路径

http://jslab.pro/demo/critical_rendering_path/index.html
http://jslab.pro/demo/critical_rendering_path/async.html

总结

关键渲染路径的定义

浏览器显示网页所必须的一系列事件。

优化方法

  • 减少关键的资源
  • 减少关键的字节数
  • 减少关键的路径长度

附录

下面是收集的一些其他优化方法还有最佳实践。

优化步骤

先测量,找到瓶颈,再优化。

not all requests are made equal
not all bytes are made equal

—— Paul Irish https://www.igvita.com/

优化技巧:

图片——就算页面有1000张图片,只加载关键的(首屏所需的)3张。其他的9997张都可以延迟加载或者滚屏加载(lazy Load)。

JavaScript文件——可以有100个JS文件,但是渲染头部只需要一个,就延迟加载剩下的99个。

CSS文件——可以有多种做法,合并请求、压缩文件、内联首屏样式

其他手段

异步加载HTML、HTML延迟渲染、内联CSS的缓存处理,减少首屏需要加载的字节数,控制首屏所需字节先加载(第一个14KB)

网页速度的度量

网页速度并不是页面展示下载的字节数,也不是整个页面的大小。要关注的是用户的体验,网页最快可用时间,或者首屏开始渲染时间,才是最重要的。

天猫首页源代码——2016年11月16日,首屏以外的DOM节点动态生成

淘宝首页源代码——2016年11月16日,inline关键CSS,其他CSS异步加载

参考链接:

Chrome Dev tools 查看页面加载

https://developers.google.com/web/tools/chrome-devtools/network-performance/resource-loading

学会看Chrome Dev tools 的 timeline

https://developers.google.com/web/tools/chrome-devtools/evaluate-performance/timeline-tool

一个资源的请求过程

https://developers.google.com/web/tools/chrome-devtools/network-performance/understanding-resource-timing

above the fold 定义

https://en.wikipedia.org/wiki/Above_the_fold

https://www.smashingmagazine.com/2009/09/10-useful-usability-findings-and-guidelines/

延迟加载图片

https://varvy.com/pagespeed/defer-images.html

都有谁在阻塞渲染

https://www.keycdn.com/blog/blocking-the-dom/

阻塞渲染的CSS

https://varvy.com/pagespeed/render-blocking-css.html

阻塞渲染的JavaScript

https://varvy.com/pagespeed/render-blocking.html

async的支持情况(IE10+)

http://caniuse.com/#search=async

网络字体阻塞渲染

http://ianfeather.co.uk/web-fonts-and-the-critical-path/

优化首屏显示

https://varvy.com/pagespeed/prioritize-visible-content.html

First RTT 14KB

https://docs.google.com/presentation/d/1MtDBNTH1g7CZzhwlJ1raEJagA8qM3uoV7ta6i66bO2M/present?slide=id.g3eb97ca8f_10

speed index 速度指标

https://sites.google.com/a/webpagetest.org/docs/using-webpagetest/metrics/speed-index

https://gtmetrix.com/

谷歌的 pagespeed insights 对图片有损压缩

http://stackoverflow.com/questions/41313719/google-pagespeed-insights-optimize-images-running-new-image-compression

http://stackoverflow.com/questions/5451597/how-does-googles-page-speed-lossless-image-compression-work

为什么你应该把按钮左移三个像素

为什么你应该把按钮左移三个像素

本文链接: http://yukun.im/news/452
原文:Why you should move that button 3px to the left

3px

每次当产品即将发布的时候,我就变成了完美主义者,每个元素的错位或蹩脚的交互都让我芒刺在背。 每次都会有十几个细节实现上的小错误,它们就像在嘲讽我,觉得一切都不对劲。

但对于团队中的其他人来说,我们的产品很好啊,功能正常啊。 他们会问“把这个按钮向左移动三像素,真的能改善我们的产品吗?”然后接着说 “上次我们修复一个很小的设计问题后,没有感觉到有什么区别啊” ,然后团队就扭头转向下一个“big idea”和下一组新功能了。

如果你和我一样是个较真的人,遇到这样的情况,你也会感到很挫败。作为设计师,我们要为用户体验的整体质量负责, 但是我们能设计出来漂亮、复杂、愉悦的细节,却拿团队其他人没有办法,我们没法儿控制队友制作、测试、发布的过程。

到底应该怎样说服我们的工程师和产品同行同样关注设计的整体细节呢,纠结了很长时间后,以下是我的几点体会: 继续阅读