1. 周爱民的讲演“前端设计与开发的基本模式”，看起来很丰富，很多模式或理念听起来也蛮有争议，避免不了空和虚，但我不能不承认他提供了很多我有兴趣但尚未涉及东西，这些给了我新的视角。
2. 黄继佳的讲演“Silverlight应用”，虽然很高兴他能来参加和支持D2，幻灯片也很cool，但我强烈的感觉这是一个很纯正的Silverlight的产品推广，我不是太喜欢。
3. Hedger Wang的讲演“Enterprise Ajax in PHP”，是这次D2的精华。他提出管理Ajax在企业级应用的设计模式，很多正是我日常开发中遇到，比如他讲到的映射，我也曾经做过类似的解决方案，比如他讲到的对多次同一请求的管理，我也曾思考过，但那往往是一个个独立的小点，这次讲演终于让我有了从点到线到面的感觉。他的讲演也准备的相当好，既有总结，又有代码，同时利用生活中的例子来说明原理，想听不明白都不行。我不需要如何得称赞hedger的讲演，如果你的开发涉及到Ajax，那么你就应该去看看他的讲演。ps，祝他杭州玩的开心。
4. Nate Koechly的讲演“Enhanceing Web Sites With The YUI Library”(English)”，作为YUI开发的核心成员，这次讲演虽然有点推广YUI的意味（在此有近一年应用YUI经验的我也强烈推荐YUI），但是仅仅从他幻灯片上就可以看出他事先的准备和用心，甚至他表达出了要学习汉语的意愿。但很遗憾的是，由于语言的原因，这次没有能充分的从Nate身上获取更多的更深的东西，虽然有hedger义务做翻译，虽然对nate的提问是最多的。
5. 章亦春的讲演“Nifty web apps on an OpenResty”，讲的很有激情，也给出了一个新的Web OS，作为一个视角是一个很棒的东西，但是作为我个人来讲我并不赞同这个思路，我一直认为让一门语言处于它最适当的位置才是王道，就像语义化设计一样，应该用合适的标签来组织合适的数据。虽然章亦春提到了不应该对Javascript滥用，但是很遗憾的是我感觉这就是一种滥用。
6. 案例分享阶段，贤安的“如何写一个富文本编辑器”，小马的“前端开发工具介绍”，一位仁兄（不好意思，记不起来名字）的“用Adobe Air开发IM”，都很有意思，这些很务实的小分享越多越好，因为每个人的心得体会小窍门汇聚在一起就有了越来越顺畅的前端开发。

第二届D2已经结束，第三届目前还没有明确的主办方（有兴趣请看如何申办D2），我的一些想法和建议如下：

1. 主办D2是需要费用的，所以建议下一次D2可以有正式的赞助商和门票，这将能保证D2更好的运作。
2. 不少人对我说互动不够，但是由于演讲本身就是一对多的，所以注定了互动是有限度的。建议通过在午餐和晚餐时话题分桌，一边吃，一边彼此认识，一边圆桌会议。
3. 这次D2已经很务实了，下一次希望更务实。可以提前征集大家期望的讲演内容，可以参考大家主题邀请演讲嘉宾。同样也可以提前搜集分享案例，更好的更深入的组织分享。我期望下一次D2能遇到的内容：
   1. 语义化的HTML。这是一个最基础的东西，也将是一个巨大的挑战。
   2. Firebug实战。虽然大家开发基本上离不开它，但是我总感觉并没有充分的利用它，每一个小技巧都可以让我们进步。
   3. 整站的CSS管理。这肯定是一个百花齐放的问题。
   4. 高性能的WEB页面。Yahoo的preformance列了34条，但是我们的实战呢？
   5. 前端工程师如何推动整个项目的设计和开发流程？这就是需要实践+经验+效果。

中国雅虎主办第二届D2前端开发论坛

坐着听讲演的开发者。由于2008的原因，北京的会议室不是特别好找，这次的会议室过于细长，hedger首先坐在了地上，并且号召大家都这么做，很多年没有坐在地上了，感觉不错。

Nate正在开讲，首先拿出相机拍一下听讲者。他的幻灯片开始部分用了中文，是他临时学的，拿到他名片的朋友也会发现，有一面是简体中文的。

Nate讲演时发现的一个提示站点是否使用YUI的小工具。在他的演讲过程中，列出了当前哪些站点使用了YUI，估计都是用这个小工具挖掘的。

hedger演讲中…

部分现场的工作人员，我的同事们

在YUI 2.4.0到2.5.1版本中，YUI Loader通过其addModule()方法只能配置一个YUI Loader实例的加载模块信息，无法配置全局的加载模块信息。实际中，能够全局的配置加载文件的模块信息对于统一维护非常的重要，特别是在静态文件服务器设置了上传文件不可以修改和删除情况下。下面是解决这个问题的两个方法：

方法1：修改YUI Loader源文件，引入YAHOO_config.load来配置全局信息

在YUI两个全局变量之一的 YAHOO_config中,有一个load属性是用来配置YUI Loader的全局信息的，但是遗憾的是仅仅是2.4.0之前的版本支持。

1、修改YUI Loader源文件

