前几天看The Big Bang Theory第一季大结局的时候，注意到了nauseous和nauseated的问题。剧中人物Leonard和Sheldon之间有这样一段对话（含剧情透露，不想知道的请跳到中文部分接着看）：

Leonard: Now that I’m actually about to go out with Penny, I’m not excited, I’m nauseous.
Sheldon: You made a common grammatical error. You said “nauseous” when you meant “nauseated”.

我以前大致知道nauseous和nauseated原则上不一样，但实际运用中已趋同化，所以我一向是把它们当可互换的同义词处理的。这次被Sheldon“点”了一下，于是决定一探究竟。

Nauseous versus nauseated

关键点摘录如下：

1. 如果一定要坚持原则的话，nauseous是“令人恶心的”，nauseated是“身体不舒服，觉得恶心”，就如同Sheldon讲的那样，不应该把两者混为一谈。

2. 语言是跟着时代不断变化的。目前，各大权威词典已经明确指出：说nauseous不可以表示nauseated的意思已经不合时宜。在现代英语里，nauseous的主要意思已演变为“觉得恶心”，而非“令人恶心的”。换句话说，nauseous的“误用”已是这个单词的主流用法，它的正确用法反倒不再常用。

3. nauseous的主要意思虽然已是“觉得恶心”，但它一般跟在feel、get、become、grow之类的动词后面才表示这种意思，如果放在名词前当定语的话，它还是表示“令人恶心的”居多。比如：

Doctor, I’m feeling nauseous.
To conceal the nauseous flavor of the raw spirit, they added aromatic herbs and spices.

如此看来，Leonard的话完全没错，是Sheldon太nerdy了。

4. nauseous的本义“令人恶心的”又跟nauseating是一样的。

这个比较容易让人头晕，不过我觉得，如果对这几个词都不熟悉的话，干脆就不要记nauseous，只记nauseating/nauseated。这对组合的区别就跟interesting/interested、exciting/excited一样，这下肯定不会搞错了。

Bonus video: Linkin Park - Leave Out All The Rest

从业这几年，自己写过的和帮人参谋的所谓“设计规范”不少了，这个东西大概在中国的决策层眼里是这么回事儿 - 一帮农民在一块田里种粮食，起先天气不错，土地肥沃，但是不久天气变差了，虫子多了，土地沙化严重，还有几个缺心眼的内鬼偷粮食，这下必须立定一个规范，挑头的告诉他们该在哪儿种，收多少麦子算合格，哪部分的地是留到下一季种的，种出什么样的麦子给奖金，偷懒不干活的怎么处理……

但我理解的规范不是简单的把一个设计做成一个“行业套路”的量化指标，而是一个综合的品质评估的参考，甚至是一个设计能否面市的决定因素。为此，我们需要拟定一些表格，文档备案，图形参考，交互模板。

同时，设计规范还要成为设计部门或者一个公司对于设计品质的共同价值观，让大家伙都知道这样做出来的是好设计，通过这样的规范教育和交流，形成对设计品质的统一认识。设计规范不是规定要做什么，而是提出这样做是正确的，但是有更好的地方可以改进。

国外设计师管这种做法叫设计工具，是模板化应用的方法（stencil），我们称之为规范，更多的偏向于规则（regulation），却只学习到了量化指标的简单部分。说的严重点吧，我们中国人向来就特别擅长给自己搞个框架（紧箍咒），来约束人的作为与想法，可能有三个原因：
1. 我们不太擅长找到解决问题的严谨逻辑，甚至是已有现成教训的；
2.我们始终缺乏对于团队成员之间的信任，哪怕是共同合作了多年的；
3.我们的企业无法承担某些错误带来的后果，甚至是很小风险的。

我们一开始就把一个工具性的东西变成了制度，因此问题便出来了。对于成长期的设计团队来说，建立设计规范需要的是确立一套可用工具，然后在工具的基础上发展成为部门设计品质建设的road map，如果只是弄个“导航按钮间距不得超过10px”这样的规范，就跟小时候尿尿要听到“嘘~~~~”声一样，尿得更快。

