11月9日，晚上10点多，发现外边下小雪。还奇怪这不刚下完雪么，要在去年下一次可都得憋很长时间的。不一会居然跳闸停电，而且还连续跳闸，对面小区的楼也全部漆黑（我住东城区）。这时，出现了多年在北京感觉最恐怖的一幕：停电+打雷+闪电+下雪。更奇怪的是外边一片黄光，与沙尘暴颜色差不多，有点世界末日的感觉。难道是传说中的冬雷？论坛上见有人打趣说，气象台应该加个叫“雷阵雪”的天气。（据说是北京150年来最晚的雷暴记录）

11月10日，中午在中关村软件园这边给同事拍照，我们创作了软件园最有创意的雪人。到处都是水，我穿的休闲鞋进雪，又冷又冻，后悔死了。下午去了趟颐和园，入园的晚，天气越来越冷。从文昌院门走到南湖岛即返回，一路都能碰到拿三脚架拍雪景的摄影爱好者，其实光线并不好，所幸积雪厚度还可以。去年在地铁里见过张颐和园风景照，佛香阁的宽幅雪景，照的真好。有天上班听两人讨论，某人说“这照片就是为了让我们感觉没去过颐和园。”忍不住想笑。

11月12日，北京又飘起第三场雪。正好还是上班时间，一怒之下我穿登山鞋出门，不打滑不进水果然很爽，我喜欢踩雪的感觉。

北京の雪 2009
http://rexsong.com/photography/beijing/snow_2009.htm

地坛公园 2009
http://rexsong.com/photography/beijing/ditan_park_2009.htm

颐和园 2009
http://rexsong.com/photography/beijing/the_summer_palace_2009.htm

相关文章

• No Related Post

其实这样也不彻底解决问题，在title做“补充说明文本内容”作用时，用括号的场景可能有解释、简写缩写、前后补充等等，这些人际功能产生的内容模糊机器不懂。如何区分并准确转化为机器语言？在讲究语义化的HTML标准里，有更恰当的标签来做这些工作。

简写缩写说明

HTML4.01中分别有<abbr>与<acronym>两个标签来表示缩写，区别在于<acronym>是英文首字母缩写，<abbr>是名称缩写。应用分别如下：
<acronym title="Portable Document Format">PDF</acronym>
<abbr title="Minimum">Min</abbr>


但在HTML5.0与XHTML2.0中，<acronym>变成不赞成使用的标签，而推荐<abbr>代替。因为<acronym>容易与<abbr>混淆，它们用法之间是互相包含的关系，很多英文名称缩写其实就是首字母缩写，比如CSS的全称是Cascading Style Sheets。“千鸟，是一叶千鸟的简称。”这句话如果用代码来阐述：
<abbr title="一叶千鸟">千鸟</abbr>


专业术语说明

针对不同知识领域读者时，有时会大量用到专业术语或特殊短语，但不属于简写、缩写范畴。这时可以使用HTML提供的<dfn>标签，比如：
<dfn title="Mozilla公司推出的网页浏览器">Firefox</dfn>
<dfn title="Microsoft web browser">Internet Explorer</dfn>

W3C不建议大量使用，当首次出现新术语时，应定义样式与普通文本分开，促进读者理解，而从那以后也不需要再对此术语进行标记了。道理类似不要重复在一篇内容内，做多个同样链接。

按照这个思路，我觉得HTML应该提供个叫做<translate>的标签，用以针对翻译词汇的说明。尤其在专业技术领域，外来词汇特别多。比如，要解释UCD的全称（User-Center Design）可以用<abbr>，但中文翻译（以用户为中心的设计）呢？老用括号太不专业了。

相关文章

• 使用Title提升可访问性

1. 为视听的内容提供同等的文字替代；
2. 不要仅依靠色彩来提供信息；
3. 适当使用标记语言和样式表；
4. 阐明自然语言的使用；
5. 创建编排良好的表格；
6. 确保页面能够在新技术下良好呈现；
7. 确保使用者能处理时间敏感内容的改变；
8. 确保嵌入式用户界面具有直接的可访问性；
9. 设备无关的设计；
10. 使用过渡的解决方案；
11. 使用W3C推荐的技术和规范；
12. 提供内容引导信息；
13. 提供清晰的内容导航机制；
14. 确保文档内容的清晰与简单。

微软MSDN上关于WAI、WCAG和Section 508的解释中分别提到了WCAG1.0和来自美国联邦政府的Section 508规范要点。Section 508法案的Subpart B有16条，原文翻译的很啰嗦，根据自己理解简化如下：

