用户体验从产品设计阶段便开始介入进来，如原型设计中交互模式设计、功能实现方式设计都融入了设计人员对用户的关怀，听过这样的一句话：“具有良好用户体验的产品，不仅仅取决于一个有着丰富交互设计经验的产品设计师，还与产品生产过程中的每一个环节是否都具备良好的用户体验意识有一定的关系”。
今天我想从一个页面重构工程师的角度出发，从两个方面去谈谈在我的工作中，我所理解的用户体验，以及我做了哪些和用户体验有关的事情。

一、 从可用到易用的细节处理

1. 按钮、链接、导航菜单的鼠标触发状态、鼠标手型等

随着视觉设计的发展，对按钮、链接、或者导航菜单的表现方式变得异常丰富，比如:

这些图片丰富了对鼠标点击形式的视觉表现力。在基于功能可用的前提下，逐渐通过视觉渲染达到美化的效果，有了精美的设计图后，就需要页面重构工程师们加以切割，在代码化的过程中，通常要做如下考量：

• 可点击区域大小，例如（下图）尽管风格上似乎按钮只有10*10，但是在实现时，要考虑用户操作起来是不是很容易获取锚点，而不是点来点去找不到
  
  
• 鼠标操作类型的提示，鼠标输入提示、手型提示、文本区域提示、不可点击提示，尽管整个页面的视觉引导更重要，但用户在操作时，人眼一直跟随着鼠标或键盘的操作而转换，如果能伴随着正确的鼠标操作提示，更可增强引导作用。从而提升交互体验。
• 按钮风格的一致性，按钮当前状态和点击状态的统一，按钮按照功能所作的统一，
  设计师天马行空的想象力，赋予了他们创造性，而我们既要保留他们的创造力还要抽象出一些共用特征，在我看来按钮类型有3种，如果能有效区分，对网站的整体风格的建立和强化交互感受方面都会有一定一致性，同时在页面构建过程中会抽离成公用信息，非常便于管理和维护。

1. 1）如确认、取消等，可称之为贯穿型
2. 2）如登录、加关注等，可称之为点睛型，这一型在实际工作中通常从视觉上都略强于贯穿型，所以会建议设计师做一定统一，有时候是风格上，有时候是结构上，再甚者就是大小比例上
3. 3）如发博文、发微博等按钮，可称之为增强型，通常这个类型不会限制设计师按照标准类型去做，即便出来的是个异型，我们还是应该理解的。
4. 4）最后就是无论哪种类型，都要注意是否有鼠标点击的hover状态，即便设计师没有设计，也要做出hover的交互效果，至少是预留，就我而言通常都是在原按钮颜色基础上调整一下颜色深度作为hover状态，大部分按钮我都会考虑做出交互效果，当然也有例外，比如活动专题中的点击区域，通常不会增加点击后的过分明显效果，如果非要做出一点效果，最多是调整一下文字本身的明暗度。（我承认我有些吹毛求疵）

2. 图片的alt解释信息

通常拿到设计需求，我会要求设计师帮助梳理icon，一般会分两类，功能型、注释型。同时要求两种类型图片的像素区间要各自保持一致性，这样一来设计师在整理的过程中就会意识到，有的文字没有必要加注释图片，有的是功能和注释类型的大小、风格可能不一致，梳理过程中设计师会去调整一下，同时也在创意的过程中渗透一些规则。

第一、二行是注释型，第三行是功能型

3. 因设计或排版而没有完全显示出来的文字信息的title提示

产品或用户经常抱怨“后面的文字看不到，这到底是什么内容？”之所以出现这样的情况，主要是没有考虑到文字信息出现的位置和当时这些文字的重要性，如果是图片瀑布流，那文字信息的作用只是索引而已，如果是文章列表页或视频列表页、甚至正文页这样的终极页面，标题名称是务必要全部展示的。所以为了避免折磨用户，一定要给显示不完全的信息增加title，在存在缺陷的情况下也能有让用户有些许安慰，否则你就太伤用户的心了。

4. 网站logo的权重设置H1、网站主要标题、标识的权重设置H2-H6、stong、em、b等(对搜索引擎的友好可读性)

考虑各个层面的用户体验，是为了让用户尽量全方位的感受到网页的无边界浏览，在视觉和交互充分发挥作用的背后，代码标签的选择，也从一定层面决定了用户是否能够更好的使用，目前的一些搜索引擎，如Google、Baidu等，在过滤网页信息的过程中，有一套机制去寻找你网页中的主要内容，那些对搜索引擎比较友好的标签会更有利于页面信息的抓取，在用户搜索的过程中，抛开企业间战略合作不谈，也会相对显示在比较靠前的位置（当然如果搜索引擎的广告效益非常好的时候，或许第一屏还是与你无缘，这……你懂的）

5. 网站字色的一致性，链接色、提示色、内容字色等 （降低学习成本，培养用户习惯）

设计一套互动类产品（博客、视频、邮箱）或者用户功能型产品（消费类产品、资讯类产品等）同样面临着一个问题，用户习惯，人其实对规律会更容易产生安全感也更容易增加舒适性。所以在网页的设计过程中，统一视觉感受不仅让用户安心的舒适的去浏览图片文字音乐多媒体等信息，也能培养用户认知。
因此在设计师天马行空的创造力面前，我总是横亘在他们面前的那个规范和逻辑的卫斗士。当设计师天马行空的时候我是不会也不敢去干扰他们，但如果谁告诉我风格确定时，我就会站出来披荆斩棘，要求设计师给出一整套设计规范，例如：
• 链接色分主链接色和辅助链接色，建议不要超过2种，增加类功能区域除外
• 文字色也是主辅都要有，同样不要超过两种（其实有多少种都可以，但你要考虑用户花多长时间适应你的五花八门）
• 提示信息又分普通提示、正确提示、错误提示、空状态提示等
• 什么图标类型分为功能型图标和注释型图标

6. 各种内容读取花较长时间的模块，在内容尚未加载成功时，先显示图片图片列表页、或视频截图列表页面，在图片尚未加载时显示初始图片，并固定位置，防止满屏跑图

7. 提示性文字位置在不干扰用户操作的前提下，交互一致性很重要，如固定在某一提示位置或不影响操作的颜色提示等

在处理表单过程中，会考虑提示信息所在位置，包括默认提示，出错提示，正确提示等，如果提示风格不统一，会中断用户行为，页面表单填写过程中的流畅度非常重要，为什么会提起这一点，因为在实际工作中，如果没有交互设计经验，不论产品还是设计人员都经常会遗漏表单相关的各种提示信息，但这会影响页面构建过程中HTML的结构，因此如果前期发现产品文档，或者设计稿都没有表现出相关内容，不妨提醒他们务必考虑并添加好，减少后期调整页面结构的冗余工作量。

很多人会说这些不是页面范畴，那页面是什么范畴呢，这些知识有产品范畴的、有设计范畴的、有用户研究范畴的、有交互范畴的，在我看来会这些最大的好处是减少你的工作量，我认为这些都是很基础的知识，不是必须掌握的，但最好了解，了解的好处非常显而易见，就是面对不一定靠谱的需求时，可以有的放矢的给出一些意见，从而减少一些返工，或者细碎的体验的增加。

二、从慢慢等待到愉悦点击的变化

1.页面模块的按需加载

由于互联网产品发展愈来愈趋向于规模化和正规化，在早年间采用全站只加载一个公用样式的时代已经过去了，取而代之的是对性能更优的模块化按需加载模式，如上图所示，模块化显而易见的好处就是代码冗余相对较低，代码量也较小。除此之外模块化的好处还包括：结构清晰，易上手；频繁变更产品需求时的快速维护和开发；快速下线局部模块；动态调整页面模块加载优先级时，无需剥离任何代码；便于多人协同开发；降低多人协同开发时，互相覆盖代码；适合开发大型产品等很多优点。不论对用户，还是对维护开发都是非常有利的。

2.页面公用元素复用

所谓公用元素，主要指：

reset类型

各类文字色

各类链接色

浮层框架

页面主框架

适用于本站的高复用补丁类型

3.文件调用的层级酌情减小、文件名酌情缩短

如，image/index/module1/limoumou/icon/fabiaopinglun.jpg 酌情优化目录层级
如，fabiaopinglun_default.jpg 、.CommentListContent_linedot{} 酌情优化文件名长度

4. 请求数量和背景大小均衡处理

图片请求数方面，有时候你要考虑CSS Sprite 拼合图片减少背景数，同时还要注意拼合图片K数不要太大，以及拼合图片注意纵横比，建议拼竖图（做过实验，同样内容，横图体积大于竖图）
当背景图片需要平铺时，请酌情考虑背景图片大小，比如1px高的虚线，请不要切一个1*2的小图，比如1*10,1*50，主要考量在于1*2的小图的平铺次数。
影响页面性能的因素还有很多，例如hack的使用、position的使用, table的使用等等……关键是保持技术的新鲜，丰富自己的知识。

