CSS森林(CSS Forest) - Articles

迎接AI时代——在生产力重构中寻找新位置

Ghostzhang — 2026-04-11 21:20:00

迎接AI时代——在生产力重构中寻找新位置

由 Ghostzhang 发表于 2026-04-11 更新于 2026-04-20

感觉 AI 的发展太快了，但这只是一种错觉，了解一下历史，虽然“人工智能”一词最早出现在 1955 年，但对 AI 发展至关重要的事件却可以追溯到几个世纪以前。只是与普通人的关系不大，所以感觉不明显。直到现在，当技术真正触达应用层，我们才感受到这种“突袭”般的快节奏。

历史的镜像：技术冲击与焦虑

每次科技浪潮带来的冲击，总会让部分人感到焦虑。因为新技术带来的改变，必然导致依赖旧技术生存的人面临重新选择的风险。

这在历史上屡见不鲜：

纺织机的出现让手工织布的匠人不得不转行或学习操作新机器
PhotoShop 革命性地将传统的排版和插画工作交给数字工具，许多设计师必须重新学习软件或设计方法
手机相机让暗房冲洗、胶片拍摄等传统工艺迅速衰落，摄影师转而投向数码后期

互联网行业的快速发展对各行各业的冲击，与当前 AI 带来的变革其实本质相同——它们都是颠覆性的。时代的车轮已经转动，与其螳臂挡车，不如面对现实。

AI 时代的定位：是“替代”还是“重配”？

在经过前两年的慌乱之后，最近也慢慢能看到一些更深层的反思。比如在 AI 时代，人类的定位是什么？AI 替代掉一些工作岗位，真的不可接受吗？

实际上，AI 的影响是整个社会分工的重构，而非简单的岗位消灭。Anthropic 在 3 月发布的一份关于 AI 对劳动市场影响的数据显示，与信息处理相关度越高的岗位，受影响程度越大。

因为信息处理正是 AI 的强项。

但”影响最大”不等于”被取代”。研究里有一个说法让我印象深刻：AI 目前更像是在”重新分配工作”，而不是”减少工作”。

会用 AI 的人效率变高，接到更多的活；不会用的人，则面临实质性的竞争压力。

—— AI到底在抢谁的工作？Anthropic拿出数据了

在AI 时代，所有可重复生产的东西，价格都会快速下降。因为生产成本正在被技术压缩到极低。

以绘画为例。过去，一幅精美的插画需要多年训练和数小时创作。但现在，像Midjourney 这样的工具，普通人十分钟就可以生成一张高质量作品。

当创作工具完全普及之后，单纯依赖“技术门槛”的价值体系就会被迅速削弱。

真正变得稀缺的，反而是那些难以复制的东西，比如审美判断、个人风格、叙事能力、情感连接。

换句话说，在AI 时代，当生产力趋近于无限时，价值并不会消失，而是会迁移。它会从“事物本身”，转移到“事物背后的意义”。

这个逻辑其实很像F1比赛。

在这项赛事里，最有价值的资产不是赛车，而是车手。因为赛车的性能相对稳定，但驾驶员的判断力和技能差异很大，车手才是影响比赛结果的最大变量。

人工智能也是一样。强大的工具在不同的人手里，会产生完全不同的结果。

归根结底，AI带来的并不是简单的替代，而是一次生产力结构的重排。

—— Anthropic 用一份报告，说透了 AI 时代的就业真相

当前AI的相关的宣传不少都是别有用心的，过分夸大某些功能或现象，制造焦虑，让不少人都产生了认知扭曲。实际情况远没有那么糟糕，当前确实有不少公司在大量裁员，但这个现象在我看来是企业在以“AI提效”为借口处理早几前扩大招聘的债务，大公司还能理解，那些中、小企业跟风裁员就有些想不通了，原本公司就没几个人，效率就不高，再裁员不就更雪上加霜了吗？引入AI就真能提效？自动化的前提是标准化，标准化的前提是流程化，流程化的前提是规范化，不是一蹴而就的。大多数企业只看到自动化的好处，却忽略企业是否具备自动化的前提，也不验证一下是否真能解决公司的问题就先把人裁了，也是生猛，干不死就往死里干。

警惕“多巴胺”陷阱

面对焦虑，最有效的办法是剖析焦虑的来源。

在《杀死你的不是 AI》中提到的一个观点，很有意思：AI 可能会让我们变成“头顶接电线的老鼠”。

之前的文章中，我曾提到，AI 把人活脱脱的变成了头顶接电线的老鼠，只要你按下按钮，大脑就会被刺激到，多巴胺变会被分泌出来。「再换一个模型」、「再换一个 prompt」、「再试一次肯定能成功」。实验里的那只老鼠不吃不喝变成了一个只靠按钮取乐，最后把自己饿死的可怜虫。而现在我们则变成了不眠不休盯着 LLM 输出的异物。

那是一种全新的成瘾，与赌博别无二致，更糟糕的是具备正当性。

回想一下，当前大家对 AI 的热情，跟『老鼠电击实验』中的老鼠确实很像，特别前段时间 openclaw 带来的现象，已经有点往失控上走的意思，好在 AI 当前的实际效果还没有达到完美，这给了我们一个让热情冷却、理智思考的窗口期。

开发岗位：从“写代码”到“建系统”

开发岗位是受 AI 影响最大的岗位。虽然写代码这事门槛降低了，但代码质量还是决定一个互联网产品或软件最主要的指标，而这部分至少目前 AI 是无法保证的。

对于基础扎实的开发者，AI 是巨大的效率加速器。但真正的危机在于：当开发者习惯于依赖 AI，而忽视基础知识时，才是行业最大的冲击。

我们要意识到，开发一个系统的最大挑战不在于写代码，而是在于：

前期：需求分析、架构设计、技术选型、方案评估
后期：日常维护、风控管理、运营管理

等等，但大多数开发者并没有掌握完整开发一个系统的所有知识，这也是开发一个系统需要多人合作的原因，当然分工也会带来岗位差异和沟通协作问题，但本质上是掌握知识差异的问题。

优秀的人依然优秀，与其担心被工具替代，不如利用工具更好的提升自己。

交互岗位：重新定义人机界面

看到一些比较深刻的思考，比如《You’re still designing for an architecture that no longer exists》，提到了作者在使用 Claude 时的想法：

We keep asking the wrong question. We keep asking how good is the assistant — how well it writes, codes, summarizes, reasons. But that question belongs to the old architecture. What’s actually happening is bigger: the environment itself is changing. The space where we work — the one we’ve inhabited for four decades, the one built on windows and menus and folders and clicks — is being replaced by something structurally different. And if you’re still designing screens, flows, and navigation systems, you might be perfecting the blueprint of a building that’s already been demolished.

人机交互的方式由于输入输出方式的改变，也必然发生改变。当前的交互方式是通过终端界面进行的，而由于终端硬件的限制，就需要有针对性的进行设计。

比如移动端出现后，有人就提出把 PC 端的界面直接应用到移动端，但移动端的硬件有自己的特点——屏幕小，交互方式也与 PC 端不同，原本 PC 端的界面实现方式就不适用了。也是经历了一段时间的争论和验证，才慢慢达成共识。

结果无非就是根据产品需求，平衡开发成本和收益，再决定要做几端。设计规范也是从 PC 端延续到移动端，好听讲叫减少用户学习成本，本质上就是重新定义一套标准成本过高（当前有能力定义的也就 apple 和 google），与其重新定义，不如在现有基础上修改。

而 AI 的快速发展，对传统的界面交互确实带来了冲击，但至少在 token 像现在的水和电一样便宜之前，传统的交互方式是不会被完全抛弃的，因为底层的逻辑还是成本。对于一些问题明确、功能单一的场景，并不需要使用 AI。就跟智能汽车上的机械门锁一样。

交互设计，设计的是人与机器的交互方式，不管如何变化，只要机器需要与人进行互动，就需要交互设计，区别只是设计的对象变化了。就如移动端出现后，需要多考虑一个移动端的交互设计一样。

写在最后

AI 带来的并不是简单的替代，而是一次生产力结构的重排。

面对这个时代，我们必须重新思考哪些事情是 AI 能做的，哪些是它永远无法触及的，从而重新定义分工合作。这与当年电脑出现、互联网出现时的逻辑是一样的：谁能更快地在新的坐标系中找到自己的位置，谁就更有机会抓住时代的红利。

参考文档

眼见为"心"——探寻人眼机制与交互设计的深层联系

Ghostzhang — 2026-02-03 00:20:00

眼见为"心"——探寻人眼机制与交互设计的深层联系

由 Ghostzhang 发表于 2026-02-03

看了不少的设计理论，很好奇为什么会有这样的设定，除了通过不断的观察总结出现的现象之外，更深层的原因是什么呢？在一些文章中也了解到一个概念——『地缘政治』，介绍了地理因素（人文地理、自然地理）如何形塑政治与国际关系，并形成了一门学科。同理，人类这么多形形色色的特点，跟人体本身的生理构造也必然有着很大的关联。这也许对于加深理解各种设计理论会有帮助。

眼睛如何看见物体

人类的眼睛结构

人类眼睛由眼球、眼睑、泪器、眼肌和视神经组成，其中眼球壁分为纤维层（角膜、巩膜）、血管层（虹膜、睫状体、脉络膜）和视网膜层（视网膜）。眼球内部有房水、晶状体和玻璃体，它们共同聚焦光线，通过视网膜将光信号转化为电信号，再由视神经传至大脑进行视觉处理。

人眼能看到物体，是整个眼睛各个部分共同协调的结果，其中的黄斑区（macula）是视网膜中央一个重要的椭圆形区域，负责接收高精度的视觉信息，尤其是在阅读、驾驶等需要精细视觉的活动中发挥着核心作用。黄斑因含有叶黄素等黄色素而得名，其最中心区域是负责锐利中央视觉的中央凹。

光线由瞳孔进入眼睛，通过晶状体进行聚集后落入视网膜，光线的焦点会落入黄斑区的中央凹中，再由感光细胞对这些光信号进行转换。这里的感光细胞主要分为两种，视锥细胞和视杆细胞，分别负责感知颜色和感知灰度。

通过对视网膜上这两种细胞数量的统计，可以看到负责感知颜色的视锥细胞主要分部在中央凹之中，而视杆细胞则分部在两侧。因此，如果从单一时间点上来看，我们眼睛看到的界面应该是中央清晰且颜色丰富，越往外越模糊且颜色越不明显。

这可能比较反直觉，但从生理结构上来说，理论上的结果应该是这样。有一个实验可以来验证这一点。上面的图中应该有同学注意到了，人眼中有一个区域叫视神经盘，是视网膜神经纤维的汇集处，也就在眼底形成了一个没有视觉细胞的『洞』，也叫『盲点』。

顾名思意，在『盲点』中是看不到东西的。不对啊，如果眼睛中有一个区域看不到东西，为什么我平时没发现？这也正好能说明，为什么眼睛生理结构推导出来的结果是反直觉的。通过下面这个实验，可以让你看到这个『盲点』的存在。

可以找一张白纸（如A4纸），在左右两边分别画两个点，然后遮住一只眼，用另一只眼去看。如果是左眼，就看着右侧的点（右眼就看左侧的点），移动纸与眼的距离，注意眼睛保持不动，有某一个距离（约50厘米左右）上会发现另一侧的点消失了。

如果你在电脑上看，也可以打开上面这张图，用右眼盯着红色加号，移动头与屏幕的距离，约50～60厘米的位置，右侧的飞机会消失。

原理就是『飞机』的投影正好位于『盲点』之上，于是就『消失』了。那为什么平时我们并不会为此感到困扰呢？同样从生理上的解释就是，『盲点』正好位于另一侧眼睛的视野之中。

而且，除了『盲点』在另一侧眼睛的视野中这个原因之外，眼球是可以转动的，头部也可以转动，所以这个『盲点』的影响也就变得不明显了。

这里带来一个新的问题，虽然眼球可以转动，但眼睛的生理结构同样注定了这个转动是有限制的，于是就有了这个图。分别为水平角度

和垂直角度

知道这些有什么用？

不知道大家有没注意到这个现象，电脑的屏幕越来越大了，但网站的内容宽度却没有跟着变宽。是为了兼容旧的屏幕吗？

正常使用显示器的距离约50～60厘米，结合眼睛视野的角度

就可以大约计算出最舒服的阅读尺寸，具体可以看《页面内容最大宽度推导》

不知道是有意的设计，还是巧合，不少网站的内容宽度都在这个范围内。

眼睛的运作方式

前面知道了眼睛看到的画面是这样的（其实只要你专心盯着一个位置，就能感觉到类似中心区域清晰，四周模糊的现象）

看起来是点状的，既然是点状，那平常我们是如何看清世界的呢？没错，可能不少同学都知道，叫『扫视』。不是那个『扫射』，但也差不多，从一个位置开始，往另一个位置移动，只要速度够快，连起来就是完整的画面了（电视机的原理）。

方向

从一个位置移动到另一个位置，那就会有方向。

但大多数时候人眼并不是逐字进行阅读的，而是『跳着』。通过眼动仪可以得到左右眼在阅读一段文字时的移动轨迹。

这些视觉焦点的轨迹被称为视觉流。

从视觉流中发现了这么一个阅读特征

左侧的长图是文章的完整内容，右侧是阅读的视觉流，可以发现基本集中在前两到三屏的距离，后面就读不下去了。

这与《界面设计模式》中的『即时满足』、『满意即可』，没有耐心阅读长文等心理特点十分符合。

由于视觉流是通过眼动仪测试得到的，而测试用的界面则是设计的结果，于是我也在想，是因为排版问题，所以观众会这样看？还是因为观众这样看，所以排版才变成这样？

来看几张图，注意体会眼睛的移动

仔细感受下，目光是会受排版影响的

14世纪西方活字印刷术的发明人约翰•古腾堡提出的一种普避适用的阅读规律。

在超过130,000次的注视中，用户 80% 的时间都在关注左侧的内容。这也进一步说明了虽然屏幕越来越宽，但内容却并不是越宽越好。

颜色

人眼的另一大特点是『颜色』的感知

做过体检的同学对这种图应该并不陌生，利用不同颜色的排版来检验人眼对颜色的识别度

为什么需要对眼睛进行检查呢？

颜色是由视锥细胞负责的，视锥细胞又可以分为三组，分别负责红、绿、蓝三种颜色。

这三组里任何一组或以上的视锥细胞发育时有问题，就会导致『色盲』。是指能看见及辩别颜色的能力低于常人的状况。色盲目前是无法在生理上治愈的。

人类的色盲率相当高，十二分之一的高加索人（8%），二十分之一的亚洲人（5%）和25分之一的非洲男性（4%）是所谓的“红绿”色盲。它比AB血型更常见，据统计，平均每12名男性中就有1人有某种形式的色盲，每200名女性中就有1人，占人口的4.25%。

麦当劳每天为300万色盲客户提供服务。亚马逊每天超过110万客户是色盲。所以在设计上，往往需要考虑这一因素。

除此之外，颜色也会影响人的情绪，在不同的文化背景下，颜色会代表不同的含义。

动态

人眼还有一个重要的特点，就是对动态物体的捕捉

对于『动态物体』的敏感，来源于对『危险』的警觉。因此，会动的物体总会更容易引起人的关注。

小结一下，人眼的动作方式，一是通过扫视进行信息的收集，通过颜色、形状等进行物体的识别，对动态物体敏感

眼见非脑见

我们常说“眼见为实”，实际是真是这样吗？来看一个例子

先来画一个卡尼萨三角

脑补——预测看见什么

你能看到中间的三角形吗？

可以发现，我们并没有画中间的三角形，但我们还是能看到三角形。很显然，我们看到了一个实际上不存在的图形。这个能力能够让人类可以快速阅读和更高的兼容性

这些现象的总结可以了解一下《格式塔原理》

在视觉设计中被广泛应用

注意力——看向哪

来看一个短片

可能觉得这个短片平平无奇，如果你稍稍留意一下，探长的衣服颜色变了，前景桌子上的花变了，地毯变了……

事实上，短片中有21处变化，只是一开始被忽略了。但当你知道了这些之后再回过头去看，应该就能找到这些变化了，这又是为什么呢？

再来看一个短片，这次需要你来帮忙算一算穿白衣服的人一共传了多少次球

有人看到猩猩了吗？当你认真在计算传球次数时，很可能就会忽略无关的事物，同一时间能处理的事件的数量和复杂程度，与认知负荷息息相关

认知负荷——看到什么

当需要处理复杂问题时，认知负荷就会变得很高，当高到一定程度时，最直接的处理就是“放弃”，这个大家在生活中可能都所体会。

最后，如果大家对相关内容感兴趣，推荐阅读这几本

感谢阅读

《眼见为心——探寻人眼机制与交互设计的深层联系》 from GhostZhang

在腾讯的第十个两年

Ghostzhang — 2025-10-31 14:00:00

在腾讯的第十个两年

由 Ghostzhang 发表于 2025-10-31

很遗憾，没能真正到 20 年，时间停留在 7143。这篇也是我在腾讯工作系列的最后一篇了，心情复杂。同时也很幸运，在最后的时间里，能把之前的一些手尾的内容做了闭环。

回想这一路走来，大体可以分为五个阶段：

入职，新人阶段：《在腾讯的两年》

有热情，一切都新鲜有意思，团队氛围也很不错，大家都比较单纯。

立足，成长阶段：《在腾讯的又一个两年》、《在腾讯的第三个两年》

开始独立负责大的项目，要考虑的东西越来越多，一些以前不会想的内容渐渐进入视野。工作不再单纯，但还算简单。不满足于公司内，还试图影响行业。

成长，学习阶段：《在腾讯的第四个两年》、《在腾讯的第五个两年》

尝试了新的工作内容，接触了公司的管理体系，虽然只是最基层的岗位，但已经能体会到种种差异。工作渐起动荡，经历了三次大的团队重组。

受挫，祛魅阶段：《在腾讯的第六个两年》、《在腾讯的第七个两年》

大环境快速变化，岗位危机，工作危机，身体各种毛病接踵而至。生命也已过而立之年，上有老下有小，生活处处与你不善。

祛魅，沉淀阶段：《在腾讯的第八个两年》、《在腾讯的第九个两年》

回归平常心，生活没有与你不善，它只是一个回音谷，重要的是你要对它说什么。

几句话

公司BBS的签名：『前方无绝路，希望在转角～』
对新人常说的：『要带着明天会离职的心态工作，想想什么是你真正能从公司带走的』
团队群名称：『互为肩膀，共同成长』
企业微信的签名：『教明其方，学明其理』

新的开始

时代在变，从PC到互联网、移动互联网、物联网、大数据、人工智能……每一阶段都有自己的故事。还记得早些年，公司内最常听到的是『产品就像自己的孩子』、『主人翁精神』、『一切以用户价值为依归』，现在则更多的是『小团队』、『全栈』、『降本增效』；以前台风天会有关怀的短信，天灾网站会变灰；以前……

从价值观 2.0 的『正直、尽责、合作、创新』到价值观 2.1 的『正直、进取、合作、创新』再到价值观 3.0 的『正直、进取、协作、创造』，公司也在不断的适应整个大环境的变迁。能感受到公司从一个热情洋溢的青年小伙逐渐变成了一个圆滑老练、精打细算的中年大叔。

很荣幸自己参与了这一时代变迁的过程，感恩不同时期遇到的每一位。

系列文章

读《新乡重夫谈丰田生产方式》后感

Ghostzhang — 2025-04-08 19:48:00

读《新乡重夫谈丰田生产方式》后感

由 Ghostzhang 发表于 2025-04-08

看了《新乡重夫谈丰田生产方式》后的一些思考，感觉对之前的一些设计理论、方法是有误解的。

首先，丰田当时的时代背景，决定了丰田即要高质量又要省成本。

1941年，太平洋战争爆发因战争而不得不断念的丰田喜一郎把自己的梦想托付给了时任丰田专职董事的丰田英二，希望他能在3年内追上美国。

但是，当时美国汽车行业的劳动生产率已超过日本8倍，同时因为战败，丰田正面临着材料及资金严重短缺的困难。

丰田英二和时任机械厂工场长的大野耐一认为，要和欧美的高效生产设备比高低，就必须将自働化的思想渗透到制造工序的每个细微之处，从而提高员工劳动的附加价值，创出高效益。

——《透视IE论道—读《新乡重夫谈丰田生产方式》有感》

在这样背景下出现的工具、理论、方法都会带有强烈的目的性，同样也会有相应时代背景的局限性（或者说应用场景）。

其次，像看板的使用场景，是有一个前置的原因的，就是丰田推行的JIT(Just In Time)、后工序拉动等，通过看板让各环节能了解自己需要生产多少的工件。而我们现在使用看板，更多是当成一个任务状态管理工具，除了更直观之外（数量多了之后其实也不直观），并没有本质的改善。我就奇怪为什么这样被很多人推荐的工具实际应用时却并不是那么回事。

还有就是新乡重夫提到的SMED（快速换模）什么是SMED（快速换模）以及如何在您的工厂实施，看起来就是互联网公司常说的『高内聚、低耦合』。

防呆设计也是类似的，网络上的搜索结果都是字面上的理解：

防呆设计的定义：是一种预防矫正的行为约束手段，运用避免产生错误的限制方法，让操作者不需要花费注意力、也不需要经验与专业知识即可直接无误地完成正确的操作。在工业设计上，为了避免使用者的操作失误造成机器或人身伤害，（包括无意识的动作或下意识的误动作或不小心的肢体动作），会有针对这些可能发生的情况来做预防措施，称为防呆。

——《设计心理学 | 设计中的防呆设计 | 人人都是产品经理》

防呆（日语：ポカヨケ poka-yoke，英语：Fool-proofing）是由新乡重夫（Shigeo Shingo）提出的工业生产方式，并随着工业品质管理的推展传播至全世界。在工业设计中，为了避免使用者的操作失误造成机器或人身伤害，会针对这些可能发生的情况来做预防措施，被称为防呆设计。

——《「防呆」手法在设计中的应用 | 人人都是产品经理》

但从丰田的背景来说，下面这个解释更符合：

防呆法的作用在作业过程中，作业者不时会因疏漏或遗忘而发生作业失误，由此所致的问题所占的比例很大，如果能够用防呆法防止此类失误的发生，则质量水平和作业效率必会大幅提高。

——《什么是“防呆设计”？应该遵循什么原则？|防错|自动化_网易订阅》

防呆设计的目的是提高工人的组装效率，降低不良率。防止用户出错其实是副产品（是过程不是目的）。这与我对防呆设计的认知是有出入的。

最后，关于『防呆设计』这个名称。

防錯法，日文為 Poka-Yoke，英文為 mistake-proofing，目的是使錯誤發生的機會減至最低程度，進而使任何的錯誤絕不會再發生。台灣管理界大多稱之為防呆法或愚巧法 (fool-proofing)，是舊的稱法，日文為 Baka-Yoke。

防錯法的創始者為鄉新重夫 (Shigeo Shingo)，1909 年出生日本佐賀市 (Saga city)。 1930 年新鄉先生從 Yamanashi Technical College 機械工程系畢業，到當時的日本軍需省 (Ministry of Munitions) 服務官拜陸軍步兵少尉，分派到台灣鐵路管理局台北鐵道工廠（台北機廠）擔任鑄造技手，工作期間學習及推動科學管理系統，以期降低作業成本。1943 年回日本後在橫濱 Amano Manufacturing Plant 擔任製造主管。1945 年退伍，進入日本能率協會 (JMA) 擔任顧問工作，開始豐田生產系統的推動。

1960 年代新鄉先生在日本推動防錯法時稱之為防呆法，Bata-Yoke (Baka-Yoke)，英文為 fool proofing，意思是連愚笨的人也不會做錯事的設計方法，因此中文又稱為愚巧法，後來新鄉先生將之正名為 Poka-Yoke，英文為 Mistake-Proofing，中文為防錯法，表現出新鄉先生尊重人性的性格。

這段故事陳述在新鄉重夫《零品質控制：根源檢驗與防錯系統》 (1986) 一書中：

『防錯其實和防呆的原理差不多，防呆主要是用來保證操作的安全。剛開始，我使用了「防呆」這一稱呼。大概在 1963 年，當時 Arakawa 車體公司使用了一種「防呆」裝置，防止員工因為分不清一個座椅零部件的左右，而將該部件點焊的方向弄反。當一個部門主管告訴員工採用這個防呆裝置的原因時，一位兼職的女性員工哭得驚天動地，她說：「我真的呆成這樣了嗎？」第二天她待在家裡拒絕上班，這位主管便去看望她。向她千方百計地解釋：「這並不是說你笨，我們使用這個裝置是因為人們都會犯無意識的錯誤。」還好，最後終於說服了她。聽完這個故事後，我才意識到「防呆」這個稱呼不是很好，過於貶義。但是取什麼名字好呢？苦思良久，我決定給將防呆裝置更名為防差錯裝置，因為它們的作用是防止出現任何人都有可能無意識犯的錯誤。』

後來新鄉先生在《豐田生產方式探究》一書的英文版中，使用了從日語中音譯過去的 poka-yoke 一詞（在日語裡，yoke 指防止，poka 則指錯誤）。該詞又被法語、瑞典語、義大利語等各個版本所引用，到現在poka-yoke 已為全世界所熟悉。

——《防錯法不是防呆法，原作者新鄉重夫先生早就做了澄清！》

像早前某大厂一直在说的『像小白一样思考』、『把用户当小白/傻瓜』之类的观点，多少有点类似的情况，容易被理解为对用户的不尊重（虽然话糙理不糙）。

果然，二手信息有很大概率是会被作者主观影响的，有可能还是得去看原版。保持独立思考！

更多阅读

关于霍夫斯泰德文化模型

Ghostzhang — 2024-11-11 00:00:00

关于霍夫斯泰德文化模型

由 Ghostzhang 发表于 2024-11-11

在一次内部的交流中，有一位同学提到了『UAI（避免不确定性指数）』，给了我一些启发，会后特意了解了一下：民族文化可以根据吉尔特·霍夫斯泰德的分析来描述。该项目旨在研究一家跨国公司 (IBM) 64 个国家/地区子公司之间的国家文化差异。这些研究共同确定并验证了民族文化差异的四个独立维度，后来又添加了第五个维度。

把内容整理了一个文档，有兴趣的同学可以了解下：【腾讯文档】霍夫斯泰德文化模型

『UAI』是指民众对不确定性的容忍程度，数值越高越不能容忍。从 UAI 指数中可以发现，日本（UAI 92）、德国（UAI 65）都是比中国（UAI 40）要高出许多。回想起之前看过的一些信息，比如在日本，大多数城市的变化很小，基本小时候什么样长大后还是那个样；而在中国，我们常用翻天覆地来形容。但对于设计创新的认知，日本在我心里是名列前茅的，这就引起另一个问题，『创新与UAI是否有冲突？』或者说『对不确定性的低容忍是否会影响创新？』从结果来看，显然是不影响的，所以这里面应该还有一些没被正确解读的内容。（也许这正是数据的局限性，只能反应局部的特征）

UAI 在跨境产品中的应用可能更有参考价值，像 UAI 低的国家地区，在产品功能的说明上应该更明确直观，减少模糊不清的表达，甚至迭代时对界面布局的改变应该更加谨慎。

在腾讯的第九个两年

Ghostzhang — 2024-06-03 14:47:00

在腾讯的第九个两年

由 Ghostzhang 发表于 2024-06-03 更新于 2024-06-14

两年匆匆而过，这两年大环境变化剧烈。后疫时期，一些行业在复苏，一些行业的影响才慢慢突显；俄乌战争、中美博弈；AI 的突飞猛进让打工人对未来又产生了焦虑。《未来简史》中的情景好像真的会发生似的（狗头）。

这两年也不知道是幸或不幸，不幸的是身体上的症状后来确诊是支气管哮喘。幸运的是去了北大医院看过之后，不但哮喘控制住了，连困扰了多年的过敏性鼻炎也缓解了。这两年还参加了 BG 的两场足球联赛，虽然体力一样很差，但病是没再犯了。

照例先聊聊这两年的一些思考。

关于『以人为本的设计』

诺曼在《诺曼门》中提到『以用户为中心的设计』时提出了这样的问题：

为什么要把『人』叫做『用户』呢？

显然诺曼觉得，应该叫『以人为本的设计』，这在他的书中也一直在强调。简单的讲就是——计算机应该是为『人』服务。

个人觉得，『以人为本的设计』这个概念对于大多数的产品来说都太大了。目前我们做的产品无法服务于所有人，通常只能服务于某一部分人群，所以在定义产品目标时，往往需要先定义目标用户人群，即产品的『目标人群』。

我们平时所说的『用户』，更多是指存在共同需求的某类人群。而在《软件方法》中则更极端，将第一需求的涉众称之为『老大』，是具体的某一个人（产品最终要解决谁的问题，或者说谁最需要这个产品），这当然是为了让需求更容易被挖掘，但也让产品功能更局限，所以软件方法中也引入『涉众利益』的概念，来确保产品功能的完备。

可能在诺曼看来，这是一种有局限的设计，只能服务于特定的人群。换一批人可能就不好用了。Apple 的产品之所以受众更广泛，可能与诺曼这种观点有很大的关系。

诺曼发现，现实中大多数的计算机系统是以满足计算机要求来实现的（背后是技术与产品间的博弈），即『人要去服务计算机』，像必须以某种格式提供给计算机文件，必须输入明确的指令等等。除了技术发展的客观原因外，更多是系统设计者对『人与计算机的关系』没有深刻的认知。在这个基础上，也就难以达到理想中的『以人为本的设计』了。

回忆下现实是否如此？很多时候因为用户输入一个错误的指令，系统就会报出一堆的错误信息，有时是一串看不懂的数字、英文、符号的混合，好一些的会告诉你哪里出错了，可以怎么做。但这些都是要让用户自己去处理这个『错误的输入』，因此，当用户遇到问题时，往往需要去各种搜索引擎寻找解决方法（有趣的是，产品的帮助文档并不是第一选择）。更有趣的是，这种方法已经成为主流，不但用户接受了，产品的开发者也觉得理所当然。『又不是不能用』这个观念让大多数产品开发者降低了对品质的追求。

很可惜，这些都是对『设计理论』的漠视。比如根据『首因效應』，你的产品可能只有一次机会吸引到用户。如果只有一次机会，是将一个『完善』的产品还是一个『半成品』交给用户，答案可想而知。但在互联网时代提倡的『快速迭代』的理论下，都赶着快点把『功能』上线，把用户当小白鼠。于是用户大多数时候拿到的就是一个『半成品』。

顺便提一点题外话，『快速迭代』是相对于『传统软件开发流程』来说的，它也有适用的场景，比如适合快速验证『市面上还没有出现的新功能、新产品』，这时用户没有太多的选择，不管功能好坏，都有较高的包容度。反之，当市面上已经有大量同类产品时，还用这种方式，只会在第一次推向用户时，就面临巨大的竟品对比，可以想像得到，通常是难以胜出的，同时还会给用户留下一个不好的印象，以后再要扭转就得花更大的力气。当然也不是就没了机会，只是能成功的例子不多。

『以人为本的设计』是我们应该追求的方向。为所有人而设计，不仅是设计师对『人和物』的思考，也是整个社会人文的一种体现。

交互设计的本质是信息的传递

我喜欢探寻『本质』的内容，会有一种『原来如此』的感觉，但也容易产生『不过如此』的感觉。

交互设计的定义，说明了交互设计的核心，是让人和人造系统能进行互动。

交互设计（Interaction Design，缩写 IXD），是定义、设计人造系统的行为的设计领域，它定义了两个或多个互动的个体之间交流的内容和结构，使之互相配合，共同达成某种目的。交互设计努力去创造和建立的是人与产品及服务之间有意义的关系，以“在充满社会复杂性的物质世界中嵌入信息技术”为中心。——百度百科

先不说人造系统，人与人之间是怎么互动的？通过声音、文字、动作、语言等进行交流。交流什么？信息，是的。我们无时不刻在接收信息和传递信息，直接或间接。人与人之间的信息传递可以分为两种，『面对面』和『非面对面』。『面对面』的效率和信息量是很丰富的，但成本也比较高。大多数时候是无法面对面的，因此需要借用一些媒介。最早的媒介是人，用带口信的方式，再到带写有文字的信件（任何可书写的物件）；之后的媒介是机器（人造系统），像电话机、手机、计算机，可以打电话、视频、发信息、E-mail……传递对象也从单对单，变成了可以同时对多人发送。

互联网产品（工具）本质上可以理解为『设计者与用户之间的信息传递』，用户通过计算机与开发者进行交流，只是交流的形式被开发者定义为一种产品的形态。开发者发现问题，提供解决方案（产品），用户遇到问题，寻找解决方案（产品），然后通过产品与开发者交流如何解决问题。所以用户能不能解决问题的关键在于能不能正确理解产品所提供的信息（前提是产品已经提供了足以解决问题的信息）。

所以，如果计算机系统背后代表的是产品，那计算机系统对用户的傲慢，即是产品设计者对客户的傲慢。而让一个产品走向灭亡的，不是弱小和无知，傲慢才是。

关于 B 端设计（内部系统）

经历了 C 端当道，体验为王的时代，习惯性的只把使用 C 端产品的人当成『用户』，最直接的影响就是总觉得产品的用户都是普通人，会有那些 C 端产品中遇到的普遍性，总会往 C 端产品的指标上去考虑。在最初的时间里，费了好大劲才把观念转过来。

B 端体验之所以较差，也跟那个时代有关，因为『用户』的不同，受重视的程度不同，也就导致了设计资源的多寡。

由于之前很长时间互联网的主要产品都是 C 端为主的，导致大多数人习惯以 C 端产品的特点看待其他产品，如以用户数量多少来衡量项目的重要性。同时 C 端更容易出效果，大体量的产品更多，设计师成就感更强。
B 端业务更复杂，需要设计师对业务更为了解，也就意味着成长周期更长。
更多的设计理论是由 C 端设计师输出的，因此大量的理论应用案例都是以 C 端为背景，对 B 端场景的参考性不高。B 端竟品大多是非个人用户可以使用的，对于设计师来说，竟品分析学习的门槛高。
B 端产品收益周期长，而且进入垂直领域意味着风险和投入都会大增，很少设计师能长期坚持，因此设计资源较少，很多界面都是开发同学自已发挥，普遍出现以『实现模型』实现的界面就不足为奇了。
B 端产品的通常被贴上『专业工具』、『界面复杂』、『学习成本高』等标签，所以交付时往往会辅以相关的培训，用户通常也是需要经过培训，甚至考试来掌握相关的使用流程（也就是硬记）。这也导致遇到交互问题时，很容易依赖培训来解决（解决提出问题的人）。

前面四个问题很容易理解，无非就是岗位前景的问题，在当前各大厂的重点从 C 端开始转移，B 端等更垂直领域的产品不断被重视，会有更多的设计师愿意进入到这个领域。但还是学习成长的周期问题，短期内不会有太大的改善。学校和靠谱的培训机构如果能参与进来，效果可能会更好。但垂直领域的问题，还是需要设计师有决心投入才行。

至于第五点，我有时会想，到底是产品本身真的很复杂？还是因为大多界面是以『实现模型』实现的，导致用户难以掌握，所以才需要培训。培训的内容大多也是第一步点这里、第二步点这里、……这也让产品的每次更新都可能让原先的培训失效，培训成本和记忆成本双高。

产品的傲慢在 B 端系统中很是常见。B 端有一种『能用就好』的普遍认知，功能正常，能出来预期的结果就好了，至于用户在使用过程中的体验，从来不是需要认真考虑的，反正不懂就看使用文档，再不行就问『讲师』。同时因为设计资源少，B 端系统的界面也大多是『开发者审美』，界面美观什么的就全依赖所使用的前端组件库了。

做了几年的研发支撑系统，跟 B 端类似，但细想还是有所不同。用软件方法的说法就是，C 端的用户是执行者，B 端的用户是业务工人，而研发支撑系统的用户则是人脑系统。简单的说就是比 B 端产品更底层的系统。

整体来说，正因为 B 端业务更复杂，所以更应该重视用户的体验，毕竟能自动化的都尽可能自动化了，之所以还需要人参与，说明这部分流程中人的参与很重要，有什么理由不关注人呢？

对 AI 的一些观点

AI 的出现的确对现有的工作岗位会有影响，很多人都在担心自己是否会因此而失业。我的观点是，不要过于担心，最重要的是对 AI 的定位要有正确的认知。其实一直以来，软件行业就一直在做类似的事情。通过开发软件来替代原本需要人参与的工作，从而提升工作的效率，这也在影响着旧有的社会分工。从计算机出现发展到现在，我们也在不断的适应新的社会分工，看着一个个岗位从无到有再到消失（比如『页面重构』），看着一个个行业的兴衰（疫情时期的互联网行业、旅游行业、外送行业等），都有着类似的历程。而变化才会给年青人带来更多的机会，整个社会才会有进步的可能（就如计算机 / 手机是对老一辈人的冲击，也是年青人改变世界的平台）。

焦虑的来源在于『没有准备好』。各种 AI 的报导让人产生一种未来突然间到来的错觉，而『我』还没准备好，不知如何面对这个新世界，由此产生的不安全感。这种焦虑其实是人为制造的，目的无非是造势，利用信息差赚取利益。

就像《设计心理学》中提到的

技术为每个设备提供更多的功能以使生活更简单，但同样的技术也会让设备变得难学难用，使人们的生活更加复杂。这就是技术的悖论和设计师所面临的挑战。

工具有两类：一类是提升人的能力，帮助人更好的生存；另一类是代替人类工作。但工具始终只是工具，工具的好坏其实是由使用工具的人决定的。

现在大多的导向都是急功近利的。技术越发展越便利，反而越没时间给你慢慢研究，比的就是谁的脑子更好使，普通人变成弱势群体的趋势越明显了。虽然一直都这样，但科技的发展加速了这一过程。

在大众眼中，AI 能让普通人也做出专业人员才能做的东西，很兴奋；在专业人员眼中，AI 把自己那么多年的学习和努力全打了水漂，专业优势被消除了；在老板眼中，普通人能做的事，就不用请专业人员啦，一个人能做就不用多请一个啦，而且随着 AI 越来越强，所需要的人越来越少。

但，社会是人组成的，如果大多数人下岗无事可做，那收入从哪来？没钱又如何产生消费？没消费社会又如何正常运转？所以大众关心的并不是技术如何高端，而是技术对自己的生存环境会产生什么影响，以及自己能不能借这个机会过上更好的生活。

技术无对错，但人要有底线。

系列文章

分享近期整理的一些内容

Ghostzhang — 2023-04-11 15:11:00

分享近期整理的一些内容

由 Ghostzhang 发表于 2023-04-11 更新于 2023-04-12

早两年因为眼睛的问题，顺便去了解了下『人因工程』，结合人类眼睛的生物特点，推导了关于界面内容宽度的规范（《页面内容最大宽度推导》）。之后又在知乎上看到了『视觉系统』的文章，从生物学的角度拆解了人类的视觉系统，也蛮有意思的，只是毕竟不太了解这一领域，一知半解，学了点皮毛。

这些研究也解释了心理学的一些现象的产生，正是由于生理上的这些特点所导致。特别是跟视觉相关的现象，像格式塔的设计原则。不过作者大大没有更新了，还没涉及到记忆相关的内容，不过这部分在认知心理学中有比如多的内容，有兴趣的同学可以看看《设计师要懂心理学》、《认知与设计》、《设计心理学》等内容。

学习交互体验也有四年多了，回想这段时间，从一开始对那些设计原则感到有意思，到去了解各种心理学的现象，在各种教程、文章、书中了解到的内容，很是繁杂，单独看都觉得有道理，但当把这些信息放在一起时，就有种无从下手的感觉，条条大路通罗马，但罗马在哪却没人说得清楚。后来想通了，所有文章、书都是作者观点的输出，相关的案例都是先有结论再找案例去做支持，所以每个案例都能解释作者的观点，但当我们要应用到项目中时，硬套理论就会很生硬，毕竟实际场景下是要针对问题找解决方案，而不像文章那种给观点找案例的方式。

原因其实也不难理解，毕竟同一个案例中，往往只会涉及到一小部分作者的理论内容，只讲一个案例是无法把作者观点讲完整的，于是只能拼案例。所以这对于学习者来说，就必须能反向思考，把自己遇到的问题提炼出某些理论的特征，再去代入应用的理论来做验证。

因此，实际场景中，正好是跟学习反过来的，是把多个理论结合应用于一个案例之中。这也就需要我们尽可能了解更多的理论知识，不然应用时必定会出现没有理论支持的场景。

基于这个原因，我也对接触过的大多数理论做了整理，希望能理清思路。

结果比较让人意外，很多理论都是几十年前的经验，至今仍未过时，不得不佩服作者。同时心情也很复杂，国内设计相关的理论发展真是远远不及。

不难看出，后面出现的理论会受之前的理论影响，并进一步完善。这也解释了为什么有时在网上看到的一些内容相似度很高，但又有些许差异，除了作者自身的理解之外，还可能因为理论自身的阶段。像可用性的原则，在我们熟知的尼尔森可用性十原则之前，还出现过好几个版本，内容都很相似。

另外的一个发现就是早期的交互设计相关理论的提出者，都有计算机、心理学或工业设计等领域的背景，所以谁说开发就做不好设计？在各种软件系统开发的书籍中也不难找到需求分析、界面设计的内容，交互设计本就是软件开发中的一环，只不过到了互联网时代，快速迭代的需要做了分工，这部分工作被分了出来，并由与界面更相关的设计师角色来承接。

打造个人的工作流

Ghostzhang — 2022-11-09 19:43:00

打造个人的工作流

由 Ghostzhang 发表于 2022-11-09 更新于 2022-11-10

试了无数的笔记、日历、任务清单工具，始终没有一款是能够完全满足我的需求的，即：

尽可能覆盖整个工作过程
好看、好用
省钱

目前感觉比较顺手的一套组合就是Vision、Agenda、Timeview，再加上系统日历为核心的组合，可以较完美的覆盖到整个工作过程，而且从颜值到价格都比较可人：

颜值：系统日历、Agenda、Timeview、Vision
体验：系统日历、Agenda、Vision、Timeview（只有移动端）
价格：系统日历（免费）、Timeview（免费版够用，Pro ¥40.0）、Vision（当前永久解锁有40%优惠价¥88.0；¥12.0/月；¥43.0/年）、Agenda（订阅 $29.99/年，订阅一次即可永久解锁所有当前的功能）

Vision 是一个个人 OKR 目标管理工具，但真正打动我的是它的任务能与系统日历双向同步的能力，这让我在任务执行这块能很好的在系统日历上进行，而不用切换到任务管理工具里。（只要保留日历事件的URL值，其他属性可以自动被同步到Vision中）

而 Agenda 可以让笔记跟日历事件进行绑定，这样就可以通过日历事件快速定位到对应的笔记。又因为日历事件跟 Vision 的任务同步，所以也可以通过 Vision 中的任务快速定位到笔记，这样就闭环了『目标->任务->执行过程记录->复盘』。

以上，适合像我这种以系统日历事件为主要GTD工具的同学。最后，如果有数据分析需求，可以使用 Timeview ，快速得到相关事件的统计数据。（这里有个小技巧，在建任务时可以定一些『规则』，如『会议』、『项目』等，方便后续的统计。）

顺便推荐下目前为止还留在我必装清单里的工具：

MWeb 很喜欢的 Markdown 写作软件，基本上就是我文章的孵化器
OmniFocus 著名的GTD工具，用高价格让你重视GTD这件事
OmniGraffle 强大的画图工具，不过我基本当成脑图笔记在用
MarginNote 电子书阅读，拆书工具，可导出思维导图
Scapple 思考工具，比起思维导图我更喜欢用这个整理思路。可以看这篇《脑图之困，为什么你的思路打不开？》
MindManager 著名思维导图工具，就是贵
Obsidian 双向链笔记本，越用越觉得强大，主要用来整理知识
Cubox 信息收集工具（输入推荐码 r6yuxe 可领取 7 天会员）

在腾讯的第八个两年

Ghostzhang — 2022-10-20 15:48:00

在腾讯的第八个两年

由 Ghostzhang 发表于 2022-10-20

这世界上有两种东西经不起计算，一是钱，另一个是时间。一转眼，又一个两年过去。回想这两年的时间，没什么特别的印象，在疫情之下，生命的话题从未有过的被重视，以前遥不可及的『死亡』可能转瞬出现，当恐惧变得麻木，总会出现一些更大胆的想法。

这两年身体明显出现了问题，右眼视网膜从之前的病变到去年出现轻微的脱落，现在看东西还是有一层灰色的『滤镜』，当然也因此对眼睛多了解了一些，于是无意间也找到了页面内容为什么要定宽的原因（见《页面内容最大宽度推导》）；然后是慢性鼻炎变成了鼻窦炎，引起了咳嗽，几乎每天凌晨就咳醒，搞得觉都睡不好；更郁闷的是还不能有稍大一点活动量的运动，心率一上来还会咳到喘不过气，一度担心变成哮喘；再然后是鼻窦炎引起了上颌窦粘膜下囊肿，好在是良性的概率比较大……（恶运退散！！！）

可能是这么多事凑一起了，胡思乱想的时间也多了。

设计与开发

学过画的同学会发现，作画时的步骤都是先整体定型再局部刻画再整体调整。初学者往往会出现的问题就是只盯着局部画，可能画得很仔细，但一放到整体上就会觉得并不和谐。长时间在这种思维的框架下，看问题会更关注整体性，关注局部与整体的关系。

写过代码的同学会发现，做一个项目时，往往是先把核心功能做出来，再往上面加更多的功能，不断迭代完善。长期在这种思维框架下，看问题时会直指核心，总试图找出最主要的部分。而且长期因为交付的压力，会更倾向于「复用」、「能用就行」的思考方式，缺乏对非功能需求的关注。

可能会有同学不同意，这也是我想说的，优秀的同学都是即关注整体又关心局部的，加油。

在思考方式上也会有比较明显的差别，实现模型和心理模型的差异是真实存在的。

交流的基础是同频

时常会遇到讨论中看着很积极，实际没有在同个频道的情况。在分析问题时也会遇到，思维发散之后不知道怎么收回，该往哪收。

特别在研发团队中，同个名词的定义可能因为上下文的差异产生不同的定义，比如在学习交互设计的过程中，看到『概念模型』这个词，我最先想到的是业务建模里的概念模型，但进一步看了介绍后，才知道设计心理学里也有这个概念，而且定义是完全不同的。

因此，在讨论问题时，有必须对问题的边界进行明确，以减少因认知不同而产生歧义。分享一个自我觉查的方法：时不时用自己的话把对方的意思复述一遍，让对方确认。当发现对方表达的内容与你的预期有较大出入的时候，特别是一直无法达成共识时，就应该进行边界的确认了。

同样的，问题的不同层次也会引起理解的差异。比如结构层的问题，在表现层就很难从根本上解决。因为人之间的信息差，分歧可以说是客观存在的，不理解才是正常的，所以知音才可贵。

这让我想到『空杯心态』，同样适用于日常的沟通讨论中。

古时候有一个佛学造诣很深的人，去拜访一位德高望重的老禅师。老禅师的徒弟接待他时，他态度傲慢。后来老禅师恭敬地接待了他，并为他沏茶。可在倒水时，明明杯子已经满了，老禅师还不停地倒。他不解地问：“大师，为什么杯子已经满了，还要往里倒？”大师说：“是啊，既然已满了，干嘛还倒呢？”访客恍然大悟。

传说中，这就是空杯心态的起源。

我的理解是，『空杯』并不是要把已存在的东西清空，没有谁能真的做到（还记得《用户使用过后就知道了吗》中提到的『知识的诅咒』吗），而且谁知道要装的新东西就一定是好的呢。『空杯』更重要的是不固执自见，不先入为主，听得进别人的观点，能理解别人的意图，而不是放弃自己的想法。

交流的基础是同频，同频的前提是接纳，接纳的开始是聆听。

交互设计与体验设计

这两年主要是做交互设计、体验设计的学习，主要的项目类型是内部用的研发支撑类产品，包括研发管理、研效工具等。在《在研发团队做交互设计》有更多的内容。

在《页面重构中的语义化》中我说重构做的事像『翻译』，

所谓语义化，就是尽可能的理解要表达的内容，选择适合的标签，将内容转换成浏览器认识的语言，通过浏览器传达给用户。从这个角度来说，我们更像是“翻译”。

经过这段时间的学习思考，我觉得交互设计在做的是『表达』。让产品与用户能在界面上进行交流，表现的是产品的『行为』，体验设计则是在展示产品的『个性』。实际工作中很难把交互和体验分开来看，某种角度来说，产品体现出的是『设计者们』的『个性』，用户是在隔着终端在与设计者们（可能大多数时候是指「老板」）交流。

体验的核心在于『管理用户情绪』

看了不少交互设计、体验设计相关的书籍和文章，我发现有一个共通的点，就是大师都是关心人的，关心人在使用产品中的感受，像《交互设计精髓》、《认知与设计：理解UI设计准则》、《用户体验要素：以用户为中心的产品设计》、《设计心理学》、《设计师要懂心理学》等；这不是废话吗？产品是给人用的，不关心人要关心什么？还有一类是教你怎么做的，像《界面设计模式》、《简约至上：交互设计四策略》、《写给大家看的设计书》、《交互设计精髓》、《Don’t Make Me Think》等。

其中，关于web端的交互体验部分，最主要的功能其实是安抚用户情绪，不管界面的显示、输入还是反馈，都是在减少用户等待（缓解焦虑）、减少犯错（缓解受挫）、提升效率（自我认同），其实都是担心用户在使用产品时产生负面情绪，从而对产品产生不信任，进而弃用。反之，好的使用感受能帮助产品形成正面口碑，提升产品转化。

系列文章

页面内容最大宽度推导

Ghostzhang — 2022-09-30 17:02:00

页面内容最大宽度推导

由 Ghostzhang 发表于 2022-09-30

在制定布局规范的过程中遇到了一个问题，内容区域的最小最大宽要定多少呢？一直以来好像都没有认真想过这个问题，于是翻了下几个主流的设计规范，都没有看到相关的定义，只好用开发者工作大概看了看。

因为我用的是『带鱼屏』，所以又发现一个有意思的现象，屏幕变大了，网站的内容却并没有随之变大

是因为产品的设计者都没有发现这个现象，留着这么多的空间浪费着不用吗？

看这占比，不太可能不知道吧，那么问题来了？

在华为的《人因研究》有这么一张图

于是好像找到了一个突破口了，知道距离和角度，不就能算出屏幕区域大小了吗？

呃～厘米跟像素有什么关系……在这里卡了一段时间……转机在另一个事情上，是关于字体大小的

为什么以前的字体用12px可以，现在字体得用14px了呢？

通过字体大小对照表，找到了像素与英寸的对应关系，这里涉及到另外两个概念，DPI和PPI。

因为DPI是用于打印的，这里我们先不管。在屏幕上，像素其实也分两种类型

这也就导致了虽然大分辨率下使用了12px的逻辑像素在物理尺寸上还是要比小分辨率下的12px显得更小一些。

通过屏幕的计算，就可以得到PPI，然后就再通过厘米和英寸的关系，就得到了最终的像素啦

接下来就是体力活了，一通计算后得到这些，为方便记忆，取得中间值 650px，需要注意的是，这里计算的是单眼的视角。

简单验证了下，看起来是可行的。

但是

参考前面大多数站点的宽度值，取双眼舒适的视角，即2倍650的1300像素。

至此，完成了页面内容区域最大宽度的推导。

其他的一些问题，如限制了宽度，那应如何对齐？及空间是否被浪费？等问题，请见附件PPT。

《页面内容最大宽度推导》 from GhostZhang

记GIF动画转CSS逐帧动画工具

Ghostzhang — 2022-08-16 19:27:00

记GIF动画转CSS逐帧动画工具

由 Ghostzhang 发表于 2022-08-16

翻到了 2018 年左右团队支持的一个项目，当时看重构同学不断的在和设计师来回沟通调动画细节，就在想能不能提升下这里的效率，于是了解了下当时的实现过程，大概是这样的：

设计师用 PS 或其他工具输出 gif 动画图或视频给到前端开发，前端开发再对照着用 CSS 动画实现。开发会用用工具（如 PS）把 gif 图中每一帧的时间取出来，由于显示精度的问题，往往取到的时间会比较粗（秒），这就导致最终效果与设计师给出的还是会有差异，就感觉不对，因此还需要再进一步调整代码，于是就出现了需要反复沟通的现象。

CSS 动画，简单的说就是用 CSS3 的animation属性，设置@keyframes关键帧来实现的帧动画。（示例可以看这里 https://www.jianshu.com/p/05c5a9b302d2 ）看完应该大概有了个概念。

现在进入主题，平时我们对帧动画的印象，大多是同一时间间隔的，像上面示例中的例子：

@keyframes run {
  0% {
    background-position: 0 0
  }
  10%{
    background-position: -100% 0
  }
  20%{
    background-position: -200% 0
  }
  30%{
    background-position: -300% 0
  }
  40%{
    background-position: -400% 0
  }
  50%{
    background-position: 0 -100%
  }
  60%{
    background-position: -100% -100%
  }
  70%{
    background-position: -200% -100%
  }
  80%{
    background-position: -300% -100%
  }
  90%{
    background-position: -400% -100%
  }
  100%{
    background-position: 0 0
  }
}

会发现每一帧的间隔都是一样的，大部分情况下效果也还不错。但如果遇到需要设置不同间隔的情况呢？

像周末摇摇乐这样的项目，界面上的动画是每一次活动运营的重点，对动画质量的要求会高很多，特别是在节假日时，会有专门的动画效果，为了让动画看起来更加的流畅，往往需要控制到每一帧的时长，这也让开发的实现难度有了增加。

那如何提高这个过程的效率呢？设想下，如果能读取 GIF 中每一帧的时间，是不是就能计算出来总的时长和每一帧所占的时间比。如果再自动给出相应的代码，嘿嘿……

GIF 图片解析

首先来找找 GIF 图中时间是在哪表示的，关于 GIF 图，在这里（What’s In A GIF）有很详细的说明

用支持十六进制的编辑器打开一张 GIF 图，就可以看到这样的一串数据。为方便分析，我用了一张 10*10 的小图，如下：

文件头

GIF 有两个版本，分别是 87a 和 89a，区别如下：

GIF87a：是在 1987 年年制定的版本。
GIF89a：是在 1989 年年制定的版本。在这个版本中，为图像互换格式⽂文档扩充了了图形控制区块、备注、说明、应⽤用程序接⼝口等四个区块，并提供了了对透明⾊色和多帧动画的⽀支持。

	GIF87a	GIF89a
LZW 压缩	Y	Y
支持隔行扫描	Y	Y
支持透明度	N	Y
支持动画	N	Y
无限循环	N	Y

逻辑屏幕描述

全局调色板

图形控制扩展

可以看到图形控制扩展块的第五位、第六位字节表示就是当前帧的延时时间。注意这里是十六进制数，需要转成十进制才是我们需要的时间。

图像描述

图像数据

文件尾

工具化

知道了格式后，工具的思路就很简单了，查找到各图片帧的延时时间，通过数量就知道有多少帧，再计算各帧的时间与总时间的比例，转换成百分比，输出 CSS 就可以了。

实现出来的界面大概是这样

由于只是个临时工具，加上问题好像也很冷门，就没有对外开放了（差点源码都找不到了 😅 ）。

更进一步的想法，就是读取 GIF 的每一帧图片，自动生成雪碧图¹和 CSS 动画关键帧代码。不过这个功能用 air 不好实现，而且现有的前端工作流其实也支持类似的功能，像自动生成雪碧图等。搜了下，有个叫 ImageMagick 的图像处理库能很好解决这个问题，用法可以看这个《「CSS3」ImageMagick - 从 gif 建立雪碧图动画 - Sprite Sheet Animation》。至此，动画实现的效率有了明显提升，只希望项目能坚持得更长时间。

我的博客即将同步至腾讯云开发者社区，邀请大家一同入驻

雪碧图是根据 CSS sprite 音译过来的，就是将很多很多的小图标放在一张图片上，就称之为雪碧图。 ↩

用户使用过后就知道了吗

Ghostzhang — 2022-06-21 17:26:00

用户使用过后就知道了吗

由 Ghostzhang 发表于 2022-06-21 更新于 2022-06-22

先说结论：

帮助文档有必要，但现有的形式可以优化
关注中间用户没错，但体验受第一次使用时影响
所有人在第一次使用某一功能时，都是新手
功能越符合用户的概念模型，新手用户越快转变成中间用户
一致性有利于概念模型的建立

在《由文本链接引发的思考》最后提到了一个理由——『又不是不能用』，这是一个很无赖的理由，会让所有追求更优秀的想法受到打击，类似的理由还有『用户用过一次之后就知道了』。

不只一次听到这个『理由』，有道理，但不对。做为『用户』本身，你自己是如何看待『帮助文档』和『新手指引』的？大多数时候是不是能点『跳过』就不会想要看完？遇到问题宁可去『百度』也不看帮助文档。

用户教育是必要的，这有助于用户建立对应的概念模型。但也是性价比较低的方案，最好的体验是自然而然，而往往需要学习的操作都是不那么自然的。并不是所有的功能都能做到自然而然，特别是专业性比较强的产品，没有一定的专业知识无法正常使用。但大多数功能的学习成本可以尽可能降低，比如 PhotoShop，不同专业程度的人有不同的用法，但都不妨碍它成为大家喜爱的修图软件。

以『又不是不能用』、『用户用过一次之后就知道了』为理由的方案往往是做了妥协的方案，设计者明知这样不太好，却找不出更好的方案或因其他种种原因，只能这样说服自己。

大多数体验问题都发生在用户第一次接触时。

比如苹果的产品，为什么会让人感到体验很好、很易用，是因为用户都很熟悉电子产品吗？显然不是。那是因为什么呢？因为第一次使用时，用户按自己经验进行操作的（雅各布定律¹），当与已形成的『概念模型²』有冲突时，经验失效导致的中断，会触发系统 2 进入经验的纠偏，如果进一步尝试仍无法达到预期。这时通常会产生两种想法，一种是『哪做错了？』，另一种是『出 bug 了？』，不管哪一种，都是『差』的体验感。当用户第一次接触时就能自然而然的，不用过多的学习就能正确完成操作，无阻碍、顺畅的使用感受，是良好体验的开始，而这在大多数的产品中是不容易看到的。《Don’t Make Me Think》中的所说的第一性原则：『别让我思考』

它意味着，设计者应该尽量做到，当我看一个页面时，它应该是不言而喻、一目了然、自我解释的。

我应该能明白它——它是什么，怎样使用它——而不需要花费精力进行思考。

可能也是知识的诅咒(Curse of Knowledge)³，设计师出方案时需要了解产品功能，但一旦了解了功能，就难以回到最初的状态，无法想像对此功能一无所知的用户会如何使用这个功能。因此，我通常在进一步了解要做的需求之前，会先体验一下相关的功能，然后记下最开始的这种感觉，用于后继评估方案时做为一个参照。不过也只能是尽可能的还原，并无法真的回到那个状态。

这种状态对于辅导过作业的家长来说，应该比较容易理解。你觉得理所当然的事情，对小朋友来说可能无比困难，那种无助和自我怀疑，在我们面对一个新事物时，还是会出现的，没人喜欢那种感觉。

在《软件观念革命：交互设计精髓》中，有关于新手用户、专家用户和中间用户的描述：

处于中间状态的大多数用户都很愿意进一步学习，但通常没有时间。偶尔，也会出现一些机会。有时候，那些中间用户为了完成一个大的项目，持续几个星期大量使用产品。在这段时间内，他们学到一些新的东西，知识也增长了。

然而，有时候，他们又会几个月都不使用该软件，忘掉了大量重要内容。当他们重新使用软件时，他们不是新手，但需要一些提示，回到以前的状态。如果一个用户发现自己几个小时之后仍然不能取得进步，超越新手阶段，他们会完全放弃，然后换另外一个。没有人愿意时间长了还对某个任务不称职。

虽然每个人都会在一段时间内以新手的形式存在，但没有人会长期停留在这个状态。

人们不喜欢显得不称职。而就定义来说，新手意味着不称职。相反，学习和提高是令人高兴的，所以新于努力尽快成为中间用户——或者，他们干脆放弃。例如，所有滑雪的人，都会在新于层次停留一段时间，但那些不能很快取得进步，也就是摔跤过多的人会很快放弃这种运动。剩下的人则会从初学者变为普通的运动者。只有少数人会成为滑双黑钻雪道的高手。

对于程序员来说，他们完全有资格成为所编软件的专家，因为他们必须考虑每一种可能的使用情况，无论这些情况多么模糊和不可能，他们都需要创建程序代码来处理。

他们自然的倾向是设计实现模型方式的软件，并且在交互中对每一种可能的情况都给予问等重视，因为作为专家他们不存在理解的问题。

与此同时，销售人员、市场入员和管理人员一他们没有一个可能是专家用户，甚至是中间用户一一由于经常要向对软件不熟悉的倾客、记者、合作伙伴及投资商演示产品。因为经常和新手打交道，这些以业人员通常对用户群有一种强烈的偏见。因此，销售和市场人员经常劝说让界面为新手服务就不足为奇。他们要求培训与产品捆绑在一起以帮助苦苦奋斗的新手用户。

程序员只创造适合专家的界面，而市场人员要求只适合新手的交互，但正如我们已经看到的”数目最多、最稳定和最重要的用户群是中间用户。

想到大多数实际用户通常被忽略是令人吃惊的，但情况经常就是这样。你可以在很多企业和基于软件的商业产品中看到这种情况。整体设计偏向于专家用户，而与此同时，一些令人厌烦的工具，如向导（wizard）和 Clippy 捆绑在一起来满足市场部门对新用户的理解。专家级用户很少使用它们，而新手则希望尽快摆脱这些令人不安的有关他们无知的提示。但是，永久的中问用户，则需要永久地面对它们。

《软件观念革命：交互设计精髓》是 2005 年的书了，作者的观点依然对现在有很高的启发价值。技术日新月异，但存在的问题依旧。

回到标题的问题，『用户使用过后就知道了吗』，对于有良好体验的产品来说，在第一次接触的时候就知道如何使用了；而对于大多数产品来说，使用过后却未必就能知道，有效帮助用户建立相应的概念模型，是重要的事情，而且这个过程还要考虑人的情绪因素，如不要让用户觉得自己无知（帮助文档就常做到这点）、无能（老是犯错）、无助（不知接下来要做什么）。

降低用户学习成本要求尽可能依据用户既有经验进行任务和流程设计。雅各布定律认为，用户将大部分时间花在别人家的网站(产品) 上，而不是你的。 ↩
『人们会对自己、他人、周围环境以及与他们互动的物品形成某种心理模式；这些心理模式，就是在人们的心目中，所理解的事物如何运作的概念模型。』——《设计心理学》 ↩
知识的诅咒(Curse of Knowledge)：一旦知道某个东西，就很难想像不知道它会是什么样子。1990 年，斯坦福大学研究生 Elizabeth Newton 做了一个著名的心理学实验：让敲击者在桌子上敲击最常见的歌曲,听众根据听到的节奏回答是什么歌曲,然后让敲击者估计听众答对了多少。120 次的实验中，敲击者预测听众猜对的比率会大于 50%，真实的结果是听众猜对的比率只有 2.5%。因为听众听的是敲出来的声音，敲击者听的是大脑里已有的歌曲。 ↩

关于状态可见原则

Ghostzhang — 2022-05-09 16:12:00

关于状态可见原则

由 Ghostzhang 发表于 2022-05-09

『状态可见原则』是尼尔森交互设计原则之一，大体的意思是

系统应该在合理的时间内通过适当的反馈，始终让用户了解正在发生的事情。

由于定义里提到了『反馈』，以至大多数的时候我们都是围绕着反馈在做方案，如用户点击之后消息要如何提示、网络状态变化时要如何提示用户、任务进度变化时怎么提示等等。但状态并不只有操作后才出现，操作前也有状态，如制作一个组件时，通常会把组件的不同状态（正常、鼠标经过、鼠标点击、加载中、报错、禁用等）做出来，其中正常态和禁用态就是操作前的状态，其它都是操作后的反馈。

读过《简约至上》的同学都知道，书里介绍了简化设计的四个策略：删除、分层、隐藏和转移。其中『隐藏』策略提到了一点：提示与线索。主要是意思就是在某些场景下，被隐藏的功能可以提供一些提示信息，在不干扰用户的情况下留下便于探索的线索。如 PhotoShop 工具栏里的工具图标右下角的小三角。

受此启发，在 web 的设计上是否也会有类似的场景呢？

第一个想到的属于操作前提示类型的组件就是树组件。

我们对列表前面的三角箭头所表达的意思已经很熟悉了，通常代表着可以展开下一级内容

同时也意味着存在下一级内容（并非都有这一层意思，如文件夹就没有，仅能表达类型）

可见，列表前的三角箭头有表示『有下一层级信息』的意思，同时箭头的方向表示『层级是否展开』的状态。因此如果功能上没有按这个规则去实现，就会对用户造成困扰。

类似的组件还有折叠面板、折叠菜单。

应用

下拉菜单

由下拉菜单的激活方式引起的一个思考点，我们常见的下拉菜单有两种激的方式，hover 激活

和 click 激活。

但从外观上是无法进行区分的，也就是没有操作前的暗示。由此带来的问题是用户在操作前无法确定要以什么方式激活菜单，只能先试着尝试某一种。如果系统中同时存在不同激活方式的下拉菜单，这种尝试就更加让人烦恼了。

应对的方案除了整个系统统一之外，有没有其他的方案呢？从操作前暗示的角度入手，能不能通过三角箭头的不同样式来区分呢？

至于为什么实心是 click、线型是 hover，主要是在视觉上实心比线型要更有「重量」一些，而 click 在操作上比 hover 更耗费「能量」。

侧边导航

除了下拉菜单，在左侧导航菜单上也发现同样的问题，当导航菜单收起之后，『是否存在二级菜单』这个信息就丢失了。

尝试着改进后的左侧导航折叠态

链接

虽然文本链接有几种表达自身状态的样式（link、visited、hover、active），但由于实际场景中点击链接时可能会有几个结果：

打开方式\跳转目标	当前站点	外部站点
当前窗口	当前窗口打开当前站点的页面	当前窗口打开外部站点的页面
新窗口	新窗口打开当前站点的页面	新窗口打开外部站点的页面

就导致了用户在操作之前，会不能确定目标内容会以何种方式呈现，也就是『结果不可预期』。

当前常见的方案是在链接文本的后面加上一个表示跳转到外部的图标，用于提醒用户链接目标是站外内容，如果点击将会离开本站点。这时用户可以主动选择是否使用新窗口打开。

不过这个只是区分了站点内外，对于是否新窗口打开的问题并没有解决。关于这个问题，我记得早些年讨论 HTML 语义化时也讨论过，当时没有明确的结论，大体的共识是不建议使用新窗口打开，原因主要是：

留给用户自主控制。默认当前窗口打开时，用户可以通过鼠标右键菜单决定链接的打开方式，也可以通过浏览器的快捷键（如Chrome 键盘快捷键）进行控制；而如果默认为新窗口打开，则无法支持切换为在当前窗口打开链接。
大多数的站点都是默认当前窗口打开的，更符合用户的使用习惯。

同样试着解决下

打开方式\跳转目标	当前站点	外部站点
当前窗口	默认
新窗口

可以发现对于新窗口的场景，只使用同一个图标，理由是对于当前页面的影响不大，不管是不是站点的内容，用户都可以很方便的返回（关掉新窗口）。不过，还是不推荐将链接设置为新窗口打开的方式，将选择权留给用户。对于不得不使用新窗口打开时，可以明确告知用户，减少不必要的尝试。

扩展出去，对于下载文件的链接，也可以通过图标标示出文件类型

以上，抛砖引玉。

对『适老化与无障碍』的一点思考

Ghostzhang — 2022-01-13 21:33:00

对『适老化与无障碍』的一点思考

由 Ghostzhang 发表于 2022-01-13

随着工信部相关的发文¹，适老化与无障碍在国内互联网企业引起了高度的关注。做为一个互联网从业者，个人觉得这是中国互联网一个里程碑事件。标示着中国互联网企业将更进一步关注有需求但无法与正常人同样享受互联网便利的人群。

无障碍长期被看作是公益相关的事情，因为从商业角度来看，可取得的价值远小于投入。可能也因为国内当前所处的阶段所致，在追求经验增长的过程中，对人的关注必然有所减少。而国家这次大力推动『适老化与无障碍』，大体是因以下几个关键事件，主要来自于这两个报告²。

首先是『人口普查』³，其次是『十四五规划』⁴，再是『新冠疫情』⁵。这三个事件一步步影响着这一决策。这几大事件分别对应着：人口普查，三胎政策；十四五规划，延长退休时间；新冠疫情，改变生活方式。

这一次的人口普查的一个数据显示，人口的增长率在下降，这意味着青少年的人口数量在下降，未来青壮年劳动力将会减少。

（一）人口总量。全国人口[注]共 141178 万人，与 2010 年（第六次全国人口普查数据，下同）的 133972 万人相比，增加 7206 万人，增长 5.38%，年平均增长率为 0.53%，比 2000 年到 2010 年的年平均增长率 0.57%下降 0.04 个百分点。数据表明，我国人口 10 年来继续保持低速增长态势。

（五）年龄构成。0—14 岁人口为 25338 万人，占 17.95%；15—59 岁人口为 89438 万人，占 63.35%；60 岁及以上人口为 26402 万人，占 18.70%（其中，65 岁及以上人口为 19064 万人，占 13.50%）。与 2010 年相比，0—14 岁、15—59 岁、60 岁及以上人口的比重分别上升 1.35 个百分点、下降 6.79 个百分点、上升 5.44 个百分点。我国少儿人口比重回升，生育政策调整取得了积极成效。同时，人口老龄化程度进一步加深，未来一段时期将持续面临人口长期均衡发展的压力。

另一数据则反应了老龄化的进度在加快，同时意味着至少在这一批 15 岁以下人口成长起来之前，当前青壮劳动力依然是主力，即便他们将进入老龄阶段。于是就得面对两个事实：

当前青壮劳动力不会在短时间内有所增长
他们进入老龄后依然得工作

国家也给出了对策，就是加不了人那就加班（延长退休时间）；年龄大干不动，那就提供更简单有效的工具（工具适老化）。

因此，适老化并不是只是为了让现在的老龄人能跟上时代，更重要的是让现在的青壮年能工作的得久，是为了我们而做的！（心疼一秒，生活还得继续）

真相有点残酷，说说机会点吧。

首先，所有跟老龄化相关的行业都可以提前部署或准备着，毕竟从政策到执行还有个时间差，当前只是头部几个大的产品被要求，但以后是肯定要变成基本要求的，就是政策不强制，市场也会让更多的公司和产品关注到这一领域，毕竟老龄人的规模是在不断增长的，可能当前的老龄人不怎么会消费，但前面也说了，这些是为我们自己准备的。所以为中小公司提供适老化方案会是一个机会点。

其次在生产工具方面，针对老龄人常见的身体机能退化而定制的工具，也会是一大机会。

再就是与老龄人相关的民生，涉及生活（衣、食、住、行）、安全、养老、社交等领域，都可能因为老龄人口规模的增长而产生更多的机会。

以上，前段时间所见所思，简单记录下。

在研发团队做交互设计

Ghostzhang — 2021-04-14 12:02:00

在研发团队做交互设计

由 Ghostzhang 发表于 2021-04-14

2018年开始，由于工作内容的调整，我开始接触交互设计的工作，算是半路出家。由于是在研发团队里，整体的氛围跟在设计团队里还是有蛮大的差异的，比如小姐姐很少，气氛没那么活跃等等；再者就是项目类型的差异，内部研发支撑工具，即不是toC，也不是toB。因为项目服务对象的特殊性，更像是一种定制类的产品，对于设计师来说，很有挑战。因其用户的特殊性，当下能找到的toC/toB产品的经验都不大能直接使用；并且在最开始的一段时间里，学习的压力很大，要学习了解一些研发类的知识，要能看懂用例图、序列图、状态图、类图等UML图…准确理解各种专业名词、概念模型，学习软件方法等等理论知识，而这些对于设计师来说，可能是平时根本不会去关注的内容。

关于『交互设计』的定义

在招交互设计师的时候我常会问一个问题，『你怎么理解交互设计这个工作的？』，很多同学都会讲交互设计在做什么，怎么做得更好……最近因为某些原因，重新思考了这个问题。

什么是产品？

产品（Product），是用来满足人们需求和欲望的物体或无形的载体。消费者购买的不只是产品的实体，还包括产品的核心利益（即向消费者提供的基本效用和利益）。产品的实体称为一般产品，即产品的基本形式，只有依附于产品实体，产品的核心利益才能实现。期望产品是消费者采购产品时期望的一系列属性和条件。

从一个想法出现后到变成一个产品，这个过程是一个设计的过程。那么会有这么几个问题：

为什么会有这个产品？
用户为什么要选用这个产品？

产品有好有坏，如果都是解决用户问题的，那应该都是好产品才对；既然都解决同一个问题，用户为什么要选这个产品而不选那个产品？

在认真了解『交互设计』这个定义之前，我也像大多数同学那样觉得『交互设计』就是指人与机器的互动设计，通过界面的操作，帮助用户更好的完成任务。简单讲就是让用户觉得好用。随着理解的加深，发现交互设计更深层的定义是，通过设计用户使用机器界面的行为来满足用户目标，从而实现产品目标。

交互设计是对产品在吸引用户使用、提升产品粘性的设计，是为产品目标服务的。

而所有的设计都是基于『信息的有效传达』这个基础上的，用户看不懂，做再多都是徒劳。所以对于一个界面来说，易读易理解是最基础的要求。

信息的呈现方式是交互设计的核心

对于工具类的产品，信息量大是常态，甚至用户为了有『掌控全局』的感觉，希望界面上信息尽可能多。因此分析用户核心需求，把信息的优先级、层次划分出来，对于界面的易读易理解是十分关键的。有些信息可能会在不同的界面中出现，但由于不同页面的核心诉求不同，信息的组织方式也会有所不同，比如只显示汇总后的信息还是显示详情，显示变化趋势还是显示变化过程。

在开发主导的项目中，大多数开发的同学都只是考虑有多少功能点，界面上要显示多少设置项，但不太关心这些设置项之间的关系，别人看到这些设置项时会有什么反应。并且总以『大家都是开发，一看就明白了』作为理由，但事实上除了项目成员，其他人就是看不明白。之前流传过一个笑话，说开发人员最讨厌的两件事情是，别的开发不写文档，以及自己要写文档。虽然是个笑话，却反映了开发者和用户之间的差异，都是同一个人，但角色的转换还是会产生不同的需求。

关于需求

内部项目由于没有上游的产品经理梳理需求，所以也没有需求文档等资料，想做出东西，就得从头开始了解项目的目标、需求，整理相关的内容。而从需求方（开发）得到的信息，大多已经是如何实现的方案，由于思考方式的差异，开发同学更多会想实现的可行性，一谈到需求，总会不自觉的就跟你讨论如何实现，这样实现的限制是什么等，话题总会跑偏，有时争了半天，仅仅是因为他在考虑实现上的问题。就是设计师是从用户需求出发来讨论方案合理性，开发是从技术实现出发来讨论方案可行性，结果就是虽然都是讨论同一个方案，但角度不同，引起争论的点就很奇怪。

这里有趣的现象是，很多时候接到的所谓『需求』，其实并非『需求』，而是一个『方案』。比如『在……加个……功能』、『把……改成……』，这种句式提的都是如何实现的方案，而为什么要这样做的原因可能才是『需求』。如果不深挖下就动手做，可能怎么都满足不了需求，毕竟如果开发知道要怎么做更好，就不需要交互设计了。

所以到底什么是需求？

因需要而产生的要求。 ——现代汉语词典

『需要』是什么？

对事物的欲望、要求。 ——现代汉语词典

『欲望』呢？

欲望（Desire）是由人的本性产生的想达到某种目的的要求，欲望无善恶之分，关键在于如何控制。欲望是世界上所有动物最原始的、最基本的一种本能。从人的角度讲是心理到身体的一种渴望、满足，它是一切动物存在必不可少的需求。一切动物最基本的欲望就是生存与存在。 ——百度百科

好了，为了最基本的生存，我们需要吃，于是就需要交易，于是需要钱，于是需要工作，于是需要完成工作，于是需要想怎么更好的完成工作……这里面起作用的并不只是一个欲望，而是好几个欲望，生存、安全、归属、尊重、自我实现等共同作用，只是不同的人生阶段、不同的生命状态下占比不同而已。

跟开发一个系统一样，再小的系统都需要增删改查的功能，当然也可以只做查，但其他三个功能并没有因此而不需要，只不过变成了人工处理的方式。大部分情况下我们只看到系统的一部分，比如查看文档时我们只希望这个软件能打开这个文档，但打开之后又会变成希望这个软件能编辑，编辑时又会想要能插入图片、脑图、视频、音频什么的，编辑完又会想要能保存，保存时又想支持别的格式……需求总是一点点被激活，而不是被完整提出。

交互设计是在做界面的帧动画

因为需求是不断变化的，受当下的场景影响，用户因为操作引起的外部变化会反过来刺激用户，从而让用户产生相应的行为变化，这个过程很快，在你反应过来前就已经完成了，在《关于一致性原则》中有相关的内容，系统1主导着这一部分。我试着把这个过程分解了下，以保存文档这个操作为例。

抽象出来就是

『经验』就类似便签纸，随时都在往里记着东西，也往里寻找内容，而『经验』也是系统1工作的基础，只有当经验遇到问题时，系统2才会被激活来解决问题，解决完又会形成新的『经验』以备下一次使用，不过这并不是永久的，记忆有时效性。

如果把用户每个时间切片所接触到的界面，看成是一个个静态的界面，所有时间切片连起来形成一个交互行为，就像帧动画一样。因此，做设计的时候可以把动态的界面变成多个静态的界面，来表达完整的交互行为。像这样：

在将界面看成不同时间切片下的静态界面之后，对界面的观察角度发生了一些变化，比如我会在某一个时间切片下推导用户当下的状态，从而判断当前界面的内容是否合理，对于一些细小的思考过程也能比较容易发现。很多时候操作是连续的，但有些时候会中断，不管是什么原因引起的中断，都应该能帮助用户更快回忆起之前的任务，从而继续完成后继的操作。

好的体验是『流畅』的，也就是说，虽然设计过程中把界面切开了，但最终目标是要减少在各个界面时间切片下的停留时长，特别是任务流中的界面。

体验的整体性

做为交互设计师，推演的能力就显得比较重要了，毕竟在把东西做出来之前，大部分都是在大脑中进行的。把自己当成用户，代入流程中，一步步推演出用户的需求，再想办法满足用户的需求。

体验或者说感受是个整体的过程，从第一个想法开始，到完成任务离开，整个过程中的所有可见可操作的元素都对这一过程产生作用。就如我们去一家餐厅吃饭，影响我们对这家餐厅评价的除了菜品好坏之外，还有环境、服务员的态度，点菜、上菜的流程等等，甚至与同时用餐的其他客户之间的互动……

虽然说设计阶段要尽可能完整，但实际开发过程中所说的迭代是以功能可用为划分的，这也就导致有些内容不是简单的把界面上的入口隐藏或修改就可以实现，可能会需要对流程进行一定的修改。也就是可能会有分支情况，这就留下了一个坑，当后继没有跟进把这个临时方案改回去时，就可能发展成跟原本的设计越来越大的差异。所以应该在设计的过程中就把迭代的划分考虑进去，以迭代功能的完整性来设计，尽可能让迭代中的交互流程是完整可用的。

关于组件库

开发的同学总有一种错觉，如果有足够多的组件，就可以自己搞定所有的界面。在确定了组件库后，就可以自由发挥，通过拼组件来实现一个个的系统。

然而问题随之而来，不同的人用同样的组件并无法拼出体验一致的页面。身边大量这类例子，使用同一个组件库，但做出来的界面各式各样，看起来是同个风格，体验则完全不同。这不是最初想要的结果。

我们其实是希望通过组件化的方式，最终不管是谁来做，都能输出一致的结果。就像是给你一堆乐高，再给一份『说明书』，通过这份说明书，不管男女老少都可以拼出一样的结果来。当然这里得有一个前提，就是『组件』已经有了，在这个前提之下，就可以讨论另外的重要问题，『说明书』谁来给？『说明书』怎么得来？

回想按岗位分工的工作流程里，开发阶段拿到的交互稿、设计稿都属于『说明书』，开发的同学按着『说明书』，把相关的组件拼起来，得到最终的页面。这里的『说明书』有两份，一份说明页面信息的组织方式及页面与用户如何进行互动（交互稿）；另一份说明页面的表现形式（视觉稿）。如果再往后延展，还有架构设计方案、接口说明等等文档。

在有了『说明书』之后，理论上来说，只要有相关的开发资源，就能做出一模一样的功能。当然这些都是理想化的，现实中需求不断更替，『说明书』也需要不断更新，但相对同一迭代版本来说，有和无的差别还是很明显的。

关于一致性原则的反向应用

Ghostzhang — 2021-03-23 16:08:00

关于一致性原则的反向应用

由 Ghostzhang 发表于 2021-03-23 更新于 2021-12-06

在《关于一致性原则》中讲了一致性原则的重要性，能大大提升用户操作的效率。但原则本身没有好坏之分，用对了场景才是好的原则。什么意思呢？盲目遵守一致性原则，也可能带来负面的影响。比如常见的场景是在一些不可逆操作如删除操作时，如果保持操作的一致性，将会增加误操作的机率。

在《关于一致性原则》的最后有提到『有些原则本身是有冲突的』，比如『一致性原则』和『防错原则』，要防止用户出现错误的操作，就不能让用户操作的太快，需要在重要决策之前让用户停下来确认，而这个停下来的时机，往往是通过打破『一致性原则』来实现的，比如改变按钮的位置，或者改变按钮的默认焦点等，像 MacOS 的删除确认默认焦点在『取消』上，如果你习惯性的按回车键，将会取消删除操作。虽然可能在意图上会有用户确实很清楚自己要进行删除，但从系统的角度来看，删除操作导致的结果是文件可能找不回来，如果用户因为习惯动作导致误操作，所带来的负面情绪可能比操作被打断的影响要大得多，两害相权取其轻。

关于一致性原则

Ghostzhang — 2021-02-07 18:32:00

关于一致性原则

由 Ghostzhang 发表于 2021-02-07

『一致性原则』是交互的基础原则之一，为什么一致性很重要呢？因为同样的一个操作，应该是可预期得到同样的一个结果的，当同样的一个操作得到了不一样的结果，会让用户产生挫败感，一开始会觉得是自己操作错了，但再次尝试之后发现不是自己的问题时（用户不一定知道自己的操作有错误），对整个产品的感受就会变得很糟。想想如果把保存的快捷键cont+s(windows) 、⌘+s(mac)换成其他功能试试……

写这篇文章的目的并不是想说如何做到一致性，而是因为读了《思考快与慢》后有一些思考，想从更底层的原因找到支撑这个原则的理由。

系统1和系统2

由心理学家基思·斯坦诺维奇(Keith Stanovich)和理查德·韦斯特(Richard West)率先提出的术语，用以说明大脑中的两套系统，即系统1和系统2.

系统1的运行是无意识且快速的，不怎么费脑力，没有感觉，完全处于自主控制状态。

系统2将注意力转移到需要费脑力的大脑活动上来，例如复杂的运算。系统2的运行通常与行为、选择和专注等主观体验相关联。

以上是书中对大脑思维方式的定义，并用大量的案例来说明系统1和系统2之间的相互作用及对行为的影响。

注意力、冲突及自我控制

系统1和系统2这两个系统都对注意力有控制作用。

系统2的运作是高度多样化的，但所有这些运作方式都有一个共同特征: 所有运作都需要集中注意力，如若注意力分散，运作也会随之中断。

系统2具有某些改变系统1运作方式的能力，通过控制注意力和记忆力的一般自主运行功能的方法可以实现这些改变。

系统1不断为系统2提供印象、直觉、意向和感觉等信息。如果系统2接收了这些信息，则会将印象、直觉等转变为信念，将冲动转化为自主行为。通常情况下，一切都会顺利进行，系统2会稍微调整或是毫无保留地接受系统1的建议。

系统1和系统2的分工是非常高效的：代价最小，效果最好。通常情况下，这种分工很有效，因为系统1很善于完成自己的本职工作：它在熟悉情境中采取的模式是精确的，所作出的短期预测是准确的，遇到挑战时做出的第一反应也是迅速且基本恰当的。然而，系统1存在成见，在很多特定的情况下，这一系统易犯系统性错误。你会发现这个系统有时候会将原本较难的问题作简单化处理，对于逻辑学和统计学问题，它几乎一无所知。系统1还有一个更大的局限，即我们无法关闭它。

系统1是自主运行的，我们无法随意使其停止，因此直观思维所导致的错误常常难以避免。我们不可能一直没有成见，因为系统2可能对系统1产生的错误毫无所知。即使对可能发生的错误有所察觉，也需要系统2进行强有力的调控和积极的运作才有可能避免。然而，作为一种生活方式，时刻保持警觉性并不是一件好事，想要这样做也并不实际。总是质疑自己的想法会使我们的生活非常枯燥乏味，因为系统2在代替系统1进行日常抉择时总是耗时很长且非常低效。最好的解决办法就是妥协：学会区别常会出现重大错误的情境，在风险很高的时候，尽力避免这些错误。前文中曾提到过，发现别人的错误总比发现自己的错误更容易。

尽管系统1和系统2是本书的主题，但我必须要澄清一个事实，即两个系统并不是真实存在的，它们只是我杜撰出来的角色。系统1和系统2不是标准意义上的实体，没有错综复杂的组成部分，也不是大脑中某个固定的部位。为什么将两个系统命名为系统1和系统2，而不是“自主系统”和“耗力系统”呢？原因很简单：说出“自主系统”比说出“系统1”所需的时间长，因此会占用更多大脑工作记忆(短时记忆)的空间。这一点很重要，因为任何事物占用了大脑的工作记忆，都会削弱你的思考能力。

我们大脑的生活步调(现在我爱用系统2的生活步调来代替)大多像是在悠闲地散步，有时候会变成慢跑，只有在极少数的情况下，才会如短跑冲刺。

我们发现，如果人的大脑正处于冲刺的状态，就有可能(对次要信息) 产生有效的屏蔽。

我们会忽视显而易见的事，也会忽视自己屏蔽了这些事的事实。

如果大脑的使用超负荷，其处理则是有选择性且精确的:系统2会偏向最重要的活动，因此这个活动会得到其所需的注意力，其他“多出来的”注意力再慢慢被分配到其他任务中去。

注意力这种精细的分配是在大脑漫长的进化过程中形成的。快速判断最严重的困难或者快速锁定最佳时机并做出迅速反应能提高生存概率。

当你对执行一个任务越来越熟练时，需要付出的努力程度就会降低。对大脑的各项研究证明，与行动相关的活动模式会随着熟练程度的加强而变化，一些大脑区域将不再参与其中。天才也是如此。通过观察瞳孔变化和大脑活动，我们发现高智商的人往往需要较少的努力便可解决同样的问题。普遍的“最省力法则”不仅适用于体力活儿，还适用于我们的认知行为。这个法则主张，如果达成同一个目标的方法有多种，人们往往会选择最简单的那一种。在经济行为中，付出就是成本，学习技能是为了追求利益和成本的平衡。因为懒惰是人类的本性。

以上是书上摘录的部分内容，主要就是说人的注意力是有限的，会因为系统1无法处理而激活系统2，但系统2会消耗更多注意力，而同时系统2又是懒惰的，能省则省。举个身边的例子，大家都知道『在开车过程中，不要打扰司机，特别是路况比较复杂的时候』，而在做熟练的事情时，所花费的精力少，也就是越熟练越省心，反过来说就是越不熟悉越花心思。这也是为什么有时候当界面变化太大时，对老用户的体验并没有带来提升，反而会因为找不到原本想要的功能而感到受挫。

界面的一致性除了让界面看起来更好看之外，最主要的作用是可以减少用户理解的成本，因为『理解』需要激活系统2，而系统2更加消耗脑力。还有一个要关注的点：

与立刻重复一个7位数相比，4位数的加1任务会使瞳孔扩散得更大。加3任务则更为困难，这项任务是我所观察到的要求最高的任务。仅仅在前5秒钟瞳孔就扩散了50%心跳每分钟增加了7拍。这是一个人能达到的最大工作极限—如果超过这个极限人们就会自动放弃。

用开发的话说就是『超时时间』，当遇到一个较复杂的问题时，系统2会调用更多的注意力来处理问题，但超过极限时，就会产生放弃的想法。也就是说，用户并不会给你太多的时间理解界面的信息，如果在短时间内理解不了，就会放弃。也许你会说用户不一定会放弃啊，说不定还能激起用户的探索欲望呢，这取决于当前任务的重要性，如果很重要，那当然不管怎样都必须进行下去，这时能做的就是尝试着去验证理解得对不对，也许最终是能完成了，但整个过程的体验绝对不能算是好的。

一致性原则又是设计过程中很容易被忽略的原则之一，一方面设计师总想做出『与众不同』、『有亮点』的作品；另一方面，也受实际场景影响，现实总是比较骨感，比如原本在界面中划出一些固定的区域，用于放置对应的功能组件来满足一致性，但当某场景中组件数量太少，引起的空间浪费或视觉美观问题时，就会开始想要放弃这种划分了。同时一致性原则也是最难落地的原则之一，主要难点在规范本身的迭代落地是有时间跨度的，而不管是否有规范，只要有迭代，就会有沉没成本；同时还跟落地过程中相关人员对规范的执行力度有关。

这段时间其实读了好几本关于交互设计、心理学相关的书，也从更底层的知识上理解了一些设计原则的底层原因，不仅仅是一致性，像格式塔的完形理论、尼尔森的交互设计原则等等，底层都是人类观察世界、认知世界的方式甚至是大脑的运作方式决定的。有些原则逻辑上可能并不太经得起推敲，特别是各个原则之间可能还会有冲突，但因为大脑就是这样运作的，所以就是合理的。

在腾讯的第七个两年

Ghostzhang — 2020-03-16 15:10:00

在腾讯的第七个两年

由 Ghostzhang 发表于 2020-03-16

这两年过得比以往丰富多彩。学会了利用空闲时间看书、听书。这一年读过的书比前面10年加起来都多，读书确实开阔了视野，让自己更加脚踏实地。

这两年也想了很多东西，工作、生活、生命等等。不知怎么大家开始关注起『死亡』，原来还在担心30岁之后还能不能写代码，后面变成35岁能不能有工作，再后来就是不知道什么时候实然就『猝死』了。怕死就不会死吗？那有什么好担心的呢？没想到2020年的春节又遇上了很严重的新冠病毒事件，至今仍在全球传播。搞得全世界各国都手忙脚乱，也许世界的格局也将在这次事件之后发生很大的变化。

经历了一次更大的转折，响应了公司『管理人员可上可下』的号召，虽然我之前根本算不上什么管理者。但经历过了，眼界就开了。生命有时候是被动的，你能做的只是主动去适应。

在后端同学的身上能感受到是从产品、从解决问题的角度在思考如何出方案的，而前端的同学身上更多的时候感受到的是『懒』（笑脸）。可能我接触的后端同学都比较厉害，让我有了这样的感觉。接触了领域驱动设计¹的相关理论，做为一个后端小白，算是打开了一扇新的窗，给我最大的触动就是前端所接触的东西确实是比较窄的。也因此对前后端的岗位有了一些思考。

前后端的差异

人

所谓事在人为，那我们先来分析下做『事』的人，为什么做这些事的是这些人，而不是别的人。不是说别人不能做，能不能做是一部分，愿不愿意做是另一部分。当然是不是自愿可能也是问题。

面试过不少前端的同学，我总会问到一个问题：『你是因为什么原因选择走前端这条路的？』得到的回答基本上可以概括为：『前端所见即所得，觉得比较有成就感』、『前端变化比较快，能学到比较新的东西』，我自己也是差不多的原因。从这些回答可以看得出一些特点：

对反馈的及时性要求较高
偏向视觉系，对视觉刺激比较敏感
对新事物比较好奇
对『成就感』敏感，有趣的事更有吸引力

前端人员对看不到效果的方案都是不太能接受的。不怕折腾，就怕看不到变化。还有就是怎么方便怎么来，总想绕过规则。前端的人不太能静下心做事，对新东西很有兴趣，受不了重复性的工作，喜欢被关注，但前端又是很容易达到天花板的岗位，就像麦兜里的吃火鸡一样，除了一开始的新鲜感，之后其实就是“吃下去”的机械工作。受不了了，怎么办呢？折腾新东西呀，从工具、库、框架；跨界折腾，做产品出交互画UI码代码塔服务做运营…美其名曰『全栈』。

所处环境

前端跟终端打交道比较多，各位浏览器、屏幕，各种版本、尺寸、分辨率；前端代码运行在浏览器中，而后端代码运行在服务器端，两者算力的差距也让代码的实现方式有明显的差异，如后台代码可以在架构上尽可能的分层以划分逻辑，但前端的代码如果写得太复杂，有可能浏览器就给你『白屏』看。

关注点

前端²所关注的问题集中在界面的展示与操作上，设计稿还原是最基本的要求，在此之上是设计理念的还原，这部分可能不仅仅局限在前端的部分，也包含了对产品的理解及后端的实现。前端和后端都是一个产品必不可少的组成部分，都很重要，都应受到理解和尊重。界面做得再酷炫，服务总是出问题，是无法使用的；同样，后端服务再稳定可靠，前端体验各种不顺畅，用户也是不会埋单的。

而前端里面又细分为负责界面实现的『重构³』及负责交互体验的『前端⁴』两部分，为什么还要再细分呢？个人观点：虽然都是写代码，但关注的东西是不同的，重构关注的是视觉的呈现，如何使用代码在终端上尽可能的呈现出产品所想传达的视觉表现；而前端关注的是如何与后端更好的数据交互及将数据在合适的时间展示到合适的位置上，这里会涉及终端的性能、网络等的研究。

分工的细化同时产生了很多边缘的工作，边缘的工作谁做？这些边缘的事多是连接上下游的事，而处理边缘性工作的人相对来说广度比深度更好。深度的工作需要有环境、制度的支持；而广度为主的工作会更容易生存，但相对成就感低。不过沉淀到一定程度后都是差不多的，差异是在普通人身上。

比较有争议的是部分表现的实现是需要借助js⁵来实现的，这使得无法简单的以使用哪一类开发语言来区分重构和前端，也就是边界模糊的问题，而不管哪一边，剥离了这部分的js，都将变得更加的『简单』，不够『酷』。于是都想把js的部分划到自己的技能树里，最终的结果只能都做。再加从业人群的特点，『全栈』的流行也就不难得出了。当然背后更大的一个推力是因为MVC等前端架构的出现，让组件成为最基础的部分，当前端架构把原先运行阶段的『分离』给搞成『不分离』了，那作为开发者，你不『全栈』一下，连个组件都做不好。这算是『被全栈』了。

『全栈』是出路吗？『成也风云，败也风云』！送上一张图——技术S曲线，希望能更客观的看待各种技术的出现和消失，不是技术本身的问题，是环境在不断的发展。

MVC等架构在前端能火起来，很大程度也是环境适合了。移动端兴起，而大部分移动端的界面数量少、复杂度低，适合做单页面；移动端组件规范化程度高、数量有限，更多开发精力集中在数据上。

前端为什么总在处理兼容问题？

后端同学都在搞算法，前端为什么总在处理兼容问题？

运行环境跟不上追求更酷更新的内心。前端的标准大多数是处于草案阶段的，而正式的标准大都处于要被草案代替的阶段。简单来说就是终端的发展很快，而终端的差异性决定了前端总是在处理兼容问题。同时也就有了终端的『统一大业』这一伟大的目标，当前移动端走在前面的要数微信，但在自身版本中同样也存在着差异；而平台端则是Chrome。但这只是终端的差异，从产品角度来看，也是不可能消除差异的，因为要『竟争』，这或者是个无穷尽的问题。有一个有意思的现象，前端总在做一件事——组件库。各种各样的组件库从十几年前在开始有人做，到现在还在做。有段时间我就在想，为什么这么多年下来，总没有一个组件库能实现大一统呢？随意搜索一下『前端库』、『UI库』、『组件库』，你就能看到一堆文章介绍各种各样的库。而库开发者做这一个库的理由中，一定会有这么一个理由：『为了减少差异、提升开发效率』。这工作理论上是行得通的，对于产品来说也是有意义的，但这问题跟环保有得一拼，得看国情。

在学习DDD¹时，看了到洋葱架构，感觉像看到世界地图，发现原来自己一直只是一个偏僻的小村落里，像一只井里之蛙，以为世界只是一口井。然后就明白『为什么前端总在处理兼容问题』这个问题的答案了，因为生活在地震带上。地缘位置决定了最根本的问题。创新是产品的生命力，而创新就要打破常规，而打破常规如何能不变？

三星、华为、TCL等厂商正争相推出自己的柔性屏终端，可折叠、弯曲，跨屏显示等等新的体验方式，都将给前端带来不小的变化。

图片来自 TheVerge

因此，所有试图统一产品表现的工作，都将非常非常困难。

当下与未来

无数的历史案例都能说明，生存环境对生物的影响是巨大的，决定了生物的一些基本特征，如体形、性格、特殊能力等等。但从来都是生物是去『进化』适应生存环境，而不是环境适应生物。人类看起来是个『例外』，因为人能在一定程度上改变环境，让环境更适合人类生存，不过这种改变也是相对的，对于大自然这个大的系统来说，人类的这些改变不足以影响整个大系统，毕竟对于地球几十亿年的生命来说，人类的出现就像细菌进入了人体。《人类尺度》中有这样的观点，当下人们在担心气候变暖，而没有想过可能即将到来的下一个冰期，人类的快速发展得益于地球当前所处的大周期中的相对平稳的时期，而这个周期终将结束，人类也许什么都改变不了。可能不太乐观，但想透了未来，就能更好的活在当下。之所以『活在当下』那么难，不正是因为所有的『当下』都在考虑未来吗？而未来根本就不可预知。我时常会拿股票的曲线举例子，人们总以为能从那根曲线分析出未来的可能性，但下一个点在出现之前根本就不可预知，所有的分析都是基于历史数据的，都是事后诸葛。无非是想找个『理由』，为可能的『后果』讨个开脱的说法。

图片来自网络

在接触了软件方法后，最大的感受就是认识到自己是井底之蛙。自以为很了不起的发现，其实不过是前人思想中的一个小角落，十几年前就己经提出来了，只是因为现在分工的细化，让原本是一整体的内容被拆开了，当然现在的理论和方法会针对当前的情况加以改良，但并无多少的原创性。也就是说，多读书，能少走弯路！

最近的一年也开始转做交互设计相关的事情，是一个新的领域，但也不算陌生，从以前就比较关心用户体验相关的设计，对心理学也有兴趣，甚至一度想过去当心理咨询，不过显然是想简单，只是看了一小段刑侦小说，就感到自己还是太年轻……社会远比想像中险恶。

系列文章

DDD（Domain Driven Design, 领域驱动设计）是一种通过将实现连接到持续进化的模型来满足复杂需求的软件开发方法。 ↩ ↩²
指web前端 ↩
以HTML和CSS为主要开发语言 ↩
以javascript为主的开发语言 ↩
Javascript的简称 ↩

由文本链接引发的思考

Ghostzhang — 2020-01-01 00:20:22

由文本链接引发的思考

由 Ghostzhang 发表于 2020-01-01 更新于 2020-01-06

最近在折腾交互的规范，遇到这么一个设计，表格中的操作按钮都会使用『链接按钮』。觉得很奇怪，为什么一个看起来是链接的文本被赋予了一个按钮的操作，这跟我所学习的交互原则是相违背的。

于是好奇看了下几大流行的UI框架对这一部分的处理，不好意思，因为移动端基本没有表格的组件，所以主要是看Web端的框架。

Element UI的表格中操作使用了『文字按钮』。

Ant Design的表格中操作使用了『链接按钮』。

Bootstrap也有『链接按钮』，但表格示例里没有使用到。

ZUI的『链接按钮』，表格示例中未使用。

Foundation更奇怪，可以把链接变成按钮，把按钮变成链接。

飞冰同样有这种设计。

这是一种趋势？还是一种滥用？

有同学给出的理由：文字链接被弱化，因为现在使用的场景变少了？移动端的场景里没有多少会用到链接，更多的操作，而移动端的跳转有别的表现方式。

这又让我想起之前做重构时的经历及对标签语义化的思考，如果语义要通过标签进行表达，那么表现层是否就不重要呢？普通用户事实上并不接触到标签，而是从表现上来区分的。从表现层来说，CSS可以做到任意的展现，问题是为什么？为什么是这样展现而不是那样展现？因此，表现层的效果也是语义化的一部分，也就是要『表里如一』。

了解过『HTML 链接』这个内容的同学都知道默认的链接样式是蓝色文本加下划线，这与现在我们在网站上看到的链接样式有点不太一样，比如google的搜索结果（几乎都是问怎么去掉的 -_-||）

个人经历过了链接默认样式被去掉下划线的阶段，因为信息类站点总会有一个首页，这个首页的作用就是进行信息的分类、导航，也就会出现一大片内容都是文章的标题，这时如果按链接默认的表现，就会出现一大片带下划线的文本，还会因为字体的差异而出现不同的下划线样式，这对于UI来说是个灾难，于是各大网站的设计师开始很有默契的统一去掉了下划线这个规则，保留了蓝色这个规则，但这个蓝色也会根据各个站的风格会有一定的调整，毕竟纯蓝色太难驾驭了……再后来个人博客的流行，个性化的链接样式也出现了不少，像对链接文本加大、加背景、把下划线改成虚线等等，不过都还是能表达链接的意思。中间还出现为了区分是站内跳转还是站外跳转，特别给站外的链接加上一个小的icon。

但是不知道什么开始，出现了『链接按钮』这样样式。『链接按钮』由于表现上与链接相同，所以会出现表意不明的情况，而表意不明确可能引起理解上的问题，影响用户对操作的预期出现偏差，降低好感度。

链接是链接、按钮是按钮，两者要表达的东西是不一样的。在《页面重构中的语义化》中讲到了我们其实是内容的传播者，我们对信息的理解影响着我们传递的准确性，影响着信息最终的呈现方式。在《能用并不表示用对了》中讲了生活中类似的经历，用户不会觉得自己有错，一定是产品的设计有问题，虽然最终用户学会了如何正确使用这个产品，但代价是付出了一笔维修费用，同时对这个品牌的产品标上了『不够好』的印象，即使后面的同类产品解决了这个问题（打完豆浆不用取出机头），用户还会延续现在的使用方式（打完豆浆后将机头拿出来），很难改变，因为尝试的成本太高。

说到豆浆机，其实还发生过一个类似的事情。之前的豆浆机用的时间久了，总要换换新的，有一天老婆兴冲冲就买了一台『破壁豆浆机』，有点三体的感觉。收到豆浆机的之后我开始拆包装，顺利拆开后把盖子一盖，发现无法完全闭合，有一条还蛮大的缝，中间还有几个橡胶的物体，如下图。我习惯的以为是包装的一部分，于是手起刀落，把其中一个给拔了……然后老婆就『爆炸』了……

后来才知道这是这台豆浆机的一个特殊的设计，叫『海豚嘴』，就是不能完全闭合的盖子，果然很『破壁』的设计，根本猜不到。心里一千只草泥马跑过。让用户尝试理解一个特殊的设计是有很大风险的。

从设计师那了解到的之所以会出现『链接按钮』这种表现形式，主要是要表达比『次要按钮』更次要的操作，界面上一些轻量的操作使用按钮的表现会觉得有点重，这本属于视觉上的问题，估计是一开始哪个设计师觉得次次要的按钮是什么鬼，反正都是可点击，就用链接的表现吧……（如果有哪个UI设计师不想背这个锅，可以尝试出一个方案）

也许用户经过这么些年已经习惯了这种表达，将错就错或许也是比较好的方案。之所以提出来，是因为我觉得这个问题触及了核心的认知，人类花了那么多时间认识世界，然后用一种不准确的方式进行表达，那之前做的又是为什么呢？如果生活中充满了这一类将错就错的小细节，最终如何才能达到我们所追求的好的体验呢？事实上生活中也确实存在着不少这一类的设计，像《提升体验的设计》中没学到精髓的香港餐厅。还有身边各式各样的『推拉门』，用户忍忍就过去了，反正不是用能用……

关于团队管理的一点思考续

Ghostzhang — 2019-11-09 01:22:48

关于团队管理的一点思考续

由 Ghostzhang 发表于 2019-11-09 更新于 2020-01-20

回顾过往的几年，前前后后加起来差不多带了7年的团队，几乎每三年左右就重组一次，原因多种多样，组织变动、转岗等等。在前面的《关于团队管理的一点思考》已经分享过一些，这篇聊一下考核和目标。

关于考核

关于考核的问题，对于新Leader总是会比较棘手，因为平时不关注或有关注但不知道怎么做，一到考核的时候就会因为无法平衡各成员间的利益而感觉烦恼不已。关于考核的结果，每个人都是希望自己是好的，问题的关键在于如何让成员对自己的能力有较客观的认知。有以下的方法可以参考：

平时如果有问题Leader要及时提出来
对于优点也是，表扬和批评都要及时
要针对行为进行表扬或批评，不要针对人
在考核前可以进行一场团队内部的工作总结

再有就是Leader自身应该定时对团队成员进行综合的能力评估，如专业能力、工作热情、学习能力、工作配合度等方面，把感性的部分数据化，会帮助考核更顺利的进行。

上图是我使用的一个图，借用『技能意愿矩阵』，分别以技能和意愿分为四个象限，即：

高技能高意愿
高技能低意愿
低技能低意愿
低技能高意愿

但简单的分为四个象限是不够的，这个图也不是为了把成员划分四六九等，而是从全局的了解团队成员的当前的状态，所以我在这一基础上，加上了专业影响力、业务影响力、团队影响力和潜力四个评估项。为什么呢？因为大部分的成员可能会处于同一个象限，而这时就需要更加细的划分了。

技能: 完成当前工作所需要掌握的知识、方法、能力
意愿: 完成当前工作所必要的热情、认可程度、主动程度
潜力: 不满足完成当前工作的技能，但掌握有效学习方法，能在短期内补足
专业影响力: 在专业方向的影响范围
业务影响力: 在业务方向的影响范围
团队影响力: 在团队里的影响范围

还是要再强调一次，这个图要客观评估，而且这个图应该是动态变化的，只能说明在当前阶段的状态，也就是说只做一次是不够的。可能你已经注意到上面定义中的强调了『当前工作』，在《不懂教人你就做到死》里讲了这么一个观点——

对于第一次做的人来说，他就是新手，这与年龄无关

我是比较认同的，并不是只有工作才是『隔行如隔山』，在日常生活中，随处都可见，像我前面写过一篇关于冲奶粉的《冲奶粉有感》，对于新手爸爸来说也是不简单的。

当然我们总会希望第一象限的人越多越好，但在团队的不同阶段，会有一些客观的现象，如团队新人主要会出现在第四象限；而团队老人则容易出现在第二象限。

最重要的一点，Leader自身要做到公平、公正，减少自已主观倾向的影响。就像绘制地图，不能因为你不喜欢爬山就把山去掉或换个位置。

目标

每当组织架构变动的时候，第一要关注是保持团队的稳定性，而不稳定的原因很大程度来源于『不安』，对未来项目方向的不安。所以这时候，团队目标的作用就显得很重要了。

团队目标并不是指团队的业务目标（KPI），而是一个团队因何而立？业务可以换，但团队不能散，这才是一个团队立足之根本。甚至只要有一个团队中的人出来，分分钟就能再形成一个团队。

团队之所以叫团队，就是因为大家为共同的目标而聚在一起，也就是说团队中的每一个人都将为了大家共同的目标而做出自己的贡献。但现实生活中的团队，并非都是这样的，像创业公司的团队，大家都很清楚要做什么，这件事对自己的意义，不然你也不会加入这样的一个创业团队。但非创业团队的情况是怎样呢？团队成员往往只是因为一份薪酬，或是一个学习机会而聚到一起，至于目标是什么？不知道，有的只是KPI，需求。这种现像正好是跟团队的定义相反的，先把人聚起来再找事做。

这就导致了团队不稳定性的情况，如果没有目标，那么大家都会没有方向，主动性不足，缺少激情，人心涣散；而一但有了目标，或多或少就会有部分人不认同，也就可能导致成员的流动。对于团队管理者来说，应该分清成员变动的原因，不要过于担心。

目标传递

有时你无法直接将最终的目标向下属说明，虽然知道目标会更有利于提升下属执行时加强自主性和动力，但同时也可能因为无法理解这个目标而产生更大的阻力。甚至会有部分成员根本不想知道，毕竟纯执行对于思考来说是更简单的，而且有时过早思考这些内容也不利于自己的成长。什么阶段做什么事情，这是这几年感触比较深的。

因此在目标传递上面，应该因人而异，由浅入深。做为leader最好先理解分解为阶段目标或多个小目标，再向下传递。情景领导这门课应该是所有带团队的人都要学习的管理课程，但真正在实践中能做的还是很少的一部分。

团队竞争力与个人竞争力

一个团队独立存在最重要的一点是要找到『核心竞争力』，即其他团队在短时间内无法达到的能力。因此，需要对自身的特点、优势有较清晰的认识，时常反思是必要的功课。

竞争的产生是来源于个体的差异，如果大家都一样，就没有所谓的竟争了。对于个体是这样，对于团队同时如此，但团队与个体不同的地方在于，团队是由多个个体组成的，而且是有着共同目标的个体，于是团队能发挥出个体所无法比拟的力量。这里又出来一个问题，现在对于个人，经常会讲全能、多能。一般跟你讲这种理论的团队大都缺少核心竞争力。听起来好像是为你好，但每个人的精力和时间都是有限的，有多少的人能够达到理想化的全能，大多都是一知半解，吹吹牛可以，根本无法在实际工作中应用，想想那些真正的大牛，哪个不是先立足于某一领域的？而组成团队的个体都变成这种追求个体的成长，合作性就会减弱，对团队整体的竞争力反而是有损害的，而如果团队不在了，个人也就得进行新一轮的调整了……回想这些年，每当大环境开始变差，团队成员开始担心自己未来的时候，这种言论就会大行其道。

在小朋友的教育里，让我最有感触的观点是，尊重个体的差异性。每个人都可能是某一领域的成功者，只是这些领域是否符合大众的主流。还是借用游戏的例子，《王者荣耀》中的团队，每个英雄都有各自的特点，各自优势的能力，如果不利用好这些优势，那打起团战几乎都是被灭的下场。但到了后期，经济起来后，能力的优势会渐渐被装备替代，不过这也是买装备的策略问题，如果装备跟能力的匹配度不高，能力无法发挥，反而还会拖后腿。所以，在这一战中，个人的能力与团队发展的要求是否匹配，个人成长的策略与团队发展的策略是否匹配，都会影响到团队的竞争力。

以上，不一定适合所有团队的情况，纯属个人想法，如有不同意见或想法，那就保留意见和想法吧。

CSS Sprites 样式生成工具

Ghostzhang — 2019-02-17 22:47:01

CSS Sprites 样式生成工具

由 Ghostzhang 发表于 2019-02-17

2009年写的一个小工具，当时只是为了解决自己每次对雪碧图做修改时总得去计算位置，要么就是得打开PS这等牛刀。后面用adobe的air打包成了个桌面应用，放到了博客上。现在已经各种框架、自动打包工具处理图片，本以为已经没人用了，没想到今天有人加我QQ反馈说这个工具今天突然就报错了。

看了下他给的截图，跟我之前遇到的情况很像，猜想大概率是证书过期了。于是重新更新了证书，打包发给了他，问题解决。于是也更新了下载的地址，有需要的同学可以自行下载bg2css。

在腾讯的第六个两年

Ghostzhang — 2018-12-31 03:11:00

在腾讯的第六个两年

由 Ghostzhang 发表于 2018-12-31

又是一个历练的两年，虽算不上大起大落，但这两年的变化也够好好消化一段时间了。2017 年又一次经历了团队的大调整，从设计中心调往了研发中心，开发哥终于在开发的路上走了一小步。但这一步意味着从外到内的改变，特别是思维上的调整，正好又是遇到年底最忙的时候，真真切切的感受到来自内心的压力和焦虑。体现在博客文章的数量上，发现今年连总结都没写了。（连这篇文章也晚了整整一年 -_-）

人到中年，生活、工作都到了一个惯性前进的阶段，平凡而忙碌。要关注的事越来越多，工作、家庭、父母、小孩等等，不管能力如何，责任却是越来越重，『青年不懂事』已经不再是一个合理的借口，出来混迟早是要还的。

自身的平凡与想法的不平凡

简单讲就是『眼高手低』。原本以为只有在小年青身上才会有的问题，在工作多年之后发现依然会出现，而这一次是别人的期望造成的，即旁人的高期望与自己能力的不匹配。并不是所有人都能保持能力与年龄同步增长，正是能力与年龄的差异，造就了各种各样的人生，所谓天才，也就是能力超过年龄应有（普通大众认知里的）的水平；而平庸，则是能力低于年龄应有（普通大众认知里的）的水平；至于什么是年龄应有的水平，就看大多人的能力了，而大部分的人能力的增长是跟不上年龄的增长。

知道却无法正确应用的知识

上过不少的培训课，从知识到技能，从思考到表达。但知道了不代表就会做。就像金字塔思维、GTD 时间管理之类的内容，其实原理也并不难，但就是无法在实际生活中应用。还有最最简单的『总、分、总』结构，从小学开始老师就教的内容，特别有用但就是用不好。主要还是缺少『刻意的练习』。是的，就连知道是缺少『刻意练习』，还是没能刻意练习。而这种知道又做不到的落差，又进一步增大了期望与能力的差距，这也是生为『孩子』时为什么会气忿『大人们』总是双重标准——只会教训别人，自己又做不到。因为『大人们』也只是知道。也许正是因为大多数人做不到，所以『能人所不能』才是成功者的标志之一。

试图改变无法改变的事物

试图改变无法改变的事情是最容易产生自我怀疑和挫败感的。

历史长河浩浩荡荡，人类在这里面真的是十分的渺小，以为自己掌握了趋势，其实只不过是趋势中的一部分。

系列文章

2018 CSS裸奔节

Ghostzhang — 2018-04-09 00:00:00

2018 CSS裸奔节

由 Ghostzhang 发表于 2018-04-09

一个渐渐被忘记的属于前端的节日。节日的意义不仅在于庆祝，更在于提醒未来的人们记得，曾经有一件需要人们记得的事发生在这个世界上，而这件事有很高的重要性，不能被忘记。CSS裸奔节¹的意义在于提醒前端开发者，HTML的结构、标签语义的重要性，关注内容本身的准确呈现。

近几年前端越来越快餐化，各种框架、库不断的刷新着前端的开发效率，AnglarJS、reastJS、vue的出现让前端有了更多的机会了解和实践程序开发的模式，但也因此让HTML和CSS更加的碎片化，开发人员的关注点都转移到如何实现组件、实现模板上，让原本应该为内容呈现服务的前端工作更偏离了本职。

追求成仙者易成魔啊。以上是在这个渐被遗忘²的节日里的所思所感。

CSS Naked Day，也称CSS裸奔节或CSS裸奔日，在裸奔节这天，参加裸奔节的Blog 将会去除页面上所有的 CSS 样式和广告裸奔整整一天。 ↩
第一届开始于2006年，有将近800个国际知名网站参与这个节日。最近一届是到2013年，之后就没有正式组织过了，连网站也已经不可访问。 ↩

记一次学校活动

Ghostzhang — 2017-08-23 00:00:00

记一次学校活动

由 Ghostzhang 发表于 2017-08-23 更新于 2025-12-26

周末女儿班里组织了一次『定向越野』，小朋友们从一天前就开始兴奋着。做为家长，我有幸一起参与了这次活动，陪着女儿完成了整个过程，原本对自己的定位是一个『战地小记者』，一方面注意她的安全问题，一方面也观察她在过程中的表现。

个人以为，『定向越野』这个活动，对于小朋友们来说，主要有两个目标：学会指北针的使用；学会看地图。因此在过程中应该更关注如何让小朋友们学会使用这两种工具。更高级的目标：学会团队合作，策略制定，如位体力分配、分工等。

可惜组织方明显没有考虑那么多，或者说根本控不住场，只是用『蛮力』、『威胁』的方法，效果一般。也导致活动规则没有有效的传达到位，部分小朋友根本不知道道具如何使用。当然这些都还算可预知的范围内。

考虑到公园里人员复杂，场地也较大等问题，部分家长会跟在小朋友身边。有些家长可能是为了让自己的孩子能『赢』，会给一些提示，但在活动过程中明显能感觉到小朋友对家长的提醒会产生依赖，一遇到困难就会寻求家长帮助而不是自己解决问题。而对于同组的其他家长（比如我）就很尴尬了，不提示好像就变成『坏爸爸』，提示又不是我期望的。当然最终因为实在看不过眼，还是教了她们如何使用指南针和看地图，但因为有家长总是直接就帮着她们找出目标，导致她们根本就听不进使用方法，总想着反正有答案……

建议下一次活动类似的活动可以找场地稍微小一点的，场地过大也会导致小朋友的运动量过大，天气太热很容易出现中暑等情况，而场地过大也会导致救援不及时，这样的安全工作是有隐患的。确保小朋友能安全而独立的完成，不需要家长参与，这样可以避免掉一些作弊的情况。然后以一种阶段性进阶的方式进行游戏，在每一个阶段过后进行小结，分享经验以及感想，共同提高掌握技巧跟方法。可能组织方本来也没想过要教会小朋友们什么东西，只是为了拿钱时有个交代。

今天这场活动感觉就是大家都是为了竞赛，充其量就是锻炼身体吧，但是在这过程中并没有学会团队合作分工以及指南针地图的使用。刚有家长出现作弊指导的情况下，那么队伍就有可能获得胜利，而在这个胜利的建立下会导致小朋友的认知出现问题，虽然通过外力能取得胜利也是一种路径，但在这种小活动中，有点把胜负看得过重了。

人生中大多数时候需要面对的是失败，学会面对失败，才能更好的面对人生。

margin-right右边距失效

Ghostzhang — 2017-06-22 00:52:13

margin-right右边距失效

由 Ghostzhang 发表于 2017-06-22 更新于 2017-06-21

不小心看了下知乎，万年潜水，突然看到有一个邀答，问题在这里，进去看了下，觉得这个问题很有意思，于是想试着回答：

先试着还原最初的状态，在题主的Demo上改改：

于是变成这样

用Chrome的开发者工具看看：

可见子元素的margin跟父级元素重叠了，这是外边距合并的现象，具体可以看看这几篇：《外边距合并》、《盒模型》、《CSS 外边距(margin)重叠及防止方法》、《What You Should Know About Collapsing Margins》

但都没能解释这次的问题，右边距为何失效了。

当父元素设置了overflow:auto之后，变成了下面这样

正常哈，因为激活了父元素的BFC¹，margin合并的规则失效，现在看到的才是我们预期的样子。

从Chrome的开发者工具来看，子元素的margin只有top、left、bottom有效，右边距失效。试着移动下子元素：

可以看到子元素的外边距位置是随着子元素移动的，所以才会出现了移到右边后右边的外边距没有显示的结果。

找了下margin合并，或叫外边距塌陷(margin collapsing)相关的内容，基本上都只是提到上下边距的问题，于是试着给父元素也设置了margin，然后就看到，右边距基本也是无效的，一个auto的状态：

总结下：

默认状态下的块级元素右边距是无效的 设置float（除了none以外的值）、display (inline-block，inline-flex，inline-grid，inline-table，inline-box，table)、position（absolute，fixed）之后会生效
当父元素的宽度小于子元素的宽度时，子元素的右边距无效。 用scrollWidth取到的值也是不包括右边距的，跟盒模型的规则有点冲突，不知道算不算是BUG。通过设置display（inline-block，inline-flex，inline-grid，inline-table）可以让右边距生效。

如果非要子元素有右边距，可以这样：

子元素设置右浮动，但会导致父元素的overflow失效，抱脸～～
子元素的左边距为auto，并且父元素的宽大于子元素的宽；

对于当前问题的解决方案也很简单，为子元素再加一个父级，然后为它设置一个跟子元素实际宽度相等的宽即可：

效果展示

或者，加一个兄弟元素，让它隐藏起来，宽度为实际宽度，应该更实用些：

效果展示

只是，为什么会无效，我没找到答案。

更新：重新又检查了遍，找到一个更简单的方法，设置子元素的display：

效果展示

BFC（W3C CSS 2.1 规范中的一个概念）就是所谓的Block formatting contexts （块级格式化上下文）。创建了 BFC的元素就是一个独立的盒子，里面的子元素不会在布局上影响外面的元素，反之亦然，同时BFC仍然属于文档中的普通流。

↩

对『小程序』的一点理解

Ghostzhang — 2017-05-25 00:42:04

对『小程序』的一点理解

由 Ghostzhang 发表于 2017-05-25

到微信支付团队的近两年来，一直在思考的是到底什么的O2O，我要怎么去理解它。在经历了小程序发布前后行业舆论的变化，感觉想法渐渐明晰，以下是一些些感想。

从服务整合到碎片化场景

在移动互联网时代到来之前，我们都在提倡平台化，将同类的服务整合到一个平台上来，从信息搜索、应用下载、线上购物到美食、电影、排队等等，都是小平台整合服务，大平台又整合小平台。这是互联网的玩法，『线上』的玩法。

线下同样也搞服务整合，为了提供便利，这是地理位置造成的问题，像肉菜市场，如果分散到不同的地点，买个猪肉到A市场，买个佐料到B市场，再买个青菜，到C市场，一餐饭的菜买下来花了大半天，是很低效的。类似的还有便利店、水果店，甚至大型商场、超市，都是基于这个诉求。

天下大势，分久必合，合久必分。比如银行网点，我们以前取款都必须去银行办理，不管你要取多少，不同地区的银行网点数量不一样，如果刚好你所在的区域没有网点，为了办理个业务可能要跑大老远，很显然这是反人类的。后来有了提款机，小额取款可以直接在ATM解决，相对于网点，ATM的数量就要多得多了，再后来，打通各银行的屏障，可以跨行取款。转账就更加方便，不涉及现金，直接通过互联网完成，连ATM网点都不需要去了。

『互联网+』的提出，用互联网的能力为线下传统行业赋能。但很显然这是互联网人提出的观点，是用互联网去加传统行业，而这也让线下实体商户对『互联网+』这个概念有这种吃了只苍蝇的感觉。互联网的传播能力对传统的商家营销方式产生了深远的影响，特别是将地理位置的局限性减弱了，通过快递物流可以有效提高自身的业务能力。但互联网解决的是人心理上的距离问题，并解决不了地理空间上的距离问题。并非所有的商家都可以通过互联网卖自己的产品或服务，有些东西还是必须到店才能得到，对于他们来说，『互联网+』是不准确的，应该是『+互联网』，而这类商家应该说是占了大多数。互联网对于这类商家来说，更多的是品牌的传播，他们对互联网的认知可能更多是『H5活动』、『朋友圈广告』等词语。面对线下那么大体量的市场，互联网人真不知哪来的自信觉得只要打上『互联网+』的旗号，商家就会跟你合作。在商言商，最终还是要看互联网能给商家真正带来什么利益，毕竟再多人知道也得实际到店才能产生价值。

近几年随着移动支付渐深入生活，也渐渐影响了线下行业对互联网的关注度，互联网不再只是用于『宣传』、『吸粉』，而是有可能改善经营，提升自身竞争力的有效手段。而这种观念的转变，『小程序』是主要的推动者。

对『小程序』的一点理解

『小程序¹』出来至今，从一开始各种关注、热抄，到现在渐渐冷却，甚至出现不看好的种种观点。

『小程序是一种不需要下载安装即可使用的应用，它实现了应用「触手可及」的梦想，用户扫一扫或者搜一下即可打开应用。也体现了「用完即走」的理念，用户不用关心是否安装太多应用的问题。应用将无处不在，随时可用，但又无需安装卸载。』

不想评价对不对的问题，只是想聊聊我对它的理解，为何它会是现在大家看到的现在这个样子（也许以后会不一样，在写这篇文章的过程中，已经发布了好几次更新）。

列几个大家都觉得是『问题』的问题：

不支持模糊搜索（已经支持）
入口太深使用不便（从扫一扫进入还是蛮快的，这是使用场景问题）
不能跳转到外部
包大小不能超过1MB（不包含外部资源；现在增加到2M了）
功能层级不能超过5步（不超过5层view）
没有关注功能（其实只要打开过一次就会出现在小程序列表里，这也算是一种关注吧）
不能分享到朋友圈（通过分享二维码图片，其实算是放开了）
不支持在微信中长按识别二维码（已经支持公众号文章中、朋友圈图片长按识别）

看起来是种种的限制，但何为『限制』？或者说何来『限制』的感觉？很简单，想做的事无法做，就叫限制。但是否想过如果这就是它应该的样子呢？因为是新事物，没有参照物，所以将之与『公众号』、『服务号』做对比，跟客户端做对比。在习惯了互联网的开放和网络营销等等套路之后，惯性的用之前的方式去看『小程序』，结果发现处处走不通，于是产生否定的观点。甚至不少人在想当然的把『小程序』当成是解决自己目前困境的突破口，但对它能做什么并不了解，判断基本上都是来自于『小程序』发布前网络上各种文章的猜测。

然，在经历了一段时间的冷静后，也许应该重新认识『小程序』。前面所有的『问题』，都是构成『小程序』的特点所在，因此也许要想另一个问题：为何『小程序』要有这些特点？

如果单从技术实现上来说，小程序能做到的，现有的Web和客户端都能做到，而且要更自由丰富些，像扫码点餐的体验，现在都是以web的方式实现的，也没有差到哪去。那么问题就变成：为何小程序要有这些『限制』？

因为包大小的限制，必须精减内容，专注最主要的内容；因为功能层级不能多于5层、不能外跳，必须优化流程；不能分享到朋友圈，不必考虑把它的营销，更专注于体验。而这一切都会让你提供的服务更加高效、体验更好。

综合来看，小程序不需要像app先下载一个客户端，这其中还会涉及到要先找到应用商店，搜索到对应的app，然后输入帐号密码，下载，等待下载安装完成。进入了app，还会遇到如登录、注册等操作。也不需要像现在公众号或服务号那样，先扫码或搜索公众号，关注公众号，然后等消息推送或回复关键字，按提示操作等等。而这些操作无疑会让用户的心理负担，影响用户体验，从而影响商家的品牌形象。

而小程序会减轻用户使用时的心理负担，带来更好的到店服务体验。我的观点是：『小程序』能更好的解决服务的最后一公里问题。用更短的服务路径触达到用户，减少用户在享受服务过程中的挫败感，提升商家品牌印象。而对于一个好的服务，用户的口碑传播也会是很可观的。

因此我认为，在做线下商家这部分时，已经不能再按之前『线上、线下』的方式进行需求的划分，而是要从『到店、离店』的维度来划分。用『线上』的方式提升『到店』的体验，将影响『到店』体验的部分转移到『线上』或『离店』的场景中去。 像预定、排队、点餐等等任务，通过互联网都可以现实为『离店』任务。最直观的感受就是原先政府部门的业务办理，几年前我还写过文章吐槽，不少的城市都开始实现线下业务线上办理，一些不必要亲自去到线下才能办的业务都可以随时随地的办理；而那些必须到线下办理的业务，非核心的任务也可以移到线上去办理，像预约办理时间、填表格等任务，可以利用碎片化的时间在线上完成。这让线下的生活幸福感提升了不少，也是互联网对线下生活最大的贡献。这是一种服务体验的升级。

线下商家要更进一步了解互联网能做的事，才更有可能将之应用于自己的服务上，从而真正带来服务体验的提升，而这些对于线下商家来说是比较困难的，原因当然种种，所以需要有对商家所能提供的服务与受众的使用过程中的体验有较高洞察力的人，在用户使用过程中的各个接触点，提供或被动或主动的优化方案。因此我相信后继会出现类似互联网交互设计师这样岗位的新岗位，专职服务体验的内容。

虽然现在小程序不断开放出来新的能力，（这段时间不断放开的限制一度让我觉得这篇文章是不是写不下去了）但我觉得都只是对之前『不温不火』处境的一种妥协，与小程序的初心虽不冲突，但也不全契合，小程序并不是为了取代app而生，线下才是小程序真正的入口。

可惜的是现在成功的案例还有待探索，随着小程序功能不断的完善和提升，我相信并不需要再多久的时间。一切都还是开始。

依赖于微信客户端的轻量级应用 ↩

关于葬礼

Ghostzhang — 2017-03-16 23:18:20

关于葬礼

由 Ghostzhang 发表于 2017-03-16

在看《神奇队长》时，一开始以为是又一个漫威英雄的电影，结果是一部讨论『教育』的影片，在电影的后半段，出现了关于『葬礼形式』的讨论，当时只是觉得很感人。

2012年9月12日，我奶奶的祭日。也是我活了这么多年第一次参加葬礼。从小家里就以算命先生的告诫——小朋友不要参加『红白事¹』要求我，于是乎，在我自己的婚礼之前的二十几年里，根本不知道所谓『红白事』是什么样的。

之后陆续参加了几次葬礼，都是亲人。有不同地区风俗的、有法事的、有佛事的、有自己为主角的、有简单的、有奢华的，总之也算是这么多年来难得的体验了。

我通常不是个感情丰富的人，总习惯以旁观者的视角看待身边的事物，多了些理智，却也少了些生趣。看着身边参加葬礼的人们，竟思考起自己的葬礼要怎样举办。做为当事人，在参加奶奶的葬礼时，跟我结婚时的感受居然差不多，都是『任人摆布』，繁长的礼节，让人精神麻木，身心疲累。根本已经顾不得悲喜，只是想给大家一个完整的结果。心疼家人还要为了『死者』身后事，不但要面对失去亲人的悲伤，还要为了筹办葬礼而东奔西走折腾得心力憔悴。

死亡也许并不可怕，可怕是活着的人所要面对的舆论。不管生前做人怎样，死了就死了，活着的人也并不会因此怎样。伤心？难过？都是臆想出来的。

办一场葬礼，几万，十几万，几十万的花，为了什么？从以前人的生存环境来说，家里有人死了，往往意味着势变弱，而能办得起葬礼的基本上也算是有钱有势的人，也就必然有不少明的暗的对手，这时候一场葬礼的场面，也是对对手的一种警示，同时也是分散在各地的家族人难得同聚，加强交流的机会。

流传至今，葬礼更多变成是一种仪式，普通的家庭为了缓解舆论压力，有权有钱的家庭则当面子工程。在参加的几场葬礼里，大致可分为几类人群：一种是至亲，就是跟死者关系最好、最亲的人；一种是亲戚，平时交往不多，但脱不了关系那种；一种是朋友；最后一种是葬礼的承办方。除了至亲，其他人并不怎么关心葬礼办得怎样，更多的是一种任务，出于舆论的约束。对于参加葬礼的人来说，除了『长见识』之外，就是品评主人家的礼数周不周，而大多数参与葬礼的人，也将有机会办葬礼……

我觉得最大的『收获』就是，不管是出于舆论压力或是表达对死者的尊重，这种时候大部分的亲人、亲戚都会到场。于是我见到了平时连过年都几乎见不到的远近亲戚，也才知道原来『家族』有那么多人。休息的间隔几个人聚在一起聊聊各自近来的工作、生活，各自在不同城市的发展等等……却无法用『开心』之类的词……

相比办了一个加重家庭经济负担，对死者毫无价值的仪式。我希望我的葬礼能办成一场聚会，以『死者』之名，让各亲朋好友能相聚一起，交流下各自的近况，也许有相互帮助的机会，也许可以化解一些矛盾，做为『死者』最后为家庭做出一点贡献。

婚礼和葬礼 ↩

2016年总结

Ghostzhang — 2017-01-24 01:48:22

2016年总结

由 Ghostzhang 发表于 2017-01-24

今年是不平常的一年，在经历了新团队、新业务、新行业的适应期后，终于也是要面临『生存』的问题。

微信支付的发展是迅猛的，这些都离不开产品、品牌、BD 的大力推动，但做为一个前端的团队，所掌握的能力也只是线上的技术，在这样一个重点关注线下推广的阶段，所能做的事情非常的有限。而看着大家都在努力向前，自己却无所做为，那种心情也是不太好受的。

有着视觉转型线下品牌设计和交互转型为线下行业解决方案的前车之鉴，前端团队也被惯性的往线下推，但这真的是对的吗？穷则变，变则通，然而怎么变，变成什么才是根本的问题。这也是一直困扰我的问题。

团队

很感谢团队对我的信任和支持，在我过来之后对我的工作提了很多的建议和想法。虽然我过来之后并未做出多大的改变，还是以稳定为主，但能看到大家渐渐收心，更踏实的去做事情，还是很欣慰的。

在大环境正不断变化的时候，最难的是及时发现自己的位置是否适应变化，并做出调整。而更难的是要决策如何做出变化。『问题本身解决不了问题』当自己无法跳出原来的思维框架时，就会看不到解决的方法。而身为一个 leader，你不能盲目的带着大家去做改变，虽然有个说法『烂泥爬楼梯，就算摔下来，也不会比原来更差』，不过这也只是自我安慰的话。我不相信盲目的改变会有机会变得更好，现在的环境并非在一片迷雾里，经过了互联网快速发展的过程，移动端的崛起，一切都是有迹可寻的。不管怎样，都必需有一个能说服自己的方向，不管未来可能怎样。

能确定是的，不管是个人还是团队，都应该有自己的核心竞争力。不同的是你对核心竞争力的理解和对生存环境的理解。

新年初始，团队将迎来新的变化，也许一切重新开始，也许能够磐涅重生。所幸对于自己来说，也是痛定思痛的过程，希望能推动自己做些改变吧。

教育

女儿也渐渐长大，对学习也开始不太上心，小聪明用到了如何顶嘴上，然后又让我开始纠结骂或不骂的问题。一直觉得以强势的方式是有问题的，以成绩为主的教育是有问题的，但每次她成绩不好，不由自主的就是会“上火”。

教育的问题跟团队管理也很类似，都是影响人，都需要为他人负责。不同之处在于，小朋友并不太讲理，无法更直接的沟通，而这种『无理可讲』的挫败感对于成年人才说是很可怕的，通常只有一种结果，就是发火。然而发完之后，小朋友还是不知道你在讲什么，沟通依然无效。

参加了几次家长会，每次都感觉老师是在讲管理课，对我的触动是有的，只是之后从实际日常的上课、作业、测验中，从我女儿的表现加上老师的反馈，我会觉得家长会讲的那些跟实际老师的行为还是有不少差别的。也许是身在中国这个教育环境里不自觉的会被影响到，或是大家都做不到言行一致。

与小孩子的相处，也是值得持续自省的，希望在新的一年能有更大的进步。

『悟』

每年都会或多或少『悟』到点什么，之前会以单一的趋势去看问题，渐渐学会分不同的阶段去看。毕竟互联网变化太快，而且现在的人思维也很活跃。同样的事情，在不同的阶段，其重要程度是不一样的，但不被关注不等于不重要，之所以被关注，可能是因为当下最紧急、最重要，但并非不关注就不重要，就像空气质量，在以前很少有人会关注，因为并不威胁到生命，但能说不重要吗？当觉得不被关注就不重要时，终于要迎来不得不关注的结果，而且需要付出更大的代价。

『工匠精神』 vs 完成任务

一提到『工匠精神』，可能不少同学会觉得就是要做到最好，不放过任何一个细节，包括正在各种对『工匠精神』的宣传，都会让人觉得『工匠精神』是专注于一个领域，坚持不懈。但实际的工作里常常会发生这样的矛盾，项目交付的时间已经快到了，但细节上还有很多不完美的地方，到底是为更好的完成细节还是放弃一些细节让项目能按时交付呢？

有同学举了个例子

像打战的时候，遇到了一条河，对于工程兵来说，是要快速建一座桥让大军通过呢？还是建一座精美、可以留存很长时间的桥？

我以为，在有限的时间和资源内做到最好，也是工匠精神的体现。正如上面的例子，当然会选择快速建一座桥的方案，但并不意味着这座桥就质量很差，再怎样都要能保障到大军的快速通过，这才是这座桥存在的意义，而这也是『工匠精神』的体现，在同等条件下做到更好。

读书

之前一直用手机看小说，因为长期用眼过度，眼睛都不答应了。在看完眼科完成冶疗后，决定买了台 kindle，虽然觉得墨水屏的翻页效果确实是不怎样，但只是看看书的话，还是很赞的。

这一年对我影响比较大的，有两本，但都还没看完。一本是《大秦帝国》，以史为镜，在佩服古人智慧的同时，反省现在遇到的问题，有时候上帝视角也是很无奈啊。历史的进程充满了各种可能性，一些不起眼的事情最终让一个个国家面临灭亡，也让一些国家崛起，有些原因很荒唐，但却真实的决定着各国的命运。

另一本是《被讨厌的勇气》，阿德勒的心理学入门。问题不在于『世界』是什么样子，而在于『你』是什么样子，跟佛洛伊德的『决定论¹』不同，阿德勒的心理学是『目的论²』，他认为决定自我的不是『经验本身』，而是『赋予经验的意义』。这本书解开了很多我以前的困惑，虽然有些观点我以前也是那么想的，但更多觉得可能是自已的歪论，与众不同则必然得不到很多的认同。直到无意间买了这本书，才看到了一个不一样的世界。

『过去』发生的事决定了人的『现在』。 ↩
应该追究的，不是过去的『原因』，而是现在『目的』。 ↩

小巧的文件模板工具

Ghostzhang — 2016-12-14 22:47:01

小巧的文件模板工具

由 Ghostzhang 发表于 2016-12-14

工作中常有一些小页面，结构是一样的，换换图、换换文字就是一个新需求。对于我们来说，就是把文件复制一份，然后找到里面要修改的位置换上所要的文字，这是很简单的事情。一次可以，二次可以，三次、四次、N+1次之后呢？枯燥随之而来，一不小心改错位置或漏改、删错标签。能不能让这些看起来简单却需要不断重复的事更高效呢？或者让别人去做呢？比如上游的同学。

但是对于不懂得代码的同学来说，你也不可能放心让他们去改你的代码，所以能不能大不接触代码的情况下完成内容的修改呢？

比如，下面代码里的内容：

<title>CSS森林</title>
<a href="http://www.cssforest.org/blog/" target="_blank">CSS森林</a>

如果变成填表单，会不会更友好？！

啊哈，你一定想到了“内容发布系统”之类的东东，写个后台让需求方自己填写，自动生成，搞定。自动化是不错的选择，但往往自动化是有针对性的，即高度定制化，这也使得『系统』的通用性比较差，而且自动化系统的开发是需要时间和服务器支持的。最最重要的是并不是什么东东都能有接入“某某系统”的优先级，或许根本就没有系统。毕竟，开发一个后台的成本可能比需求本身还要高。

每次看到聚惠活动的一大堆产品列表，就有一种想死的感觉，真佩服做活动的同学能一个个去填内容，还要校验。对此，做为一个玩技术的，总要看看能不能解决问题，或者说减少工作量。

在一个以内容发布为主的需求中，一般与之相对应的发布系统都是比较后面才会实现的， TIDemo是一个小巧的模板工具，通过制作简单的模板文件，即可实现将模板中需要更换的内容生成对应的表单，提供更直观的输入体验。

TIDemo支持自定义变量，将变量在界面上以表单的形式展示，通过填表单的方式输入内容，然后导出为填内容之后的文件。经过几年的更新，当前版本已经支持包括循环输出、数据导入、数据筛选、输出二维码等功能，基本能满足常见的简单内容维护工作。

在实际工作中会有一些特别的应用，后继我再整理出来跟大家分享，也欢迎大家分享自己的使用感受。快下载试试吧 TIDemo。

设置Sublime Text为Adobe Air的开发编辑器

Ghostzhang — 2016-10-09 00:29:19

设置Sublime Text为Adobe Air的开发编辑器

由 Ghostzhang 发表于 2016-10-09

在上一篇关于Adobe Air的文章中¹，介绍了如何设置Air的开发环境，由于是跟Web差不多的开发方式，基本上Web所使用的编辑器都是适用的，像Dreamweaver、aptana studio等，当然还有Sublime Text。

回到正题，当你下载了Air的SDK后，编辑完一个项目后，需要运行它进行调试，你可以用命令行的方式，设置完AIR的开发环境后在命令行进入到项目目录中，输入


adl application.xml

就会运行你的项目了。这种方式其实也蛮快的，就是每次都得切换窗口、输入、回车，一次两次还行，多了还是挺烦的。

下面来看看怎么用Sublime Text减少下这个工作量。

新建Build文件

在Sublime Text的菜单上找到『Tools->Build System->New Build System…』，点击后会出来一个新文件，输入下面的内容：


{
    "cmd": ["adl","application.xml"],
    "path":"/Users/ghostzhang/AIRSDK/bin/",
    "working_dir":"${project_path:${folder}}",
    "file_regex": "^[ ]*File \"(...*?)\", line ([0-9]*)",
    "windows":{
        "path":"D:/AIRSDK/bin/"
    }
}

注意，上面设置中的『path』需要根据你实际的SDK路径修改。保存为『Air.sublime-build』，可以放到你的个人设置²目录中。这时在『Tools->Build System』下应该就可以看到刚才创建的『Air』了。

关于更多Build的选项，可以参考这里。

运行你的项目

首先，得先把你的项目保存为一个Sublime Text项目，很简单

『Project->Add Folder to Project…』，增加项目目录
『Project->Save Project As…』，保存项目

在窗口左边会出现项目的目录，说明设置成功了。然后选择我们创建的Build设置『Tools->Build System->Air』，这时我们按『Ctrl+B』，mac下快捷键为『command+B』，可以看到我们的项目就运行了。

使用Adobe AIR SDK搭建AIR开发环境（HTML+Javascript） ↩
windows：Preferences->Browse Packages…；mac：Sublime Text->Preferences->Browse Packages…；打开后里面的User目录 ↩

老似名山到始知

Ghostzhang — 2016-08-30 01:54:50

老似名山到始知

由 Ghostzhang 发表于 2016-08-30

这几天因为通道晋升的事，又让自己又陷入了深深的自我矛盾中。

编程能力一般，对于在前端通道晋升无优势，甚至是处于弱势；重构的能力也因多年未写代码而有所下降；自身对于英文有心里上的抗拒，总是不自觉的会自我暗示学不好；但又不满足让自己就一直在这职级上停留着。转通道或许是因为听信了别人的意见，但最终还是因为自己做了选择，既然自己选了，就得为此负责。但这种想继续往上走又明显能力不足的情况，让自己很焦虑。而同时也触发了我的自我保护，开始为自己找理由了。

为什么一定要晋升呢？为什么我需要通过别人的认可才能得到肯定呢？为什么我不能自我肯定？公司给的始终只是公司给的，如果我换了一家公司，还能不能得到同样的？过去10年公司已经给了我不少东西了，难道还要因为晋升不了而闹情绪吗？以我当前的职级，就算再升一级，也就差不多到头了，那现在升不升关系大吗？明明是因为自己前端的专业能力不足才无法晋升的，我花点时间补上来不就是了？但我为什么要花时间到一个我补完也没多大作用的事情上呢？因为我再怎么补，也不可能走回专业前端开发的路啊，我内心更偏向走管理的路线，但我也有很多的能力是不足的，比如对社交并不上心，纠结的人啊～

更痛苦的是当你面对向你询问这方面问题的人时，即不能传递负面的情绪，又不能完全不管，但自己也并不知道怎样的方向就是对的。特别当你给了别人建议之后，自己又迷茫了的感觉很不好，责任心作祟。

不可否认，通道评委的影响力是很大的，对于希望自己能晋升的同学来说，往往会因为评委的一个问题或建议而开始调整自己后继的工作方向和重点。但却忽略了评委只是对你在面试过程中的表现进行的评价，对于你实际的工作环境、所处的状况是不清楚的。

有同学被挑战『为什么要做这个项目，访问量这么少，影响力有限，做来干嘛？』『团队都开始往线下转型了，你们为什么还不转型？』结果回答不上来。于是开始埋怨自己所在的业务不给力，项目太小，没人关注自己。这类似是而非的提问最容易讲，因为大部分人回答不上来，提问的人也就不容易被反过来挑战，以此来掩盖自己对问题背后的问题的无知。冷静想想就能走出这个误区，每个业务、项目都有自己的特点和环境，别人做得好的，未必适合你。

回答不上来并非只是业务的问题，还有自已没有思考过『为什么』，这个才是根本的问题。就像别人总会问『你结婚了没有？有没女朋友？』，你要怎么回答？『关你什么事？』你心里会想，实际上也是很难回答，回答得好也不会送女朋友。别人只关心你怎么还不结婚的结果，但并不在意你的感受，而对于自己，结婚可能并不是结婚本身那么简单，还关系到你未来的生活。

嗯，说出来就好些了。『答案在问题本身』，社会的进步不在于颠覆，而在于积累。积极求变的人必定对现有的环境有极大的不安全感。

GitHub Pages 更新

Ghostzhang — 2016-05-07 02:26:59

GitHub Pages 更新

由 Ghostzhang 发表于 2016-05-07

有段时间没有更新了，没想到一更新就收到GitHub的邮件，说是系统升级了，因为使用了一些旧的功能，需要更新……为什么啊～我只是想安静的写写文章……好吧，不更新的话根本就编译不通过，那就只能动手改改了。

首先，看看这次系统升级了些什么，根据邮件指示，来到了这里：GitHub Pages now faster and simpler with Jekyll 3.0，大概的意思是GitHub Pages更新到Jekyll 3.0了，有以下几点变动：

2016年5月1号开始，GitHub Pages只支持kramdown,作为Jekyll的默认Markdown引擎，如果你用的是其它的引擎，那么你有三个月时间进行更新。
代码高亮的实现方式也要改啦，只支持Rouge的方式。原先如果使用{% highlight js %} code {% endhighlight %} 的方式进行代码高亮，那么就得修改啦，用```即可，详见 https://help.github.com/articles/creating-and-highlighting-code-blocks/。
Jekyll 3.0对本地版本的优化，我没有使用过，不太了解，有兴趣的同学自己到上面的链接看吧。
将不再支持Textile

更多Jekyll 3.0的特性可以看Upgrading from 2.x to 3.x。

在腾讯的第五个两年

Ghostzhang — 2016-05-05 22:59:43

在腾讯的第五个两年

由 Ghostzhang 发表于 2016-05-05

今年是在腾讯的第十年，按我的观点，每两年都是一个成长的节点，虽然环境变化很快，但想要有立足之地，并非只有不断的学习新技术，随着年纪的增长，反而会开始思考本质的东西。特别是看到越来越多一时成功后又失败的例子在身边不断发生，『成功』为何？『反思』是这两年的主旋律。

这两年我又经历了一次环境的转换，2015年中，从财付通的设计团队转岗到微信支付的设计中心团队，虽然还是负责重构前端团队的管理，但感受最为明显的是业务的转变，应该说并不仅仅像换了个团队，更像是换了个行业。

微信支付是做O2O的，相比互联网线上的业务，这是一个对我来说全新的领域，不一样的关注点，不一样的思考方式，从互联网的只考虑用户的使用体验，到O2O的不仅要考虑用户的体验问题，更重要的要考虑商家的体验。也让我更加认识到『创新思维的TASK模型』中提升通用技能的重要性，而其中提升思维部分的方法，也是近期的特别关注点。

这半年的接触，感受较深的是相对于线下的企业，互联网并不像原先自认为的那么的强大，虽然确实是高科技了，也大大减少了线下做到同样效果所需要的时间和成本，但体量还是太小，线下商家能看到互联网所带来的好处，但却并没有到非用不可的程度，只是一个补充，至少当前互联网还无法解决线下商户遇到的所有问题，而做为互联网与线下连接的在线支付行业，目前更是还在争夺市场份额，解决生存问题的阶段。

总体来说，更像是一个创业团队（虽然我并没有创业经历，也许经过这了段时间也就有了。）

人生真的是在不断的选择中进行，往左还是往右，吃什么，先做哪件事等等，可以说正是过往的无数个选择成就了现在的你。由此可见，人之所以不同，真正的差异可能就是做选择的能力，以及与之相关的能力，如执行力及坚持的时间等等。

事情没有对错，只是你的选择不同，而我们需要学会的是对自己的选择负责。离开是一种选择，加入是一种选择。

技术何尝不也是做选择？选择什么框架、选择什么工具、使用什么模式等等，而一个工程师的水平，往往表现在他做一个选择的正确性和速度上。

回想过去这十年，基本上在一个项目最多也就3年，然后要么主动要么被动会出现一些调整，轮岗、转岗、组织架构调整等等。这也从侧面反应了互联网行业的变化是很快的，只有『变』才是『不变』的根本。

正如日本建筑鬼才安藤忠雄所说：

一个人真正的幸福并不是待在光明之中。从远处凝望光明，朝它奋力奔去，就在那拼命忘我的时间里，才有人生真正的充实。

然而可能大多数人还在寻找自己的『光明』，也就谈不上朝它奔去了。随着不断有新技术出现，有新的表现形式被大众认可、追捧，而那些都不是自己所擅长的领域，总会不自觉的焦虑起来，而这焦虑，很大部分来源于不甘于平凡。

最近在玩『王者荣耀¹』，英雄有法师、战士、刺客、坦克、射手和辅助几种不同的角色，当然各自擅长的能力都是不同的，游戏中影响最终结果的因素很多，但最大的因素是团队各个英雄的能力搭配和合作默契度，各角色只有发挥自己英雄所擅长的技能，加上团队的配合、互补，才有可能取得胜利。换个角度来看，只有各自发挥自己擅长的能力，加上默契的配合，才是提升团队整体战斗力的关键。而当前我们所处的环境是人人都想做ADC，都不愿意做辅助；而原本愿意做辅助的人，也会受到嘲笑甚至讽刺。结果就是，越来越多的人不愿意做辅助，而想组成一个战斗力更强的团队也将越来越难。

有时会在想，『平凡』有什么不好？特别是看过介绍日本不少在自己领域做了一生的大神，大多都是在一件我们看起来很平常的事情上，不断打磨，不断追求更高标准的过程。这也是『匠人精神』的体现，关注的是怎么做得更好，而不在于这件事是否『平凡』。

平凡与否，并不在于你做了什么，而在于你做成怎样！

系列文章

腾讯的一款对战游戏（http://pvp.qq.com） ↩

答前端早读课专访的提问

Ghostzhang — 2015-12-29 22:12:28

答前端早读课专访的提问

由 Ghostzhang 发表于 2015-12-29

首先感谢情封的礼物。看了之前专访里同学们的评论，有些问题在文中已经有提到了，有些是我博客里已经写过的，有兴趣的同学可以到CSS森林（https://www.cssforest.org）看看。这里回答下最多人点赞的两个问题：

Baokun Wang 很好的访谈，我有个问题要请教@Ghostzhang: 在带团队以后往往会各种杂事缠身，时间和精力都会不够用，请问这种情况下如何保持技术敏感性？谢谢！

这个问题的确会是比较棘手，一般这个时候我们会推荐去学习『时间管理』和『问题分析与解决』，简单的说就是『学会处理轻重缓急』，其中最重要的就是要把重心放在处理『重要不紧急』的事务上，在它变成『重要紧急』之前。

会提这个问题，说明已经对技术并不那么敏感，甚至感觉跟不上技术的发展心里开始焦虑。不过这个问题真的是很重要吗？从个人的角度来看技术，了解新技术意味着有更大的机会，但对于团队来说，新技术意味着更大的风险，除非遇到不得不解决的问题，一般情况下是不会随便应用新技术的。因此关键在于如果你已经是一个Leader，那你对于技术的关注点就应该是这个技术是否能为团队带来突破口或解决团队的问题。于是，你团队的问题是什么？也许并不是通过技术能解决的。

Z皓我是一名大二的学生，专业是web应用软件开发。从大一第二个学期就开始决定以后成为一名前段工程师，但是学习了一年多的时间，发现进步的并没有想象中那么大，并且平时在训练的时候会经常犯很多错误。在这里我想知道如何打下坚实的基础以及如何高效的学习，希望能得到指导@Ghostzhang

早先从事前端工作的同学大都是自学的，计算机或网络专业应该就算是比较接近的了。然而工作中所需要的技能在学校中是比较难获取的，参加工作室、社团之类的途径相对来说会更有用些，如果有机会实习的就更好了。

没有人能不犯错并一直一帆风顺的，正确的对待错误才是一个好的开始，所以最重要还是心态要调整好，有进步就应该感到高兴，低于预期只能说明方法可能没用对，试试换一种方法再来一次就是了。

至于方法高效与否，要看这个方法是否适合你。每个人都有自己的学习方式，如读书、看视频、写DEMO等等，并不是所有人都一样的，比如我的方法就是给自己找一个项目，然后通过做这个项目的过程让自己去接触相关的知识并试着解决问题。在你找到适合自己的方法之前，可以多试试不同的方法，但一定不要觉得对别人有用的就一定对自己有用，如果这个方法你无法坚持（让用感兴趣）下去，那就说明不适合你（当然你得试着让自己提起兴趣）。

回到你的问题『如何打下坚实的基础以及如何高效的学习』，回答就是找到适合你的学习方法，坚持下去。

答前端早读课专访

Ghostzhang — 2015-12-11 17:35:00

答前端早读课专访

由 Ghostzhang 发表于 2015-12-11

关于前端早读课

其实蛮早之前就已经知道并加了前端早读课的官网（http://www.zaoduke.net），可惜一直没有怎么去看。几周前在朋友圈看了别人转发的前端早读课，觉得内容质量蛮高的，于是在群里找到了@情封，关注了前端早读课的公众号，现在基本上每天能看一篇。回想自己也曾经想为行业做点什么，到头来却渐渐找到各种理由，渐行渐远。能坚持下来真不容易，敬这份热情，推荐。

关于这次专访

在关注了前端早读课的公众号之后，@情封找我说要做一次专访，我一听心就虚了，专业上的内容现在跟我的距离还真有点远，自从开始带团队，已经很久没写代码了，这并不是好事，好在并未停止思考。以下是这次的几个问题：

Q：1）自我介绍，网名，在公司所服务的团队，现在负责的项目

A：每次做自我介绍都得经历一次内心的斗争，这是一次自我定义的过程，我是怎样的一个人？我希望别人如何认知我。虽然最后也就是陈述历史，但选择说哪些不说哪些呢？好吧，已经看得出我是个『纠结』的人，现在的网名是Ghostzhang，用了有10年了吧，这也是我在腾讯的ID，目前服务于微信支付设计中心，负责重构前端团队的日常管理。

Q：2）是在什么样的机缘下走进前端的？

A：我2005年毕业，经师兄介绍进入广州一家电脑代理商的设计部做美工，视觉和页面一起做，当前还在用DW画表格布局。虽然也学过美术，但个人的设计水平远没到商业的程度，所以美工的工作做得并不太好，自己也很痛苦。然后就是看到了关于Web标准的内容，直觉这是以后的方向，于是开始关注Web标准，学习CSS布局。然后是写博客，然后就被当时腾讯ISD的总监看到，约了面试，然后就进了腾讯，开始了重构的路。更多的内容在我的博客上有分享，有兴趣可以看这里。

Q：3）这么多年了，你是怎么看待前端？以及在前端深广度上，你是如何考虑的？

A：交互、视觉、重构、前端，这个过程基本上是不能减少的，不同的只是比例。早些年交互、重构不被重视，大家以为不需要，现在回过头去看，这部分的工作还是在做的，只不过没有专门的人独立去支持，更多的可能是产品经理把交互的工作做了，前端把重构的工作做了，甚至把视觉的工作也做了……

经过了这么多年，交互、重构、前端已经比之前得到了前所未有的重视，都有独立的岗位和越来越专业的知识体系，这是好事，也是发展的规律。既然是规律，就会兴极而衰，这『衰』就意味着变革，在以为重构、前端已经找到位置，可以大展拳脚的时候移动端开始兴起，面对一个新的领域，又是一片『未知』和『机会』。这时候除了感叹之外，很多人开始转型，IOS开发、安卓开发等等，java、C#、C++之类的开发语言又重新进入大家的话题里，这也是规律之中的，关于程序语言的兴衰规律。每一周期重新产出新事物，淘汰不合适的旧事物，而随着人对同一领域理解的加深，这个过程只会越来越快。因此，所谓深广度，有时候只是用于『回顾』或者类似这种『经验分享』时的一个谈资。当然深度、广度还是很重要的，对于当前所处的环境中，更深更广意味着有更强的竞争力。说到竞争力……又是一个大话题……

Q：4）在专业技术上，是否遇到过瓶颈？如果有的话，你是如何突破的？

A：专业上的瓶颈，应该就是对JS的学习上吧，到现在都还是半桶水，也许这也跟我对设计感到困难一样，思维的方式决定了学习的效率，俗称『天赋』。但再怎么困难，都只是比较慢而已，试着找到一些自己比较感兴趣的切入点，会是不错的方式。比如我写的几个工具，大部分都是因为我要学JS而发起的，虽然对于JS的学习并没能真的提升多少，但后面写的比起前面写的在代码上已经有所提升，更高效些、更可维护，自己也没以前那么怕面对JS了。

Q：5）有没学习前端的经验，可以分享給前端新人，包括实习生？

A：兴趣爱好很重要，找你喜欢的、感兴趣的东西学，坚持下去。至于是不是前端，已经不是那么重要了。也许到时你要解决的问题是如何保持兴趣。然后，别只是低头做事，时不时停下来想想，多思考是很重要的，就像是打地基，是不能只是一味把土往坑里填，还需要压平，加上其它一些材料才能让它更坚固，才能支撑起更高的建筑物。

Q：6）你现在带团队，在对于新人在团队中如何更快融入团队、怎么学习等有什么建议？

A：这个话题其实也是很虚的，每个团队的环境不同，所需要用到的方法也就不尽相同，最好请教你团队的同学，会更靠谱。就职业化来说，让自己更专业，更高效是不会错的，没有哪个老板会不喜欢能赚钱的员工。这里又引到另一个话题，不只是新人，所有人都会面临的问题就是外部环境不断在变，需要不断去适应，去学习新东西，从这个角度来讲，每个人都是『新人』，《给不同阶段的自己》中有这部分的思考，保持『空杯』、『谦虚』的心态，保持『敬畏』之心，每个阶段都是一个新开始。

希望未来还能有机会拿出技术上的东西跟大家分享，而不是谈『经验』。

冲奶粉有感

Ghostzhang — 2015-11-12 16:38:00

冲奶粉有感

由 Ghostzhang 发表于 2015-11-12 更新于 2021-11-03

做为两个小孩的父亲，冲奶粉这件事前前后后做了好几年，可是这有什么好说的呢？不就是加水加奶粉就完了吗？好吧，为此我搜了一下，早就有这类文章和教程了，比如常见的误区：

奶粉冲调的常见误区

1.用沸水冲婴儿奶粉

从日常习惯来看，成人饮用的奶粉、豆浆粉、果汁粉等产品，常用沸水冲调，这样可以加速粉末溶解的速度。因此很多新手爸妈也主观地认为婴儿奶粉也要用沸水冲。甚至还认为高温可以杀菌，保证宝宝的健康安全。实际上，冲婴儿奶粉一定不能用开水。婴幼儿配方奶粉中含有丰富的蛋白质、脂肪、碳水化合物以及维生素 A、维生素 D 以及钙、铁等微量元素，开水的水温很高，会使奶粉中的乳清蛋白产生凝块，影响孩子的消化吸收。而那些对热不稳定的维生素也会被破坏，特别是添加了免疫活性物质的奶粉，免疫物质的活性也会被破坏。

2.先加奶粉后加水

是最多见的一种错误冲调方法，按照日常习惯，大多数人都会将粉末状的冲剂倒入杯子或碗中，然后用水冲。但是婴儿奶粉不能这样做，正确的冲调次序应是，量取量的温水，按照冲调比例倒入相应量的奶粉。每款奶粉的冲调比例都是特定的，如先加奶粉后加水，仍加到原定刻度，奶就加浓了；而先加水后加奶粉，会涨出一些，但浓度合宜。婴儿吃过浓的奶，胃肠消化能力难以负担，肾脏的排泄能力也难以承受。

3.奶粉冲得太浓

每款配方奶粉都会在包装上标注明确的冲调比例，标注形式多是“N 毫升温水加 n 勺奶粉”，而且要用奶粉本身配备的专用奶粉勺。但很多家长会认为，按标示冲调比例冲的奶粉太稀，宝宝容易饿，就擅自将奶粉冲得很浓。这样的做法最常见的后果是宝宝便秘、上火，严重时会促使幼儿脑部毛细血管破裂，导致出血，最后影响宝宝智力发育。因为奶粉中含有钠离子，需要加足量开水稀释。如果奶粉浓度过高，宝宝饮用后会使血管壁压力增加，最后导致毛细血管破裂出血。

4.用矿泉水冲奶粉

给宝宝冲奶粉的水也有讲究，但有些父母就会太讲究了。他们会选择矿泉水或纯净水去给宝宝冲奶粉，这都是错误的。矿泉水富含矿物质，磷酸盐、磷酸钙过多，而婴儿肠胃消化功能还不健全，长期用矿泉水冲牛奶会引发婴儿消化不良和便秘。纯净水失去了普通自来水的矿物元素，而人从水中对钙吸收率可以到 90% 以上，所以也不宜用来冲奶粉。

5.大力搅拌或摇晃奶瓶

通常给宝宝冲奶粉都是直接用奶瓶冲的，在水中加入正确量取的奶粉量后，为使奶粉溶解更加均匀不结团，我们需要稍微进行摇晃助溶。但很多爸爸会很粗鲁的摇晃奶粉，上下左右前后各个方向摇晃，最后使得奶粉产生很多气泡，宝宝喝了之后就会不断的打嗝。正确摇晃奶瓶的方法是，手握奶瓶中上部，沿同一方向摇晃瓶底，使在水平面上旋转。速度不宜太快，不产生气泡为宜。若产生气泡，应静置至气泡消失才给宝宝饮用。

竟然还有智能冲奶粉机，看看它的广告：

对于刚刚升级宝爸宝妈的人后来说，奶粉喂养估计还真是个难题。冲奶粉一直是一个技术活，不同品牌、不同段数的奶粉，对粉、水比例和冲泡时温度的要求都有差异。知道粉、水配比、温度，每日喂几餐、怎么喂之后要做什么呢？是这样一个 To-do-List：

烧水、冷热水 2:1 混合调温、倒入奶瓶、洗手、打开奶粉罐、舀奶粉、刮平奶勺、在不触碰奶瓶壁的情况下将粉倒入奶瓶、再重复舀奶粉 5 到 6 次（期间你可能会数错勺数或者忘记你数到第几勺了）、摇均匀奶液。这个过程一般会长达则 15min，最短也要 3-4 分钟。

在夜间,这个过程又会变得更加复杂。另外，手动冲奶，浓度和温度的误差都可能对宝宝的健康成长造成不良影响；如果奶液浓度过高，会对宝宝肾脏不好，浓度过低，宝宝会出现营养不良现象；温度过高，会烫到宝宝，破坏奶粉里的营养成分；温度过低，则可能冲不开奶粉。

讲了这么多，无非是想说原本以为很简单的一个冲奶粉的动作，因为食用的对象是宝宝，所以也就多了很多的注意事项。因此，这个行为保证质量是最主要的目标，在这个基础上如何能更快速的完成这一系列的动作呢？

第一步，列出当前的问题

水的部分一般都会准备两份，一份热水和一份凉白开，为了保温，我们会使用保温瓶，在冲的时候先进行热水和冷水的混合得到温水，这里的问题是可能会因为小朋友的哭声而导致紧张，造成多次调整比例，影响效率。

还有是奶粉的部分，勺子和奶瓶口的大小差不多，如果奶粉装太满的话很容易会粘到瓶口或撒出来;另外就是可能数着数着会忘。

第二步，分解行为得到关键点，大致涉及的几个点：

水
- 用什么水
- 水温
- 加多少水
奶粉
- 下多少奶粉
- 什么时候下
- 如何搅拌

第三步，对于关键点明确必须保证的内容：

水
- 用什么水：开水和冷开水
- 水温：75 度左右（开水会破坏奶粉的营养，水温不够又会让奶粉结块而影响吸收，水温太低也容易引起肠胃不适）
- 加多少水：每勺奶粉约 30 毫升水（也可能不是，看奶粉盒上的说明）
奶粉
- 下多少奶粉：每勺奶粉约 30 毫升水（看说明）
- 什么时候下：先加水再加奶粉
- 如何搅拌：注意不要搅出气泡（喝入太多空气容易吐奶，因此喝完奶也要将小朋友抱起来由下往上轻拍背部，帮助多余的空气排出，俗称『打嗝』）

第四步，方法上能否有更优的方案

水的部分，即然保温瓶可以保温，那为什么不能直接装温水呢？这里需要经验的部分就是要看小朋友的喝奶间隔和保温瓶的保温时长。

奶粉的部分，有一个叫『奶粉盒』的东西，一般是为了方便外出的时候可以更快速冲奶粉，可以提前把相应量的奶粉装在『奶粉盒』中（装多少当然得看小朋友能喝多少），用奶粉盒还有个要注意的地方，就是将奶粉倒入奶瓶的时候要快，不然可能会因为水蒸汽使奶粉沾在瓶口上。

最后摇奶粉，最重要的就是力量的把握，以瓶口为支点画圆，注意不要起气泡。

以上基本可以将整个过程缩短到 3 分钟内，然后就看熟练度了。

—— 思维急转弯分隔线 ——

工作中有蛮多时候会遇到类似的情况，如新接手一个项目，可能会处于一种别人觉得很简单但我就是做不好的状态，除了抓紧时间了解之外，接受自己『不知』也是蛮重要的，当然也需要团队其他成员的鼓励和理解。

如果你是团队 leader，那么你更应该关注组员是否处于这种状态之中，也许他正需要你的帮助。

—— 思维急转弯分隔线 ——

从冲奶粉这件事上，我发现其实事情所谓的『简单』，往往只是自以为的，再小的事想要做好都是需要时间沉淀的，因此我也会经常提醒自己，不要随便说别人的工作容易，尊重别人的工作。

另一方面，通过对过程的优化，是有可能提高效率又保证到质量的。当然可能有人会挑战过程中靠经验的部分太多，对于新手来说其实帮助并不大，我只想说，只有入了门才有谈经验的可能，先实践下我们再来交流。

提升体验的设计

Ghostzhang — 2015-09-07 01:10:50

提升体验的设计

由 Ghostzhang 发表于 2015-09-07

说了好几年的用户体验，也做了好几年的用户体验，用户体验发展至今，我们知道了什么是用户体验：

用户体验（User Experience，简称UE/UX）是一种纯主观在用户使用产品过程中建立起来的感受。

也知道了一些基本的方法，如 http://goodui.org (翻译版)，又如『一致性原则』等。

但我心里总觉得少了些什么。从网上能看到很多日本的产品设计,比如原研哉的作品，会由心的觉得很赞，特别是在对使用者的使用体验细节上。不过是不是只是一些放在展厅里的作品呢？前段时间去了冲绳旅游，虽然并没有去到日本本岛，但在冲绳已经能感受到日本对人的关注。

比如经常在电梯到层后犹豫着是不是到了我要去的楼层，也许你会说电梯里不是有显示屏吗，有些电梯也会有语音提示。有问题，也有解决方案，也执行了，大家也认可了，但是为什么还是会有这样的感受呢？当我去到冲绳的酒店后我看到了这个的场景：

电梯的楼层提示是在门上的，当时我就有一种『就应该这样』的感触，虽然豪无技术含量，但却真正体现了对人的关注。

同样的例子还表现在餐纸上，冲绳餐馆的纸巾都不是整齐对折的，一开始想不明白为什么要这样，然后当我要去取的时候，我就懂了：

可能你也注意到了，当取纸巾的时候，你的手是不会接触到另一张纸的，也就是说这样更加的卫生。 一个零成本，无技术含量却让人由心觉得赞的创意。为什么我们没想到呢？

之后在香港一家日本餐厅吃饭，发现那家餐厅的纸巾也是不对齐的，本想要赞一下的，可惜他是这样折的：

可以看到店家学到了纸巾的不对齐折，却不理解为什么要这样折，结果就出来了这样一个『然并卵』的设计。为什么学了却做不好呢？

无意间听了周海宏教授的《走进音乐的世界》，主要内容是讲如何欣赏音乐，在最后的部分（115分钟开始），他提到了另一个话题——感性素质对个人生活与社会发展的影响。周教授举了不少的例子，用互联网的话说就是『用户体验』，最有感触的一句话是：

不重视，所以视而不见

周海宏教授在中欧回答音乐教育问题中提到：

我们到底为什么要学琴？我的想法是：通过学琴热爱音乐，通过音乐热爱艺术，通过艺术热爱生活，通过生活体验幸福。

突然有点开悟，行为都只是一个过程，目标是感悟生活、感受幸福。我们目前最缺的是『感性素质』，缺少对『人』的关注。好的『用户体验』不仅仅只是赢得用户的手段，还是影响用户对『美』、对『生活』的关注，提升『感受幸福』的渠道。

我们所从事的互联网行业，相比传统线下的行业有着传播快、用户量大等特点，能接触和影响更多的人。也正因为这样，我们做为传播者，有着更大的责任，提升大众审美能力。

重视美的追求和对自己审美能力的培养，也许是我接下来努力的方向，虽然不一定能做成些什么，但真的应该做些什么。

给不同阶段的自己

Ghostzhang — 2015-07-13 01:10:50

给不同阶段的自己

由 Ghostzhang 发表于 2015-07-13

4 月中的一天(呃~已然是 7 月，惭愧)，在充满各种广告和消息的邮箱中看到了一封特别的邮件。

CSS 森林学长，你好！我和朋友们正建立一个“职业技术入门手册”，来解决应届生缺乏对岗位行业实际了解的问题，帮助在校生们顺利走出象牙塔~ 我是在您的博客上找到了您的联系方式，希望您来分享下一些 IT 方面的心得与建议，是否可以给个机会私聊？当然，如果您比较忙，可以直接参与我们在 GITHUB 上创建的项目：https://github.com/scope-doc/scope ！祝安康~么么哒～ Light Lou

很是羡慕如此有激情的同学，特别是把激情化为行动的。

工作 10 年了，说多不多，说少不少。俗话说三年一个坎，不过以现代人的学习能力，应该差不多两年就到一个坎了。这里说的“坎”，并不是说会有多大的困难，更多是指到了一些瓶颈的时间。博客上也是以两年为单位，分享了这些节点上我的个人经历。

初入社会，前两年，最重要的事情除了找到一份工作之外，就是学会适应周围的环境，体会其中的游戏规则，让自己能生存下来。说到找工作，还是应该找跟自己喜欢、能发展下去的类型，别信学校说的什么“先就业后择业”，所谓“男怕入错行”，“入行”是很重要的，将会影响你往后最少 4 年的人生轨迹，甚至更久。建议心态保持平衡，不眼高手低，通过实践了解自身能力，找到自己喜欢或者善长的事情。

之后两年应渐渐明确自己的发展方向，更系统的进行学习和积累，关注良好习惯的养成，挖掘自己在某一方面的特长。所谓良好的工作习惯，最基本的时间管理是要学会的，关于时间管理的内容，网上有非常多的文章，值得花时间研究下，当然方法也有不少，最主要一点就是找到一个自己能坚持下来的方法。工作上也要从了解“如何做”进一步到“巧做”。

到了第五、六年，基本上也到了一个大周期的瓶颈阶段，会因为很多之前的思考不够深入而迷茫，提高眼界成为主要的任务，也要开始学会自我激励，从以前的关注自身学习成长逐步转变成为帮助团队成长，把自己的知识变成团队的基石。在团队中应该也渐渐成为某一业务的骨干，有机会可以学习专业之外的能力，如项目管理等。顶着新同学专业能力不断拉进的压力，也需要调整好自己的时间和心态，去应对越来越多的工作。方法论的学习也日渐重要，像时间管理、项目管理、沟通表达、PPT 制作等，保持自己的竞争力。这个时间也许也是压力特别大的时间，成家的需求渐渐提上日程，家人、朋友有意无意总会在身边提起小孩、爱人的话题。成家也就意味着有更多的责任，更多必须做事情和必须花的钱。钱从何而来？

第七年第八年，已经渐渐跟不上新知识的更新了，但是以往的经验也渐渐成为竞争力之一。反思成为主要的事情，学习历史并思考未来，也许也会思考关于 30 岁后的生活状态，破除迷茫并更加坚定的走下去。随着视野的提升，也渐渐学会从不同的视角去思考问题，看到原先看不到的事情，开始重新审视自己。不管你愿不愿意，别人都会将你当成是有经验的人，你的能力是否与你的工作年限相匹配，将会是后继竞争力的体现。

讲了那么多，都离不开我个人的属性和观点，对于 90 后的同学来说，80 后的我并没有太多的激情和敢于去闯的勇气。特别是在这个创业最好的时代，插根扁担都能开出花的年代，安份做好一件事变得特别不容易。自己创业也好，与别人合作创业也好，除了技术外，最重要的还是要学会做人。

在朋友圈看到一个故事：

巴菲特每年都会同大学生进行座谈，在一次交流会上，有学生问他：您认为一个人最重要的品质是什么？巴菲特没有正面回答这个问题，而是讲了一个小游戏，名为：买进你同学的 10%。

巴菲特说：现在给你们一个买进你某个同学 10%股份的权利，一直到他的生命结束。你愿意买进哪一个同学余生的 10%？你会选那个最聪明的么？不一定。你会选那个精力最充沛的么？不一定。你会选那个官二代或者富二代么？也不一定。最后的结果是，当你经过仔细思考之后，你可能会选择那个你最有认同感的人，那个有着自己的原则，不是一直追着利益跑的人，那个慷慨，诚实，即使是他自己的主意，也会把功劳分予他人的人。然后你把这些品质写在纸的左边。

现在再给你一个机会，让你卖出某个同学的 10%，你会选择谁？你会选那个成绩最差的人么？不一定。你会选那个穷二代么？也不一定。当你经过仔细思考之后，你可能会选择那个最令人讨厌的人，不光是你讨厌他，其他人也讨厌他，大家都不愿意和他打交道。因为此人不诚实，爱吃独食，喜欢耍阴谋诡计，喜欢一直在背后计算，自己的得失怎样，怎样能够把自己的利益最大化。然后你把这些品质写在那张纸的右边。

当你仔细观察这张纸的两边，你会发现能力强不强并不重要，大家首先最看重的，是你这个人靠不靠谱。

今年终于有机会去了日本冲绳（琉球），虽然冲绳人民并不太承认自己是日本的，但还是受到日本很大的影响，特别是一些生活细节上，当然也有当地环境的因素。在冲绳美军基地边上有一个四层楼高的建筑，用于给民众和游客参观，在四楼可以看到对面的美军基地。在那里有一群特别的人——日本记者，听导游说那些日本记者每天的工作只有一件事，就是一大早就到这里守着，等着对面美军基地出现什么新闻。当然大部分时间只是干等。我当时就在想，如果是我，有没可能做得好这份工作？对于想成为记者的人来说，对新闻事件、对新鲜事物的渴望一定是高于常人的，可在这样一个也许一天、一周、一年甚至几年都不会有大新闻的地方，是一种怎样的心情？对于正处于高速发展中的我们，真是无法想象。但那群日本记者每天都带着自己的装备，在那里等着，还有的在记录着对面机场上时不时起飞或降落的飞机。

对于“生命意义”的理解，还有很长的路要去思考。

给Github-Page加上代码展示

Ghostzhang — 2015-04-22 22:33:19

给Github-Page加上代码展示

由 Ghostzhang 发表于 2015-04-22

博客中常常会需要用到代码展示，在《用Github搭建个人博客》中也介绍了几个可以用于代码展示的站点，不过由于是跨站的服务，可能会由于种种原因访问慢甚至打不开，于是就想找找有没本地实现的方法。自己写一个？No。

在Github上找到Editr这个项目，正好能满足需求，也成功应用到了这里，当然需要一点点技巧。下面就跟大家分享下。

动手前先看看说明，看到安装的部分，下载项目文件，将editr目录放到需要的目录下，这里我放在根目录下（不是所有的文件都是必须的）：

. username.github.com
|---. editr
|    |--- editr.js
|    |--- editr.css
|    |---. items #默认项目目录
|        |--- index.html
|    |---. libs
|        |--- ext.emmet.js
|        |--- parser.coffeescript.js #coffee扩展，不用可以不加载
|        |--- parser.less.js #less扩展，不用可以不加载

要引用的文件还蛮多的，有没办法不要每个页面都加载呢？想到了文件头部的设置，我们可以加一个自定义的属性，像“demo”，做为一个开关，当需要使用的时候将它设置为“true”：

---
demo: true
---

在页面头部加上样式：

{% if page.demo %}
<link rel="stylesheet" href="{{ site.url }}/editr/editr.css">
{% endif %}

在页面底部加上脚本：

{% if page.demo %}
<script src="{{ site.url }}/editr/libs/jquery.min.js"></script>
<script src="//cdn.jsdelivr.net/ace/1.1.01/min/ace.js"></script>
<script src="//cdn.jsdelivr.net/ace/1.1.01/min/ext-emmet.js"></script>
<script src="{{ site.url }}/editr/libs/ext.emmet.js"></script>
{% if page.coffee %}
<script src="{{ site.url }}/editr/libs/parser.coffeescript.js"></script>
{% endif %}
{% if page.less %}
<script src="{{ site.url }}/editr/libs/parser.less.js"></script>
{% endif %}
<script src="{{ site.url }}/editr/editr.js"></script>
<script>
    $('.editr').each(function() {
        new Editr({
            el: this,
            theme: 'clouds'
        });
    });
</script>
{% endif %}

创建一个通用的模块：

{% if page.demo %}
<div class="editr" {% if include.html %}data-files-html="{{ include.html }}"{% endif %} {% if include.css %}data-files-css="{{ include.css }}"{% endif %} {% if include.js %}data-files-js="{{ include.js }}"{% endif %}
{% if include.view %}
    {% case include.view %}
    {% when "h" %}
     data-view="horizontal"
    {% when "v" %}
     data-view="vertical"
    {% when "c" %}
     data-view="cartesian"
    {% else %}
    {% endcase %}
    {% if include.hide %}
     data-hide="{{ include.hide }}"
    {% else %}
     data-hide="all"
    {% endif %}
{% else %}
    {% if include.hide %}
     data-hide="{{ include.hide }}"
    {% elsif include.js == null %}
     data-hide="js"
    {% endif %}
{% endif %}
><span class="none">效果展示</span></div>
{% endif %}

为了方便文件的管理，我们新建一个名为“demo”的目录，并且以文章标题为目录区分不同的示例：

. username.github.com
|---. editr
|---. demo
|        |--- index.html #公共索引文件
|        |---.  关于nth-child的疑惑 #文章标题
|            |--- index.html #空文件，没有的话会报404
|            |--- 1.html
|            |--- 1.css

index.html文件内容如下：

<!DOCTYPE html>
<html lang="en">
<head>
    <title></title>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">
</head>
<body></body>
</html>

把Editr的设置修改为：

<script>
    $('.editr').each(function() {
        new Editr({
            el: this,
            theme: 'clouds',
            path: '{{ site.url }}/demo/{{ page.title }}'
        });
    });
</script>

然后在对应文章中，如《关于nth-child的疑惑》这篇文章，需要展示代码的位置加入如下的代码：

<div class="editr" data-files-html="1.html" data-files-css="1.css"></div>

关于nth-child的疑惑

Ghostzhang — 2015-04-20 23:20:23

关于nth-child的疑惑

由 Ghostzhang 发表于 2015-04-20

今天在CSS森林群有同学问了个问题：

【活跃】ζ”綉;財ヾ nth-child 怎么选前三个【活跃】Davin :nth-child(-n+3) 【吐槽】鬼-CSSForest +4

正好很久没写代码了，也想试试回答下这个问题，于是就搜索了下，于是就找到了 W3School的CSS3 :nth-child() 选择器，看到了这样一个代码：

p:nth-child(-n+3){
	background:#ff0000;
}

效果展示

感觉有点奇怪，我原本以为应该会是前三个段落被选中，像这样：

效果展示

一定是哪里不对了。来看看它的说明：

:nth-child(n) 选择器匹配属于其父元素的第 N 个子元素，不论元素的类型。 n 可以是数字、关键词或公式。

MSN文档对:nth-child的说明：

伪类:nth-clild(an+b)匹配在文档树中前面有an+b-1个兄弟元素的元素，此时n大于或等于0，并且该元素具有父元素。简而言之，该选择器匹配多个位置满足an+b的子元素。

span:nth-child(-n+3) 匹配前三个子元素中的span元素。

注意到一个特点——“具有父元素”，于是我们给这个例子中的<p>加个父元素试试：

效果展示

element:nth-child(an + b) { /*规则*/ }

成功。也就是说nth-child从最大的父元素”body”开始，匹配“an+b”个元素，如果里面包含”element”，则对其应用样式规则。

效果展示

以上，如果你想更可控的应用到“element”元素上，可以试试：

p:nth-of-type(-n+3){
	background:#ff0000;
}

效果展示

最后，在Useful :nth-child Recipes中的例子由于都是使用li，所以很容易就忽略了上面出现的问题，也是提个醒吧。

感谢CSS森林群里热情的同学。

【活跃】Davin 前 3 个不是 -n+3 么？怎么来个 +4 除非有个不一样的在前3个里面【吐槽】鬼-CSSForest http://codepen.io/ghostzhang/pen/dobKaq 【活跃】Davin 你把 h1 去了啊【吐槽】鬼-CSSForest 把它变成子元素就可以了。【活跃】Davin 嗯兄弟元素有不一样的不对了【吐槽】鬼-CSSForest 也就是说(an+b)是直接取元素，而跟伪类前的element无关嗯嗯【吐槽】Aoteman-大白本来就没关系呀 nth-child 不会在乎前面是什么标签【吐槽】鬼-CSSForest 很容易误解啊，p:nth-child(-n+3) 不会理解成前三个p吗？反正我是误解了【吐槽】Aoteman-大白那是你用少了，用多了就知道 nth-child 压根就不在乎前面用的是什么，前面的p 选择就是把p的所有兄弟元素算成一个集合。【吐槽】鬼-CSSForest 学到了【吐槽】鬼-CSSForest 2015/4/20 15:18:59 用li应该不会遇到这个问题，所以也容易被忽略【冒泡】诺兰德怪不得没注意，是这个问题【吐槽】鬼-CSSForest 又一篇blog了~ 【活跃】Davin 理是这么个理但人家说这些元素要有父元素【吐槽】鬼-CSSForest body 哈哈【活跃】Davin 哈哈哈【吐槽】Aoteman-大白元素会有父元素的。因为有body和html 15:21:40 【活跃】Davin you win 【吐槽】Aoteman-大白记得提及我~求在高大上的blog里面露脸

在腾讯的第四个两年

Ghostzhang — 2015-03-25 02:46:20

在腾讯的第四个两年

由 Ghostzhang 发表于 2015-03-25

离上一个两年又过去了两年，这两年经历了项目、团队的大起大落，从精品战略到互联网金融；经历了项目和团队的拆分；整个行业人员的大量流动。移动互联网将行业重新洗了牌。有些思考、有些想法：

团队管理

管理的问题是复杂的，我学到的也只是九牛一毛，很多问题我还无法解决，但在我能力范围内，还是希望能帮助到有兴趣走管理路线的同学，正如我在团队中推崇的互为肩膀，共同成长。

上面是我这几年在重构团队建设上所沉淀的一些东西，相比《关于团队管理的一点思考》里大而虚的观点，显得更明确了些，有相当的部分是这几年实际执行过后总结下来的，不过不同的人效果可能会有差异，不见得都能得到同样的效果。

重构岗位

移动设备的兴起，为互联网移动化带来了前所未有的机会，也让我们感到了深深的危机感。可能对于个人来说是有了更多的机会，从不断冒出的创业团队就可以看出，个人有更多的机会和选择，可以说是猎头行业的春天。但对于团队管理者来说，身边不断有同事出去创业，不断有创业公司到团队中挖人等等，团队的稳定性就受到了很大的冲击，如何维持团队稳定并进一步发展就成了最重要的事情。原有业务的转型，技术的更新，让很多同学感到了不安，看不清未来的发展方向，过去这两年有很多的同行转岗做移动端开发，整个行业给人的感觉是很浮躁。

2014 Webrebuild年会的主题也是在这样的一个大背景下确定的——“初心”。这也是对整个岗位方向的一次思考，在《人生就是一次次的被挑战》中提到了重构要从“设计稿还原”更进一步到“设计理念还原”，那么设计理念是什么呢？

设计理念是设计师在空间作品构思过程中所确立的主导思想，它赋予作品文化内涵和风格特点。好的设计理念至关重要，它不仅是设计的精髓所在，而且能令作品具有个性化、专业化和与众不同的效果。

设计理念还原，重点在于“还原”，前提是“理解”设计理念。因此学习设计相关的知识也成了一个必须的条件，不一定要达到多高的水平，但至少要能明白设计师想做出什么样的效果。设计稿还原我们已经做到了，但那是静态的，跟最终成品还有一定的差距，而设计理念的还原，则要求我们做到为成品负责。

系列文章

《寻找适合重构的理论》——2014年webrebuild年会分享

Ghostzhang — 2014-12-28 14:14:00

《寻找适合重构的理论》——2014年webrebuild年会分享

由 Ghostzhang 发表于 2014-12-28 更新于 2021-12-10

从《革命》、《蜕化》、《菩提树下》、《重构人生》、《重构七年》、《泰然》、《蜕变》到本届《初心》，每一年的WebRebuild年会都是一次反思，成长的过程。重构这个岗位一路发展过来，每一年都面临着对未来发展的不断探索和思考。在行业快速发展，人心浮动的今天，回归初心，才能更好的面对未来。

有一种爱叫“分离”，那就是父母对孩子的爱。如果把“重构”当成自己的孩子，那么有什么东西是在分离之后还能继续帮助到“孩子”的呢？技术？HTML5、CSS3 当前很火，但是早几年浏览器根本就不支持，谁又知道它们还能火多久呢？想想当初的 ASP，也就一年的时间就被淘汰了。

在创新思维的 TASK 模型中也可以看到，知识是最不重要的能力（相对于通用技能来说）：

知识: 完成事情所需要的知识、经验等，它受时间和空间两个外部因素影响，即如果时间或空间发生了变化，知识将可能不再适用
技能: 如沟通、表达、演讲等能力
态度、心态: 对待事物的心态，一个好的心态会让你面对困难时更加的乐观、坚强
思维: 指思考的角度。正向的思维才会有一个积极的心态

TASK 模型是一个从 T 开始的扇形图，这种扇形模型的含义就是底层的思维发生一点点的改变，上层的 ASK 会产生更大的变化。

因此，我希望能从过往的经验中找到更像理论、可以传承的东西。

《2014年会分享》 from GhostZhang

系列文章

Github的自定义域名设置

Ghostzhang — 2014-11-07 02:25:02

Github的自定义域名设置

由 Ghostzhang 发表于 2014-11-07

还是有很多同学会问到github的自定义域名处理设置的问题，这里再简单分解下阮一峰的《搭建一个免费的，无限流量的Blog—-github Pages和Jekyll入门》中关于域名的部分

第七步，绑定域名。如果你不想用http://username.github.com/jekyll_demo/这个域名，可以换成自己的域名。具体方法是在repo的根目录下面，新建一个名为CNAME的文本文件，里面写入你要绑定的域名，比如example.com或者xxx.example.com。如果绑定的是顶级域名，则DNS要新建一条A记录，指向204.232.175.78。如果绑定的是二级域名，则DNS要新建一条CNAME记录，指向username.github.com（请将username换成你的用户名）。此外，别忘了将_config.yml文件中的baseurl改成根目录”/”。

举个例子，我的域名设置如下（把下面的“ghostzhang.github.io”替换成你的github page项目名）：

主机记录	记录类型	线路类型	记录值	MX优先级	TTL
@	A	默认	103.245.222.133	-	1800
blog	CNAME	默认	ghostzhang.github.io.	-	3600

记录类型与记录值

如果需要将域名指向另一个域名，再由另一个域名提供ip地址，就需要添加CNAME记录。

A记录：地址记录，用来指定域名的IPv4地址（如：8.8.8.8），如果需要将域名指向一个IP地址，就需要添加A记录。

CNAME记录：填写空间商给您提供的域名，例如：ghostzhang.github.io

TTL

即 Time To Live，缓存的生存时间。指地方dns缓存您域名记录信息的时间，缓存失效后会再次到DNSPod获取记录值。

600（10分钟）：建议正常情况下使用 600。

60（1分钟）：如果您经常修改IP，修改记录一分钟即可生效。长期使用 60，解析速度会略受影响。

3600（1小时）：如果您IP极少变动（一年几次），建议选择 3600，解析速度快。如果要修改IP，提前一天改为 60，即可快速生效。

一开始测试的时候可以把TTL的时间先改小些，确认没问题了再改大。

IP的获取，可以通过下面的方式取得：

windows下按Win+R，输入cmd后回车，在命令行里输入ping ghostzhang.github.io，回车后会看到一个IP，就是它了。
如果是mac，可以在终端输入dig ghostzhang.github.io，同样回车后会看到一个对应的IP地址。

利用桌面做任务管理

Ghostzhang — 2014-10-15 00:54:43

利用桌面做任务管理

由 Ghostzhang 发表于 2014-10-15

看着桌面上大大小小的记事本、便利贴，还是觉得会忘掉什么。强迫症，一定是强迫症。

时间管理讲得最多的就是“四象限”法：

时间“四象限”法是美国的管理学家科维提出的一个时间管理的理论，把工作按照重要和紧急两个不同的程度进行了划分，基本上可以分为四个“象限”：既紧急又重要(如客户投诉、即将到期的任务、财务危机等)、重要但不紧急(如建立人际关系、人员培训、制订防范措施等)、紧急但不重要(如电话铃声、不速之客、部门会议等)、既不紧急也不重要(如上网、闲谈、邮件、写博客等)。

按处理顺序划分：先是既紧急又重要的，接着是重要但不紧急的，再到紧急但不重要的，最后才是既不紧急也不重要的。“四象限”法的关键在于第二和第三类的顺序问题，必须非常小心区分。另外，也要注意划分好第一和第三类事，都是紧急的，分别就在于前者能带来价值，实现某种重要目标，而后者不能。

是啦，看起来很简单，但平时比较少这么去操作，没有足够的空间（脑补：我的桌子很小的）、记的东西太多，没找到适合的方法云云……可能是习惯了使用软件的方式解决问题，于是搜索了下，没想到还真有，像四象限电脑桌面工作法，不过基本上还是靠软件了，其实之前也做过一个叫“MyTime”的air程序，可惜签名过期了，程序运行不了，源文件也找不到了……

想到windows的便签，于是做了这么一个桌面文件，配合Windows自带的便签和桌面图标即可进行最简单的任务管理了。

有同学觉得配色不太喜欢，可以下载PSD版本自己编辑。

关于便签的使用和桌面图标设置，可以参考善用快捷键，玩转Windows 7便签程序和 win7系统桌面图标不能随意摆放怎么办？这两篇文章。

关于专业度的思考

Ghostzhang — 2014-10-11 22:33:44

关于专业度的思考

由 Ghostzhang 发表于 2014-10-11

一直以来，在团队中都经常强调要关注效率和质量的提升，但是近两年会渐渐发现，就算很努力把效率提升了，像制定规范，制定模板，自动化工具建设等等，需求方却并不一定会买单，如果能更快就好了；质量？当所有人都在催进度，打着用户体验的旗子做着 “放大加粗” 的事，并用一次次的“新高”恶心你的时候，有时真会怀疑自己的审美。呃~看来负能量有点多，一不留神就抱怨了。

说回主题，效率和质量的确是日常工作中很需要关注和改善的方向，像什么什么工具啦、什么什么系统啦之类的，相信大家都不陌生，也许你团队的自研项目里就有这个。这两年带了团队，做了几次服务满意度的调查，渐渐会发现效率和质量对满意度的提升并不是很明显，总会有这样那样的问题，于是在想，是不是还有其它的因素在这里面发挥着作用，但现在没发现呢？

这两年也办了不少的证，跑了很多次大大小小的办事处、办证厅。在深圳办证相对于其他地方应该还算是比较方便的，特别这两年互联网的接入，很多信息可以在网上查到，可以网上预约，甚至在网上填写资料，去到之后凭身份证打印签名即可，效率提高了不少。嗯，这是接触过不同地区办证的同学才可能会有的感受，如果只是接触过深圳地区的同学呢？如果多次需要办证，这种感受还会明显吗？显然，虽然流程短了，效率提升了，但还是需要早上6点多去排队，不然根本就轮不到你；还是会遇到资料不全，需要回去重新准备的而白跑的情况。在《服务质量从办证谈起》已经吐过槽了。既然重构也是定位在一个服务支持的岗位，那么在与服务相关的意识与技能是不是也应该包含到工作技能树里呢？我们常说的效率与质量，可以说是直接与专业技术相关，算是硬技能，如果硬技能能达到非常高的水平，那其它的因素可以说已经无关紧要了，但事实上很多的团队并达不到那么高的水平，或者说再高水平的团队，也终会有新人。每个团队都会有自己的硬技能，在硬碰硬之间，还是需要一些软技能来做为缓冲的。

无意间看到了《寿司之神》，被深深的触动了。看起来就是饭跟肉放一起的寿司，竟能做到如此的境界。跟《舌尖上的中国》里丰富的美食相比起来，寿司是简单得不能再简单的食物了，二郎却一做就是75年（2012年上映），单是这份对职业的热爱，就十分让人敬佩。在二郎身上看到了专业职人的特点——热情、专注、坚持、高要求。也带给了我一些思考，把一件简单的事做到不简单，这也许就是专业度上的差别吧。看完会有一种我也要这样的冲动，不过回头一想，明显是不现实的，那从中有什么能学习的呢？而不是感动完就完了。

首先会问的是“我的这份职业是否能做一辈子？”，也许二郎一开始也不知道他会做一辈子，只是单纯的喜欢，想要做到最好，于是就一直做下来了。显然，重构从出现至今，远还没到一辈子的时间，谁也不知道它能存在多久，那是不是就意味着不应该投入更多的精力呢？谁也不知道自己未来会变成什么样子，难道就不活了？不，而且要追求更好的活着。所以问这个问题意义就不那么大了，能不能做一辈子，重点在于你能不能坚持。

坚持也就意味着会面对很多的困难，在困境中才有所谓的坚持。于是，如何面对困难，并让自己走出困境就成了最重要的问题。个人觉得有两点是很重要的：第一是定位，第二是价值。

定位: 确定当前自己（团队）在团队（公司、行业）所处的位置，及所掌握的资源，未来可能的发展方向。
价值: 当前自己（团队）所存在的价值，能做什么，最最重要的是要搞清楚自己（团队）的核心竞争力是什么，如何保持。

说回专业度，很多的工作已经都有人做了，已经越来越少会有创造出一个新工作的机会了，衣食住行。同样的工作，如何做到比别人更赚钱，这是80%的人都会面临的问题。跟以前发挥的空间比较大不同，竟争无可避免，所以谁做得更好、更优质无疑就会得到更多的机会。

个人的专业度，二郎已经做了很好的示范了，热情、专注、坚持、高要求。这里还想提到的一个是团队的专业度，除了解决核心的问题，一些“软技能”也会很好的提升客户的体验，赢得一些口碑。比如“海底捞”，口味、质量其实只能算是中等稍好，但比其它商家最大的不同是海底捞的服务，从你进门那一刻开始，就能体验到的无微不至。而这些不是其中的个别服务员才有的行为，而是整个团队共同的行为。

巧用Markdown语法添加本地文章链接

Ghostzhang — 2014-09-30 17:11:00

巧用Markdown语法添加本地文章链接

由 Ghostzhang 发表于 2014-09-30 更新于 2021-12-06

我喜欢在当前文章中提到以前写过的文章，所以常常会需要找到之前文章的链接再复制进来，很显然，如果链接有变动的话，对我来说就是一个灾难。

因为前段时间已经把博客迁到了[github][https://github.com/]，现在也渐渐习惯用 markdown 格式来写，相关的格式可以看这里，markdown 提供了很多种添加链接的方式，其中有一种是隐式链接标记：

[CSS森林][]

[CSS森林]:http://www.cssforest.org/

在需要链接的地方只需要写名称，具体的链接可以放在文件中任何的位置。于是我们可以把链接集中放到下方，然后在上方需要的位置引用。

只是这样，方便在哪呢？如果用文章列表由程序自动生成呢？哈哈，看看可以怎么做：

1.在_includes目录中新建一个文件links.md

/ username.github.com
    / _includes #如果需要用到页面片可以建这个目录
        |-- links.md

2.在links.md里写入

{% for post in site.posts %}
[{{ post.title }}]:{{ post.url }}
{% endfor %}

3.在需要引用的文件中加入


{% include links.md %}

这样就会在文件中生成一个包含所有文章的隐式链接列表，于是要引用之前文章的时候就很简单啦。同样的方法也可以用于文章中经常出现的外站引用。不过关于友情链接，可以看《使用 Jekyll - Data Files 简介》，用了递归的方法，很赞。我简单改了下，也做成了隐式链接标记：

1.在_includes目录中新建一个文件data_links.md

/ username.github.com
    / _includes #如果需要用到页面片可以建这个目录
        |-- data_links.md

2.在data_links.md里写入

{% for node in include.nodes %}
{% if node.meta == false and node.data %}
{% include data_links.md nodes=node.data %}{% else %}
[{{ node.name }}]:{{ node.url }}
{% endif %}
{% endfor %}

3.在需要引用的文件中加入


{% include data_links.md nodes=site.data.nerd_urls %}

用Github搭建个人博客

Ghostzhang — 2014-09-04 22:30:39

用Github搭建个人博客

由 Ghostzhang 发表于 2014-09-04

上个月26号下午开始，原先博客的服务器宕机了，虽然一直觉得过段时间就会好的，不过一连3天都没恢复，开始有点忍不住了，内容还是好多的，没了多可惜啊，在公司登录不了管理后台，想从数据库把内容搞出来也做不到，如果是文件就好了，哭~~。虽然一直以来对Git¹还停留在使用图形界面软件的程度，但还是想试试用GitHub²怎么折腾出一个博客出来。

搜索了关于github建站的文章后，看了前人各种安装node、ruby等天书般的命令就头大，最后还是选择了相对简单的hexo³，也在win7上成功搭建，教程见最下方。不过hexo的模板修改起来不太容易，看不懂，也就意味着只能用别人做好的theme，对于想要自己定制theme的同学来说，并不太适合。

这时候，[阿成][]同学又出现了，提到另一个方法，就是利用github已支持的jekyll，按要求建目录、文件，然后直接传到github对应的项目中就可以了，github会自动解析模板并显示，此方法优点就是只需要安装git就可以了，模板的自由度高，但缺点也很明显，就是本地无法预览，不过这问题不大。

下面就总结下我使用的方法，希望能帮到有用github搭建个人博客的同学。

站点

先看看阮一峰的《搭建一个免费的，无限流量的Blog—-github Pages和Jekyll入门》，看完对整个站点应该就有了一个大概的认识。如果你跟着他一步步做下来，无意外的话就能看到一个最简单的博客了。

目录结构

/ username.github.com
    / _layouts #框架文件
        |-- default.html
    / _posts #要发布的文章放这里
        |-- 2014-09-02-hello-world.html
    |-- index.html
    |-- _config.yml #配置文件

站点已经建成，好像也没写下去的必要了。可是说好的美肤呢？不急，先来看看相关的语言。

编写文章

Markdown 有多个实现, Github, 以及国内很多社区都是使用 GFM 包括 Python China, Ruby China, SegmentFault 都用了 GFM 语法，有 Node 模块 marked 支持 GFM 的渲染，GFM 和原始 Markdown 的区别可以看轻量级标记语言了解更多。

除了Markdown之外，还可以用Textile语法来写，我原先使用的博客系统Textpattern就是使用这种语法。

编辑器（Sublime Text）

知道编写的格式之后，有以有很多的编辑器可以选择，这里以Sublime Text为例，安装几个相关的插件，也可以把Sublime Text变成一个Markdown的编辑器。

安装插件

先安装传说中的插件管理Package Control，非常简单，进入Sublime Text，按ctrl+~打开控制台，将对应的代码复制进输入框，回车然后等待完成，重启Sublime Text后会在 “Preferences” 菜单下看到 “Package Control”，说明安装成功。

SUBLIME TEXT 2

import urllib2,os,hashlib; h = '7183a2d3e96f11eeadd761d777e62404' + 'e330c659d4bb41d3bdf022e94cab3cd0'; pf = 'Package Control.sublime-package'; ipp = sublime.installed_packages_path(); os.makedirs( ipp ) if not os.path.exists(ipp) else None; urllib2.install_opener( urllib2.build_opener( urllib2.ProxyHandler()) ); by = urllib2.urlopen( 'http://sublime.wbond.net/' + pf.replace(' ', '%20')).read(); dh = hashlib.sha256(by).hexdigest(); open( os.path.join( ipp, pf), 'wb' ).write(by) if dh == h else None; print('Error validating download (got %s instead of %s), please try manual install' % (dh, h) if dh != h else 'Please restart Sublime Text to finish installation')

SUBLIME TEXT 3

import urllib.request,os,hashlib; h = '7183a2d3e96f11eeadd761d777e62404' + 'e330c659d4bb41d3bdf022e94cab3cd0'; pf = 'Package Control.sublime-package'; ipp = sublime.installed_packages_path(); urllib.request.install_opener( urllib.request.build_opener( urllib.request.ProxyHandler()) ); by = urllib.request.urlopen( 'http://sublime.wbond.net/' + pf.replace(' ', '%20')).read(); dh = hashlib.sha256(by).hexdigest(); print('Error validating download (got %s instead of %s), please try manual install' % (dh, h)) if dh != h else open(os.path.join( ipp, pf), 'wb' ).write(by)

然后就可以通过Package Control来安装下面的插件了，按ctrl+shift+p，找到 “Package Control: Install Package”，然后在搜索里输入插件名，回车即可，安装完成后不需求重启即可使用。

Markdown Editing
SublimeTmpl
Markdown Preview

设置

Sublime Text

修改保存文件时的默认后缀形式

新建一个空白文件，设置文件类型为 “Syntax - Markdown”
然后 “Preferences > Setting - more > Syntax Specific - User” 会打开 “Markdown.sublime-settings”，然后将下面的内容保存（文件名应该是：Packages/User/Markdown.sublime-settings）

{
  "extensions": [ "md" ] 
}

Markdown Editing

在 “Preferences > Package Settings > Markdown Editing > Markdown GFM Settings - User” 里可以修改Makdown Editing的编辑界面和输出格式等等。

SublimeTmpl

在 “Packages/User/SublimeTmpl/templates/” 下增加一个模版文件：

|-- Packages
    |-- User
        |-- SublimeTmpl
            |-- templates
                |-- markdown.tmpl

内容如下：

---
layout: article
title: ${1:文章标题}
date: ${date}
tags: $2
---

# {{ page.title }}

$0

然后在 “Preferences > Package Settings > SublimeTmpl > Settings - Menu” 里加上

[
    {
        "id": "file",
        "children":
        [
            {
                "caption": "New File (SublimeTmpl)",
                "children":
                [
                    {
                        "caption": "Markdown",
                        "command": "sublime_tmpl",
                        "args": {
                            "type": "markdown"
                        }
                    },
                    ......

在 “Preferences > Package Settings > SublimeTmpl > Settings - Commands” 里加上

    {
        "caption": "Tmpl: Create Markdown", "command": "sublime_tmpl",
        "args": {"type": "markdown"}
    }

在 “Preferences > Package Settings > SublimeTmpl > Settings - User” 里加上

{
    "markdown": {
        "syntax": "Packages/MarkdownEditing/Markdown.tmLanguage"
    },
    "attr": {
        "author": "Ghostzhang" ,
        "email": "lovej1bz@gmail.com",
        "link": "http://www.cssforest.org"
    }
}

Markdown Preview

修改设置文件 “Preferences > Package Settings > Markdown Preview > Settings - User” ，加入

{
    "enabled_parsers": ["markdown"],
    "github_mode": "gfm",
    "enabled_parsers": ["github"],
    "build_action": "browser"
}

然后在编辑Markdown文件时，按下Ctrl+B即可在本地浏览器进行简单的预览了。

其它Markdown免费编辑器

Windows 平台

Linux 平台

ReText

Mac 平台

在线编辑器

浏览器插件

MaDe (Chrome)

常用git命令

git clone git@github.com:heiniuhaha/heiniuhaha.github.com.git//本地如果无远程代码，先做这步，不然就忽略
cd .ssh/heiniuhaha.github.com//定位到你blog的目录下
git pull origin master //先同步远程文件，后面的参数会自动连接你远程的文件
git status //查看本地自己修改了多少文件
git add .//添加远程不存在的git文件
git commit * -m "what I want told to someone"
git push origin master //更新到远程服务器上

参考文章

Sublime

hexo

Git

Git Linus Torvalds写的分布式版本管理系统，用与管理Linux的开发。 ↩
GitHub 一个提供Git托管服务的网站。 ↩
hexo 一个快速，简单和功能强大的博客，基于node.js。 ↩
可以在菜单 “Preferences > Browse Packages…” 找到目录的位置。 ↩

奇怪的颜色

Ghostzhang — 2014-09-02 17:10:50

奇怪的颜色

由 Ghostzhang 发表于 2014-09-02

<font color="red">这里是红色</font><br />
<font color=\"red">你以为是红色，但却是蓝色</font><br />
<font color=\"red\">既不是红色，也不是蓝色，而是绿色！</font><br />  这是为什么呢

效果展示

昨天一早就收到[阿成][]的消息，说遇到一个很奇怪的问题，如上。

真是非常神奇，只是多了个\，就完全不一样的结果。

经过几组测试后，得出大概规则如下：

计算属性值字符个数，再把所有字符分成3组，不能有余数，如果位数不够就补0， 每组颜色只有前两个字符有效并以十六进制的方式表示 ，非十六进制的字符以0表示。

html linenos red => r,e,d => 0,14,13 \"red" => 00,0e,d0 => 0,14,208 \red\ => 0r,ed,00 => 0,237,00

页面重构中的设计模式

Ghostzhang — 2014-07-02 02:40:06

页面重构中的设计模式

由 Ghostzhang 发表于 2014-07-02

查了下最开始的创建日期，竟然是2011年12月19日，这文章断断续续写了快3年，终于了算比较完整了，但可能相对还是写得有些简单了，看不懂的同学欢迎给我留言，我尽量做补充。

原本是以为写成书的，所以看起来好像是有点那样，不过问了下相关人仕，好像至少也要5W字，而对于我的表达能力来说，硬要凑字数感觉还蛮难的，就不折腾了。

《页面重构中的设计模式》 from GhostZhang

以前写过的系列文章《前言——页面重构中的设计模式》，可以帮助理解，但需要注意的是，因为这期间有些想法上的变法，可能一些细节会不太一样，怎么办？当然以最新的为准咯。

人生就是一次次的被挑战

Ghostzhang — 2014-03-03 01:45:42

人生就是一次次的被挑战

由 Ghostzhang 发表于 2014-03-03

看到题目中的『被』字，有些人脑子里会出现一句话『主动性不足，我们应该要主动去迎接挑战』。可惜你不是什么时候都能清楚的知道挑战是什么。

在微信朋友圈转了个小故事：

小鸡问母鸡：“妈妈，今天可否不用下蛋，带我出去玩啊”？母鸡道：“不行的，我要工作”。 “可你已经下了许多的蛋了”小鸡问。母鸡意味深长的对小鸡说：一天一个蛋，菜刀靠边站，孩子你要记住：存在是因为价值创造，淘汰是因为价值丧失！过去的价值不代表未来的地位，所以每天都要努力！

相信引起了很多人的思考，是的，我们每天都需要产生价值，才不会被淘汰。可就有个朋友回了一句：

如果主人不想吃蛋了呢？

对了，这种感觉就是『被挑战』。作为一只母鸡，除了生蛋还能做什么呢？

参加过通道评审的同学，这种感受应该是最能体会的。也许这群母鸡里有那么几只一天能生两只蛋，那么这几只会成为高级母鸡，它们不单需要每天生两只蛋，还要发挥影响力，让更多的母鸡也能生出两只蛋。在下一次晋升的时候，评委就会问，『你上次晋升是因为每天能生两个蛋，这次有什么不同的吗？』『我总结出了如何生出两个蛋的方法论，并给其它母鸡学习，成功培养了3只会生两只蛋的母鸡。』……可是，再下一次晋升的时候，评委会问，『你除了生蛋，还会什么？』。在评委眼里，通常只是考虑这里是否需要一只母鸡，而不是一只母鸡除了下蛋还能干嘛，于是很多的母鸡就被挑战了。而做为母鸡，除了生蛋，也要微创新，也许以后哪天会出现水果味的蛋，问题是，敢吃吗？

开个玩笑。鸡蛋看起来很简单的一个东西，却成就了达芬奇，所以回到专业上，重构除了还原视觉稿，还能干嘛？提高页面性能，把控交互、视觉的还原，兼容多个终端的展现，开发效率工具……这几年发展出来的有好多，甚至感觉原先一直在讲的『视觉稿还原』已经不足以说明重构的工作内容，现在我们有一个更高的要求——设计理念还原。

相信也会有同学跟我一样想问，『设计稿我懂，但设计理念是啥？』（思考中……）

关于团队管理的一点思考

Ghostzhang — 2014-01-20 18:56:48

关于团队管理的一点思考

由 Ghostzhang 发表于 2014-01-20

2013年末，总结下这一年所思所感。

带财付通重构组已经三年，但感觉好像是上周的事一样。回看这三年，自己的成长主要还是在团队管理方面，从一开始的一知半解到现在的若有所思，一点点实践着曾经的想法。团队管理的经验不好做分享，毕竟每个团队的环境不同、成员特点不同，除了用对了方法，还需要用对了人。

『铁打的营盘，流水的兵』，这句话在大约09年开始，就时常会听到，意思大概就是一个如钢铁般的营地，是由一批批如流水般更替的士兵打造出来的。很多时候说这句话会有点伤感，有点『一将功成万骨枯』的感觉，不过渐渐的我有了新的体会，为什么会觉得伤感？因为关注的点不同，之前没有带团队，所以更多的关注到了后半句的『流水的兵』，自己身为一个兵的感慨；而如果把关注点放到前半句『铁打的营盘』时，就完全一个新的思路，而这个『营盘』，其实就是现在的『团队』。

不再伤感『流水的兵』，我开始思考如何打造『铁打的营盘』。虽然关注点放到了『营盘』，但『兵』却是『营盘』真正的基石，所以执行层的关注点还是应该在『兵』身上。于是，我的管理思路大体上就是『营造高效、稳定的成长环境；量化行为结果；沉淀可继承的经验』

营造高效、稳定的成长环境

团队的成长离不开成员的成长，一个稳定的学习环境对于成员的成长有很大的帮助，也有不少的成员是以这样的心态在工作的，特别是还没有太多工作经验的毕业生。满足成员成长的需求，会让团队富有激情。

氛围建设

首先要确定的是，要营造一个怎样的氛围，公平、好学、积极、团结等等，你能想到很多正面的词，都是我们希望团队俱备的，但实际情况下可能并不太容易做到。即要鼓励大家去做，又要提供相对应的环境和机会，比如鼓励团队凝聚力，可以有定期的团建，如每月定期的聚餐；比如鼓励分享，就需要为大家提供分享的舞台；比如鼓励公平，就需要对所有可能引起不公平的行为进行处罚。总之，不能光说不练。

流程建设

工作环境中，大部分是要跟流程打交道的，制作流程、交接流程、发布流程等等各种各样的流程，一个好的流程对于效率的提升是非常明显的。但流程的制定者一般都不完全是流程的受益者，对于基层的执行人员来说，大部分同学都没有权限或没有够的影响力去改变流程，让执行者真正受益。所以这个时候团队的Leader就应该更加的关注流程的优化，为执行人争取更好的工作流程。

量化行为结果

『效率、质量、专业度』是技术团队最关注的三个方面，行为的量化也是为了验证这三个方面的指标是否健康。效率方面主要是对工作计划的执行程度，是否能按计划完成；质量则是在计划时间内，输出物是否符合要求；专业度主要是在主动性和规范化方面的体现。

规范化

要量化行为，就需要有一定的规范，规范的种类也有很多，平时大家关注的大多是在代码规范这块，但其实还有一块的内容需要规范化，那就是行为的规范。行为的规范能体现出团队的专业度，比如你进入一家店，在服务员未开口之前，你可能已经有了一个初步的评价，像是店面干净的程度、店员着装的情况、当你进门时有没有店员马上关注到有客人而做出反应等等，而这些都会形成你对这家店是否可信赖的第一印象。同样，主动热情的跟进需求，是每个需求方都希望看到的，而服务方如果能在代码规范的基础上，提供行为的规范指导，对于团队整体的满意度将会有很大的帮助。可能会觉得太刻意了，但专业与否，不正是因为这些小细节给人的感受吗？其实身边不乏这类案例，比如酒店的服务员，当客人进门时要讲什么，要做什么动作等等，都是有要求的；如电话客服人员，接电话第一句要讲什么，不管客户情绪多大，都必须耐心听完等等。

沉淀可继承的经验

回到『兵』的问题，一个团队的打造，不会是从始至终都是同一群人，会有新人加入，也会有老人离开，这也是为什么称为『流水的兵』。当然这里面也有很大部分是时间的关系，一个团队的成长周期可能比个人的成长周期要长得多，所以可继承的经验对于团队来说就十分的重要了。

工具化、自动化

规范有执行精度的风险，可能中间哪一环关注不够，就会引起一系列的问题，而人的状态是会有波动的，特别是长期处理单一问题时，很容易因为精神疲劳而松懈。自动化工具始终如一的按设置执行，正好可以解决这个问题。把重复的工作交给程序去去完成，把复杂的工作交给工具去完成，即可以提高效率，又减少人为的因素引起的规范执行不到位问题。把人放到更多需要创造力的工作上。

文档

除了工具化，文档的沉淀也十分的必要。随着时间的推移，成员的变动等等原因，有一些原本很简单的问题会渐渐变得复杂。可能因为中间某一时间的特殊原因，做了非常规的操作，可能不同的人修改过其中的内容等等，如果没有相关的文档沉淀下来，到后面将没人敢去修改这段代码，即使已经出现问题。

以上是近两年团队管理上的一点思考，执行上的细节这里就不展开了，也没有太多特别的地方，只有两个字『坚持』。

Execl函数中的固定单元格

Ghostzhang — 2013-11-19 22:15:00

Execl函数中的固定单元格

由 Ghostzhang 发表于 2013-11-19

经常用Execl统计一些数据，很好很强大，也很复杂，高级的功能用不上，有几个场景是经常会用到的，比如考勤。

原来没有这篇的，不过今天发现了一个很方便的技巧，其实网上能找到，只是一直不知道有这个功能，也就不知道搜索的关键字。假设原始数据如下表：

	A	B	C
1	人员	休假类型	时间
2	userA	年假	2
3	userB	事假	0.5
4	userA	年假	1.5
2	userA	事假	1

时常会遇到这样的需求，统计对应人的某一个状态的数量。

	A	B	C	D
1	人员	年假	事假	总次数
2	userA
3	userB

这个时候可以使用『COUNTIFS』函数，像这样： =COUNTIFS(检查范围1,条件1,检查范围2,条件2) 比如B2单元格是要统计userA这个人休了多少次年假，可以在B2单元格里这样写：

=COUNTIFS(原始数据!A:A,A1,原始数据!B:B,B1)

这样就完成了一个单元格的定义。问题从这里才开始，填充一个单元格很容易，后面还有很多呢。用过execl的同学应该知道，有个很方便的功能，选中单元格之后右下角会有一个控制点，直接拖动可以快速智能填充，我们来试下，比如拖动填充了B3单元格，内容如下：

=COUNTIFS(原始数据!A:A,A2,原始数据!B:B,B2)

再填充C2单元格，内容如下：

=COUNTIFS(原始数据!B:B,B1,原始数据!C:C,C1)

很明显并不是我们希望的值。我的方法比在execl上改要稍稍高效一点，就是用文本编辑器先写好再复制粘贴到对应的单元格里：

=COUNTIFS(原始数据!A:A,A1,原始数据!B:B,B1) //B2
=COUNTIFS(原始数据!A:A,A2,原始数据!B:B,B1) //B3
=SUM(B2,B3) //B4
=COUNTIFS(原始数据!A:A,A1,原始数据!B:B,C1) //C2
=COUNTIFS(原始数据!A:A,A2,原始数据!B:B,C1) //C3
=SUM(C2,C3) //C4

原本已经觉得很不错了，但还是不太方便，本着一懒到底的精神，甚至有想说写一个小工具。直到今天，在用Numbers的时候，发现它在定义函数的时候可以选『保留行』或『保留列』，可以很方便的把函数中的参数固定:

这样就不会因为自动填充而被改变了，才知道原来可以这样简单，只是因为之前一直不知道。于是又找了下execl下有没类似的东西，结果在mac版的execl下有同样的功能，不过体验差了很多：

windows版的没有找到，但功能是支持的，同样只需要在要保留的行或列前面加上一个美元符号 $ 即可。于是只要这样：

=COUNTIFS(原始数据!$A:$A,$A1,原始数据!$B:$B,B$1)

然后使用自动填充的功能就可以了，简单快捷，再也不用编辑器一个个改了，感激涕零。

自我的价值

Ghostzhang — 2013-10-08 19:10:00

自我的价值

由 Ghostzhang 发表于 2013-10-08

渐渐发现每年的7、8月份就是一年中最忙的时间段，比过年还忙。而且这段时间也总会有一些想法冒出来，可能是因为年会快到了，逼着自己要去想一些东西吧。

看标题又是聊『价值』，已经7年了，还在迷茫吗？人生是一个不断思考的过程，随着年龄和阅历的增长，每一次的思考都可能会引发新的问题或答案。

前不久参加一个论坛，又听到了tony提起2010年的『 30岁以后，还能不能继续写代码？！¹ 』这个话题，突然才发现，对于职业发展这个问题，已经有些时间没有去思考了。自从过到财付通，带团队已经成了日常工作，平时自然也就更多的关注团队管理的问题，对于『技术』的关注度也就没有以前那么高了，那还能算是一个『技术人』吗？好像做『技术』的人都有这种类似的『与非心态』，非0即1。这是个自我定位的问题。

在面对这个问题的时候，最先给自己画的圈是什么？正如原想把标题定为『重构的价值』，就把自己圈在了『重构』这个圈里，同样的『技术人』，就已经是把自己圈在了『技术』这个圈里。而更高一级的思考，是『人的价值』，或者说『自我的价值』！好吧，变成了一个哲学问题。

事实上如果跳不出『技术』，是无法产生更大价值的，很多成就的背后是需要非技术能力的支持，所谓的软技能。『技术』只是一条路，由于个体的差异，所选择的为社会做贡献的一种方式。也就是说，你会觉得迷茫，是因为你没有找到一个自我认可的大目标、大方向，也许结果是一样的，但我们更应该享受过程。

写着写着已经10月了，中间断断续续看了些东西，比如《冲上云宵2》，在第12集里有一幕：

以泰回夏晨家後，发现父母竟然在屋内等自己回来，原来以泰的父母一直反对自己的儿子做飞机维修员，并想以泰投考机师，但是以泰认为成为飞机维修员比驾驶飞机更有成就感，最後不欢而散。

『页面仔』与『维修员』，同样是要求对工作严谨、要有高度的责任感，也同样是做着幕后的工作，需要强烈的自我驱动力及对工作的热爱。

又比如『大黄鸭之父』，鬼才艺术家：弗洛伦泰因·霍夫曼（Florentijn），荷兰艺术家，以在公共空间创作巨大造型物的艺术项目见长。代表作品包括“胖猴子”(2010年在巴西圣保罗展出)、“大黄兔”(2011年在瑞典厄勒布鲁展出)、大黄鸭（Rubber Duck）等。他的作品为人们广泛认知，材料的大众化阻挡不了其作品的宏伟。他的作品使用特定的材料，具有重要的意义，因为用当地的志愿者可以轻而易举收集与雕塑。雕塑材料当地化也是作品的核心。

像胶袋做成的鼻涕虫：

2012年，霍夫曼在法国 angers城 accroche coeurs festival节日里用4000个塑料袋做了两只巨大的蛞蝓－俗称“鼻涕虫“。

还有用拖鞋做成的胖猴子：

《Fat Monkey》上万双人字拖组成的“胖猴子”，仰头栽在巴西圣保罗的公园里

平凡与否，在于你对自己的认知与定位，人无完人，与其花时间在改善缺点，不如把时间用来接受自己、找到自己的优点并努力发挥它，即将不再平凡。

在关于职业化中提到 ↩

关于『教』与『学』

Ghostzhang — 2013-05-21 13:02:00

关于『教』与『学』

由 Ghostzhang 发表于 2013-05-21

最近在学开车，对于一个从没开过车的人来说，进入一个陌生的相对封闭的空间操作一个机器，感觉还是比较困难的。虽然男生对于机器的操作相对比较容易上手，但还是少不了被教练训。在开车这方面，教练无疑是经验丰富的，而且他应该也教了不少的人了，听说以往考试的通过率还不错。那为什么我在学的这个过程中，还是会感到无助，还是会被训呢？啊哈，也许是我不够聪明吧。

对于一个从没接触的人来说，再简单的动作也是困难的。对于汽车，因为不了解开车要注意的事项，所以一开始肯定是很小心的，什么时候要看什么位置，要先做哪一个操作，根本就没有概念。如果一开始就讲理论，可能很多人都会听不进去，所以很多时候教练会选择最直接的方式，比如直角转弯时，当看到车前盖与边线接触时就快速打满方向。至于为什么在这个时候打满方向盘就可以做到直角转变，如果你不问，教练也不会多事告诉你，也许只是他的经验，也许是教练的教练教的。

两三个月前陪小朋友去买了轮滑，门口就有商场请来的教练在教小朋友们滑。从开始的热身运动，我就看教练教一次正确的动作之后，就会讲两三个错误的动作，跟小朋友们强调不能这样做。结果呢？结果就是很多的小朋友学到了错误的动作，正确的动作反而因为看得少，并没有多少小朋友学会。因为他们根本听不懂『错误动作』，在他们看来，教练的动作就是对的，是要学的。

更早的一个例子，冲奶粉。很简单吧，好像是个成年人就不好意思说不会。要用开水还是温水？多少毫升水加多少奶粉？先加水还是先加奶粉？水温到多少可以给BB喝？

同样的问题也有不少。我发现开车让人的视觉感官从新得到了学习，我们在日常生活中已经习惯了寻找各种参照物，通过两眼间的角度判断物体的大小和距离等，但当你在车里，原本习惯的参照物没有了，你要重新学习，从车内看到的不同的位置，来判断车子与车外物体的距离。但有一个重要的问题被忽略了，就是『个体差异』。我明明按着教练说的，看到那条线在车的那个位置时操作车子，可为什么就是得不到正确的结果呢？总被教练说方向盘打慢了，打快了。其实很简单，我个子比教练高，同样是看到那条线在那个位置，可是因为角度不同，实际的距离是不同的。这个时候，『正确示范』就显得很重要了。

所谓『正确示范』，就是一个正确的操作过程和结果示范。在关键的节点让学的人代入，感受正确的环境和方法，至于如何做到这样的正确动作，过程可能会因为个体差异而有所不同，这时教的内容就只是参考了，往往是要在教练教的基础上做一些调整，才能得到正确的结果。

小朋友没有分辨对错的能力，这个时候『教』很重要。而成年人的学习更关注结果，只要能得到正确的结果，条条大路通罗马，因此在『学』的时候，识别出『正确示范』，将会更有效的帮助我们得到所要的结果。

失败是成功之母，因为失败更容易总结出经验教训，但这只能告诉你什么是不对的，即『错误示范』；尊重个体差异，学会从别人的成功中总结，会让你更接近你的成功。

职业倦怠与瓶颈期

Ghostzhang — 2013-04-21 16:22:00

职业倦怠与瓶颈期

由 Ghostzhang 发表于 2013-04-21

在腾讯不知不觉已经7周年了，回想过往的那些年，很感谢我遇到的所有的人，是你们成就了现在的我。之前的经历已经在之前介绍过了，这里也就不再啰嗦。每年总有一段时间，对工作的意义、对未来感到迷茫，同样的一个问题，不同时期的思考总会得到不一样的答案。

刚进公司的时候，我觉得在一个公司能待上3年，对我来说已经很多了，结果3年过去，我还在；我曾经觉得ISD是我最喜欢的部门，我不会离开，结果2年前我离开了；曾经我认为的业内最强的重构团队，现在也已经各分东西；曾经被认为很难沟通同学，如今信起了佛……未来不可预知，所以充满了奇迹。

其实，真正不可预知的是人，『未来』是由人创造的。未来一秒内，你将会接触到什么，而这一秒可能将让你的想法发生发变，从而改变你对下一秒的看法，做出影响下一个一秒的事情，最终成就下下下个一秒。所以，未来也并不是不可预知的，『因』、『果』，成功之人，必有过人之处。

最近有点走低潮，也许是个提醒自己要慢下来的信号，瓶颈期需要停下来整理思路。虽然平时十分不舍，但说不定哪天就要面临从头开始？也许是精神上的，也许是物质上的。好吧，又回到我的唯心论了。

最近听了不少心理学的培训，有关于小孩子教育的，有如何带团队的，有职业发展的等等。发现每个人都是从小就带着伤在成长的，差别只是在于这个过程中对待问题的角度和态度，积极的心态就会有积极的人生。可是既然是人，就免不了会有状态差的时候，气候还分春夏秋冬呢。最重要的是要及时发现自己当前的问题，以积极的方式去打破负循环。

原本是想写『瓶颈期』的，因为去年的一个朋友问我『近来怎样？』的时候，我回答说『瓶颈期』，今年刚好差不多时候又问了我，答案还是一样，『瓶颈期』，突然间觉得这个问题是不是每年差不多的时候都会发生呢？跟那啥一样。正好最近又听了个『职业倦怠与有效干预』的培训，于是又觉得我所处的状态是不是也算是一种『职业倦怠』，只是我把它叫做『瓶颈期』。后来细想之下发现其实『职业倦怠』与『瓶颈期』还是有所差异的。一个是处于消极之中，一个是处于寻求突破。

对个人发展来说，“瓶颈”一般用来形容事业发展中遇到的停滞不前的状态。这个阶段就像瓶子的颈部一样是一个关口，再往上便是出口，但是如果没有找到正确的方向也有可能一直被困在瓶颈处。瓶颈期专指处于瓶颈的这一段时间。

职业倦怠（burnout）是指个体在工作重压下产生的身心疲劳与耗竭的状态。职业倦怠一般包括以下三方面：

情感衰竭

指没有活力，没有工作热情，感到自己的感情处于极度疲劳的状态。它被发现为职业倦怠的核心纬度，并具有最明显的症状表现。

去人格化

指刻意在自身和工作对象间保持距离，对工作对象和环境采取冷漠、忽视的态度，对工作敷衍了事，个人发展停滞，行为怪僻，提出调度申请等。

无力感或低个人成就感

指倾向于消极地评价自己，并伴有工作能力体验和成就体验的下降，认为工作不但不能发挥自身才能，而且是枯燥无味的繁琐事物。

不管是哪一种，都是需要找到能转变当前状态的方法，这也是我觉得应该跟大家分享的。借用培训课上老师的例子：

有一个胖子，一天在路上遇到一个瘦身中心搞活动『7天保证瘦10斤，不瘦不收费』。胖子就想了，反正瘦不下来不用钱，瘦下来正好，可以试试。结果他就进了瘦身中心报名参加了。

第一天上课，胖子正等着教练，从门口进来一个美女，身材火辣，简直就是胖子心目中的『女神』。美女走过来对胖子说：『我在前面跑，你来追我，如果你能追到我，我就是你的~』。胖子一听，还有这种好事？上帝终于开眼了，给我送来个女神。一听到美女说『开始』，就迫不及待的追了上去。追啊~追啊~虽然很累，但胖子还是不愿放弃。眼看还差一点追到美女，『时间到，想追明天继续吧~』，不得了，原来是美女教练。

回去后胖子兴奋极了，做了一夜的美梦。第二天继续追，第三天继续追，七天过去，胖子真的瘦了10斤。

这个过程中，胖子瘦了没？开不开心？

胖子把这消息告诉了他的好朋友，另一个胖子。他的朋友一听，还有这种好事？也想去追美女。来到瘦身中心报名。

第一天一大早就来上课，正满怀期待的等着美女教练的出来，这时门开了，进来一个满脸胡碴的彪形大汉，过来对他说：『你在前面跑，我来追你，如果你被我追上，你就是我的~』。不是吧，给追到那还得了。还没等大汉说开始，胖子的朋友已经撒腿就跑。好不容易到下课时间，胖子的朋友赶紧喊到『时间到了，要追明天再追！！』。

回去后胖子的朋友做了一夜的恶梦。第二天、第三天，七天过去，胖子的朋友也瘦下了10斤。

这个过程中，胖子的朋友瘦了没？开不开心？

同样是瘦身，为什么两个人的心情会差那么多呢？佛洛依德说『人的一生就是一个趋利避害的过程』，要么追美女，要么躲大汉。如果两样都没有，那会怎样？一直胖下去。就会没有动力，人就不会进步。所以真正的问题在于，面对同样的问题，我们要尽量去找出那个『美女』，而躲避『大汉』，这样才能让我们更开心的完成事情。

而面对『职业倦怠』，最重要的是找回『幸福感』。每天重复的工作内容，很容易让人觉得乏味、失去兴趣。而完成一件事是可以有很多种方法的，如果你觉得现在的方法已经不新鲜了，或许你可以想想有没其它的方法可以实现，也许更慢了，也许更快了，变化也会带来乐趣。食物本身的味道可能并不是最好的，大部分的美味还来源于『调味料』的加入，给工作、生活找些『调味料』，像打球、爬山、读书、旅游等等，有句话说得好『生活并不缺少美，只是缺少发现』，比如苹果中的『五角星』，换个角度，生活更美好。

对于各种『宅』来说，外出的难度太大了，并不见得外出这种事真会带来多大的开心。以读书为例，放松大脑只需要换一种思维就行了。如果你语文读累了，只要做点数学题，就会是一个放松。所以，如果写累了页面，可以画画图，如果画累了，可以写写代码，都是不错的选择，最重要的是你觉得放松，喜欢做，每个人的『美女』不尽相同。像我觉得累的时候就喜欢看书，寻找新的想法、观点或者写写小工具，总之就是让自己把当前的问题先放下，调整好后再继续。

『美女』是需要自己去找的，当然也不能等到『大汉』出现再去找，平时就需要多关注自己，有句话叫『怕什么来什么』，自己怕什么事，在它还没发生之前就要先想想如果真的遇上了，有没什么办法可以应对，甚至平时可以做些什么避免它的出现。

写blog也是其中的一个方法，像我写完这篇，基本上也开解了自己，至少情绪没那么低了。共勉。

使用Adobe AIR SDK搭建AIR开发环境（HTML+Javascript）

Ghostzhang — 2013-03-16 00:00:00

使用Adobe AIR SDK搭建AIR开发环境（HTML+Javascript）

由 Ghostzhang 发表于 2013-03-16 更新于 2016-10-13

之前开发 AIR，用的是 Aptana2 + AIR 的插件，界面的操作的确带来很大的方便，不过可惜 Aptana 后来就更新到3了，然后……然后就不支持 AIR 插件了，而且 AIR 插件也不更新了……

还是下载 SDK 自己安装吧，点这里下载。官方的安装说明上写得比较简单：

ADL 和 ADT 工具包含在 AIR SDK 的 bin 文件夹中；请将此文件夹的路径添加到 PATH 环境变量中。

安装SDK

windows

首先把 SDK 解压到你要的目录下，如『C:\AIRSDK』这个目录，右击“我的电脑”图标->属性->高级->环境变量。在界面里找到名为『path』的环境变量（建议先备份下内容），在它的最后面加上 ;C:\AIRSDK\bin （注意前面的『;』是分隔区）。然后按『win+r』，输入 cmd 回车，在命令行中输入 adl ，如果刚才的路径设置正确，命令行会显示 adl 命令的帮助信息。

mac

mac 下的安装可以看这里，原理也是一样的，把 SDK 的安装目录加到系统路径中，然后就可以调用了，简单说明下过程：

首先把SDK解压到你要的目录下，如『/Users/ghostzhang/AIRSDK』这个目录，然后打开终端（/Applications/Utilities/Terminal），如果现在输入 adl 是会显示『-bash: adl: command not found』的，因为找不到这个命令，现在输入下面的命令


export PATH=$PATH:/Users/ghostzhang/AIRSDK/bin

意思就是在系统系统变量 PATH 里加上 SDK 的 bin 目录（多个路径的分隔符是『:』），现在再输入 adl ，如果出现 adl 的帮助信息，说明刚才的设置正确了，否则就需要再检查下路径了。

与 windows 不同的是，通过终端设置的是临时的，重新打开终端后之前的设置都会被重置。解决的方案就是把这个设置写到系统配置文件里，方法可以看上面的那篇文章，这里简单说下过程

~/.profile: 每个用户都可使用该文件输入专用于自己使用的shell信息,当用户登录时,该文件仅仅执行一次!默认情况下,它设置一些环境变量,然后执行用户的.bashrc文件.
~/.bashrc: 该文件包含专用于你的bash shell的bash信息,当登录时以及每次打开新的shell时,该该文件被读取.

在终端输入


cd ~
ls -a

找找看有没『.profile』，如果没有找到，那么需要先创建它


pico .profile

会打开一个编辑器的界面，现在输入『export PATH=$PATH:/Users/ghostzhang/AIRSDK/bin』，然后按『ctrl+x』->『y』->回车，这时再用 ls -a 就能看到『.profile』了。

如果原来就有『.profile』文件，就简单了，直接输入


open -e .profile

然后把『export PATH=$PATH:/Users/ghostzhang/AIRSDK/bin』加到文件里，保存。

做完上面的工作，要么重启下系统，要么运行下面的命令，让刚才的设置生效


..profile

注意文件前的点『.』，到此，AIR的环境就建好了。可以使用 AIR SDK 创建第一个基于 HTML 的 AIR 应用程序了。

2016.10.13更新

更新了macOS到Sierra(10.12)后，发现命令行原先的设置失效了，每次设置后一新开一个窗口就又找不到命令……后来找到这篇¹，提到需要把设置放到~/.bash_profile这个文件中才会生效，上文所说的~/.profile和~/.bashrc设置在Sierra中并没有加载。囧

https://coolestguidesontheplanet.com/add-shell-path-osx/ ↩

在腾讯的第三个两年

Ghostzhang — 2013-02-18 09:01:00

在腾讯的第三个两年

由 Ghostzhang 发表于 2013-02-18

新年伊始，回家过年的时候不可避免的会聊到工作，忍不住又回想了下过去几年，时间真是很快，在TC已经快第7个年头。做了两年的团队管理，感觉自己慢了下来。两年一个周期，成长、沉淀。

新技术一日千里，让原本徘徊的人看到了希望，也让人变得浮躁。已经没有追赶的能力，不是认老，而是很清楚自己能跑多快，超出能力的盲目追赶不但会让自己身心疲惫，效果也不理想。特立独行是要承担更大压力的，很多看上去很平常的事情都会因此产生阻力。

关于工作

从个人到团队，思考的转变，虽然还不是转换的很好，但过程中能实实在在的感觉到自己的变化。团队成员能力的成长，所带来的成就感，并不比自己码出Qzone少多少，特别是团队时常会有一些超出预期的惊喜。

这两年也是在矛盾与尝试中过来的，经验与实现的冲突，有时会让人觉得有很强的“无力感”，明明很显而易见的问题，为什么就这样发生了？！但事实上就是这样发生了，于是渐渐也学会了从实际出发，明白了一口确实吃不成胖子。

经过两年的流程梳理，目前感觉已经是到新的瓶颈了，接下来需要改变下策略，也许应该再回到项目中去“树标杆”，由点带动的方式去进行。

关于技术

模块化的整理了一半，写了近万字的文章，最终因为思路调整，一想到要重改就没心思写了，今年看看能不能改完；学了下PHP，写了个内部系统，用来管理需求的优先级，比较简陋，倒也解决了部分问题；学了下python，写了个sublime text 2的扩展 modeCSS ，还是个半成品，核心功能还没写，关于sublime text 2的扩展开发，后继可以写下基础的部分，网上能找到的中文教程很少，过程中有部分细节没讲清楚，还是遇到不少的麻烦。

关于“道”

去年悟到的：“过程就是结果、结果亦是过程”。如果你关注结果，那么不可错过过程，如果你在乎过程，同样不可忽略结果。

今年还是要继续学学怎么写好PPT，与之前相比有不少进步，对此我还是满意的，从只会堆文字到渐渐能讲故事，还要再简洁，加油！

系列文章

聊聊“精品”

Ghostzhang — 2012-12-31 18:35:00

聊聊“精品”

由 Ghostzhang 发表于 2012-12-31

“聚焦精品”——明年公司最大的关注点，从上到下，无处不在提“精品”。也许是被微信刺激到了，也许是成本不断提升，这些都离得太远了，屁民只关心自己。

一提到“精品”，总会不自觉想到这个产品要怎样怎样“好玩”，界面要很“炫”，体验要很“爽”。很大的程度在于两个字——“感受”，所谓精品就是“给用户带来超出预期使用感受的产品”。在一开始听到这个词，总会直接想到产品，我们平时做的跟产品相关的，也就是多提提需求优化的建议，做为一个技术人，难道要转去做“产品”？很显然回答是“NO”，所以我们要先搞清楚，做为一个技术人，我们追求的“精品”是什么。

一个优秀的产品，必定是从外到里都很强大的。所谓“外”，即是可见的部分，像产品策略、界面效果、交互方式等；而“内”，即是后端代码的支持，像操作流程、处理请求的速度等等代码层的技术支持。举个例子，微信的成功大家有目共睹，但我们更多的只是看到了“外”，一个只有“外”的产品是不可能长久的，而微信这个短时间内就上升到千万级在线的产品，“内”的部分也是很强大的，可以读下这篇《一亿用户增长背后的架构秘密》，只有内外都强大了，才有可能出来一个“精品”，缺一不可。因此不难得出，做为技术人，我们的“精品”即是更健壮的代码，更高的效率。

如果更进一步去看，

解读“精品”

做为技术人，“精品”的精神就是追求更高质量、更高效率，不断的自我超越，更加的“专业”。至于“如何更加的专业”这个话题已经聊过很多了，可以看看之前的文章：

前言——页面重构中的设计模式

Ghostzhang — 2012-11-09 02:56:42

前言——页面重构中的设计模式

由 Ghostzhang 发表于 2012-11-09

前不久开始写《页面重构中的设计模式》，本想着内容应该是蛮多的，可是到约9000字的时候，发现写不下去了，有些内容我觉得很重要，但又不知道怎么说清楚，特别是那些已经“自然而然”的东西，不懂表达啊。

之前在写《[页面重构中的模块化设计][]》系列时就发现，只是讲模块化有点窄了，有些很重要但并不是模块化的内容放不进去，所以才会想说是不是需要一个更大的主题，正好也接触了下设计模式相关的内容，觉得可能会合适吧。

在开始下面的内容之前，可以先了解下我对模块化的理解，不然后面的内容可能会看得云里雾里的：

关于设计模式，以我的理解归纳了一下：

设计模式是被发现而不是被发明的。
设计模式是在解决特定问题时，所独立开发出类似的技术来解决这些问题，它们的共通性即为模式。
设计模式是用来解决一类相关问题的通用技术，而不是解决问题的特解。
设计模式是一种解决问题的思路，而不是解决方案本身。

简单的说，设计模式就是某种或某类问题的通用解决方案。当然说到设计模式，我们可能最先想到的就是“工厂模式”、“观察者模式”等程序上的解决方案，而我们的话题似乎有点不同。

如果你够细心，你会发现现有的理论与我们正在讨论的内容最大的区别在于，程序语言间有很强的共性，都是以一种理论为基础的，既使一个功能的实现使用了不同的程序语言。几乎所有的编程语言都会有“类”、“对象”、“变量”等概念，实现上都是“定义变量，赋值”、“如果符合条件就执行这个代码，不然就执行那个代码”，都有差不多的流程控制“条件判断”、“循环语句”等等。而HTML和CSS并算不上是编程语言，HTML是超文本标记语言，是用于描述网页文档的一种标记语言，而CSS是一种用来表现HTML或XML等文件式样的计算机语言。两者都没有编程序语言所必须具备的流程控制能力，甚至不能定义变量。这也许是页面重构在业内被大多数程序员同学所不屑的根本原因吧，当然对于习惯了编程思维的开发同学来说，CSS还是有一定难度的。

你一定想说，less、sass不就是让CSS可以定义变量了吗？这样算是程序了吧。它们本身是程序，但对于CSS来说，只是写法改变了，本质并没有改变。就像 zencodeing 一样，只是让你的输入更快了，但什么地方要写什么，还是需要我们去思考的。

在很长一段时间里，我都是把HTML和CSS放在一起去考虑的，因为在重构里HTML和CSS就是不可分开的关系，但它们之间有着不同的特性，侧重的点有所不同。HTML强调的是语义化、结构合理性，CSS则更多的偏重于灵活性和表现。它们间甚至可以说在某种程度上是矛盾的。在相当长一段时间里，都在考虑怎样处理好HTML和CSS间的这种矛盾，试图去寻找解释。包括从程序实现上的“模块化”、“面向对象编程”去找解释，虽然有大部分概念能对应上，但还是有一部分概念需要更多的理论支持。

在学习“设计模式”这个概念时，才发现自己其实一直在给自己画圈，总想着要把HTML、CSS给套到开发语言中的模块化里。正因为HTML和CSS并不是编程语言，所以当我们以程序的模块化去套的时候，就会觉得有些别扭。

既然放一起不好理解，那就把它们分开来理解吧。首先是HTML，在WEB标准的三者分离的思想中，HTML应该是划入到内容这一块的，即要传达给用户的实际数据，因此我们在HTML的关注重点在于如何更准确的把内容传达给用户，因为页面是通过终端读取显示的，所以这里要关注的就是终端是否能正确解析。对于大部分的人来说，只要是能看到的，就可以理解了。但对于机器来说，并不存在视觉这一说，举个例子，如果我们把一个文章的标题用p来实现，通过样式把它加粗、放大，让它“看起来”像个标题，但机器还是会把它当成是一个段落，因为机器读取到的是p所代表的含义，而不是视觉上的大小、粗细。

这也说明了标签语义对我们正确传达信息的重要性，但是……HTML中有语义的标签并无法满足到目前我们这个国度的网站需求，各种奇怪的需求让我们有时候坚持使用语义化的标签反而变得很不语义，这是很无奈的，但也是现实的情况。所以你会发现，我们输出的页面中，还是会大量的使用div标签，特别是在布局的标签上。当然，对于能够使用语义化标签的地方，我们还是会优先选择使用语义化标签的。

而对于CSS，则是更偏重于效果的展现，使用视觉的表现让内容更好的传达给用户。相比HTML来说，CSS更加的自由，这是优点，也是缺点。高自由度带来了使用上的便利，同时也带来维护上的困难。也正因为CSS的高自由度让团队中的合作会面临着较高的沟通成本，团队成员越多，成本越高，所以我们需要有一些相关的约定，来帮助我们减少沟通的成本。从这种角度来看，模块化其实就像是类似的规范，用来约束CSS的实现方式，以达到提高代码复用率、减少沟通、快速迭代的目的。

方——2012Webrebuild年会深圳站

Ghostzhang — 2012-09-11 19:23:00

方——2012Webrebuild年会深圳站

由 Ghostzhang 发表于 2012-09-11

离深圳站的年会已经过去两周多了，之后一直就忙着其它的事情，到今天才开始有时间整理下分享的内容。

这次的分享准备的时间有点短，花了一周的时间，不过发现最终还是可以顶得住的，虽然那段时间有些焦虑。还是得学会“处之泰然”吧。

每次年会都是一个思考、总结的时间节点，每年这个时候都会主动或被动的被同一个话题所吸引，即重构的价值在哪？方向在哪？

今年有幸站到了WebRebuild的讲台上，本想讲讲关于“模块化”的东西的，毕竟在这块也前后折腾了不少时间，也有一些总结和想法，不过与本次年会的主题还是不太合的。加上这样的机会其实不多，用来讲技术其实是有点浪费的，短短1小时能讲清楚的东西很少，最终大家可能也就一知半解，并不能有多大的收获。

正好遇上了公司半年一次的PDI，有同学也提到了自己在工作中的困惑，不知道应该做些什么；有同学把自己的定位放得有点虚，自我感觉不错，可是并不容易生成真正的价值；也有同学面对各种需求时不知道如何处理，觉得压力很大，无法泰然，于是也帮我找到了一个主题——《方》。

内容主要分为三部分：

方位：方向、位置

真正的权威来自知识，专注才能有所突破
自我认知，找到你的能力短板
正确定位自己在团体中的位置
别人的成功可以参考，但不可复制

方法

理解和接受自己会犯错误
管理好时间，小需求≠马上做
多角度看问题
提意见时要提建议
计划是一种猜测

方便

拒绝“理所当然”，多做一步，方便他人

《方——webrebuild年会》 from GhostZhang

所谓好的用户体验

Ghostzhang — 2012-07-16 19:20:00

所谓好的用户体验

由 Ghostzhang 发表于 2012-07-16

怎样的用户体验才是好的用户体验呢？工作中时常遇到需求方的挑战，相信你也遇到过这样的情况：你觉得这个地方放上个广告是不合适的，但又找不到理由说服需求方，特别是当她拿出 KPI 的时候。而且结果是这个广告位的确也带来了不少流量，从营销的角度来说，它是有价值的。多少跟做网络营销的 SEO 差不多，只看中短期利益，所有可以提高排名的手段都用上。

好像有点跑题了，这次的思考是：并不是所有关注用户感受的体验就叫做是“好”的用户体验。

从何而来这想法呢？上面的唠叨是一个引子，结果就是＂不能赚钱的交互不是好交互＂，简单的说就是好的交互可以赚钱，可是不好的用户体验也是能赚钱的。举个例子：椅子，大家应该都很熟悉了，从用户的角度来说，当然是坐得舒服是最重要的，椅子就是用来坐的嘛。但是从商家的角度来说，我们需要考虑几个因素，第一个就是成本，这个是直接决定了能给用户提供最佳体验的上限到哪，好的椅子意味着更高的成本；其次是投入产出比，开门做生意，不为赚钱是很少的，投入越多，意味着盈利周期可能越长，周期越长，资金的流动性就越差，也就意味着对抗风险的能力越差；再来是利润最大化，能最少的投入得到最多的利润当然是最理想的。

做为商家，提供什么样的椅子能让利润最大化是很重要的。比如麦当劳，稍微留意下你会发现，麦当劳的椅子并不是很好坐，长时间坐着会让你觉得 PP 不舒服，如果是站在用户的角度，会觉得提供这样的椅子显然用户体验没做好，应该提供更舒适的椅子才对。可是如果从商家的角度来看，做为一个快餐店，最重要的是“快”，人流量要大才能赚钱，如果客人来了就不想走了，那如何让人流动起来呢？只要让客人离开就行了，但又不能用赶的，最好的方式就是让客人自己想离开，而这种椅子的舒适度差不多是一餐饭的时间，再久坐下去就不怎么舒服了，于是就想走了。当然这是对于大部分的人来说，也许就有人喜欢到里面坐一整天。

再回到一开始的场景，由于跟需求方所站的角度不一样，所以产生了一些摩擦，一边只考虑用户体验要好，另一边只考虑这样做能赚钱。很显然最终不管哪边胜利了，另一方都是很不爽的。你也许会说，那让两边沟通好，统一目标不就可以了。是的，道理谁都懂，在实际工作中，每个人都可能只关注到自己，要做到站在他人的角度看问题，可能还需要一段时间的训练。

拒绝一个不合理的需求最好的方法就是提出一个比它合理的方案。对于营销类的产品经理，他们的 KPI 相对来说是比较重的，我们不能只是粗暴的说一句：“这样不好”来拒绝他们，用华仔的话说就是“今时今日，这样的服务态度是不够的。”做为服务支持的团队，我们的客户并不只是最终使用产品的用户，还包括需求方和合作方，所以我们也应该要关注到他们的用户体验。产品经理的目标是完成 KPI，而如果我们只是拒绝而不给其它的方案，就相当于让他们完不成 KPI，显然是会被抵触的，虽然完成这样的一个需求并不一定就真能完成 KPI，但他们很自然就会把责任推到你身上。

不要只关注当前需求的好坏，随时收集数据，为以后的优化做准备。要说服产品经理最好的方法是用数据，但不是所有的东西都是一开始就有数据的，需要不断的尝试、积累。当遇到一个觉得不好的需求，又无法说服产品经理的时候，可能最好的方法就是先实现，然后收集下相关的数据。也许你的想法并不一定是对的，也许以后还会遇到同样的需求。

麦当劳的椅子虽然用户体验不是最好的，但却是这么多年来产品与体验最好的平衡，从而实现利润的最大化。

当你再次遇到这种问题时，就知道如何处之泰然了。（本届年会的主题）

作为资源方的思考

Ghostzhang — 2012-06-08 18:59:00

作为资源方的思考

由 Ghostzhang 发表于 2012-06-08

快两个月没有更新了，这段时间有点忙着“救火”，团队的大伙们辛苦了。虽然明知道现在的环境还有很多的不足，可惜实现情况不会给到足够的时间等着慢慢改善。

本文想讨论下团队管理方面的问题——如何更有效的减少资源的浪费。这里所指的资源，主要是像设计中心这类的，在部门中属于公线支持的团队，通常会包含交互、设计、重构三种类型的资源，有些还会有前端的资源，像财付通设计中心。

作为资源方，资源的数量总是要比需求方少得多，相信很多的同学都有这种感觉，“需求是永远做不完的”，于是会出现“僧多粥少”，几个产品经理抢一个资源的情况。

至于如何“抢资源”，这就跟具体产品经理的素质有直接的关系了。像先提一个小需求占位，然后在做的过程中把真实的需求以优化的方式加入，结果就是评估工作的时候是很小需求，实际做的时候就变成大需求了，如果负责这个需求的同学不懂得主动反馈，这种情况就会不断的发生，最后各种烦躁。还有一种，把领导搬出来，说这个需求是领导关注的，优先级最高，不管怎样一定要支持。最郁闷的一种，就是等到差不多要上线的时间点，再来提紧急需求，这个时候已经没有时间再来讨价还价了。

而通过“抢”这种方式得到的资源，又往往因为产品需求准备不充分，在抢到的时间点上无法提供完整的需求，在需求的确认上花费大量的沟通成本；或因为某些原因无法按时启动，造成资源的浪费。要么就是因为时间不足，结果把还没完成的项目阉割上线，不但质量不能保证，体验也是有缺失的。

理想中的资源方，应该有这样的优势，应该是充满自信的一群人：

掌握主要技术力量，甚至是稀缺技术。
有资源分配的权限。
得到必要的重视及认同。
影响产品质量。

而现实中的资源方，却往往是这样的：

受上游输出质量、时间点影响严重，上游花光了项目时间，总要快到提测的时间点再来加班。
缺少自信心、自我价值感，这个是大环境的原因，岗位知名度低。
缺少项目团队归属感，资源方往往不属于某个项目组，所以在项目组里或多或少会被边缘化。
机器人，大部门同学停留在机械的完成需求，工作中缺少思考。

有环境的因素：需求质量较低，变更多，合作方过于强势，项目进度把控不到位等；也有自身的原因：大多来源于基础能力不过关，效率较低，时间管理欠缺经验，对不合理需求没有抵抗力等等。

因为资源少，所以如何更有效的使用，就显得很重要了，从源头抓起无疑是最好的。举个例子：“需求优先级列表”方案，由需求方的接口人输出，资源方以这个优先级列表做为需求安排的主要排期依据。主要的三条原则：

所有资源分配单位为工作量。
不在优先级列表中的需求不处理。
每个产品组的前三个需求，尽可能的安排到，如果工作量太大，至少安排一个。

同一个资源，可能同时负责了几个产品组的需求，如果以人为单位，很显然有点大了，以工作量为单位，则能更有效的分配。另外两条原则，主要是减少不必要的精力花在优先级不高的需求上及保障基本的公平性。

环境的因素不好改变，不过做为环境的一部分，通过自身的改变，也能影响到大的环境，比如，提高资源组的输出质量把关，通过约束自身来约束上游，好像有种壮士断腕的感觉。应该还有不少的方案，欢迎讨论。

谁来关心用户？

Ghostzhang — 2012-04-13 10:20:00

谁来关心用户？

由 Ghostzhang 发表于 2012-04-13

大家都在提用户体验，那么谁真正关心用户的体验呢？产品经理、交互设计、视觉设计、页面重构还是前端开发？

我们都很想当然的认为用户体验就是交互设计师最最关心，最应该关注的，那么交互设计环节当然就是真正关心用户的体验问题了；前端开发环节是把页面的交互实现的环节，当然也是要很关心用户的体验的。

实际工作中是怎样的呢？大部分的团队都是以产品为主导的，而产品经理关注的是用户数、流量、转化率，很多产品经理都只是借着交互设计这样的一个壳，合理化自己的需求，并没有真正为用户着想的心。虽然交互设计师应当是在体验方面最说得上话的，但一般人数都很少，能影响的只是很小一部分重点的项目、而在铺天盖地的需求面前，就显得很无力了，特别当产品经理以KPI为理由的时候，立场不坚定的交互设计师就会妥协了，进而成为产品经理躲避后继环节在交互上异议的“档箭牌”。加上之后的每一环节对用户体验的关注度、认知度基本都是递减的，结果就可想而知了。

写程序的前端开发同学，普遍对逻辑方面比较关注，较偏理性，喜欢简单的、不是0就是1的世界，对于用户体验这种比较感性的问题，他们是关注起来是比较痛苦的。而且等到开发阶段，时间上也不会允许再去争这些嘴皮上的事，除非实现成本过高。

当然，产品经理有KPI压力，也不能简单的说产品经理就不关心用户体验，只是这种需要长期积累才能看到效果的事情，与短期的利益相比就显得不那么迫切了。就像伐木跟种树一样。

交互设计的出现，最大的意义就是让大家都认识到用户体验的重要性，但改善用户体验却不仅仅只有交互设计师就能做好的，于是我在想，交互设计师真正的意义是不是应该像“传教士”一样，“让更多的人理解、关注用户体验”、“让更多的人懂得相关的方法，真正的提高产品的用户体验”，而不只是为某一个产品画画线框图。

于是，页面重构的意义呢？做为改善用户体验的具体实现者之一，在追求为用户提供使用服务的最佳体验 (关于重构的意义) 的同时，也同样需要让更多的人认识、了解，甚至认同我们所采取的方法。

在产品经理普遍只知道“伐木”的今天，我们更需要站在用户的角度，尽可能多的为用户争取得到更好的体验。

浏览器工作原理浅析

Ghostzhang — 2012-02-08 19:44:00

浏览器工作原理浅析

由 Ghostzhang 发表于 2012-02-08

前段时间 [丸子] 发个篇《关于css通配符性能问题不完全测试》，又一次引起了不少的讨论。也看了下相关的几篇文章，发现大家对通配符的意见与之前有所不同，不再是一面倒的认为它不好，为什么会有这样的变化呢？

相信爱折腾的同学已经做过不少的测试的，也许会发现对于CSS，好像很难得出一个结果，主要是因为CSS的解析并不是在页面渲染的时候，而是渲染之前就解析好了，也就是说，我们在浏览器的测试，都是解析之后的渲染效率问题，而这个问题跟系统当前的资源使用环境有着很大的关系，极不稳定，所以得到的结果也是很不稳定的。我之前也试过测试几次然后取平均的方法，不过得出的结果也是没能分析出什么结论。

在网上找了下浏览器工作原理相关的内容，根据自己的理解简单的整理了下，希望能解开大家对于通配符性能问题的疑惑。

《浏览器工作原理浅析》 from GhostZhang

大致的流程图，可能中间有些理解上的问题或错误，欢迎指正。

从连锁店看专业度的体现

Ghostzhang — 2012-02-02 17:39:00

从连锁店看专业度的体现

由 Ghostzhang 发表于 2012-02-02

这次更新有点迟了，也是刚好遇到年底有点忙，而且也开始想着放松下过过年，嘿嘿。说到过年，就少不了吃。这次过年回家，听说汕头也开了“黄记煌”，想着带爸妈去尝下鲜，于是才有了这篇文章。

这里也不是写软文给“黄记煌”做广告，从它店门口排着的长队就足以说明它生意的火爆，也不在乎我这一点点的曝光度。

先简单讲一下做一个锅的流程：

首先当然是准备好材料了；
先下黄油（块状）；
把切好的菜（小块状）铺在锅底，摊平；
把切好的鱼铺在菜上面；
盖上锅焖10分钟左右；
在鱼上铺上调好的酱料；
再焖5分钟左右；
（如果需要）加其它配菜，焖1分钟左右；
开吃。

常常在讲“细节体现专业”，同样的一个制作流程，为什么深圳的“黄记煌”就要比汕头的“黄记煌”显得更专业呢？对比下细节：

先下黄油（块状）；
- 深圳：开火热锅，放黄油，等稍有点化之后将黄油涂满锅底
- 汕头：开火热锅，放黄油
把切好的菜（小块状）铺在锅底，摊平；
- 深圳：倒入切好的菜，铺平
- 汕头：倒入切好的菜，铺平
把切好的鱼铺在菜上面；
- 深圳：先选较大块的鱼身，从锅周边开始铺，鱼头等较厚的部分放到锅中间
- 汕头：先选较大块的鱼身，从锅中间开始铺，鱼头等部分看哪有空间放哪
盖上锅焖10分钟左右；
- 深圳：10分钟以上
- 汕头：约10分钟
在鱼上铺上调好的酱料；
- 深圳：从四周开始往中间铺
- 汕头：随意铺
再焖5分钟左右；
- 深圳：5分钟左右
- 汕头：约3分钟
（如果需要）加其它配菜，焖1分钟左右；
- 深圳：加配菜，焖1分钟左右
- 汕头：加配菜，焖1分钟左右

不难发现其中的差异，也正是这些小细节，让同是“黄记煌”的焖锅吃出了不同的味道。比如第一步对黄油的处理，由于没有涂满锅底，可能会导致部分菜油不够而不熟；第三步铺鱼的时候，从四周向里铺，能让鱼受热较均匀，鱼头放中间，能得到更多的热量，同时也会比较美观；另外焖的时间长短也很重要，短了可能没熟，长了又会影响口感。

很多时候一个小小的细节，可能就会带给用户一个不好的体验，反过来说，好的体验是由一个个细节组成的，专业不专业，其实就是在细节上差异。

还有一个差异就是排队等候的时候，深圳的“黄记煌”是有提供花生或瓜子的 :P 。

CSS书写顺序

Ghostzhang — 2012-01-16 18:36:00

CSS书写顺序

由 Ghostzhang 发表于 2012-01-16

整理了一下自己写CSS时的顺序，跟大家分享下。

下表顺序为从上到下，从左到右：

display || visibility
list-style : list-style-type || list-style-position || list-style-image
position
top || right || bottom || left
z-index
clear
float

width
max-width || min-width
height
max-height || min-height
overflow || clip
margin : margin-top || margin-right || margin-bottom || margin-left
padding : padding-top || padding-right || padding-bottom || padding-left
outline : outline-color || outline-style || outline-width
border
background : background-color || background-image || background-repeat || background-attachment || background-position

color
font : font-style || font-variant || font-weight || font-size || line-height || font-family
font : caption | icon | menu | message-box | small-caption | status-bar
text-overflow
text-align
text-indent
line-height
white-space
vertical-align
cursor

服务质量从办证谈起

Ghostzhang — 2011-12-12 15:59:00

服务质量从办证谈起

由 Ghostzhang 发表于 2011-12-12

最近在办户口迁移的事，过程就不多说了，虽然我算不上粪青，但还是有那么点气堵在那里，不放不快。。。

相对于我老家，其实深圳的办事效率还是很高的，可为什么还是每个办事的人都心怀不满呢？

不得不说，各办证大厅都有各种应对每天几百人流的方法，像每天只处理一定号数的量（一般都是先到先拿号）然后排期等，再办理的时候如果遇到材料不全，就pass，再去准备。而深圳的处理方式明显更优些，添加了一个材料审核的前置环节，先做一次筛选，只给材料准备完全的人发号，这样每天正式办理的成功率会提高不少。而且对于材料准备不全的人，可以在较短时间内被筛选出来，把机会留给准备好的人，一定程度上也增加了总的处理数。唯一不变的就是还是得一大早就去排除。

仔细去听，大部分的不满还是来致于这个“神奇国度”所特有的制度，自己人都信不过的，提供一个证明，还得用另一个证明去证明这个证明是真的，而开那个证明又得同时提供各种相关的证明、证件，搞不到还得再去证明……总之，都是ZF开出的，连ZF都不信！

虽然很不爽，但同是“服务支持部门”，我们又能从中反省些什么呢？

“态度”，对于提供服务的部门来说，服务态度一定会是被放在第一位的，好的态度可以让客户感受到被尊重、舒适，会愿意拿出更多的耐心。

“持续性”，我们很多时候都会抱怨服务态度不好，自己做为客户，花钱花时间，还要看服务员的脸色，心情一下大坏。对于客户来说，每个人只是几分钟的时间，但对于提供服务的人来说，每天不断的重复着这几分钟里的事情，要持续维持好的态度是很难的，这也是服务的质量问题。同等环境下，谁能更长时间的维持好态度，谁就是能赢得更多的客户。

“为他人着想”，有了好的态度，还要懂得为客户着想。比如排队的时候提供椅子、拿号排队、在需要填写的时候提供笔、用别人能听懂的词等等。站在客户的角度思考，让客户体会到服务者的用心，也会在一定程度上赢得口碑。

反观自己的工作——页面重构，一直都被冠以“没有什么技术含量”的说法，可是同样有那么一群人，热爱着这份工作、这个职业。虽然大家入行的原因各不相同，有因各种原因在原岗位混不下去的；也有想入互联网行业而选择最容易入门的；有喜欢写代码但对程序又不太灵光的……归纳起来，就是“简单”。对于页面重构，有这么一个说法“入门容易，深入难”。“容易”大家都懂了，那么这个“难”，又是难在哪呢？“坚持”！

页面重构的岗位基本上可以划入到“服务支持”的范围里，所以有关于“服务态度、服务质量”的讨论同样适用于页面重构这个岗位。从之前的关于职业化、页面重构工程师修练功略到近期的关于《重构七年》的一点点总结都或多或少提到了“服务态度”的问题。为什么等待的过程最难熬？因为缺少变化，而人对没有变化的东西很快就会失去兴趣。像《关于职业化》中提到的“工作乐趣”的问题，我个人是从“为他人着想”的方面去寻找我的工作乐趣的，包括去开发一些很小的工具，只是为了提高一点点的效率，在不断重复的工作中，这一点点的变化的正是“乐趣”所在。

你找到你工作中的乐趣了吗？

关于《重构七年》的一点点总结

Ghostzhang — 2011-11-22 11:05:00

关于《重构七年》的一点点总结

由 Ghostzhang 发表于 2011-11-22

相对于写文章，我还是更喜欢画思维图，能更快的整理思路，抓到想要表达的东西。当然最重要的还是快，这比起让我写一段话所带来的烦恼要少太多了。（其实就是懒）

借这次WebRebuild年会的主题，给大家带来一个关于《重构七年》的一点点总结的图，共勉。

感谢[小志][]提醒，对图片内存占用的部分做了修改，另外在“交互原则”和“问题处理方法”上也增加了一点内容。

关于重构的意义

Ghostzhang — 2011-10-18 17:18:00

关于重构的意义

由 Ghostzhang 发表于 2011-10-18

最近问到新来的同学一个问题：“重构的意义是什么？”同样的，这个问题其实也是在问我自己。

做了这么久的重构，本不应该“迷茫”的，但我绝不想因为怕丢脸而不去面对这个问题。正如《重构七年》——2011年webrebuild年会里说的，方向还在探索。

回想当年重构之所以能被中国的页面制作者所接受，并在短短几年的时间里得到广泛的传播和应用，其根本的原因就是：重构并不仅仅只是把设计稿制作成网页。很可惜现在学重构的同学，对重构的理解很多还是停留在“重构只是用HTML和CSS做网页”。那么，重构除了把设计稿制作成网页之外，还有什么呢？在HTML5、CSS3横行的今天，有一个词渐渐被遗忘了——“web标准”。

重新翻开 w3cn中关于标准好处的介绍，里面有这么一段：

简单说，网站标准的目的就是：

提供最多利益给最多的网站用户

确保任何网站文挡都能够长期有效

简化代码、降低建设成本

让网站更容易使用，能适应更多不同用户和更多网路设备

当浏览器版本更新，或者出现新的网络交互设备时，确保所有应用能够继续正确执行。

对于网站设计和开发人员来说，遵循网站标准就是使用标准；对于你的网站用户来说，网站标准就是最佳体验。

是的，如果从web标准的角度来说，为用户提供使用服务的最佳体验就是我们的追求，不管你使用的是什么技术。但不是每个人都样样精通的，细分到不同的岗位，重构所能做的，主要有以下几点：

将设计稿尽可能完整的在各浏览器中展现。
为前端开发的同学提供“友好”的静态页面原型。
把控与页面重构相关的页面性能问题，提供解决方案。
规划站点资源文件（主要是样式和图片文件）的文件分布，目录结构等。

当然我们能做的可不只这么多，像多终端、效率工具的开发等等，谁说我们就只会HTML和CSS的？！

还有一点需要关注的，新技术是否就一定会带来好的体验？实践过才有发言权。

《重构七年》——2011年webrebuild年会

Ghostzhang — 2011-08-29 18:57:00

《重构七年》——2011年webrebuild年会

由 Ghostzhang 发表于 2011-08-29

今年的webrebuild年会主题是《重构七年》，一看到这个主题，大概就能猜到是以总结、回顾为主了。

深圳站的年会给了我很多的思考，事实上是在得知主题之前就一直在思考的问题——“方向”。狭义的重构，只是从事HTML+CSS的编写的工作，再深入一点就是如何把HTML和CSS写得更好、如何把图片切得更小，再深入一点就是如何让网页打开速度更快。

对于“转岗”这个问题就像“你是谁？要到哪去？”一样充满了哲学，事实上也让我烦恼了相当长的一段时间，因为我一直不太愿意接受重构去做开发的工作。但是现实又不断的提醒着我，单纯写HTML和CSS是无法让这群人有更大的发展空间的。

nico和emu在年会上都说了，不相信那些什么“虽然现在不写代码，但还会继续走重构的路这样的鬼话……”，的确是不太靠谱！

佛说：“最好的答案就是问题本身”，换句话说就是没有答案。佛又说：“自己悟”。。。。。

我所知道的，就是“问题本身是解决不了问题的，只有找到了突破口，超越了问题，才能找到解决问题的方法”，至于“突破口”在哪，“自己悟”。。。。

是的，方向还需要探索。

在腾讯的又一个两年

Ghostzhang — 2011-07-23 14:58:00

在腾讯的又一个两年

由 Ghostzhang 发表于 2011-07-23

这阵子又到了年中考核的时间，同时也是一个总结回顾的时间，离上次写《在腾讯的两年》已经又过去了两年，今年是我在腾讯的第5个年头了。

因为“种种”原因，09年中离开Qzone去了拍拍学习了近一年，也是我第一次离开ISD（当时拍拍还没合入ISD，现在的ISUX），感受到了一个不一样的团队，执行力很高，比较中国式的氛围。2010年初又回到了ISD，加入了多媒体音乐项目组。2011年初转到了财付通设计中心（TID），大概的经历就是这样了。

时长会在想，很多人都说我技术强，但为什么我总感受不到呢？反而常常因为大家这么说，让我觉得很有压力，我想这也是许多工作了两三年的同学所会遇到的问题，看着新来的同学一个个比自己年轻、技术又好、又有活力，自己虽说工作了几年，却没有什么能让自己充满自信的地方。后来经过蛮长一段时间的调整，才渐渐解开了这个心结。

我一直以“提升页面仔在行业中的地位”为事业，虽然我并不是很充满激情（可能我的性格是很大的原因吧，对任何事都不会表现出特别感兴趣），但这是我一直的以来的方向。那么学技术是为了什么？学会之后是否要教给更多的人，才能达到我的目的呢？是的。那么，有人比我学得更好，我为什么要感到不安呢？因为生活、现实？技术在我手上，难道还怕会没工作？是的，但还是需要学习，因为学到的都是自己的。工作只是以自己能力做为交换的一个途径，以换取支撑生活的开销。

所有人都可能比你强，都有能让你学的地方，包括不好的，而并不是只有比你强的人才有值得学的地方。时常静心体会，你会发现很多地方都有值得学习的点。也许，正是因为每个人都有缺点，这个世界才会如此多彩。想起以前写的一句话“因为缺陷所以完整”。这会时常提醒我不要看不起别人，不要因为问了一个“笨问题”，就想嘲笑他。因为我也常故意问一些“笨问题”。

工作了这么多年，特别是自己有幸能在腾讯这样的大公司里工作这么长时间，给我最大的体会就是光技术强，提升的空间是很有限的。综合能力的提升会比单纯的技术更重要。说到底，本质是要解决问题，其次是正确的解决问题，从技术、从沟通、从关系等等各个方面。有时候差距，并不是很具体的某一个技术点，而在于心态。当你还执着于个人的时候，就无法提升到团队。就跟蛇一样，要长大，就必须褪去束缚自身的那层旧皮。当然最重要的是要认清自己处于哪个阶段，也不是想蜕皮就能蜕皮的。

虽然一直以来都有接触一些团队管理的工作，但完全脱离需求专职做管理的还是从加入TID开始。这半年让我体会到了要做一个好leader所要学习的还有很多很多。我觉得最大的转变是思维上的，也就是决定你从哪个角度去看、去想问题的基础。也许再多点时间，才会有一些拿得出来与大家分享的经验吧，在这一领域，我还只是个新人。

难道就这样转型了？也许吧，现在还时常会想要学一门编程语言，会想起关于模块化的东西。说到模块化，最近才想通为什么我所主张的模块化与大家所理解的模块化有所差异。嗯，关注这一次的webrebuild年会，也许我会有机会分享给大家。

系列文章

重新认识CSS的权重

Ghostzhang — 2011-05-19 19:34:00

重新认识CSS的权重

由 Ghostzhang 发表于 2011-05-19

今天 [大白] 问了一个关于CSS权重的问题：

关于选择器权重的问题。class的权重是10 标签权重是比如说 p span{} 权重是2. 如果11标签自选择器的组合的权重11，会不会覆盖一个class选择器权重10的样式？

在跟他的讨论中，重新整理了我对CSS权重的理解。

在《样式的作用域──页面重构中的模块化设计（一）》中有做过总结，其中提到比较重要的两点：

权值的大小跟选择器的类型和数量有关

样式的优先级跟样式的定义顺序有关

在《继承──页面重构中的模块化设计（三）》的评论中 [operafans] 也提到了

标签选择器的权值永远都比一个类选器择器的权值低，无论有多少个

但一直以来都还是没能想通。

其实规则很简单：比较同一级别的个数，数量多的优先级高，如果相同即比较下一级别的个数，至于各级别的优先级，大家应该已经很清楚了，就是：

important > 内联 > ID > 类 > 标签 | 伪类 | 属性选择 > 伪对象 > 通配符 > 继承

这也就解释了为什么11个标签的定义会比不上1个类的定义，1个类加11个标签会比不上2个类的权重高。

W3CTech第十八期深圳站分享

Ghostzhang — 2011-05-09 18:08:00

W3CTech第十八期深圳站分享

由 Ghostzhang 发表于 2011-05-09

上周六参加了这一次的W3CTech深圳站的交流会，应主持人的邀请，硬着头皮做了个关于浏览器兼容的小分享。PPT分享给大家。

《闲话浏览器兼容》 from GhostZhang

能用并不表示用对了

Ghostzhang — 2011-04-15 19:53:00

能用并不表示用对了

由 Ghostzhang 发表于 2011-04-15

前不久家里买了个九阳豆浆机，每天早上就能喝上自家做的高质量豆浆了。没想到过了一周左右，机子就出现问题了，机头在工作的时候会发现较大的响声。不禁对九阳的广告产生了不好的感觉，并没有以为的质量那么好啊。

看了下豆浆机上的说明，有一行让我很奇怪的说明“不要将机头泡在水中清洗”，心想豆浆不就是液体吗？机头工作的时候不就是泡在水里的，为什么清洗的时候不能泡水里呢？结果过了一段时间后机头坏了，找到维修的师傅才知道是因为机头长时间泡在水里的原因，打完豆浆后得把机头拿起来，不能放在里面泡着。

回想HTML的标签，很多都是比较自由的，但它的出现都会有一定的背景，有它特定的使用场景。了解它们，才能真正的用对它们。能用，并不表示用对了。在这个神奇的环境里，需要我们更多的去讨论、理解标签的语义。

更多讨论：页面重构中的语义化

关注细节的影响

Ghostzhang — 2011-03-01 15:22:00

关注细节的影响

由 Ghostzhang 发表于 2011-03-01

过年的时候发生了件事，虽然时间有点久了，但我还是觉得应该讲一下。这次过年假期的最后几天，鱼鱼很不幸扁桃体发炎，发烧了。吃了一天药无效后决定去医院打吊针，故事就从这里开始。在医院拿了药后准备打针，鱼鱼有点baby肥，血管不太好找，于是最后决定从脚上打进去。

前面两天还算顺利，虽然我不懂打针，但做为一个正常人，护士技术的好坏在心中还是有一些衡量标准的，最好的当然就是“不痛”，至少要做到“不那么痛”才能算合格吧。很幸运前面两天的护士都还算是合格的。第三天的护士是一位比较面生的护士。结果很不幸，在试了几下都没打中血管，鱼鱼实在哭得不行了，最后被换掉，重新找了个有经验的护士过来。

虽然对这名护士不专业的手法很是愤怒，但从她打针过程中的几个细节，引起了我的反思。她让我感到了不安的几个细节：

在准备固定针头的时候，就不小心把用于固定针头的大胶带给贴到一个药盒上，不能用了，原本以为她会重新去拿一块，结果她就这么算了……原本应该至少准备三条胶带的，结果最后只准备了一条。
在开始打针的时候，她做了一个我认为很不专业的动作，将针头上的保护套取下来后，随手就放到了床上。对于在医院工作的人来说，对各种有可能引起病毒传播的细节应该是十分关注的，可就是在医院，她做了这么一个动作。
在将针头插入皮肤后，反复试了几次都没能找到正确的位置，甚至在其中一次还问了一句“怎么没滴”，鱼鱼已经大哭。

想到之前过来面试的一位同学，简历上是写了4年相关工作经验，以我的角度来看，感觉应该是经验比较丰富的，至少我认为应该能称得上是“专业人仕”了。不过很可惜，在提交的面试题中，有些很细节的地方还是没有关注到，比如img标签没加alt、没闭合，甚至标签嵌套错误。类似这些基础问题，是不应该在一个工作了4年的重构人员身上发生的，如果学了这么长的时间，连最基础的东西都还出错，如何能够让领导放心的把东西交到他手上呢？

专业与非专业的差距，更多的时候是体现在对细节的关注度上，其次才是对问题的解决能力。

关于“事业、工作，兴趣”的话题

Ghostzhang — 2011-01-26 15:02:00

关于“事业、工作，兴趣”的话题

由 Ghostzhang 发表于 2011-01-26 更新于 2021-05-08

昨天被问到“你对于事业、工作、兴趣三者间在现在的生活中如何平衡？”

对于“事业”，说实话我并没有很深刻的理解，不过我觉得能被称为“事业”的事，至少不应该以个人的利益为主，而是能影响一定范围的，需要通过一段时间去实现的事。在《在两年前》中，我提到了我的“事业”——“提高页面仔在行业中的地位”，虽然当时并不清晰的认识什么是“事业”。现在看来，“事业”的确是区别于“工作”的，“事业”更像个是一个目标、一个方向。当然前提是这个“事业”无公害，把打家劫宿做为“事业”可不是好事。

“工作”，是让自己和家人能够在这个“钢筋森林”生存下去的一种方法。从进入社会之后，工作将会占用生命中的大部分时间，至少每周40个小时，而大多数人时间会更长。

“兴趣”，我觉得它就像是生活的调剂品。它让生活的色彩不只是单色。

在说如何平衡这个问题之前，我们先到分析下有多少种情况：

“事业”与“工作”或多或少是有关联的，即工作的内容是为了事业的，这类人工作会成为他的乐趣。
“事业”与“工作”没有关联，那么意味着需要用工作之外的时间去完成自己的事业，这类人将兴趣当事业，工作会比较没乐趣。
无“事业”，工作只是工作，如果你的兴趣里有工作的内容，那么工作会比较有趣。

三者无关联，这类人活着只为混日子。

回想了自己的经历，觉得自己一直以来都是很“幸运”的。人生的第一个转折点发生在中考的前一年，那年第一次在同学家看到了电脑，当时看他玩Photoshop（好像是5.0版），感觉十分的新奇。回去之后就跟爸妈说想要买电脑，当然我也知道家里负担不起，所以也没有死缠烂打，只是说了下。之后其实也并没有像一个狂热份子那样时不时去同学家，但对于电脑的向往已经种在了心里。

由于从小学开始英语科没学好，结果中考没考上普高，在报职中的时候，有一个叫“电脑美术设计”的专业，由于在自己为数不多的兴趣中正好有美术和电脑，于是选择了这个专业，结果到高三开始才有电脑课……由于算是美术专业，当时的电脑课主要是教photoshop。靠着自己对PS的喜爱（后来还考了个高级图像制作员证书，可是事实证明，这个证书并没多大的实用性），很快就在班里脱颖而出，后来老师干脆让我帮他教其他同学……-_-……。

第二个转折点是高三的时候。我发现自己在美术上已经达到了一个瓶颈，看着身边的同学一个个画出让人羡慕不已的作品时，自己却有点使不上力的感觉。在高考准备选学校的时候，我做了人生的第二个重大决定，放弃美术方向的专业，改报计算机专业。当时家里人虽然会心疼“浪费”了几年，但也没有过于反对。（很感谢爸妈当时尊重了我的选择。）于是在高考前半个学期，当班里的同学努力背历史（三加一，美术专业要考历史）的时候，我就到计算机班去旁听。（加上平时对于计算机相关的内容的积累。高二的时候我有了我的第一台电脑。）最后如愿考上了广东技术师范学院的计算机专业，大学的几年为我后面在计算机上的学习打下了基础。再后面就是《在两年前》、《在腾讯的两年》里写的了。

基本上读书的时候更多的是根据自己的兴趣去学习、选择专业。因为我相信“行行出状元”，只要自己真正感兴趣，愿意花时间去做，或多或少是可以做出成绩的。一个简单的动作，坚持做上千上万次就不再简单了。工作之后想的更多是如何让重复的工作变得有趣，也许这个过程本身就充满了乐趣，更重要的是这个过程跟“事业”是不冲突的，甚至有所帮助。

“事业、工作，兴趣”三者的关系是相互关联、相互辅助的，找到工作的兴趣，才能找到工作乐趣，以事业做为指引，让自己找到生命的意义。如果你还没找到目标，那么找到你最大的兴趣，将它变成你的事业，成为你工作的牵引。

致初学者

Ghostzhang — 2010-12-22 10:14:00

致初学者

由许未来发表于 2010-12-22

今天一上线，小梅花就跟我说

小梅花 9:47:01
测试火狐我代码改怎么调整现在就是6 . 7 .都正常的
火狐对px的认识和对字体的认识跟6 .7.不一样
对magin-left的认识也不一样

很明显，我对这个徒弟有点不满意。虽然是情有可原，当年带了她两个月，基础本已打好，可是跟着我离开，她回家养孩子，大半年一过，基础全丢了。这篇文章主要是针对她和刀刀的问题做一些警告，这都是初学者容易犯错的地方，所以说是警告。

一、css并不难

真的不难！首先你不要去抱怨有多少种浏览器，css只是一门描述型语言。只有那么点属性，只有那么点排列方式。想一下你都能记住超过3000个汉字的字形、音、写法，这区区几百的数量难不倒你。

然后，端正你的学习态度。

二、笃行

我有个别号叫“沈之”，是取自表字“慎之”的谐音。出自“博学、审问、慎思、明辨、笃行五者，废其一，非学也。”，同样，著名的杂家代表人物龚自珍也说过“纸上读来终觉浅，绝知此事要躬行”。

所谓笃行，是为学的最后阶段，就是既然学有所得，就要努力践履所学，使所学最终有所落实，做到“知行合一”。这里不是在说教，我只是警告你们，要想知道不同浏览器对某个属性的渲染差别，动手测试它；想要知道那个bug什么时候、怎么样、为什么会出现，动手测试它；想要知道css3的新特性有什么好处，动手测试它！

测试，测试，再测试！记住并积累你的测试结果。

换一个更简单的词：“勤学苦练”

三、分离

结构、行为、表现的分离。养成这个良好的习惯。

##四、良好的HTML结构

我敢说，很多人写的页面所遇到的浏览器兼容问题，有80%以上是因为不够好的结构而引发的(当然，不包括特定的已知bug)，如同某个地方扇动翅膀的蝴蝶一样。

良好的HTML结构是你最大的潜在帮助！去年虽然robin让我#$!%#$%!，但是我对他的最大的印象仍然是他严谨的注释。

每一个板块、模块的开始和结束；你分析出来的全局应用；包含文件的始末；分屏位置等。把它们分的清清楚楚才对。

关于模块化多说几句，在开始的时候，你完全不用去考虑怎样节俭代码，哪怕没有任何一点全局性的设置。这样做的好处是有助于提升你的结构，完善你的思路，和养成良好的习惯。在一段时间的践履之后，你自然会拥有节俭代码的能力。

##五、先写HTML

好像跟第4条有点重复，其实我觉得这个很重要。优秀的HTML代码在没有css的时候依然是那么的优雅。

记得有一张gif图，表达的是一个个人博客从html开始增加css的不同变化，顺序就是无css – 基础css(reset) – 布局和模块 – 模块头和尾 – 模块内容。大略就是这样，还分个左右栏，有这张图的同学可以在评论里贴出来让大家温习一下。

基本就这些，首先端正态度，然后勤学苦练，注意一下方式。下面继续废话。

1、关于查错（排除法）

善用firebug之类的开发工具
检查doctpye
检查css文件引用是否正确
检查页面标签闭合情况和css格式是否正确
html和css文件的编码是否一致
同名类、同名ID

或单独保留出错模块后再去查错。提问盒子 http://box.linxz.cn http://code.wanz.im 提问是一门艺术

2、关于工具个人觉得工具只是用来提升你的效率。至于工具能规避一些低级错误的说法，我觉得既然是低级错误就不应该犯。

分享一下我更换输入法的情况：当年是五笔，五笔是拆字，画画的时候刚好在练局部，准备考书法也在温习偏旁，这个时候我看人、写字都是一半一半的，所以改用智能ABC，多年后，觉得无论哪个新的拼音输入法都比我的智能ABC效率高，于是筛选了一下，选择了可以自定义词汇和短语及按键文字的谷歌拼音输入法，是针对智能ABC的习惯，tension肯定知道的，打个“i”，出来的是“一”。大约花了4个多月的时间，才把习惯彻底改过来。这期间犯的错，不计其数。

一定要我推荐工具的话，我推荐记事本！

3、关于重构结构、行为、表现三层次的分离以及优化，行内分工优化，以技术与数据、人文为主导的交互优化等。

4、关于入门首先，你必须有一本（一份）css手册和html手册。

入门书籍推荐李超的《CSS网站布局实录》和[林小志][]的《CSS那些事儿》，一本足矣。

5、时刻了解并熟悉前沿的技术及思想 RT

6、关于类和ID 类(class)如同你的名字，可以有多个，学名，乳名，外号之类；而ID则如同你的身份证号码，只能有一个

多个类、继承的时候需要计算优先级别，可以看属性选择符的优先级。

7、关于命名、语义化命名问题，在你没有适当而完整的想法前，要么参照别人的命名规则；要么，随便命下吧。

语义化，先用在HTML上吧

8、图片简单的gif、png、jpg图片优化，图片合并等。

ps.我自己的博客weilaixu.cn因为备案的问题让我很不爽，所以关闭几天。等哪天太阳把我晒暖和了再去备案

pss.个人观点(weilaixu)，欢迎指正。

psss.一个上午就这么没了。这个编辑器不错，直接写HTML代码，虽然有点懒…

页面重构工程师修练功略

Ghostzhang — 2010-10-19 16:22:00

页面重构工程师修练功略

由 Ghostzhang 发表于 2010-10-19

为CSS森林群（30247792）四周年准备的一份礼物，感谢所有群友一直以来的支持和付出。特别是 along ，做为群里唯一的管理员，辛苦了。

一直以来，我想希望通过自己的分享，能让更多的同行有所收获，特别是有一定基础，已经到瓶颈的同学，找到一个突破口。当然，我本身的阅历还太少，这个希望纯属YY，但有目标至少有做事的方向，我也就自顾自的做下去吧。

说回《页面重构工程师修练功略》，之所以会以这个为题，主要是团队里的新同学给我带来了很多不一样的想法，开始关注到了“专业化”的话题。

分为三个大部分：

为“下游”
为“上游”
为团队、自己

首先，来看看在工作流程中的“上游”和“下游”。做为一个页面重构工程师，我们自身的工作之前在你是一个职业的页面重构工作者吗？和再读《你是一个职业的页面重构工作者吗？》中已经有较多的讨论，但在整个流程中，页面重构工程师又可以做些什么呢？

为“下游”

时常会听到某某在抱怨“上游”如何如何，的确很多看来“额外”的工作量，是由于“上游”产生的，会产生抱怨很正常，人之常情。但静下心来，别忘了我们也有“下游”。做为“上游”，你的输出直接影响了“下游“的工作效率。因此，我们在输出的时候需要更多的为“下游“的工作提供方便。

记得在一个培训课上老师讲到一个例子，当然当时的主题跟我们今天所讲的不同，但例子我觉得蛮有启发的：“在一个电子商务站点中，为了让用户得到更好的体验，交互设计师在用户下单后，设计了一个跟踪发货情况的区域，将货单的各个时间结点显示在上面，包括当前状态等等，很好的体验。结果负责开发的同事看了后就说了，这个功能实现的成本太高了，而且这个物流公司是第三方的，我们拿不到相关的数据…… 最后大家讨论的结果是，改成一个链接，跳到第三方物流公司的订单查询系统上，用户自己去查，页面只提供一个入口。”又比如模拟下拉菜单的效果跟使用系统下拉菜单所需要的工作量是差很多的，可能上游一个很小的改变，就会给下游带来很大的修改量——流程中的“蝴蝶效应”。

从重构的这一环来说，能为“下游”提供的方便主要就是代码方面的内容了，像在代码中添加合理、充分的注释，引导下游更快的找到需要的部件、代码等等；还可以多接触、了解下游的工作，像学习Javascript等的实现方法，以提高我们输出的页面能更容易被实现。

为“上游”

“技术限制”这个词，对于产品和设计的同学，应该是再熟悉不过了，也是很讨厌的一个词，因为总是因为“技术限制”，需要把原本自己很满意的作品进行修改，为下游做妥协。甚至有一段时间团队里还出现“技术限制产品发展”的一场风波，细节不用展开大家也能想像得到。换个角度来看呢？我很喜欢换个角度来看，常听学程序的同学说“只有想不到的，没有实现不了的。”，让我想起阿基米德的“给我一个支点,我将撬起整个地球。”，那么，现实中真能找到这个支点吗？。如果产品一开始就设定得很概念化、理想化，忽略了现实中的环境、条件限制，那么这个产品必定会实现不了或延长期限的。

在要求“上游“的同学学习了解“下游“的工作外，做为“下游”，我们也很应该为“上游”提供一定的培训，让“上游”更加了解我们的工作以及完成工作所需要的帮助。即可减少“上游”输出实际价值不大的内容，做无用功，也能提供更完整的内容。甚至能从我们的角度提供给“上游”提高效率的方法等。

一样，从重构的环节来看，能为“上游”提供的帮助，《网页制作基础》、《网页制作流程》、《Photoshop动作制作》等等内容培训，也许会奇怪为什么PS的动作会在其中，大部分的设计师对程序并不太感冒，虽然我们对设计不在行，但对于程序化的PS动作，掌握起来还是很快的。那么，可以帮助设计师完成某一类动作的制作，帮助提高工作效率，也是不错的方式。

上面是流程中“上、下游”角度的内容，可以概括为一句话： “得到下游的信任，信任你的上游！”。除了上面的内容外，还有一些可以很快提高效率的小Tips：像“发长篇代码、文本时先保存为txt文件”、“确认问题时给肯定的回复”、“提供对方需要的文本时，给可复制的文本”等等。这些场景中，发送方就是“上游”，接收方就是“下游”。能做的还有很多，需要我们多思考。

为团队、为自己

做技术工作的同学都很清楚或将会清楚：技术本身并没有什么乐趣，真正的乐趣来且使用技术解决某一问题或实现某种功能、效果。换个设计师能懂的话就是：“Photoshop本身并没有什么乐趣，真正的乐趣在于使用Photoshop可以实现想要的效果。”从中我明白了一个道理，工作的乐趣是可以自己创造的。乐趣何在？

为你的团队提供更高效的解决方案，在工作中积累、思考，探索更好的规范、流程、工具、方法等等。分享你的解决方案，最好能在团队内形成一定的正向竞争，让你的团队保持活力。

可能很多同学会“没自信”，觉得就算团队里有这样的人，也不会是自己。有什么关系呢？这只是一种方法，让你工作有乐趣的方法。每个人的兴趣点不同，只要是积极向上的，必定会找到乐趣所在。

引用回我很久前的一个签名：“找到工作的兴趣，才能找到工作的乐趣。”

Data URI的利弊

Ghostzhang — 2010-10-16 00:00:00

Data URI的利弊

由 Ghostzhang 发表于 2010-10-16

最近Data URI似乎热了起来，特别是从淘宝UED上发了一篇《Data URI小试 —— 在旺旺点灯(JS)上的应用》后，陆续出现这方面的文章。看到不少人提到Data URL时都只是提到了优点，我也好奇了一把，借这机会更全面了解了下。

说到Data URI的优点，自然少不了“减少链接数”，把图片转为Base64编码，以减少图片的链接数。我们先想当然一下，同样一张图片，如果不用发起一个下载请求，打开速度是会更快的。但是，有几个问题需要关注下：

图片始终是要下载的，那么下载一张图片的速度快还是下载一堆编码快？
浏览器对图片的显示，处理效率哪个更快？
图片的缓存问题

做了几个Demo，我们来看对比下：

多小图的处理对比： Demo1 DataURI ； Demo2 img

单图处理对比： Demo1 DataURI ； Demo2 img

多刷新几次，可以发现，使用Data URI方式的Demo在渲染时会比不使用多消耗53%左右的CPU资源，内存多出4倍左右，耗时平均高出24.6倍。由此可见，使用Data URl方式还是需要更多的考量，在可接受的范围内适量使用。

有关Data URI的介绍可以看下《data URI scheme》和《利用 Data URL 加速你的網頁》，里面提到的IE8以下浏览器不支持的问题，相应的解决方案可以看《MHTML – when you need data: URIs in IE7 and under》，当然使用这种方法的代价就是为了兼容IE6\7，使代码量多出一倍；优点是可以被Cache和Gzip压缩。

在 CSS森林下方使用了另一种兼容IE6\7的方式，有兴趣的同学可以找找。

关于“先扛住，再优化”

Ghostzhang — 2010-09-13 19:00:00

关于“先扛住，再优化”

由 Ghostzhang 发表于 2010-09-13

公司内部有一个系列的培训课——海量服务之道，其中有一个思想，叫“先扛住，再优化”。很不错的思想，对于在一个用户以亿为单位的服务平台里，这个思想有着很重要的作用。

随着这个培训在公司内的推广，越来越多的人对它进行的传播，相信公司外的不少同学也或多或少听过这个思想了。但渐渐的，我发现这个思想有点被滥用了。不分具体情况，一遇到需要花点时间的需求，就退缩了，还给自己一个漂亮的理由：“先扛住”。举个例子：前不久做一个活动，遇到一个在IE下图片重复拉取的问题，初步定位到是因为页面上有一个动态的时间显示，而时间的数字是用图片的，这时开发的同学开始放弃了，因为离提测的时间已经很少了。不断的跟我说，“先用以前的方式实现，以前的没问题，先把这个版本发了，再安排个时间优化”。其实以前估计也是用这个方式实现的，只不过刚好没有触发这个bug。最后，我直接跟他要了实现的脚本，自己定位，最终确定了是由于脚本里用了填充模板再innerHTML进页面的方式去实现，而innerHTML 进去的内容带背景引起的图片重复拉取。所以解决方法就是不使用innerHTML，很快就解决了。前后也不就是花了我半小时不到，为什么开发的同学就不能定下心找原因呢？

我所理解的“先扛住”，并不是简单的先把东西搞出来就算了，而是在当前情况下已经做了80%左右的优化，一些很花时间的优化先保留接口，后期到一定阶段“再优化”。如果一开始没有优化的意识，那么到后面“再优化”的难度将会非常的大。说不定还没到“再优化”的阶段就已经出问题了。

任何一种技术、思想，都是有它适用的环境、条件的，如果不做分析，一味的接受、使用，有时并不会带来正面的效果。希望各位理解了“先扛住，再优化”思想的同学，在传播这个思想的时候，更准确的把它的意思传达清楚，而不只是字面的意思。在学习这个思想的时候，我觉得最重要的还是两个字——“态度”！

谈谈我的“分离”观

Ghostzhang — 2010-08-25 22:39:00

谈谈我的“分离”观

由 Ghostzhang 发表于 2010-08-25

很久没有跟其他人做重构思想方面的交流了，可能大家都觉得不太好意思讨论，特别是“分离”的思想这么基础的话题，拿出来说怕会被“笑话”。做为页面重构中最基础的一个思想，我们有必要清楚的认识它，因此我们需要更多的讨论。正所谓“理越辩越明”。借着这次webrebuild年会上 [焕义][] 提到的“分离”，我也来谈谈我的“分离”观。

一说到重构的“分离”思想，第一个进入脑残里的是“表现、内容、行为”的分离。“表现”指CSS、“内容”指HTML、“行为”指脚本。然后……

在《页面重构中的模块化思维》中我提到了“HTML与CSS的接口”实现，从“接口”可以看出，我们在做页面的时候，把CSS、HTML、脚本等文件独立出来的做法，就是一种“分离”的体现。但只是这样吗？在CSS2.1的时候有这样的认识是正常的，那么CSS3为什么又加入了原本脚本可以实现的动画效果呢？

表现，个人觉得应该包括了像滚动、发光、hover等动画的效果在内，脚本制作的动画效果也应该属于“表现”的范畴；内容，要传达给用户的内容，包括HTML标签；而行为，指由用户触发的由脚本与服务器端的交互，如登录。

举个例子，比如用户登录网站的过程中，当前输入框的边框高亮（表现），将鼠标放到登录按钮上，按钮变亮（表现），点击发送输入的内容（行为），界面出现一个进度条或转动的小圈（表现），登录成功，返回（行为）一个成功提示（内容），绿色图标、文字（表现）。

因此，CSS3中增加的动画效果并不像有些人说的，引起表现与行为的混乱。由于目前浏览器还不能做到支持真正意义上的表现、内容、行为分离，很多时候我们需要使用脚本到完成表现的效果。从这个角度来讲，目前脚本所完成的更多是“表现”的东西，而非“行为”。

CSS模块的注释——页面重构中的模块化设计（六）

Ghostzhang — 2010-07-20 14:07:00

CSS模块的注释——页面重构中的模块化设计（六）

由 Ghostzhang 发表于 2010-07-20

从前面的内容我们已经知道，样式是可以分成各个模块去写的，如何表示各个模块的作用及它们之间的关系呢？CSS的注释是不二的选择。

与普通的注释不同，模块的注释需要一些更详细的内容，比如：功能说明、模块版本、关联信息等等。像《基类、扩展类──页面重构中的模块化设计（五）》中例子的注释，显然是比较简单的。为了减少不必要的沟通，我们可以使用较为固定的格式去完成这个注释。

举个例子：

/**
  * @name   :mode_name
  * @author :ghostzhang
  * @version    :1.0
  * @type   :基类
  * @explain    :Demo
  */
.mode_name{...}
.mode_name h2{
    ...
}
.mode_name .cont{
    ...
}
/* @end **/
/**
  * @name   :mode_name_b
  * @author :ghostzhang
  * @version    :1.0
  * @type   :扩展类
  * @explain    :Demo
  * @dependent  :mode_name
  */
.mode_name_b{...}
.mode_name_b h2{
    ...
}
.mode_name_b .cont{
    ...
}
/* @end **/

从注释中就可以知道mode_name_b和mode_name_a之间的关系。

主要的关键字有：

@name: 标明模块的名称
@author: 标明模块的作者
@version: 标明该模块的版本
@explain: 功能说明
@relating: 标明该关联的模块
@dependent: 标明该所依赖的模块
@type: 标明该模块的类型：公共、基类、扩展类

需要注意的规则：

以“/**”标记模块的开始
从“/*”到第一个“/”作为模块相关信息的说明，包含关键字
关键字以 @ 开头，“:”后开始到“*”的内容为相关的值，即：
@关键字:值*
以“/* @end **/”标记模块的结束
模块注释内不可嵌套

提供了一个小工具（ cssModeCode ）帮助大家填写样式模块的注释。

系列文章

基类、扩展类──页面重构中的模块化设计（五）

Ghostzhang — 2010-06-11 19:24:00

基类、扩展类──页面重构中的模块化设计（五）

由 Ghostzhang 发表于 2010-06-11

基类和扩展类是这个系列的主要内容，上一篇《模块化的核心思想──页面重构中的模块化设计（四）》中只是简单提了一下，我们再深入的来了解下它们。

一般所使用的“模块化”的方法，就是以某一个类做为定义的开始，比如：

/* S 图片列表 */
.pic_lists li,
.pic_lists li img{float:left;width:122px;height:122px;margin-bottom:8px;}
.pic_lists li{list-style:none;margin:0 0 0 6px;text-align:center;}
.pic_lists li .pic{display:block;border:1px solid #476081;}
/* E 图片列表 */
/* S mtv列表 */
.mtv_lists{width:930px;height:130px;}
.mtv_lists li,
.mtv_lists li img{float:left;width:120px;margin-bottom:8px;}
.mtv_lists li{list-style:none;margin:0 10px 0 0;text-align:center;}
.mtv_lists li img{height:90px;border:1px solid #476081;}
.mtv_lists li .pic{display:block;width:120px;height:90px;margin-bottom:8px;}
/* E mtv列表 */

这个例子：两个列表模块。

效果展示

这种方式是比较常见的，可以很好的将一个模块独立出来。如果使用新学习到的“方法”来写这两个列表模块，应该是怎样？

基类: （基础样式）模块的基础表现。包含了模块中大部分的状态。

也就是说，当出现多个类似的模块时，基类包含了这些模块的大部分的效果（或者理解为公共的部分），在基类的基础上，我们可以通过添加很少的代码——扩展类，来达到所需要要效果。像这样：

/* S 列表 基类 */
.mode_lists li,
.mode_lists li img{float:left;width:122px;margin-bottom:8px;}
.mode_lists li{list-style:none;margin:0 10px 18px 0;text-align:center;}
.mode_lists li img{border:1px solid #476081;}
/* E 列表 基类 */
/* S 图片列表 */
.pic_lists li,
.pic_lists li img{height:122px;}
.pic_lists li{margin:0 0 8px 6px;}
.pic_lists li .pic{display:block;border:1px solid #476081;}
/* E 图片列表 */
/* S mtv列表 */
.mtv_lists{width:930px;height:130px;}
.mtv_lists li,
.mtv_lists li img{width:120px;height:90px;}
.mtv_lists li .pic{display:block;margin-bottom:8px;}
/* E mtv列表 */

可能你会觉得这样的样式不就多写了，还得把原先的模块类变成两个。的确不是所有的模块都值得这样去做，于是我们可以得到一种“偷懒”的作法，把其中一个模块直接变成基类。对于经常会被使用的模块，像图片列表、播放列表等，这种写法在代码的复用和效率会有一定的提高。一般情况下只需要做下简单的修改即可应用，来看一个复杂些的例子：

一个带头像的消息列表（A）

不带头像的简化列表（B）

看看这两个图，在脑中先想想如果是你，你要怎么实现。……5分钟过去了……差不多有方案了，按上面的思路，基类是包含了大部分的效果的，也就是说基类应该能满足大部分效果的需要，两个模块间差异的地方，可以通过扩展类来完成。当然前提是这两个模块有能找到类似的点，能够形成基类。

在这两个模块中，我们不难看出，A模块和B模块在信息的部分是很类似的，虽然B模块的列表不需要A模块的评论部分，但这并不影响B模块的表现。所以我们可以把这两个模块看成的类似模块。另个，以哪个为基类呢？从满足大部分效果这个要求来看，很明显A模块做为基类是要比B模块做为基类更合适的，如果用B模块做基类，那么需要写更多的扩展类来满足A的需要。另外还有一个重要的点，之所以选择A模块为基类，是因为A在栏目中被更多的页面使用。

OK，来看看A模块怎么实现（样式部分）：

/* S 消息 基类 */
.mode_message{position:relative;padding:8px 3px 8px 48px;border-bottom:1px solid #DAECF6;_zoom:1;line-height:1.3;}
.mode_message .user_info{position:absolute;left:3px;top:10px;}
.mode_message .user_info .pic img{width:35px;height:35px;}
.mode_message .mode_message_cont{color:#797979;word-break:normal;word-wrap:break-word;}
.mode_message .mode_message_cont .info{display:block;zoom:1;}
.mode_message .mode_message_cont .info .music_name{color:#22639B;}
.mode_message .mode_message_cont .info .op_music{display:none;}
.mode_message .mode_message_cont .info:hover .op_music,
.mode_message .mode_message_cont .info.hover .op_music{display:block;position:absolute;right:5px;top:7px;background-color:#FFFFFF;}
.mode_message .msg{padding:2px 0;word-break:normal;word-wrap:break-word;}
.mode_message .mode_message_cont .op{margin-bottom:3px;}
.mode_message .time{display:inline-block;*display:inline;*zoom:1;font-size:10px;}
.mode_message .msg .p_zt_l,.mode_message .msg .p_zt_r{display:inline-block;*display:inline;*zoom:1;width:13px;height:8px;background:url(img/_g_other.png) no-repeat -17px -17px;vertical-align:text-middle;*vertical-align:middle;}
.mode_message .msg .p_zt_r{background-position:0 -28px;}
.mode_message .write_back .cont{margin-bottom:2px;padding:5px;background-color:#EAF6FA;_zoom:1;}
.mode_message .write_back .cont .cont{border-left:1px solid #ABCFE1;}
.mode_message .write_back .cont .zt{*overflow:hidden;}
.mode_message .write_back .cont .zt2{*padding-right:6px;}
.mode_message .write_back .cont .zt textarea{width:100%;height:40px;padding:0 2px;border:1px solid #D1E1EC;line-height:20px;color:#4F4F4F;}
.mode_message .write_back .cont .zt .normal textarea{height:23px;color:#B1B4B8;}
.mode_message .write_back .cont .zt .normal .op{display:none;}
.mode_message .write_back .cont .op{margin:5px 0 0;}
.mode_message .write_back .cont .op .bt_v2{padding:0 2px;vertical-align:middle;}
.mode_message .write_back .cont .zt{width:98.5%;*width:99.9%}
.mode_message:nth-last-child(1){border-bottom:none;}
/* E 消息 基类 */

别忘了提示条，虽然是用于模块中，但它应该是可以被更广泛使用的模块，因此我把它单独提了出来：

/* S 提示条 基类 */
.mode_hint{position:relative;margin:3px 0;padding:5px;background-color:#FFFEAB;color:#000000;_zoom:1;}
.mode_hint .op{position:absolute;right:8px;top:5px;}
.mode_hint .op a{color:#000000;}
/* E 提示条 基类 */

还有像按钮、全局定义这些内容，就不列出了。完整的可以看下面。

效果展示

例子中可以看到，扩展类的定义很少，只是一些简单的定义，像B模块：

/* S 消息 扩展 */
.message_nopic{padding-left:0;}
/* E 消息 扩展 */

只需要一句，将头像去掉即可。

系列文章

模块化的核心思想──页面重构中的模块化设计（四）

Ghostzhang — 2010-05-12 15:48:00

模块化的核心思想──页面重构中的模块化设计（四）

由 Ghostzhang 发表于 2010-05-12

有不少同学觉得前面的内容过于简单了，对于样式的作用域的分类、栏目级作用域、继承等内容的确十分基础，不过基础还是很重要的。下面就一起进入这个系列真正的主题——“模块化”吧。

早在Qzone4.0的页面架构中已经在项目中开始摸索提高代码复用的方法，只不过当时并没有很清晰的认识到“模块化”这个思想。从去年的《从宜家的家具设计讲模块化》开始，模块化成了我主要的一个学习方向。借着无数的提问、思考、讨论，渐渐形成了一个比较清晰的、较为完整的方案。后面的内容，更多的是出于我在实际项目中总结出来的方法，虽然已经尽可能为出现的问题提供了解决方法，不过还是少不了会有些我没遇到过或没考虑到的，欢迎各位指出。

首先来了解下页面重构中模块化的核心思想： 将HTML和CSS通过一定的规则进行分类、组合，以达到特定HTML、CSS在特定范围内最大程度的复用。 有三个关键词：规则、 特定范围 、 最大程度的复用 。怎么理解呢？

规则: 编写模块时需要遵循的规范
特定范围: 模块可使用的范围。与样式的作用域有关，大部分模块的使用范围仅仅是某一个栏目或站点。
最大程度的复用: 做最少的修改即可重复使用。

很多同学都把“复用”理解成不用修改的直接使用，但在页面制作中，由于实际的项目环境，基本是不可能做到“一个模块走天下”的。不同的栏目会有不同的需求，大家应该都多少有所体会，我就不多讲了。

从实际出发，才能最终服务于实际。我们知道一个HTML标签可以绑定多个样式，所以我们可以这样去定义一个模块：

<div class="class-a class-b class-c">
    ...
</div>

不少同学已经知道这个方法了，而且还很形像的称之为“拼样式”。这样的定义很容易引出其它的问题，比如样式类的个数多少个适合？样式类如何命名？等等。下面讲下我的方法，从前面我们学到的样式作用域及模块化的核心思想，我们可以把样式进行一个分类，像这样：

.mode-a{/* 定义一个模块 */}
.type-a{/* 模块中的差异化定义 */}
.mode-name{/* 针对单个模块的个性化定义 */}

<div class="mode-a type-a mode-name">
    ...
</div>

上面的“mode-a”，我称它叫为“基类”；“type-a”为“扩展类”；“mode-name”为“模块名”，作用分别是：

基类: （基础样式）模块的基础表现。包含了模块中大部分的状态。
扩展类: （扩展样式）用于对使用基类的模块进行小范围的修改
模块名: 模块在某一作用域中的唯一名称。

这里有一个简单的例子可以帮助理解。

效果展示

也有同学主张用ID去表示“模块名”，我认为这种方式扩展性比较差，而且很容易与开发的ID冲突，不过也不失为一个方法。

系列文章

继承──页面重构中的模块化设计（三）

Ghostzhang — 2010-04-16 13:24:00

继承──页面重构中的模块化设计（三）

由 Ghostzhang 发表于 2010-04-16

前面我们了解了样式的作用域的分类和栏目级作用域。在权值中，还有一个很重要的因素，需要做下补充，起因是这样的，有个同学在CSS森林群里问了个问题：根据样式权值两个关键的因素

权值的大小跟选择器的类型和数量有关
样式的优先级跟样式的定义顺序有关

可以知道，如果10个标签选择器的权值应该比一个类选择的权值高，像这样：

div div div div div div div div div div div{color:blue;}
.c10{color:red;}

<div class="c1">
  <div class="c2">
    <div class="c3">
      <div class="c4">
        <div class="c5">
          <div class="c6">
            <div class="c7">
              <div class="c8">
                <div class="c9">
                  <div class="c10">
                     <div>这段文字是什么颜色？</div>
                  </div>
                </div>
              </div>
            </div>
          </div>
        </div>
      </div>
    </div>
  </div>
</div>

先别急着看答案，分析下。意料之中？如果这样呢？

div{color:blue;}
.c10{color:red;}

是不是跟想的不太一样？难道前面所说的权值是有问题的？前面讲的权值并没有问题，不过漏了一个重要的规则： 继承的权值小于0,0,0,1 。

样式的继承: 指被包在内部的标签将拥有外部标签的样式性质。

继承最大的意义在于可以减少重复的定义，比如要定义整个页面的文本颜色，只需要定义body的color样式，body里的所有标签都会继承body的color定义。是不是很方便？方便是相对的，当你想要为body内部分标签定义另一种文本颜色时，继承也许会成为增加重复定义、降低性能的祸首。

并不是所有的样式定义都具有继承的性质，整理了一下常用有继承性的定义1，这些定义在使用的时候要比较注意。

简单分析下上面的例子，最后一部分的代码：

<div class="c10">
    <div>这段文字是什么颜色？</div>
</div>

当定义了c10后，根据权值，类定义的权值是0,0,1,0，应该是比div这个定义0,0,0,1要高的，但由于div是直接定义到标签上的，比起从c10的定义中继承来的定义权值更高。稍微改下就清楚了：

效果展示

从修改后的例子可以看到，p标签继承了c10的定义，显示为红色。因此，在使用标签选择器的时候，应特别注意它的作用域，个人的建议是，除了最基本的reset之外，在公共作用域中最好不要使用标签选择器，在栏目级作用域中也应尽可能的少用。

常用有继承性的样式定义：

ext-indent
ext-align
ayout-flow
writing-mode
ine-break
white-space
word-wrap
ist-style
ist-style-image
ist-style-position
ist-style-type
font
font-style
font-variant
font-weight
font-size
ine-height
font-family
color
ext-transform
etter-spacing
word-spacing

系列文章

关于职业化

Ghostzhang — 2010-04-07 22:34:00

关于职业化

由 Ghostzhang 发表于 2010-04-07

上个月的web标准化交流会似乎把大家对于页面重构的职业化问题给引了出来，比较有意思。从大家的会后感想中不难发现，大部分同学都是抓着“沟通”，“沟通”的确十分重要，不过有个大的前提：沟通双方是否能相互理解？有个故事叫“对牛弹琴”，讲的就是这个，你很用心的弹琴，但牛听不懂得你是否弹得好。正所谓“隔行如隔山”，很难要求你的上下游中所有的人都像你一样懂得那么多，由于职业需求的不同，大家所侧重的点也不同。当然这个例子有点极端，不见得不做重构的人就不懂重构，就像做重构的为什么就非得什么都懂一样。

很多时候我们都希望别人能主动跟你沟通，把事情都安排好了，甚至用脑都是多余的。可惜大家都这么想，于是就开始感到事事不顺了。都知道沟通不好会引起很多的问题，但沟通并不是说说那么简单，这也是为什么大家都知道沟通有问题却一直还是有问题。

2号参加了公司的技术大讲堂，印象较深的有两个内容，正好也是这段时间比较有感受的。第一个是“ 理解需求的真正目的 ”。相信很多人都看过下面这张图：

这张图形像的表现了各个不同的角色对同一个需求的理解，不难想像，如果各自想当然的去做，最终是得不到客户所想到的结果的。因此，正确理解“客户”（并不单指产品经理，也可以是与你合并的任一方）的需求，是提高效率的捷径。

稍微发散一下，再看下《【转】关于学习——写给初学者》中的例子：

问：怎么去掉列表前面的黑点呀？答：list-style:none; 问：没有效果答：你把代码发上来看看。问：<li>·<a href=“xxxx”>xxxxxx</a></li> 答：……………………老大，你那个黑点是文字！问：我看看……哦，这样啊。答：无语晕倒。

很有意思，回答的人以为自己知道别人在问什么，提问的人以为别人知道自己在问什么。有没想过我们也许在别人眼中就是那个提问的人？而做为回答的人，是否也应该先了解清楚提问的人所遇到的问题？

第二个是“ 对质量的执着 ”。其实我以前一直认为写程序的人都有对代码上追求完美的特质，不过渐渐发现，现在学习程序的同学，很多都只追求效果，对于实现的过程和原理没有兴趣，更不会去追求质量上的完美。“自我要求”虽然是个比较虚的东西，可能别人看不到，但却是良性循环中不可少的一环，也是能力要上一个台阶所必需具备的素质。

tony每次的演讲都很精辟，这次的主题是“30岁以后，还能不能继续写代码？！”其实很早之前就听过这个话题，只是当时还小，并没有认真去想过这个问题。一个30多岁的页面仔，会不会让人觉得有那么一点“可悲”？很现实的一个问题，相比前几年，现在的页面重构已经被越来越多的公司所认识，并重视，在一定程度上说，有的公司已经可以解决这个岗位的生存问题。那么对于个人来说，是否愿意30岁甚至更大的年龄还继续从事这个行业？这个问题在群里也讨论了一次，很显然大家各有各的观点，当然也有人纠结于30这个数，它只是代表了一个年龄，背后可能是一个现实的问题——生活负担越来越大，精力越来越少。不管你给的答案是什么，这上问题只是提醒你，需要停下来思考下方向。

栏目级作用域──页面重构中的模块化设计（二）

Ghostzhang — 2010-04-03 14:49:00

栏目级作用域──页面重构中的模块化设计（二）

由 Ghostzhang 发表于 2010-04-03

在《样式的作用域──页面重构中的模块化设计（一）》中，我将样式的作用域分为了三个部分：公共级（全局）、栏目级（局部公共）、页面级。公共级（全局）容易理解，即影响站点中所有页面。简单解释下栏目级（局部公共）和页面级：

页面级: 可分为两种情况：在多个页面间，页面级作用域指针对某一单独的页面定义；在同一个页面中，页面级作用指针对某一标签的定义。它将决定最终的页面效果。
栏目级（局部公共）: 介于全局与单个页面之间的一个作用域，影响一个栏目（或某区域）。通常以某一类选择符做为开始，以包含选择符的方式将样式定义限定在某一区域中。

/* 只影响demo这个区域 */
.demo a{...}
.demo p{...}
.demo .title{...}

需要消化下的内容，决定一个样式定义是属于哪个作用域的因素有以下两点：

样式定义所在样式文件中的位置。（同样的一个定义，放在不同的位置，所影响的范围会有所不同。）
HTML中绑定demo这个类的标签位置。（同样一个类，绑定在body标签和绑定在页面中某个标签上，所影响的范围也会不同。）

在一个站点中，可能会分为几个不同的栏目，同一个栏目中，一般风格会保持一致。而不同的栏目间，相似的风格则不一定会相同。即使是全站通用的模块，如翻页，也可能会因为栏目的不同而会有一些差异，比如链接的颜色等等。使用栏目级的样式定义，能很好的减少代码的冗余，提高模块的复用性。

另外需要在思维上注意的一点，以作用域划分，并不意味着有着对应的文件，可能有些同学会习惯的以为一个作用域就应该对应着一个文件。比如一个小的栏目，可能只有两三个页面，这时我们就不一定需要再把栏目级的定义单独出来一个文件，而是与页面级的定义一起放在一个文件里，像这样：

/* S 栏目级定义 */
.class{...}
/* E 栏目级定义 */
/* S 页面级定义 */
.page{...}
/* E 页面级定义 */

系列文章

样式的作用域──页面重构中的模块化设计（一）

Ghostzhang — 2010-03-24 18:41:00

样式的作用域──页面重构中的模块化设计（一）

由 Ghostzhang 发表于 2010-03-24

很久没有更新blog了，这段时间实在是发生了很多的事，累身累心。但还是有很多想做的事，比如更新merceCSS、把一直以来所总结的有关模块化的内容整理出来跟大家分享、参加交流会等等。

模块化设计我已经提过很多了，像《从宜家的家具设计讲模块化》、《页面重构中的模块化思维》、《页面重构中的组件制作要点》都是跟模块化相关的，不过之前一直没有讲到具体实现方面的内容，只是一些思维。这次重点讲一下实现方面的内容，权当到目前为止我对模块化的一些总结整理。

要做好模块化，我觉得理解好样式的作用域是很重要的，所以将这部分作为这个系列的第一篇。

写过程序的同学应该都知道，变量是有作用域的（不知道的同学自己去问谷歌，这里就不作解释了），样式的定义也同样存在着作用域的问题，即定义的作用范围，很容易就能理解，如下面的p的作用域：

/*作用域：全局*/
p{text-indent:2em;}

/*作用域：.demo这个类中*/
.demo p{color:#000000;}

样式选择器的优先级是学习样式的基础知识，一起简单回顾下：

通配选择符的权值 0,0,0,0
标签的权值为 0,0,0,1
类的权值为 0,0,1,0
属性选择的权值为 ~~0,0,1,1~~ 0,0,1,0
伪类选择的权值为 0,0,1,0
伪对象选择的权值为 0,0,0,1
ID的权值为 0,1,0,0
内联样式的权值为 1,0,0,0
important的权值为最高 ~~1,0,0,0~~ 1,0,0,0,0

使用的规则也很简单，就是选择器的权值加到一起，大的优先；如果权值相同，后定义的优先。虽然很简单，但如果书写的时候没有注意，很容易就会导致CSS的重复定义，代码冗余。

从上面我们可以得出两个关键的因素：

权值的大小跟选择器的类型和数量有关
样式的优先级跟样式的定义顺序有关

了解样式的权值后有什么作用呢？比如可以这样用：举一个最简单的例子，

body{color:#555555;}
.demo{color:#000000;}

<p>这里的文字颜色受全局定义的影响</p>
<div class="demo"><p>这里的文字颜色受类demo定义的影响</p></div>
<p class="demo">这里的文字颜色受类demo定义的影响</p>

知道了样式的权值，你就知道上面例子的表现是怎样的了。进一步的应用，就是模块化了，比如《从宜家的家具设计讲模块化》中的例子，详细请移步。

再来说说“作用域”，相信大家很容易就会想到“全局”、“公共”这些词，关注过模块化的同学应该都知道，网上说得最多的一种“模块化”，就是像header、footer这样的以大区域划分。在去年web标准交流会（页面重构合理化讨论）上，克军提出了“样式的三层架构”——公共规则层、公共模块层、项目层。这些都有它们适用的范围，而且最大的优点是容易理解和应用。这里也不再做重诉了，感兴趣的同学可以找找相关的文章。

我在这一块的划分上，有点类似克军的“样式的三层架构”，有一点小的差别，我是以“作用域”来分的：公共级（全局）、栏目级（局部公共）、页面级。如何划分这个“作用域”呢？很简单，全局的global就是公共级的；只在栏目中用到的局部global是属于栏目级的；只影响单个页面的就是属于页面级的了。

最后几点要特别注意的：

除了标签选择器之外，哪些类是使用于公共级、栏目级中的，如.tx_hit{color:#FF0000 !important;}的适用范围是公共级的，应该放于全局的定义中。但，如果它只影响于某个栏目，那么就应该把它放于栏目级的作用域中。
标签选择器一般属于栏目定义，有时会用于公共级作用域中，除了最基础的reset之外，应尽可能少使用在公共级定义中
可继承的属性定义使用时须注意影响的范围，特别是在标签选择器中使用时
同类选择器无加权

接下来的内容就是以这个为基础的，希望大家能理解“样式的作用域”，对于后继内容的理解会很有帮助。

系列文章

记录下两个正则表达式的使用

Ghostzhang — 2009-11-27 11:15:00

记录下两个正则表达式的使用

由 Ghostzhang 发表于 2009-11-27

昨天在做mergeCSS的时候遇到两个正则匹配的问题，也花了不少的时间，最后在CSS森林群的 CE 同学帮助下，才完成了这俩正则，特别记录下，以后可能也会用到。

第一个是匹配图片路径的问题，要处理的字符串是：

background:url(demo.jpg);background-image:url(demo.gif);

我一开始写的是：

url\((.*)\)

得到的结果为：

url(demo.jpg);background-image:url(demo.gif);

可以看到，把两个图片匹配成了一个，结果不是所希望得到的。把它改为惰性匹配，如下：

url\((.*?)\)

得到的结果为：

url(demo.jpg);
url(demo.gif);

匹配到了两个图片，是所要的结果了。:)

第二个问题是正则表达式中使用变量的问题，简单解释下为什么加变量也会成为问题，先看下 RegExp 对象和 replace() 方法的说明，Javascript的正则一般的书写方式是：

/正则表达式/匹配模式

所有在“/”中间的内容都会被当成正则表达式，于是变量名也就被当成字符串了。不加“/”？也行，不过不加“/”的话就不能指定匹配模式，也就只能匹配到第一个。

通过RegExp对象可以生成一个新的 RegExp 对象，具有指定的模式和标志。

于是：

new RegExp("url\\((" + 变量名 + ")\\)", "g");

这里要注意的是使用“\\”的方式的方式进行转义，因为

如果参数 pattern 是正则表达式而不是字符串，那么 RegExp() 构造函数将用与指定的 RegExp 相同的模式和标志创建一个新的 RegExp 对象。

这个过程中“\\”会被转换成“\”，即上面的结果是：

/url\((变量内容)\)/g

页面重构中的组件制作要点

Ghostzhang — 2009-10-20 17:23:00

页面重构中的组件制作要点

由 Ghostzhang 发表于 2009-10-20

在写完前面“模块化”相关的文章后，感觉试图用“模块化”本身去讲什么是“模块化”真是不容易讲得清。相信大家都多多少少能理解什么是“模块化”，但是不容易说得清，也有不少同学反馈说缺少实例。现在的团队里在推“组件化”，做为“模块化”的一个应用方式，也许正好可以从另一个方面讲讲“模块化”的实现。

这里的“组件”跟“模块”并没有本质的区别，那为什么还要提一个新的名词呢？在《页面重构中的模块化思维》中提到了“模块化”的应用是十分广的，而且大家已经对它有了自己的理解，想要重新认识“模块化”是不太容易的，因此决定换一个名。“模块化”更多的讲一种思维，而这里的“组件化”更多的是讲一种实现。

一个组件效果的实现，需要的支持可能是不同的，组件强调的是“效果的完整”，要保证效果完整，就需要HTML、CSS、前端脚本甚至后台脚本等的配合。

简单列下做组件时需要注意的几点：

组件需要一个底层的运行环境。特别是对于CSS，就是常说的全站公共样式，包括reset。
确保同一组件在同一底层环境中的效果完整。
组件中的定义需要注意受组件外继承定义的影响。

在使用上面这些定义的时候，应该注意继承性对作用范围中标签的影响。同理，为了减少组件中被外层定义中的有继承性定义的影响，必要时须要在组件中reset。

在做一个组件之前，有几个问题需要先搞清楚，如：

是否需要静态化？
组件有多少种状态？
是否通过脚本程序实现状态的更改？
组件更新的频率？

这些问题对于组件如何实现更优起了很重要的作用。了解了基本的实现方式后，在制作组件所要考虑的方面，大概有下面这些：

效果的完整性（同一底层环境）
良好的性能
可移植、复用（同一底层环境）
易维护
易扩展

一个好用的组件，应该是充分考虑到上面这些点，并在它们间找到平衡。

我们来看一个例子：

首先，我们需要了解基本的实现环境：

是否需要静态化？（需要）
组件有多少种状态？（三种基本状态：正常、当前、已完成）
是否通过脚本程序实现状态的更改？（不使用）
组件更新的频率？（较低）

<div class="flow_step">
	<ol class="cols3">
		<li class="current">第一步</li>
		<li>第二步</li>
		<li class="last">第三步</li>
	</ol>
</div>
<div class="flow_step">
	<ol class="cols3">
		<li class="done current_prev">第一步</li>
		<li class="current">第二步</li>
		<li class="last">第三步</li>
	</ol>
</div>
<div class="flow_step">
	<ol class="cols3">
		<li class="done">第一步</li>
		<li class="done current_prev">第二步</li>
		<li class="current">第三步</li>
	</ol>
</div>

.flow_step{width:950px;height:25px;margin:20px auto 10px;padding:0;}
.flow_step ol{margin:0;padding:0;}
.flow_step li{float:left;padding:0px 15px 0px 0px;list-style:decimal inside;
background:url(step.png) #E6E6E6 no-repeat 100% -50px;color:#333333;font:700 14px/25px "宋体";text-align:center;} 

 /* 当前步骤 */
.flow_step li.current{background-color:#FF5500;color:#FFFFFF;} 

 /* 已完成步骤 */
.flow_step li.done{background-position:100% 0px;background-color:#FFD98D;color:#FF6600;} 

 /* 已完成无当前步骤 */
.flow_step li.done_none{background-position:100% -50px;background-color:#FFD98D;color:#FF6600;} 

 /* 当前步骤的上一步 */
.flow_step li.current_prev{background-position:100% -25px;background-color:#FFD98D;} 

 /* 最后一个步骤 */
.flow_step li.last{background:none;background-color:#E6E6E6;} 

 /* 最后一个步骤为当前步骤 */
.flow_step li.last_current{background:none;background-color:#ff5500;color:#FFFFFF;}
.flow_step li.last_current_none{background:none;background-color:#FFD98D;color:#FF6600;}
.flow_step .cols3 li{width:301px;}
.flow_step .cols4 li{width:222px;}
.flow_step .cols5 li{width:175px;}

完成效果

效果展示

再看看它几个方面的分析：

效果的完整性，可移植、复用，良好的性能：没问题
易维护：较差。HTML维护量较大，每个状态需要一个新的HTML代码；样式的组合需要花点时间理- 解。
易扩展：较差。新增一个5步的导航，需要增加10个HTML代码片段；样式基本不需要更新。
较难做成程序模板，HTML代码量较大。

同一个效果，如果基本的实现环境有所改变，可能就需要一种新的作法：

是否需要静态化？（需要）
组件有多少种状态？（三种基本状态：正常、当前、已完成）
是否通过脚本程序实现状态的更改？（可使用CGI）
组件更新的频率？（有多种步骤，3~5步）
有多个步骤同在一个页面的情况

<div class="flow_step_no1 flow_step_no0_n">
	<!-- flow_step_no1中的“1”为当前步骤。
	flow_step_no0_n的“0”表示正常状态，当出现无当前步骤时与flow_step_no1中的“1”相等。 -->
	<div class="flow_step">
		<ol class="cols3">
			<!-- cols3表示总共有三步 -->
			<li class="step_1">第一步</li>
			<li class="step_2">第二步</li>
			<li class="step_3">第三步</li>
		</ol>
	</div>
</div>

/* 组件页面流程图 */
.flow_step{width:950px;height:25px;overflow:hidden;margin:20px auto 10px;padding:0;}
.flow_step ol{width:110%;margin:0;padding:0;}
.flow_step li{float:left;padding:0px 15px 0px 0px;list-style:decimal inside;
background:url(step.png) #e6e6e6 no-repeat 100% -50px;color:#333333;font:700 14px/25px "宋体";text-align:center;}
.flow_step .cols3 li{width:301px;}
.flow_step .cols4 li{width:222px;}
.flow_step .cols5 li{width:175px;}
.flow_step .cols6 li{width:143px;} 

 /* 当前步骤效果 */
.flow_step_no1 .step_1,
.flow_step_no2 .step_2,
.flow_step_no3 .step_3,
.flow_step_no4 .step_4,
.flow_step_no5 .step_5,
.flow_step_no6 .step_6
{background-position:100% -50px;background-color:#FF5500;color:#FFFFFF;} 

 /* 最后一步去箭头 */
.cols3 .step_3,
.cols4 .step_4,
.cols5 .step_5,
.cols6 .step_6
{background-image:none;} 

 /* 当前步骤时前一步的效果 */
.flow_step_no2 .step_1,
.flow_step_no3 .step_2,
.flow_step_no4 .step_3,
.flow_step_no5 .step_4,
.flow_step_no6 .step_5
{background-position:100% -25px;background-color:#FFD98D;color:#FF6600;} 

 /* 前前步骤时除去前一步外已完成的效果 */
.flow_step_no3 .step_1,
.flow_step_no4 .step_1,.flow_step_no4 .step_2,
.flow_step_no5 .step_1,.flow_step_no5 .step_2,.flow_step_no5 .step_3,
.flow_step_no6 .step_1,.flow_step_no6 .step_2,.flow_step_no6 .step_3,.flow_step_no6 .step_4
{background-position:100% 0;background-color:#FFD98D;color:#FF6600;} 

 /* 最后一步时的效果 */
.flow_step_no3 .cols3 .step_3,
.flow_step_no4 .cols4 .step_4,
.flow_step_no5 .cols5 .step_5,
.flow_step_no6 .cols6 .step_6
{background-color:#ff5500;color:#ffffff;} 

 /* 已完成无当前步骤 */
.flow_step_no1_n .step_1,
.flow_step_no2_n .step_2,
.flow_step_no3_n .step_3,
.flow_step_no4_n .step_4,
.flow_step_no5_n .step_5,
.flow_step_no6_n .step_6
{background-position:100% -50px;background-color:#FFD98D;color:#FF6600;}
.flow_step_no2_n .step_1,
.flow_step_no3_n .step_2,
.flow_step_no4_n .step_3,
.flow_step_no5_n .step_4,
.flow_step_no6_n .step_5
{background-position:100% 0;}
.flow_step_no3_n .cols3 .step_3,
.flow_step_no4_n .cols4 .step_4,
.flow_step_no5_n .cols5 .step_5,
.flow_step_no6_n .cols6 .step_6
{background-color:#FFD98D;color:#FF6600;}

完成效果

效果展示

再看看它几个方面的分析：

效果的完整性，可移植、复用，良好的性能：没问题
易维护：一般。HTML维护简单，多个步骤、状态同在一个HTML；样式的维护点较多。
易扩展：一般。HTML扩展性较好；样式的扩展性一般，基本不需更新。
可较方便的制作为程序模板。

从上面的例子可以看出，同样的效果，不同的实现方式，它的可维护、可扩展等等特性是不大相同的，在CSS森林群里讨论这个图的实现时，还看到了上面两种之外的实现方式，像完全使用脚本将各个状态输出等。

近期对模块化实现方式的一点总结，欢迎讨论。

常用有继承性的样式定义：

text-indent
text-align
layout-flow
writing-mode
line-break
white-space
word-wrap
list-style
list-style-image
list-style-position
list-style-type
font
font-style
font-variant
font-weight
font-size
line-height
font-family
color
text-transform
letter-spacing
word-spacing

CSS森林三周年

Ghostzhang — 2009-09-23 12:21:00

CSS森林三周年

由 Ghostzhang 发表于 2009-09-23

9月15号是CSS森林群建群三周年的日子，回想这三年，感触蛮深的。通过这个群，认识了一帮“思维活跃”的同行、朋友。

19号晚上在广州（广州市天河南二路六运六街27-29号水沐莲清）搞了一次线下的聚会。

由于时间的关系，这次邀请了两位同学带来分享：

twinsen ( blog: http://twinsenliang.net )

《一专多长》: 介绍了重构工作者除了HTML、CSS之外，还需要学习、掌握的技能。WebRebuild第三届年会分享的内容。好东西应该让更多的人知道嘛。

steven ( blog: http://blog.gulu77.com )

《蛋炒饭》: 介绍了PNG8、多终端、HTML5及CSS3的一些内容。

本次聚会能顺利的举办，特别要感谢群里的 bluefly ，原定地点出现问题后，在很短的时间内帮忙在广州找到了新的场地，并负责中间的联系，和设备的准备等工作，才使得这次聚会能按计划进行。参加这次聚会的同学也让我十分感动，所有人都全程参与，特别是几位MM。另外，还有群里的“不小心”同学，提供了很好的话题。再次感谢大家的热情参与。

换种角度看“语义化”

Ghostzhang — 2009-07-22 11:18:00

换种角度看“语义化”

由 Ghostzhang 发表于 2009-07-22

《页面重构中的语义化》所表达的好像不太好理解，我们可以换一个角度来看看。

在“表格布局”¹的时代，大家所使用的布局方式都是表格，没有其它的方式可以选择， Dreamweaver 的可视化操作大大的简化了页面制作的过程，而且当时虽然网络情况比现在差得多，但并没有多少人会去关注页面性能这块。搜索引擎对于表格布局也无能为力，只能过复杂的算法去把内容抓取出来，而且很难知道哪些内容是重点，因为会正确使用标签的页面太少了。那搜索引擎如何得知页面的重点呢？没错，就是页面头部的信息，在这个区域，标签是有语义的，明确的指出页面的标题、主要内容、作者、版权等等信息。

接着，WEB 标准进入了国人的视野，它带来了颠覆性的改变，从页面制作方式到思维方式的种种改变。推荐使用“CSS 布局”² 代替原先的“表格布局”，让原先让人遗忘的许许多多 HTML 标签重新被认识，并以较严格的方式使用，在一定程度上规范了页面书写的形式，像“标签闭合”、“标签、属性使用小写”、“使用 DTD”等等。搜索引擎也很支持这种方式制作的页面，因为算法不用像以前那么复杂了，可以很简便的得到内容的主次，提高抓取的质量。这也是为什么 WEB 标准会更利于 SEO 。

那么，如果标签足够表达内容的语义，页面内容的语义就能以标签的方式被传递给更多的用户。因此，所谓语义化，就是尽可能的理解要表达的内容，选择适合的标签，将内容转换成浏览器认识的语言，通过浏览器传达给用户。可以理解为将内容的语义通过标签的方式表现。

写过 XML 的同学可能体会会深些，在 XML 中，标签是可以自定义的，但这些标签的定义都是为了让读取更容易，或许可以看下常见的 RSS，它就是一个标准化的 XML 格式，但 RSS 里使用的标签都是有语义的，你可以通过标签很清楚的看出哪部分是代表什么的。虽然(X)HTML 看起来比 RSS 复杂得多，但在搜索引擎看来，好的页面不就是一个 XML？

做为对《页面重构中的语义化》的一个补充，欢迎讨论。

使用表格单元格的划分来进行页面布局的方式。 ↩
使用样式的定位属性进行布局的方式。 ↩

页面重构中的语义化

Ghostzhang — 2009-07-10 18:15:00

页面重构中的语义化

由 Ghostzhang 发表于 2009-07-10

在想什么是“模块化”的时候，HTML部分的模块化也让我烦恼了一段时间，其中引出了另一个问题，就是“语义化”，本文想与大家探讨的内容。

“语义化”的知名度应该不亚于“模块化”，WEB标准在国内推广后，其中一个亮点就是“有利于 SEO ”，而“语义化” 也就被提出来了。目前讲“语义化”的文章基本上都是围绕着几个主要的标签，像标题（H1~H6）、列表（li）、强调（strong em）等等，大多是洗脑文。

做了几年的页面，听了不少人讲“语义化”，也讨论了几年的“语义化”，可是到现在，大部分人都还是不清楚到底“语义化”要怎么做，这几年间我也试着去理清相关的内容，只是有些点始终无法想透，特别是那些没有嵌套错误的标签，如列表（li），可以使用的标签十分广泛（可包含标签： %Flow; ），加上对“列表”理解上存在差异，导致在一定程度上的滥用。

我一直使用的方法是，将页面样式去掉，看页面是否以一种文档格式显示，并且是容易阅读的。使用这个方式可以让你对“语义化”的理解在短时间内有所提升。当然有些标签在浏览器中并无具体的表现，或表现与其它标签一样，不过方便用户读取内容，不正是“语义化”的意义吗？好像很对，在森林的聚会上被allan问到做语义化到底为了什么？时，我一时无言了，只是为了“祼奔”1 时好看？有多少用户会看到“祼奔”的页面，并且看下去？当时我是用了“盲文阅读器对不同标签所发出的声音是不同的，以此来传达信息的重要性”来说服allan，只是，连我自己都说服不了。

另外一个例子，关于标题的，“是否所有的块都需要添加一个标题？”小志的《列表模块是否需要标题》讨论了这个问题。我们经常使用隐藏的文字将内容放到页面上，这种做法我们一般也称之为“语义化”；选择要使用什么标签，我们也称之为“语义化”。选择标签是件很痛苦的事，比如一个电影列表页面，看上去是一个列表，是列表就使用 li ，很多同学都是这种思维，这个角度偏重于标签的语义。我们再从内容的角度来看，什么是列表？我记得之前看过的解释是“一些简短、有某种关联性的内容排列在一起，称之为列表”（准确的解释现在不好找了，百度和google也有找不到的东西），应该是区别于段落的，从这点上看，列表中放标题、段落、块等等都是不合适的。很多时候我们都只是关注到其中的一方面，比如我们在写代码的时候，更多的关注到当前部分应该使用什么标签，而不是关注到这个内容在整个页面中应该是什么语义的。

前段时间重新思考了这个问题：“什么是语义化”。发现一直以来都很纠结，因为我们把两个思维混在一起了，因此我提出了“内容语义化”和“代码语义化”，在一定程度上能让思维清析些，之后发现，其实“内容语义化”和“代码语义化”并不是独立的东西，我们是根据内容的语义去选择标签的，这时标签的语义也就代表了内容的语义。

所谓语义化，就是尽可能的理解要表达的内容，选择适合的标签，将内容转换成浏览器认识的语言，通过浏览器传达给用户。从这个角度来说，我们更像是“翻译”。我们要做的还不只是简单的翻译，毕竟我们的“听众”并不是单一的。

目前来说，做语义化的确还不能体现出它的优点，可能的原因是：

除了专业的人外，没人会去看我们的标签是否使用得有语义
HTML的标签还不足以表达所有可能的语义
语义化会需要增加一些额外的代码

简单说下我的想法：记得前段时间有同学向我反映一个设计稿的问题，主要是说产品经理让她改设计稿上一个写反了的广告语，“XXYY”改成“YYXX”，而且看上去意思差别并不大。我给的回答是，在我们这种外行看来可能没什么差别，但这正是专业的体现。外行看热闹，内行看门道，我们写的页面并不是所有人都会去看源代码的，那我们为什么还要注意那么多东西呢？我们也一样，用户只是看到了一小部分，更多的是做给懂得点右键选“查看源文件”的人看的这点也是从我们自身发展来说的，如果你想在这个行业内有所建树，专业化是必须的。也就是说如果你不考虑自己的发展，也就不用讨论“语义化”的问题了。

HTML5新增的几个标签，更多的补充了目前HTML标签语义上的不足，这点也可以看出语义化是以后发展的一个方向，当然更大的目标是统一的实现标准，语义化只是为了这个目标所使用的一个方法。这可能需要相当的一段时间，而我们正经历着这个过程。

在“语义化”的过程中，的确是需要增加一些标签。这个需要做页面的同学先明白一个问题：我们是为了什么而做页面的？正如前面所说，我们是内容的传播者，我们尽可能的让更多的用户更容易的从互联网获取信息。那么，表现上不需要的标签就是多余的吗？虽然我们现在很多的表现还需要额外的标签来支持，但这也是因为浏览器对样式的支持不完全造成的。随着浏览器对样式支持的改进，这类为了表现而写的标签也会越来越少。

页面重构中的模块化思维

Ghostzhang — 2009-06-21 21:24:00

页面重构中的模块化思维

由 Ghostzhang 发表于 2009-06-21 更新于 2021-12-10

最近被“模块化”缠身，又是文章又是 PPT 的，被逼着想了很多相关的东西。整理下我这段时间对于“模块化”的思考，大多都是我自己从事页面重构这份工作的经验和理解，在一定程度上存在局限性，也希望自己能温故而知新。

“模块化”只是我们对于过去一直使用的技术、方法的一个新潮的称谓，就像“Ajax”。不过做为页面重构发展的一种趋势，越来越被大家重视，不自觉也满口的“模块化”，只是你真的理解什么是“模块化”吗？

什么是模块化？

对“模块化”的解释，在 CNKI 中就有 28 种。可见“模块化”思维使用的广泛。最接近页面重构中的“模块化”，现有的解释应该就是软件开发中的解释了。

先看一下百度词条是怎么解释“ 模块化 ”的：

模块化是指解决一个复杂问题时自顶向下逐层把软件系统划分成若干模块的过程。每个模块完成一个特定的子功能，所有的模块按某种方法组装起来，成为一个整体，完成整个系统所要求的功能。模块具有以下几种基本属性：接口、功能、逻辑、状态，功能、状态与接口反映模块的外部特性，逻辑反映它的内部特性。在软件的体系结构中，模块是可组合、分解和更换的单元。

相关的书籍也蛮多的，有兴趣的同学可以搜一下。需要强调一点，我们所借鉴的是一种思维的方式。

##页面制作为什么需要模块化？

站点内容越来越多、代码越来越臃肿，渐渐影响到了客户端的体验（主要是打开速度），影响到了维护的效率。有什么方法可以解决这些问题呢？

我们很容易就想到：减少代码冗余、提高代码重用率、图片压缩等等，而这些要如何实现呢？模块化思维可以解决，即可以有效减少代码冗余、提高代码重用率，更重要是可以支持到多人维护，降低维护成本。CSS 写法较为灵活，容易产生代码的耦合，使用模块化也可以在一定程度上降低耦合度，对于 BUG 的定位也有帮助。所以，我们更应该在站点前期就重视并使用“模块化的思维”编写站点。

我们之前经常提到的站点性能优化，有相当一部分也是“模块化”的内容，比如提高代码重用，提高开发效率等等，“模块化”的优点还有很多，我大概列了一下：

提高代码重用率
提高开发效率、减少沟通成本
降低耦合
降低发布风险
减少 Bug 定位时间和 Fix 成本
提高页面容错
更好的实现快速迭代
更好的支持灰度发布
其中最重要的一点，我认为是“提高代码重用率”，这也是模块化最重要的特点之一。

如何实现“模块化”

这里的主要问题是 HTML 与 CSS 的“模块化”，我们可以看下换肤的实现方法：

同一类名，换文件（JS）
同一文件，换类名（JS）

由此可知 HTML 与 CSS 的接口实现：

CSS 引入的三种方式
类名

为了更好的实现这种接口，需要有相关的（交互、设计、页面、开发）约定、规则、规范，比如：所有当前状态都使用同一个类名“nonce”，所有变灰的表现都使用原类名后加“_n”，Tab 的实现方式等等。有了这些约定、规则、规范后，HTML 代码就很容易可以实现模板化，统一接口规范。

有两个误区需要先认清下：

模块化后并不是就能被使用在任何位置（模块化后的代码段也是有适用的范围限制，需要一个提供接口规则的环境）
模块化后并不是就不能再变更（模块化后的代码段可根据实际需要做修改）

完全独立的模块放在同一项目中，由于项目有自己的表现、交互统一性，所以各模块间必定出现类似的部分，这些部分可以被提出来做为公共的定义，减少冗余，这时就会出现耦合的问题，完全不耦合是不可能的，因此模块化中很重要一点就是“适度的耦合”。有了公共定义，就得调整模块样式的实现方式了，而这种调整也会影响到“接口”的实现方式。

由于本篇主要是讲模块化的思维方式，具体实现的细节留待以后的文章中探讨。相关内容可以看下之前写的《从宜家的家具设计讲模块化》。欢迎一起讨论。

系列文章

写给应聘页面重构的同学

Ghostzhang — 2009-03-10 18:25:00

写给应聘页面重构的同学

由 Ghostzhang 发表于 2009-03-10

当“ 页面重构工程师 ”这个职位的面试官也蛮长一段时间了，跟前两年比起来，总的来说来应聘的同学能力在很大程度上有了提高，记得两年前的一场招聘会上，有个同学还问我“div这个属性是什么意思”，让我一时间不知道如何回答。经过这两年的时间，也可以看出WEB标准在国内已经被很多学习页面制作的同学认可并学习、使用。越来越多公司也开始设立页面重构的职位，要求也越来越高。不过从招聘信息上看得出很多公司对这个职位所应该具备的能力跟前端开发工程师还是比较近的，基本就是换了个名。这也从某方面反映出页面重构这个职位越来越得到重视，也是一种改变。

回来正题，我写这篇文章不是为了说招聘信息应该怎么写，而是想总结下我面试过的、看到的那些应聘这个职位的同学所存在的问题，也算是给将要应聘这个职位的同学提个醒。

首先简单说明下我面试的范围，以明确下面所总结的范围：到目前为止，我主要是从事“页面重构工程师”这个职位的技术初试，所谓初试就是第一次的筛选，主要是技术，也就是职位所需能力的面试。因此，我所总结的主要是技术方面的内容。

从以往的面试评价中可以看出，大部分没有通过面试的同学都或多或少有下面的问题。

技术方面：

基础知识

问题主要是对HTML标签掌握欠佳，使用很随意，更不用说语义化了。一些常用的技术如“滑动门”没有深入理解，使用上存在问题或没有正确的使用。还有就是不验证，有些同学因为受某些人性主义说法的影响，对“验证”这个工具很反感，没错，我们不是为了过验证而做页面，这个工具能很方便、高效的帮我们找到一些低级的错误，为什么不使用呢？
设计稿还原

大部分同学没有关注设计稿的还原，往往只是看上去差不多就算了，但作为这个岗位的基本素质，这明显是不合格的。
语义化

在国内很难有明确的标签语义化标准，不过一些最基本的标签语义还是需要做的，像在列表（li）里放标题（hn），虽然没有嵌套错误，但明显是有问题的。
页面性能

主要还是连接数、文件大小，说虽然都懂，做就总没注意。
图片类型

什么是内容图？什么是装饰图？我一直以为这个很好理解，可是“自以为”果然是容易出问题的，发现有相关多的同学理解都不太相同。有“能给用户传递信息的图片就是内容图”、“带文字的图片就是内容图”等等。没有正确理解，就难正确使用，所谓知其然还要知其所以然嘛。
用户体验

这块比较泛，作为一个更高的要求，主要是如何让用户更流畅的使用站点。

其它方面：

对待面试的态度

有些应聘的同学本身有工作，时间不多可以理解，我一般也是让应聘者自己定个时间，只要不过份，都是接受的，但有些人并没有按时提交作品，不说其它，首先对于自己能力的评估是否就有问题？评估错误的风险是很大的，如果是实际工作中出现这种问题，那可能带来的结果就不是没有了一次面试机会这么简单了。另外就是诚信的问题。
对待作品的态度

相信做技术的人都有一些代码洁癖，对自己做的东西要求较高、追求完美，可惜现在这种特质并没有以前那么明显了，很多时候都是只要实现就好，怎么实现就随便了。最常见的就是不使用验证工具，在作品中出现一些低级的错误，像标签没关闭、嵌套错误等等。
表达、沟通

很多应聘的同学很会讲，说起来头头是道，不过作品中并体现不出来；还有些同学就是缺少沟通，自己的想法表达不出来、或不敢说，这些都是比较吃亏的。

还遇到过一个问题，有些同学很希望能通过面试，进而采取了一些投机的方法，如猜面试官喜欢什么样的写法、实现方式等等。这种方式也是不可取的，首先就是猜的东西准确性比较低，有经验的面试官会隐藏得较好或给出错误的信息，猜的时间还不如好好做题。另外就是不明白面试的意义。面试，我的理解就是用人单位通过一些测试的方法，了解应聘者是否有具备相应工作岗位所必需的能力。如果是什么人都可以做的工作，面试也就没意义了。面试同时也是为了应聘者负责，做能力之外的工作，工作上压力过大、效率低下，由于工作的不如意，引起生活上也事事不顺心，又怕失业，整天精神紧张……应聘者合不合适应聘的岗位，面试官应该更加清楚，投机的行为更多的会出来反效果。还不如更多的专注于把能力表现出来。

还有一点细节上的建议，发求职简历的时候，特别是邮件，主题上最好出现自己的名字，邮件内容中应该以文本简历的方式写，最后有一些其它形式的简历再附上。很好理解，因为这样支持搜索，在一堆简历中要找到某个人的简历是不容易的，如果不使用搜索的话。怎么可以方便搜索呢？上面已经说了。这样能减少因面试官（面试官可不是只有一个人）找不到简历而失去面试的机会。

面试也是一种经验，希望应聘的同学不会一无所获。最后，祝所有在找工作的同学，生活开心，面试顺利。

从宜家的家具设计讲模块化

Ghostzhang — 2009-02-11 17:46:00

从宜家的家具设计讲模块化

由 Ghostzhang 发表于 2009-02-11

很久之前就知道宜家，以前在广州的时候也去过一次，给我的印象就是：大、贵、巧。地方很大，东西很贵，设计很巧。现在住的地方离宜家不远，这个月找时间去逛了下，地方还是那么大，东西还是那么贵，设计还是那么的巧。虽然没有买什么东西，不过也还是有所收获的，通过宜家的家具设计方法，我们可以聊聊模块化。

去过宜家的同学应该都有注意到，宜家的家具基本都是组合的，可拆装。模块化的特点也是这样，可以组合，相对独立，在需要的时候可以很方便的加上。那怎么写可以基本实现这种方式呢？给个简单的例子：

<div class="mode-a">
    <h3>模块化Demo</h3>
    <p>模块化结构的例子。</p>
</div>

对应的CSS可以这么写：

.mode-a{...}
.mode-a h3{...}
.mode-a p{...}

其中“mode-a”就是这个模块的名称，表示这是名为“a”的模块，现在这个模块可以被放到你所需要的地方。既然是做模块，就不会只有一个，我们再加一个“mode-b”：

<div class="mode-b">
    <h3>模块化Demo</h3>
    <div>
        <h4>模块化的特点：</h4>
        <ul>
            <li>相对独立</li>
            <li>可移植性高</li>
        </ul>
    </div>
</div>

对应的CSS可以这么写：

.mode-b{...}
.mode-b h3{...}
.mode-b div{...}
.mode-b h4{...}
.mode-b ul li{...}

实际应用中大多需要加一些classname来减少类定义的复杂度，这个例子比较简单，但足以说明模块化的特点。上面两个模块可同时被使用到一个或多个页面中。

在宜家的卖场中，也许你也注意到了，基本是以设计师来划分商品区的，特别是那些小件的商品。模块化后的代码也可以被分配给不同的人进行编写，提高效率。当然要实现这种方式，我们也需要做些工作，如模块的命名规范（可参考《样式命名规则》）、模块中哪些地方是需要留接口的等等。如上面的例子中可以约定的就有：命名以“mode”开头，模块标题使用h3标签。这样不管是哪个人写出来的模块都可兼容项目中的页面。

看到这你可能会发现，既然上面已经约定了模块固定的结构，每个模块的样式定义中所写的这一部分不就是冗余的吗？是的。如果已经形成相关的约定，这部分的样式定义可以被提出来放到项目的公共定义中，减少代码的冗余。如上面的例子可以变成：

/* =S global */
h3{
/* 第一种写法 */
...
}
.mode-a h3,
.mode-b h3{
/* 第二种写法 */
...
}
/* =E global */
/* =S mode-a */
.mode-a{...}
.mode-a p{...}
/* =E mode-a */
/* =S mode-b */
.mode-b{...}
.mode-b div{...}
.mode-b h4{...}
.mode-b ul li{...}
/* =E mode-b */

不知你有没注意到宜家那些小件的商品，往往可以组合到不同的其它商品上面。这也带出了模块化的另一个话题：模块中的模块。即在模块中可以存在其它的模块，也很好理解，就像我们做网站的时候，整个页面的结构就像是一个大的模块，而上面所讲的例子就是模块中的模块了，只不过我们把这个定义缩小一层。上面例子中对h3的定义，就可以看成是一个模块，它在“mode-a”、“mode-b”两个模块中都出现，并且结构表现相对固定。

OK，这只是对一个标签的定义，如果不只一个标签呢？我们重新改下例子：

<div class="mode-b">
    <div class="mode-a">
        <h3>模块化Demo</h3>
        <p>模块化结构的例子。</p>
    </div>
    <div class="cont">
        <h4>模块化的特点：</h4>
        <ul>
            <li>相对独立</li>
            <li>可移植性高</li>
        </ul>
    </div>
</div>
<div class="mode-c">
    <div class="mode-a">
        <h3>模块化Demo</h3>
        <p>这个是“模块中的模块”的例子。</p>
    </div>
    <div class="cont">
        <h4>模块中的模块：</h4>
        <p>模块“mode-a”就是一个模块中的模块。</p>
    </div>
</div>

/* =S mode-a */
.mode-a{...}
.mode-a h3{...}
.mode-a p{...}
/* =E mode-a */
/* =S mode-b */
.mode-b{...}
.mode-b h4{...}
.mode-b .cont{...}
.mode-b .cont ul li{...}
/* =E mode-b */
/* =S mode-c */
.mode-c{...}
.mode-c h4{...}
.mode-c .cont{...}
.mode-c .cont p{...}
/* =E mode-c */

从上面可以看到，“mode-a”是一个独立的模块，当它作为“mode-b”和“mode-c”的一部分时，就成了模块中的模块了。抛下砖，希望能引出更多相关的讨论。

系列文章

再读《你是一个职业的页面重构工作者吗？》

Ghostzhang — 2009-02-09 14:34:00

再读《你是一个职业的页面重构工作者吗？》

由 Ghostzhang 发表于 2009-02-09

这段时间常给来面试的同学用《你是一个职业的页面重构工作者吗？》中三个部分的不同阶段去做自测，发现很多人都自我感觉良好，给我的回答基本都是比较高的，只不过实际上提交的面试题所反应出来的并没有那么高。我总结了下，主要有3点：

对自己的能力没有足够的了解，没有实事求是的认清自己
存在侥幸的心理，希望以较高的答案赢得面试的机会
对文章里每一点的理解存在偏差

简单做下说明：

对于我们来说是很重要的，只有真正的认清自己的能力，才能知道自己还有哪方面的不足，才能有针对性的提高自己。
就是人的问题了，这里也提醒下各位正找工作的同学，正直、诚信，是很多公司十分看重的，也是做人很重要的品德。我不会因为你没有达到文章中的要求而不给面试的机会，但会因为不正直而扣分。
也就是我决定写这篇文章的原因了。在文章的讨论中gulu77提到希望能为每个阶段写一篇详细的文章，之后就在想可能需要写一个更详细的说明，当初不想把每一点写得太细，是担心可能会变成误导，毕竟有些地方我有自己的想法。直到在 Webteam 中发表了这篇文章后，很多人对里面的点有疑问，让我觉得现在还不用担心误导的问题，因为根本就没能明白我想说什么。

写《你是一个职业的页面重构工作者吗？》的目的是为了帮助暂时找不到方向的同学，所以在读的时候对自己更诚实些，相信会得到更好的效果。

##一设计稿的分析

能分清设计稿中的公共与私有的部分

从最基本的开始，分清公共部分如菜单、导航、大框架和每个独立页面所用到的部分等，至少在想法上做不同的对待。
在1的基础上对各部分的实现方式有一个初步的方案（包括如何切图、写结构、写样式）

在分清公共和私有部分后，分析最简单的实现方法，如哪些部分是可以平铺的，哪些是可以重复被使用的等等。
在1的基础上，准确的给出各部分的实现方案（包括如何切图、写结构、写样式）

在分清公共和私有部分后，能准确的给出各部分的实现方案，如“滑动门技术”的实现方法有2种，选择哪种方法更合适项目？图片应该如何切？应该使用哪种HTML和CSS的写法？
3的基础上，能同时考虑方案的扩展性、复用性及页面性能（包括如何切图、写结构、写样式）

在给出的方案中考虑是否可扩展、如何重复使用、将哪一类的图合并可以最大化页面的性能。这里还要注意有些模块的内容可能是动态的，当内容改变后如何兼容。
在4的基础上，考虑整站的结构分布（包括文件分布、目录结构）

考虑上面方案的综合效率，如维护所需要的成本、页面打开速度、带宽成本、服务器开销等等。

1～3点应该成为基本的技能，4～5属于更高的要求。这块的熟练度会影响到后继切图和写代码的效率、返工的机率及维护成本的高低。

##二切图

切成所需要的图片（如何将需要的部分切出来）

最基本的，将需要的图切出来，有时候会需要PS出自己需要的图。
在1的基础上，对切出来的图片进行一些优化（包括压缩文件大小、选择图片类型）

压缩输出的图片，在不影响画面质量的前提下，尽可能的减少文件字节数。这个工作很重要，优化一张图片所带来的效果可能比优化很多的代码所带来的效果要明显得多。
在2的基础上，规划切出来的图片（包括文件分布）

规划切出来的图片，哪些图应该被合并，存放于哪个目录等等。
在3的基础上，考虑整体的性能（包括合并图片、压缩文件大小）

同样是综合整体的性能、效率。

1～3点应该成为基本的技能，4属于更高的要求。这块会影响到HTML和CSS的写法，还有页面的性能（流量、链接数）。

##三 HTML和CSS的编写

还原设计稿视觉效果，并通过标准验证（HTML）

还原设计稿，是页面制作最基本的要求，不管设计稿是否符合自己的审美观，做为页面重构工作者，还原设计稿是一项职业素质。通过标准验证是检验我们输出的质量很重要的一个方法。虽然最终的页面不一定可以通过验证，但我们所输出的静态页面大部分是可以做到通过验证的，除非有特殊的需求。当然我们不是为了过验证而做页面，是为了标准化。
在1的基础上，实现多浏览器的兼容（HTML）

兼容多浏览器，要实现多浏览器的兼容，少不要了解下各浏览器的习性。不过对于什么才是兼容，在《中国式WEB标准》中有讨论。
在2的基础上，标签语义化（HTML）

标签语义化，是WEB标准的核心内容，只有做好了语义化，才能说得上做到了WEB标准。虽然在国内很重有统一的标准，不过一些基本的语义标签的使用还是可以定下的，如段落、列表、表格等等。
在3的基础上，选择较优的实现方式（包括模块化结构，方便程序脚本使用，HTML和CSS）

做好了上面3点，只能说单一的页面做好了，下面得考虑两个以上的页面了。模块化就是为了更好的提高复用，减少重复开发所带来的浪费。模块化也是被越来越多的人所关注，可以说是发展的一个趋势，随着大家对HTML和CSS掌握越多，如何更好的发挥它们也成了提高工作效率的重点，其中模块化就是很好的一种方式，打算在之后写相关的内容（时间不好确定）。
在4的基础上，考虑到扩展性、复用性和可维护性（HTML和CSS）

做好了模块化，并不一定就是最优化的，如果考虑上扩展性、复用性和可维护方面的内容，模块化有时反而会不利于这几个方面，如何平衡这几方面，是一个更高的要求。
在5的基础上，考虑到整站的样式分布（包括如何实现分布）

这个算是整站的规划了，需要多少个样式，多少个目录，这些样式文件分别存于哪个目录（当然同时也需要考虑图片的分布）
在6的基础上，样式写法的优化（包括技巧的应用）

这点需要跟上面的第4、5、6点结合，需要做综合的考虑，使用更合适于项目的样式写法。

1～3点为基本的技能，4～7属于页面优化方面的内容。这块影响了一个页面甚至一个站点从无到有、从有到优。掌握好各个点的知识，会让页面在越短的时间内达到最优的状态。当然这也是个人能力的体现。

Rock在 Webteam 文章中的评论十分精彩：

“即设计师给三天的时间，制作只给一天的时间完成”

这一点我有些微言。呵呵，我觉得有些不现实。除非是非常专业的团队，虽然说通常都是这样的流程，但现实来讲:

1.很多设计师不具备模块化的思想，(即使有)通常设计出的稿子也是公用元素太少。往往现实的流程上3天设计师可能做出3个以上的设计。以及“产品经理/策划”无计划的修改。扰乱你的进程不说，还会对你的现有结构(html)产生更改，比如这个加个下一页链接，这个头像上悬浮一个什么图标。这都是很现实的问题。你的结构和你的css会因此看起来很不堪。

2.设计上对自己的要求不严格，通常会有1px-10px的差错，因为我做页面的时候每1px都会很计较，因为没有相应的规范，所以我都是在设计稿上量来量去，会发现很多的问题，因为如果不这样做，上级会认为你工作不认真，1-2px的padding甚至都会影响你的工作成果，在这个问题上我经常会和设计师们沟通很久，通常也会很不满设计的粗糙。

3.高质量的切图与psd/png文件的规范性，这也不得不提，从事这个行业毕竟会遇到各种各样的这类问题，有些psd文件会很规范，分组清晰，栅格化合理，图层混合方式不影响大局栅格化的效果，这些因素都会影响你的切图质量和效率。

4.浏览器的兼容性，这个问题不大，只要做的够久就会知道哪些浏览器的哪些特征，但往往特殊的需求还会使你在ie6上痛苦一番。代码洁癖的你是否愿意结构hack和多层嵌套的html，鱼与熊掌不可兼得，想要更加通用，你需要更多的嵌套和更多的class，想要完美，就意味着随便一个改动就破坏你的平衡。

5.与程序的合作，通常很多程序员也不具备这方面的知识，也就是说，你交给他的模板，等他套完程序，可能完全就是另一套模板了。而最遗憾的是，公司可能并非使用SVN或VSS等源代码管理系统(一种节省成本的方式?)，你没有管理模板的权限，你的权限仅限于图片文件夹和css文件夹。仅此而已。程序每套错一个地方，你要花时间去排错。可以说，这个成本很高。

一点个人见解，工作效率的决定因素究竟取决于什么，团队中每个人的专业性

呵呵，我觉得楼主在这些方面太过理想化了，其实我更想这样的操作方式。因为那真是太节省时间和成本了。但现实是完全不同。

从现实的角度说出了大家或多或少遇到的问题，Rock所说的问题的确存在，我也都遇到过，甚至目前还有。设计师和程序员不具备相关的知识的确是一个很大的问题，当然还有领导的重视程度和项目成本等原因。

从WEB标准开始在国内推广算起，差不多有三年半的时间，到现在才有多少同行真正的认同它、学习它、使用它？相信大部分人都还处于“别人都这么做，我也得学学”的状态，更别说是设计师、程序员了。为此，帮助他们认识到标准的好处，如如何使用标准提高工作效率、减少工作压力、减少成本等等，只有他们接受并使用标准，Rock所说的情况才会有好转。要影响、帮助别人，自己就必需先提高自己的能力。做技术的人大都有个特点：有代码洁癖、对自己写的代码要求严格、追求完美。其实很多人并没有一个标准，会这么写往往只是因为自己喜欢，所谓的代码洁癖、严格，都是以自己的喜好来决定的，对个人来说可能算得上是特点，但对项目来说却十分不利，可以说是一种片面的完美。

很少项目是可以一次成型的，也就是说大部分情况下并不完美，修改是少不了的。如果在前期的规划中就没有把这些修改（扩展、兼容）也考滤进去，后面必然会给带来很多困扰。当然扩展和兼容的考滤是在合理的范围内尽可能的支持，并平衡与性能间的矛盾。如何让产品经理、设计师、程序员去减少无理的、不必要的需求、修改，把修改变得可控，这些已经不只是页面制作的内容了，有兴趣的同学欢迎再讨论。

对WEB标准的理解

Ghostzhang — 2008-11-30 14:31:00

对WEB标准的理解

由 Ghostzhang 发表于 2008-11-30

“div+CSS”可以说是WEB标准在中国的一个里程碑式的标志，连原先只懂table的程序员也知道WEB标准不是简单的把table换成div，甚至开始会关注WEB标准的一些东西，比如对SEO的效果。

WEB标准化有利于SEO，但不单只为了SEO，学习是需要动机的，就像一开始推广的时候，重点是说站点的“换肤”、“改版”功能，这个对于初接触CSS布局和喜欢个性化的同学来说有一定的吸引力，这也是为了更好的推广WEB标准。感觉现在（样式布局对SEO的优化）SEO被越来越多的人所关注，特别是用来说服领导支持使用WEB标准。做为推广WEB标准的一种方式，我并不反对，但往往推广者本身并不能理解WEB标准，以SEO为目的推广WEB标准，虽然都是推广了WEB标准，但所产生的影响并不见得是积极的。SEO所使用的一些方法跟WEB标准是有冲突的，即如果做WEB标准，对SEO的效果是有一定影响的。

每个人对标准的理解不见得相同，有些人知道标准可以更好的做SEO，有些人知道样式布局可以让站点更好的支持个性化、维护起来更方便，有些人知道标准可以让站点更好的支持到多终端的显示、可以降低成本……好处很多，这也是WEB标准现在得以得到越来越多支持的原因。所有所有，都只是想到“自己”！我所理解的WEB标准：“让页面更友好，支持更多的终端，让更多的人（包括有障碍的人）可以使用互联网获得自己想要的信息”。是为了让更多的人可以使用互联网获取信息，不是单单的为了“自己”。因此，WEB标准另一个重要的内容就是“用户体验”。现在网站的交互设计也得到越来越多的关注，这是很可喜的，从观念上讲，重视交互就是关注“他人”，是质的改变。再进一层就是关注有障碍的人，这可以说是一种社会责任了，在中国现在的大环境中要做到这点，路还是很长。 Henny Swan 的《WEB标准在中国》里对中国的现状做了分析。相信有了国外对中国WEB标准进程的关注，在一定程度上会有所改善，值得期待。

最后，一起为了做个“有社会责任感的网站建设者”努力吧！

对站点架构的一点想法

Ghostzhang — 2008-10-24 22:41:00

对站点架构的一点想法

由 Ghostzhang 发表于 2008-10-24

不知不觉又一个月过去了，这个月很“盲”，有几件很“大件”的事在脑子里转，可是又不断有“紧急不重要”的事过来，搞得都有点烦躁、郁闷。没什么时间打理blog，也许各位也已习惯我这个更新频率了，我尽量维持在一个月左右的时间更新一次。

这个月里感触良多，有几次有写下来的冲动，可是时间都用来对付“烦躁”了，多希望自己可以“放手一拼”，不再年轻了啊～～

在准备写一份《站点架构-初级》的PPT（内部资料，不知道能不能发出来），主要是从页面制作的角度介绍如何进行站点规划，一些方法和工具的使用。从《你是一个职业的页面重构工作者吗？》中可以看出，在不同的阶段所要掌握的东西其实是差不多的，只是在深度上有所不同。同样，站点架构是在优化中更深入的一个阶段，它的本质就是“将局部的优化扩大到整站”，思维方式上会有一些改变，要考虑的东西会更多、更细，对“平衡点”的把握要求更高。“优化”这个词现在大家都不陌生，在“链接数和流量”的矛盾中找“平衡”是优化的核心。到了架构的层面，就变成了“可维护性和页面性能”的矛盾，对成本的控制也是一个很重要的方面，包括维护成本、沟通成本、流量等等。最重要一点，项目特点，只有充分考虑到项目的特点和环境，才能准确的把握好“平衡点”。

现在CSS布局已经成为学习页面制作的同学必学的一门，学习资料也越来越丰富，大部分都是技术类的文章，很多文章都讲怎么实现效果，怎么学习CSS，在思想方面涉及较少，也使得有些同学只关注如何实现效果。CSS的灵活性很高，甚至可以用写程序的思维去写样式，比如模块化、复用等思想，都是借鉴了程序的思维。虽然内容与表现要分离，但CSS和HTML又是不可“分离”的，两者相互影响，同样的效果，可以用不同的HTML结构和不同的CSS写法实现，比如滑动门，有两张图的实现方式，也有三张图的实现方式，有简洁的实现方式，也有高扩展的实现方式（要注意的是，这些方法都不是单单用CSS就可以实现的）。没有最好的方式，只有放到一个实际的项目环境中，选择最接近“平衡点”的方式。期望有更多关于思维方式上的文章出现，不单单只停留在技术实现的层面。

困了，思维不太清晰，就此停笔～

你是一个职业的页面重构工作者吗？

Ghostzhang — 2008-09-20 22:27:00

你是一个职业的页面重构工作者吗？

由 Ghostzhang 发表于 2008-09-20

做为一个专职的页面重构者，我们从事的工作简单的说就是“将设计稿转换成WEB页面”，这一过程可以很简单到直接把PSD从PS里导出成网页；也可复杂到需要考虑页面中每个标签的使用，考虑“页面性能”。以“前端工程师”为目标的同学可能会不愿承认将页面重构这块分出来，但随着工种的细分，加上页面重构本身的专业性，独立为一个职业也不是不可能，至少我现在从事的就是一个专职的职位。如果你觉得一个前端工程师必须去画设计稿，可以不理会下面的内容。

单纯的页面重构，所涉及到的工作内容一般是“分析设计稿=>切图=>写 HTML 和 CSS ”，虽然看起来很少，但要做好这份工作，绝非所想的那么容易。原因很简单：工作内容单一，在时间和工作量上必会很苛刻，往往跟设计师的工作时间是3:1，即设计师给三天的时间，制作只给一天的时间完成；在这种工作强度下，很多人都是靠着对这份工作的喜爱在维持着，一旦工作热情消失，很容易就会变得枯燥，保持热情也成了重构工作者（也许是所有参加工作的人）应该具备的能力。

跟“前端工程师”所要求的有所不同，“页面重构”虽然也是“前端工程师”的一个范畴，在职业化中，对专职的页面重构者，要求当然也更高。不单是做出页面，而是做出好页面。又引出另一个话题，“何为好页面？”，一般包括下面几点：

结构完整，可通过标准验证
标签语义化，结构合理
充分考虑到页面在站点中的“作用和重要性”，并对其进行有针对性的优化

很多同学多少都遇到过方向不明，不知道自己应该提高些什么，我们可以从“分析设计稿=>切图=>写HTML和CSS”这个工作内容，针对每一点提出一些要求，以方便我们分析自己的能力水平，为继续提高确定个方向：

设计稿的分析: 是指对设计稿如何制作成页面的分析，即哪一块的内容可以做为公共的部分、哪一块的内容结构可以如何实现等。

对设计稿的分析能力可以划分成下面的几个阶段：

能分清设计稿中的公共与私有的部分
在1的基础上对各部分的实现方式有一个初步的方案（包括如何切图、写结构、写样式）
在1的基础上，准确的给出各部分的实现方案（包括如何切图、写结构、写样式）
在3的基础上，能同时考虑方案的扩展性、复用性及页面性能（包括如何切图、写结构、写样式）
在4的基础上，考虑整站的结构分布（包括文件分布、目录结构）

上面这些都是在还没开始动手制作之前所要做的。

切图: 是指将设计稿切成便于制作成页面的图片。

很多人都有个误区，觉得切图就是把图片切出来，其实并不完全是这样，还包括把切出来的图片合并到一起，怎么切、从哪切才能将性能最大化，说“切图是一门艺术”完全不为过。切图也可以划分成几个阶段：

切成所需要的图片（如何将需要的部分切出来）
在1的基础上，对切出来的图片进行一些优化（包括压缩文件大小、选择图片类型）
在2的基础上，规划切出来的图片（包括文件分布）
在3的基础上，考虑整体的性能（包括合并图片、压缩文件大小）

HTML和CSS的编写: 是指将上面完成的内容，通过HTML和CSS的编写，将设计稿转换成WEB页面

这块是最重要的一块，也是我们所要重点掌握的内容，把它们放在一起，是因为它们相互的关联性太强，HTML的写法会影响到CSS的写法，它又可以划分成下面几个阶段：

还原设计稿视觉效果，并通过标准验证（HTML）
在1的基础上，实现多浏览器的兼容（HTML）
在2的基础上，标签语义化（HTML）
在3的基础上，选择较优的实现方式（包括模块化结构，方便程序脚本使用，HTML和CSS）
在4的基础上，考虑到扩展性、复用性和可维护性（HTML和CSS）
在5的基础上，考虑到整站的样式分布（包括如何实现分布）
在6的基础上，样式写法的优化（包括技巧的应用）

还有一点是对所遇到问题的解决能力，这一点在不同的阶段都可能会遇到，所以没有写到上面。

如果你已经达到或超过4、4、5，恭喜你，你已经是一个职业的“页面重构工作者”了，如果你想要一个大展拳脚的舞台，欢迎与我联系。（转载的同学注意啦，被骚扰可别怪我）

为了我们自身的发展，关注新技术、技术创新、提高用户体验、审美观、程序脚本的实现方式等，也是十分必要的。大家一起进步吧。

页面制作中要注意的编码问题

Ghostzhang — 2008-08-11 11:50:00

页面制作中要注意的编码问题

由 Ghostzhang 发表于 2008-08-11

不知道大家在做页面的时候会不会遇到样式定义不生效的问题，基本的表现就是怎么改样式都没显示或只有某些浏览器正常，这时通常需要做下面的几步：

确认所修改的样式文件是否是当前页面的样式文件（多个环境的情况）
确认文件中的路径是否正确（可能手误多写或少写）
如果上面两点都确认没问题或只是一部分样式失效，基本可以确定是文件的编码问题

大家都知道使用“UTF-8”比“GB2312”跨平台的兼容性更好，却不一定知道文件的编码跟文件编码的申明不是一回事，以为只要申明了文件的编码类型就是改了文件的编码，导致很多时候只是简单的申明了文件的编码类型，而并没有真的修改文件编码类型，当浏览器以申明的编码类型去解析文件时，由于文件的实际编码跟申明不同，出现解析不正确的问题。

以上问题如何产生呢？

只修改了申明，没有保存与申明对应的文件编码类型
在不同文件间拷贝时，两个文件间的编码不一样

上面的问题只要再另存一份，选择跟申明一样的编码类型即可解决。

如果上面的方法都没有作用的话，可能就是编辑软件的问题啦，建议换个编辑器试试。

目前我知道的会有问题的编辑器：

EmEditor Professional v7.50 Alpha 5（可能还是Alpha版本的关系，在UTF-8不加签名时，如果样式注释结尾出现特定的中文，如“不、用、接、名、近、见、鬼、评、论、的、出、写、下、现、面、日”等，会导致之后的内容无法被IE7解析）
Editplus（不知道是哪个版本了，有人知道请告诉我，保存UTF-8加签名时，签名会导致内容无法被解析）

注：以上说的都是指样式部分，包括页面中的样式和独立的样式文件。

在腾讯的两年

Ghostzhang — 2008-07-25 17:43:00

在腾讯的两年

由 Ghostzhang 发表于 2008-07-25

重新看了一遍《在两年前》，时间已经过去了半年多，即然说找时间聊下在TC的日子，就趁着过段时间简单的说一下，也算是一个阶段总结。

刚到深圳的时候真有点“陌生”和“兴奋”，这位城市没有广州那么让我觉得“生硬”，绿化做得很好，到处是花花草草，天也比广州蓝很多。办完入职手续，就算是正式加入了TC这个大家庭了，说是家庭，因为这里比起其他公司的环境，包括工作的氛围，都比较舒服。如果要说最吸引我的地方，那就是一份完全符合我兴趣的工作及发展空间。不用画设计图、不用写脚本，只要页面制作，这个环境在两年前我是想都不敢想，但真的让我遇上了，所以我很快就答应了到TC来。

刚进TC的时候，我所在的小组只有5个人，每个人都最少要支持2～3个业务的需求，当然，有些业务下面还会分portal、client等，如Qzone、QQ音乐。通过做了一段时间的活动，以更快的熟悉工作流程后，我第一个做的项目是网站相册（现在看到的还是两年前的作品），这个是我最先遇到“IE下多了只猪”这个经典的IEBug。

接着是礼品店（已经改过多次），曾经让我熬了两次通宵后都因为开发原因而放弃使用我做的页面，让我下定决心再也不为了这种小项目通宵。当然，有得就有失，这个项目也创下了我最快的速度，四天做了一个项目（好象是34个页面），那时最常说的一句话就是“半小时可以做多少页面？”，呵呵，现在可能做不出来了。另外，《[原]用DIV做九宫格》也是在这期间完成的。

随后是单身贵族（现在的“爱情小镇”），这个项目算是第一次尝试多人同时制作一个项目，虽然在此之前就有一些关于多人协作的想法，但在这个项目中可以说是“无能为力”，而这个项目只不过是两个人协同制作。协作真不是说说就能行的事情，并不是简单的定些约定、规范。如何才能更好的协作，这个问题在之后也时不时在我脑海里出现。可以说是“团队合作”的问题，但不是一般所想的不同工种间的合作，像设计、制作、开发间的合作，而是同一个工种的多个人，同时做一个项目时的方法。

Qzone是我接触时间最长的一个产品，到现在整整两年。可能很多同学因为个人情感问题或无法查看源代码而觉得Qzone十分“神秘”，Qzone是个很有挑战的项目，Qzone的“庞大”可以跟一个门户站相比，“复杂”却可能是门户站的10倍以上，但我觉得最大的挑战是改变那种种的“历史原因”，Qzone里有着很多“不可改变”的“历史原因”……由于我是做页面的，也就不讨论其它方面的问题了，只说页面。

当时的版本是3.2，只有小窝的表现，使用的是表格布局，4.0版本要实现打破那个小框框，也想在Qzone上使用CSS布局，由于我在之前的项目上已经使用了CSS布局的方式制作页面，正好有机会参与进来，在Qzone4.0启动的时候，跟着 twinsen 一起做Demo。当时4.0的页面Demo已经是兼容了FF的，但由于大环境的原因，最终4.0还是只兼容了IE。接触Qzone后发现，Qzone应该算是国内第一个应用了重构思想的站点，3.2里已经有不少地方都体现出了表现和内容分离的特点。

接下来就是着手将二级的页面都重构， twinsen 在帮忙把日志重构之后基本就离开了Qzone，留下了一堆的“历史问题”，所谓“历史问题”，就是指架构设计上的限制、或制作规则上的原因，导致出现无法解决的问题，就称之为“历史问题”。在Qzone里会遇到很多变态的问题，为了避开那些问题，也练就了一套写法，慢慢成了习惯，有时我也说不上为什么要这么写，虽然离开了Qzone的环境不一定会遇上那些问题。最大的问题还是由于架构设计上的不合理，以暴制暴始终不是办法，还是得从源头着手，改造整个页面的架构。

当然不是想改就改的，公司还要赚钱呢，又不能像My space一样，直接关闭改版。只能在平时一点一点的改，借小改版或优化的需求，对底层架构进行调整。Qzone最大的特点应该算是可以换风格，也许你会说“是博客都可以啊”，分析过的同学会知道Qzone并不是简单的改颜色、换图，有些是不能改的，模块是不固定的，还有些是用户自己装扮的。这期间也出现了打开速度过慢的问题，链接数过多、代码大量冗余等等问题一下都冒了出来，无它，如果站点打不开，用户大量流失，功能再强也是白搭，更谈不上收入了。解决链接数过多，使用的就是现在大家都在用的“合并图片”，老外叫作“Css Sprites”，小图变大图，用流量换速度。我也因此得到了一个“优秀员工”。这次经历也让我知道了页面制作并不是只能简单的把设计稿变成网页，还有“性能优化”这一层的事情可以做，一个好的页面制作者，应该把页面在实际项目的重要性考虑在内，对其做相应的优化。

随着对Qzone页面结构的进一步了解，能做的优化也越来越多，从HTML的写法、HTML语义、CSS的写法，到模块化框架，再到样式文件的分布，越来越多的东西，那些“历史问题”也成了我的工作乐趣，只是始终是在4.0里，不管底层如何优化，最终成品的结构直接对产品产生了影响。花了一年半的时间，我完成了80%的重构，除了音乐盒和一些小页面仍无法升级到4.0，恨！~

历史又将重演，Qzone迎来了5.0，这次换我制造“历史问题”了。5.0可以说比4.0更“庞大”、“复杂”，但结构清析，支持更多的扩展性，更好的支持协作，更趋向于一个平向的架构。关于5.0的内容，不方便说太多，而且也说不清，有兴趣的同学可以看下我的Qzone ，现在还在内测中，黄钻的用户过段时间也能优先体验下啦。至今还记得两年前有一次跟 twinsen 喝酒的时候对我说的话：“我的Qzone时代已经过去，接下来就是你的时代了。”，以这句话送给将接手Qzone的“战友们”。很快我就有一次“大升级”啦，呵呵，所有的方向都会有所调整，虽然有可能会离开Qzone，也没什么不舍的，过程比结果更重要。

系列文章

更改Mac上的文件关联

Ghostzhang — 2008-05-23 22:11:00

更改Mac上的文件关联

由 Ghostzhang 发表于 2008-05-23

最近更新了coda，结果原先跟coda关联的文件变成了跟DW关联了，真是“墙头草”。找了很久不没找到在哪更改关联程序，最后终于搜到啦，比windows还要简单，直接在文件属性里就可以修改了，操作如下：

按住“control”选择要修改的文件
在弹出的菜单中选择“Get Info”
在打开的面板里有一个“Open with”项，选择要关联的程序
如果要更改所有同类文件的关联，选择“Change All…”，点“Continue”就行了

记录下以备查阅。

关于H1的位置

Ghostzhang — 2008-04-02 16:03:00

关于H1的位置

由 Ghostzhang 发表于 2008-04-02

最近对 H1 的讨论很多（在文章内容页中），大致有以下两种情况：

H1 应该用于文章的标题上
H1 应该用于站点的标题上

相信大多数人都偏向第一种方式：用于文章标题上，从文章的角度上看，用户进到内容页里，想看到的当然就是文章的内容，文章标题理所当然是最重要的、最应该突出的。

OK，以上是在文章的角度看的，如果在页面的角度看呢？

页面中除了文章内容、由内容引伸出来的链接外，还有导行、广告、搜索等跟文章内容无直接关系的内容。在页面中，文章只是其中的一个组成部分，从语义的角度来讲，一个页面中只有一个大标题（H1），用于概括页面的内容（包括非文章的部分）。所以，H1 用于站点标题上比用于文章标题要更准确些。注意 H1 跟 title 是不一样的。

这里也解决下在讨论中有些同学提出的想法：

有关 SEO 的问题（H1 对 SEO 有影响）
有关语义的问题

这两个问题是有矛盾的，有时候做 SEO 就得放弃语义，以国内做 SEO 的手段，基本无语义可言。可悲的是现在做站的同学基本都着重于 SEO。

H1 对于 SEO 是有影响，但还不至于非它不可，它的权重比页面头部的信息要低得多，何不用心做好页面的头部信息呢？而且做好了语义化，对 SEO 并无不好的影响，为什么非要钻这牛角呢？

我觉得 body 里的内容是怎样就应该怎样，重点应该放在语义上，因为这一块主要是给用户看的，同时也为了适应多终端，有同学说你不也使用了隐藏的文字，没错，那是为了语义服务的，在没有样式或不支持样式的终端上，为了让内容更具有可读性，而不是为了做 SEO。SEO 应该重点放在 head 上，这块也是搜索引擎最看重的，比如 meta 就包含了许多用于搜索引擎的属性。

样式命名规则

Ghostzhang — 2008-03-20 23:12:00

样式命名规则

由 Ghostzhang 发表于 2008-03-20

命名一直是个让我头痛的问题，特别是那些看上去差不多的模块，所以就得想办法啦，我总结了下面的方法，虽然还在试验中。希望对大家有帮助。欢迎大家提出改进的意见。具体如下：

要注意的内容：

一，命名所选用的单词应选择不过于具体表示某一状态（如颜色、字号大小等）的单词，以避免当状态改变时名称失去意义。

二，样式类名由以字母开头的小写字母（a-z）、数字（0-9）、下划线（）、减号（-）组成。 ID名称由不以数字开头的小写字母（a-z）、数字（0-9）、下划线（）组成。

可使用类似下面的规则:

[模块前缀|类型|作用][名称][状态|位置]

约定模块、类型、状态、位置等的所使用的单词或其缩写，保持上面的顺序，尽量保持在两到三个单词说清用途。

例：

通用名词缩写
设置	set
成功	suc
提示	hint
操作	op
密码	pw
菜单	menu
按钮	bt
文本	tx
颜色	c
背景	bg
边框	bor
居中	center
图标	icon
弹出	pop
文本输入框	.input_tx
密码输入框	.input_pw
登录密码输入框	.input_pw_login
日志设置成功提示	.hint_suc_blogset
相册弹出的设置层	.pop_set_photo
公共提示	.hint_bg
文本颜色	.c_tx
段落文本颜色	.c_tx_p

在两年前

Ghostzhang — 2007-12-26 22:54:00

在两年前

由 Ghostzhang 发表于 2007-12-26

很快又一年就过去了，一转眼在TC工作了近两年，想起当初刚进来的时候，并没有“仿佛是昨天”的感觉，总感觉时间很久了，可是算下日子，也不过近两年，也许是每天要做的事太多，以至于总觉得时间不够，想起培训的时候的一个问题：“如果一天有25小时的话，你会怎么安排这多出来的1小时？”，我当时的回答是“工作”。当时很多人笑了，可能是觉得我很“笨”吧。我也觉得我很笨，工作有那么重要吗？对于我来说其实并不是很重要的，我所说的“工作”并不单指工作，更多的是指“事业”，虽然我也觉得谈“事业”有点可笑。

突然很想聊聊两年前，毕业后在广州找了大半年的工作，那段时间在上社跟一个朋友一起租了一个两室一厅的小房子，广州的房子也是蛮小的，加起来可能50平方左右大小，月租好像是700左右。当时边找工作边做兼职，接“外单”，一个单就400~900之间吧，小的是做后台管理，大点的就加上前台的页面，遇上“抠门”的客户，就总是拖着不给钱，让我印象最深的就是“某学院”的艺术系，找我做了整个后台管理，砍到900块后还以种种借口拖着不给钱，最后还欠我100块不还。也不是我小气，在当时的情况下，100块对我来说也不是小数目。这件事让我更深的体验到“页面制作”的地位低下，虽然一面说其他同行把市场做坏了，另一面又自己又接这种“低价活”，很是无奈。

后来在广州找到一家“台湾”服装公司做公司网站，工作倒没什么重的，就是路程很远（一天4小时左右在车上）、工作时间很长（早9晚8），而且老板很“抠门”。工作了整整10天就“放弃”了，不过后来还是为那公司做了一个月的兼职。

再过不久就经一个师兄介绍进了 [惠海IT连锁][] 做页面制作，参与了公司网站的项目，在那里我完成了我的第一个“CSS布局”的站点，还使用了“Ajax”，呵呵。可惜我的设计功力不行，一直都没能达到老总的要求，虽然老总并没有说出来。现网的站点是重新做的。很感谢陈总对我的支持，在当时“CSS布局”才刚出现的时候，很信任的让我在公司的站点上使用；在我收到TC的面试通知后，也很支持我。

再下来就是到深圳，进了TC工作，06年的4月。认识了 twinsen ，接受了“提高页面仔在行业中的地位”这个目标并为此而努力，我所说的“工作”。

在TC的时间就找下个时间再聊聊吧，写这么多字对我来说已经相当不容易了。:)

系列文章

【转】关于学习——写给初学者

Ghostzhang — 2007-11-30 11:56:00

【转】关于学习——写给初学者

由 Ghostzhang 发表于 2007-11-30

在 [豆豆猫][] 那看到一篇关于学习的文章，把我想说的都说了，经作者同意，于是就转过来啦，哈哈。原文地址： http://www.ddcat.net/blog/archives/2007/11/195.html

前几天有个人退群了。起因很简单，他问了一个问题，没人回答，于是说要退群，后来我看到了，给了个链接，说这个问题已经说过好多遍了，于是他就退了。

打开QQ的群列表，我所在的技术群有5个，不包括原来参加过又退了的。另外，还去几个论坛里看。看得多了，忽然觉得有几句话想说给初学者。

97年，我开始接触网络，然后开始做网页，直到现在，10年的时间，让我觉得自己有资格说这些，毕竟，我也是从一个“小白”开始。

一、基础学习

无论学什么，想做出些样子来，都是要付出时间与精力的。

网页制作看着很简单，用软件（比如word）都能输出，但是要想做好也不容易，特别是如果想拿网页制作当作养家糊口的本事来做的。那么，拿出点儿时间来看看html和css的基础知识，是必须的。而不是要用到什么就跑去论坛或者群里问，下次再遇到又问。

听过那个相声么？“这个问题我不能马上告诉你，马上告诉你你印象不深。”

事实上就是这样，别人告诉你一句，只能是短期记忆，只有自己查资料甚至走了弯路总结出来的东西才印象深刻。

html和css都是很简单的东西，不涉及算法，不涉及数据库，只要搞清楚含义就可以。

有了基础，其实很多问题都会迎刃而解，真的遇到了不明白的，再问也不迟。

群里也好，论坛里也好，那些水平高的人，一般都是很忙的，一些太基础的问题，可能他们不会回答。而有些问题看上去似乎是简单而且独立的，但是如果对基础知识不熟悉，却又很难解释得清楚。

例如：浮动和定位。浮动是布局绝对要用到的东西，定位也是，但是其在浏览器内的表现，又涉及到box model、包含块、文档流等等知识，同时，还可能有浏览器的bug在中间捣乱，那么我想没有几个人能用一两句话说清楚这许多的内容，只有去查资料，认认真真地学、实践，才能透彻地理解。

二、明白自己要问什么

经常有人问：“为什么这个没有效果？”，然后给一个截图。页面是由代码来表现的，不给代码，人家再聪明也没法猜。

经常看到一些帖子，问得问题既模糊，文字又不通顺，错字连篇，让别人看得都糊涂。问问题都这么不认真，还怎么指望别人去认真回答你？

说到这里，有个真实的例子：

问：怎么去掉列表前面的黑点呀？

答：list-style:none;

问：没有效果

答：你把代码发上来看看。

问：<li>·<a href="xxxx">xxxxxx</a></li>

答：……………………老大，你那个黑点是文字！

问：我看看……哦，这样啊。

答：无语晕倒。

三、善于使用搜索引擎

其实明白自己要问什么了，最直接且效率最高的方法是使用搜索引擎，网络的好处就是资料多得目不暇接。

也许你的问题已经有人问过——特别对于初学者来说，问题一般都是被问过很多遍的，因此，也许已经有人针对这个问题给过很详细的解释，搜一搜看看有没有，这样的结果，比别人在论坛或者QQ上随便打一句两句话回答你更能提高你自己的水平。

四、谦虚

忽然想起一个小品，说如今杨白劳是大爷，黄世仁要追着求杨白劳还钱。

经常看到一些帖子，问问题没人答，就抱怨论坛人气低，有人回答了可能没解决问题，就抱怨没有能人，在群里问了没人答就说群不好。

没有一个论坛或者群是万能的，也许你问的问题跟群没关系，自然没人答；或者，群里的人刚好都忙，毕竟大家都有工作，那么等等或者去搜资料，比抱怨更节约时间和体力。毕竟人家也没有义务要回答问题。

再或者，别人给的答案跟提问者预期的不一致，不要急着说不对，其实有些问题看上去的样子和其实质是有很大差别的。

举个例子，经常有人问一些CSS设定的问题，但是当我指出他的html结构不好时，总被回答，别管那个，你就说现在怎么写CSS。一个好的结构可能会让CSS变得很简便，你拒绝了简单的答案，别人哪里有那么多时间去给你搞复杂的东西？

五、关注别人的问题

天外有天，人外有人。

我之所以愿意关注这些群和论坛，因为从这些问题里，可以检验我到底掌握了多少知识，问题总是千奇百怪的，而总有人能对这些问题给出答案，有的方法是自己知道的，有的可能是自己不知道的。而看别人的回答也许就能让自己更进一步，同时，回答别人的问题，也能巩固自己的知识，有时候还能让自己发现新的东西。

如同前些日子，我买了两本CSS基础的书，有人问：你还要看这些基础的东西么？

每本书的作者都有自己的视角，自己的出发点，自己的经验，因此差不多每本书（当然那些纯是凑代码的书除外）都有其优点，都可以发现一些自己不知道的东西。

绝对的天才听说过，但是从来没见过。踏下心来，开卷有益。

把图像热区跟链接关联起来

Ghostzhang — 2007-07-20 18:46:00

把图像热区跟链接关联起来

由 Ghostzhang 发表于 2007-07-20

在《Sample XHTML 1.0 document》里看到图像热区也可以跟链接关联到一起，即点热区和点链接是一样的地址。看下具体的玩法。

正常的玩法：

效果展示

关联链接：

效果展示

xsl模版优先级

Ghostzhang — 2007-05-12 22:29:00

xsl模版优先级

由 Ghostzhang 发表于 2007-05-12

当一个节点匹配在 XSLT 模板中建立的多个模式（也称为规则）时，处理器就会按照 XSLT 规范中描述的冲突解决指导原则来确定使用哪一个模式。这些指导原则表明，当发生冲突时，会调用优先级最高的模板。然而，确定模板实际优先级的算法还需要附带解释一下。

要确定哪个模板具有最高优先级，处理器首先会消除导入的所有模板（使用 xsl:import 元素）；自动导入的模板比经过导入转换的模板优先级低。然后处理器确定其余模板的优先级值。

可以通过 priority 属性显式指定模板的优先级。例如，以下模板被赋予优先级 1：

<xsl:template match="/foo/bar" priority="1">
<!-- do something interesting -->
</xsl:template>

如果每个模板都赋予了优先级，则处理器可以使用这个值来确定哪个模板具有最高优先级。如果没有显式指定优先级，则处理器会为模板计算一个默认值。由处理器指定的默认优先级范围是从 -0.5 到 +0.5。基本上，模式越特殊，其默认优先级就越高。由于范围是从 -0.5 到 +0.5，因此如果显式指定一个模板的优先级为 1，就总会超过默认优先级。

Pattern Type	Default Priority	Examples
Node test by type	-0.50	*
		@*
		node
		comment
		text
		processing-instruction
Namespace wildcard	-0.25	ns:*
QName	0.00	foo
		ns:foo
		@bar
		@ns:bar
Processing instruction tests by literal	0.00	processing-instruction('foo')
Everything else	0.50	ns:foo/bar
		ns:foo[@bar]
		foo[contains(.,'Aaron')]
		//foo
Multiple patterns (pattern1 \| pattern2)	Treated as distinct templates, whose priorities are calculated independently

详细列出了如何为现有的不同类型的模式指定默认优先级。只包含按类型的节点测试的模式（例如 *、节点、注释、文本等）是最一般的，因此它们的默认优先级为 -0.5。只包含命名空间通配符 (ns:*) 的模式比较具体，所以它们的默认优先级为 -0.25。只包含限定名测试或常量处理指令测试（例如 foo、ns:foo、@bar、处理指令 (‘foo’) 等等）的模式分配的默认优先级为 0。而比这些具体的其他模式所分配的默认优先级为 0.5。这意味着具有多个定位步骤 (Location Step)，或具有谓词的任何模式都会自动得到默认优先级 0.5。

仍然存在这样的情况：有多个具有相同优先级的模板匹配给定的节点。当出现这种情况时，处理器可能产生出错信号，也可能选择使用文档中的最后一个模板。这是通常的选择方式。例如，以下 XSLT 片段包含两个模板，它们可以匹配相同的 foo 元素（该元素具有一个 bar 子元素和一个 bar 父元素）。由于两个模板的默认优先级都为 0.5，因此 XSLT 处理器要么产生出错信号，要么选择文档中的最后一个模板 — 在本例中为匹配 bar/foo 元素的模板：

<xsl:template match='foo[bar]' >
<!-- default priority = .5 -->
</xsl:template>
<xsl:template match='bar/foo'>
<!-- default priority = .5 -->
</xsl:template>

当然，您最好是避免出现这样的情况。如果您想让处理器在出现冲突时始终使用第一个模板，则只需要将它的优先级设为 1，如下面的代码所示：

<xsl:template match='foo[bar]' priority='1'>
<!-- would have a default priority = .5 -->
</xsl:template>
<xsl:template match='foo/bar' >
<!-- default priority = .5 -->
</xsl:template>

正如您所看到的，当出现冲突时，XSLT 需要经过大量处理才能确定调用哪个模板。当大量使用 XSLT 的声明性编程模型时，理解这些规则是很有必要的。

交互浅解

Ghostzhang — 2007-04-16 22:57:00

交互浅解

由 Ghostzhang 发表于 2007-04-16

“好久没有更新blog了”发现每次一写日志，都少不了这一句。交互设计现在也成了一个热门词，到哪都总能听到交互这交互那的，当然工作上也少不了接触到交互。每每跟臭鱼聊到交互，总会提到“以目标为导向”的交互设计——以用户的目标为设计的主导，任务越少越好。貌似是怎么说的。

有个例子：“比如有一个人想从A地到B地去，古时候是要几个任务要做：

带上枪
拿上足够的钱
租一辆马车

而现在如果也是要从A地到B地去，所要做的任务就不一样了：

不能带枪
拿少量现金
定机票

虽然是完全不同的任务，但目标是一样的：从A地到B地。如果有个人帮你把这些任务提前给你安排了，那会不会更爽呢？当然！交互所要做的就是帮你把这些任务给你安排好，让你更快的到达目地地。”

听起来好像没错，但仔细想想，你会发现任务还是要做，交互所要做的不是帮用户把任务做了，而是让用户更顺利的完成必须要完成的任务。

学交互的同学应该都知道“别让我思考——Krug可用性第一定律”、“……设计者应该尽量做到，当我看一个页面时，它应该是不言而喻，一目了然，自我解释的。我应该能明白它——它是什么意思，怎样用它——而不需要进行额外的思考。……”当然不可能完全做到这种页面，过多的提示只会让用户有被当成“白痴”的感觉。所以整站统一的设计，能让用户更容易形成心理模型，更容易的自我帮助。

“自我解释” 在对于提高页面友好度是很有帮助的，特别是当用户需要完成一些操作的时候，如链接、按钮等操作。一个不知道结果的操作，对于用户来说，都有一定的“恐惧感”，点了之后会出现什么呢？最简单的一个例子，关于链接的：大家都知道链接可以打开新窗口，也可以在当前窗口跳转。当一个链接没有说明是否在新窗口打开时，用户对于要不要点这个链接，总会犹豫，因为不知会不会将当前页面的内容覆盖。观察下身边使用电脑的朋友打开网页的习惯（特别是找资料的时候），你会发现一个很奇怪的现象：有大部分的人会在链接上点右键，然后选“在新窗口打开…”，也有人会按着Ctrl键直接点链接（在新窗口打开链接），为什么呢？因为不用去担心会不会把当前窗口覆盖（-_-||我就喜欢在新窗口打开，不行啊？……）。

OK，其实只是想说明一点：让用户知道自己在哪、将会去到哪。

对非IE浏览器使用条件注释

Ghostzhang — 2007-03-29 18:41:00

对非IE浏览器使用条件注释

由 Ghostzhang 发表于 2007-03-29

IE条件注释很多人都知道了，今天才知道，原来它也可以对非IE的浏览器起作用。嘿嘿，想知道吧。

我们所认识的IE条件注释是这样的：


<!--[if IE]> IE的内容<![endif]-->

看这个了解一下：

仅ie5.0以上版本支持仅IE可见参数属性：

gt : greater than，选择条件版本以上版本，不包含条件版本

lt : less than，选择条件版本以下版本，不包含条件版本

gte : greater than or equal，选择条件版本以上版本，包含条件版本

lte : less than or equal，选择条件版本以下版本，包含条件版本

! : 选择条件版本以外所有版本，无论高低

```html

如果是非IE的浏览器，会把这一段也当成一个注释，当然也就不会起作用了。所以要这样写：

```html

<!-[if IE]><![if !IE]><![endif]-> 非IE可见 <!-[if IE]><![endif]><![endif]->

这样非IE的浏览器就可以读到里面的内容，而IE则因为里面的条件为真而不显示内容。

效果展示

在标准中什么时候用使用表格

Ghostzhang — 2007-01-23 13:01:00

在标准中什么时候用使用表格

由 Ghostzhang 发表于 2007-01-23

在群中讨论了个列表与表格的问题，现在有很多人都不在页面中使用表格了，因为标准不提倡。真的是这样吗？不是。标准是不提倡用表格布局，不是不能使用表格。

使用样式表可以有很多方法模拟出表格的效果，但当样式表不起作用时，原先的表格效果就没有了，成为了一些没有意义的数据。

所以当要显示表格数据时，还是要使用表格来显示数据。

内容垂直居中

Ghostzhang — 2007-01-22 20:14:00

内容垂直居中

由 Ghostzhang 发表于 2007-01-22

在CSSPlay上看到了一个垂直居中的例子，感觉还是不错的，跟大家分享一下：

效果展示

代码改动了一点点。有两点必须要注意的：

HTML中IE条件注解部分的标签要用内联对象标签。


<!--[if IE]><span class="edge"></span><![endif]-->

要放在内容之前。如果放在之后，内容是中文时会不能居中。

横排列表(li)的左右对齐

Ghostzhang — 2007-01-03 20:50:00

横排列表(li)的左右对齐

由 Ghostzhang 发表于 2007-01-03

之前解决的一个小问题，让横排的列表可以左右对齐。相关代码如下：

效果展示

边框样式的写法总结

Ghostzhang — 2006-11-15 21:13:31

边框样式的写法总结

由 Ghostzhang 发表于 2006-11-15

今天在群（CSS森林:30247792）里讨论了border的样式写法，发现border的写法还真是灵活，做了一下总结，希望对大家有用：

border : border-width || border-style || border-color

border是一个复合的属性，它可以同时定义上右下左四个边框，当四个边都是同个样式时可以使用，如：

border:1px solid #FF00FF;

这是最简单的应用，如果四个边的样式不是相同的怎办？一般会有下面几种情况，写法差不多：

/*边框样式、宽度、颜色都不同*/
.div1{
border-top:1px solid #FF00FF;
border-right:2px solid #0000FF;
border-bottom:1px double #FF00FF;
border-left:1px solid #FF0000;
}
.div2{
border-width:1px 2px 1px 1px;
border-style:solid solid double solid;
border-color:#FF00FF #0000FF #FF00FF #FF0000;
}
/*边框样式不同*/
.div1{
border-top:1px solid #FF00FF;
border-right:1px solid #FF00FF;
border-bottom:1px double #FF00FF;
border-left:1px solid #FF00FF;
}
.div2{
border:1px #FF00FF;
border-style:solid solid double solid;
}
/*边框宽度不同*/
.div1{
border-top:1px solid #FF00FF;
border-right:2px solid #FF00FF;
border-bottom:1px solid #FF00FF;
border-left:1px solid #FF00FF;
}
.div2{
border:solid #FF00FF;
border-width:1px 2px 1px 1px;
}
/*边框颜色不同*/
.div1{
border-top:1px solid #FF00FF;
border-right:1px solid #0000FF;
border-bottom:1px solid #FF00FF;
border-left:1px solid #FF0000;
}
.div2{
border:1px solid;
border-color:#FF00FF #0000FF #FF00FF #FF0000;
}

还有就是有些边框是没有的，比如只有底边：

.div1{
/*错误的*/
border:none;
border-bottom:1px solid #FF00FF;
}
.div2{
border:1px #FF00FF;
border-style:none none solid;
}

注意：如果提供全部四个参数值，将按上－右－下－左的顺序作用于四边。

如果只提供一个，将用于全部的四条边。如果提供两个，第一个用于上－下，第二个用于左－右。如果提供三个，第一个用于上，第二个用于左－右，第三个用于下。

对标准的一点想法

Ghostzhang — 2006-09-29 09:09:00

对标准的一点想法

由 Ghostzhang 发表于 2006-09-29

早上起来的时候突然觉得“XHTML”没什么好玩的，标准是什么？能通过验证就算是标准？不是。标签正确的嵌套，该是标题的地方就用标题的标签，列表就用列表标签，等等。但这些也不能就说是标准了，每个人对页面的理解不同，所定义的标签就不同（XML更是可以自定义标签），而且都能通过验证，换句话说，标准只是一个“格式”的标准，不是内容的标准，只要格式正确，怎么写就是个人理解能力的事情了。

只写好格式真的就行吗？如果只是这样，那最多也就是一个页面仔。我一直在想如果有盲人朋友读我的页面会是怎样的一种感觉，发声的阅读器能否正确的把内容告诉盲人朋友。或许这就需要在内容上的标准了，因为标签是有语义的，不然也用不着那么多的标签来定义不同的样式。当然在这一块我并没有真正的去学习相关的知识，只是在做页面的时候会想到，也许是因为自己是“正常”人，所以并不能真正体会到“非正常人”的感受吧。

想搞点别的玩玩……

8月工作总结

Ghostzhang — 2006-09-12 11:08:00

8月工作总结

由 Ghostzhang 发表于 2006-09-12

忙了一个月，终于也有点东东出来了，算是我较为满意的一个作品，不算最好，但足以见到自己的进步。这个月里也体会到一些蛮重要的东西，像样式的书写顺序、文件的结构、兼容性的问题等等。

这个月有蛮多东东可以跟大家分享的，不过因为时间太少，没能一个个的给出例子。就说说在写样式文件的时候要注意的地方吧：

一、编码问题

有些时候你可能会发现网页加了样式表文件后显示不正常，而且样式表文件也并没有错，这时就得找找编码的问题的，因为如果用UE等文本编辑器保存文件的时候，有时会不小心存成UTF-8编码的文件，而网页如果使用的是GB-3212编码，就会出现网页显示不正常的问题。

二、书写顺序

很多人不注意样式属性的书写顺序，想到什么写什么，虽然这个影响小到你查觉不到，但在带宽很小的时候，这个影响就会被放大了。因为样式表文件也是按文件的读取顺序去执行的，将属性分类并以一定的顺序书写，不但可以提高可读性，对于文件执行的优化是有帮助的。

当然这顺序不是你想怎么写就怎么写，也得有些依据才行。我们可以把属性分成两大类，布局属性和表现属性。很容易理解，布局属性就是用于布局的属性，表现属性就是用于显示效果方面的。先执行布局再执行表现属性，可以让页面先把布局显示完整。按《Mozilla建议的CSS书写顺序》中所提到的“显示属性”、“自身属性”、“文本属性”的顺序，我觉得是很不错的，你会发现这个顺序是布局的属性在上方，表现的属性在下面。我是把“自身属性”中的border之上的部分分为布局属性，其它的分为表现属性。从大的角度上，你可以把布局属性和表现属性分开，为“换肤”提供方便。

三、兼容问题

这个问题也是最让人头大的问题，为不同的浏览器写hack，已经成为很多用CSS布局的页面仔常做的事，但很少会有人去想怎么做hack才是“正确”的，我并不是说做“hack”是正确的，能不用还是不能的好。还是推荐使用IE条件注解。这里有个技巧，虽然不是我发现的，但的确是很有用：在网页代码的第一行加上


<?xml version="1.0" encoding="UTF-8"?>

让IE7以下的IE版本使用旧的盒模型，先对FF、IE7和OP写样式，再对IE7以下的版本做hack，这个hack可以放在IE条件注解里：


<!--[if lt IE 7]>样式文件<![endif]-->

这样就只有IE7及以下的IE版本才会用到hack了。同时也是使用了正确的XHTML文件格式。

其它的一些目前还没有成功的、有效的实现，在这里就不多说了。

停了这么长的时间没有更新BLOG，但还能看到每天都会有固定的一些访问，真的很高兴，是你们的支持让我有动力去写BLOG，真的很感谢你们。(~-~)

7月工作小结

Ghostzhang — 2006-08-04 09:11:00

7月工作小结

由 Ghostzhang 发表于 2006-08-04

终于也算是结束了一个项目，对我来说，这是我进TC后的第一个项目。没有什么新鲜感，写出的代码还是一样垃圾，一直自己提倡的东西自己却做不好，不过我相信，现在“丑”只是为了更快的看到进步。OK，牢骚发完，还是说点有用的吧。

一，宽度的问题。

auto 默认值。无特殊定位，根据HTML定位规则分配。 length 由浮点数字和单位标识符组成的长度值或百分数。百分数是基于父对象的宽度。

二，浮动的问题。

当该属性不等于 none 引起对象浮动时，对象将被视作块对象，即 display 属性等于 block 。也就是说，浮动对象的 display 属性将被忽略。

跟随浮动对象的对象将移动到浮动对象的位置。浮动对象会向左或向右移动直到遇到边框、内补丁、外补丁或者另一个块对象为止。 div 和 span 对象假如没有指定宽度会被分配默认的宽度，在IE5之前的浏览器版本中则必须指定宽度值才可以呈递此属性。

三，样式的重用问题。

样式的名称真是个头大的问题，太多了也不好维护，虽然可以使用包含选择符，但同时也会带来继承的问题。

一直都知道样式有继承的特点，可什么时候会继承，怎么继承就不得而知了，还好在《HTML与XHTML权威指南》里发现了这么一段“类继承了它们的一般基本标签的样式属性……”、“类无法继承其他类的属性，只能从它们代表的标签的未分类版本中继承。”也就是说类之间没有继承的关系，只有当它代表了某个标签后才会继承那个标签的样式。基本标签样式会继承它的“父元素”的样式。

四，边界的auto问题。

对于盒模型，只有宽与左右边界可以使用auto，表示让浏览器自动确定宽度。此外，如果宽和左右边界都定义了宽度，而且它们之和小于父元素的宽，会向左对齐；如果左右边界为auto，会居中；都为auto时会向左对齐。

以上只是把这段时间里想到的做了下总结，会在以后再分别展开讨论。

关于CSS样式命名中的下划线

Ghostzhang — 2006-06-07 10:15:00

关于CSS样式命名中的下划线

由 Ghostzhang 发表于 2006-06-07

长久以来，一直习惯了在命名CSS样式名时使用下划线_做为单词的分隔符，这也是在写JS时惯用的写法。

用过CSS hack的朋友应该知道，用下划线命名也是一种hack，如使用_style这样的命名，可以让IE外的大部分浏览器忽略这个样式的定义，所以使用_做为命名时的分隔符是不规范的。在做CSS检查时会出现错误提示。

为此得找一个能代替下划线而又合规范的符号，当然不是一定要用这种分隔符之类的，只是个人习惯问题。

做了个小测试，将下划线分别用了~、$、```、&和－去代替，结果只有－号是可以使用的，而且对JS的支持也正常，看下测试：

效果展示

结果是“try1”变成了红色，显示正常。不过在CSS定义里，经常会用到ID选择符，如果在页面中的ID命名中使用了_，就免不了在CSS样式里出现下划线_了，所以在此还得注意在ID的命名上也要避免使用下划线。

注：由于在JS脚本里有时会用到document.idName这样的调用，如果ID中使用-号的话会被解释成是减的操作，所以使用ID选择符时不在此建议范围，当然在写样式的时候，也不建议过多的使用ID选择符。

小小的感想

Ghostzhang — 2006-05-22 17:15:00

小小的感想

由 Ghostzhang 发表于 2006-05-22

学了几天互交设计，发现这东东还是很有意思的，有点像做导游，现在在哪、要做什么、去哪……让用户在不知觉中进“黑店”，买点“记念品”。

跟开始接触Web标准一样，主要要面对的还是思想上的转变问题，新事物总是有新的思维方式，很多的为什么，可是已经不是接受新事物那么简单了，更多的是要放弃原本已经根深的思维方式，甚至得要有“认错”的勇气，当别人问得你无语时，是生气？堵气？还是接受？

可最大的问题还是“无知”，虽然知道这是种新东西，不知才要学嘛，可是新东西不一定就是好的，在无法分辨“好坏”的情况下，是否要接受？我觉得这才是个最大的考验。在学Web标准是时候也是，一开始就被那些所谓的“高手”引到了“DIV+CSS”的路上，结果很多人都错误的以为Web标准就是用DIV布局去替代表格布局，结果页面从一堆表格标签换成了一堆DIV标签，页面变得更难维护。

知比不知好，但一知半解还不如不知好。

用属性选择符来解决IE跟FF的兼容性问题

Ghostzhang — 2006-04-24 11:39:00

用属性选择符来解决IE跟FF的兼容性问题

由 Ghostzhang 发表于 2006-04-24

从之前写过的《属性选择符的使用》中发现了一个可以用来解决IE跟FF兼容性的问题，因为IE不支持CSS的属性选择符。下面来看看可以怎么做：

效果展示

从上面的例子可以看到，在IE中二个层里的文字颜色跟在FF中的文字颜色是不一样的，也就是说可以使用属性选择符来来写针对FF的样式。

可能你会说用!important声明提高样式的优先级不就完了吗，用属性选择符来为FF写样式意义不大。使用!important声明的确是比较方便，但IE6也认识这个声明，也就是说如果你给FF写了!important声明，那就得再为IE写一个样式来还原默认值，才能让IE6也显示正常。使用属性选择符就不会有这样的问题，而且可以将多个定义写到一起，是不是比较方便呢？看看下面的样式：

/* 使用声明 */
div.try{
  width:200px !important; 
   width:204px; 
  height:300px !important; 
   height:304px; 
   padding:2px; 
}

/* 使用属性选择符 */
div.try{ 
   width:204px; 
   height:304px; 
   padding:2px; 
}
div[class=try]{
   width:200px; 
   height:300px; 
}

这里的属性选择符最好不要使用ID为属性。在《CSS样式的优先级补遗2》及《属性选择符的优先级》中我们了解到，ID选择符的特性值为100，而属性选择符的特性值为11，即不能达到将样式定义分开的目的。

属性选择符的优先级

Ghostzhang — 2006-04-24 10:59:00

属性选择符的优先级

由 Ghostzhang 发表于 2006-04-24

大家都知道样式定义存在优先级的问题，像“ID选择符”的优先级就比“样式选择符”要高等等。在写完《属性选择符的使用》和《CSS样式的优先级补遗2》后才发现，原来属性选择符的优先级是比较特殊的，看看下面的例子：

/*IE*/
div{float:left;color:Orange;} /* 特性值为：1 */
.left{color:Aqua;} /* 特性值为：10 */
div div.right{color:Fuchsia;} /* 特性值为：12 */

/*FF*/
div[title=left]{color:Blue;}
div[title=right]{color:Gray;}

<div>
  <div class="left" title="left">
    <dl>
     <dd>dd1</dd>
     <dd>dd2</dd>
     <dd>dd3</dd>
    </dl>
  </div>
  <div class="right" title="right">
    <dl>
      <dd>dd4</dd>
      <dd>dd5</dd>
      <dd>dd6</dd>
    </dl>
  </div>
</div>

在FF中可以看到，第一个层里的文字是蓝色的，而第二个层里的粉红色的。所以不难得出，属性选择符的特性值是在10到12之间，姑且写为11吧，以方便表示。

CSS样式的优先级补遗2

Ghostzhang — 2006-04-21 14:26:00

CSS样式的优先级补遗2

由 Ghostzhang 发表于 2006-04-21

今天看到一篇《深入了解CSS的继承性及其应用》，文章中提到了CSS的特性值

样式表中的特殊性描述了不同规则的相对权重，它的基本规则是：

统计选择符中的ID属性个数。

统计选择符中的CLASS属性个数。

统计选择符中的HTML标记名格式。

最后，按正确的顺序写出三个数字，不要加空格或逗号，得到一个三位数。( 注意，你需要将数字转换成一个以三个数字结尾的更大的数)。相应于选择符的最终数字列表可以很容易确定较高数字特性凌驾于较低数字的。

以下是一个按特性分类的选择符的列表：
H1 {color:blue;} /* 特性值为：1 */
P EM {color:purple;} /* 特性值为：2 */
.apple {red;} /* 特性值为：10 */
P.bright {color:yellow;} /* 特性值为：11 */
P.bright EM.dark {color:brown;} /* 特性值为：22 */
\#id316 {color:yellow} /* 特性值为：100 */
从上表我们可以看出#id316具有更高的特殊性，因而它有更高的权重。当有多个规则都能应用于同一个元素时，权重越高的样式将被优先采用。

可能不太好理解，按照上面的权重顺序，先统计ID，再统计CLASS，再统计HTML标记。即：

H1 {color:blue;} /* 特性值为：1 */
P EM {color:purple;} /*特性值为：1+ 1=2 */
.apple {red;} /* 特性值为：10 */
P.bright {color:yellow;} /*特性值为：10+ 1=11 */
P.bright EM.dark {color:brown;} /*特性值为：10+10+1+ 1=22 */
#id316 {color:yellow} /* 特性值为：100 */

可以看出，HTML标记的权重是1,CLASS的权重是10,ID的权重是100。在文章中还提到了继承的权重为0。

文章中提到一个小技巧：

如果想让H1始终为黑色，而EM文字在其他情况下红色，那么下面的样式表设置就是一个很好的方法：

H1，H1 EM {color:black;} 特性值为：1，2 EM {color:red;} 特性值为：1

给定这个规则后，除在H1元素内的任何EM文字就都是红色，而H1内的EM文字仍旧为黑色，由于其选择符分组，在第一条规则中就有两条有效的规则（一条是对H1的，另一条是对H1 EM的）也就有两个特性值——每条规则一个。

这个技巧很有意思，HTML是这样的：

<H1>黑色的H1<EM>黑色的EM</EM></H1>
<EM>红色的EM</EM>

也许你会说是不是跟上面的CSS样式顺序有关系呢？可以试试改成：

EM {color:red;} /* 特性值为：1 */
H1，H1 EM {color:black;} /* 特性值为：1，2  */

效果还是一样的。这也解释了为什么“包含选择符(E1 E2)”的优先级比“类型选择符(E)”要高。

这一点对于在写样式时是很有帮助的，比如我们可以在定义列表的时候用到：

ul{color:red;}
ul li{color:green;}
div ul{color:orange;}
div ul li{color:blue;} 

这样就可以在不用增加像“id=XX”、“class=xxx”等属性的情况下对标签进行分别定义了。

属性选择符的使用

Ghostzhang — 2006-04-17 16:15:00

属性选择符的使用

由 Ghostzhang 发表于 2006-04-17

在CSS的选择符中，除了常用的“类型选择符(E)、通配选择符(*)、包含选择符(E1 E2)、ID选择符(#ID)、选择符分组(E1,E2,E3)、类选择符(E.class)、伪类及伪对象选择符(E:P)”外还有“属性选择符(E[attr])”和“相邻选择符(E1+E2)”，试了一下属性选择符，感觉很不错，如果使用到页面中的话，会让CSS的定义更加的强大，可惜现在IE并不支持这一选择符。

属性选择符可分为下面几种：

Attribute Selectors E[attr] 属性选择符。选择具有attr属性的E。

Attribute Selectors E[attr=value] 属性选择符。选择具有attr属性且属性值等于value的E。

Attribute Selectors E[attr~=value] 属性选择符。选择具有attr属性且属性值为一用空格分隔的字词列表，其中一个等于value的E。

Attribute Selectors E[attr|=value] 属性选择符。选择具有attr属性且属性值为一用连字符分隔的字词列表，由value开始的E。

下面看看例子：

效果展示

我的页面重构经验

Ghostzhang — 2006-03-23 10:19:00

我的页面重构经验

由 Ghostzhang 发表于 2006-03-23

前两天跟群里的『白菜』兄谈到了学习web标准中遇到的问题，觉得很值得写一下，是我对标准的一些理解，希望对在学习web标准的朋友有所帮助。

现在学习web标准的人越来越多，对于刚接触标准的人来说，我想大多数人的第一个印象就是用DIV+CSS制作页面，使用DIV来布局的确是标准的一个主要的特点，但标准并不只是用DIV+CSS布局，看过w3cn网站上的文章，你应该也了解到标准是

由符合标准的XHTML组成；用CSS来布局而不是表格；使用结构化、语义化的标记；能够在任何浏览器中显示

最后二点被大多数学习标准的朋友所忽略，结果就是现在很多用DIV+CSS制作的所谓”用标准制作”的页面，一查看源文件，都是 <DIV> <DIV> <DIV>……</DIV> </DIV> <DIV> …… </DIV> …… </DIV> ……，这样的页面在不支持样式表文件的浏览器中就是一堆没有分隔的文字，阅读都有困难，更谈不上可访问性了。『使用结构化、语义化的标记』是标准的一个重点，因为这直接就对不支持样式表文件的浏览器起作用。

下面是我的制作页面的一点经验，权当是总结吧，跟大家分享一下：

第一阶段

开始制作的时候，应该先从没有样式表文件的页面做起，做到最基本的结构，就是使用结构化、语义化的标记，如用ul,li标签或dl,dt,dd标签等，这时你可以先不考虑布局的问题，只要做到在没有样式表文件的情况下也可以正常的阅读页面中的内容就可以了。要注意使用符合标准的(X)HTML语言，在这个阶段中不使用DIV标签。

第二阶段

当完成第一个阶段后，再来就是布局了。我们要使用支持标准的浏览器来做为制作时查看的浏览器，推荐使用Firefox。这是为了让我们制作出来的页面更接近标准。这个阶段也要注意少使用DIV标签，因为CSS可以应用于任意的标签上，要好好利用现有的标签，只有当没有标签可以定义或现在的标签不能满足布局上的需要时，再使用DIV标签进行布局。也许你会觉得奇怪，为什么要少用DIV标签呢？因为DIV标签没有语义，添加过多的DIV标签会影响源文件的可读性，不利于日后的维护。

这阶段还有另一点需要注意的，就是图片的问题，图片分为”内容图片”和”背景图片”两种。意思很明显，内容图片就是用于内容中的图片，可使用img标签加入，注意要加alt属性；而背景图片就是用于装饰页面的图片，使用CSS的background-image属性加入。这一步也是为了保持我们上一步的成果，使之在没有样式表文件的情况下也不影响到显示。

第三阶段

做完上面两个阶段，你的页面基本上已经可以通过W3C的验证了。现在我们来让它偏离一点标准，使它兼容多个浏览器。这个阶段是很无奈的，为什么呢？在IE中打开刚刚制作的页面就清楚了，也许你已经看到，整个页面的布局乱了。因为浏览器对CSS样式的兼容问题，使到我们现在还要做这一步。这时就得出动多个浏览器啦，最基本的IE5/IE5.5/IE6/FF，目前我就只有这几个版本的浏览器，应该也已经足够了吧。因为是在FF中做的页面，所以现在主要要解决页面在IE中的显示问题，在我BLOG上可以找到相关的一些资料，主要是使用hack，但hack不是标准，所以使用hack有可能会通不过W3C的代码验证。

我们不能为了通过验证而做页面，验证只是一种手段，让你知道页面是否符合基本的规范，但能通过验证，并不就是说你的页面达到标准，只能表示没有语法错误，象最开始提到的用DIV+CSS布局的页面，也是可以通过验证的。

还有就是一些细节，主要是一些制作上的习惯问题，像关闭每个标记、标记的每个属性都要有值等等，可能会觉得很烦琐，但只要在制作的时候注意一下，慢慢成为习惯，对于提高页面质量和制作效率是很有帮助的。

由于本人的写作能力有待提升，如果看得不太明白，欢迎给我留言。

用JS读取XML的例子

Ghostzhang — 2006-03-21 01:27:58

用JS读取XML的例子

由 Ghostzhang 发表于 2006-03-21

刚开始学XMLHTTP，试写的一个读取XML的JS脚本，没什么技术含量，主要用来读取一个类似于通讯录的XML文件。

xml

<?xml version="1.0" encoding="utf-8" ?>
<hhitshop>
 <shop>
  <name>aa</name>
  <phone>01234567</phone>
  <fax>01234567</fax>
  <address>aaaaa</address>
 </shop>
 <shop>
  <name>bb</name>
  <phone>12345678</phone>
  <fax>12345678</fax>
  <address>bbbbb</address>
 </shop>
 <shop>
  <name>cc</name>
  <phone>23456789</phone>
  <fax>23456789</fax>
  <address>ccccc</address>
 </shop>
</hhitshop>

Javascript

Photoshop各种版本趣味大收集

Ghostzhang — 2006-02-27 15:41:00

Photoshop各种版本趣味大收集

由 Ghostzhang 发表于 2006-02-27

PhotoshopNews 公布了由 Jeff Schewe 收集的，Photoshop 历年以来——从 Display 0.07 （Photoshop 的前身）到目前为止最新版 Photoshop CS2 ——各个版本的启动画面及彩蛋。而我们 PConline软件资讯栏目曾经在《傲视群雄——平面设计霸主Photoshop辉煌十三载》一文章中介绍过 Photoshop 带有传奇色彩的发展成长故事。现在就让我们通过这些图片一起再来回顾一下 Photoshop 的演变历史。

1、Display 0.07（即 Photoshop 的前身）

Display 0.07 启动画面

2、Photoshop 0.87 启动画面 (Barneyscan XP)

Photoshop 0.87 启动画面

Photoshop 0.87 彩蛋

译者说明：原文是“Alt Screen”，即“两者间进行切换的屏幕”。这里我们统一称之为“彩蛋”(Easter Egg)。 提示：如何显示彩蛋？

对于 Windows 系统：点击“帮助”菜单，按住 Ctrl 键不放，再从弹出下拉菜单中点击“关于Photoshop”命令即可。
对于 Mac OS 系统：点击“帮助”菜单，按住 Cmd 键，再从弹出下拉菜单中点击“关于Photoshop”命令即可。

3、Photoshop 1.07 零售版启动画面，1.0 版发行日期：1990年2月

Photoshop 1.07 零售版启动画面

Photoshop 1.07 彩蛋

4、Photoshop 2.0.1 零售版启动画面。2.0 版发行日期：1991年6月，2.01 版发行日期：1991年12月。

Photoshop 2.0.1 零售版启动画面

Photoshop 2.0.1 彩蛋

5、Photoshop 2.5 零售版启动画面。2.5 版发行日期：1993年2月，2.5.1 升级版日期：1993年7月。

Photoshop 2.5 零售版启动画面

Photoshop 2.5 彩蛋

6、Photoshop 3.0 零售版启动画面。 3.0 版发行日期：1994年9月，3.05 升级版发布日期：1995年6月。

Photoshop 3.0 零售版启动画面

Photoshop 3.0 彩蛋 (by Mark Hamburg)

7、Photoshop 4.0 零售版启动画面。 4.0 版发行日期：1996年11月，4.01 升级版发布日期：1997年4月。

Photoshop 4.0 零售版启动画面

Photoshop 4.0 彩蛋 (by Joseph Kelter)

8、Photoshop 5.0 零售版启动画面。 5.0 版发行日期：1998年5月，5.01 升级版发布日期：1998年6月。

Photoshop 5.0 零售版启动画面

Photoshop 5.0 彩蛋 (by Jeff Schewe)

9、Photoshop 5.5 零售版启动画面。 5.5 版发行日期：1999年7月。

Photoshop 5.5 零售版启动画面

Photoshop 5.5 彩蛋 (by Jeff Schewe)

10、Photoshop 6.0 零售版启动画面。 6.0 版发行日期：2000年10月，6.01 升级版发布日期：2001年2月。

Photoshop 6.0 零售版启动画面

Photoshop 6.0 彩蛋 (by Mike ‘The Cigarette Smoking Man’ Shaw)

11、Photoshop 7.0 零售版启动画面。 7.0 版发行日期：2002年4月，7.01 升级版发布日期：2002年7月。

Photoshop 7.0 零售版启动画面

Photoshop 7.0 彩蛋 (by Mike ‘Tabletmeister’ Shaw)

12、Photoshop CS (8.0) 零售版启动画面。 CS (8.0) 版发行日期：2003年10月。

Photoshop CS (8.0) 零售版启动画面

Photoshop CS (8.0) 彩蛋 (by Jeff Tranberry)

13、Photoshop CS2 (9.0) 零售版启动画面。 CS2 (9.0) 版发行日期：2005年4月下旬（原定5月，但Photoshop CS2 提早出货）。

Photoshop CS2 (9.0) 零售版启动画面

Photoshop CS2 (9.0) 彩蛋 (by Chris Smith)

关于CSS Hacks

Ghostzhang — 2006-02-08 21:24:43

关于CSS Hacks

由 Ghostzhang 发表于 2006-02-08

今天在SIC的BLOG上看到了一篇日志，很有感觉，转下来分享下。

现在用 CSS 的人越来越多了. 为了解决不同浏览器之间 CSS 支持的不同, CSS Hacks 诞生了.

始作俑者的叹气主题: http://tantek.com/log/2005/11.html

在里面他写到了 CSS Hack 的使用时几点愿望:

有效. 能够通过 Web 标准的验证.

只针对太古老的/不再开发的/已被抛弃的浏览器. 而不是目前的主流浏览器.

代码要丑陋. 让人记住这是一个不得已而为之的 Hack, 时刻记住要想办法去掉.

但是现在, 很多 Hacks 已经抛弃了以上的原则. 结果, 自然是导致标准更难以被支持.

从诞生到滥用, 也不过区区 1 年. 现在使用 CSS Hack 甚至被很多人认为是理所当然的. 除了叹气, 还能如何?

CSS Hack 查询表格: http://centricle.com/ref/css/filters/

现在的确有点对CSS Hack过于热衷了，为了兼容不同的浏览器，使用了大量的CSS Hack，CSS Hack是标准吗？不是标准为何可以通过验证？这会使标准变成“畸形”。

关于CSS样式的优先级问题

Ghostzhang — 2005-10-19 18:36:00

关于CSS样式的优先级问题

由 Ghostzhang 发表于 2005-10-19

在CSS中，你可以为同一个标签定义多个样式，如下面的例子：

#aaa{
   background-color: Fuchsia;
}
.ab{
   background-color: Black;
}
td{
   background-color: Aqua ;
}

<table>
<tr>
<td class="ab" id="aaa" style="height:200px;width:200px;background-color: Blue;"></td>
</tr>
</table>

这么多的样式，哪个是有效的呢？我们一个一个把上面的样式删除，在浏览器中可以看到： style的优先级最高，然后是id，再来是class，最后才是td 另外，使用!important可以改变优先级别为最先，如下：

#aaa{
   background-color: Fuchsia;
}
.ab{
   background-color: Black;
}
td{
   background-color: Aqua !important;
}

<table>
<tr>
<td class="ab" id="aaa" style="height:200px;width:200px;background-color: Blue;"></td>
</tr>
</table>

td将会显示为Aqua 即优先级变为td，然后是style，再来是id，最后是class

注：谢谢QQ48251710的朋友指出了文章中的一个错误，现已经改正。