charies_蔡

面向对象的CSS

charies — Sun, 05 Jul 2009 04:49:32 +0800

“你如何为成千上万的用户和页面提供CSS？” 这是Nicole Sullivan在她的在丹佛的Web Directions North 大会上的幻灯片中尝试回答的问题。得益于面向对象的CSS (OOCSS) ，这个想法从社区收集到了大量的反馈。

OOCSS显然已经不仅仅是一个工具了，它还是一种思考的方式。根据这个观念可以有很多优势，主要来说有：

它可以让你写更快的、可维护的、基于标准的前端代码。
它在CSS中预先加入了一些必须的元素，这样即便是初学者也可以参与写出漂亮的网站。

OOCSS 基于两个主要原理：

分离结构和表现；
分离容器和内容。

建议花些时间看一看面向对象的CSS的幻灯。总共有64页，绝对值得一看。

Object Oriented CSS

View more documents from Nicole Sullivan.

PS:神飞之前就有考虑将此幻灯翻译成中文，但是作者不允许下载，所以大家就将就着看吧先，另外考虑翻译一些相关的文章来更多的解释OOCSS。

PS2，貌似国内也有个人做了一个OOCSS，意思也是面向对象的CSS，不过和这个不是同一个。

原文：http://www.qianduan.net/object-oriented-css.html

“七”乐无穷，尽在新浪新版博客，快来体验啊~~~请点击进入~

工程师与科学家 realazy

charies — Mon, 29 Jun 2009 10:21:37 +0800

入行已久，做的领域也从浏览器扩展到桌面端甚至是手机端，对 Web 标准多少有些自己的看法，今日斗胆一说。

两种家

我们困惑不解、迷惑不安，很大程度上源于没有指导思想。要摆正自己的位置，我们究竟是想做科学家，还是想做工程师。简明扼要，科学家经常要问“为什么”，他们关心了解人类不懂的知识；工程师则利用科学家发现的知识，制造对人类有用的物体或工具。前者研究，后者实战。很明显，我们大多数人属于工程师，W3C 那一群才是科学家。端正自己的态度，很多疑问就会迎刃而解。

两种用法

HTML 生为标记语言，是组织文档的一种格式。随着技术和社会的不断进步，HTML 的用途也逐渐升级。今天它不仅出现在浏览器上（普通网页），它还出现在桌面程序上（Adobe AIR），出现在手机程序上（PalmPre WebOS）；它不仅用来展示网页，也用来构建程序的用户界面。Web 标准要求我们，HTML 必须有良好的语义化，对于展示内容的文档来说，这是毋庸置疑的，但对于只是作为构建用户界面的程序来说，强调语义是没有多大意义的。要注重语义的时候一定不能松懈，只是用户界面而已的话，怎么方便怎么来，利用最方便的手段做最适合的布局。

实用主义的前提

工程师信奉的是实用主义，但不等于可以放弃原则和规范。工程师关键任务是在遵守规范的前提下，发现、理解并结合实际的局限来达到满意的结果。作为一个流量巨大的网站，Google 对待 HTML 的态度是一个非常好的例子，省略</body> 和 </html> 的做法我们何曾想过呢？但这却是符合 HTML 4 规范的。详见： http://code.google.com/speed/articles/optimizing-html.html（需自行翻墙）。

原文地址:http://realazy.org/blog/2009/06/29/engineer-vs-scientist/

“七”乐无穷，尽在新浪新版博客，快来体验啊~~~请点击进入~

如何选择图片格式

charies — Mon, 15 Jun 2009 05:40:26 +0800

GIF

GIF是一种调色板型（palette type）（或者说是索引型）的图片。它含有多达256种的颜色。每一个象素点都有一个对应的颜色值。因为这种格式不再存在专利权的问题（译者注：想简单地了解一下gif的历史,请点这里）,所以你在创建gif图片的时候不会再有被抓进监狱的危险。（想要了解更多关于gif的历史,请点击这里.）

GIF是一种无损压缩的格式，这意味着当你修改并且保存了图片的时候,它的质量不会有任何损耗。

GIF格式也支持动画.在黑暗的web1.0时代，它导致了大量多余的昙花一现的“新”图片（blinking “new” images），循环的@符号（rotating @ signs），birds dropping，a email以及其他一些让人厌烦的东西的出现。在更加文明的web2.0时代，在等待一个更新页面的ajax请求的时候，我们仍然会看到 “loading”动画，但是也有一些比较讨人喜欢的东西,人们喜欢把它们放在自己的网络上。不管怎么说，如果你有需要，就可以使用动画支持。

GIF也支持透明度，透明度的值是一种布尔类型数据。GIF图片里的一个象素要么完全透明,要么完全不透明。

JPEG

JPEG图片不象GIF图片那样只能有256种颜色，它可以包含数百万种颜色，而且有极高的压缩率。这使得JPEG图片比较适合用来保存相片。事实上，大多数的相机以jpeg格式保存照片。JPEG是一种有损压缩的格式,这意味着你每次进行编辑的时候都会有质量损耗，所以如果你打算进行多次编辑，那么最好把中间生成的图片换一种格式存储。但是,还有一些不会损耗图片质量的操作，比如说裁剪图片，旋转图片或者修改元信息。元信息包括，比如说，存储在图片文件中的注释。