var Y=YAHOO, util=Y.util, lang=Y.lang, env=Y.env;
/*
 *在上面一行代码的位置下面加上下面的代码：
 *判断当YAHOO_config存在且有load属性时，把YAHOO_config.load赋值给变量Y_load
 */
if('undefined'!== typeof YAHOO_config){
	if(lang.hasOwnProperty(YAHOO_config,'load')){
		var Y_load = YAHOO_config.load;
	}
}
...
this.base = YUI.info.base;
/*把上面一行修改为下面一行，这样可以用过YAHOO_config.load.base来指定YUI组件的路径*/
this.base  = (lang.hasOwnProperty(Y_load,'base'))?Y_load.base:YUI.info.base;
...
this.moduleInfo = lang.merge(YUI.info.moduleInfo);
/*把上面一行修改为下面一行，这样可以用过YAHOO_config.load.moduleInfo来指定YUI组件的路径*/
this.moduleInfo = (lang.hasOwnProperty(Y_load,'moduleInfo'))?
lang.merge(YUI.info.moduleInfo,Y_load.moduleInfo):lang.merge(YUI.info.moduleInfo);

2、在YUI Loader文件前写下如下配置文件：

YAHOO_config = {
load : {
 base : 'http://cn.yui.yahooapis.com/2.5.1/build/',
 /*
 *  通用的非YUI组件和不自动加载皮肤的YUI组件
 *  @name   string
 *  @type   string
 *  @fullpath   string
 *  @requires   array
 *  @optinal    array
 *  @skinnable  boolean
 */
 moduleInfo : {
/*
 *YUI的组件中，有皮肤的组件使用时都会自动加载皮肤
 *比如require(['container'])时，会加载container.js，也会加载container.css
 *但是实际应用中，往往不会直接使用YUI的默认皮肤
 *利用YUI Loader本身的skins属性设置，只能在具体的YUI实例中使用，且需要满足YUI的文件结构
 *利用insert({},'js')方法虽然只能加载Js，但如何require()方法中的CSS也会被过滤掉
 *所以最好的方法是全局性的把其skinnable属性值修改为false
 */
  'container': {
   'type': 'js',
   'path': 'container/container-min.js',
   'requires': ['dom', 'event'],
   'optional': ['dragdrop', 'animation', 'connection'],
   'supersedes': ['containercore'],
   'skinnable': false
  },
  'dwncontainercss' : {
   'type' : 'css',
   'fullpath' : '/lab/2008/extend-yuiloader/container.css'
  },
  'dwncarouselcss':{
   'name' : 'dwncarouselcss',
   'type' : 'css',
   'fullpath' : '/lab/2008/extend-yuiloader/carousel.css'
  },
  'dwncarousel':{
   'type' : 'js',
   'fullpath' : '/lab/2008/extend-yuiloader/carousel-min.js',
   'requires':['dwncarouselcss','yahoo','event','dom',
                'containercore','animation']
  }
 }
}
}

请看演示实例1

方法2：利用YAHOO.lang.extend方法封装一个新的Loader

YAHOO.namespace('CN.util');
/* start:YAHOO.CN.util.YUILoader */
YAHOO.CN.util.YUILoader = function(o){
 YAHOO.CN.util.YUILoader.superclass.constructor.call(this,o);
  this.base = 'http://cn.yui.yahooapis.com/2.5.1/build/';
  this.addModule({
   'name': 'container',
   'type': 'js',
   'path': 'container/container-min.js',
   'requires': ['dom', 'event'],
   'optional': ['dragdrop', 'animation', 'connection'],
   'supersedes': ['containercore'],
   'skinnable': false
  });
  this.addModule({
   'name' : 'dwncontainercss',
   'type' : 'css',
   'fullpath' : '/lab/2008/extend-yuiloader/container.css'
  });
  this.addModule({
   'name' : 'dwncarouselcss',
   'type' : 'css',
   'fullpath' : '/lab/2008/extend-yuiloader/carousel.css'
  });
  this.addModule({
   'name' : 'dwncarousel',
   'type' : 'js',
   'fullpath' : '/lab/2008/extend-yuiloader/carousel-min.js',
   'requires':['dwncarouselcss','yahoo','event','dom',
                'containercore','animation']
  });
}
YAHOO.lang.extend(YAHOO.CN.util.YUILoader,YAHOO.util.YUILoader);
/* end: YAHOO.CN.util.YUILoader */

YAHOO.CN.util.YUILoader的使用和YAHOO.util.YUILoader的使用没有任何区别。请看演示实例2

两种方法的优劣比较

方法1的缺点是需要修改YUI Loader的源文件，而方法二2只是外层增加一个壳，比较友好和保险，但方法1直接修改配置文件的方法比方法2每次实例化都需要通过特定方法修改配置文件要高效，特别是当添加或者修改的配置模块间也有依赖关系的时候，方法2很可能会因为过度运算而死掉。例如把实例中的模块container依赖于dwncontainercss的时候，方法1没有问题（请看演示实例3），但方法2下浏览器会提示脚本忙（请看演示实例4）。

Douglas Crockford已经传授了一个有用的单例模式（singleton pattern）实现此规则，我认为他的模式有益于你基于YUI的那些应用。Douglas叫它模块模式（module pattern）。它是如下工作的：