1. 对每个非文本元素都应该提供等同的文本。
2. 任何多媒体演示的等同替代内容都应该与该演示同步。
3. 保证所有通过颜色传达的信息无需颜色也可获得，比如通过上下文或者标记。
4. 文档应该经过组织，这样它们无需关联的样式表也可阅读。
5. 为服务器端图像映射的每个活动区域都提供冗余的文本链接。
6. 提供客户端图像映射而非服务器端，除非区域不能使用可用的几何图形来定义。
7. 为数据表标识行和列标题。
8. 对于具有多个行列逻辑层次的数据表，应标记清楚关联数据单元格和标题单格。
9. 使用有助于框架标识和导航的文本来为框架加上标题。
10. 避免在频率大于2Hz并小于55Hz的情况下导致屏幕闪烁。
11. 当以任何其他方法都无法达到符合性时，应该提供有等同信息或功能的纯文本页以使Web站点符合规定，并相应同步。
12. 使用脚本语言来显示内容或创建界面元素时，应预留退路保证功能文本一致。
13. 要求客户端用插件或应用程序来解释页面内容时，必须提供相应插件或程序链接。
14. 允许用户使用辅助技术来访问并提交在线电子表单所需的信息、字段和功能，包括所有说明和提示。
15. 提供方法允许用户跳过重复的导航链接。
16. 当需要定时响应时，应该警告用户并给予其充分时间以表示需要更多的时间。

熟悉WCAG和Section 508的同行，可能已经意识到，它们都只满足了可访问性的部分要求，而并不是完备的解决方案。仔细推敲，WCAG有个web“内容”可访问性的前提限定；Section 508范围稍广，但只是个法案而非技术标准。

其实很好理解，能进入站点才能享受服务，享受了服务才能体验功能，体验功能后才能看到内容，“内容”可访问性只是web可访问性的站点、服务、功能、内容层次之一。比如强行设主页和弹窗都属于站点可访问性；404页面和强行注册属于服务可访问性；不提供站内搜索和提供N多同类链接则属于功能可访问性。

在搞清楚技术定位之后，视野可以更开阔，看问题也不至于那么模糊。比如，绝大多数互联网工作者对优化“web用户体验”的工作，总是有种承担最少改动风险，获取最大收益回报的心态。既没太多资源和时间做很多事，又想马上看到效果，对任何设计师来说都是绝对挑战。以我的从业经验总结来看，这样的客户其实需要的是“可访问性设计”优化，并且他们理解认定的“web用户体验”优化工作也仅止于此。

很多时候，当涉足优化那些需要专业知识来驱动设计改进的专业网站时，我们往往对信息架构的“可发现性”、交互设计的“可用性”优化提不出建设性建议。因此，能够大显身手的地方也只有针对“可访问性”的优化改进。由此可见，一方面应该更重视并准确理解可访问性，另一方面更应该注意避免内容可访问性带来的局限性误区。

如果从产品角度理解，似乎互联网产品总是与web2.0划等号，UCD设计理论的发展也与之息息相关。而针对web1.0网站的用户体验优化，我认为可访问性效果远大于可用性，因为此类网站没有复杂的用户行为、交互逻辑，以及应用场景。

相关文章

• 页面加载对访问的影响
• 可用之前先保证可访问
• 给网站界面预留退路

事后想了想，犯这个错其实也不完全怨我。如下图，他们收银台临街，明摆着让路人参观。而且收银台机器、桌子也和其他没啥差别。如果一排店员站着工作，就全部背对路过的看客，有这么浪费临街铺面的么？收银台能不能找个低调点的地方。

顺便提下我的好习惯，在人家的体验电脑上都打开个人网站再走，比如去年WinHEC也干过。

相关文章

• 我把电话给店员吧
• 多赚一口
• 墨脱和摩托罗拉
• 换零钱
• 灰鸽子
• 在麦当劳
• 脑部发育好
• 虎背熊腰

举个例子，某页面浏览到一个地方卡住了，至少要等十几秒才出来内容。排查原因，浏览其他网站页面很快，说明客户端网络带宽没问题；浏览同个服务器上其他网站页面都很快，说明服务器的处理速度和网络带宽也没问题。分析代码可能有好几种情况，在YUI官方加速网站的最佳办法提到了13条方法，对于普通产品来说，个人认为有几条应该强化注意，其他（灰色）从性价比上来说则成本有点高。

