刘钢的博客 – 我是UED

//格式化函数 Date原型扩展
Date.prototype.format = function(format)
{
 var o = {

 "M+" : this.getMonth()+1, // month
 "d+" : this.getDate(),// day
 "h+" : this.getHours(), // hour
 "m+" : this.getMinutes(), // minute
 "s+" : this.getSeconds(), // second
 "q+" : Math.floor((this.getMonth()+3)/3), // quarter
 "S" : this.getMilliseconds() // millisecond
 }

 if(/(y+)/.test(format))
 format = format.replace(RegExp.$1,(this.getFullYear()+"").substr(4 - RegExp.$1.length));
 for(var k in o)
 if(new RegExp("("+ k +")").test(format))
 format = format.replace(RegExp.$1,RegExp.$1.length==1 ? o[k]  "00"+ o[k]).substr((""+ o[k]).length));
 return format;
}
// 日期比较

function datecompare(startDate, endDate) {
 var re = /^(\d{4})(\-)(\d{1,2})(\-)(\d{1,2})$/;
 var d1 = new Date(startDate.replace(/-/g, "/"));
 var d2 = new Date(endDate.replace(/-/g, "/"));
 if (Date.parse(d1) - Date.parse(d2) == 0) {
 // window.alert("两个日期相等");
 return "1";
 }
 if (Date.parse(d1) - Date.parse(d2) < 0) {
 // window.alert("结束日期 大于 开始日期");
 return "2";
 }
 if (Date.parse(d1) - Date.parse(d2) > 0) {
 // window.alert("结束日期 小于 开始日期");
 return "3";
 }
}
//添加一天
function DateAddOneDay(now){
 return new Date(Date.parse(now) + (86400000 * 1))
}

这是我在本周珍珠奶茶会上做的分享。编码的细节太多太多，对于前端工程师，掌握主流常用的编码就可以了，并知晓后端处理URL编码的基本思路以及浏览器在 处理编码问题上的差异性。

ps：补充一点，encodeURIComponent和encodeURI，可以参照玉伯的例子
http://lifesinger.googlecode.com/svn/tr … _test.html

原文：http://pdpo.iyenei.com/2010/04/sns-zhuanfa0422/

研究了SNS研究了那么久，今天才悟出一点小小的奥秘。UGC（用户原创内容）转发机制，看起来就是一个小小的功能，很简单——不就是一个转载或者分享功能吗？其实不然。我个人感觉，正因为这个机制，我甚至大胆地把SNS分成两个时代（从SNS信息传播角度来看。个人看法，不代表权威）：目前的Twitter、新浪微博都是SNS2.0；而人人网、开心网很可惜仍是SNS1.0，我们淘江湖也属于SNS1.0。Facebook是一个例外，因为其有多年的基于真实关系网络的用户群体积累；第二是因为其手机端SNS优势；第三是因为其开放平台优势；第四也在不断吸取Twitter成功模式的优势之处；第五由于开放，事实上目前很大一部分Facebook用户一直用Twitter来更新其Facebook主页。所以其地位很难撼动。

Twitter作为SNS后起之秀，我们不能仅把它看做阉割版的SNS（因为Twitter没太多功能，唯独只有微博功能），一个小小的UGC转发和消息即时提醒的功能改变了它的命运。人人网学艺不精，仅学了一个UGC转发的皮毛，精髓的东西没学到位，如下图：

一、人人网也设计了UGC转发，不过只作信息的一级传播：即消息仅在一级用户关系间传递。

1.选择转发用户关系转发的消息，只能穿透一层用户关系：

2.转发后的效果（仅一级用户关系）：

3.被转发者，没有任何消息提醒！

二、Twitter和新浪微博设计的转发功能一致（暂以新浪微博为例解说）：可消息穿透至N级用户关系

1. 选择转发用户关系转发的消息，信息可穿透至无限级用户关系：

2. 被转发者，都会受到消息提醒！

也许我们会搞不懂，为什么有一个评论的设计及一个@提及的设计呢？

其实这就是Twitter和新浪微博设计巧妙之处，它们鼓励用户转发信息，随便也做下评论，即转发并评论功能。

三、举实例说明

如果看不懂，那举一个例子来看：

