很常见的，比如。

在form里，这样调用

在一些list的地方，也会把这个值作为一个显示

调用的时候：

这里，做笔记的目的是告诉自己，invert命令很简洁，之前，呵呵，我会用map的方法把每一个item都处理一遍，写代码的朋友一定知道，那样是很常见的思路，但是很不ruby。

经过三个多月的共同努力，sns项目终于完成上线了。感谢众位合作兄弟的持续支持和热情投入。项目走过了开发，完善，再开发，再完善的过程。下面逐步将开发中的经验和大家分享。期待和大家共同交流，提高水平。谢谢！

今天首先介绍一个优秀的插件，city_helper。

代码：http://github.com/yzhang/city_helper/tree/master

网站：http://www.letrails.cn/archives/city-helper-a-plugin-provide-state-and-city-select

功能：实现国内省份，城市的联动选择。

特点：这个省份城市联动选择功能，是sns网站必备的功能之一。我们不用反复的造轮子啦，感谢作者的分享。

修正：插件中有一点点小错误，已经在作者博客留言。使用的朋友会发现的。

1、CITIES，keys中广西应为广东
2、海南的城市没有加，我添加了两个 ‘海南’ => [’海口’, ‘三亚’],

还有一个太合适的设置，一是 state_and_city_select 方法初始化时，省份为北京，城市为所有城市，其中包括北京。研究了一下方法，将city_choices改为

def city_choices
“北京”
end

并且增加 了famous_select 方法，将几个重点城市放置其中，方便选择。

当然应用要根据需求定制，这个插件非常优秀的实现了联动选择，稍加修改，即可实现客户的需求。感谢开源，感谢作者。感谢众多辛苦工作，热心奉献的程序员们。

update:2009-6-3

又修正了一下，编辑所在地时，会列出所有城市的问题。

city_helper

右键另存一下这个文件吧。修改的部分比较下就能看到了。

update:2009-6-30

补充一下页面上的引用。改插件在创建新纪录时，完全没问题。但是当加入到“我的资料”这样的版块，需要修改时，会出现城市列表中，包含全部城市。这里并没有初始化已有选择。下面做了一些改动。

在页面调用上，如下：

<%= state_and_city_select :user_detail, :province, :city, {:state=>{:include_blank => true}, :city=>{:include_blank => true}} %>

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, and browser detection.

里克：最近在把jquery应用的两个Rails的项目中，一直在使用jRails和Rails-widgets这两个插件，完成的非常不错，刚才查jquery的oberve的时候看到了这个文档，分享一下。

| View | Upload your own

正在处理Rails的表单，发现的这个，不错，分享下。

另：第一次使用wp的快速发布，挺好

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日情人节前。情人节给老婆买个平底锅去~~

浅析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变成“开始菜单”，把应用放进去。

.
.

最后，看看一些抄袭者的作品：（是谁我就不说了）

（作品1）

点评：
这个设计单看一个页面就有问题，属于层次混乱。 单个页面的逻辑不顺畅。
用户经常不知道自己在哪里。
而且没有将关联导航和友好导航区分开，次序和逻辑都交代的十分混乱。 

.

（作品2）

 

点评：
这是某社区专家的网站结构图，单看他的页面没有任何问题，结构清晰，层次分明。
但，用户只要一使用，就晕乎。改动过的信息架构（其实只是把内容区的“关联导航（操作和设置）”的放到了“全局导航2（应用）的上面”）使用起来极其不流畅。（为什么不流畅，在这里不多解释）。

该网站从上线到现在一直充斥着一类投诉：靠，怎么加入群呀？ 怎么设置群？ ….

虽然是借用facebook的信息机构，但足见抄袭之失败。虽然只是一个“关联导航（操作和设置）”的变化而已。

.

.

.

此文为抛砖引玉，我想说的内容大概只表达了1/3不到。（这里只说了布局，并未说栏目、导航划分的原则、延续性、扩展性等问题）
.

结束，简单总结：

好的信息架构设计，可以清楚的表现产品定位，可以清楚的阐述内容层次和关系，可以在使用中保持流畅，并能够让用户迅速的熟悉。

所谓“清楚的表现产品定位”：用户一看网站的信息架构，就知道这个网站是干什么的，我是否应该留在这里，我在这里能干什么应该怎么开始去用。
所谓 “清楚的阐述内容层次和关系”：用户一看网站的信息架构，就清楚知道页面上有多少内容，内容和内容之间的关系是什么，什么类型的内容在什么位置。
所谓“可以在使用中保持流畅”：让用户在使用的过程中感觉不到“跳转”和“障碍”，感觉自己在一个平和世界里畅游，非常流畅，不跳动、不卡机。
所谓“能够让用户迅速的熟悉”：用户看到你的第一个界面时，也许需要找一下他需要的内容在那里，也许会觉得这个网站陌生、有距离。但当他很自然的看到第二个、第三个界面后，应该感觉“这个网站很熟悉”，需要任何内容时都不用去“找”，很自然的就能知道什么类型的内容在什么位置。
.