以上文章只是沉淀了一下过往我在页面重构工作中所领悟的用户体验。略显肤浅，可能大家会质疑，为什么写页面的还要自己加图标状态或者修改局部效果，要知道在早期的互联网在分工上没有现在这样精专的分工，顶多分个前台、后台、产品。当然在当初这些事情不一定有如今的专业深度，但涉猎面的确较如今是更宽阔的。所以早几年开始从事网页制作的朋友，都不会对设计制作界定的那么明显，在图形图片处理方面也是有一定认知和操作能力的。不是为了显摆什么，只是觉得知识的深度和广度同样重要。

事实的确如此，人类总有一种惯性，即使有最好的意图，也是说一套做一套。用户也不外乎凡人的本性，那么，我们如何快速的发现用户在进行测试时是真心还是假意呢，下面就是我作为一名小实习生的一些小感想，写出来与各路仙儿分享。

用户真的会“掏钱”吗？

用户测试的目的究竟是神马？

通常我们只是停留在了解产品是否易用、好用的层面上，但是，请别忘了还有更深层次，那就是用户对产品是否想用。而前者就是我们通常在做的可用性测试，后者我们姑且称为价值测试。

大多数测试人员最后只是简单询问用户“愿不愿意购买”产品就草草结束了一次用户测试。其实你知道吗？用户的惯性回答“也许”或者“会”，只是用户碍于你的颜面，在对你华丽丽的说“不”而已。

那么，测试人员要怎么问才会得到用户的真正“心意”呢？在这里，前ebay副总裁Marty Cagan给了我们一个简单的评判方法：我们可以抛出一个问题，“你是否愿意把产品推荐给同事（或其他你在意的任何人）”，之后我们再让用户以推荐值自己打分，0代表极不愿推荐，10代表相当愿意推荐。答案很简单，只有用户打9-10分才是真心大爱，表示用户真的会“掏钱”使用我们的产品；用户打5-7分只是出于礼貌的敷衍你，表示对我们的产品根本不感冒。

图一：《启示录—打造用户喜爱的产品》和作者Marty Cagan

总的来说，我们在搞清楚“用户是否会买产品？如果不会，原因是什么？”之前，不能终止用户测试。当用户研究人员的工作告一段落时，产品经理会接手跟进讨论，试图找到问题的答案。开展价值测试时，我们必须对一些细节保持关注，他们往往是成功的关键。在调查“要怎么做，才能说服他们购买该产品”时，我们可能会发现这些人并非我们的目标客户，还有人更需要我们的产品，或者发现产品所解决的问题不是用户所关心的，改进产品，让它真正解决用户的问题，产品才会更有价值。有时是解决方案出了错，有时是盈利模式不对，只要多加留意，稍做调整，结果会好很多。

记忆是“骗人”的

从认知心理学角度讲，我们的记忆不是照片式的，而是不断被建构的，随着信息的不断进入，有可能被悄悄的修改。因此，我们印象中某个用户表达的观点或者意愿，其实和我们记忆中的也许并不一致。此时，完整的记录可以帮助我们避免这一问题。

我们需要对用户的言行有清楚的认识。也许用户自己根本不知道想要什么，这是很多用户的普遍心理。永远不要指责用户的无理取闹，就像不要指责女生的善变。如果你足够把她放在心上，你应该会知道她喜欢什么，想要什么，会买什么。她的每一次浏览，每一次点击，每一次购买其实都在告诉你她喜欢什么，想要什么，这些都是用户给我们的机会，请不要浪费掉。

用户的态度是会随时间改变的，有时可能面对不同情景的压力同一位用户的态度会决然不同。那么什么时候测量态度才能成功地预测行为呢？

我们最好是在同一时间测量态度和行为。曾有心理学家进行过研究挖掘，得出一些导致态度与行为一致的因素：
1. 态度的显著性 如果你对某个人或某件事的态度非常明确，那么它便具有显著性、重要性，容易从记忆中提取。态度越明确，它就越能预测个体的行为。
2. 情景的压力 在某种特殊的情景中外在压力很大，以至于使人们的内心想法对行为丝毫不产生任何影响。

用户常常言行不一，源于他们很多时候意识不到自己行为的真相。众所周知的例子，Sony公司引入 Boom Box 概念的时候，召集了一些潜在用户组成焦点小组来讨论这个新产品应该是黑色还是黄色。此时每个测试用户都认为消费者应该更倾向于黄色。会议以后，组织者告诉他们在离开前可以免费带走一个 Boom Box 作为回报，结果是每个人拿走的都是黑色！此前对态度的评估竟然完全推翻了真实的行为。

图二：黑色Boom Box

欢迎出声思维

用户在进行测试时出声思维，就是让用户集中于如何与产品进行交互的意识流。这是运用于可用性测试过程获取用户数据反馈的有效方法。如果测试中的氛围比较平等、自然、融洽，用户又特别愿意表达，那么用户就会在进行任务操作的同时，表达他们想做什么、打算如何做、背后的原因是什么。此时，不仅是操作行为、用户表达出来的想法和原因以及语言中透露出的疑惑、失望、不满、惊讶、犹豫等情绪同样是需要我们加以关注的。

出声思维最初由Lewis在IBM公司提出，之后被Ericsson 和Simon进一步修正。该方法要求用户在完成一系列由测试人员设定的任务过程中，口述出自己所看所想所感受的，以帮助我们观察并获得第一手反馈。我们在整个测试过程中被要求，客观全面的记录用户所说的每一句话，不能打断用户的行动和表达。该方法的目的是明确“谁”在完成特定的任务时出现了什么样的“问题”，强调特定的用户和特定的问题。

微表情正在出卖你

在2009年的美剧《LIE TO ME》里面男主角Lightman说，“普通人在谈话中每十分钟就会撒三次谎”。这部以微表情识谎为题材的美剧引发了大洋彼岸的LIE TO ME门。

微表情，是一个心理学名词。人们通过做一些表情把内心感受表达给对方看，它一般只持续不到五分之一秒，如果超过一秒那就是在撒谎了。微表情一闪而过，通常只有10%的人察觉到，甚至连作出表情的人和观察者都察觉不到。

比起有意识做出的表情，“微表情”更能体现用户真实的感受和动机。 虽然测试人员会忽略“微表情”，但是我们的大脑依然受其影响，而改变对用户表情的理解。所以如果用户很自然地表现“高兴”的表情，且其中不含有“微表情”，就能断定这是真心高兴。但是如果其间有“嗤笑”的“微表情”闪现，就算你没有刻意去察觉，你会更倾向于认为这张“高兴”的面孔是“狡猾的”或“不可信的”。

图三：真的笑容，表现在眼角纹的上翘

需要说明的是，微表情是无意识的，不是通过选择而做出的，因此是用户无法控制的，并且和国籍木有关系。它能够发掘深埋在人类脸部、身体和声音里的线索，然后将用户的真心昭示天下。

下面是一些有趣的用户行为，当用户出现下列行为时，表明他的话是有质疑的，需要我们自己判断或者进一步挖掘可信信息：
1. 问题的生硬重复是典型的撒谎，如“你用过微名片吗？是的，我之前有用过几次”。
2. 嘴角略微翘起or单边耸肩or下意识的摊手or摩挲自己的手or抿嘴两次，都是一种自我安慰的表现。表明用户对刚刚的话毫无信心。
3. 如果用户对我们提出的问题表示不屑，通常这些问题会是用户内心肯定的声音。
4. 手放在眉骨附近表示用户羞愧回答这个问题，我们需要赶紧换种方式巧妙的引导。
5. 真正的吃惊表情转瞬即逝，超过一秒都是假装的。
6. 当用户想要隐瞒的时候，鼻子下方的海绵体这块就会痒，尤其是男性用户，要小心喽。
7. 用户在陈述时眼球会向左下方看，这代表大脑在回忆，所说的是真话，而谎言是不需要回忆的过程的。
8. 用户在描述一连串测试的流程时，能否流利准确地进行倒叙是判断其是否说谎的标准之一，因为谎言通常都是按时间顺序编造的。
9. 用户撒谎时并不像惯常理解的那样会回避对方的眼神，反而更需要眼神交流来判断我们是否相信他说的话。所以，必要时刻，请死盯用户。
10. 人在害怕时会出现生理逃跑反应：血液从四肢回流到腿部（做好逃跑准备），随之手的体表温度下降。因此，我们可以在邀请用户前来跟临走时分别与他们握手，作为用户是否说了谎话想快点逃脱的参考。

