原文： Remy Sharp has gone through the jQuery and Prototype frameworks, which are probably the two closest to each other, and has done a side by side comparison of the frameworks by showing you how similar things work on both. The presentation looks into the utility functions, selectors, DOM manipulation, DOM walking, events, Ajax transport, [...]

http://www.noupe.com/css/47-excellent-ajax-css-forms.html 正在处理Rails的表单，发现的这个，不错，分享下。 另：第一次使用wp的快速发布，挺好

最近太多的sns站点需求摆在脑海里（所以晚上睡不着觉，哎），所以画了一张，给予自己目前项目设计的ui框架，姑且是一个概念图吧。在此简单笔记一下思路： 1、header，footer：目前的趋势是更加充分利用header的空间，增加隐藏层，通过鼠标实践显示一个列表内容。header，只提供整站大分类导航 2、sider_bar：应用导航。放到左侧，更加重用户的关注度，用户会更多的点击里面的连接。比如uchome把博客（发布），图片（上传）等操作放到这里。下面是游戏的列表。 但是对于所有页面，side_bar并不全都适合，1、影响到内容的展示，占用了200px空间。2、side_bar内容可能不符合该页面主体内容，比如页面为博客展示页面，side_bar内还出现相册，上传图片，圈子，讨论区等等连接，会给人一种杂乱的感觉。 还有可能对seo产生不良影响。 3、main，当side_bar隐藏时，width为100%。为主体内容提供容器。 4、tab和button：二级页面导航功能，资源页面导航功能。比如 活动 分类，tab包含 全部，热门，最新，登陆后显示我的活动。 这样设计，使得在header进入后，tab可起到位置定位，比如当前tab和其他tab可用式样来区分。 button强调该分类下的资源重点操作，如“创建一个新活动”，“发表一个新话题”。 这种设计的考虑是，二级分类多数为资源，button体现了吸引用户操作该资源。 ps：这是uchome中的设计，个人非常喜欢。 5、content和content_bar content为主要内容展示空间，content_bar辅助显示动态，管理按钮，广告等内容。 content_bar可隐藏，内容不固定，根据content来决定内容。 最后，个人总结的uchome ui中的问题 1、css太过复杂，结构不清晰，没有使用layout和theme分离的设计 2、side_bar部分为全局模板，多数页面显得占地方，不过上面的重点连接也是sns站的主要功能，所以需要灵活设计 3、js设计占用了太多页面代码，html浩如烟海啊 4、mtag这个名字让我很摸不着头脑，类型复用程度低，根本无法实现资源的设计和管理。比如，Rails中的topic和photo的多态设计，使得其他资源均可以使用，但uchome中不可以。 5、uchome不是一个技术产品，它是个市场需求下的产品，不能期望太多，但是，无论是php还是Rails去设计一个sns站点，uchome的设计细节非常值得学习。 里克，2009年2与13日情人节前。情人节给老婆买个平底锅去~~