1. 创建一个命名空间对象：如果你使用YUI，可以用YAHOO.namespace()方法： YAHOO.namespace("myProject");这分配了一个空的myProject对象，是YAHOO的一个成员（如 果myProject已存在的话，则不会被覆盖）。现在我们可以开始添加YAHOO.myProject的成员。
2. 对你的命名空间对象分配一个匿名函数返回值：

   YAHOO.myProject.myModule = function () {
   return  {
     myPublicProperty: "我作为YAHOO.myProject.myModule.myPublicProperty被访问。";
     myPublicMethod: function () {
       YAHOO.log("我作为YAHOO.myProject.myModule.myPublicMethod被访问。");
     }
   };
   }(); // 这个括号导致匿名函数被执行且返回
   

   注意有闭合大括号和紧接着的括号()的最后一行—这种符号导致了匿名函数的立即执行，返回包含myPublicProperty和myPublicMethod的对象。只要这个匿名函数一返回，返回对象就作为YAHOO.myProject.myModule被访问。

3. 在匿名函数中，在返回语句前加入“私有”方法和变量。到目前为止，我们只是将myPublicProperty和myPublicMethod直接分配到YAHOO.myProject.myModule中。此外，当我们在返回语句之前放置一些代码时，这个模式还支持被增加的效用。

   YAHOO.myProject.myModule = function () {
   //“私有”变量：
   var myPrivateVar = "我仅能在YAHOO.myProject.myModule内被访问。";
   //私有方法：
   var myPrivateMethod = function () {
       YAHOO.log("我仅能在YAHOO.myProject.myModule内被访问。");
   }
   
   return  {
       myPublicProperty: "我作为YAHOO.myProject.myModule.myPublicProperty能被访问。"
       myPublicMethod: function () {
       YAHOO.log("我作为YAHOO.myProject.myModule.myPublicMethod能被访问。");
       //在myProject,我能访问私有的变量和方法
       YAHOO.log(myPrivateVar);
       YAHOO.log(myPrivateMethod());
       //myPublicMethod的原生作用域是myProject，我们可以用“this”来访问公共成员。
       YAHOO.log(this.myPublicProperty);
       }
   };
   }();

   在上面的代码中，我们从一个匿名函数返回有两个成员的一个对象。在YAHOO.myProject.myModule内部，可以分别用this.myPublicProperty和this.myPublicMethod来访问。在YAHOO.myProject.myModule外部，公共成员可以用YAHOO.myProject.myModule.myPublicProperty和YAHOO.myProject.myModule.myPublicMethod来访问。
   私有变量myPrivateProperty和myPrivateMethod只能被匿名函数本身或返回对象的成员访问。尽管匿名函数会立即执行和终止，但它们依然是保留着，凭借闭包（closure）的力量——通过一个函数的局部变量在这个函数返回后是保留的规则。只要 YAHOO.myProject.myModule需要它们，我们的两个私有变量就不会被销毁。

4. 实践这个模式。让我们来看看这个模式的一个常见应用案例。假设你有一个列表，列表上的一些项可以被拖拽。应用拖拽的项上有拖拽的CSS类。

   <!--这个脚本文件包含所有的YUI实用程序-->
     <script type="text/javascript"
   src="http://yui.yahooapis.com/2.2.2/build/utilities/utilities.js"></script>
   <ul id="myList">
      <li class="draggable">一项</li>
      <li>二项</li> <!--二项将不能被拖拽-->
      <li class="draggable">三项</li>
      </ul>
   <script>
     YAHOO.namespace("myProject");
     YAHOO.myProject.myModule = function () {
    //YUI实用程序的私有简写引用：
     var yue = YAHOO.util.Event,
     yud = YAHOO.util.Dom;
    //私有方法
     var getListItems = function () {
    // 注意这个地方使用其他的私有变量，包括"yud"YAHOO.util.Dom的简写：
     var elList = yud.get("myList");
     var aListItems = yud.getElementsByClassName(
     "draggable", //得到仅有CSS类"draggable"的项
     "li", //仅返回列表项
     elList //限定搜索改元素的子
     );
     return aListItems;
     };
    //这个放回的对象将变成YAHOO.myProject.myModule:
     return  {
    aDragObjects: [], //可对外访问的，存储DD对象
    init: function () {
     //直到DOM完全加载好，才实现列表项可拖拽：
     yue.onDOMReady(this.makeLIsDraggable, this, true);
     },
    makeLIsDraggable: function () {
     var aListItems = getListItems(); //我们可以拖拽的那些元素
     for (var i=0, j=aListItems.length; i<j; i++) {
     this.aDragObjects.push(new YAHOO.util.DD(aListItems[i]));
     }
     }
    };
     }();
   //上面的代码已经执行，所以我们能立即访问init方法：
     YAHOO.myProject.myModule.init();
     </script>

   这是一个简单的例子，特意写的详细一些——如果按照这种方式做，我们无疑能把它写的更紧凑。当项目变得更加复杂和它的API增加，这个模式缩放的很好。通过这种方式，它避免了全局命名空间，提供了对外的可以访问的API方法，支持受保护或“私有”的数据和方法。