总结一下

本文仅是对用户观察中发现的一些小技巧，在背后其实还有许多的理论支撑，如情绪理论、神经营销与眼动追踪、微表情训练工具(Micro Expression Training Tool, METT)的使用、瞬间互动研究、面部行为代码系统（Facial Action Coding System， FACS）等。但是，无论哪一种方法或者工具，都没有绝对的完美。当我们在真正面对用户的时候，要组合多种研究方法，并根据研究目标和数据整理分析工具以及预算和研究时间等来做合理的取舍。

再次申明，以上仅是将烦人的理论生活化的一些小思路，欢迎探讨，拍砖即可。

iOS Web App开发，配合HTML5，是目前比较热门的话题。今天，先抛开HTML5，我们来尝试在PhoneGap框架上进行简单的开发。

PhoneGap是一个使用HTML，CSS和JavaScript的，创建移动跨平台移动应用程序的快速开发平台。它使开发者能够利用iPhone，Android，Palm，Symbian,WP7,Bada和Blackberry等智能手机的核心功能——包括地理定位，加速器，联系人，声音和振动等，此外PhoneGap拥有丰富的插件，可以以此扩展无限的功能。PhoneGap是免费的，但是它需要特定平台提供的附加软件，例如iPhone的iPhone SDK，Android的Android SDK等。

PhoneGap的优点：

1、兼容性。完全做到了written once, run everywhere。

2、标准化。PhoneGap用W3C标准，特别标准，Web App直接一字不改就能运行。尤其是和JQ Mobile结合在一起使用，实在是威力无穷啊。

3、配合使用JavaScript+HTML5，潜力巨大。

当然目前PhoneGap缺陷还是蛮多的，比如运行速度慢，UI反应延时——这是个致命伤。不过嘛，这种问题是会随着技术的进步而消失的。它的优势是无以伦比的：开发成本低（包括跨平台）。当然，Native App永远会有一席之地，比如高端游戏。

一、 开发准备

1、首先需要一台运行苹果系统的电脑，装好Xcode，如果需要真机调试，还需要开发者证书。

2、去http://phonegap.com/下载最新版的PhoneGap，目前是1.3版本。

3、把下载完的zip文件解压缩，双击运行里面的一个dmg镜像，进行安装。

4、打开Xcode，新建工程，就会看到PhoneGap-based Applicaton，就是它了。

二、 注意事项

1、 用PhoneGap-based Applicaton向导生成工程以后，按command+B，生成一下。打开工程文件所在的目录，就会看见一个www的目录，拖拽到Xcode中，选择引用即可。强调一下，必须选择引用方式，这样www目录在Xcode中是蓝色的。www目录下放的就是web端的一些文件（html/css/js/image）。

2、 在PhoneGap中，如果需要访问外部链接是需要授权的，在phonegap.plist文件中可以看到，有一个ExternalHosts数组，里面可以配置。顺便说一下，Plugins下可以清楚的看到，可以使用iOS的本地核心组件，例如相机，联系人等等。

三、 例子说明

例子很简单，在向导生成的基础上，加上了模拟Path应用程序的左下角的快捷菜单功能，并且通过PhoneGap框架调用iOS的Camera模块。先来看看截图吧：

基于PhoneGap框架的开发非常适合有web开发经验的开发者，因为里面基本上都是Html/CSS/js。比如快捷菜单的功能，在html文件中代码如下：

<footer class="op-footer">
      <a href="javascript:photo();toggle_menu();"><img id="path_photo" class="path_icon" src="image/icon/1.png" /></a>
      <a href="javascript:toggle_menu();"><img id="path_people" class="path_icon" src="image/icon/2.png" /></a>
      <a href="javascript:toggle_menu();"><img id="path_place" class="path_icon" src="image/icon/3.png" /></a>
      <a href="javascript:toggle_menu();"><img id="path_music" class="path_icon" src="image/icon/4.png" /></a>
      <a href="javascript:toggle_menu();"><img id="path_thought" class="path_icon" src="image/icon/5.png" /></a>
      <a href="javascript:toggle_menu();"><img id="path_sleep" class="path_icon" src="image/icon/6.png" /></a>
      <a href="javascript:toggle_menu();"><img src="image/path_menu@2x.png" width="40" id="path_button"/></a>
</footer>

CSS中的op-footer让按钮在左下角，toggle_menu函数用于扩展和收缩菜单，photo函数调用系统拍照功能。

function toggle_menu()
{
	if( $('#path_button').hasClass('path-extend') )
	{
		// 收缩
		$('#path_button').removeClass('path-extend');
		$('#path_photo').animate( { 'left' : '10px' , 'top': '10px' } , 200 , function(){} );
		$('#path_people').animate( { 'left' : '10px' , 'top': '10px' } , 180 , function(){} );
		$('#path_place').animate( { 'left' : '10px' , 'top': '10px' } , 160 , function(){} );
		$('#path_music').animate( { 'left' : '10px' , 'top': '10px' } , 140 , function(){} );
		$('#path_thought').animate( { 'left' : '10px' , 'top': '10px' } , 120 , function(){} );
		$('#path_sleep').animate( { 'left' : '10px' , 'top': '10px' } , 100 , function(){} );
	}
	else
	{
		// 扩展
		$('#path_button').addClass('path-extend');
		$('#path_photo').animate( { 'left' : '-5px' , 'top': '-100px' } , 100 , function(){} );
		$('#path_people').animate( { 'left' : '31px' , 'top': '-94px' } , 120 , function(){} );
		$('#path_place').animate( { 'left' : '59px' , 'top': '-78px' } , 140 , function(){} );
		$('#path_music').animate( { 'left' : '82px' , 'top': '-56px' } , 160 , function(){} );
		$('#path_thought').animate( { 'left' : '98px' , 'top': '-25px' } , 180 , function(){} );
		$('#path_sleep').animate( { 'left' : '104px' , 'top': '10px' } , 200 , function(){} );
	}
}
function photo()
{
// 通过PhoneGap框架调用iOS的Camera模块
navigator.camera.getPicture(function(imageURI){$('#refresh_image').attr('src',imageURI);},
function(message) {alert('get picture failed' + message );},
{
			quality: 50,
			destinationType: navigator.camera.DestinationType.FILE_URI,
			sourceType: navigator.camera.PictureSourceType.CAMERA
		}
    );
}

可以看到，这些js中的函数都使用到了jQuery，非常方便实用。

四、 总结

基于PhoneGap框架的iOS Web App的开发真的很方便实用，把工作量都转移到了Web开发，但也是有代价的，性能上肯定不如Native App高效，在一些用户体验需求不是很强的地方可以考虑使用。

Comet是指基于HTTP长连接的“服务器推”技术，是一种新的web应用架构。基于这种架构开发的应用中，服务器端会主动以异步的方式向客户端程序推送数据，而不需要客户端显示的发出请求。非常适合股票交易行情，聊天室等交互性和实时性要求很强的应用。

长轮询（Long Polling）是Comet的一种实现方式，也是Facebook，Plurk实现动态更新内容的方法，具体原理是发送一个长时间等待的request，当服务器有资料response的时候立刻断掉，接着再发送一个新的request。

我们这里使用新浪微博的openAPI做我们的数据来源，我们需要每隔5秒中推送5条最新的微博内容到客户端，由客户端进行呈现。

我们先来看下前端部分的代码，这里使用YUI3作为基础框架。

<script type="text/javascript">
YUI().use('jsonp','node-base',function(Y){
	var handler = function(response){
		var s = '';
			for(var i=0;i<response.length;i++){
				s +='<li class="MIB_linedot_1">';
				s +='<div class="head_pic"><img src="'+response[i].user.profile_image_url+'"></div>';
				s +='<divm class="MIB_feed_c"><p class="sms"><a href="#">'+response[i].user.name+'</a> : '+response[i].text+'</p></div>'
				s +='</li>';
			}
			Y.one('#weibo').prepend(s);
			Y.jsonp('http://127.0.0.1:8000/stream?callback={callback}',arguments.callee);
		};
		Y.jsonp('http://127.0.0.1:8000/stream?callback={callback}',handler);
	});
</script>

我们看到在浏览器端我们使用JSONP的方式来取得服务器端的数据并执行回调，每次收到服务器端的数据并处理后会再次发起一个JSONP的请求来保持与服务器端的连接。

下面我们看下服务器端的代码是怎么样的，这里不在讲述Node.JS的基础问题，有问题的同学可以去http://nodejs.org查看相关文档和介绍。

首先需要引入Node.JS的相关API

var http = require('http');
var path = require('path');
var qs = require('querystring');
var fs = require('fs');
var url = require('url');