JPEG不支持透明度。

PNG

PNG是一种无损压缩的格式，而且它有很多种类。单考虑实际的用途,我们可以把它分为两种：

1.PNG8
2.真彩色PNG

PNG8是一种调色板型(palette)图象格式,就象GIF。 8代表8位, 2⁸, 或者 256。 PNG8, 调色板型PNG以及索引型 PNG，这些术语都可以互换使用。

那么,PNG8比起GIF有哪些优缺点呢？

    优点：
             通常文件体积比较小
             支持alpha（可变）透明度
    缺点：
             不支持动画

第二种类型的PNG格式是真彩色PNG。这类图片可以包含百万种颜色,就象JPEG。你有时候会碰见它们以PNG24或PNG32命名。

那么真彩色PNG和JPEG相比怎么样呢？从优点方面来说,它是无损压缩的而且支持alpha透明度。从缺点方面来说,它文件的体积比较大。This makes truecolor PNG an ideal format as an intermediate between several edits of a JPEG and also in cases where every pixel matters and the file size doesn’t matter much, such as taking screeenshots for a help manual or some printed material.

IE浏览器和PNG透明度

我们说过,前面两种PNG格式都支持alpha透明度。但是你应该知道,有一些浏览器比较反常,它们对这两种类型的文件支持并不完整。

拿PNG8来说,不管什么时候,一些不完全透明的象素在IE（IE6或更低版本）浏览器中会变得全透明。这并不理想,但是它仍然是有用的,你能得到与gif相同的效果。所以使用PNG8的时候,最坏的情况下（ie<7）你会得到与使用GIF相同的用户体验，而使用其他浏览器（比如说 firefox、safari、opera）你会获得一种更好的体验。下面的一个例子说明了这个问题，注意围绕在灯泡周围不完全透明的光晕效果在IE6中是怎么样消失的。

对于真彩色PNG,这种情况带来的麻烦更不易被人察觉。所有不完全透明的象素点在版本7之前的IE浏览器中都变成灰色了(来源：W3C)。

对于PNG8和真彩色PNG，IE7都提供了alpha透明度正确的原生的支持。对于早期版本的IE浏览器你需要使用css和AlphaImageLoader滤镜来修复全彩色PNG中的透明度问题。对于这个问题,在接下来的文章中，我们将会讨论一些更多的细节。

“所有人都在说：给PNG一个表现的机会吧。”

虽然PNG8应该作为PNG类型文件的首选,因为它的文件体积更小而且在早期版本的IE浏览器中不需要使用特别的css滤镜就能很好地降级,但是在使用的时候仍然有需要注意的地方：

1.当PNG8的256种颜色不够用的时候,你可能需要使用全彩色PNG。这种情况应该尽量避免。一方面，如果你想使用成千上万的颜色,那么这种情况下JPEG将会比较适合,而且能够有更好的压缩率。另一方面，如果颜色数在一千左右,你应该尽量把这种图片转换为PNG8格式,然后看看它是不是看起来还能够接受。很多情况下,当颜色数达到200到1000的时候,人的肉眼就分辨不出来了。当然，这也得看是哪种图片了；通常你可以非常安全地删掉1000种颜色,但是有些时候只是删掉2种颜色,图片的效果就不能让人接受了。不管怎么样, 尽可能地把真彩色PNG转换为PNG8和JPEG格式，看看你能不能接受它们的质量和体积。
2.图片的大部分象素是半透明的情况。如果图片种只有一小部分是不完全透明的,象围绕在圆角周围的象素点,那么PNG8的类GIF(GIF-like)降级通常都没有问题。但是如果图片的大部分是半透明的（象视频播放器上的播放按钮）,那么你除了使用AlphaImageLoader hack你可能别无选择。

最后，让我们总结一下我们刚刚讨论的主要内容：

1.JPEG格式比较适合用来存储照片
2.GIF格式可以用来做动画
3.PNG8可以用来做小图标（icons），按钮，背景等等。

“七”乐无穷，尽在新浪新版博客，快来体验啊~~~请点击进入~

JavaScript,5种调用函数的方法

charies — Tue, 31 Mar 2009 05:57:31 +0800

JavaScript,调用函数的5种方法

一次又一次的,我发现,那些有bug的Javascript代码是由于没有真正理解Javascript函数是如何工作而导致的(顺便说一下,许多那样的代码是我写的).JavaScript拥有函数式编程的特性, 当我们选择面对它的时候,这将成为我们前进的阻碍.
作为初学者,我们来测试五种函数调用的方法,从表面来看我们会认为那些函数与C#中函数的作用非常相似,但是我们一会儿可以看到还是有非常重要的不同的地方的,忽视这些差异无疑会导致难于跟踪的bug。.
首先让我们创建一个简单的函数,这个函数将在将在下文中使用,这个函数仅仅返回当前的this的值和两个提供的参数.

JavaScript函数调用规则1
在没有通过明确所有者对象而直接调用的函数中，如myFunction()，将导致this的值成为默认对象（浏览器中的窗口）。

函数调用
让我们现在创建一个简单的对象,使用 makeArray函数作为它的一个方法,我们将使用json的方式来声明一个对象,我们也来调用这个方法
//creating the object
var arrayMaker = {
    someProperty: 'some value here',
    make: makeArray
};