• Make Fewer HTTP Requests 更少的HTTP请求
• Use a Content Delivery Network 使用CDN
• Add an Expires Header 指定过期时间
• Gzip Components 压缩结构
• Put Stylesheets at the Top 样式表文件在顶部
• Put Scripts at the Bottom 脚本在底部
• Avoid CSS Expressions 不在css中使用表达式
• Make JavaScript and CSS External 将Javascript和CSS文件分离到单独的文件
• Reduce DNS Lookups 减少DNS查询
• Minify JavaScript and CSS 精简Javascript和CSS
• Avoid Redirects 避免重定向
• Remove Duplicate Scripts 去掉多余的脚本
• Configure ETags 配置实体标签
• Make Ajax Cacheable 可缓存的AJAX

当所有假设都理想化之后，是否所有问题都解决了？答案是不一定。因为并不是加载越快就越好，快慢先后都应该有讲究，分别从加载速度、加载优先级两个角度举例探讨。

加载速度

我曾经碰到种情况，因为页面呈现过快反而影响用户体验。页面跳转交互一闪就过去了，但首屏内容没怎么变化，结果我不知道页面是否真进行了跳转。过快的交互感觉不是流畅，而是迷茫。此问题常见于博客系统，各位同行可以仔细观察。比如淘宝UED博客，下图左为首页首屏，右为网志页首屏。（连连看？）

http://ued.taobao.com/blog 截图于2009年10月28日

UCDChina官方博客也有类似问题，其症结在于前后页面布局不当。按理说，不同层级页面所突出的核心内容应该不同，所以首屏也应该有明显差异才对。我设计自己博客首页、列表页、网志页布局时，就特别注意了它们之间的传达关键点差异，如此在较快的交互时会有“动画”效果。下图上为首页首屏，左为列表页首屏，右为网志页首屏。

http://blog.rexsong.com 截图于2009年10月28日

从以上例子可以得出结论，加载速度并不是孤立存在可能影响用户体验的因素，而在整个设计方案体系中起推动作用。事实上，用户对加载速度的要求也不是特别高，最关键是稳定，不低于用户期望。慢一点没关系，只要能给用户“说法”，比如动态加载提示，用户反而会觉得“过程”很受用。

另外从技术原理上来看，60%到80%的优化很容易，但再往后的每一点进步，都得付出相应的成本和资源。因此，不纵观全局、不考虑客观条件追求极致优化的做法不可取。

加载优先级

在打开到浏览页面的过程中，除加载速度，我留意并发现呈现顺序之差也能造成细微的体验影响。从web原理来讲，整个页面正常应该是从上倒下，逐步呈现。但现实中web往往是竖状布局居多，因为更符合用户浏览习惯，更易于页面技术实现。

竖状布局就会牵涉到个优先级问题，应该先显示哪列模块？答案肯定是最重要的内容。在2004年网站重构技术得到重视之后，此问题已经不算什么新情况了，技术解决方案很成熟。之前最常见的是用table标签进行布局，造成需要table内的内容全部加载完成之后才显示的后果。具体表现为可能卡在页面某处长时间停留，并整个模块突然出现在页面上。下图为三星中文官网错误的先显示广告，而在重要模块长时间等待。

http://www.samsung.com/cn 截图于2008年7月23日

除重要性，我认为模块还有时间先后关系在影响呈现。比如在网站首页顶部加长幅消息模块，通知服务器维护、改版新体验等用以提升用户体验的手段很常见。但是否有设计师考虑过这些内容“性质”模块应该在什么时间出现比较合适？

我曾经做过个方案规定“改版体验的提示必须在整个页面加载完成2秒之后，从上往下滑出推动整个页面，以求更明显让用户注意的效果。”因为在页面加载过程中，所有对象都在从无到有的移动显示，如果在整个页面相对静止之后，突出更重要的“改版提示”，效果会顺畅很多。同样的结论还可以用在帮助提示，或某些新功能贴“标签”上。下图为雅虎官方新改版的测试邀请。

http://www.yahoo.com 截图于2009年3月21日

前几年弹窗广告流行时还有个类似案例，因为用户都特烦弹窗，打开页面的弹窗往往用户下意识就去关掉了。后来我设计了个延时10秒的弹窗，一月数据显示点击效果平均提升了30%。

相关文章

• 内容可访问性不是全部
• 可用之前先保证可访问
• 给网站界面预留退路