我不是跟这儿扯谈，在我看来咱们现在行业里面瞧得见摸得着的优秀的设计规范不多，现在来说说，和大家交流一下：

1. 设计规范达不到预期效果的原因

总是出现问题和错误后才开始拟定和修改规范，缺乏预见性；
规范制定出来后，执行不到位，缺乏力度和奖惩措施，监督控制节奏拖沓缓慢；
在产品设计过程中，不对设计规范做进一步的修订，甚至之前出现的错误也不去改正；

完全教条的根据设计规范设计，比如有些团队做的还是通用设计规范，很多设计师就照着里面的要求重复设计类似的页面，类似的广告，类似的动画，完全豪无特色，没有差异化。- 用心的话，你可以看看现在各个互联网产品的相似程度有多少？我不得不说，那些恶劣的设计规范要负一定的责任。

2. 设计规范最常见的错误

让部门领导者制定设计规范 - 设计规范是共同讨论出来的，在迭代中改进修正，由于国内设计师大多数有“领导恐惧症”，因此这样的规范就算制定出来也是空头支票，甚至有不少领导是很少参与一线工作的。
照搬国外成功团队的设计规范 - 这样的事情多半发生在喜欢“洋为中用”的设计团队中，国内外的设计环境差异很大，产品差异很大，面对的市场差异也很大，所以不要照搬，更不要直接翻译。
把设计规范打印出来贴在座位旁边 - 这是“大字报”，还是“表决心”啊？从我认识的设计师朋友来说，经常看座位旁边的东西只有2种，一是日程表，二是检查手机电池是否充满了。

3. 设计规范的本质是做好人的工作

在我看来，中国的企业只要是有设计部门的，做这个设计规范，最重要的是要和企业管理，团队文化建设绑定到一起，做人的发展建设工作。我们的设计师老实说没那么成熟，也没有过多的设计锻炼，整个不良的规范在哪儿杵着只会让设计师更加不愿意沟通 - “有啥好聊的？不是有规范么，照着做就行了”

设计部门如果真的沟通紧密，在设计过程中有共同价值观，这一个设计的流程是顺水推舟的，也是自然就形成的“规范”，不需要过多的文字描述。我还见过某些公司的设计规范中赫然写着：“一旦出现上述设计制作中A-C问题，设计师个人考评-5分”，OMG，原来你家的产品原来就值5分。

4. 优秀的设计规范要达到什么目的

A. 量化指标： 确定一般可用性原则和审美常识下的避免犯错的方法，以及一旦出现错误后的补救方案。规范的第一个目的是减少设计过程中出错的次数，一般这是针对新手设计师的，好的量化指标是告诉他经验，比如：建议html文件输出后在ie6,ie7,firefox,safari中做至少2次不同分辨率测试，并将结果添加到《设计规范-参考数据》中；而不是规定他方向，比如：根据产品部要求进行测试修改。

B. 确认设计关键点： 获得该设计规范针对范围内的关键点，包括设计方向和设计元素，以通过项目设计的过程，达到团队成员的更加密切的配合效果。它是一份检验文件，记录过程中的错误，留作以后的经验。并在此可以做出项目和产品设计的里程碑。

C. 规范设计原则： 这个原则有可能是针对单个项目的，也有可能是整个设计团队的指导原则，这个原则要被反复强调，反复实施，团队人员要共同为这个原则负责，比如：“确保在任何项目结束时间前4小时，完成设计输出”，“绝不允许设计粗糙的界面方案，如下图所示说明：XXXXX”等。

D. 设计规范本身也需要可用性： 描述同一个设计要求，可以说：“S级设计师针对该项目phase1部分工作，可控时间不超过2.5循环周期，输出交付件供ISO000459号程序评审”；但这样描写，能够明白的人会更多“界面设计师 XXX 设计该项目界面高保真原型，需在10个工作日内完成，5月22日下午14：00在5号会议室评审”。

千万不要把事情搞复杂，能把事情做简单的人是伟大的，设计规范也是如此。