• [1]原文：《a javascript module pattern》。这是在YUI blog上的，有的地方可能打不开，可以搜一下英文的转载或者利用搜索引擎的缓存也能看。
• [2]《A JavaScript Module Pattern – JavaScript的一种模组模式》这是别人的翻译，参考了不少，不过感觉挺不方便看的，这是我翻译的这篇文章的一个原因，当然最主要的原因是这篇文章算是学习YUI的最基础的文章了，整个YUI的模块模式都基于此。

Yahoo!英文版页面和中国雅虎三次改版的截图

1. Yahoo!英文版2007年5月首页
   
   Yahoo!英文版2007年5月首页窄版
   
2. 2006年8月中国雅虎首页
3. 2007年初，第二次改版,也就是现在大家看到的中国雅虎首页
   中国雅虎2007年5月首页
   中国雅虎2007年5月首页窄版
   
4. 中国雅虎2007年5月底首页测试版
   

总结

1. 越重要的内容出现在越上面，这是符合了人们从上到下阅读浏览习惯的，所以Logo和搜索被放在在最上面，紧接着就是导航、图片新闻和邮箱等入口。
2. 视觉重点在左边，鼠标的操作重点在右边，这是基于人从左到右阅读习惯，用右手翻书右手使用鼠标（绝大部分人）的使用习惯，所以Logo、导航这些需要关注视觉重点都在左边，搜索框、邮箱登录等等都在右边。这点我在《向Yahoo Mail的主页学习》中提到过，同样的结论在MSN上也可以得到明显的验证。
3. 首屏的完整和足够信息量至关重要。
   1. 首屏指的是在浏览器最大化时从顶端看到网页的大小，在1024×738分辨率下一屏的大小是1003×600，在800×600分辨率下的一屏大小是779×432，具体请看《网页一屏有多大？》.
   2. 虽然在《页面长度与用户行为的一些数据》提到，页面的长度和用户是否会完整浏览整个页面没有关系，但需要考虑，用户在浏览后面的页面的时候注意力是否会向开始那样集中，同时对于大多数用户（网速不快）特别是新用户，首先看到的是首屏，这会有一个首因效应，毫无疑问，对于世界上任何一个站点来说，新用户（潜在用户）永远多于老用户。
   3. 对于Yahoo来说，其最重要的是Logo、搜索框、导航、邮箱登录等功能、和资讯信息。上图中紫色横线以上部分是在其对应分辨率下（如窄版对应800×600分辨率）看到的首屏内容。
      1. 对比一下Yahoo!英文版就会发现，导航恰到好处的完整出现在一屏，中栏的资讯分为两种，一种是图片资讯（Featured那一行），很吸引人，一种是文字资讯（in the news那一行），容量大。在宽版下文字资讯在图片下面，而在窄屏下两者位置上下对调，这就是为了保证首屏完整和足够信息量。
      2. 中国雅虎的前两个版本，都在Logo的两侧放置重要的链接，但是实际上重要链接的视觉效果被Logo干扰和弱化，同时也导致了导航链接的混乱，也直接导致了首屏浪费了大量的空间。这个问题在中国雅虎2007年5月首页窄版上表现最为明显。
4. 导航的设计
   1. 保留重要导航，隐藏全部导航。综合性站点的分类越来越多，导致导航越来越庞大，直接在页面全面列出，非常的杂乱不仅不会带来很好的效果，反而让人却步，这点在AMAZON已经得到了充分的思考和实践，所以Yahoo！的导航处理是一个非常好的方式。
   2. 别让我思考。中国yahoo前两个版本中，在导航的最前面出现“全部”会导致用户需要思考是点击全部呢，还是先看看已经列出的重点导航。
   3. 导航还是一个的好。分类的入口应该稳定而不易过多，这点中国yahoo前两个版本中表现的很明显，导致了混乱，相同链接相互干扰，同时因为分类链接数量增多，也干扰了其他的链接。
   4. 排序还是分类？英文由于可以明显的看到按照首字母排序，所以很好确定导航的顺序，但是中文就不好办了，绝大部分的中文菜单，一般都是按照重要性来进行排列，所以当菜单很多的时候进行分类是一种很有效的方式，其重点就是归纳分类，对比中国雅虎的前两个版本，现在的第三个版本无疑前进了一大步。

5. 如何用好Tab？

   在中国雅虎第三次改版的测试版中Tab页的效果被拿掉，增加了对一个栏目的内容的类似”下一页”的功能，这必将带动挖掘内容的深度。那么Tab呢？

   自从Yahoo！英文版用上Tab之后，Tab风靡起来，于是乎就像Ajax一样被到处滥用，比如网易、新浪都采用上Tab页来大量显示内容了。其实在Yahoo!英文版的页面并非仅仅是用Tab在一个区域来显示更多的内容，而是有节制的选择部分重要内容，然后记录用户最后一次点击的Tab，完成用户的定制的，这种定制是需要通过统计且精心安排一行Tab的内容的。

   从效率上讲，Yahoo！单击Tab效果肯定没有网易那种触发式的Tab高，但是效率最高的肯定是传统的直接通过滚动页面浏览。所以Tab要物尽其用，而不是到处乱用。

   中国雅虎前两个版本中Tab页的视觉效果，通过一个突出的纯色块，是达到了突出被选中的Tab页，但是太突出了，突出的色块夺走了文字的感觉，这个色块的题目是什么，还需要定眼一看。