//invoke the make() method
arrayMaker.make('one', 'two');
// => [ arrayMaker, 'one', 'two' ]
// alternative syntax, using square brackets
arrayMaker['make']('one', 'two');
// => [ arrayMaker, 'one', 'two' ]

看到这里的不同了吧,this的值变成了对象本身.你可能会疑问原始的函数定义并没有改变,为何它不是window了呢.好吧,这就是函数在 JSavacript中传递的方式,函数在JavaScript里是一个标准的数据类型,确切的说是一个对象.你可以传递它们或者复制他们.就好像整个函数连带参数列表和函数体都被复制,且被分配给了 arrayMaker里的属性make,那就好像这样定义一个 arrayMaker:
var arrayMaker = {
    someProperty: 'some value here',
    make: function (arg1, arg2) {
        return [ this, arg1, arg2 ];
    }
};

JavaScript函数调用规则2 在一个使用方法调用语法,像 obj.myFunction()或者 obj['myFunction'](),这时this的值为obj

这是事件处理代码中bug的主要源头,看看这些例子
<input type="button" value="Button 1" id="btn1" />
<input type="button" value="Button 2" id="btn2" />
<input type="button" value="Button 3" id="btn3" onclick="buttonClicked();"/>

<script type="text/javascript">
function buttonClicked(){
    var text = (this === window) ? 'window' : this.id;
    alert( text );
}
var button1 = document.getElementById('btn1');
var button2 = document.getElementById('btn2');

button1.onclick = buttonClicked;
button2.onclick = function(){   buttonClicked();   };
</script>

点击第一个按钮将会显示”btn”因为它是一个方法调用,this为所属的对象(按钮元素) 点击第二个按钮将显示”window”因为 buttonClicked是被直接调用的(不像 obj.buttonClicked().) 这和我们第三个按钮,将事件处理函数直接放在标签里是一样的.所以点击第三个按钮的结果是和第二个一样的.
使用像jQuery的JS库有这样的优点,当在jQuery里定义了一个事件处理函数,JS库会帮助重写this的值以保证它包含了当前事件源元素的引用,

//使用jQuery
$('#btn1').click( function() {
    alert( this.id ); // jQuery ensures 'this' will be the button
});

jQuery是如何重载this的值的呢?继续阅读

另外两个:apply()和call()
你越多的使用JavaScript的函数,你就越多的发现你需要传递函数并在不同的上下文里调用他们,就像Qjuery在事件处理函数里所做的一样,你往往经常需要重置this的值.记住我告诉你的,在Javascript中函数也是对象,函数对象包含一些预定义的方法,其中有两个便是apply()和 call(),我们可以使用它们来对this进行重置.
var gasGuzzler = { year: 2008, model: 'Dodge Bailout' };
makeArray.apply( gasGuzzler, [ 'one', 'two' ] );
// => [ gasGuzzler, 'one' , 'two' ]
makeArray.call( gasGuzzler, 'one', 'two' );
// => [ gasGuzzler, 'one' , 'two' ]
这两个方法是相似的,不同的是后面的参数的不同,Function.apply()是使用一个数组来传递给函数的,而Function.call()是将这些参数独立传递的,在实践中你会发现apply()在大多数情况下更方便.

JSavacript函数调用规则3 如果我们想在不复制函数到一个方法而想重载this的值的时候,我们可以使用 myFunction.apply( obj ) 或 myFunction.call( obj ).

构造器
我不想深入研究在Javascript中类型的定义,但是在此刻我们需要知道在Javascript中没有类,而且任何一个自定义的类型需要一个初始化函数,使用原型对象(作为初始化函数的一个属性)定义你的类型也是一个不错的主义,让我们来创建一个简单的类型
//声明一个构造器
function ArrayMaker(arg1, arg2) {
    this.someProperty = 'whatever';
    this.theArray = [ this, arg1, arg2 ];
}
// 声明实例化方法
ArrayMaker.prototype = {
    someMethod: function () {
        alert( 'someMethod called');
    },
    getArray: function () {
        return this.theArray;
    }
};

var am = new ArrayMaker( 'one', 'two' );
var other = new ArrayMaker( 'first', 'second' );

am.getArray();
// => [ am, 'one' , 'two' ]

一个非常重要并值得注意的是出现在函数调用前面的new运算符,没有那个,你的函数就像全局函数一样,且我们创建的那些属性都将是创建在全局对象上 (window),而你并不想那样,另一个话题是,因为在你的构造器里没有返回值,所以如果你忘记使用new运算符,将导致你的一些变量被赋值为 undefined.因为这个原因,构造器函数以大写字母开头是一个好的习惯,这可以作为一个提醒,让你在调用的时候不要忘记前面的new运算符.
带着这样的小心,初始化函数里的代码和你在其他语言里写的初始化函数是相似的.this的值将是你将创建的对象.
Javascript函数调用规则4 当你将函数用作初始化函数的时候,像MyFunction(),Javascript的运行时将把this的值指定为新建的对象.

总结
我希望理解各种函数调用方式的不同会使你的Sjavacript代码远离bugs,有些这样的bug会确保你总是知道this的值是避免他们第一步

