一葉千鳥

初期设计的系统架构比较复杂，采用了 UI -> Data Object -> DB 的三层结构。

简洁。简单不仅是UI的简洁，也包括系统架构的简单化。

永远Beta。快速上线、不断完善的轻型开发模式被视为Web 2.0的典型开发模式，豆瓣在核心功能开发成功之后始终处于不断完善之中。这种模式虽然难免把问题暴露在用户直视中，但在用户的直接参与下的修改完善比“闭门修炼”效果更好。

注重用户体验。众口难调，不可能覆盖到全部用户的需求，所以只要照顾到多数用户就好。通过调研及悉心体验获知多数用户需要什么，如果搞错了及时调整。在具体开发上，阿北遵循的许多做法都值得参考，例如：

1. 选择Python开发的原因，是效率、效率、效率。
2. 重点关注、率先实现核心功能，未及实现的逐渐完善。
3. 网站应用结构要扁平，如果系统多人开发时应纵向切割。
4. 程序员不要有惯性思维，如对数据库不熟悉就采取逃避态度。
5. 在用户需求的理解上，程序员易自我中心，从程序实现思路出发。
6. 乐此不疲地热爱Coding对于程序人员极其重要。

————————————————————

这样的经验虽然是豆瓣总结出来的，其实所有SNS网站都适用。

第二条赞同，典型的结构完善思路，利于分工和节点控制。

第三条赞同，程序结构控制好，这和工程师经验是直接挂钩的，纵深我也说过好多次了。

豆瓣的成功经验
http://zeroliu.blogdriver.com/zeroliu/1175204.html

• 信息的生产、获取、组织与呈现（上）
• 信息的生产、获取、组织与呈现（中）
• 信息的生产、获取、组织与呈现（下）

不能转载，荣我细读，再做评品。

由Google的头号粉丝站Google blogoscoped恶搞，挺有意思的设计。一方面在说明微软的问题，另一方面也揭示了传统的危害。

首先，依照微软的风格，Gmail这个名称实在是太短了，那么最好改为“Windows Live Gmail”这个名称。其次，最好有些Windows软件常见的视觉元素。例如，给邮件标题的空间需要压出来一点留给阅读区，最好是Outlook的三分栏设计。

另外信箱的安全性需要提升，除非你标记邮件时安全的，否则邮件附带的外部链接均无法打开。同时，登录的地址一定要是username@gmail.com的形式，而不能用username登录。

至于浏览器的链接地址，为了安全性考虑绝对不能显示成http://gmail.microsoft.com，而要改成http://by114w.bay114.gmail.live.com/mail/mail.aspx?rru=home

邮件前面的多个邮件选取框要变成图标的形式，还要多放点广告，否则多浪费空间。一定要在收件箱里显示点垃圾邮件，否则垃圾邮件拦截功能谁会用？

充分利用上部的空间，放上点广告。然后有点微软精神，给用户2MB空间，对了，一定要显示成2000KB的形式。最后，登录后用户首先看到的页面一定要是欢迎页面，不能让他们直接看到收件箱。

现在的颜色设计有些太淡了，加点渐变，阴影效果，再加点载入效果。广告放不下？算了，去掉搜索功能，加入Windows的帮助小狗。任务完成。

假设Gmail由微软设计……
http://www.donews.com/Content/200711/6825f9d3ffb047bf90a8e3d9cd2adabf.shtm

Jacob Neilson告诉过我们：不要使用“按这里(Click here)”或其他不具有描述性的链接文字，很多研究机构的报告也支持他的论点，证明使用者讨论这种缺乏资讯的链接。

Copyblogger提出了自己的论点：当你希望人们去做某件事都时候，就直接教他们那样做。并公布了Marketing Sherpa近期的研究数据，在电子报中使用“点击继续(Click to continue)”做为文字链接，可以提高8%的点击率。

其实关于usability, web standard这一类的事情都是这样，“###”不是个好主意，但也没多坏。叫使用者“按这里(Click here)”不是个好主意，但也没多坏；用户可能会在心里咒骂你干嘛不写清楚，但还是会乖乖地按。

「按這裡」不是個好主意，但也沒多壞
http://blog.yoren.info/2007/11/19/483/