6. 中国雅虎2007年5月底首页测试版中，登录的处理应该是一个败笔
   1. 登录顺序的排列方式，会在用户在登录过程中造成干扰，这一点Yahoo Mail做的很好
   2. “登录雅虎”后面的“个人空间”是一个按钮还是一个链接？如果是链接，则很容易让人当作是一个登录个人空间的按钮；如果是登录个人空间的按钮，但是个人空间却是雅虎的一部分，提供两种登录方式，让人迷惑，人们期望的是一次登录后，选择前往地方，而不是在登录之前就需要选择。
   3. 那个显眼的“免费注册”简直是一个怪胎。

ps，Yahoo！英文版的设计采用了相对大小，这对中文来说可能有更多挑战性（本站的设计就是相对大小来设计的），但是最害怕的是用户不会使用吧？

补充一点刚想到的对于中国雅虎2007年5月底首页测试版页面的一些想法：

1. “选择颜色”的选择色块按钮应该隐藏起来，这只是一个额外体验功能，并非所有人回去都去选择，或者是每次浏览都会去选择，一般人选择一个喜欢的，会长期不变，或者间隔一段时间，重新换一个，所以目前占用面积过大，同时色块也干扰了对其旁边内容的获取，还是目前yahoo！英文主页的定制方式比较合适。这点在MSN网站上也得到了验证，在Yahoo！英文版改版后，MSN也进行了一次改版，其颜色的选择就像目前中国雅虎2007年5月底首页测试版一样，5个色块直接放在页面上，现在直接改成了和yahoo！英文版主页同样的处理方式。
2. 对于首页设置登录框的思考,除了上面提到的，还有：
   1. 用户到首页来利用登陆框直接登录的比例会很大吗？至少从Yahoo！英文版和Goolge的首页对登录的处理来看，这个问题需要考虑和调查数据的支持
   2. 用户在首页直接登录之后，返回到首页。这个需要考虑的是，用户如果在首页登录，还想停留在首页么？即使首页能够提供登录后可使用服务的选择，但是首页其他的大量的已有内容会影响这种选择的效率和关注度，Yahoo英文版直接登录到邮箱，似乎感觉产品的整合不够，这点上我比较支持Google在登录后页面的处理方式。

再次补充关于主页改版的一些想法：

1. 主页改版最基础最重要的是IA（信息架构）部分，这部分真正决定了整个页面的布局，但是这个和公司战略，整个站点的构架，用户信息等等相关紧密，如果不深入了解，实在难以妄言。
2. 主页改版应该是一个逐步的过程，而不是很爽的一下子从旧页面直接切换到新页面。这点Yahoo英文版改版时公测就用了好几个月，中国的Yahoo这点也做的非常好，这是国内知名站点首页改版很少见的。这样做的目的是：
   1. 比如很多用户记住某个链接是在页面的某个位置，而不是每次看页面按照逻辑去查找，所以很多用户对旧页面熟悉了，即使新页面做的很好，突然切换会让用户摸不着头脑。
   2. 新旧的对比，会让用户能够体会到新的优点和缺点，能够更好的定位问题所在，同时不会因为某个新页面的问题而导致现有用户的流失。
   3. 新旧页面的同时存在，其实就是一种培养用户、引导用户的一个非常好的做法。

1. 视觉重点(Logo、宣传图片、说明文字)在左边，鼠标的操作重点（登录框、注册链接等）在右边，这是基于人从左到右阅读习惯，用右手翻书右手使用鼠标（绝大部分人）的使用习惯
2. 登录框和注册谁重要？一次注册，多次登录，毫无疑问登录应该更重要一些，这就决定了登录框的设计应该处于最易用的位置
3. 如何处理登录的流程？ID->密码->记住登录->登录按钮->忘记ID或密码->登录帮助
4. 按钮是按钮，链接是链接？登录(sign in)是一个按钮，注册(sign up)是一个链接
5. 视觉设计，简洁而不简单
6. 登录表单的设计，比如fieldset和label的应用
7. ……

看Yahoo Mail的主页的变迁

1. Yahoo Mail 2000-2001年首页，这是一个很熟悉的页面了，因为人们的阅读习惯，所以重要的注册和登录放在左边
   
2. Yahoo Mail 2001-2002年首页，视觉重点虽然在左边，对于大多数人来讲，鼠标的操作重点在右边，于是登录框在右边区别显示，Yahoo Mail首页的整体结构基本形成，这个时候说明文字不管好不好辨认能够围绕圆球排列或许是一种技术表现
   
3. Yahoo Mail 2002-2003年首页，对齐说明文字，突出关键词
   
4. Yahoo Mail 2004-2005年首页，美女在这个时候是眼球经济，在此带动下把链接伪装成按钮也成为一种流行，这种恶劣的流行一直还影响着今天的我们
   
5. Yahoo Mail 2006-2007年首页，圆角和色块配合，简洁而不简单的设计，这个四个页面是按照出现时间顺序排列的，明显的反应出对链接和按钮的考虑，注册和登录位置考虑（突出注册或为登录框更易于登录的好位置）等等
   
   

谁在向Yahoo Mail的主页学习？

1. 163邮箱2007年首页
   
2. 百度登录2007年首页
   
