由圆通建包操作引起的思考
七/102
什么是建包：
建包操作一词源于快递行业，这个词汇在某些快递中的过程中经常出现。它的意思是在快递的途中，把需要邮寄到同一个地方的大大小小的邮件打包成一个大包，一同发往目的地。
本来这个操作并不存在什么问题，但是在圆通这里就遇到了一些问题。现在大多快递公司都可以进行物流跟踪，圆通也不例外。之前我在淘宝订货走圆通不在少数，也没有遇到过什么意外。但是这次当我过了一天查看物流情况，看到了物流跟踪结果如下：
2010-07-24 20:47:18 福建厦门 快件揽收扫描
2010-07-24 21:15:46 福建厦门 建包操作
从最后一个操作，也就是“建包操作”之后就没有进一步的动静了，整整1天时间。其实本来如果是上车扫描之类的记录的话我也不会感到非常奇怪，因为物流走1天也是常有的事情。但是建包我第一次见，就感到十分困惑，所以我就拿着我的疑惑去询问了谷歌。得到的结果除了上述的哪个定义以外，还有大量的对圆通的投诉，抱怨，都表达了一个意思，建包操作以后就死在那里了，几天没有反应。其实产生这个结果的一个原因在这里：
圆通建包操作：
建包操作完成，中间再出现的中转记录，看不到单号了，只能看到包号，也就是说快递单号要到拆包后，才会有记录显示的。
明白了。圆通建包以后，物流没有死，只是单号消失了，中间几次转运的上车下车扫描都获取不到了。所以如果一次转运需要1天，那么多转运几次导致的单号“假死”现象也就可以理解了。
分析到这个程度，文章还没有结束。让我们看看以下两种情况：
- 第一种：我订了货，物流正常要走3天，但是我无法直接查询物流的具体情况。
- 第二种：我订了货，物流正常要走3天，我可以直接查询到物流的情况。
前一种情况，只要货能在正常的3天内到达，作为用户的我并不会感到不安和疑惑。
但是作为后一种情况，用户的要求就会变得很高，他们中的一部分可能会乐衷于时不时得检查一下，看看物流是否正常，看看是否已到家门口。这一定程度上增加了用户的紧张心理。原本3天内正常的物流，可能因为1天没有跟踪的刷新而让用户怀疑是不是出现了丢了这类的问题。
所以上文提到的圆通建包正中了这个问题的下怀。在建包以后的处理上，圆通向用户隐藏了实际进行中的物流动向，这种隐藏导致了用户在正常物流时间范围内不必要的恐慌和抱怨。
其实在物流查询的问题上圆通做得没有他的同行申通做得好，我们来看两单记录：
圆通的：
2010-07-19 22:34:18 广东广州海珠区滨江 快件揽收扫描
2010-07-20 01:10:01 广州分拨中心 下车扫描
2010-07-20 01:11:39 广州分拨中心 上车扫描
2010-07-20 22:44:55 杭州分拨中心 上车扫描
2010-07-20 22:45:19 杭州分拨中心 下车扫描
2010-07-20 22:49:37 浙江杭州 上车扫描
2010-07-21 07:37:47 浙江杭州天目山路 下车扫描
2010-07-21 07:45:45 浙江杭州天目山路 业务员派送扫描
2010-07-21 16:17:59 浙江杭州天目山路 签收扫描,签收人:本人
申通的：
2009-12-08 20:44 福建晋江公司 的收件员 沈建国已收件
2009-12-08 21:33 由福建晋江公司 发往 福建泉州航空部
2009-12-08 22:59 快件已到达福建泉州航空部 扫描员是 称重扫描2 上一站是福建晋江公司
2009-12-08 23:07 由福建泉州航空部 发往 河南郑州航空部
可以看到申通比圆通的运单跟踪废话更多，而这种废话多的表现给了用户一种安全感。我一直以为在电子商务的过程中，安全性和可信度是成功的关键因素，所以在这个细节上申通做得的确要比圆通来得好。
就问题论问题，来讨论一下解决方案，为什么圆通在建包以后就不能把包的跟踪情况都更新到各个子运单的动向里面呢。从操作上讲，既然在建包时进行了扫描，那么包号和单号应该存在一个对应关系，那么这个更新操作完全是可以实现的。不知是因为跟踪系统在需求时没有考虑到这一点，还是圆通故意绕过了这点来隐藏建包后的操作。
如果这个跟踪真的无法完成，我觉得至少应该在圆通的页面里给出对建包的说明，指出建包到拆包中间的操作是无法跟踪的，并估计出一个大概需要的物流时间，这样在这个漫长的包转运过程中的单号假死现象对用户造成的影响就会减弱很多。等到用户担心了，郁闷了，到贴吧里面去询问了，为时已晚，企业的品牌信誉就这样慢慢得荡然无存。
WEB可用性学习<十>添加额外装饰
四/102
并非所有文档生来平等
Office的背后
将Office文档转化为HTML要做几步：
- 检查颜色、对比度；如果有视频，检查视频。具体操作参考前一章
- 为包含信息的图片添加替代文本
- 当处理演示文稿软件时，需要将所有演讲中说的话制作成文字记录或字幕；取消变换效果。
PDF:创建高可用性的便携文档
PDF有三种：扫描图像；没有标签的文本；带标签的PDF。
扫描图像的PDF几乎没有什么可用性。有必要用一些特殊的软件将图像转化为文本。但这些文本在修改后依然没有标签作为支持。
然后为这些扫描图像的生成文本添加标签；检查纯文本。最终得到高可用性的PDF版本。
脚本的回应
脚本的不速之客
脚本页面需要满足的特点：
- 注意行为和样式的分离
- 页面不依赖特定的输入设备
- 页面在没有脚本情况下依然可以运行
源代码的可用性应该避免出现以下3种书写形式：
<a href='...' onclick='[脚本在这里]'>(高耦合)<a href='javascript: func(...)'>（javascript不应该出现在href中，可能导致空链接）<a href='#' onclick='...'>（综合了上面2个的问题。）
高端脚本
Ajax虽然是使用javascript来实现富Web界面，但它依然可以具有可用性。
当Ajax发生更新时，它可能带来一些可用性问题，解决方案如下：
- 使用视觉或听觉反馈来标示页面刷新
- 向用户说明，页面会自动刷新其内容，或者告诉使用用屏幕阅读器的用户关闭Javascript
- 明确提供选择。使不喜欢Javascript的用户可以更换模式
当使用脚本实现拖放效果时，也可以提供多一个接口，用按钮的形式替代拖放。
使用API（如YUI）
WEB可用性学习（完）
WEB可用性学习<九>造就完美外观
四/100
一图胜千言
信号灯和毒苹果
首先我们需要了解一下色盲
- 红绿色盲（出了大家知道的难以区分红色和绿色这个特点外，他们还会感到颜色和亮度变暗，以至于无法区分红色和黑色。最普遍的色盲，男性居多）
- 黄蓝色盲
- 全色盲（完全无法分辨色相，但对相对亮度比较敏感，极其罕见）
我们主要考虑红绿色盲，因为其他两种人群都非常罕见。
色盲用户遇到的最大问题就是用颜色作为关键字的信息。如果某种颜色在色盲模拟中表现不佳，有3个选择：
- 改变冲突的颜色之一
- 添加纹理使信息更明确
- 在关键字的说明中添加数据信息（替代的访问途径）
在黑白世界中思考
相对明度的计算公式：
（0.2126*R）+(0.7152*G)+(0.0722*R)
相对明度的值永远在0~1之间，如果两个颜色的相对明度过于接近，就说明对比度太弱了
择路而行
为所有的<img>和<area>添加alt=属性，这个很容易实现。问题的关键在于如何书写正确的替代文本。
- 首先alt里面是简短的文本，字数在40-80字母之内。
- 使用类似“……的图像”这样的说法。
- 避免在替代文本中提供其他方式中没有的信息。
由于有效的<img>都具有alt=属性，所以这意味着有可能会出现alt=”这样的空属性。两种情况下会出现这种情况：
- 冗余的图像
- 装饰性图像
alt=之外
有的时候图像表现的内容太多，以致无法简略地进行总结，这种情况下可以把说明写在单独的页面上，然后用longdesc=属性连接起来。注意，longdesc是alt的扩充，而不是替代。
一个比较好的例子就是图表。对于这种情况，有3种策略：
- 将内容最小化
- 依靠longdesc=
- 在叙述文本中进行说明
对于一些简单的图像，是完全不需要图像，比如用HTML和CSS来构建一个柱状图。
别让视频破坏你的网站
不要粗鲁地闪你的读者
为网站添加视频和多媒体内容时，应当注意是否存在闪烁。感光性癫痫在受到特定的视觉刺激时，会不同性质，不同程度地发作。
闪烁是指任何形式的视觉输入在高亮度和低亮度之间来回反复切换。对于感光性癫痫，特别注意2-55Hz的闪烁。
对于闪烁的阈值，这样定义：
- 相对明度超过10%的变换序列都可能是闪烁变换，如果在1秒时间内，序列出现3次或更多就属于超过阈值。
- 如果是小块闪烁往往不认为有害。当闪烁范围占据超过了屏幕像素的十六分之一的矩形大小就认为超过阈值。
如果某一段视频中闪烁是必须的内容，那么请在开始前给予警告。
午夜吱吱嘎嘎走过的文字幽灵
为视屏提供字幕使视频对听力障碍具有可用性。请注意subtitle和caption的区别。前者被设计为提供外语翻译。后者主要为听力障碍者设计。我们重点在于后者。
一个好的caption要做到：
- 保持相关性，提供的信息不能太少也不能太多。
- 任何重要的词语都应该在字幕中体现。
- 如果说话人不明确，应当在字幕中指明说话人。如果会破坏内容，则抽象地指出说话人
- 描述重要的背景声音，忽略无关的。
- 字幕必须同步。
请讲给我听
为视觉障碍者改进视频，在相关性方面和创建caption大同小异。
- 只说该说的话。因为添加解说会使视频的其他背景减弱甚至是视频暂停。
- 内容过多，声音描述应付不过来。如果内容是重要的，需要在视频中创建暂停，引导用户自主得去查看内容。
剪辑室里的秘密
提供一些处理视屏的格式：
- SubRip SRT和SubViewer SUB这是简单字幕格式，非常常用。
- SAMI 微软提供的，制作用HTML形式呈现。
- QuickText 苹果quickTime的某种格式。
- SMIL W3C的解决方案，形式类似XML
- DXFP W3C的用于分发和传输时控文本的解决方案。
- MAGpie 一个字幕处理工具。
WEB可用性学习<八>高可用性界面
四/100
web属于用户，我们只是建造者
不要成为控制狂
- 让用户知道我们将要做什么
- 考虑是否“自动播放”，这个选择权应该交还给用户
- 增加控制按钮，而不是只有开始
对不起，时间到
消灭不必要的时间效果：
- 页面重定向
- 系统超时（确保程序关键路径尽可能简短、简单）
让<form>更正式
为它加个<label>
为它和表单元素增加说明
tips:
- 避免将<input>放在<label>中，这和使用<label>的初衷背道而驰
- 对于隐藏元素无需增加<label>说明，因为他们本来就不打算被访问
- 对于文件上传<input>，增加<label>是必须的
将鸡蛋和火腿放一个篮子里
当一组选择（单选或多选）其实是不同类型的时，可使用<fieldset>+<legend>的嵌套来代替<label>是更好的选择
当同样情况发生在<select>中时，使用<optground>(注意这个无法嵌套)
与键共舞
首先，accesskey和tabindex作为针对无法使用指向设备和依赖键盘导航的用户的解决方案是不提倡使用的。甚至被建议为完全不去使用。
访问的快捷键
- 用户需要为网站所使用的快捷键付出学习成本
- 快捷键可能覆盖系统和浏览器的快捷键设置
Tab键上的内容
tabindex打破了页面的自然阅读顺序，有时会带来一些奇怪的跳跃。
界面要简单易懂
为了将用户的注意力集中在当前任务上，我们要让界面简单易懂。
- 动作计数
- 比较两个界面
动作计数多不一定意味着界面不够简单易懂，有时为了形象可能会损失一些动作计数。关键在于减少无谓的复杂度。
WEB可用性学习<七>圆桌
四/100
表格的基础
我们需要为table添加额外的信息，用来描述它，这对屏幕阅读器的依赖者有益。
马上使用<thead>
<thead>和<tfoot>标签用于设置表头和表尾，在其中用<th>来标记单元格。而表格的主要内容在<tbody>中
tips:
- 只能有一个<thead>和<tfoot>（<tfoot>是可选的），但是<tbody>可以有多个；
- <thead>和<tfoot>要出现在<tbody>之前。
为表格加标签
用<caption>标签为表格指定标题，它位于<table>之后的第一个标签（<thead>之前），在<table>中添加summary属性来对表格进行描述。
啊！我所不知道的<table>
为了使屏幕阅读器使用表格，我们需要添加信息将表头内的单元格和内容联系起来。
连接表头与表格其余部分
通过scope=row/cols属性来明确某个单元格的表头是标题行还是标题列。
双重表头
通过对单元格设定headers属性可以为表格中的一项指定多个表头，这个要通过id属性为表头赋予标志（banum注：与页内锚点的使用类似）。
abbr属性是缩写，在阅读器中可能读出abbr的值，headers顺序和阅读顺序可能是相关的。
轴：信息的联盟
有的时候信息是多个维度的（超过两个维度）。一种较高的的要求是指使用一个表格来表现。这需要使用axis属性。
有的时候将表格拆开是更好的做法，因为使用axis对于普通用户和屏幕阅读器都是相当的负担。当很难讲表格按维度分割时，才使用这个属性。
附例子：
（请通过源码查看该示例）
| Artist | Album Title | Media Format | |
|---|---|---|---|
| Compact Disc | MP3 | ||
| Magnetic Fields | 69 Love Songs | Yes | No |
| Song Title | Rating | ||
| Absolutely Cuckoo | **** | ||
| I Don’t Believe In The Sun | **** | ||
| U2 | Zooropa | Yes | Yes |
| Song Title | Rating | ||
| Zooropa | ***** | ||
| Babyface | ** | ||
布局和其他不良的表格习惯
滥用表格导致的3个问题：
- 布局管理困难
- 降低网页速度
- 降低页面可用性（请考虑屏幕阅读器是线性的）
如果必须使用表格布局
为了可用性，请考虑表格的线性顺序（从左到右、从上到下）。处理不当，会使用户的操作流程不断被打断，甚至产生误解，最糟糕的结果是失去用户。
当表格不是表格
列表不是表格
表格和表单
尝试用<fieldset>来代替表格作为表单的容器。
WEB可用性学习<六>结构化生活
四/100
言之有物
创建语义内容的第一步，是正确使用标记语言。目标是使内容清晰明了。
阅读顺序
如标题标签不应该越级
使用故事板避免混合内容和表现
不要试图使最终设计与故事板丝毫不差。
用微格式增加更多信息
软件可以将信息提取出来，用不同格式展现。微格式是方法论，而不是技术
自定义格式
用div+css+class以标志出信息类型即可，为用户提供可能的语义环境。
简单就是美
使用开门见山的语言来增加内容的可用性。按面向用户的类型选择内容的语言水平。
特殊术语
对于术语，如果用户群是专业用户，则可不用提供定义。否则要增加定义，如果术语很多要提供词汇表，但首次使用时定义依然不可缺少，因为在正文与词汇表之间的跳跃会增加用户的负担。
我看不懂希腊文
在必要的地方增加lang属性（这里指外语，外来词）。
成语的雷区
避免过度使用成语、俚语等。
缩写亦须明意
使用<abbr>处理简写。使用<acronym>标记处理缩写。在title中使用完整内容。
注意<p>和<q>
字体和格式
避免使用非语义的标签，用其他标签代替他们：
用<strong>代替<b>表现粗体；
用<em>、<var>代替<i>表现斜体；
用<strong>、<em>代替<u>表现下划线；
用<del>代替<s>表示删除线；
用<ins>表示上划线；
用<code>、<kdb>、<samp>、<var>代替<tt>表示等宽字。
框架
减少使用框架，或在<noframe>中提供替代版本。
链接在一起
让链接引人注目
清晰地使用链接，不要模糊他们的意图。
使用有别于其他元素的显眼颜色标注。同时防止链接相互紧挨。
明确链接的目标
给链接添加描述的元数据。避免使用<a href=”#here”>点击这里</a>这样的表述。（banum注：关于这个业内有很多讨论。从可用性角度分析，应该这么做。）
“跳转到内容”链接
添加页内锚点以方便有障碍的用户，却依然使全能力者得到好处。（banum注：关于这一点，其他专家同样有很多不同的看法。）
样式：华丽的盛装
使用CSS要注意分清内容和表现，确保失去的样式，内容依然是内容，即不要使用<span>来表现<h1>。
再者要在css标准与实际应用中找到平衡点，有些建议标准没有得到广泛支持，减少或者避免使用。
WEB可用性学习<五>
三/100
设计时就考虑测试
测试应该在最初就被得到关注。可用性成本高的项目有两类：
- 大量需要文本替代物的媒体项目（不可削减）
- 开发末期加入可用性导致的两次创建内容的成本（可削减）
从上面的分类可以看出最初就考虑测试和可用性开发可以减少成本。
第一天就开始测试，即每做一步都测试可用性，然后渐进地添加新功能和样式。
动手去做
手工测试
- 检查替代文本的恰当性(alt、lable、声音的文字记录和字幕)
- 关闭图像，看内容是否有意义（或是否中断页面流向）
- 关闭样式表，看是否按自然阅读顺序构建web产品
- 检查其他分辨率，确保在低分辨率下可用
- play unplugged，放弃鼠标，看看依靠键盘是否可浏览（甚至考虑屏幕阅读器）
让残障用户参与过程
- 组成焦点小组
- 加入残障作为全程的测试人员
测试考虑的问题
- 哪些任务无法完成，为什么？
- 完成某任务是否耗时过长？
- 用户完成任务时，界面是否舒适？
WEB可用性学习<四>第三部分
三/100
多种访问途径
选择使用多种途径的目的是为了向用户以最佳的方式呈现信息，这取决于用户如何访问网站。
如果一段内容依赖于特定媒体的表现（如视频中的画外音），我们就至少要提供一种替代表现方式（我们添加字幕）。最终，我们希望用尽可能少的途径来覆盖尽可能多的用例。这并不意味着我们只是简单的在页面上罗列内容的几个不同版本。
在使用替代方案时要注意途径是否合理，确保没有使残障用户迷失方向的“黑洞”，以及允许其他完全用户进一步研究的能力。如果只是简单罗列替代版本，这可能导致
用户过载（overload）
这个说法基于感知负荷理论（cognitive load theory），即人用于某事的精神是有限的。除了信息本身带来的负载我们无能为力以外，我们需要减少因为信息的表现形式所导致的外来负荷，即使信息更容易理解。需要注意的是，非互补的信息会带来障碍。如为视频提供字幕，如果字幕与视频不同步，就会增加障碍。此外，如果互补信息跨越了多个页面(banum注：如某些注释链接需要开新的页面)，用户就需要在导航和界面上消耗精神资源。
牢记媒体的属性
每一个媒体的属性都是不相同的，所以我们需要考虑他，然后提供额外的信息作为该媒体类型缺失属性的补偿。对于交互元素，如果这个交互元素很重要，就需要设计替代的控制和响应来使不具有感应能力的也可以交互。
这里需要注意一点，设计一个大部分用户都一目了然的页面和为每个用户都设计一个页面是有巨大区别的。如果可能就要避免后面那种情况。
不要重复工作
如果项目中包含相互依赖的重复，事情变得糟糕，修改的工作量会按乘法增加。在某个系统中，一条知识必定有单一、明确、可靠的表现方式。
为了做到这一点，我们需要
进行抽象
我们需要许多真正有用的基本要素。 这个要素能够在多个地方使用，同时要避免上层的修改反过来影响这些要素。
避免一次性的决定
当系统需求中出现“一次性”的请求时要判断它是不是真的是一次性请求，如果真的是要把这个样式变化限制在一个特定页面上，以减少未来维护的开销；如果这个一次性请求（通常是如此多的一次性请求）其实是因为系统漏洞引起的，那么应该向开发者提出意见，在未解决前依然使用前面的方法来处理这个请求，即局部样式；如果这个一次性请求是内容开发者过于追求某个想法的最初观点而产生的特定语言，那么可能可以用已有的标记和样式来表达，重新审视它吧。
使用模板系统
并不是所有的模板系统都可以解决重复问题。请使用支持数据、接口和表现的最佳分离的模板系统吧。
WEB可用性学习<四>第二部分
三/100
做好可用性计划
如软件工程中不断提到的那样，在《Design Accessible Web Sites》中也提及了可用性计划要在项目初期进行，以减少后期因为可用性重构而引起的高费用。
文中提到计划分可以为如下两个部分：
- 样式指南
- 修订计划
让我们一个一个来看：
样式指南
关键字：最有价值的产物
形式：wiki上的页面、由计划小组创建的文档
作用：解释内容的标签和样式以及能反映产品目标的媒体获取标准。
具体：
结构化标签。
将内容和表现分离。样式指南每种内容对应的标签。
文档化的输出格式。
将每种格式都输出为文档。
内容样式。
以一致的方式清晰写出内容，目的在于减少读者负担。尤其对于专业用户，请参考对应的标准。
媒体获取标准。
确保输出格式能够恰当呈现多媒体资产。这可能涉及到资产的属性、内容以及储存形式，甚至是替换形式。
修订计划
制定了计划以后应该经常修订。
步骤：
- 将修订建议添加到主修订列表
- 考虑修订的影响
- 审查修订列表，对于改变做好记录以方便驳回修订。
- 确定要做什么
- 该修订是否需要获取新的内容？
- 是否需要新的标签形式？
- 当前的到黄和搜索系统是否满足需要？或者，是否需要新的东西？
- 是否须要为内容准备新的布局？
- 该修改是否要求使用多媒体元素，以致需要生成字幕或声音的文字记录？
- 关于这个新的标签需求的哪些信息应当写进样式指南中？
- 新的内容是否需要更多的基础结构支持？
- 将任务分派给适当的人并决定截止日期。
如：
WEB可用性学习<题外话>
二/100
今天在google搜索相关内容时，发现一位淘宝网的朋友前不久也写了一篇《Design accessible web sites》的学习笔记，不过他的是简明提纲版的，我的blog更新得比较慢（自己比较懒），急着看完的看官可以去他的blog看看，所以上来一个链接maxbbn>>阅读笔记《创建高可用性的Web内容》