其实CSS早在两年前已经有所掌握了，但是最近半年来从事的工作跟技术基本上不沾边，所以CSS方面已经开始不沾边。现在可以说是重新温习一下CSS吧，基础内容会来自一些CSS，PHP，JS书籍吧，博客主题也即将改为基础技术类博客，然后要优化的词“博百优”作为一个主角出现吧。
1 标记
HTML原本是一种简单且易记的标记语言。但是随着网页变得复杂，页面代码就变得累赘，不但大大加大了带宽的符合，还为用户体验，搜索引擎友好性增添了不少麻烦。所以我们在做SEO的时候，在技术端这边的优化最重要的就是优化代码。博百优本人也有一段时间没有接触代码了，所以我们一起来学习学习基础吧。
» Read more..
红网长沙4月16日讯（潇湘晨报滚动新闻记者 王欢），今年21岁的女大学生小慧，三岁就失去了母亲，双鬓斑白的父亲打工供她上学。2008年考上湘潭某大学后，为了省钱，小慧每天只吃一顿饭，很多时候还是两个白面馒头，一天的生活费不 到3块。
» Read more..
我本来打算在2月13号，也就是Buzz发布之初写这篇日志，结果当天毒瘾犯了，玩PSP月下去了。拖到3月中成稿后，又因忙碌和烦躁，放了两周不去修订 它。此时是否已经没有人关注Buzz？
剽悍的Buzz不需要解释，基本上是Friendfeed的翻版。很多人没玩过 Friendfeed，所以老往Twitter上面套，并盛赞Buzz的创新，其实大都是Friendfeed玩残了的把戏。没办法，明星吃饭拉屎皆新闻 也。然则Friendfeed没能大红大紫，始终是笼罩在Buzz头顶上的一片阴云。这个模式的缺陷到底在哪里呢？
显而易见，Buzz认 为是推广不利，没能快速到达增长拐点，所以背靠Gmail/Google Reader/Picasa三颗大树。Buzz心想，坐拥近2亿的用户基础，自然胜券在握。吓！好乐观，我看未必。强大的推广渠道其实是把双刃剑，带来用 户也带来麻烦，甚至于麻烦超乎想象，预期的收益中却充满了泡沫。
近半年来，我一直在极力鼓吹产品的纯粹性，主要是用户社区的纯粹性。所谓 用户社区，即人与人之间相互影响较多的产品。在我看来，Friendfeed也好，Buzz也好，都是由于纯粹性不足而上升乏力的案例，Buzz的情况尤 其糟糕，具体有如下五点：
1、不纯粹的习惯
首先，我们可以明确Gmail是一款邮件产品，Buzz是一款社交产品。二者的使用习惯并不一 致。比如邮件应用的目的性较强，社交应用的随意性较强，如果沿袭邮件的使用习惯，有可能访问Buzz的时机不对（早上上班），停留时间下降（忙于处理正经 事务），访问频度也低于其他社交产品。但若期待用 Buzz去改变Gmail的使用习惯，它目前还没有如此大的魔力。
拿特别熟悉的QQ举 例。我们会因为挂QQ而顺带使用它面板上的其他服务，却不容易为了使用“其他服务”特地打开QQ。在子母产品之间，习惯上的主次分明，次要服务必然迁就主 要服务，除非它也慢慢进化为了主要服务的一部分——多么漫长的过程，但Gmail的用户习惯却不利于Buzz的快速渗透。
我 猜，Google的工程师一定也看到了个中隐忧。或许正是因为Gmail的用户习惯难以拉动Twitter类产品的使用，最终才采用了 Friendfeed模式，即便用户并不活跃地产出信息，他在Google Reader、Picasa以及其他feed源的活动依然能自动输出内容，使得Buzz用户“总有得看”，用阅读来带动Buzz起步，再用互动来加速 Buzz成长。
于是Gmail一方面加入了社交阅读器的特征（QQmail早就干了），另一方面也借力于Gmail的邮件往来数据，用算 法搭建好了用户关系网络。在一开始的新闻稿中Google正是得意洋洋地宣布，庞大的关系网络乃Buzz的核心优势之一。
当真如此？
我 看未必。留到第三个小节再去评价。
2、不纯粹的感受
所谓“用户感受”的概念，可以用更专业，更装逼一点的名 词来描述，即“用户情感体验”，他使用产品时，在情感上产生的细腻的触动。
如果从产品类型的角度出发，那么Gmail和Buzz同为信息 获取工具，用户操作均为收取-阅读-回复，看似雷同。但如果从用户感受的角度出发，阅读一封邮件和阅读一条社交信息的情感触动往往有明显的区别。邮件类型 因其多元化，其阅读感受是中性的；而社交资讯的阅读感受则是亲切而随性的。
正是由于这种差异化，作为邮件产品，Gmail强调信息的获取 与管理效率；作为社交产品，Buzz强调的是轻松阅读与便捷互动。产品设计风格出现了明显的区别。那么不同感受的内容，不同风格的服务，强行糅合在同一款 产品里，又怎么能算得上纯粹呢？
就像宣纸是纸，草纸也是纸，却绝不可以混为一谈。感受上的不纯粹使得用户适应性被削弱，接受新应用的时间 被延长，无法实现平滑而凶猛的扩张。
3、不纯粹的关系
之前提到过，Buzz得意于Gmail和Google Reader现成的用户关系网络。这是鲜花，也是炸药。这是营养牛奶，内含三聚氰胺。问题并不在于用户关系网络是否真实，是否有效，而是这张网络属于什么 样的交流性质？
很显然，我的工作网络，家庭网络，同学网络，兴趣组网络各自不同。我希望老板看到自己生活中的一面吗？我希望家人看到自己 工作中的一面吗？把关系网络简单理解为熟人关系，好比这世界上只有一个Internet，却不允许无数个局域网的存在。我在接受Buzz作为社交网络之 前，被强行夹到一份自以为是却错漏百出的速配列表之中，然后一个个删除清理。何必这么辛苦呢？不用它便是。
任何一张成功的社交网络必定由 用户亲手织成，由他根据不同的社交情景来选择每个交往对象。从情景和对象出发，自由定义社交类型，才会使得用户足够投入。这就是人的社会性，它必定是自由 恋爱而非相亲节目。然而Buzz与Gmail、Google Reader捆绑，使得用户关系的性质错综复杂，发言颇多顾忌，更有隐私泄露的大患。
后 来Google很快解除了Buzz与Google Reader好友的同步，可见用户之怒。这不是废话吗？Google Reader的follow只是普通的订阅关系，可视之为“社会化”，却与“社交”两个字天差地别，我接受一个陌生人的文章推荐并不代表也接受他输出的其 他信息。可解除同步无法根除Gmail关系的芜杂，速配必然失败。我们必须尊重用户本人的社交选择意愿，多么高明的算法也无法将之取代。
如 果没有被用户接受的关系网络，那么社交就是一朵假花。Buzz借力于Gmail，情况可能还要糟糕一点，就是用户被茫然导入，对此地的对话语境全无了解， 也很难认可这张轻浮的算法列表。好像被外星人抓到了一起，天空中有个高音喇叭喊：“快聊”。那么他连从头开始建立关系网络的兴致可能都被打消了，或者直接 过滤掉Buzz，眼不见为净；或者自居于公众场合而不是私人空间，有悖社交的初衷。
4、不纯粹的内容
上面谈到“不纯粹的关系”， 乃是Buzz的致命伤。当然也不排除有一部分用户，他们可以接受Gmail的算法推荐，或是手动清理出来一张满意的关系网络，然后踏上Google赞助的 社交之旅。你好，Friendfeed的衰败阴云正在前面等着你们。
在2009年，我曾经疯狂迷恋过半年的Friendfeed，但只使 用它的Room（以后还会专门写篇日志分析“社会化推荐”）。和大红大紫的Twitter相比，Friendfeed一贯叫好不叫座，红颜薄命吗？我倒认 为是孤芳自赏居多。
那半年里我在Friendfeed上follow了不少人，信息流那是刷刷的快。过瘾吗？一点也不。我压根感受不到在 信息背后的人的存在，只是一队僵尸，一个高音喇叭，一条死气沉沉的河。只见源源不断的碎片资讯被抓取而来，可作为阅读器，乱纷纷的碎片干扰了阅读的质量与 节奏；作为社交产品，它又缺乏最起码的人味儿。既然大多数人压根不来这里活动，哪里有什么人味儿呢？与邮递员送信又有何异。
缺少个人魅力 的吸引，把人抽象为内容订阅源，却忽略掉了微妙的“人的气息”，这就是Friendfeed模式的败笔。在社交场合我们关注的是某个鲜活的人，而不仅仅是 他发表的内容，如果他不在这里（或很少来这里），那么我也没有留下来的必要。当他发表的内容被从本人身上剥离出去，变成若干条广播消息，于是光芒尽折，我 却更愿意看到他亲口在某处讲述。这无关时间、地点与形式，转发如临摹，再怎么逼真也是幅赝品。
当然，Friendfeed里也不乏活跃的 发表型用户，但终归是少数，僵尸抓取信息与真人发布信息羼杂在一起难以辨识，尸臭沾染到活人身上。信息再怎么汹涌，也如同群尸过界。创始人太看重信息获取 效率，却无法理解人与人之间的情感诉求。
说回来Buzz，它自动关联feed的设计既丰富了内容，又制造了一大批生化僵尸来削弱社交的乐 趣，看似Google Reader的互动加强版——然则僵尸愈多，社交乐趣愈少。
5、不纯粹的阅读
即便是照搬Friendfeed模式，Buzz可能比它的前辈还要更糟糕一点。因为 Friendfeed的正文设置为新开窗口阅读，Buzz却继承了Google Reader的衣钵，在本页直接展开阅读。带来什么样的后果呢？你自己看嘛，正文接评论接正文接评论接正文，鸡包纸包鸡包纸包鸡……
冗长 的评论毫无疑问对正文阅读造成了干扰。有时候我好奇点开折叠评论，呼啦啦拖下去两屏，全是生面孔的无聊吵闹，下一条正文信息被挤到两屏开外。Buzz的交 互设计极力鼓励琐碎的评论发表，又时常因为陌生评论者的掺入而显得索然无味。再加上Friendfeed回复优先的显示设置，信息被反复顶上去，一长串无 趣评论频频跑到你眼皮子底下去抢风头。结果用户关系驳杂的创口越撕越大，不感兴趣的“好友”动态，莫名其妙的口水回复，充盈视野，使人焦躁不安。
更 加要命的是，轻快的微博和长篇大论的文章，通栏排开的图片绞在了一起，忽而长文忽而短语，绞成一团乱麻。内容界面全无简洁清爽的美感，只能用“杂乱无章” 四个字来形容，阅读节奏时轻时重，时快时慢，怎可能与Twitter行云流水的流畅相比。
Buzz把长长短短性质各异的内容放在同一个页 面上，必然带来阅读上的跳跃感，忽而漫步忽而短跑，全无连贯性可言。然而Twitter之所以是了不起的Twitter，不仅因为它够简单，还因为它够纯 粹，又从纯粹中派生出鲜明的感染力与稳定的节奏感来。像脉搏一样强有力的内容节奏能明显提高阅读舒适度，进一步促进阅读的连贯性和浸入感。如果把 Twitter的纯粹理解为简陋，把Buzz的花哨理解为强大，则徒增笑柄。
反观Buzz之旅，与其说是热闹，不如说是嘈杂，使阅读区变 成了闹哄哄的广场——是的，一群Google粉丝聚集闲聊的广场就是Buzz的现状。讨论比发表更热烈得多，讨论者之间常常互不相识。它更像是一个由五花 八门的follow关系构成的，开放性的资讯讨论组（或灌水群），却与社交的初衷南辕北辙。轻浮的用户关系再加上紊乱的阅读体验，如何能“社交”得起来？
Buzz 发布半个月后，伟大的谢尔盖·布林宣布说，Buzz公测的结果与Google内部2万名员工的内测结果大不相同，因此Google今后的产品都将进行小范 围公开测试，不再以内部员工测试为准。于是你立刻理解了为什么牛逼如Google也会在Buzz上犯这么多错误，因为所有的Buzz试验都是以 Google员工，这批少数派精英为参照标准，尤其在封闭式的环境下无法还原多样化的用户情景。而社交中的情绪化，个性化，远远超出了 Google工程师的感知范畴。社交的本质是特定关系网络中的特定社群文化，它的规律即便用尽全世界的大型电脑也无法计算。
最终，我猜测 Buzz不会垮掉，毕竟背靠着Gmail这棵大树，但它也很难大红大紫。遥想Yahoo！Buzz当年，难道不是另一颗大受追捧，冉冉升起的明星吗？今天 谁还记得它人老珠黄。
From:http://ucdchina.com/snap/6229
【转载请标明出处，多谢】
最近在研究品牌如何演绎，当然，看的时候没有忘记本行，分析了一下他们的交互设计~~
上图采用胶片展示多组信息——大片展示品牌渲染。
利用胶片或者类似相册的展示方式，能够展示更多的信息，视觉焦点放到上部，用动态或者滚动的选择方式让用户继续浏览下去。
比较适合主题醒目，品牌放大的页面。
上图采用多图展示细节方式——展示品牌的细节品质优势。
品牌注重物品的质量和细节的设计。用多个单图表现同一个物品的不同细节，甚至可以做到放大每一个纽扣或皮质纹路。所谓好东西不怕看细节，用小图给用户造成一种高质的心理。
上图是点击某个细节后展示整个物品——强调细节和整体的关联。
细节和整体的关联，质量和款式表现，在看细节的同时，可以对比整体的款式，相互融合。有的时候我们在做设计的时候，往往追求“酷、炫”的效果，其实在表现实质需求的本质时，也不乏新颖的表现。
LV的网站的设计场景和出发心理：
整体品牌形象（告诉你，我是什么） 》 选中你关心的类 》 看看细节品质 》 不仅质量好，整体款式更好 》 引导购买
再收集一个例子（yoka）：
演绎搭配，不能单单的推给用户搭配好的物品，而是引导用户如何才能搭配出合适自己的装扮。也就是说简单的搭配列表也许满足不了用户的需求。
上图按照：你的现状是什么（调查） 》 看看其他人是这样的（达人秀） 》 你该怎么搭配（咨询引导搭配方式） 》 找到你的特点，开始搭配吧（上图右侧）
想到什么：
西贝学习到设计一个网站，不仅仅按照品牌推广的逻辑，单纯的采用交互技巧来满足用户的需求。其实，关注用户购物的流程方式，循序渐进的利用现实场景 模式进行引导也许会更好。一个简单的物品列表设计也许可以演绎出比较丰富的用户需求。不要单纯的从形式来表现需求，而应该深入的分析需求，按照用户的真实 场景，更加合理的表现形式。
上图是物品的列表——用不同造型的同类物品展示品牌趋势。
品牌引导流行趋势。
很多时候大家都会这样说“今年流行什么？流苏？条纹？ ”。
说明物品的品牌特点推广和物品的展示有一定的关联性。
上图很聪明的把造型相似的物品放到一起，体现造型的优势。但是本页面有个统一的特点，都是有金属配饰和细跟表现。顺理成章的表现了趋势和品牌的统一。
试想：造型不同或者类型不同的鞋子，放到一起，都是简单的物品，给一个统一的列表，有翻页。
如下图，这样就看不出品牌特点和造型优点。
通过以上的例子想到什么？
》 交互不仅仅考虑页面的排版。
》 交互设计要深入了解需求的本身。
》 交互设计可以把简单的东西变的更加让人接收，TA不仅仅传递了信息，还演绎了需求的内涵。
》 一个小小的改善，那怕只是列表的简单分区。只要处理恰当就可以得到意想不到的收获。
》 设计永远离不开思考用户场景。
》 交互可以考虑的更多，如何平衡产品价值和界面表现也有很多技巧可以使用。
相信大家对街边林林总总的房产中介并不陌生，那么我们先看看下面这张图片。
图1
从右侧这家店的橱窗里，我们能迅速分清哪些是租房信息哪些是售房信息。因为店家很贴心的将房产信息进行归类，并且在视觉上做了一些划分，让我们对信息能一目了然。借这个小案例引出我们今天要分享的话题：深广度平衡。
其实“深广度”本身并不是一个单一的概念。在网站的信息架构中，有一种组织结构叫做树形结构：网站首页视为链接层级中第一级，与其有从属关系的页面 视为链接层级中的第二级，一般称其为二级页面。通过二级页面又可以继续得到第三级页面，依此类推可以得到一个完整的树形链接结构。这样一个完整的链接结 构，我们称它为树形结构。
在整个树形结构中，链接的层数被称为网页链接的【深度】（depth）。而在树形结构里，最底层页面包含的页面总数被称为网页链接的【广度】（breadth）。
我们可以通过下面这张图来理解深度和广度的概念：
图2
我们回到开篇的小案例。左侧那店铺采用的是“只有内容链接的模型”（它们之间没有层级结构；链接没有模式可循；且没有某种导航方案将他们分离开）（注1）在这里每一条房产信息都可以看成一个内容链接，整个橱窗就像一张错综复杂的大网，让人头晕目眩。
而右侧的店铺采用的是“结构化浏览模型”（只有一组链接，作为获取网站信息的途径；导航区域与布局中其他内容有视觉上的分隔；要到达另一区域的某个页面，必须沿着树向上导航，再沿着另一个分支向下）（注2）店家将信息进行了规整，在房产信息上增加了一个分类，并且对不同类型的信息使用了不同的颜色，高效的将租房信息和售房信息区分开来。
一个网站的链接深度和广度最好有一个合适的均衡关系，深度过大的网站不利于用户快速获取信息，广度过大的网站则容易让用户在无数并列的超链接面前不知所措。
图3
图3的上图说明了又窄又深的层级系统，用户必须点击6次才能到达最底层的内容。对又宽又浅的层级系统而言（相对而言），用户必须从6个类别中选择， 才能找到6个条目。就像图3的下图所示，用户会面临主菜单上太多选项，而当他们选了一个选项，却没看到什么内容时，就会产生不良的观感。（注3）
我们再来看一张用户对于不同层级结构所需反应时间的图表（注4），图4：
图4
总共512项内容，组成了三种不同的分级方案，X轴是分级，Y轴是反应时间（秒）。可以很清晰看出，在过深和过广的分级方案上，用户所需要的反应时间都比较长。因此我们在组织网站信息的时候，需要仔细平衡深度和广度之间的关系。
我们在处理网站结构时，常常会使用按组分类的方法来组织信息。而信息的分类我们能使用时间序、主题或科目、地理、字母序、受众群体以及任务等方案。现在我们再来看看深广度平衡在web上的应用。
图5
这是某电脑公司的官方网站，他们的导航本身就是一个站点地图。他们将14项内容分级组成了一个两层的结构树，每个分支上都有3-4项内容。对于这样一个信息量不是很庞杂的网站来说，使用主题或科目的方案，将信息组成一个两层的结构树，就是一种深广度平衡的方式。
再来看个案例，图6是某软件官方网站的一个下载区块，这个区块里密密麻麻罗列了N个下载链接。有不同的版本、有不同的下载工具、有不同的外站下载。这些链接在没有进行任何组织的情况下呈现给用户，体验是非常糟糕的。
图6
对于那些信息量很大很杂的网站来说，单纯的使用某一种按类分组的方案已经不太适用了。一般来 说，广度比深度的效果更好。在深结构的各级别间选择，比起在广导航的各选项间扫视，要付出更多精力。眼睛比起鼠标点击（和页面载入）要快得多。虽然用户在 深结构更容易迷失方向，甚至可能迷路，但也不要在广度上走得太远。任何时候都把所有链接展示出来会吓倒用户，让他难以选择。用户会点击看起来适合他们需要 的第一个选项，或者干脆放弃，下图清晰的阐述了用户放弃率和深广度之间的关系：
图7
淘宝首页类目地图大概有300个类目，使用了三层结构将他们清晰得展示出来，每层类目都是4～12个之间，是一个深广度保持平衡的典型案例，图8：
图8
对于不同类型，不同信息量的网站，在深广度平衡上应采用不同的策略和方式。本文仅以个人在工作中的经验来对深广度平衡的方法论进行一些实例化的分享。对这方面有兴趣的同学欢迎留言探讨。
注1：摘录《Web导航设计》第1章 第一节 导航的需要（P6）
注2：摘录《Web导航设计》第1章 第一节 导航的需要（P9）
注3：摘录《Web信息架构》第5章 第四节 组织结构（P70）
注4：摘录微软论文《Web page design: implications of memory, structure and scent for information retrieval》
参考文献：
传统的翻页方式是“上一页+页码+下一页”，大家最熟悉的设计。
而近年兴起的这种“无尽滚动翻页”的翻页方式，即滚动条拖动到最底部后开始加载后面的内容，而不再有“上一页+页码+下一页”这样的链接。
相对而言twitter、Iphone app store这样的“递进式翻页”则没那么激进，保留了一个翻页按钮，是介于传统翻页与无尽滚动翻页的一种折中方式。
上图是Google book search一个巧妙的翻页设计，鼠标悬停在文档底部一个局部区域（高度约50px）时，出现一个半透明的层，点击这个层开始翻页。这个巨大的辅助翻页按钮，大大提升了翻页的便利性，且对界面影响很小。
这里讲到的翻页组件创新，是用新的翻页方式替代传统翻页组件。从信息的结构来看，传统翻页是将信息分段，而“无尽滚动翻页”属于信息滚动。这两种方式对应现实生活中的原型是：书籍和电影胶片，书籍把信息拆分到每页里去翻动，电影胶片的信息则一帧帧的滚动而过。
从信息流动速度和翻页便利性来看，“信息滚动”远远大于“信息分段”。这两种翻页方式应该如何选择？我想这应该取决于用户对后面内容的需求强度，像 google搜索结果页这种越往后信息质量越低的场景，用户对翻页需求并不那么强烈。Google reader这样不是按信息质量排序的场景，提供高速的翻页方式是个相对必要的做法。需要注意的是，滚动翻页不利于内容准确定位和信息回溯。
信息流动速度对信息接受者心态有很大影响，流动速度越快信息吸收量相对越小，所以阅读pdf文档比阅读纸质书籍心情急躁，忍不住去翻页，是在“扫描”而不是“阅读”（个人主观感受，如有雷同纯属必然）
由此也延伸出一点，交互设计师的工作职责除了架构信息，还应该控制信息的流动速度和供给量。
最后，以一张图片总结交互组件创新的四种方式，一家之言希望对大家有所启发。
常见的带条件搜索框是“输入框+下拉菜单+按钮”三个控件组成的，合适的控件组合可以带来更好的效果。
1、【输入框+下拉菜单】组合
新浪微博的搜索框，将下拉选项融合到输入框提示里，选择搜索范围的操作更加便利。
Google reader这样的带输入操作的下拉菜单，让下拉菜单更加易用。（这种控件组合在word、photoshop等软件里很常见，如字体选择控件）
2、【按钮+下拉菜单】组合
豆瓣与Flickr的搜索按钮后面加了一个下拉箭头，按钮与下拉选择操作合二为一 （flickr这个设计与它网站主导航条体验一致，豆瓣用这种设计在其整站看来则略显突兀）
标准的文件上传组件是由“输入框（伪）+浏览按钮+提交按钮”组成。之说以称之为“伪输入框”是因为它主要承担显示文件路径的作用，于是Firefox下点击这个输入框是开始文件选择操作，chrome更是把伪输入框改造成了按钮，还原控件最原始的作用。
使用标准文件上传组件经常会出现两个提交按钮，以上图为例，最经常的误操作就是：选完文件后，直接点击“保存头像设置”，于是杯具了。
Gmail附件上传的设计对文件上传组件做了两次瘦身手术。
过去的gmail附件上传步骤是：1、点击“添加附件”（点击后出现一个不带提交按钮的上传组件），2、选择文件（选完后自动开始上传）。去掉了那个提交按钮。
现在的gmail附件上传步骤是：1、点击“添加附件”（点击后自动开始上传，且有上传进度条）。去掉了输入框和提交按钮，只剩下一个浏览按钮，上传只需要一次点击操作。
交互设计是一个创造性的工作，利用创新的方式漂亮地解决产品问题，是一个交互设计师价值的体现。当创新的交互设计被用户认可、被业界同行学习，更是 一种巨大的职业满足感。这种创新不一定是惊天地泣鬼神的革命性设计，一个小小的交互组件的创新就可以让产品体验增色不少。今天就通过一些案例聊聊交互组件 创新的四种常见方式，与大家共勉。
我们先来回想一下阅读PDF文档的两种滚动方式：1、手型工具拖动 2、滚动条。
要翻看后面的信息，用手型工具向上拖动，用滚动条则是向下拖动，两种操作方式的原理是什么呢？
把文档分成可视区域A和整体区域B。滚动条滑块对应的是文档的可视区域A。因此滚动条拖动的是可视区域A，而手型工具拖动的是整体区域B，两种操作方式拖动的主体不一样，所以方向恰好相反。
滚动条可以理解为文档在垂直方向上的缩略图，滑块可以表示可视区域当前位置，可视区域占整体区域的比例。随着文档整体区域不断增高，可视区域所占的 比例越小，因此滑块高度不断变小。统计过IE、FF、Office等常用软件，一般滑块高度到8px时就不再缩小。当滑块高度只剩8px时，滚动条的拖动 体验就相当的差。
Google wave对滚动条做了大胆的创新。
1、 上下按钮与滑块连在一起（好处：从滑块到上下按钮的鼠标运动距离变短；问题：点击上下按钮，滑块无法跟随运动）
2、 滚动条的滑块高度固定不变（好处：解决了滑块极小的问题；问题：无法表示可视区域的比例）
这两处修改优化了传统滚动条的问题，却引发滚动条基本属性（“位置”与“比例”）问题。为解决引发的新问题，google wave的滚动条引入了两个新元素：
1、 半透明灰色块 （点击上下按钮，滑块无法跟随运动，则半透明灰色块运动——解决位置问题）
2、 终止条 （wave内容不断增多，终止条位置不断向下，用来表示内容整体高度——解决比例问题。可惜这个终止条视觉效果让人以为是可拖动的，容易引起疑惑。）
Google Wave花了这么大心思创新滚动条，也面临着滚动条复杂化后引发的用户习惯问题。个人认为这个滚动条创新是因产品需要而做的，wave一个页面可能同时存 在4个滚动条，当4个传统滚动条同时出现在一个页面上效果可想而知。Wave滚动条无论视觉还是交互上都是很“轻”的设计，与产品整体上还算贴切。
====================================================
苹果对滚动条的改进则简单有效：加锚点。
mac官网： 加锚点横向滚动条，点击锚点，滑块滚动到相应位置
iphone音乐专辑列表：加锚点的滚动条，轻触字母，列表滚动到相应位置
加锚点的方式让滚动条增加了导航和准确定位功能，变得更加易用。
http://ued.taobao.com/blog/2010/02/05/interactive-controls-innovation1/
相信大家对街边林林总总的房产中介并不陌生，那么我们先看看下面这张图片。
图1
从右侧这家店的橱窗里，我们能迅速分清哪些是租房信息哪些是售房信息。因为店家很贴心的将房产信息进行归类，并且在视觉上做了一些划分，让我们对信息能一目了然。借这个小案例引出我们今天要分享的话题：深广度平衡。
其实“深广度”本身并不是一个单一的概念。在网站的信息架构中，有一种组织结构叫做树形结构：网站首页视为链接层级中第一级，与其有从属关系的页面 视为链接层级中的第二级，一般称其为二级页面。通过二级页面又可以继续得到第三级页面，依此类推可以得到一个完整的树形链接结构。这样一个完整的链接结 构，我们称它为树形结构。
在整个树形结构中，链接的层数被称为网页链接的【深度】（depth）。而在树形结构里，最底层页面包含的页面总数被称为网页链接的【广度】（breadth）。
我们可以通过下面这张图来理解深度和广度的概念：
图2
我们回到开篇的小案例。左侧那店铺采用的是“只有内容链接的模型”（它们之间没有层级结构；链接没有模式可循；且没有某种导航方案将他们分离开）（注1）在这里每一条房产信息都可以看成一个内容链接，整个橱窗就像一张错综复杂的大网，让人头晕目眩。
而右侧的店铺采用的是“结构化浏览模型”（只有一组链接，作为获取网站信息的途径；导航区域与布局中其他内容有视觉上的分隔；要到达另一区域的某个页面，必须沿着树向上导航，再沿着另一个分支向下）（注2）店家将信息进行了规整，在房产信息上增加了一个分类，并且对不同类型的信息使用了不同的颜色，高效的将租房信息和售房信息区分开来。
一个网站的链接深度和广度最好有一个合适的均衡关系，深度过大的网站不利于用户快速获取信息，广度过大的网站则容易让用户在无数并列的超链接面前不知所措。
图3
图3的上图说明了又窄又深的层级系统，用户必须点击6次才能到达最底层的内容。对又宽又浅的层级系统而言（相对而言），用户必须从6个类别中选择， 才能找到6个条目。就像图3的下图所示，用户会面临主菜单上太多选项，而当他们选了一个选项，却没看到什么内容时，就会产生不良的观感。（注3）
我们再来看一张用户对于不同层级结构所需反应时间的图表（注4），图4：
图4
总共512项内容，组成了三种不同的分级方案，X轴是分级，Y轴是反应时间（秒）。可以很清晰看出，在过深和过广的分级方案上，用户所需要的反应时间都比较长。因此我们在组织网站信息的时候，需要仔细平衡深度和广度之间的关系。
我们在处理网站结构时，常常会使用按组分类的方法来组织信息。而信息的分类我们能使用时间序、主题或科目、地理、字母序、受众群体以及任务等方案。现在我们再来看看深广度平衡在web上的应用。
图5
这是某电脑公司的官方网站，他们的导航本身就是一个站点地图。他们将14项内容分级组成了一个两层的结构树，每个分支上都有3-4项内容。对于这样一个信息量不是很庞杂的网站来说，使用主题或科目的方案，将信息组成一个两层的结构树，就是一种深广度平衡的方式。
再来看个案例，图6是某软件官方网站的一个下载区块，这个区块里密密麻麻罗列了N个下载链接。有不同的版本、有不同的下载工具、有不同的外站下载。这些链接在没有进行任何组织的情况下呈现给用户，体验是非常糟糕的。
图6
对于那些信息量很大很杂的网站来说，单纯的使用某一种按类分组的方案已经不太适用了。一般来 说，广度比深度的效果更好。在深结构的各级别间选择，比起在广导航的各选项间扫视，要付出更多精力。眼睛比起鼠标点击（和页面载入）要快得多。虽然用户在 深结构更容易迷失方向，甚至可能迷路，但也不要在广度上走得太远。任何时候都把所有链接展示出来会吓倒用户，让他难以选择。用户会点击看起来适合他们需要 的第一个选项，或者干脆放弃，下图清晰的阐述了用户放弃率和深广度之间的关系：
图7
淘宝首页类目地图大概有300个类目，使用了三层结构将他们清晰得展示出来，每层类目都是4～12个之间，是一个深广度保持平衡的典型案例，图8：
图8
对于不同类型，不同信息量的网站，在深广度平衡上应采用不同的策略和方式。本文仅以个人在工作中的经验来对深广度平衡的方法论进行一些实例化的分享。对这方面有兴趣的同学欢迎留言探讨。
注1：摘录《Web导航设计》第1章 第一节 导航的需要（P6）
注2：摘录《Web导航设计》第1章 第一节 导航的需要（P9）
注3：摘录《Web信息架构》第5章 第四节 组织结构（P70）
注4：摘录微软论文《Web page design: implications of memory, structure and scent for information retrieval》
参考文献：
截止2010年1月15日，使用google搜索“用户体验设计”，返回1千3百万条结果。
“用户体验设计”无疑是这两年互联网行业最炙手可热的话题，而从我们成都UCD书友会火爆的现场来看，也的确如此。那么“用户体验设计”为什么会如此火爆呢？这需要从互联网的Web2.0革命说起。
这场革命，代表了互联网应用关注焦点的变迁，从以内容为王的门户型网站时代，转变为以用户为中心的互联网服务时代。以用户为中心的互联网服务，自然就需要以用户为中心的设计。但是要做到真正的以用户为中心的设计却并不简单。
这是什么意思呢？我想用彩程的实际经历对这个问题做出解释。和很多其它软件企业一样，彩程也是从一些中小型的企业网站、电子商务网站开发业务启程的。当时我们开发一个电子商务类网站的流程是什么样的呢？
首先会由超级打杂老妖出马，跟客户沟通，套出用户的需求，然后由费西或是老妖自己，三下五除二的搞一个首页出来，拿去给用户确认，用户如果点头，那 么ok，开始做首页的html切图，然后丢给程序员开始开发，同时，美工继续孤军深入，出各种特征内页，切html，交给程序员开发，如此循环往复。而一 旦整个项目开始进行，客户就很少再参与其中了。
于是，这个项目持续运行，直到某一天，程序员说：“好了”，这样，老妖满怀希望的冲到客户那里，很想听到客户对网站认可，但实际的场景往往是：
客户抱怨说，这里我明明是想要个Flash广告，但是却只有一张图片；这个订单系统怎么不好用，为什么不参考淘宝来做呢？我还想要个会员系统，每个会员有自己的个人页面。
这个时候，可怜的老妖只能作出两种选择，要么照单全收，ok，哪里有问题我给你改哪里，要么就是耍死皮，但是后面一种情况一般不会出现，因为老妖不愿因为得罪客户而丢掉奶粉钱。所以，这个原本大家都认为很简单的网站项目就这样被delay下去了。
这样的情况出现的次数多了，让公司首脑小s同学很不满意，于是他开始召集大家思考，这是为什么呢？让我们来看看之前我们的流程:
经过对这个流程的几个痛苦的日夜思索之后，我们发现了如下几个凄惨的现实：
1. 用户其实并不知道他到底需要什么，就算用户知道，你也别想知道他究竟知道什么；
2. 美工都以为自己只是画画的，而无需去考虑整个产品的设计思想，包括用户角色是什么，商业定位是什么，所以你说你想要个新闻栏目，ok，我照着163画一下就了事了；
3. 程序员都是脑残，只关注用什么设计模式或是用什么框架，美工的设计图对他们来说不值一提，不就是一个for循环生成li标签而已嘛；
4. 客户始终置身世外，他给钱了，只想你干好活，最后一手交钱一手交货罢了，但最关键的是，“货”这个东西，大家除了在最后一霎那能看到它的模样，其它大部分时间它都异常神秘。
很多时候，最大的问题往往在于我们不愿意去面对问题。所以当我们能把问题找到，并敢于面对问题的时候，解决办法的出现就只是时间而已了。这个解决办法，当时我们认为最优的，就是强化设计，最后发现，其实就是引入了“用户体验设计”。
从何入手呢？我们都知道，一般的软件开发流程中，PM会根据用户需求出产品需求分析报告，然后美工介入，出一些视觉界面，然后程序员根据有限的设计图连蒙带猜的进行实际开发。但在这样的模式下，产品会出现几次偏离。
PM只有几十页的文档，而这样的文档传递实际需求的效果极差，不能让用户确认需求，于是出现整个流程中的第一次产品与需求的偏离。美工在做视觉设计 的时候，就可能按照他自己的想法天马行空，最后出现整个流程中的第二次产品与需求的偏离。程序员在拿到美工有限的设计图后，大概想了想，觉得自己明白了， 然后就开始写代码，但是由于没有完整的产品模型到程序结构的映射，最终导致第三次产品与需求的偏离。这样带来的致命后果就是：用户明明想要个美女，但是最 终实际交付的却是个如花。
这样的流程最大的问题在于，缺少一个能够聚焦各方的核心，几十页的文档无法胜任，而原型却可以。
我们认为原型会很重要，于是我们首先引入了原型设计。在这个设计过程中，我们使用Axure作为辅助工具，它的好处在于，能让任何一个PM很容易的上手，并能把需求书中几十页的文字落地为实际的界面。
在PM快速完成原型设计之后，PM会带着原型去和客户讨论，客户由于能有实际的使用感受，所以能够很快的分辨出设计与他需求之间的偏差，然后PM根据用户的反馈修正原型。
接着，美工上场了，注意，这个时候，美工不再是美工，他有了新的title—视觉设计师。有什么新的要求呢？他需要仔细的去评估原型，从设计师的角度出发，对原型提出意见。接着，才是用PS将界面画出来，然后根据设计图制作另外一份原型—高保真原型。
高保真原型和之前的原型—也就是低保真原型–的差别在于，低保真原型着重完成信息元素的组织以及概念模型的搭建，目标定位在为产品搭框架，填充素材。但是高保真原型会完成对框架的装修以及对素材的组织。这样得到的高保真原型和实际交付的产物就几乎是100%趋近的了。
然后，产品经理会带着这份珍贵的礼物再次走访客户，根据客户的使用反馈做最后的原型调整，至此，整个原型设计阶段结束。
接下来，根据高保真原型，我们给出了整个原型的HTML代码，包括规范的CSS样式表以及JS接口，都由我们的前端工程师定义并实现。
最后，我们交到产品实施人员手里的就有两样东西，一是高保真原型，一是HTML框架代码。我们希望高保真原型能真实反应用户需求，并且让实施者知道 开发出来的东西是一个什么样子的。其次，通过提交高质量的html代码，减少普通程序员的工作量，因为不可否认的是，如今复杂的前端技术不是一个普通的 java程序员能短时间掌握得了的。
所以，最后我们的第一版用户体验设计流程就是这样的：
这样的流程解决了我们之前的哪些问题呢？
首先，原型能够成为客户和项目经理之间的沟通媒介，极大地降低沟通成本；其次，美工获得了解放，从被动画图，转为通过原型真正的参与到了产品设计的 流程中来；然后，程序员能通过原型知道自己要做出来的东西究竟是什么样的；最后，再通过提交完整的前端代码，把传统程序员的前端短板一并解决了，这个流程 就似乎已经非常完美了。
那么实际情况呢？首先需要承认的是，这确实是一个飞跃。我们自己的网站项目都得以顺利的实现，不再有delay的情况，而客户的反馈也非常良好。但是当我们想以外包服务的方式将用户体验服务提供给客户的时候，就出现了问题。
首先的问题是，外包形式的用户体验服务，我们的服务对象从最终用户变成了外包服务购买者，这使得和有效用户进行沟通的成本上升了，在需求调研的时候，感觉难以对最终用户进行定位。
其次是，我们发现低保真原型和高保真原型极有可能变成内部的闭门造车活动，拿出一个完善的原型往往持续很长的时间，而客户的产品经理或者项目经理没有在设计途中参与进来，所以当拿出最终的高保真原型的时候，我们自己的设计师就变成了客户的产品经理。
最后的问题是，我们交付给程序员的前端代码太多，导致这样的朴素的心理问题出现：我是程序员，如果我拿到一份不是我写的代码，我就有很强的畏惧心理，不愿 意去看。这样，实际的开发过程中，有很多前端的问题会压到我们团队头上，因为任何一个前端功能的开发，客户的程序员都可以说，前端代码不是我写的，我不 会。
好吧，问题当然是不会结束，但我们还是选择解决问题。
关于难以对最终用户进行定位，我们在做需求分析的时候加入角色分析环节来帮助我们完成这个任务。在《设计沟通十器》这本书中，罗列了角色分析文档所需的各个要素，我们选择其中最重要的，用户基本信息、动机、场景、对应需要实现的产品功能来完成角色分析文档。这份文档帮助我们建立起了最终的用户模型，因此我们在做原型设计时，就有了最终用户的标准参照物。
其次，我们在设计原型时，尽量和客户一起设计，也即是用很高的迭代频率和客户交流，甚至时常驻点在客户那里进行设计，让客户随时了解到我们的原型长成什么样了。
然后，在原型设计阶段加入了可行性分析这一环节，提前将程序员拉入设计。和把客户拉入设计一样重要，需要程序员在早期就介入到对设计的评估，包括对后端数据以及前端逻辑实现难度的确认。这个环节确保在后期开发的时候，程序员能有所准备，杜绝了推卸责任的现象。
最后，我们拆分了前端代码开发部分，将前端开发工作改为提供两份文档，一份是视觉规范文档。这份文档详细的提供了视觉界面设计的规范，比如字体规 范、是否自适应宽度，各种配色组合等等。另外一份就是开发指南，包括在可行性评估中得出的有难度的前端部分的示例代码，和相关的接口文档。这两份文档主要 在于鼓励程序员真正介入前端开发。有问题也不要紧，我们会按项目的实际情况，为客户提供不同时间的现场技术支持。
这样，就得到了目前我们使用的流程：
彩程UED流程图
那么，这样的流程实施的效果怎么样呢？我们来实际看一个例子。这个例子是给四方科技的一款网络优化平台提供用户体验设计服务。
首先是对产品进行商业目标需求调研，在了解到这款产品的基本商业目标定位后，我们便开始了用户角色分析。我们首先把产品的最终用户分为两类，一类是 管理层，他们最大的愿望是，一眼掌握自己企业的网络使用情况，想知道自己为什么发封email都会这么慢。当他们一眼发现自己企业网络出现异常后，接着他 们需要把优化网络的任务下派给一个下级，这个下级可能就是人事部经理或一个网管。他们的最大愿望是，确保公司网络的正常运行，完成老板下达的任务。
角色分析
有了这样一份角色分析文档，接着我们的低保真原型设计就会围绕角色的动机和场景来进行。下面我们来看看首页设计：
低保真原型
可以从这个流量监控的首页看出，如果我是老板，很容易掌握的几个信息是：今天公司网络的整体流量情况，现在哪个员工的流量最高，是否正常。有了这几 个信息，我就大概知道我自己发邮件，之所以慢，是不是由于内部网络原因引起的。如果是，这时候我就会抄起电话打给人事部经理或是网管，让他给我解决问题 了。
人事部经理得到这个任务后，就会通过平台的流量实时监控页面，找出究竟是哪部分的流量出现了问题。然后在上网控制页面，修改对应的网络策略即可。
围绕角色文档的低保真设计之后，我们的视觉设计师会基于低保真原型出视觉设计图，并将其作为素材制作高保真原型。最终的高保真原型就是这样的：
高保真原型
高保真原型结束后，紧接着是两份文档的编写，一是这样的一份视觉规范文档，我们看到这份文档中包含了页面布局定义、字体的字号以及颜色、所有控件的颜色定义等。
接下来是一份开发指南文档，其中给出了一些复杂控件的前端代码实现参考，供程序员在实际开发时使用。
最后，我们在用户现场完成了4个工作日的现场技术支持服务，解决了一些html框架搭建，切图等前端技术问题。
这就是我们的用户体验设计流程以及方法。它并不是完善的，甚至可能全盘错误，比如在如何为用户提供更好的前端开发的帮助方面，我们还在进行各种尝试。没有不变的流程，只有不断探索。
最后，我想回归到“用户体验设计”本身。用户体验设计的出现，只是代表传统软件行业在互联网时代开放、共享、自由的氛围中的一种进化需要，而它最终 会和整个软件产品的研发流程融为一体，成为无论是从需求分析、到界面设计再到开发到运维的一部分，因为我们随时都需要将用户置入服务的核心，用我们的爱来 浇注产品本身。
来源：http://blog.mycolorway.com/2010/01/23/our-ued-flow-method/