3. 支付宝2006年首页
   

不仅学习其形式，更重要的是其神是什么？这是所有人都应该努力的。

在Google中搜索“缘分 缘份 区别”,我得到的结果（因为篇幅原因，我只截取结果界面的前4条以及头尾，可以点击上面的链接查看此刻搜索结果，以下同）：

在百度中搜索“缘分 缘份 区别”,我得到的结果：

结果满眼看过去无数条搜索竟然没有我想要的，于是继续换搜索引擎搜索。

在雅虎中搜索“缘分 缘份 区别”,我得到的结果：

在搜狗中搜索“缘分 缘份 区别”,我得到的结果：

终于在搜狗中找到我想要的内容，虽然不能完全解决我的问题，但是也比一堆毫无无用信息好。但是令我惊奇的是，在中国市场排名三甲的三个搜索引擎在第一页竟然没有一条是我想要信息，而搜狗第一页的前三条都是我想要的内容，这不能不说是一个很搞笑的事情，更搞笑的是搜狗的第二条内容竟然是百度知道中的内容。

通过这个“区别”搜索我看到如下区别：

1、结果论英雄：

Google输了，即使股票超过$500又如何？仅仅靠钱解决不了有效的中文搜索问题，少说一些“半年之内本土化再无破绽”，我现在还不喜欢“谷歌”这个名字，足以说明本土化是一个多么有挑战性的事情。

百度输了，不管它现在在中国的份额有多高，不管它号称多么的专注中文搜索，中文切词技术如何的牛X，但是为啥百度知道的内容，百度不知道，而搜狗知道，或许百度知道原因。

雅虎输了，自从陈凯歌用了雅虎一千万拍了一条搜叫阿虎的狗的广告，搜狗便雄起了，虽然雅虎的体验和易用性很好，但是没有想要的结果，其它都是空谈。

搜狗赢了，不但给了我想要的，而且出现在前三条。不管市场上搜狗现在的位置如何，如果它能一点一点的赢得这种胜利，那么其他胜利都会唾手可得。

2、数字论英雄：

1. Google、百度、搜狗的搜索结果都是百万数量级的，而雅虎竟然是十万数量级别，虽然结果多未必是好事，因为是否有用最重要，但是一家独少必然也不是好事，至少对用户如此，同时也侧面反应了收录网页的绝对数量。
2. 搜索用时基本上都是毫秒级别了，虽然有报告说用户决定是否浏览一个网站只有5ms，但有目的的搜索内容和无所事事的浏览网站用户的心态差别是很大的。

3、设计论英雄：

四个搜索结果页面结构和风格上都大同小异了，如果在功能块上基本没有区别，那么对于用户来讲差别就在细节和易用性上了。

1. 高级搜索

   搜狗没有高级搜索，也不能不说是一个缺憾，简单搜索虽然最普遍，但是正是高级搜索提高了高级用户的粘性，同时能够增加部分普通用户的效率和停留时间。

2. 帮助

   搜索引擎使用虽然很简单，但是帮助依旧需要存在，特别是对陌生用户来说，而且帮助在很多时候是用户的最佳教程，但Google没有，搜狗有却放在尾部，我想如果用户感到困惑时如果第一眼看不到帮助，肯定会自己摸索尝试，尝试没有结果，那就换一个搜索了。

3. 相关搜索关键词

   Google没有，但是其实这个应该非常有用，因为很多人搜索时不能很好的确定关键词，但是已经有很多人做过类似的搜索，当用户看完一页发现得到结果不明显的时候，利用相关搜索关键词的几率就非常大了，同时也增加了用户搜索的欲望。同时这也是搜索智能化的一种表现。

4. 时间和文档类型搜索

   搜狗有“按时间排序”，雅虎有“网页时间”和“文档类型”两个选项，应该说这些功能还是比较贴心，在海量数据面前有一些细分功能还是很有效的，雅虎的这些功能要更加实用有效一些，当然过多会消弱主要功能的简易感觉和增加页面的复杂度，所以恰到好处的设计很重要。

5. 产品推广

   四家都有浏览器工具条插件，但只有Google和雅虎的搜索页后面都有推广，另外Google还提供了帐号登录链接和Google广告链接，雅虎则提供了邮箱链接和在搜索条目中无缝链接了收藏夹功能，这些都体现了整合思想，只要处理得当，对用户来讲一定是很有效的。特别是雅虎收藏夹对于每天搜索大量网页或者浏览大量网页的人来说非常的有用，应该说把这个功能加入搜索结果中，真是天作之合啊。

6. 不满意请留言

   四个搜索引擎在页尾都有类似的链接：

   • Google：对结果不满意？请帮助我们改进
   • 百度：与百度对话
   • 雅虎：对搜索结果不满意? 请提供意见给我们
   • 搜狗：对结果不满意?

   Google的最客气，雅虎的最明显，搜狗的很普通，百度的有时候让人感觉像一个产品推广。

   当用户对结果不满意的时候，心情肯定不好，包括对搜索引擎的信任程度和兴趣也会降低，出现合适语言链接来让用户缓和一下不爽的心情很重要，从这个角度上说Google做的最好，而百度做的最糟糕。

   一会把这篇帖子发通过这个留言的地方发送过去，测试一下他们对用户的反应哈。