接下来我们要创建一个客户端请求来请求微博openAPI的接口数据。

var weibo_client = http.createClient(80,'api.t.sina.com.cn');

然后创建http服务，发送内容到客户端。

var server = http.createServer(function(request,response){
	var uri = url.parse(request.url).pathname;
	var callback = qs.parse(url.parse(request.url).query).callback;
	console.log(callback);
	if(uri === '/stream'){
	//定时从api得到需要的数据
	setTimeout(function(){
		var client_request = weibo_client.request('GET','/statuses/public_timeline.json?source=3364481477&count=5',{'host':'api.t.sina.com.cn'});
		//对返回的数据进行处理
		client_request.on('response',function(res){
			var body = '';
			res.on('data',function(data){
				body += data;
			});

			res.on("end",function(){
				var weibo = JSON.parse(body);
				if(weibo.length > 0){
					response.writeHead(200,{'Content-Type':'text/javasript'});
					var text = callback + "("+JSON.stringify(weibo)+")";
					console.log(text);
					response.write(text);
					response.end();
				}
			});
		});
		client_request.end();
	},5000);
	}else{
		load_static_file(uri,response);
	}
});

在上面的代码中当客户端连接到服务器端请求数据的时候，我们就每隔5秒去请求一次openAPI的接口，获取到最新的5条feed信息，通过监听clientRequest的response事件来获得最新的数据。通过监听clientRequest的end事件对获得的数据转换为JSON格式的字符串并推送到客户端去。

最后我们开启http服务就可以了。

Server.listen(8000);

下面是该程序的所有代码：

Client:

<!DOCTYPE html>
<html>
	<head>
		<title>weibo stream</title>
		<link href="http://img.t.sinajs.cn/t35/style/css/common/index.css" type="text/css" rel="stylesheet" />
		<script type="text/javascript" src="http://yui.yahooapis.com/3.3.0/build/yui/yui-min.js"></script>
	</head>
	<body>
		<ul id="weibo" class="MIB_feed" style="width:555px;"></ul>
		<script type="text/javascript">
		YUI().use('jsonp','node-base',function(Y){
			var handler = function(response){
			console.log(response);
			var s = '';
			for(var i=0;i<response.length;i++){
				s +='<li class="MIB_linedot_1">';
				s +='<div class="head_pic"><img src="'+response[i].user.profile_image_url+'"></div>';
				s +='<divm class="MIB_feed_c"><p class="sms"><a href="#">'+response[i].user.name+'</a> : '+response[i].text+'</p></div>'
				s +='</li>';
			}
			Y.one('#weibo').prepend(s);
			Y.jsonp('http://127.0.0.1:8000/stream?callback={callback}',arguments.callee);
			};
			Y.jsonp('http://127.0.0.1:8000/stream?callback={callback}',handler);
		});
		</script>
	</body>
</html>

Server:

var http = require('http');
var path = require('path');
var qs = require('querystring');
var fs = require('fs');
var url = require('url');

//创建http client服务
var weibo_client = http.createClient(80,'api.t.sina.com.cn');

//读取静态文件
var load_static_file = function(uri,response){
	var filename = path.join(process.cwd(),uri);
	path.exists(filename,function(exists){
		if(!exists){
			response.writeHeader(404,{'Content-Type':'text/plain'});
			response.write('404 Not Found\n');
			response.end();
			return;
		}

		fs.readFile(filename,'binary',function(err,file){
			if(err){
				response.writeHeader(500,{'Content-Type':'text/plain'});
				response.write(err + '\n');
				response.end();
				return;
			}

			response.writeHeader(200);
			response.write(file,'binary');
			response.end();
		});
	});
};

//创建http服务
var server = http.createServer(function(request,response){
	var uri = url.parse(request.url).pathname;
	var callback = qs.parse(url.parse(request.url).query).callback;
	console.log(callback);
	if(uri === '/stream'){
	//定时从api得到需要的数据
	setTimeout(function(){
		var client_request = weibo_client.request('GET','/statuses/public_timeline.json?source=3364481477&count=5',{'host':'api.t.sina.com.cn'});
		//对返回的数据进行处理
		client_request.on('response',function(res){
			var body = '';
			res.on('data',function(data){
				body += data;
			});

			res.on("end",function(){
				var weibo = JSON.parse(body);
				if(weibo.length > 0){
					response.writeHead(200,{'Content-Type':'text/javasript'});
					var text = callback + "("+JSON.stringify(weibo)+")";
					console.log(text);
					response.write(text);
					response.end();
				}
			});
		});
		client_request.end();
	},5000);
	}else{
		load_static_file(uri,response);
	}
});

server.listen(8000);

该程序在Node.JS v0.4.6版本下测试通过。

造成的影响

使用 window.execScript 方法执行一段脚本代码字符串时，在 IE Chrome 浏览器以外的浏览器中可能无法执行，从而造成脚本错误。

受影响的浏览器

问题分析

根据 MSDN 中描述，window.execScript 方法会根据提供的脚本语言执行一段脚本代码。window.execScript 方法有两个参数，第一个参数指定被执行的脚本代码段，第二个参数指定脚本代码语言类别 (缺省值为 JScript)。
execScript 方法执行后的代码位于全局作用域下。

更多详细内容参见：execScript Method 。

分析以下代码，看 window.execScript 方法在各浏览器的支持情况：