PS:
我敢断言，“呈现层的信息架构和导航”必将成为未来网站产品设计中的核心工作，未来一个网站的设计80%工作都在此。其学问之深并非一两本书能说清楚，更不是一两篇blog能表达明白的。
欢迎有兴趣者深入交流。

里克：最近的项目和未来的一个项目都是sns为基础的应用，可见现在有点规模的站点sns是必备的。看了下面这个文章的确思路清晰不少。

个人观点：UI的设计是一个简-繁-简的前进路线，目前我给客户设计的站点，可以用下面的图概括

主要的想法是：同类的功能操作，放在一起，用tab实现并列，tab的current颜色，实现用户的当前定位。

这仅是个人的想法，需要一定时间来改进。毕竟uchome将在几个月后带来审美疲劳，个性风格必将在sns普及的大环境下有更多的需求。（外包的好时机哦。）所以抓紧理论的研究，能给给客户一个满意的方案。里克个人见解，欢迎朋友们讨论。

这篇文章同样值得看一下：

http://hi.baidu.com/%C2%ED%C1%BCs/blog/item/7bc98638ab83daf4b311c739.html

问题：

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的配置了，希望这次能是一个好的开始。另：今天，已经搬进新房子了，虽然是租的，但是更多的人感觉我自己开了个工作室。貌似是吧，我可以专心工作，写博客，学习了。李猪猪小朋友不会再跑来抢电脑或者：“闪开，就坐一会”啦~！

希望未来两个月可以把工作重新走上正规。加油，加油~~！！湘北必胜~~！！

刚才看了下respond_to这个方法，想写上一些东西。

最新做的项目，要求松耦合。因为之前2个月一直在做康盛的uchome的项目设计，对这种设计方式有点自己的想法。所以在初级设计这个代号kx2009的Rails项目时，走了些弯路。刚才看到redpond_to的文字，感觉又回到了一个正确使用Rails的方向，就是更加的REST，要web service。

REST的概念在我心里是来做资源管理的，这个资源管理要简单，所以我并不喜欢/users/1/posts/22这种资源嵌套，我更喜欢是/users/1，而他的posts就是/posts/index,/posts/22，足够。

多态。这次用到了很多多态的方法，使得设计上每个部分都很松耦合，能够复用，比如那个photos，就可以给活动，圈子，论坛去承担不同Model的图片上传，显示，管理功能。积分和信誉积分采用了同样的设计，下面的Account就是多态。（不过自动累加上一个Model的total字段稍微麻烦了点，magic有类似counter_cache的功能吗？对belongs_to那方的total字段进行自动加减？）

好了，看看Rdoc的描述。大意是：Rails是一个很好的web-service框架。

Without web-service support, an action which collects the data for displaying a list of people might look something like this:

  def index
    @people = Person.find(:all)
  end

Here‘s the same action, with web-service support baked in:

  def index
    @people = Person.find(:all)

    respond_to do |format|
      format.html
      format.xml { render  ml => @people.to_xml }
    end
  end

What that says is, “if the client wants HTML in response to this action, just respond as we would have before, but if the client wants XML, return them the list of people in XML format.” (Rails determines the desired response format from the HTTP Accept header submitted by the client.)

Supposing you have an action that adds a new person, optionally creating their company (by name) if it does not already exist, without web-services, it might look like this:

  def create
    @company = Company.find_or_create_by_name(params[:company][:name])
    @person  = @company.people.create(params[:person])

    redirect_to(person_list_url)
  end

Here‘s the same action, with web-service support baked in:

  def create
    company  = params[:person].delete(:company)
    @company = Company.find_or_create_by_name(company[:name])
    @person  = @company.people.create(params[:person])

    respond_to do |format|
      format.html { redirect_to(person_list_url) }
      format.js
      format.xml  { render  ml => @person.to_xml(:include => @company) }
    end
  end

If the client wants HTML, we just redirect them back to the person list. If they want Javascript (format.js), then it is an RJS request and we render the RJS template associated with this action. Lastly, if the client wants XML, we render the created person as XML, but with a twist: we also include the person‘s company in the rendered XML, so you get something like this:

  <person>
    <id>...</id>
    ...
    <company>
      <id>...</id>
      <name>...</name>
      ...
    </company>
  </person>

Note, however, the extra bit at the top of that action:

  company  = params[:person].delete(:company)
  @company = Company.find_or_create_by_name(company[:name])

This is because the incoming XML document (if a web-service request is in process) can only contain a single root-node. So, we have to rearrange things so that the request looks like this (url-encoded):

  person[name]=...&person[company][name]=...&...

And, like this (xml-encoded):

  <person>
    <name>...</name>
    <company>
      <name>...</name>
    </company>
  </person>

In other words, we make the request so that it operates on a single entity‘s person. Then, in the action, we extract the company data from the request, find or create the company, and then create the new person with the remaining data.

Note that you can define your own XML parameter parser which would allow you to describe multiple entities in a single request (i.e., by wrapping them all in a single root node), but if you just go with the flow and accept Rails’ defaults, life will be much easier.

If you need to use a MIME type which isn‘t supported by default, you can register your own handlers in environment.rb as follows.

  Mime::Type.register "image/jpg", :jpg