“中科院调查报告通过对百度、雅虎、Google三家搜索引擎总计700个常用查询词和近2万条记录进行统计分析，得出两个非常有价值的结论：一是百度、Google、雅虎三大搜索引擎在主流词汇的检索方面（在统计学允许的误差范围内），用户满意度没有明显差别；二是雅虎、百度、Google搜索结果的重复率非常低，只有7%左右,也就是单一的搜索引擎使用还不能满足用户搜索某关键词结果的全面性。”

上面这段文字看到的是大世界，我看到的是小角落，不管如何，中文搜索很有很多路要走。

IE提示“无法显示该页”，“找不到服务器或 DNS 错误”。

Firefox提示“连接超时”。

ping一下域名，DNS解析没有问题：

C:\Documents and Settings\kxy>ping www.yahoo.com
Pinging www.yahoo-ht2.akadns.net [209.131.36.158] with 32 bytes of data:

• Request timed out.
• Request timed out.
• Request timed out.
• Request timed out.

Ping statistics for 209.131.36.158:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

C:\Documents and Settings\kxy>ping www.yahoo.com.cn
Pinging homepage.vip.cnb.yahoo.com [202.165.102.205] with 32 bytes of data:

• Reply from 202.165.102.205: bytes=32 time=1ms TTL=54
• Reply from 202.165.102.205: bytes=32 time=1ms TTL=54
• Reply from 202.165.102.205: bytes=32 time=2ms TTL=54
• Reply from 202.165.102.205: bytes=32 time=1ms TTL=54

Ping statistics for 202.165.102.205:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 1ms, Maximum = 2ms, Average = 1ms

C:\Documents and Settings\kxy>ping cn.yahoo.com
Pinging homepage.vip.cnb.yahoo.com [202.165.102.205] with 32 bytes of data:

• Reply from 202.165.102.205: bytes=32 time=1ms TTL=54
• Reply from 202.165.102.205: bytes=32 time=1ms TTL=54
• Reply from 202.165.102.205: bytes=32 time=1ms TTL=54
• Reply from 202.165.102.205: bytes=32 time=1ms TTL=54

Ping statistics for 202.165.102.205:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 1ms, Maximum = 1ms, Average = 1ms

今天上午，去看mail.yahoo.com时，顺便打开了一下www.yahoo.com，发现可以访问，而现在又不可以了。

2006.11.07 13：40 又可以访问了。

印象中www.yahoo.com一直非常稳定，而这段时间不太稳定的www.msn.com和www.google.com此时却都可以访问，yahoo中国cn.yahoo.com也一样可以访问。而以yahoo目前在中国的策略也不会遇到像Google那样的GFW问题，难道像此前盛传MSN大面积瘫痪是因为技术问题或者是硬件问题？

还有，目前在baidu和google上搜索一下，没有发现有人关注此事，奇怪。

1. 有着999块砖的爱情墙的创意来自于年初的新闻《长城兴建爱情墙供情侣刻字 一块城砖收费999元》。
   这是典型的创意来源于生活案例，就像曾经的一个广告词说的，创意无处不在，关键你我留心。
2. 爱情墙上线于2006.8.12，网络上的爱情墙有免费和容易传播的特点，在新闻发布之前已经有被“刻”掉了700多块砖，而今天已经没有了。
   情感可以吃掉很多东西，而爱情要更加猛烈一些。Yahoo的“时光宝箱”收集的信息也一样能够说明这点。
   在现在这个时代，成为新闻题材的创意将带来流量的飙升，所以不难理解k68在CCTV上亮相后变得慢如蜗牛。
3. 将网站发展成为公益事业，还会陆续推出许愿墙、道歉墙等，同时计划为长辈及没有机会上网的朋友们，在现实中用砖块搭建一面“爱情墙”，目前尚未完成选址工作。已有几家企业对他的创意表示兴趣.
   当谋求不到利益的时候，应该谋求公益。
   有了软条件，硬环境只是时间和机会问题。
   谋求到利益可以做更大的公益。
4. 对比yahoo“时光宝盒”的设计和启动的创意以及信息的处理方式，爱情墙显得简单、丑陋和务实。
   当有了创意时，如果你有资源，你就可以像Yahoo那样针对全球的推广和多种形式的收集，用激光在有意义的地方发射到太空，信息掩埋起来等待2020年的开启。
   当有了创意时，如果你没有资源，你可以像建造爱情墙那样，用简陋的红砖代替古老长城的城砖，用只有文字式的记录，用现实和公益中去建筑爱情墙来纪念这个创意。
   当有了创意，就应该去行动。当没有创意，就应该去活动。
]]> http://dancewithnet.com/2006/11/03/from-love-qiang-to-time-capsule/feed/ 0 http://dancewithnet.com/2006/06/22/find-something-new-in-what-is-old-in-internet/ http://dancewithnet.com/2006/06/22/find-something-new-in-what-is-old-in-internet/#comments Wed, 21 Jun 2006 16:55:49 +0000 秦歌 http://dancewithnet.com/?p=173 推陈出新是互联网的惯例，但是最近感觉特别强烈。 Yahoo(www.yahoo.com)推出了新版已经是很久的事情了，应用了个性化的设计和AJAX技术，其实这只是表面的东西，我们要学习的是Yahoo的规划和一个流量NO.1的网站首页的改版是如何进行的，这种感觉久久不能消失。