转载请注明出自UCDChina.com，谢谢。

相关文章

• 以团队默契总结出规范
• ASK ME，关于界面规范(1)
• 设计规范的理想

“每个孩子一台笔记本”项目向发展中国家的孩子们承诺了新的教育机会，但它也并非没有问题。约翰·艾尔金顿和乔迪·索普报道。

这篇文章提出了两个问题，第一个是：没有使用指导的电脑对贫穷国家的孩子会有多大帮助？这个问题的答案有很多不确定因素。有理论认为，无论住在哪里的孩子都能从早期的电脑接触中获益良多。为了测试这个理论，印度电脑培训公司NIIT进行了一个“墙洞”项目，就是在德里贫民窟的中间设一个电脑小屋，旁边架上照相机来记录实验的过程。结果令人震惊：在短短几个小时之内，当地的孩子们——基本上都不识字不上学——已经学会了如何控制鼠标，在短短几周之内，他们就学会了如何使用应用程序、改变桌面设置以及浏览网页。

作者简介：约翰·艾尔金顿，SustainAbility创办者兼非执行主席，Volans Ventures联合创办人。

小松是科男（科研型男青年）：专业方面没得说，除此之外兴趣广泛：房地产、建筑视觉、城市、网络、新技术……

以下是我们在聊天中他给我推荐的网站：

www.my1510.cn 不能以愤青的心态看这个网站。

http://webleon.org/ 这个我每天都看，实际上和你说的玩网络有关

http://www.readwriteweb.com/ 这个每天看，但看的有限，信息量太大，英文的网络工具推荐网站

http://www.wangtam.com 中文推荐网络玩物最好的网站

http://blog.donews.com/keso/ 从keso自己做顾问去了以后更新频率太低。真希望房地产评论也能出来个类似的人物。

http://archlife.spaces.live.com 哈哈，我的。

I already wrote about some MySQL Error Messages which are confusing, here is one more:

After setting up new slave Server I'm getting error log file flooded with messages like this and there is no hint in the message what would explain what is wrong.

In fact the issue in this case is (because of configuration error) two slave servers got the same server-id.

Seriously in this case Master clearly sees the problem in this case as there are 2 servers with same server-id connected and replicating so it should report it to the slave instead of sending end packet.

At very least it would be nice to include possible reason for this error message which MySQL already does in many other cases.

I've now filed it as a bug.

Entry posted by peter | One comment

Add to: | | | |

规范的建立之路：

我曾经和一个UI、一个程序员三个人一起开发过，我给UI的需求从来不写细节，她出的页面也不会返工。甚至到程序的那个部分都是一路绿灯的。我想这样的开发速度是任何文档或者是规范都是不能比的。

但是后来人多了，我就不得不一遍一遍的告诉每一个UI，我的思路是什么，我习惯于怎样去设计，甚至包括我用了什么样的符号在设计文件上，那个是表示什么需求的。这样，容易被UI理解和记忆的被使用了。还有一些不能满足要求的，我不得不按照他们的意见去写自己的需求和设计文件。

这样规范就形成了，新来的产品经理，UI设计师，程序员都是按照这样的方式去作事情。

建立规范的目的是信息的有效传递：

先举个例子，同事去买烟； “哥们，帮我带瓶水回来。”结果这个新来的同事帮我带了瓶矿泉水回来。而如果是老同事的话，一定会给我带一瓶可口可乐回来。
事情的原因在于我没有清楚的说出，我要的是什么。可能规范的目的，就是避免这样理解错误的发生。
从最开始的一段就可以看出，如果只是为了快速的开发，那么最需要的是开发人员间的配合，而非规范。有些时候，这些规范反而会影响到开发人员个人的开发效率。
虽然在理想的状态下，规范可以帮助建立默契，但是规范往往是在第一代或者是某一代开发人员默契的配合下形成的，这个先后的关系在很大的程度上制约了规范在这个已经形成的团队中来发挥这个功能。