声明：本文转载自http://www.5gme.com/space-84-do-blog-id-8867.html 浅析facebook的信息架构 facebook的信息架构设计，是目前为止互联网上我见过的最合理的信息架构。 每次培训，我基本都需要拿20分钟左右的时间来解析它，包括老的、新的、被抄袭的。 一直打算把这个解析过程写下来，但讲的时候可以图音并茂，写的时候确实表达起来很难。 今日权且一试，希望能把培训师讲到的内容表达出30%。(只写现在界面上表现出来的东西，不分析栏目划分已经扩展性问题了) 先看facebook老版界面的信息架构：   大架构的发展和变迁过程：  1、最开始，facebook的整个信息架构主要分成三个部分：“系统核心导航区”（如上图，蓝色部分。包括LOGO和两个全部导航）、“应用导航区”（如上图，黄色部分。包括一个全局应用(搜索)和所有的应用列表）、“内容显示区”（如上图，橙色部分。主要分成局部导航、主内容、辅助内容三个大部分，有N多主要内容）。 由于“系统核心导航区”、“应用导航区”的常态存在和内容繁多，在用户使用时经常会干扰用户对主要内容的关注。所以，facebook在视觉设计上，特意通过错位特别突出了“内容显示区”（如上图，橙色部分。我看到有些设计师说“facebook的视觉很烂，把那个位置扭曲了很傻”，其实他们根本没有看出设计者的意图，很傻！） 2、后来，facebook添加了“协作翻译”，这是一个全局功能。按照一般的设计思路，这个“翻译”的位置选择可以：放在“全部导航3（设置）”的位置，或作为“全部导航2（应用）”的一个常态项目。 但facebook没有这么做，为了更好的表现其牛逼的UGC魅力，facebook的设计师大大加重了“翻译”在导航上的比重。“不伦不类”的把这个应用，突出在了“内容显示区”的右上角，同时在“全部导航3（设置）”里加了一个语言切换的导航（后来大概是发现“语言切换”的使用频率很少，现在给调换到了底部版权信息的右侧）。 3、再后来，facebook推出了IM功能。对于facebook来说这是一个常态应用，在信息架构上必须常态存在。于是他们把“即时通讯”结合了“信息通知”一起作成了“状态栏”的模式。  （我猜想，这个时候facebook的设计师们已经有了“操作系统”的设想） 这是一个很艺术性的设计，处理的非常好。而且IM本身设计做的非常轻巧易用。 在此之前我曾经猜测，他们可能会把IM放到“系统核心导航区”的“收件箱”的位置，结果我错了，他们找到了更好的设计方式。 4、如今，由于“系统核心导航区”（如上图，蓝色部分）、“应用导航区”（如上图，黄色部分）是常态存在的内容，占据了界面很大比例的位置，再加上内容显示区（如上图，橙色部分）本身还需要一些“关联导航”“友好导航”已经“标题”的内容，导致每个页面真正展示“内容”的区域很少很少。 作为一个网站，这没有什么大问题。但作为一个“应用平台”，这无疑有很多的障碍，界面内容展现严重受限，用户的视觉总是浪费“常态导航”上。想一想如果你的操作系统界面，1/3空间长期被系统菜单占据，你会不会崩溃？ . 我对老版设计的，几个主要评价： 1、逻辑清晰，层次分明严谨。扩展性好。但在内容呈现上，缺乏创新。 2、facebook整个网站的核心是“我的”，这就是他顶部系统核心导航区（如第一张图，蓝色部分）。另外，顶部还有“全部导航3（设置）”。整个顶部是网站的核心，用户不可能被用户或者第三方改变，也是facebook的官方保留“区域”。 但，这里有个细节他们一直蹑手蹑脚没有真正放开，就是那个权宜之计的“home”。 事实上现在大部分用户返回首页都会点击logo，facebook在主导航上取消了“home”，但又不敢完全取消，于是在“全部导航3（设置）”那个区域前面加了一个“home”，而且还把这个链接和logo的链接作了区分，一直保持着对数据的检测（包括最新的信息架构设计也一样作了链接区分，在检测数据。有兴趣人可以看看logo的链接和home的链接地址不一样） 3、facebook的主要导航其实是“应用导航区”。这里影响了主要内容区的显示。 “系统核心导航区”和“应用导航区”包围着内容显示区的做法，结构和逻辑都很清晰，而且容易理解。 4、主要内容区有一个设计一直存在争议： 比如，在“图片”的页面，facebook加了两个链接“我的图片”“有我的图片”，这两个链接被处理成了“友好导航”，用户点击后到了新的界面，新的界面无法返回当前“图片”的应用。 但，就国内用户（我不是很相信在这个地方存在国内外用户使用习惯的偏差）的使用习惯来看，这两个链接应该被当作“关联导航”甚至“局部导航”处理。这也是UCH在抄袭facebook时做过的为数不多的“好改动”之一。 . . 再看看facebook现在新的信息架构设计： 如上所说，老版的信息架构显示了facebook的主要内容展示区域。使每个界面都背负了严重的“导航任务”。 于是facebook开始尝试改变。刚开始，他们试图拉宽整个内容显示区的空间，把应用导航区和常态提示信息放到系统核心导航区下面，做成windows“开始菜单”的模式。（这个版本有些人看到过，UCH现在准备出的新版抄袭了这个设计。在这里不做详细评价） （也许他们觉得这样还是太啰嗦，内容显示区还是不够大），现在他们把应用导航区合并到了系统核心导航区里。 不仅是内容布局上作了改变，连栏目的规划都有了新的变化。（这个版本可以在“http://www.new.facebook.com”看到）     主要变化： 1、将所有全部导航和引用压缩到顶部的一个区域，甚至不惜大举压缩LOGO尺寸，让这个区域尽可能的小。（如图，蓝色区域） 当然，这样的大变化也伴随着其栏目划分的重新规划。 2、将广告从左边拿到右边。尽可能的放大并在主要的视觉“焦点区”突出具体的页面内容。 3、保持IM和通知的常态显示，并将“翻译”合并到一起。 . 我对新版设计的，几个主要评价： 1、新的信息架构设计其实面临着很大的调整。要从一个传统网站到一个应用平台作专门，确实很难很难。对于一般的界面设计师来说，这个任务很难完成。但facebook的设计师做到了，而且从时间上来看他们很有前瞻性，呈现层的设计甚至走到了策略之前。 2、新的设计改的大胆，页面就应该表现出“系统”的感觉。 每一个应用就像一个软件。“应用”列表就应该合并起来，“应用”和“应用”之间的切换根本不需要那么快捷。 3、顶部蓝色的主导航区应该再加宽（只要不是100%宽度就行）、压低，完全做成状态栏的样式。 3、把应用夹杂到“我的”一些选项中间不合理。特别是放在好友和收件箱中间。 如果是我设计，我会把LOGO变成“开始菜单”，把应用放进去。 . . 最后，看看一些抄袭者的作品：（是谁我就不说了） [...]

