前端技术 « Alipay UED

2010.7.28

打败 IE 的葵花宝典：CSS Bug Table

作为一名前端，我们通常要做的就是让页面在各系统A-Grade浏览器，甚至网站浏览份额0.1%以上的浏览器上良好显示。当然，还有性能问题。不过，今天要说的是样式的兼容问题。在IE/Mozilla/Webkit/Opera四分天下的今天，IE6-9/Mozilla（Gecko）系列/Chrome/Safari/Opera etc. 这些浏览器的兼容，无不让前端们头痛。而在这之中，最让人头痛的当数IE，特别是IE6。搞定了IE6，基本也就能称霸半个江山了。搞定了IE，也相当于占领了7、80%的领地。你想做一个统治页面兼容的主么？反正我是想的。

今天，趁着想完善公司的内部样式框架，把HasLayout.net的IE CSS Bug过了一遍。整理中收获了不少东西，一些官方的不足，也根据自己的知识升级了一下。当然，也顺利地升级了框架的一些内容，感觉甚爽。随后，便将一些值得去看的Bug整理成一个列表，基于Alipay前端伟大的分享精神，分享出来以供团队工友们和大家参考。

同时，由于整理仓促，有些理解和表达不当和其他纰漏在所难免，还请大家帮忙更正。谢谢。

More »

2010.6.20

JavaScript for: i++ vs i–

前端技术 | 太伯

JavaScript 循环中，i++ 与 i– 那个比较快？相信有不少朋友看过相关的讨论文章，比如这篇。文章解释了开启优化选项后，i– 的 Java 代码节省了 1 条指令，从而可以运行得更快。那么，JavaScript 上运用 i– 是否有同样的表现呢？

这里试图从语言层面分析造成差异的原因，并展示不同 JavaScript 运行环境产生的差异。

JavaScript Loop: Optimization of Weak Typing

点这里以更大窗口阅读。

2010.6.4

杂谈产品灰度上线的研发模式

交互设计, 产品设计, 前端技术 | 老鱼

传统的产品研发模式大致可以分为：产品调研-架构评估-产品启动-需求分析-产品设计-产品开发-产品发布七大阶段。本人在公司经历过大大小小的项目数以百计，发觉这些阶段一直以来都是以一条直线的形式串行着：从产品调研到产品发布，总是一拖到底。这样的做法对于范围比较大，周期比较长的项目，尤其是用户体验类项目而言，存在较大的弊端：我们很可能在没有足够清楚用户需求的情况下，定制了过多的辅助功能，这样即拉长了项目周期，又无谓的投入了过多的人力，在资源如此宝贵的今天，浪费资源实在太过奢侈，我代表春哥鄙视之…

言归正传，切入今天要谈的话题 —-“产品灰度上线的研发模式”。何谓“灰度上线”，简单点理解就是按产品需求优先级，抽出核心需求，在满足用户基本要求的情况下快速上线，并通过限制流量、白名单等机制进行产品试用，以此收集用户的意见，从而萃取出用户潜在的需求，形成后续更有针对性的设计方案。

和传统研发模式相比，这么做唯一的区别就在于将原先一锅粥式的需求和功能点进行了轻重缓急的排序，并以此将项目从原来的单长线作战转化为多迭代短线循环，让产品的生命周期不再昙花一现。

迭代开发

如此一来，需求分析阶段显得尤为关键，我们必须清晰的将需求按优先级归纳分类为几个序列，如：p1,p2,p3…核心功能和必备的体验在p1序列，辅助功能点和辅助型体验列在p2序列，争执不定的需求点可以放在p3序列。需求排序后，我们可以将项目发布点有序的分成（>2期），第一期只确保主要的核心功能和基础体验快速灰度上线，随后通过用户访谈、产品的tracker&session数据、业务数据等手段分析出用户对产品的真实反应，并以此调整二期需求，该加的加，该砍的砍，做到有的放矢。

有画面有真相，我们就以支付宝个人版三期中提醒代扣项目的研发始末为反例，正视我们现有研发模式中存在的问题：整个项目从产品启动到产品发布历时近3个月之久，发布后却尴尬的发现用户的青睐程度并不高，甚至可以用“门可罗雀”来形容产品使用率之惨淡，当然产品的始作蛹者可以推托怪罪于运营力度不够，也可以感慨产品的身不逢时，但是作为产品的设计者，在用户需求并不明朗，且欠东风的情况下除了核心功能，你完全没必要夹杂过多的辅助功能、体验…试想，在这个项目中，我们采用灰度上线的研发思路，那么这款产品的核心功能上线周期将缩短一倍有余，我们将赢得足够的时间观察用户，并形成相应的运营策略以及产品体验的优化策略。比之将产品一捅到底后奄奄一息，合理的规划迭代研发将使你的产品呈现出更旺盛的生命力，这样才可能撑过你感叹的“身不逢时”。

再议构建前端UI组件的新思路

前端技术 | 老鱼

近日，看了玉伯写的《构建前端UI组件的新思路》一文，让我追忆起去年自己分享的一篇P文《随感协同开发的JS设计模式》，有几分共鸣……

话说去年支付宝新版收银台项目中，我就小试了一把这种组件编码模式，点滴心得，这里和大家做一个交流：

回顾一下之前说到的抽象类，对设计模式有所了解的同学可能会觉得有些眼熟，没错，初一看，觉得它很像一个抽象工厂，但是结合下面的基础类来看，你会发觉我并没有在各基础类中，重写getVessel,show,hide等方法，而是直接继承了抽象类中的这些方法。一定会有人不解为什么要这么做，无他，就因为他是JS,而非JAVA。一定的偶合度换来足够的灵活在我看来一点都不过分，更何况这个抽象类是必须确保绝对稳定的，他在成形后不允许被随意修改那是必须的。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

AP.widget.basic = new AP.Class({
setOptions:function(options){
//接口设置
},
initialize:function(targets,options){
//初始化方法，目的是建立targets子集元素和某方法的关联
},
getVessel:function(target){
//获取满足target映射关系的容器
},
bindEvents:function(target,vessel){
//这里绑定target的触发动作
},
action:function(){
//target绑定的事件触发的执行函数，包含你要执行的逻辑
},
show:function(){
//显示容器
},
hide:function(){
//隐藏容器
},
setInterface:function(){
//设置各组件共用接口
}
})