例如新浪微博A用户有10000个粉丝，他转发并评论一条被转发20次的消息，那他的消息传播路径则是：

A→1→2→3→4→5→6→7→8→9→10→11→12→13→14→15→16→17→18→19→20

这20个人都会收到A的评论及转发消息，同时A的10000粉丝也可通过A的Feeds信息看到这条信息。而这20人收到A的评论及转发，都有非常大的可能性，再次对该信息做转发及评论。而A的10000名粉丝也可能会对A的这条信息做转发和评论。这种方式彻底把SNS的人际关系网络信息传播力挖掘出来。所以在新浪微博上，一条信息一天内可轻易传播至数以千万级的用户（新浪微博很多名人的粉丝数超过百万，以100万来算，如果转发2000次，这些转发者如果平均粉丝数10万，则信息可传送至100万+2000*10万=20010万用户）。其SNS信息爆炸的力量，是相当恐怖的！！

例如人人网A用户有10000个粉丝，他转发并评论一条被转发20次的消息，那他的消息传播路径则是：

A→20

只有两层用户关系，所以人人网的转发设计，并没有挖掘到SNS真正的信息传播力！！

而这里的秘密，仅仅是一个“@”符号及被“@”则的消息告之设计！！

四、淘江湖目前的设计

我们目前也有设计“分享给朋友”功能，但是信息传递，同人人网一样，仍然是一级用户关系，所以这块应该要做一些改造：

五、总结

相信很多玩过新浪微博的同事会有感受：为什么新浪微博那么爽呢：信息交互得爽、信息穿透得爽。原因在于哪里呢？

原因其实就在于一个小小的转发消息设计及对应的消息穿透提醒，这会N倍加速Feeds及相关UGC信息的产生。这就是为什么在新浪上发一条信息，一会就会有N多给回复、N多个转发，很多人都得了微博强迫症，有事没事，要上去看下有没人回复和转发。

这个设计的好处：

1. 更多的UGC内容产生；
2. 更好交互体验，让用户获得成就感和满足感；
3. 更多用户关系链的组建，转发机制，非常利于关键链建立；

     网站设计除了架构设计、交互设计、视觉设计这些方面以外，还有一个非常重要的点，那就是——网站内容。我们在进行网站设计的时候要首先思考用户为什么会来到你的网站，你能为用户提供什么样的内容，什么样的功能（帮助），你如何展示你的内容？要站在用户的角度，去体会你的网站。在体会网站的同事要记得理解用户。用户非常忙，他们都是急性子，短时间找不到想要的东西，就会生气的走开，你就丢失了这样的一位用户了。                            

        用户使用网站，就好比是用户在与你对话，当一段对话变得驴唇不对马嘴时，用户就会抓狂，然后生气的走开，从此再也不理你。用户的性情会严重影响用户对网站的印象，为那些容易发怒的，焦躁的，有压力的用户提供的网站内容要特别的清晰简单。在记录用户想法时尽量记录用户的原话，理解用户在描述他们的需求时使用的语言，这样一来，在编写网站内容时就能够知道用户通常用什么样的词汇了。用户要在网站中有成功的体验，人们必须找到他们需要的内容，理解他们找到的内容，基于用户的理解进行适当的操作。

       人们来到网站总是带着一定的目的或者为了完成某个任务而来，极少是有因为网站看起来好看而来的（部分设计师为了学习而来到一些优秀网站的设计，带着纯视觉的原因而参观网站。）用户在网站中搜寻，期望得到自己的答案，网站最好的方式就是做到跟用户对话，用户又什么疑问或需要，网页能够迅速的反馈，并给出用户解决方法。不过网站本身不会讲话，用户带着大量的疑问来到网站，网站就是为了解决用户的问题而生。

        用户上网很少是为了认真阅读的（除了关注博客这样的以内容为主的网站外），用户在网页上大多数是采用浏览信息的方式，相比较电脑上阅读，纸面的文字读起来比网页的文字有质感也更亲切，正因为如此，我们在设计网站的内容时需要考虑用户浏览信息的习惯，减少篇幅过长的文字堆砌。网站的文字大段大段的出现，用户看起来很伤神。网页的文字能简短就简短写，当写好了一段文字后，一定要仔细阅读是否能够有所删减，网页上给用户呈现的文字应尽量是重点文字，避免废话连篇的占用网页空间。

         在编辑网站内容时，大篇幅的内容写成几个部分并标上标题，这样用户在阅读时就能够先阅读标题了解内容，这样用户就不用费很多时间阅读自己不需要的章节了。当然，章节标题的意义是为了概述一段文字，因此标题需要仔细斟酌，切不可随意的安放一句话就当做标题。另外，标题与内容要比其他的信息接近，当标题和上下的文字间距相同时，标题就会“飘”在两段文字间，让用户茫然。标题和文字间应当使用紧凑原则来布局，这样用户就能准确的知道标题概述的是哪个部分的内容。如图：

        网页需要留有一些空白，分为无心留白和有意留白。因为内容多少的缘故出现的留白是无心留白，特意安排的空白空间是有意留白。虽然无心留白也能够让界面有呼吸的空间，在设计时也应当多使用有意留白，段落中的留白给网站内容留了一些呼吸的空间，让页面更通透，来访的用户不会被大量的密集文字压的喘不过气。

        网站内容可以恰当的使用一些图示，图片比文字更能够直接的传达信息，图片的出现让界面更加生动，也让用户可以更容易知晓网站的内容。但是图片的大小需要仔细考虑，根据网页设计的大小来安排图片的排布。图片的大小应尽量不要占满屏幕，来访的用户看到满屏的一个大图很可能不会记得往下滚动，这样下方的内容就被用户忽视了。

        上图中，右侧的滚动条说明该网站下方还有很多内容有待显示，但左侧的大图片占据了页面整个的空间，造成了页面已到底的假象。视线被图片所占据，这样的图片让用户对网站内容失去了把握的能力，图片已经大到了忽视内容的地步。

       我们在设计网站时很多时候都考虑布局合理性和界面美观性（当然毋庸置疑这些也是非常重要的），关注这些方面设计的同时，我们不能忽视了网站的根本—为来访的用户提供可用的信息，让他们在我们的网站上能够找到需要的内容，顺利的游走在我们的网页中。