<!DOCTYPE html>
<html>
<head>
<style>
  * { margin:0; padding:0; font:18px 'Trebuchet MS'; }
  table { border-collapse:collapse; }
  table td, table th { border:1px solid black; }
  th { background:#ddd; }
</style>
</head>
<body>
window.execScript()
<table cellspacing="0" cellpadding="0">
<script>
  var a, lang = ['JavaScript', 'JavaScript1.1', 'JavaScript1.2', 'JavaScript1.3', 'JavaScript1.4', 'JScript', 'VBS', 'VBScript', 'abcJavaScriptdef', 'Java-Script'];
  for (var i in lang) {
    try {
      a = undefined;
      window.execScript('a = 1', lang[i]);
    } catch(ex) {
      a = ex.message;
    }
    document.write('<tr><th>' + lang[i] + '</th><td>' + a + '</td></tr>');
  }
</script>
</table>
</body>
</html>

各浏览器执行结果如下：

可见，

• IE6 IE7 IE8 中，支持脚本语言类型为 JavaScript、JavaScript1.1、JavaScript1.2、JavaScript1.3、JScript、VBS、VBScript 的 window.execScript 方法。
• Chrome 中，浏览器判断脚本语言类型参数中是否包含有完整的 javascript 字符串，为真时支持 window.execScript 方法。
• Firefox Safari Opera 中，浏览器不支持 window.execScript 方法。

注: 脚本语言类型参数不区分大小写。

解决方案

window.execScript 方法不是所有浏览器都支持，需谨慎使用。若需要在其他不支持 window.execScript 方法的浏览器中达到类似的效果，可以使用 window.eval 方法：

<script type="text/javascript">
  var jsCode = "var a = 1;";
  if (window.execScript) {
    window.execScript(jsCode, "JavaScript");
  } else {
    window.eval(jsCode);
  }
</script>

和淘宝还有腾讯的朋友闲聊，不经意的又谈到了抄袭、抄习和抄越这几个有意思的字眼。刚好看到Traci Lepore写的Why Great Designers Steal, and Are Proud of It这篇文章，就整理一下和更多人分享。谢绝转载。

强调一下，毕加索的原话其实是”Bad artists copy, Good artists steal”，而不是”Good artists copy, great artists steal”。也许大部分人意识到抄袭是可耻的，把bad改成good聊以自慰，但是明显的，我们都承认偷窃是更伟大的。

一切革命性的并且成功的设计都不是来自凭空想象。不管你是否已经意识到，你每天接触到的事物都在影响你的创作。对于优秀的设计师来说，关注和吸收新鲜元素确实会激发他们本身的创造性。但是通常而言，不管你称其为抄袭、模仿或者借鉴，大部分人都只是在复制别人的想法。

而毕加索则是一个偷窃别人使自己作品受益的行家里手。在毕加索博物馆举办的名叫“毕加索窥视德加”的展览，更加印证了这一点。沉浸在巴黎的艺术世界中，模仿他人的作品是非常简单的事情。毕加索和德加在巴黎的工作室相隔仅仅几个街区，所以毕加索的作品更容易受德加的影响。但是毕加索和他的朋友们期待成为伟大的艺术家，所以他们没有对德加的作品进行简单的抄袭，而是不断的学习研究德加的作品，发掘他创作的根本动机和意图，并且以更具创造力的的方式诠释出来。
对于这种做法，德加评价到：他们盯着我，并且从我的口袋里掏东西。德加非常了解这种这种看似偷窃的创新，并且非常赞赏毕加索和他的朋友们的做法。毕加索通过这样的偷窃，把自己的作品提升到一个全新的水准，甚至创造出我们熟知的立体主义画派。

毕加索和他的朋友们想要把他们在艺术上的创新扩大影响，他们意识到必须要一个积极的并且更人性的方式让他们身边的艺术家和艺术的受众了解他们的创新。在当时最有影响力的画贩子沃拉尔的帮助下，通过举办画展、频繁曝光等炒作方式，将人们对法国的浪漫主义和印象派绘画的关注，导向了印象派、野兽派、立体主义等新鲜的绘画形式。也正是重新定向了人们的审美标准，毕加索也开始被人们熟知起来。

同大家争论是毕加索从德加那里获得了创意还是毕加索本身的天分促成他的创新一样，在当今的用户体验领域也存在一些争论。以用户为中心的设计或者以特立独行的天才的构想为中心的设计，哪种方式会产生更多革新的创造？

苹果的乔布斯和任天堂的宫本茂，都是用户体验领域的大师级人物，他们也是所谓创新独行客的杰出代表。《纽约时报》描述乔布斯，在同事眼中是一个永不妥协的人，苹果产品的构想和原型不是展示给焦点小组或者相关人员，而是由乔布斯和他的团队中的少数成员审查定夺。《纽约客》则写到，在调整游戏的过程中宫本全凭自己个人的好恶和直觉。他要求家人和朋友亲身体验游戏。任天堂根本就不采用焦点小组。在苹果和任天堂，内部人士才有机会对新产品先睹为快，除此之外它们就直接诞生于乔布斯和宫本想法和意见。而用户由于缺乏设计技术和市场洞察力，在产品设计过程中始终被控制一个安全距离之外。

User-Led Innovation Can’t Create Breakthroughs: Just Ask Apple and Ikea一文中提到，用户主导产品不可能取得完全的创新，甚至会影响到创新的进程。用户的洞察力不足以预测未来的产品需求，过分关注用户的话将会错失革新的机会，甚至会导致产品同质化。但是我认为事实并非如此。苹果和任天堂这样的公司确实是与众不同的，但是这并不意味着他们没有关注用户并且尝试了解用户的情感需求，即便是这些情感没有影响到他们创造的东西。

Jake Truemper在Where Innovation Belongs in User-Centered Design中提出，用户经常说一些与他们的行动完全相反的事情，所以一个好的用户研究人员应该知道如何更关注用户的行动而不是关注他们在说些什么。用户研究人员的另一重要职责，就是全力了解用户言行不一致的真相。焦点小组之类的以用户为中心的研究，非常关注用户所说的，而没有通过行为去验证，因此在大多数情况下并不是最好的选择。Jake Truemper推荐使用人种学的方法，比如说情境访谈，便于让你真实的体验用户的使用感受。他还推荐使用创造人物角色的方法，这种方法可以通过设计过程的的方式，在你还没有接触到用户的时候仍能与用户保持紧密的联系。

乔布斯说过，苹果商店的员工为公司提供了一扇观察用户习惯和了解用户需求的极佳窗口，他自己也时常访问帕拉奥图市的苹果商店，虽然那不是传统意义的市场研究。而宫本茂则建议游戏设计师们脱离自身思维以用户的角度思考问题，他要求年轻游戏设计师们试着转换左右手玩自己设计的游戏，这样他们就能体验初次接触游戏的人是多么的缺乏经验。可以恭维的说乔布斯和宫本的伟大想法都源自个人的远见和设计，但是绝对不能忽略终端用户参与创意的过程，他们可以是顾客、玩家、读者等等任何角色。伟大的想法、优秀的产品、出色的体验皆来源于一种创造，那就是为另一个人带来有趣的、有用的、有意义创造。用户体验的大师们永远清楚自己的方向是服务他者。

在The Creative Habit一书中，Twyla Tharp提出搜寻是寻求创意的第一步，也是探索性的第一步。我们搜寻出的最原始实物都来源于我们的经历——早期的记忆、朋友间的交谈、对周边事物的观察。在进行创造的过程中尽可能的获得启发是非常关键的，你在搜寻时所选择的参照物将形成整个创意过程。在最好的事物之间进行搜寻，你就会自动地提高自己所发现创意的质量。毕加索对德加创作的关于巴黎妓女生活写照的《妓院系列》非常迷恋，他想法设法购买到其中若干单版画；塞尚个人画展的中卖出的第一幅作品黑奴，则是被莫奈买走。愈伟大的艺术家，愈擅长从身边寻求灵感，当然，不仅仅是艺术家懂得这样做。

你真的相信如果没有索尼的walkman苹果可以发明ipod出来么，你是否留意过因为随之产生的文化转变？乔布斯本身就是最善抄袭的企业先知。他的独到之处就在于他可以从不同的角度看事物，见人所未见，把别人并不特别在意的事物偷学来，反过来以全新的风貌颠覆世界，创造出无人预期的庞大商业潜能。对于偷窃伟大构想这件事，苹果向来并不感到可耻，而苹果最令人称许的是他们进行“不自我设限”的学习模式，他们不仅向同行偷点子，更多时候他们由异业吸收设计元素。伟大的艺术家和可耻的剽窃者只有精神上的一线之差，懂得如何拾人牙慧又能融会贯通才是创新的关键。

很多设计师都懂得参考他人作品来获得新的设计灵感，是否加入了个人的创见则是区别抄袭与偷窃的首要。如果你真的希望做出优秀的设计，希望你行动起来。也可以尝试着偷窃，毕竟很多大师都含蓄的表达了抄袭的重要性。或许你已经这样做了，并且取得了不错的成绩，那么我在文章的结尾加注这样一句，创造的一大秘诀是要懂得如何隐藏你的来源——爱因斯坦。

在这篇文章中，我将给大家分享html5构建页面的小错误和不好的实践方法，让我们在以后的工作中避免这些错误。

不要把 <Section> 当成简单的容器来定义样式

我们经常看到的一个错误，就是武断的将<div>标签用<section>标签来替代，特别是将作为包围容器的<div>用<section>来替换。在XHTML或者HTML4中，我们将会看到类似下面的代码：

<!-- HTML 4-style code -->
<div id="wrapper">
  <div id="header">
    <h1>My super duper page</h1>
    <!-- Header content -->
  </div>
  <div id="main">
    <!-- Page content -->
  </div>
  <div id="secondary">
    <!-- Secondary content -->
  </div>
  <div id="footer">
    <!-- Footer content -->
  </div>
</div>

现在我看到了下面的代码样子：

<!-- Don’t copy this code! It’s wrong! -->
<section id="wrapper">
  <header>
    <h1>My super duper page</h1>
    <!-- Header content -->
  </header>
  <section id="main">
    <!-- Page content -->
  </section>
  <section id="secondary">
    <!-- Secondary content -->
  </section>
  <footer>
    <!-- Footer content -->
  </footer>
</section>

直观的看，上面的例子是错误的：<section> 并不是一个容器.<section>元素是有语意的区段，帮助构建文档大纲。它应该包含标题。如果你要寻找一个可以包含页面的元素（不论是 HTML 或者 XHTML ），通常的做法是直接对<body>标签定义样式就像Kroc Camen描述的那样子，如果你还需要额外的元素来定义样式，使用<div>,就像Dr Mike 阐述的那样, div并没有灭亡，如果这里没有其它更合适的，div可能是你最合适的选择。
记住这点，这里我们重新修正了上面的例子，通过使用两个新角色。（你是否需要额外的<div>取决于你的设计。）

<body>
  <header>
    <h1>My super duper page</h1>
    <!-- Header content -->
  </header>
  <div role="main">
    <!-- Page content -->
  </div>
  <aside role="complementary">
    <!-- Secondary content -->
  </aside>
  <footer>
    <!-- Footer content -->
  </footer>
</body>

如果你还是无法确定哪一个元素更适合使用，我建议你去查看HTML5 sectioning content element flowchart来让你继续前行。

只在需要的时候使用 <hgroup>和<header>标签

使用标记的时候写入了一些并不需要的现象这是不合理的。不幸的是，经常发现大家在并不需要的地方使用<header>和<hgroup>标签。你可以跟进我们关于<header>和<hgroup>的最新进展，下面是我的简单归纳：

• <header>元素通常是通常作为一组解释或者导航辅助工具,通常包含section的标题.
• <hgroup>元素会将当有副标题\子标题,各类标识文字时,对<h1>到<h6>标题进行群组,将其作为section的标题.

过度使用的<header>

你肯定知道,在一个文档中,可以使用多次<header>标签,下面就是一种很受大家欢迎的模式:

<!-- Don’t copy this code! No need for header here -->
<article>
  <header>
    <h1>My best blog post</h1>
  </header>
  <!-- Article content -->
</article>

如果你的<header>标签只包含一个标题元素时,就不要使用<header>标签了.<article>标签肯定会让你的标题在文档大纲中显现出来,而且因为<header>并不包含多重内容(就像定义中描述的那样子),我们为何要增加而外的代码呢?应该像下面这样简单才可以:

<article>
  <h1>My best blog post</h1>
  <!-- Article content -->
</article>

<hgroup>不合理使用

在标题的这个主题上,经常看到使用<hgroup>的错误案例.在下面这种情况下你不能将<header>标签和<hgroup>标签一起使用:

• 这里只有一个标题,
• 或者<hgroup>本身就够了(比如:不需要<hgroup>)

第一种情形看上去是下面的样子:

<!-- Don’t copy this code! No need for hgroup here -->
<header>
  <hgroup>
    <h1>My best blog post</h1>
  </hgroup>
  <p>by Rich Clark</p>
</header>

这种情况下,将<hgroup>移除,只保留标题就好.

<header>
  <h1>My best blog post</h1>
  <p>by Rich Clark</p>
</header>

第二种情况也是包含了他们并不需要的标签.

<!-- Don’t copy this code! No need for header here -->
<header>
  <hgroup>
    <h1>My company</h1>
    <h2>Established 1893</h2>
  </hgroup>
</header>

当<header>标签的子元素只有<hgroup>的时候,为什么我们还需要一个额外的<header>?如果没有额外的元素放到<header>中(比如<hgroup>的兄弟元素),我们直接将<header>元素去掉就好.

<hgroup>
  <h1>My company</h1>
  <h2>Established 1893</h2>
</hgroup>

不要将所有的链接列表都放到<nav>标签

在HTML5新增的30个元素中(在我们写这篇文章的时候),我们在构建更具语义\结构化的标签的时候,我们的选择变得太丰富.也就是说我们对现在给我们提供的这些超级有语义的标签,我们可能会滥用.<nav>就是一个很悲剧的例子.在规范中的描述是这样的:

The nav element represents a section of a page that links to other pages or to parts within the page: a section with navigation links.

Note: Not all groups of links on a page need to be in a nav element — the element is primarily intended for sections that consist of major navigation blocks. In particular, it is common for footers to have a short list of links to various pages of a site, such as the terms of service, the home page, and a copyright page. The footer element alone is sufficient for such cases; while a nav element can be used in such cases, it is usually unnecessary.
WHATWG HTML spec

这里面的关键词是”重要”导航.我们可能会对”重要”有不同的定义,但是我的理解是:

• 主要导航
• 网站搜索
• 二级导航(这个能是有争议的)
• 页面内链接(比如一篇很长的文章)

虽然并没有对错之分,但根据我的理解和一个民意投票让我觉得在下面这些情形下,我不会使用<nav>标签:

• 翻页
• 社交类的链接（虽然有些社交类的链接也是主要的链接，比如关于我About me和品味Flavours ）
• 博客文章的标签
• 博客文章的分类列表
• 第三级导航
• 大页脚

如果你不能确定是否使用<nav>，那就先对你问一下下面的几个问题：“者是否是一个主要链接？”，你可以根据下面的几个因素来回答你刚才的问题：

• 如果用<section>和标题标签能够解决你的问题，那就不要去使用<nav>–Hixie on IRC
• 你是不是为了增加可访问性而增加的一个快捷跳转链接呢？

如果上面的回答都是“不”，那可能就不适合使用<nav>.

<figure>元素的错误

<figure>和经常与它合伙作案的<figcaption>，是很难掌握的标签，下面是经常看到的一些小错误。

并不是所有的图片都是figure（注：比较难理解阿，image=图片，figure=图形）

之前，我曾经说过不要写那些不需要的标签。这个错误也是相同的。我经常看到一个网站上的每张图片都有<figure>标签。这些额外增加的标签并不会给你带来任何的益处，并且还增加了你自己的工作强度和让自己的内容变得更难理解。
在规范中关于<figure>的解释如下：“某些流内容，可以有标题，自我包含并且通常作为一个单元独立于内文档流之外。”在那里有完美的表述，就是它可以被从主内容中移除–比如放到边拦，而对文档流没有影响。
如果仅仅是一张表现类的图片而且和文档中其他的内容没有关系的话，那就不需要使用<figure>.”这张图片需要对上下文的内容作出解释吗？”，如果答案是”否”，那就可能不是<figure>(可能是<aside>),”我能把它移到附录里面吗？”，如果这两个问题的答案都是”是”，那就可能是<figure>.

你的标志不是一个<figure>

将上面的延伸开来，对你的logo也是这样。下面是两组我找到的有规律的代码片断：

<!-- Don’t copy this code! It’s wrong! -->
<header>
  <h1>
    <figure>
      <img src="/img/mylogo.png" alt="My company" class="hide" />
    </figure>
    My company name
  </h1>
</header>
<!-- Don’t copy this code! It’s wrong! -->
<header>
  <figure>
    <img src="/img/mylogo.png" alt="My company" />
  </figure>
</header>

这里就不需要说啥了，这是很明显的错误，可能你认为我们说的是不是将logo放在H1标签里面，但是我们在这里并不讨论这个问题。让我们迷惑的是<figure>元素。<figure>标签只用在当有上下文需要说明或者被<section>包围的时候。我这里要说的是你的logo可能很少会被这种情况下使用。很简单，那就不要去这样做，你需要的仅仅是下面的样子。

<header>
  <h1>My company name</h1>
  <!-- More stuff in here -->
</header>

figure只能用在标签上的误解

另一个对<figure>的误解就是我们通常认为它只能用在图片上面。事实上并不是这样子的，它可以被用在 <video><audio>, 一个图标 (比如<SVG>, ), 一个引用, 一个表格, 一段代码, 一段散文, 或者任何和这些相关的组合. 不要把你的<figure>标签仅仅局限在图片上。我们网页制作师的任务就是用标签更准确的描述内容。
这里有一篇更深入讲解 <figure>的文章I wrote about <figure>，很值得阅读的。

不要去使用那些不必要的type属性

这可能是我们最常见的一些问题，它们并不是真正的错误，但我觉得我们的最好实践还是尽量避免这种模式。
在HTML5中，我们并不需要给<script>和<script>增加 type 属性，如果这些从CMS默认添加的内容中移出是很痛苦的事情，那当你手工编码的时候还写入它们或者你能完全的控制你的模板时候你完全可以删掉它们。因为所有的浏览器都会将<script>解析成Javascript和<css>标签是CSS，你不再需要那个type属性了：

<!-- Don’t copy this code! It’s attribute overload! -->
<link type="text/css" rel="stylesheet" href="css/styles.css" />
<script type="text/javascript" src="js/scripts.js"></script>

现在我们可以写成下面的样子：

<link rel="stylesheet" href="css/styles.css" />
<script src="js/scripts.js"></script>

你也能够对编码的设置作出省略。Mark Pilgrim在Dive into HTML5的语义化一章中作出了解释。

不要包含错误的表单属性

你可能发现<html5>引入了很多新的表单属性。现在我就给大家讲讲一些不合适的使用。

布尔值属性

新引入的标签属性有几个是布尔类型的，它们的标签行为基本接近。这些属性包括：

• autofocus
• autocomplete
• required

坦白的说，下面的这种情况对我来说并不常见，但我们从 required 作为例子，如下：

<!-- Don’t copy this code! It’s wrong! -->
<input type="email" name="email" required="true" />
<!-- Another bad example -->
<input type="email" name="email" required="1" />

基本上看，这段代码并不会带来危害。客户端对 HTML的解析遇到 required 标签属性时，他的功能就会生效。但是当我们将代码修改，录入 required=”false” 的情况呢？

<!-- Don’t copy this code! It’s wrong! -->
<input type="email" name="email" required="false" />

解析的时候依然会遇到 required 属性，虽然你希望加入的行为是 假，它依然会被解析成 真。
这里有三种合理的方法让布尔值生效。（第二种和第三种方案只有你在写 XHTML 解析的时候需要）
我们上面的例子可以写成下面的样子：

<input type="email" name="email" required />

总结
对我来说，我无法将所以得蹩脚的代码模式都展示在这里，但是上面说的这些都是我们经常遇到的。

首先先看一下基本定义：

复合选择器就是两个或多个基本选择器，通过不同方式连接而成的选择器，主要包括“交集”选择器、“并集”选择器、“后代”选择器。

交集选择器

“交集”复合选择器是由两个选择器直接连接构成，其结果是选中二者各自元素范围的交集。其中第一个必须是标记选择器，第二个必须是类别选择器或者ID选择器。这两个选择器之间不能有空格，必须连续书写。

注意其中第一个必须是标记选择器，如p.class1，但有时候会看到.class1.class2，即2个都是类选择器，在其他浏览器中是允许出现这种情况的，但IE6不兼容。如下表：

复合选择器的使用

这是个简单的tab菜单：

如下是html代码:

<ul class="nav">
    <li class="first"><a href="">节目</a></li>
    <li class="current"><a href="">合集</a></li>
    <li><a href="">草稿</a></li>
    <li class="last"><a href="">项目</a></li>
</ul>

为了实现以上效果，我们在css中可以使用复合选择器。

选择<a> 标签

可以用一个选择器来定义所有的 <a> 元素, 如下:

.nav li a { }

选择第一个 <a> 元素

为了增加列表左上角的圆角效果, 你需要选择第一个 <a> 元素. 这可以用如下的选择器来实现:

.nav li.first a { }

选择最后一个 <a> 元素

为了增加列表右上角的圆角效果, 你需要选择最后一个 <a> 元素. 这可以用如下的选择器来实现:

.nav li.last a { }

突出显示当前页

通过改变tab的颜色来显示页面是当前页，我们可以在类名中加入current这个类名来实现，如下：

.nav li.current a { }

为当前页面的左右上角添加圆角样式

现在有个问题，第一个和最后一个选项被选中的时候拐角是直角的.为了达到选中时候是当前页的样式，拐角也是圆角效果，我们需要给专门给它们写特殊的选择器，由于现在我们的类名都在同一个元素中，所以我们最终可以用交集复合选择器来实现，如下：

.nav .first.current a { }
.nav .last.current a { }

结果

这看上去很简单，是不是？就像上面提到的，现在的问题是：IE5和IE6都不支持类名交集复合选择器。IE5和IE6在识别类名时候只会识别最后一个类名。效果如下：

.nav .first.current a { }
.nav .last.current a { }

IE5和IE6把这2个选择器解析为：

.nav .current a { }
.nav .current a { }

这意味着这些浏览器会给所有的当前页都增加圆角效果，效果如下：

在IE7下也是没问题的，说明IE7也支持类名交集复合选择器。

解决的办法

可以给第一个和最后一个li单独加一个current的样式，但这样增加了js的负担。

<ul class="nav">;
    <li class="first first_current"><a href="">节目</a></li>;
    <li class="current"><a href="">合集</a></li>;
    <li><a href="">草稿</a></li>;
    <li class="last last_current"><a href="">项目</a></li>;
</ul>;

.nav .first_current a { }
.nav .last_current a { }

讨论

有一种方法可以让我们不用在页面中增加像first、last这种多余的类名，那就是使用css3的样式。css3让我们选择元素变得越来越简单，实现头尾效果可用如下效果：

li:first-of-type a { }
li:last-of-type a { }

什么是 Scrum ?

Scrum是一种迭代式增量软件开发过程，通常用于敏捷软件开发。Scrum在英语的意思是橄榄球里的争球。
虽然Scrum是为管理软件开发项目而开发的，它同样可以用于运行软件维护团队，或者作为计划管理方法：Scrum of Scrums 。
相关线上资料：
http://zh.wikipedia.org/wiki/Scrum

角色

Scrum定义了许多角色，根据猪和鸡的笑话分为两组，猪和鸡：

一天，一头猪和一只鸡在路上散步，鸡看了一下猪说，“嗨，我们合伙开一家餐馆怎么样？”，猪回头看了一下鸡说，“好主意，那你准备给餐馆卖什么呢？”，鸡想了想说“餐馆卖火腿和鸡蛋怎么样？”，“我不这么认为”，猪说，“我全身投入，而你只是参与而已”。

这个笑话挺冷的……不过倒是比较准确的划分了项目参与人员。

猪组

猪组的成员是在Scrum过程中全身投入项目的各种角色，他们在项目中承担实际工作。他们有些像上边那个笑话里的猪，要把自己身上的肉贡献出来。

• 产品负责人
  产品负责人代表了客户的意愿。这保证了Scrum团队在做从业务角度来说正确的事情。产品负责人编写用户故事，排出优先级，并放入产品订单。
• Scrum主管（或促进者）
  Scrum主管促进 Scrum过程，他的主要工作是去除那些影响团队交付冲刺目标的障碍。Scrum主管并非团队的领导（因为团队是自我组织的），而是一个负责屏蔽外界对开发团队的干扰的角色。Scrum主管确保Scrum过程被按照初衷使用。Scrum主管是规则的执行者。
• 开发团队
  负责交付产品的团队。一个团队通常由5至9名具有跨职能技能的人（设计者，开发者等）组成，承担实际的开发工作。

鸡组

鸡组的成员并不是实际Scrum过程的一部分，但是必须考虑他们。敏捷方法的一个重要方面是使得用户和利益相关者参与到过程中的时间。参与每一个冲刺的评审和计划，并提供反馈对于这些人来说是非常重要的。

• 用户
  软件是为了人而开发的。有人说，“假如森林里有一棵树倒下了，但没有被人听到，那么它算是发出了声音吗？”同样地，人们可以说，“假如软件没有被使用，那么它算是被开发出来了么？”
• 利益相关者（客户，提供商）
  影响项目成功的人，但只直接参与冲刺评审过程。
• 经理
  为产品开发团体搭建环境的人。

经验：

1. Scrum主管开发的时间可能不会很多，一般来说也不适合参与开发，因为排解外部干扰，解决项目组障碍都会花去很多零碎时间进行沟通以及其他事务，都会干扰个人的正常开发。
2. 建议不要让开发主力担任Scrum主管，应当由擅长沟通，有较深技术底蕴，对产品比较熟悉或者理解深刻的人员担任。
3. Scrum主管与开发人员是平级的，身份对等，所做的工作更有点偏向于服务形式。其本身基本上可以看做是一个“人形文档”，项目执行中任何需要产品文档的地方，比如咨询，需求变更，新成员培训等等都由Scrum主管负责。
4. 对一个项目来讲，Scrum主管非常重要，其他成员可以变更，但绝对要避免Scrum主管的变更。Scrum主管的责任也很庞杂，需要擅长处理并发事件的人来担当此角色。
5. Scrum的效率核心就是“排除干扰”，开发人员可以为一个项目全力以赴。Scrum主管对干扰的排除能力直接决定了项目执行效率。
6. 所有的分歧交由Scrum主管来敲定，因此其技术能力与现实业务解决能力不能忽视，应当从开发人员中抽取人员负责此工作。考虑到离开开发岗位一段时间，技术能力会有所退化，建议轮岗。

会议

在冲刺中，每一天都会举行项目状况会议，被称为“scrum”或“每日站立会议”。每日站立会议有一些具体的指导原则：

• 会议准时开始。对于迟到者团队常常会制定惩罚措施（例如罚款，做俯卧撑，在脖子上挂橡胶鸡玩具）
• 欢迎所有人参加，但只有”猪”可以发言。
• 不论团队规模大小，会议被限制在15分钟。
• 所有出席者都应站立。（有助于保持会议简短）
• 会议应在固定地点和每天的同一时间举行。

假设会议定在每天下午下班前，在会议上，每个团队成员需要回答三个问题：

1. 今天你完成了那些工作？
2. 明天你打算做什么？
3. 完成你的目标是否存在什么障碍？（Scrum主管需要记下这些障碍）

每一个冲刺完成后，都会举行一次冲刺回顾会议，在会议上所有团队成员都要反思这个冲刺。举行冲刺回顾会议是为了进行持续过程改进。

会议的时间限制在4小时。

经验：

1. Scrum会议的核心是：不要太长！应当尽量避免任何可能导致会议延长的事情。
2. 项目开发开始前的会议不要过长，主要确定方向，任务与最关键的技术细节。应提供一个技术预备期供大家分享要使用的技术知识或者制定开发规范。
3. 项目开发正式开始前，必须达成必要的开发共识，必须完成基本的开发约定。每个人并不是只维护自己的代码。
4. Scrum会议的督促作用非常明显，但也会给成员带来相当的压力。在新版会员中心开发过程中，曾发生成员开发压力过高而离职的事件。Scrum主管有必要注意排解成员压力。

下面几点有助于降低成员压力：

1. 让开发人员领取自己喜欢和擅长的任务。
2. 项目开始前充分预估时间，务必实事求是，并考虑到成员的开发能力。
3. 开发前（或者日常）最好能进行几次技术培训，避免成员在开发中遇到不熟悉的技术。

冲刺订单

• 冲刺订单（sprint backlog）是大大细化了的文档，包含团队如何实现下一个冲刺的需求的信息。
• 任务被分解为以小时为单位，没有任务可以超过16个小时。
• 如果一个任务超过16个小时，那么它就应该被进一步分解。
• 冲刺订单上的任务不会被分派，而是由团队成员签名认领他们喜爱的任务。
• 一个任务分为todo ，开发中，自测，提交测试，完成几个阶段。

经验：
WEBIM项目实施白板：

左边的用户故事，实际上是对冲刺订单的分类。

订单一开始都在 todo 的下面，每个开发人员到实施白板前，审核还有那些订单在todo当中，从中选择自己喜欢或者相对擅长的订单，写上自己的名字，放在开发中，然后回去开发相应组件。

当组件基本开发完毕，就将订单放在自测栏下面。

如果准备将该组件提交测试，就将订单放在测试栏下面。

如果组件通过测试，就放在完成栏下面。这样一个组件就走完了整个开发流程。

实际开发中发现，由于测试实际上是在所有组件都完成开发后才执行的，所以订单放到自测阶段就基本上可以视为开发完毕，开发人员就应该去领新的订单了。

WEBIM项目中订单用便签实现：

WEBIM开发中，每个订单对应的是一个开发组件，标记了组件名称，类别，开发人员，预估时间。对应开发组件模型如下：

Name为组件名称，也是开发时的小文件名称。
Extends 为该组件继承自哪一个组件。
Property 为组件应当具有的属性。
Methods 为组件应当具有的方法。
SP 为开发该组件可能的耗时。1SP表示1个工作日（单个成员8个工作时）

项目开始前的集中会议非常重要，需要所有开发成员集中在一起执行。
应当集群体之力一起分析项目，拆解组件，但注意非关键性的细节不要过分追究，避免会议耗时。
应当有一个文档保存所有画出的组件模型。

燃尽图

燃尽图可以非常形象的表现项目执行进度。
以下图举例：

X轴原点为项目开始日期，末端为项目结束日期。每天为一格。
Y轴为预估的工作时。

• 在项目准备会议结束时，冲刺订单已经预备好，就可以统计出预估的总工作时，将其标在Y轴顶部。
• 每天检查实施白板，确认哪些订单已经完成，然后计算剩下的总工作时，然后在图上标记一个点，点的X位置为第二天的日期，Y位置为剩下的总工作时。
• 在起点坐标（X为开始日期，Y为总时间）和终点坐标（X为结束日期，Y为0）之间画一条直线，这就是理想状况下的项目完成进度曲线。
• 在项目执行中，发现曲线高于理想曲线，说明项目有可能延期，需要增派援手，或者催促成员加快进度。如果曲线低于理想曲线，说明项目有可能提前完成。

经验：
先看一下WEBIM项目的燃尽图：

不可思议的是曲线一开始居然还有个增高。这说明一开始时间预估就不完善，开发中增加了预估时间。

一开始认为订单放到完成，才能从工作时中减去时间，但由于测试实际上是在所有组件开发完成后，所以当订单放在自测，就从工作时中减去时间。

这个图后期并没有完成。实际上是因为项目组件提前在12日都开发完成，但是新的问题出现：组件完成后还有一个联调的时间，未被预估在内。还好最终还是保证了项目按期联调完毕。

燃尽图后期的陡峭往往说明了任务分割与时间估算的不完善。但是有时这不可避免，可以考虑用完成度百分比乘以工作任务，或者将任务分阶段（将预备阶段，开发阶段与测试阶段分开）来平缓燃尽图曲线，达到更细致描绘工作进度的目的。

可以考虑联调前的订单被开发完成了70%，联调完毕才标记为100%，然后从总工作时中减去剩下百分比的时间。

一开始预估完总工作时间后，应当乘以一个系数（大于1，从未预估过时间，建议这个系数接近甚至大于2，否则建议为1.5）。以这个时间为总工作时间，以应付项目执行中可能遇到的突发事件。

总结

Scrum 效率相当明显，执行过程中可以使成员中开发速度缓慢的地方被迅速暴露出来，使得项目中可能存在的问题被极早暴露，以便进行针对性的解决。

开发中要求成员有充分的自发性，自己如果能提前完成订单，应当负责起其他订单的开发任务，减轻项目整体的开发负担。

一开始的沟通会议非常重要，必须当面进行沟通会议，不可以有缺席。以保证每个成员对项目的细节都有所了解，可以负责任意一个组件的开发。

Scrum不仅仅用于软件开发，它是一种计划管理方式，适用于被限制时间，需要多人协作的团队项目。

做T的想法很早就有了,一直没有空闲去尝试,直到09年5月的那个夏天终于开始了…

主体形象－hippo81性格简单介绍：
这是一只自恋喜欢幻想,并且经常yy的河马.所有的猥琐,悚等的状态在以后都会通过图形设计表现在河马的身上,最后想达到的一种理想状态就是像HELOO KITY,机器猫那样,让人们承认它是有性格和感情的.这张照片拍摄于2009年12月31日,经历半年之后仍然不被大家认同和接受的一天…

一：T恤图案设计
好了,想法都差不多了,就要开始实施设计制作和推广了.

这张图是在网络上发帖的时候做头图用的,不适合印刷成T恤,颜色太多渐变太丰富.

在图案设计的时候需要注意以下几点

1:图案的设计
图案设计因该简洁,大色块,这样容易出比较好的效果. 颜色不宜使用过多这是受技术限制的原因,丝网印刷的特性.三种颜色就已经很多了,如果是单色印从技术的角度上来说可以保证达到最佳的效果.这样印出来的图案和设计稿会相差无几.
2:图案颜色的选择
尽量使用色相明确的色彩,因为颜色的确定是自己去工厂里面调出来的,一般工厂就提供黑 白 红 黄 绿等色相明确的颜色,比如一些高纯度的我们所谓的高级灰,需要自己去调,这个不好掌控,比如我要一个偏黄的暖灰色,白加黑加橘黄,但是实际调出来却是偏绿的灰色,原因是黑色不是没有色彩偏向的,一般黑色偏普兰,或者深红,结果我那次调的黑色是偏兰的,所以出来就变绿了,而且这种颜色调出来以后,在湿润的情况和凉干的情况下对比也会有色彩差别,在光线不同的地方也会有差别.所以尽量少用需要自己调制的颜色,直接拿工厂里面的颜色就上,还有一些就是工厂里面已经调好的灰色,你看到了实际印到T上面的效果,你觉得可以的话,那就可以直接用了.

以上是为了这次印T而准备的一些自己设计的图案,是从一大批里面选择出来觉得比较靠谱的,制作上不会出乱子的,自己能把握住的一些图.

二：T-SHIRT制作

选择好图案以后就是进入工厂和工人一块制作了.那会一般的工厂是300件起印和打板,因为他们进布料是以匹为单位,做得太少了他们亏本还得浪费布料.

1:衣服面料和版型的选择
版型是比较有学问,虽然T的版型一般比较简单,但是在细节上处理的好坏也会直接影响到T穿在身上是否好看和舒服,俺当时的做法就是去品牌店里面找一件觉得不错的,比较潮点的,买回来,让工厂照着它的版型加工就OK了.切记不要选择毫无版型的T,这样的T一般我们叫他老头衫~~

衣服的面料:一般用作T的布料都是棉,各种各样的棉,竹签棉,纯棉(精梳和普梳)等,每种棉的质感是不一样的,这个可以根据创作需要去选择.以普通的纯棉为例子,按照重量来分可以分为140克到240克六种,正常情况下选择180到220的,180以下的太薄,比较透,正常光线室外能看到肉色~~240的则太厚,夏天穿着会比较热.

2:图案的印刷
现在普及的印刷技术是丝网和热转印,有些技术可以使颜色渐变过度很自然,颜色也可以很丰富,但是没有普及,还有一些特殊的工艺,比如缝纫什么的,不适合咱们个人来批量印刷,这样成本会大大的加高.

丝网印是比较适合个人批量制作一种方式,这种印刷方式出来的图案比较透气,也不容易被洗掉。 缺点就是不能色彩过于丰富,也不能做细腻的颜色渐变。这种印刷方式的基本流程是根据图案上出现的颜色做版（类似纱窗的东西）, 一个颜色一个版, 有图形的部分在版面上漏口会大一些,方便颜色在刷的时候漏到衣服上.然后手工一个版一个版的叠加刷颜色,最终在衣服上拼出你想要的图案.

大概俺能介绍的经验就这么多了，这个过程虽然会很辛苦，但是当时自己那段时间干劲非常的足，可能是做自己喜欢的事的原因吧。希望以上的一些简单介绍能够帮助到各位想做T的朋友：）