结合上两段表述的内容，规范真正要建立的不是本身开发人员中的默契和快速开发，而是为了建立一个传承。让后来的人能在应用种快速的和原来的队伍形成一种默契。
甚至可以有这样一种理解，如果一个规范被推出以后，而且比较合理，成为真正的规范，对于后来的人来说，按照这个规范来作事情，可以节省很多的思维时间。在这里，规范才真正体现了其快速开发的意义。

由此可说规范是必须的，在一定程度上，两个人之间传递的信息，往往会因为个人的习惯不同而产生不同理解，规范在很大程度规范了表达的方式，使得不同习惯的人之间的沟通的信息更加有效。当然，这如果扩展到了两个团队之间，一个团队的规范，可以帮助其他的团队按照这个团队之间的沟通方式快速的组建起来，这更是规范在宏观上的意义。

规范必须是细化的可执行的：

去年我们分管编辑部分的高层给下面一个操作规范，上面写的东西是，编辑要尽量多的添加该频道的资料，资料要尽量的于频道的核心有关系，资料要尽量的对用户有帮助。
看到这个规范，我的第一个反应是想痛打他一顿。
诚然，这些都没有错，但是确是完全没有办法执行的，因为所说的所有东西，每个人都有不同的理解；因此，这个东西只能是一个规则或者是原则，拿给编辑部的主管（当时没有）看看还成。但是拿个普通编辑就……。

一个成文的规范，必须是没有理解歧义，并且是完全的可以执行的规范，如果在任何一个角度，这个条目可以细化下去，那么必须将它细化下去，否则规范在给新人看的时候，他们依然会按照自己的理解去细化这个规范，理解上难免就会有所偏差，起不到传承的目的。

规范的建立是团队的作品：

现在建立规范的方法，往往是一个团队种某个领导人的思路，当然，这可以使得规范文件迅速的形成，但是副作用就是，这个规范文件很可能被尘封。

第一点原因是，建立规范的领导是往往是按照自己的习惯建立规范的，这个是不是符合多数人的习惯是一个问题。
第二点是按照正常的理解，领导的能力往往是比被领导的人是要强的，其建立规范的时候往往是很难考虑员工的理解能力和在这样条件下的发挥能力。
第三点也是最重要的一点是一个人建立的规范，就很难是完全合理的，虽然领导是比较有权利的，但是在这些不合理的地方存在的时候，员工们看待这样规范时的厌恶感情，要求领导必须时刻注意才能推广这样的规范，尤其是在新人进入的时候，而领导往往不是这么有时间来作这样的事情。

所以规范应该是一个公司第一代或者是某一代员工默契配合，工作总结的结果。而并不是什么人强制下去的结果。当然，在有一个合理规范的时候，对于后加入的员工，这个规范能很好的起到传承前一代员工思想和协作的工具。

以上几点只是个人的拙见，欢迎大家批评。

转载请注明出自UCDChina.com，谢谢。

相关文章

• 设计规范有谱么？
• ASK ME，关于界面规范(1)
• 设计规范的理想

1988年夏天的一个平常早晨，在美国新罕布什尔州一个小学校举行的一个学术会议上，来自加州大学洛杉矶分校的地球物理学家Y.Y.卡根做了一次关于地震研究的讲座。因为与会的科学家多数并非地震专家，卡根介绍了一些地震学的基本知识，在告诉听众地震是如何的难以捉摸、无法预测时，也谈到已知的少数几条地震规律之一：古腾堡－里克特定律。

在1950年代，加州理工学院的地震学家比诺·古腾堡和查尔斯·里克特收集了发生在世界各地的几千次地震的资料加以统计，试图从中理出一些头绪。比如说，地震震级发生的频率是不是呈正态分布（出现一条两头少中间多的钟形曲线）？也就是说，是否某个中间震级的地震最为多见，是典型震级？人的身高就属于正态分布，中国成年男性的典型身高大约是1米7，比它高或矮的人数都逐渐减少。但是古腾堡和里克特却未发现有典型震级，震级发生的频率不是正态分布，但也不是毫无规律，而是震级越高，则发生的频率越低。而且，它遵循一条简单的原则——幂律：一次地震释放的能量每增加一倍，发生的频率就减少为四分之一。

