昨日的交互分享会， 李坏兄弟的 PPT 引起了很大的讨论，这是件好事。作为名前端开发人员，虽然没有像交互设计师样的深入，但是毕竟也属于具体产品的实践者，在这里谈下本人的拙见。

交互设计不是以用户为中心的设计，而是以用户目标为中心的设计

坦白的讲，这句话本人理解参半。平时说多了「以用户为中心」，在这里又出现个「以用户目标为中心」的概念，凭本人目前的见解需要时间去消化这句话。

在这里有两点的质疑，就是如何区分「用户」和「用户目的」。不同的用户自然会有不同的用户目标，这是非常容易理解的事情。本人认为，这两句话应是站在两个不同的高度（或者角度）去理解。

用户、商业、技术

这个不是原文的话，是本人概括的，原文是「交互们不是委屈的去找这三个圈子兼顾的那小点。要是找出这三个圈子中间那点东西，那你的产品就是不伦不类的。」

对于这个观点，本人需要反驳一下。产品设计中并不是「委屈」的去找那个点，而是找到这三者间的平衡。本人认为，这三者应该是相辅相成的，而不是互相独立甚至排斥的。

现在的中国互联网没有交互设计师

这句话的论据就是，交互需要创新，而「 试问 Web 上哪个控件是中国人发明的 」，本人对观点此保留意见。在这里要说明的是，GUI （图形界面）的发展以及 GUI 控件（按钮、单选框、复选框等）的出现，都是时间、技术、需求等推动的结果，它们都不是一夜时间就全部出现的。

比如试问下，在没有 GUI 之前，程序员对着那黑底白字的 Shell 飞快的操作时，交互设计师此时应该如何设计系统？GUI 为普通用户提供了友好的人机界面，此时交互设计师才能真正的发挥自身的作用。一定的程度上，本人相信「技术推动交互」这句话。

有关 创新 方面，本人认为这是 交互设计师 的必要条件。而好的创新，创新有「改良」和「革命」之分，其两者的不同点就是创新曲线是否是平滑的。容许我狭隘的认为，任何方便用户的改进都是创新， 哪怕只是让用户少一次单击 。

规范不是限制

规范是把双刃剑，它让我们的工作更加严谨的同时，也一定程度上的制约了 创新 -- 这是本次 小马 和 李坏 争论的焦点。

我们能否从另个角度考虑，规范本身其实不是墨守成规的。创新等到成熟了以后，组成了规范并推动其发展；而规范也能进一步的指明创新之路，使其有的放矢。

整个分享会的气氛活跃而又美味（可惜没能抢到爆米花），李坏 兄弟提出的些概念，的确让我们思考和探讨。这就像是理想主义者和现实主义者之间的碰撞，本人作为名「机械的开发人员」，天平明显倾向了现实主义者这边。

听说 FaceBook 开放其网站的代码了 ，期前也算是了解过 FaceBook 的架构，所以重点就是看其代码的质量。

可以毫不夸张的说，FaceBook 的代码质量、风格都不亚于某个开放源代码的项目（当然，并不是每个开源的项目代码都很友好）。我可以用「教科书式」的代码，来形容我眼前所看到的 FaceBook 的源代码。

有点离题了，开发语言（或者工具）的本身，并不能说明系统会有多么的优秀。目前的网络上所能找到的、开源的工具，只要稍加都能很好的提升性能。

锦上添花的就是加上良好的 Cache（缓存）机制。在「上古时代」，人们对于性能上的考虑，还处在程序也算法的优化上。随着 Web2.0 的到来（什么是 Web2.0？）、Ajax 这样的技术的出现，造成服务器处理的请求比平时多得多，此时就需要从宏观上改进整个系统的机制。

很快就出现了大量的相应工具，首先是 Squid 、然后是 Memcached ，最后是具体到 某个语言（比如 PHP）的扩展 。 正如期前所说的 ，Ajax 等前端技术的流行，Cache 技术逐渐从「后台」的点心，转成了「正餐」。

重新回到上述的 FaceBook 中，从上往下看（似乎这图不是完整的逻辑，搞不清楚为什么 Database 会在这个位置），所涉及到的 Cache 技术就有 APC、Memcached、 CDN 以及 浏览器的缓存 。基于这点就能够充分的表明，FaceBook 能够应对如此高的负载的因素之一就是合理的使用 Cache 机制。

Cache 的确是个好东西，但是有时候也带来了不少的麻烦。比如在前端开发过程中，往往就会碰到用户反应样式、脚本无法执行的情况，此时本人就会很机械的告诉他 Ctrl + F5 刷新。

坦白的说，本人认为使用 Cache 在项目中，不应该过分的乐观。Cache 所带来的用户重复刷新（虽然在良好的 Cache 机制下这种情况很少），空间上的逐渐增大（真的是用空间换取时间，想想 FaceBook TB 级别的 Cache 容量吧），这是使用 Cache 所带来的负面效果（但这往往有些技术人员会将此拿来当作炫耀的资本）。

不要将 Cache 作为提升性能的救命稻草。前段时间 Twitter 间歇性的罢工 ，虽然找到瓶颈是数据库。但本人同时也听到某些观点，诸如「如果 Twitter 有良好的 Cache 机制也许就不会这样」，在这里本人保留意见。

请容我胆大的猜想，也许 Cache 会和 Ajax 一样，最终有一天会消失。技术这玩意也就是这样，没有更好的只有最合适的。退一步讲真的到了那一天，Cache 的替代方案也会造成另外的问题也说不准 -- 以后的事情谁知道呢？

想起了一句话，就是

「计算机原先是为了解决麻烦才搞出来的，但是后来它本身就成了麻烦」。

两个都是不大不小的问题，在这里记录一下。

Flash 的遮盖问题

Flash 在默认没有相应参数的情况下，会遮盖 HTML 层并不受 CSS 的 z-index 属性控制。在这里有个简单的方法，就是在 object 中加入

<param value="transparent" name="wmode" />

即可。如果使用了 embed ，务必将此属性也加入

wmode="transparent"

这样，就不会遮盖绝对定位的层了。不过此时 object 还是不受 CSS 的 z-index 控制，寻求解决方案中。

参考链接， 这里 还有 这里 。

Explorer 6 下的 select 遮盖问题

这是个老的问题了，但是如果不小心的话还是出出现。问题是在 Explorer 6 下，某个绝对定位的层无法遮住 select 控件，而解决的办法就是使用 iframe 将其遮住，代码如下：

<!--[if lte IE 6.5]>
<div style="position:absolute;z-index:-1; top: 0; left: 0;">
    <iframe 
       style="filter:alpha(opacity=0); width:210px; height: 110px;">
    </iframe>
</div>
<![endif]-->

因为这仅仅是 Explorer 6 的问题，所以使用了条件注释，避免其他浏览器加入无谓的结构。

期间和 小马 讨论过是否将其写成脚本，回答是「基于效果、或者 BugFix 类的问题，出于效率的考虑，尽量不要使用脚本」。我同意他的观点，比如上述的代码对于其他非 Explorer 浏览器而言，仅仅是注释而已。

进一步的改进，可以使用脚本判断时候否是 Explorer 6 ，并动态加入 iframe 。排除效率的问题，这样操作更通用些。

相关的参考资料： 这里 、 这里 还有 这里 。

最后，上述两个问题的 DEMO 页面 在这里 。

--EOF--

顺便提下， Yupoo 支持 Flash 图像输出了 ，正好在这里用上。不过，我更喜欢直接用原图，这样更通用些。