“七”乐无穷，尽在新浪新版博客，快来体验啊~~~请点击进入~

XHTML原型开发－用代码说话

charies — Fri, 27 Mar 2009 12:04:10 +0800

如果你正在给标准的网页和应用程序（比如用XHTML/CSS/JS开发的）设计用户体验，那就有充足的理由把XHTML原型（prototype）开发加入你的UX工具集。也许你已经发现传统的线框（wireframes）图功能有限，也许你正在寻找更强大的方法去制作并说明你的设计方案；也许你现在的工作是基于传统的瀑布模型（waterfall model）的（比如，首先创建线框图，然后交给设计，然后交给开发，等等），但你需要更加同步的方法，比如敏捷迭代开发（agile and iterative development）。不管用什么方法，通过XHTML开始你的原型设计将帮你更好的踏上这一旅程。

那么，用XHTML进行原型设计开发到底是什么意思？实际上，它就是使用XHTML及其相关技术去生成并确定你的设计方案的过程。那么一个 XHTML的原型看上去什么样呢？这个问题，就像我们后面会看到的，其实取决于原型开发所在的步骤，一个XHTML原型通常看上去跟其他使用XHTML制作的网页是一样的，带有一些演示性的链接和特性。换句话说，也就是你用XHTML开发的东西，不管是客户网站还是企业应用，都可以用XHTML来制作原型。后面我们还会看到，这种方法相对于线框图或其他原型工具来说，都有着很多的优势。

一个迭代的过程

由于XHTML原型开发不是绑定到某个具体设计环节的，使得迭代开发大大增强了它的效果。原因有很多，但也许最显著的原因是原型及后来的程序这两者共同构成了设计说明。我们还会对这一点稍加解释（见“XHTML如何兼作设计说明”），但首先让我们看看XHTML原型开发的全过程。让我们从一个更宏观的设计进程的角度开始。

在这种（迭代）方法中，不会在开发之前对整个应用程序进行设计，而是先设计程序的一个节点（unit），然后使用这个节点充当其他程序节点的起始点。与其他的设计方法一样，整个设计过程始于草图（sketching），草图对原型的开发起到了重要作用。

草图法：一件形式自由的事情

“草图”这个词在这里指代那些不受特定技术限制的、自由的开发形式。包括制作线框图（通常要多次重绘），以及使用特定的工具来修改草图。当使用草图法来帮助思考、或演示给领导看的时候，一旦你的设计思路有了新的改进，你自然会放弃那些已经过失的线框图。但这时候往往已经开发出来一个原型产品了。在我所在的设计团队里，我们发现当使用XHTML开发原型时，线框会显得多余，而且，把草图直接变成原型会省事得多。

原型法：一个明确的回答

原型与草图有着对应关系。借用比尔巴克斯顿的话说，草图会带来一个问题：“这是一个好的创意吗？”－原型会告诉你答案。藉由对创意的具体表现，原型法综合了现有产品开发技术的实际情况和所能达到的用户体验水平，并且提供了一个方法，对你的设想进行明确而清晰的质量评价。

原型开发/打造关联

使用XHTML进行开发的时候，特别是在一个迭代模型中，开发和原型制作往往会纠缠在一起。如果你正在制作一个新应用或新产品的原型，XHTML原型实际上只是未来实际产品的一个草案。但是，当对现有程序进行升级设计的时候，现有产品的版本就能作为新的升级方案的一个起始点。

三个综合层次：结构(Structure)，行为(Behavior)，基础(Foundation)

XHTML原型开发的模型基于实际网站产品的最佳实践模型：首先用XHTML进行基础开发，然后用CSS添加表现层，接下来用JavaScript加入行为层，然后迭代。

我们从结构层开始讨论。

结构层：建立页面的基本结构

XHTML原型开发的第一步是建立一个基本结构。与线框图的制作类似，我们首先要表现出页面上的主内容区，不同的是我们用基于文本的XHTML语言来进行标记。

如果我们的草图或线框貌似这样…

我们的XHTML可能貌似这样：

…

XYZ Application

My Account

Account options

Account details

Account Help