原文地址：http://tina.reeze.cn/2010/04/13/webcontent/

转一篇：taobao拔赤的一篇文章 写的很好 查看原文

程序层面，重点是？

框架包含：核心(core)、适配器(adapter)、基础接口(public api)、代码管理(sandbox & plugin)、组件库(widgets)，显然，框架的重点在于基础接口、和代码管理机制的设计。widget的实现是基于框架提供的public api，public api interface一旦定型尽量不要更改，也就是说，设计要遵循编程基本原则：面向接口，而不是面向实现，这个原则的基本要求是接口的稳定性。因此，框架版本升级导致接口更改的情况可以不考虑？

框架设计师应当将有限的精力放在adapter、public api、sandbox & plugins上，以保证框架基础逻辑设计思路清晰，widget和外部plugin的实现则是纯粹工作量的堆积，可以由更多的人参与开发，以分担框架设计师的工作。

需不需要对core进行重构？

比较纠结的问题是，要不要对core进行重构？即将适配器以下都由自己重构，完全放弃现有的jquery或者yui，这个看情况，个人认为，使用现成的“库”是比较聪明的选择，开源的初衷不也是这样吗？我们要做的，只是将jquery式的api或者yui式的api转换成我想要的api格式即可，api的实现，有什么重要呢？

开发者的角色？

框架设计：框架设计师着力设计public api和sandbox & plugin，adapter可以另有人做，只要对adapter有规范完整的黑盒测试即可。
widget开发：可以由更多的人基于pbulic api开发大量的widget，入库保证有code review即可。
应用开发：任何人基于sandbox和widget都可以开发app了。

各自的视野？

对于框架的使用者来说，他们的视野仅限于sandbox、plugin usage、widgets，手旁只要准备一本public api手册就天下无敌了。对于框架开发小组来说，着重维护widget和api，把项目中的widgets不断抽离、code review并入库。对于工程师来说，他们的视野是一本手册和一些demo，没有必要理解框架的细节。对于那些业余的人来说，让他们一眼看到这个框架有这么多widget和demo，他们就会傻乎乎的开始用了。。。

因此，框架的开发，在于专业、在于坚持、在于团队，三者缺一不可。。。