关于提高 Tab 切换速度的思考

我们每天使用电脑,都要跟形形色色的 Tab 打交道。我正在用来写博客的 Chrome,就开着好多个 Tab。有了 Tab,我可以方便的切到其他页面看看新闻,过会儿再切回来接着写。OSX10.9 非常吸引我,让我能忍着巨多 bug 使用它的原因之一,也是因为 Finder 终于有了 Tab。

在 Web 上,也有着各种 Tab 用来呈现内容。它们一般都有若干触发点(trigger),对应若干个内容区域(container)。触发点接受一些事件,控制着内容区域的显示与否,构成一个完整的 TabView。有时候,它被称之为 Slider,或者 Switchable。

Tab 不同区域的内容可以是事先就存在的,也可以异步加载。不考虑数据加载这个环节,我们想让 Tab 响应更快,就要从它的切换过程说起了。

对于 click 切换的 Tab,延迟来自于 click 事件。我们知道,click事件在 mousedown 和 mouseup 配对之后才触发。这里有两层含义:1)如果鼠标一直不释放,一直不会触发 click;2)如果鼠标移到 mousedown 元素之外再释放,那么这个元素的 click 事件也不会触发。这个特点,对整个操作系统都适用,例如我文章写到一半,点 Chrome 的关闭,只要我在松开鼠标前把光标移出关闭按钮就没事,web 上也是类似。

可以看到,click 事件为用户提供了反悔的机会。很多后果比较严重或者成本较高的操作,如关闭页面、修改数据,页面跳转等,需要使用 click。反观大多数 Tab,内容是事先取好隐藏的,切换也不会引起页面结构变化,这时候我们完全可以使用 mousedown 来代替 click,大家可以试下本博客右侧的 Recent Comments|Recent Posts|Tags 模块,是不是切换速度飞快,也没什么副作用(注:本博客更换主题后,没有这个 tab了)?

实际上,在移动 OS 上,也有类似的场景:iOS 的 TabBar。多数第三方 App 的 TabBar 都是在 release 之后触发,相当于 web 的 mouseup 或 click;而大部分官方 App 的 TabBar,却是在 press 触发,例如 App Store、电话和时钟。国外的第三方 App,采用 press 的会多一些,例如 Twitter、Amazon 等。iOS 的 TabBar 切换不会引起界面框架变化,只有浏览内容会改变,这时候提高响应速度比提供反悔机会更重要,采用 press 有更好的用户体验。从这一点也可以看出苹果的用心之处。

iPhone 的实体按键中,Home 点亮屏幕是 press 触发,立即响应的;但打开 App 后,Home 回到桌面是 release 触发,虽说实体键不能反悔,也可以给用户一个缓冲:手指不松开,还能多看几眼当前的 App。音量键是 press 立即响应的,这个操作当然是越快响应越好。开关键关闭屏幕是 release 才触发的,因为开关键有另外一个功能:长按出现确认关机画面。这时候如果做成 press 立即触发,屏幕马上变黑,后面什么也看不到了。

综上,对于通过点击来切换的 Tab,在切换成本很低、页面框架不发生大的变化、不需要提供反悔,且没有定义有歧义事件(双击、长按等)的前提下,我们可以选择 mousedown/press 事件,提高 Tab 切换的响应速度。

另外一部分 Tab 是在 mouseover/mouseenter 时切换,例如淘宝首页的「便民服务」模块。mouseover 容易产生干扰,鼠标在移动过程中不小心经过 tab,就会触发内容区域切换。所以大部分采用 mouseover 的 Tab,都会延时一会儿才触发。也就是鼠标在触发点悬停一段时间(100~200ms)后才会切换内容,这期间如果鼠标移出了触发点,就当做什么事都没发生。

对于这种 Tab,我们既要提高切换的响应速度,又不能干扰用户,我能想到的办法就是计算用户鼠标运动轨迹,类似于这篇「揭秘 Amazon 反应速度超快的下拉菜单」里的思路。例如在切换横排 Tab 时,鼠标轨迹肯定是横向移动的。那么对于 Tab 区域内鼠标横向移动触发的切换,我们可以忽略延时立即响应。

以上,就是我关于提高 Tab 切换速度的个人看法,欢迎交流。

本文链接:参与评论 »

--EOF--

提醒:本文最后更新于 1256 天前,文中所描述的信息可能已发生改变,请谨慎使用。

专题「Web 产品思考」的其他文章 »

Comments