今天使用我写的jQuery Countdown Plugin时，遇到一个特殊的需求：要停止正在进行的倒计时。
Google了一下，发现window.clearTimeout可以做这事儿，但要求首先获得window.setTimeout的句柄，我在写这个plugin时并没有考虑这点，又不想加个句柄变量到jQuery对象中，于是再度Google，并发现了一个window.clearTimeout的很奇怪的用法，可以自动获得句柄：
window.clearTimeout(setTimeout("0")-1);
这条语句确实能够满足我的需求，可我不明白这是什么意思，哪位高手能给解释下？
根据这个发现，我顺便更新了plugin－加了个stop()方法，详细用法和下载见这里。
此外一个有趣的现象就是：在IE和FF下，window.setTimeout返回的句柄不同。在IE下，它是一个8位的数字，并且每次刷新页面时这个数字以3递增；在FF下，它是个各位的数字，并且刷新时不会有变化。
我坚信一点：对于大部分互联网公司来说，设计师完全不需要太多的分工，我认为一个小而精的架构组、一个用户研究组和一个设计师组就能够很好的适应互联网公司的需求了。
就像软件开发中的情况一样，架构组中个个都是高手。这个组对整个设计团队的设计质量和工作效率起决定作用，它负责制定设计目标和设计哲学、提供设计规范和工具、探索和引入新的设计和技术，并且引领整个设计团队和公司产品在用户体验上的发展方向。
这个组在行政上必须拥有绝对的权利，并要有完善的制度和流程，来保障架构组成员能够使用上述权利去控制设计的质量。Apple为什么能持续不断地产出高质量的设计？这是和Jobs本人对设计质量的无限追求和至高无上的行政权力分不开的。
此外，架构组绝对不是脱离产品设计实践去搞高精尖的东西，实际上，其中成员必须积极地投入到产品的设计和研发过程中，身体力行的检验和更新自己的工作成果。
用户研究组没啥好说的，能把两件事儿做好就行：用户调研和用户测试。
坚决反对搞那些花里胡哨的分工名堂，比如什么“交互设计师”（或“用户体验设计师”，UE）、“前端开发工程师”和“视觉设计师”等等。除非你的产品确实有大量且复杂的前端开发和视觉设计工作量，否则过细的分工只会降低工作效率、增加沟通成本，并最终导致设计质量不高。
此外，“交互设计师”（或“用户体验设计师”，UE）的进入门槛有多高，相信大家都心知肚明。更何况，“交互设计”这个概念本身如何定义，“交互设计师”的工作职能包括哪些，又如何去衡量他的工作成绩等问题仍是没有定论。一个典型的现状就是，同样一个名称为“交互设计师”的职位，在各个公司的职能可能是千差万别的，这点随便参加一个行业会议就能立即感受到。因此在现阶段下，我完全看不出单独设立一个只做“交互”的“交互设计师”这一岗位的必要。
那么这个设计师组中的成员该叫什么呢？这并不是最重要的，关键在于搞清楚他们的职能范围。
对于相当一部分互联网公司的设计团队来说，这个设计师组中的成员应该实行包干制：从部分用户研究到设计再到代码实现都一包到底。网站的设计不像软件开发，前者通常要在极短的时间里实施一个完整的“调研－设计－实现”流程，这就在客观上要求流程中不能有过细的分工和过多的步骤，经手的人越多，效率越低；此外，和软件相比，网页的实现难度完全不是一个数量级上的，说难听点，把一个智商正常的成年人送去学上一个月的HTML/CSS，就可以处理互联网公司的大部分日常需求，7、8年前我在外面讲课时，有些具备FoxPro基础的学员一个月后连Javascript都写的有模有样了，可你让他学一个月的Java看看？因此，实现技术的低门槛为一个设计师实行包干制创造了必要条件。
但并不是所有设计师的工作职能都是一样的：必须把具备较高能力的人提升为主设计师（或资深设计师），由他来带领其它普通的设计师工作。此时，他的角色非常类似于程序开发中的“系统分析员”，在一个产品项目中，他的设计规划将作为其它普通设计师的工作基础。比如他为这个产品设定了怎样的用户体验目标、采用了怎样的设计思想和哲学、选取了何种规范和工具等等，他还要做一些类似项目管理的工作，以便更好地让不同的设计师协作。实际上，可以考虑让架构组的成员兼任产品项目中主设计师的工作，这样既可以发挥他们的高水平，又可以让他们对各种规范的实施情况有一个切身的体会。
另起一段，休息一下。
之所以写这篇文章，一是因为我觉得我提出的“用户体验架构”这一概念，不仅要适用于单个设计师，更要涵盖团队建设的方法，否则称为“架构”就未免显得有些单薄，写完此文后，我感觉我的“用户体验架构”已经有一定的雏形了，接下来的工作就是尽快把它用图示辅以文字的形式整理出来；写这篇文章的第二个缘由是，我下午参加公司的设计沙龙时意外地发现，原来不仅是我，几乎部门内所有的设计师都对“交互设计师”的岗位职能感到模糊（虽然我是“用户体验设计师”，可谁能告诉我这是个什么职位？），并且也都或多或少的表达了“不满意分工过细”的观点；第三，我一直觉得“网页设计师”这个说法没什么不好－一些早期网页设计师的作品一样注重可用性和用户体验。
最后必须要说明的是：1）我目前并没有机会去从管理者的角度实践上述方案，但它是我根据自己的经验，不断摸索和总结出来的想法。如果你认同我的观点并付诸实施，请务必告诉我你的心得体会；2）各个公司的情况不同，我仅以与支付宝类似的网站为例。
丁宇，08年3月25日夜
写了一个简单的倒计时（countdown）插件，用法非常简单：
$('div.countdown').countdown({seconds: 3,callback: 'helloWorld()'});
上例中，这个插件会在div.countdown中插入3秒钟的倒计时，直到0为止并调用helloWorld()这个函数。
这个插件有两个选项：
目前的版本是0.2，下载地址如下：
这个插件在jQuery Plugins上的项目站点，觉得好用可以投上一票 ：）。更新记录：
0.2。加入了stop()方法，可以停止一个正在进行中的倒计时。
Core Animation的技术文档一直非常少，就连Apple Developer Connection上也是凤毛麟角，Google来Google去的就那么几篇文章，真不知道Apple是怎么想的，大概07年真把它给累垮了。
幸好有一本名为《Core Animation for OS X: Creating Dynamic Compelling User Interfaces》的书即将出版，算是贴补了此领域的空白。大牛Scott Stevenson这样提及此书：
the model is to basically ease the reader into Core Animation concepts. The focus is initially on adding animation to existing Cocoa views, but moves onto deeper details of the Core Animation framework itself by the end of the book.
单买PDF的话22美元，倒也能接受。感兴趣的话不妨玩玩，在iPhone上搞Core Animation，不仅有意思，搞好了更可有收入。
我正在阅读《Pro CSS and HTML Design Pattern》一书，下面是对HTML Structure一章的读书笔记。
这本书中很多概念和通常意义上的不同，下面的图片是我根据这本书HTML Structure部分的内容整理出来的，点击放大：
从结构上说，定义列表中所有的术语都是同义词，所有的定义都是对这些术语的不同解释（"Structurally, a definition list implies all its terms are synonyms and all its definitions are alternate definitions of its terms")。这句话令我百思不得其解：dt标签所包含的术语怎么会是同义词？书里面继续解释道：HTML规范也指出定义列表也可以有更广泛的应用，比如列出演讲者和他们的演讲主题。如果这个例子没有弄错的话，我想作者使用“同义词（synonym）”的初衷，是想表达dt在逻辑上层面的一致性，而非内容上的一致性。
老实说，这两个标签我从来没用过，恐怕连听说都是第一次。稍微Google了一下，发现了一篇名为“理解表格二：其他表格相关标签及属性”的文章，详细深入的介绍了这两个标签。作者水平很不错，推荐去他的blog看看。
W3C Recommendation中的7.5.3一节简要介绍了block-level和inline elements的区别：
block elements用来定义结构，它不能和内容在逻辑上并列；同理，内容必须呈现在block elements中。由于HTML的Docuemnt Type Definition语言的局限，HTML校验器一般无法检测出block elements和内容混杂的情况，因此在编写HTML时需小心。
图片来源：Pillow Design Looks Like Rock Avalanche
图片来源：Pingdom
众所周知，豆瓣使用了一系列标签来对用户进行分类和聚合，如“我读过”、“我想读”和“我最近在读”等等。我在使用时觉得豆瓣有一些设计问题处理的并不是很好：
一本好书往往要读几次才能出味道，方能领悟其中的只言片语。甚至像《红楼梦》这样的巨著，我都是爱不释手的反复阅读的。因此面对豆瓣的标签，我常常不知道该选择哪个才能正确表明我现在的状态。从逻辑上说，如果出现了“我读过”这样的标签，那么除非特殊说明，否则其它的标签在时间维度上就处于“读过”之前，也就是“没读过”，此时“我正在读”这一标签显然不适合我。
在豆瓣中，只要你想标记一本书（或一部电影、一张CD）的状态，你就得收藏。可如果我仅仅想表明我读过，但却不喜欢、或者没有到愿意收藏的程度呢？此时现有的设计就无能为力了。
关键在于，“收藏”到底是什么意思？是表示自己拥有？仅仅喜欢不曾拥有？还是其它的什么感情？就我个人来说，我拥有的书和CD的数量远远小于我读过听过的，而我收藏的书和CD又少于我所拥有的，因为只有那些我最喜欢的才算得上收藏。
我无法获知“我的豆瓣”这个页面的PV有多少，可如果的确有很多人希望将此作为展示自己的窗口的话，强烈建议豆瓣对这个页面和“收藏”的概念进行重新设计。我甚至连名字都想好了，就叫“豆藏”！去年参加UPA时曾和阿北提到这事儿，可惜当时他对Delicious Library这样的东西（如下图）不感兴趣，不知现在可有转变？
在标记书籍、电影和音乐时，要先点“收藏”，可是到了同城那里，却可以直接选感兴趣还是要参加了。如下图：
这个菜单总在我首先选择搜索类型时就递交了搜索申请，极其讨厌！这让我联想起Pocket PC上的微软拼音输入法，都是设计师不顾用户习惯而想当然的设计。
最后得声明一下：别误会，我是豆瓣粉丝！
第一次来？先看看“有感于与三通的对话”和“初探用户体验架构（“有感于与三通的对话”续篇）”，否则可能看完了都不知道我到底要说啥。看过前两篇的请继续往下读，接着批判。
如果说界面设计的哲学还能凭感觉胡说几句的话，这个设计流程和交付物可绝对是马虎不来的，因为其质量的高低将直接影响最终的设计质量。
一般来说，采用UCD的流程大体上遵循“研究－设计－测试－实现”这样一个流程，所不同的只在于，1）是使用类似开发中“瀑布”还是“敏捷”的方法；2）每个阶段的产出物及其衡量标准。对于第一个不同，似乎传统行业倾向于使用“瀑布模型”，而互联网公司更倾向于“敏捷”。第二个不同则大有文章可作－相对于设计流程，对各阶段交付物质量的把控显然更为重要，因为流程本身最重要的作用，就是在一定效率下保证合格交付物的产出。那么，前文一再谈到的规范，就正是作用于这些交付物。合理的规范不仅可以极大的提高工作效率，更重要的意义在于保证交付物具有一定的质量。
为了避免讨论太空洞，下面我将以一直在参与的一款产品（以下简称“A产品”）为例，说说我在推广的一些规范（值得一提的是，由于可能涉及信息保密问题，我只能大致讲下概括）：
规范看起来很多？其实在一个拥有复杂业务逻辑、许多不同部门的人协作的项目中，一些明确清晰的文档只会减少沟通成本。
未完待续，白鸦别急，呵呵 ：）
丁宇（Felix Ding），电脑Geek，狂热的爱书和爱乐分子。现就职于上海的一家设计工作室。
我的Email:
(C)2000-2008 心弦。版权所有，保留所有权利。
本Blog基于我自己编写的Lonely Thinker(LT)构建，目前版本为0.3.10.20080805。