在目前的项目中使用了Fckeditor On Rails插件，没想到碰到很不少问题，网上google一下，发现大家都有这样的问题，有的是这个plugin的问题，有的是fck的问题。为了方便日后对系统的管理，在此笔记一下目前碰到的诸多问题和临时的解决办法。 问题： 1、无法编辑内容，编辑时出现js问题 2、上传图片时无法准确放入指定Image文件夹路径中 3、上传文件时无法得到params[:Type]变量 4、无法使用 fckeditor 的文件上传配置 5、上传中文rar文件时，出现110错误提示 解决： 1、插件似乎没有考虑修改的问题，之前我的asp做的EZAdmin中，简单的传递内容即可，现在看来插件里并没有去处理传进来的value属性，所以在fckeditor.rb中增加了这个方法，使之能够编辑内容。 2、图片可以传递入Image文件夹内，但是结果中没有后面的文件名，具体原因似乎是版本的事情，这个暂时不去对比了，改了fckeditor_controller.rb中的返回值内容，也就是使 OnUploadCompleted的第二个参数带上了文件名，暂时得以解决。 3、问题同2类似，这时无法得到params[:Type]参数，看了下fck_image.js里，对图片上传设置了type属性为image，但是文件上传，或者叫Link上传时，没有设置这个属性。所以在fckeditor_controller.rb中，当该属性为空时，设置为File。这个修改非常危险，但是目前没有更好的方法。 4、在文件上传时，作者自定义了MIME_TYPE数组，来做校验。这个有点。。。。所以暂时将几个类型加上，解决doc,zip,rar等文件上传先。 application/msword application/x-zip-compressed application/octet-stream （rar的） 5、当上面都解决完，发现对中文名文件无法上传，哭吧。。。。。。 下面是我修改完的Fckeditor on Rails plugin，希望朋友们多指正问题。谢谢。 说明：plugin版本：0.5.1，Rails版本：2.1.2，两个部分的，不用安装了。 fckeditor051-for-rails212 javascripts 后记： 记得每次修改完插件内容后要重启一下服务

问题出现了： 转移了discuz！6.1论坛到新的服务器，因为使用的火狐插件来播放flash，所以打开时发现提示：“failed to open include/common.inc.php”的提示。 分析： 之前，论坛在windows环境下，搭建的php，转来后，虽然还是windows，但是改成了apache做前端。因为php的设置肯定不会转过来，所以应该在配置或权限上出的问题。 检查： 权限上，用论坛自带的检查看了下没有问题，所以可能是apache配置或php的配置问题。 查了下百度和google，大家都在认为貌似是父路径的问题。看了下open_basedir的描述，貌似是问题的关键，可是里面提到了safe_mode设置，对比了下windows的php环境和apache的php环境配置，发现windows下的safe_mode=Off，而新的apache环境是On。 解决： 改成Off后，正常访问了。 后话： 很久没有动apache的配置了，希望这次能是一个好的开始。另：今天，已经搬进新房子了，虽然是租的，但是更多的人感觉我自己开了个工作室。貌似是吧，我可以专心工作，写博客，学习了。李猪猪小朋友不会再跑来抢电脑或者：“闪开，就坐一会”啦~！ 希望未来两个月可以把工作重新走上正规。加油，加油~~！！湘北必胜~~！！