BILL GATES在宣布逐步退休前，IE7.0，LIVE，MEDIA PLAYER11(download.microsoft.com)都正式公测了，前两个只要稍微关注的人都很熟悉了，但是我想说的是MEDIA PLAYER ，不仅有感觉不错VISTAR风格，有很多实用性功能，而且支持RM 和RMVB格式。BILL要走了，互联网世界还很热闹，就像Jordan走后的NBA一样热闹，没准他做了几年的慈善家之后，换换思路又杀回来，不管怎样，BILL有能力给人惊喜。


Opera9.0（www.opera.com）正是推出了，设计上沿袭了8.5的设计，主要是技术上的改进和BUG的修复，另外的变化就是内置了BT功能，正加了widgets小东西，就相当于Firefox的扩展，很有意思。Opera是我最喜欢的浏览器，9的表现更是出色，还有这次的推广也做的很有特色，推荐大家尝试使用一下啊。下面是宣传的主题页面，中间FLASH中的6个人，代表六种不同类型的人使用Opera，有意思。


]]> http://dancewithnet.com/2006/06/22/find-something-new-in-what-is-old-in-internet/feed/ 3 http://dancewithnet.com/2005/01/24/when-go-home/ http://dancewithnet.com/2005/01/24/when-go-home/#comments Sun, 23 Jan 2005 16:42:47 +0000 秦歌 http://dancewithnet.com/?p=68 今天中午接到电影mm打过来的电话，也许是n久没有语音交流了吧，开始揣测了好久也没有寻觅出熟悉的味道，真是有点丢人。也许她在绵阳呆的太久了吧，被四川的辣妹子给同化了，呵呵，竟然开始无法感觉在徐州那种熟悉的味道了。虽然常常在网络留言，但是也好久没有语音联系了，工作了，一切都变的忙碌起来，现实中的很多事情都会拉入轨道，就像春节的假期也不会像学生时代这样的轻松了。现在我在徐州，她回来还能相见，但是以后呢，天南地北的，也许就更困难了，她3号晚上到徐州，所以我估计回把回家的时间推到4号，思念不如相见啊，何况相见的机会也不会太多。

由此，我也想到了我的家人，我也有半年没有回家了，而我在徐州四年也基本上没有给家人买什么礼物，好像只带回去一次狗肉，还被普遍反映不够好，这是我在徐州上学的最后一次回家了，是该好好的考虑一下了，最重要的是回家好好陪陪他们吧，四年来我寒暑假几乎没有好好的陪过他们，以后有了工作的理由估计就更加困难了，像这次电影回家也就是10天的假了。暑假的时候，爷爷得了脑溢血，回去的时候，他已经不省人事，病入膏肓了，听妈妈说他发病前几天还念道我什么时候回来呢，在我以为自己没有能力的时候，爷爷就走了对我来说是一个痛，但是回想起来，我们很多时候用自己没有能力来搪塞对家人应尽的爱是不应该的，有能力的时候我们需要尽我们物质上的爱，但是不管我们有没有能力，他们需要的是我们精神和行动上的爱。不应该在有“风欲静而林不止，子欲养而亲不待”的事情出现。

下午上网的时候，遇到游哉，竟然知道她家人安排相亲之事，不禁“羡慕”起来，看来一般的家庭对女孩的关心还是细致入味一下啊，否则，我年纪更大怎么还没有出现如此幸福的事情呢，不过好像听说鱼儿出现过，难怪天天看到他那么幸福啊。呵呵，回来一定要好好的恭喜她啊。

网上浏览的时候，无意看到一篇关于yahoo搜索引擎的报道：

雅虎是最有名的引擎（严格说是目录），所以访问量最大，尽管事实上它后台数据库中收集的网站并不多，不到整个网络世界中的1％。但作为一个搜索引擎／目录，必须对任何的查询都作出一定回应，它需要更为强大的数据库，怎么办呢？雅虎的方法不是建立自己的数据库，而是采用更快、更容易、更方便的方法：购买和租用他人的———Inktomi！

Inktomi是一个真正的搜索引擎，它拥有世界上最大的数据库。实际上，它在后台支持着十几个有名的搜索引擎，比如HotBot、Snap、MSN，当然也包括雅虎，而且Inktomi还提供一种订制服务，这样雅虎和Snap使用着同样的数据库，但结果却因为各自的设置而并不完全一样。这也就是雅虎对于其自己的目录数据的一种补充，当它在自己的数据库中没有找到响应结果时，它就会自动返回Inktomi中的查询结果。

那么如何进入Inktomi的数据库呢？Inktomi．com站点没有“添加站点（addurl）”这一项。事实上只有两种加入方法：一是将站点递交到那些有“addurl”，同时又采用了Inktomi数据库的引擎，如Hot Bot、Canada．com、IcqIt．com，snap．com等；二是Inktomi的检索机器人自己来拜访您的站点。

所以，我不需要像baidu，google，sogou等引擎以一样需要注册网址，就可以搜索到。今天顺便在google和sogou注册了一下网址。



]]> http://dancewithnet.com/2005/01/24/when-go-home/feed/ 0