卡根此前已在其他地方多次做过类似的讲座，这回却有了意外的结果。听众中包括在纽约布鲁克哈文国家实验室工作的丹麦理论物理学家伯·巴克（1948-2002）。在听了卡根对古腾堡－里克特定律的介绍后，巴克突然想到，地震的这种情形很像他正在研究的沙堆崩塌。

假如我们往一张桌子上一粒一粒地丢沙子，沙子将会逐渐堆积起来，越来越高，但是不可能一直高下去，随着沙堆变高，它也变得越来越陡、越不稳定，到一定程度，刚丢下去的沙子会引起沙堆的崩塌，让沙堆的高度降低。崩塌之后，继续丢沙子，沙堆又再增高，然后再崩塌，如此循环往复。

巴克首先想要知道的是一个看来很简单的问题：沙堆崩塌的规模有小有大，什么样的崩塌规模是最典型的？能否预计下一次的崩塌会有多大？这需要堆许多沙堆进行统计，很费时间，所以巴克就改用计算机程序进行模拟。巴克和他的两名同事研究了数以千计的“虚拟沙堆”，统计了数百万次的崩塌中的沙子数。他们找到了什么典型崩塌规模了呢？什么也没有。有的崩塌规模小到只有一粒沙子，有的则大到几百万粒沙子。什么样的规模都有可能发生，但是并不存在一个典型的崩塌规模，无法预计。

这是为什么呢？为了回答这个问题，巴克等人对其程序做了一些改进。设想从上往下俯瞰虚拟沙堆，然后根据沙堆上的每粒沙子所处位置的陡度着上不同的颜色：如果那个位置相对平稳，就着上绿色；比较陡峭，就着上红色。刚开始堆沙堆时，都是绿色的。随着沙子的堆积，红点也逐渐增多，进而形成网络。一粒沙子掉到红点上，就能触发周围红点的滑动。如果红点很少，新丢下去的沙子的影响就很有限。但是一旦红点多到连成一片，就无法估计新丢下去的沙子会导致什么结果：它可能只是打几个滚就停下了，也可能触发周围的沙子引起一场小规模崩塌，但也可能引起一连串连锁反应，像多米诺效应一样，导致几百万粒沙子一起崩塌。这种高度敏感的不稳定状态称为临界状态。由于它是在沙子堆积过程中自己逐渐形成的，巴克称之为自组织的临界状态。在这种状态下任何规模的崩塌都有可能发生，但是即使是最大的崩塌的发生也无其他特殊的因素。它是完全不可预测的。

巴克也发现，沙堆崩塌规模虽然不是正态分布，但是遵循幂律：崩塌规模越大，则发生的频率越低，参与崩塌的沙子数目每增加一倍，其发生的频率则降低2.14倍。所以，巴克一听说震级的频率也遵循幂律，马上就想到地震可能和沙堆崩塌一样，也是一种自组织的临界现象。随后他和其他许多人构建计算机模型，对地震进行了模拟。

由于地壳的运动产生的应力逐渐积累，地球处于临界状态。某个地壳断层的某处岩石承受不了受到的应力，就会出现滑动，这个滑动可能小到无法觉察。但是正如一粒沙子的掉下会让处于临界状态的沙堆出现无法预测的结果一样，这个小滑动之后，任何情形都可能发生：它可能就此停下来，也可能给附近的岩石带去足够大的应力让它们跟着滑动，引发一场地震，而这场地震的规模是无法预料的。不管是小地震还是大地震，它们的起因都一样，都是由于地球处于临界状态而引起的，此外大地震的发生并无特殊的起因，既无法预测，也没有可靠的前兆，就像大规模的沙堆崩塌一样。如果地震有意识的话，在它刚刚发生时它自己都不知道将会有多大规模，而地震自己都不知道，我们更无法知道。

2008.6.1.

（《中国青年报》2008.6.4）

(XYS20080604)