[footer]




            … 

            (We're only displaying the relevant snippet of the XHTML here.)

接下来，我们添加预先定义好的详细内容元素，为相应的内容使用恰当的XHTML结构。

比如，如果我们的详细草图貌似这样…

我们会把AccountHelp主题列表显示成一个无序列表（比如使用ul标记）：

…

Account Help

…

通过继续给页面添加详细的内容，我们实际上制作出了一个该页面的结构化的内容目录。它可以作为其他原型产品的一个基础。线框主要是在一个特定的布局形式之中体现页面的信息架构，但我们的方法则是纯粹的结构和层次，依我看来，能更好的表现一个网页上的真正的信息架构。

通过使用XHTML来直接定义信息的架构，我们还可以轻松的定义出与可达性（accessibility）相关的属性。比如发现那些使用屏幕阅读器来遍历网页的用户是怎样体验网页以及相应的内容区块的。另外，我们也更容易定义那些在线框图中容易忽视掉的元素，比如表单中的标签（Label）标记。

如果想要在浏览器中查看这个结构层，那基本上会看到一个非风格化的网页，而且会看上去比较无趣。虽然基础层并不以支持表现层见长，但基础层的质量会影响它所支持的表现层，所以结构层的质量也会严重影响网站的整体质量。但事实上，对样式的忽略却恰恰是使用XHTML的重要优势所在。

改进表现层

有了一个恰当的结构，我们就可以开始侧重于如何展示内容了。再看看以前的那些草图，我们已经具备了一定的布局概念，那么就可以开始往结构里面添加内容了。在不同的团队里，开发和制作外观（look and feel）的方法有很大不同。当你使用设计样稿（design comps）开始尝试外观设计时，特别是当你也同时负责整体的品牌设计时，重新设计样稿是比较划算的，就好像重绘线框图一样。正如草图有利于线框图，设计样稿也利于最初的外观设计。但现实工作中那些制作完整的表现层往往脱离了技术实际，最后不得不进行剪裁并批量的应用到网页上，就像给建筑物的外墙刷漆。而且这种静态的绘制软件外观的方法难以兼顾到网页上所有的动态元素。但是，如果使用XHTML来开发原型，则可大大提升外观实现的水平。用户可以参加到设计中来，用户提供的快速而丰富的反馈意见，可以帮助我们逐步改进页面的表现层。

以前在绘制（illustration）软件的时候，有些问题是难以显露的，但现在则会变得很明显。包括那些设计方案与浏览器之间的问题。比如设计是否应当居中这类基本问题，以及那些更复杂的问题，比如如何设计以适应不同窗口尺寸和浏览分辨率的问题。举例来说，对于较小的窗口尺寸，是否允许部分内容跑到视图外面？或者让内容自动适应窗口的尺寸？当使用绘制法来处理外观问题时，这类问题常常无法发觉，从而损害到用户体验。

添加行为层：少作无用功

用XHTML开发原型时，你是在整个网站的大环境下进行设计。这些设计会不断的加入你的实时更新的UI库。你不再是面向一个具体的功能点进行设计，而是由Google来通知你哪些人已经设计开发了类似的东西，并使用这些已有的东西作为你的解决方案的出发点。这些东西可以无所不包，从日期选取器到 WEB控件，再到那些刚刚诞生的顶尖级UI创意。此外，XHTML原型开发可以很轻松的集成或模拟WEB2.0功能，比如内置控件和内容聚合（syndication）。如果你不懂JavaScript或其他相关技术，你可以跟开发人员合作来集成你的方案。当然，有时从网上找不到符合你的设计需求的解决方案，这种情况下，还是回过头来画草图，并且跟你的团队好好合作吧。

迭代：发现，改进

原型法的真正强大之处是在迭代过程中发挥出来的，也就是用户与你的原型产生交互的时候。在最近的一个项目中，我们设计了一个草图方案，用户可以从一个库中拖拽视频文件放入播放列表。看着那份静态的草图，貌似简单又简练。但是当用户真正开始使用的时候，拖放视频的缩略图时，他们却发现这种动作极为不爽，尤其是拖放大量视频时。换句话说，原型让我们得以发现那些隐藏在线框图后面的设计问题。

随之而来的核心问题，就是使用静态图形来讨论交互方案。静态图形等于是强迫用户用自己去想象，在想象中一切功能都极为完美。但是用XHTML，我们则把这种对用户认知能力的挑战降到最低，让他们去实际体验和感受一个几乎就是真实产品的东西。

只要用户作出了反馈，那么团队就开始进行下一次迭代。另一个在原型法中用于评估质量的角色加入进来：迭代的速度有多快？迭代耗费的时间越长，原型的价值就越低。用XHTML做原型开发时，迭代可以近乎神速，这首先是由于原型易于呈现给用户，因为它仅仅是一个发布文件然后发送URL的问题。其次，XHTML是基于文本的，它的迭代（比如修改文本或更新基本功能）仅仅需要几分钟。就算高级的设计修改，通常也不会超过几个小时。

XHTML如何兼作设计说明

XHTML的一项最牛的本领，就是自描述性（self-describing）。XHTML标记在告知浏览器如何显示数据的同时，还可以变成程序员的设计说明。举例如下：

这个标记

会被读作

用时髦的话来讲，我们写的是“语义有意”标记（semantically meaningful markup）。也就是说我们选用的标记、命名的ID和Class是可以传达其实际意义和功能的。

注释仅对个别人可见

XHTML作为设计说明的另一个好处在于，ID和Class名可以兼作注释参考。换句话说，在你的说明中，ID为“账户选项” 的内容区的注释将会显示在标题“账户选项”下面。

使用线框图时，常见的做法是在页面的顶部按编号列出模糊、杂乱的注释。这种注释会给非技术性读者造成困扰和负担。但XHTML的注释则只放在标记中，只有感兴趣的程序员才会看到。而且由于XHTML文件自身的信息很丰富，实际上注释只需写成简短的要点即可。

更标准，无干扰

线框图的最大缺点之一是缺乏标准的标记。也就是说你和我彼此看不懂对方的图。这就迫使视觉设计师和程序员们不得不去翻译我们的大作，其结果就是作者与读者间产生了误解。为了弥补这个问题，我们需要制作极为详细的线框图，还得添加长长的注释去解释图的含义，说明图的元素如何工作。这样，慢慢地就会累积起大堆的说明文档，而且变成无法维护的极端“劳动密集型”工作。一旦无法及时更新，整个团队就会放弃这种设计说明，接下来就会发生各种糟糕的事情。与线框图相比，XHTML提供了标准化的注释，任何了解XHTML的用户都可以直接阅读。更重要的是，你的读者（开发人员）是使用流畅的日常语言来阅读的。而且那些不关注XHTML的读者也可以只选择阅读他们关注的部分，要做的就是打开浏览器而已。

使用标准的注释也就意味着你不会被限定在特定的线框软件或原型软件中，你可以用各种方法，不管是一个简单的文本编辑器还是各种各样的XHTML编辑工具。同时XHTML语法精炼，不象线框图那样繁琐，再加上你只需要编写文本文件即可，只需要通过浏览器就可以看到效果，这就能够帮助你工作的更快捷、更高效。

事半功倍

如果你是XHTML新手，你将会发现XHTML能让你事半功倍。只需要花费几个小时，学习一下网上众多的在线教程，你就可以立即开始书写 XHTML。（有两个好推荐：htmldog.com / w3schools.com）而且更妙的是，你不必耗费心思钻研那些时髦的UX工具，就可以深入的领会这种帮你实现创意设计的技术。

分而治之

从蓝图到草图，对线框图的一次次重绘将导致一系列连锁效应，页面或程序设计的工作分配和时间计划都将受制于它。当一个粗糙的设计描画出来后，团队中的一个人就不得不独自奋斗一阵子，把每个页面的草图设计都制作成细节丰富的线框图。但XHTML模式则提供一种分而治之的方法。在我的团队中，我可能负责初始部分的XHTML以及一部分CSS，而其他成员则在我的基础上修改XHTML，加入更多的高级CSS，还有JS。如果解决方案是团队共同提出的，那为什么不让团队所有人来共同设计呢？换句话说，与其用某人的观点来代替团队方案，为什么不让团队每个人都贡献自己的专业知识呢？通过使用XHTML，我们能够利用密切集成的CSS和JS，帮助团队成员使用一套整体思路来贡献自己的能力。

何去何从

当然，本文仅仅是在刺激那些对XHTML原型法感兴趣的人的欲望。如果你想更深入的探索这种方法，特别是那些正置身于传统瀑布模型进程中的人，我建议你们采取一种“小步走”策略。也就是说，先用这种方法做原型，然后与你的团队一起试验一个小型项目，以此作为基础。如果你的经验跟我差不多，你也会发现它对你的UX工具箱是一种异常强大的补充－一个跨越“体验vs技术” 鸿沟的更有效的方法！

“七”乐无穷，尽在新浪新版博客，快来体验啊~~~请点击进入~

写给应聘页面重构的同学 (转 css森林)

charies — Wed, 11 Mar 2009 03:32:46 +0800

作者：Ghost

作者blog：http://www.cssforest.org/

当“ 页面重构工程师 ”这个职位的面试官也蛮长一段时间了，跟前两年比起来，总的来说来应聘的同学能力在很大程度上有了提高，记得两年前的一场招聘会上，有个同学还问我 “div这个属性是什么意思”，让我一时间不知道如何回答。经过这两年的时间，也可以看出WEB标准在国内已经被很多学习页面制作的同学认可并学习、使用。越来越多公司也开始设立页面重构的职位，要求也越来越高。不过从招聘信息上看得出很多公司对这个职位所应该具备的能力跟前端开发工程师还是比较近的，基本就是换了个名。这也从某方面反映出页面重构这个职位越来越得到重视，也是一种改变。

回来正题，我写这篇文章不是为了说招聘信息应该怎么写，而是想总结下我面试过的、看到的那些应聘这个职位的同学所存在的问题，也算是给将要应聘这个职位的同学提个醒。

首先简单说明下我面试的范围，以明确下面所总结的范围：到目前为止，我主要是从事“页面重构工程师”这个职位的技术初试，所谓初试就是第一次的筛选，主要是技术，也就是职位所需能力的面试。因此，我所总结的主要是技术方面的内容。

从以往的面试评价中可以看出，大部分没有通过面试的同学都或多或少有下面的问题。

技术方面：

基础知识
问题主要是对HTML标签掌握欠佳，使用很随意，更不用说语义化了。一些常用的技术如“滑动门”没有深入理解，使用上存在问题或没有正确的使用。还有就是不验证，有些同学因为受某些人性主义说法的影响，对“验证”这个工具很反感，没错，我们不是为了过验证而做页面，这个工具能很方便、高效的帮我们找到一些低级的错误，为什么不使用呢？
设计稿还原
大部分同学没有关注设计稿的还原，往往只是看上去差不多就算了，但作为这个岗位的基本素质，这明显是不合格的。
语义化
在国内很难有明确的标签语义化标准，不过一些最基本的标签语义还是需要做的，像在列表（li）里放标题（hn），虽然没有嵌套错误，但明显是有问题的。
页面性能
主要还是连接数、文件大小，说虽然都懂，做就总没注意。
图片类型
什么是内容图？什么时装饰图？我一直以为这个很好理解，可是“自以为”果然是容易出问题的，发现有相关多的同学理解都不太相同。有“能给用户传递信息的图片就是内容图”、“带文字的图片就是内容图”等等。没有正确理解，就难正确使用，所谓知其然还要知其所以然嘛。
用户体验
这块比较泛，作为一个更高的要求，主要是如何让用户更流畅的使用站点。

其它方面：

对待面试的态度
有些应聘的同学本身有工作，时间不多可以理解，我一般也是让应聘者自己定个时间，只要不过份，都是接受的，但有些人并没有按时提交作品，不说其它，首先对于自己能力的评估是否就有问题？评估错误的风险是很大的，如果是实际工作中出现这种问题，那可能带来的结果就不是没有了一次面试机会这么简单了。另外就是诚信的问题。
对待作品的态度
相信做技术的人都有一些代码洁癖，对自己做的东西要求较高、追求完美，可惜现在这种特质并没有以前那么明显了，很多时候都是只要实现就好，怎么实现就随便了。最常见的就是不使用验证工具，在作品中出现一些低级的错误，像标签没关闭、嵌套错误等等。
表达、沟通
很多应聘的同学很会讲，说起来头头是道，不过作品中并体现不出来；还有些同学就是缺少沟通，自己的想法表达不出来、或不敢说，这些都是比较吃亏的。

还遇到过一个问题，有些同学很希望能通过面试，进而采取了一些投机的方法，如猜面试官喜欢什么样的写法、实现方式等等。这种方式也是不可取的，首先就是猜的东西准确性比较低，有经验的面试官会隐藏得较好或给出错误的信息，猜的时间还不如好好做题。另外就是不明白面试的意义。面试，我的理解就是用人单位通过一些测试的方法，了解应聘者是否有具备相应工作岗位所必需的能力。如果是什么人都可以做的工作，面试也就没意义了。面试同时也是为了应聘者负责，做能力之外的工作，工作上压力过大、效率低下，由于工作的不如意，引起生活上也事事不顺心，又怕失业，整天精神紧张……应聘者合不合适应聘的岗位，面试官应该更加清楚，投机的行为更多的会出来反效果。还不如更多的专注于把能力表现出来。

还有一点细节上的建议，发求职简历的时候，特别是邮件，主题上最好出现自己的名字，邮件内容中应该以文本简历的方式写，最后有一些其它形式的简历再附上。很好理解，因为这样支持搜索，在一堆简历中要找到某个人的简历是不容易的，如果不使用搜索的话。怎么可以方便搜索呢？上面已经说了。这样能减少因面试官（面试官可不是只有一个人）找不到简历而失去面试的机会。

面试也是一种经验，希望应聘的同学不会一无所获。最后，祝所有在找工作的同学，生活开心，面试顺利。

文章地址：http://www.cssforest.org/blog/index.php?id=127

“七”乐无穷，尽在新浪新版博客，快来体验啊~~~请点击进入~

UED技术层次初探

charies — Wed, 04 Mar 2009 01:42:31 +0800

抛砖引玉：

我的想法：

视觉规范和交互规范，以用户研究作为基础。比如全站的色调，基本操作的交互等，都取决于对主流客户群心智模型的研究。
前端技术相对独立，在规范的基础上，封装成技术框架供上层调用。这里的框架仅包括基本功能，比如css框架里的reset和grids，js框架里的dom、event等，不含widgets.
再上一层是设计模式库DPL(Design Pattern Library). 大部分模式的形成，需要视觉、交互和前端三种技术的融合。比如淘宝首页的幻灯片卡盘，不仅仅是前端技术的产物，和淘宝的视觉规范与交互设计也密切相关。
DPL是一份文档化的说明，面向的是UED全体设计人员。DPL的背面是技术实现，一般体现在JS框架里，比如YUI的widgets库，jQuery的UI插件库等等，这些封装好的代码组件面向的是程序开发人员。
在DPL之上，可以构建各种应用。比如Yahoo的首页，Google的GMail. 每个公司的DPL各不相同，体现的是一个公司整体的设计观。
DPL负责的是通用模式。具体应用中的特殊模式，还需要直接根据前端框架、视觉规范、交互规范以及用研数据来完成设计和开发。
DPL初期的构建和维护成本很高，但一旦有效运作起来后，团队将获得丰厚的回报。

JamLegend:在线玩转吉他英雄

charies — Thu, 19 Feb 2009 01:26:42 +0800

JamLegend 是一款十分有趣的Web应用，你可以在线玩转风靡全球的Guitar Hero / Rock Band 音乐游戏。

JamLegend 是一款十分有趣和有想法的Web应用服务，它将酷似于 Guitar Hero / Rock Band （类.劲乐团…）的音乐游戏以日趋流行的Web Game和SNS社区的形式呈现给普通用户。与此同时，JamLegend 引入的音乐人作品分享机制可以有效的帮助独立音乐作者将自己创作的唱片在该平台上进行推广并从中获取相应的利润返点。

音乐在游戏中的体现无疑是一个巨大的数字音乐消费产业链：国内大型音乐模拟类网络游戏运营商久游网与多家唱片公司在过去两年多时间来签订的高达数千万人民币的音乐版权使用授权以及音乐内容合作协议足以证实这种运营和商业模式的巨大潜力。但，同时，我觉得，久游的这种模式并不可被2.0网站所效仿，一个现实的理由，因为像久游这样的资本巨鳄正在虎视眈眈的瞄着和你们一样的创业型公司，他在游戏领域所签署的不少排他性合作协议无疑抬高了其他网络运营商介入音乐游戏的市场门槛。因此，我觉得像JamLegend这样，避开大唱片公司，拥抱独立音乐人，是做Web Game、甚至是所有决定做Music2.0网站的最明智的选择；同时，与独立音乐人的双向合作对于Music2.0创造交叉式营销的新模式也起到积极的推进作用！

Tips: JamLegend 的操作很简单：当音乐开始的时候会掉下一个色块，该色块对应着1、2、3、4、5 的某一个数字，按住相应的数字键不放，当色块落到底部的瞬间按下回车键即可。

“七”乐无穷，尽在新浪新版博客，快来体验啊~~~请点击进入~

CSS Sprites技术

charies — Fri, 13 Feb 2009 03:33:36 +0800

关于CSS Sprites技术的优化我们能做到多少，能减多少的请求数量。这并且不是单方面能做到的，一切取决于XHTML、CSS、CSS Sprites图片之间的配合。现时为止没有绝对优化的做法，这也是我在项目中经常衡量CSS Sprites图片与XHTML关系，如:《一张背景实现自适应九宫格》，以下总结了图片切割术与图象优化的一些方法。

图片优化

对于非动画的GIF更建议使用PNG8因为它同样能做到一样的效果，而且能为你节省10%-30%的文件体积。
Photoshop相比起Fireworks，导出同等质量的PNG图片，体积会稍大。而Fireworks虽然做了相应压缩优化，但没有达到最优秀的压缩。
我所知的设计软件，对于PNG图片的处理都没做到最优秀的压缩，图片体积还有一定的压缩空间。可以尝试使用下面介绍的”图像优化工具” 做无失真的压缩优化。
图片体积及尺寸方面，建议体积保持在100K以内(较为符合国情最佳请求SIZE)，size为800px(最佳尺寸)。(从某权威人事中得知，具体无从考证)

CSS Sprites图片切割术

CSS Sprites图片顺序合图片由上至下、左至右添加。而background-position一般采用数字组合形式定位，这样能减少维护带来的不必要麻烦。
不建议CSS Sprites图片中保持一定的间距，因为文件size增大而增加文件体积。
CSS Sprites图片中把颜色较近或相同的组合在一起可以降低颜色数，因为少色数的图片文件体积会相对的小。
size相同的CSS Sprites图片中留有较大空隙，某程度上多数情况会增大了体积，所以CSS Sprites的图片不要有空隙。Demo
在size相同的CSS Sprites图片中，垂直排列的图片会比水平排列的文件体积要大。Demo
在CSS Sprites图片中，水平排列的图片会比垂直排列的文件体积要大。Demo
图片对等合并：应用CSS Sprites图片时，适当地把对等相同的图像合并，以节省空间及减少体积。Demo
区分开不需要合并的图像：如当前用户确定只显示一种状态或一个级别时，不必要把其他的级别或状态的图片合并。
黄金切割位：在CSS Sprites图片的最右或左边为最灵活动位置最适宜摆放文本前的icon，因此不会受到其它CSS Sprites图片干预，也不需要预留一定的行宽。

Google美国总部

charies — Wed, 11 Feb 2009 10:00:20 +0800

在很多人的眼里Google是奢华的，因为Google的员工有着几乎是世界上最好的工作环境。有着巨大的工位，宽大的休息室，完备的游乐场，还有着不逊色于任何一家健身中心的健身房、瑜伽室。Google员工可以带着狗上班，可以随时预约按摩，还可以品尝到五星级酒店大厨的手艺。
　　但这仅仅是Google文化的一种外在体现，人们往往在被这种外在的“奢华”迷惑，而未能看到Google更深层的内涵。这就如人们对于美女的认识，往往只看到了她们精致的面庞和婀娜的身姿，却无暇体会她内心中才学与智慧。而致命的美丽往往是内在气质在优美曲线上的散发。
　　或许只有等你走进Google的大门，参与到Google日常的工作时才会真正的体会Google的文化。才可以体会“奢华”所体现的实质……

“七”乐无穷，尽在新浪新版博客，快来体验啊~~~请点击进入~

charies_蔡

面向对象的CSS

工程师与科学家 realazy

两种家

两种用法

实用主义的前提

如何选择图片格式

JavaScript,5种调用函数的方法

XHTML原型开发－用代码说话

一个迭代的过程

草图法：一件形式自由的事情

原型法：一个明确的回答

原型开发/打造关联

三个综合层次：结构(Structure)，行为(Behavior)，基础(Foundation)

结构层：建立页面的基本结构

XYZ Application

My Account

Account options

Account details

Account Help

Account Help

改进表现层

添加行为层：少作无用功

迭代：发现，改进

XHTML如何兼作设计说明

注释仅对个别人可见

更标准，无干扰

事半功倍

分而治之

何去何从

写给应聘页面重构的同学 (转 css森林)

UED技术层次初探

JamLegend:在线玩转吉他英雄

CSS Sprites技术

图片优化

CSS Sprites图片切割术

相关的图像优化工具

以下是安装及使用的一些载图

Google美国总部