您可以用Axure RP绘制流程图(如下图)，来解释这个功能设计的逻辑判断。

接下来，开始设计页面的操作互动：
1) Widget命名：针对操作相关的栏位、按钮、动态面板，在Interactions窗格的Label一一填入名称，以利后续的设定识别。

2) 新增Case：针对”登入”这个Button Widget，在Interactions窗格中新增OnClick (点击时触发) 的Case，并在「Interaction Case Properties」视窗中点一下「Add Condition…」连结。

3) 设定Condition：在开启的「Condition Builder」视窗中，您可以使用下拉选单建立如下的逻辑判断：

当您在设定时，下方的Descritpion区块会自动产生逻辑判断的描述：
If text on widget Username Field equals “UserXper”
and text on widget Password Field equals “12345”
（如果「Username Field」输入的是“UserXper”，而且「Password Field」输入的是“12345”）。
4) 选择Action：按下「Condition Builder」视窗的【OK】钮，回到「Interaction Case Properties」，再选择当符合这个逻辑判断时，所要执行的动作。比如：导回网站首页、显示招呼语，登入的文字连结变为登出。
当您设定了Case的逻辑判断，您会发现 Interactions窗格中的Case名称后面会自动加入一个以“If” 开头的逻辑判断描述。同时，这个Case的图示会变成绿色，强调这个 Case使用了逻辑判断。
Axure RP Interactions De.ion
最后，实际完成的Prototype互动设计如下图动画：

如果您想要进一步了解这个示范内容的详细设定，请下载：Axure RP Prototype范例-旅游网站RP档1M bytes (下载后请解压缩)。

TB在各个关键产品与购物流程中陆续加入了用户反馈入口（图1），也开设了各种官方论坛收集用户意见和建议，因此会收集到大量纯文本数据。如何对这些数据进行分析、从而指导产品改进？本文将讲述，将内容分析（content analysis）应用于网络文本数据（如，用户反馈）处理的理论基础与实际应用。包括：内容分析法简述；企业中应用内容分析的步骤与技巧。

图1：淘宝的用户反馈入口

PART1 理论基础：内容分析法简述

内容分析，是指利用明晰的编码规则，将大量文本信息转化为定量数据，并归于若干类别以分析信息特征的方法)。内容分析有三个特点：

1）客观性。内容分析不受主观偏见影响，有标准化的研究过程，研究员对结果持开放态度；

2）系统。内容分析过程（取样、分析、编码等）有统一、标准的规则和程序；

3）定性与定量结合。内容分析通过定性研究找出能反映内容本质的特征，又将文本转化为定量的数据，分析结果可用频次、百分比，或相关系数等来表示。

这种研究无需直接接触研究对象，在传播学、情报学、教育学等社会学科有广泛应用，但目的有所差别。鉴于本文所述的应用类型，更倾向从情报学的观点去定义内容分析的目的：通过分析内容了解本质性的事实和趋势，并揭示隐性问题。换句话说，在用户反馈分析中应用内容分析法，目的在于对反馈信息进行系统的归纳分类，整理问题点并评估其严重性，从而有针对地实施改进。

内容分析的基本流程如图2所示。科研中，还有训练编码员（5、6环节间）、测量编码员之间可信度（6、7环节间）的步骤。在企业环境中由于受到时间等调研成本制约，可选择性执行这两步。具体每一步的实施将在PART2中通过实例详述。

图2：内容分析流程图

PART2 实践应用：步骤与技巧

如前所述，在企业的用户研究中利用内容分析处理文本型用户反馈数据，最终目的在于，通过科学有效地总结归纳问题来促进改进。因此应用文本分析的步骤和技巧有以下特点：

现按照前文所述的分析流程，以旺铺升级后一周内的用户反馈分析为例，介绍内容分析在企业用户研究中的实践步骤。

分析目标：收集、归纳用户体验问题及用户看法
分析范围：

• 主题领域——以某产品，或某流程的用户反馈为范围
• 时间段——如，改版后一周内、新上线一周后……等。值得注意的是，在产品大事件（如发布、改版）时间段，收集到的问题会较多，用户反馈两极化明显。在系统大事件（down机等）时间段，反馈的问题会较集中，用户反馈多为抱怨。

呈现在用户研究报告中，也就是一句简短陈述，如：旺铺升级后一周内的用户反馈总结

【第二步 决定抽样样本】

包括决定以下三方面

1）内容源：选择从什么地方（帮派？问卷？…等）抽样
2）时间：选择在分析时间段的哪几天（全段？隔天？隔周？）抽样
3）内容：对内容进行随机或等距抽样

这意味着研究员要对产品周期有充分的了解和认识。在本例中，我们的抽样样本是，旺铺升级后一周内（7天）用户通过旺铺装修页面“提意见”入口（图3）提交的所有数据。

——>

图3：旺铺用户反馈收集入口

【第三步 确定分析单位】

分析单位是内容分析中的最小元素，要对此给出明确清晰的操作性定义。在本例中，分析单位就是一名用户所陈述的一条意见。值得注意的是，并非以一次提交的数据为单位，因为一名用户一次性可能提交若干条意见，需要把意见拆开，每条为一个分析单位。如图4所示，“删除模块删完不能添加”、“发布完又回到装修页面”分别是一个分析单位。

图4：分析单位举例

【第四步 建立分类】

分类是内容分析的关键步骤，决定了后续的定量分析的有效性。类别是内容分析的基本单位，每个分析单位都能且只能归入某类别中。在学术研究中，往往依据研究理论或参考过往研究结果来分类。在企业用研中，则要对产品有充分了解，并与产品经理合作制定分类框架。因为这便于分配问题解决负责人。

穷尽、互斥是分类的两大原则。分类应涵盖可能的问题范围，但由于事前无法全面预知内容，最好设立“其它”类以满足穷尽性。若有≥10%的分析单位被归入“其它”，则分类不当。类与类之间是不重合的，若有一个分析单位可归入两个或以上类别，则分类不当，或分析单位不准。

分多少类为合适？类别太多会导致某些类的分析单位少而失去统计意义；类别太少，不同性质的分析单位归入同一类，可能会掩盖显著性差异。考虑到将分类合并比将分类拆分容易，建议宁多勿少。在无从下手的情况下，可试检验50-100条分析单位。

在本例中的分类如图5——

图5：旺铺用户反馈的分类与说明

该分类倾向于以问题解决方（如系统问题由开发人员解决、功能需求由产品经理解决、交互问题由设计师解决）为基础维度，便于推动改进。对于页面、功能有限的产品/流程，也可按照页面或功能分类。对于本例，也有针对功能、页面进行分类，主要体现在二级编码中，详情见下。

【第五步 制作编码表 试验性编码】

制作编码表是在大分类的基础上进行细化，以更好地聚焦问题。在这一步，要尽可能细致全面，才能保证有效的数据分析。对每个编码的含义要有所说明，尤其在编码者不止一人的情况下。在本例中，对功能需求这一大分类的部分编码如图6，其原则是尽可能涵盖所有功能。而对于系统问题、交互体验问题，子编码又是应内容特点、以另外的维度设定的。

图6：编码表示例

在编码表制作好后，抽取50-100条分析单位（如100条反馈）进行试编码（coding），以检验是否够细够全。当然了，在实际实施编码（第六步）过 程中可能发现编码不够用的情况。此时只能新增编码，并对该分类下的所有分析单位重新编码。所幸的是——也是内容分析的优点之一——即使发现问题，能在不影响数据本身准确性和完好性的情况下弥补错误。不像问卷调研或现场实验，一旦实施，有错误也无法弥补，只能抛弃数据。

【第六步 收集数据 实施编码】

收集数据就是按照之前所定义好的范围与抽样标准提取数据。通常将数据导入到EXCEL中进行处理。在本例中，每条用户意见（即最小分析单位）对应一行（图7）。

图7：原始数据示例

然后便可开始对每个分析单位进行编码，是纯人工的过程。目前也有一些文本分析软件可辅助，但这些基于分词技术的软件智能程度不足，且实施聚类分析对样本量有要求（至少上万条），更适合用于海量文本数据的分类。

编码过程可借助EXCEL的文本筛选功能。比如笔者用得较多的是“包含XX关键词” 的筛选方式（图8），能有效提高编码效率。在过程中要把无意义的分析单位（如在本例中，会有用户在反馈中打自己店铺的广告）给清理掉。

图8：文本筛选功能示例

初步编码结果如下图所示，接着便可进入分析、报告阶段。

图9：编码结果示例

【第七步 分析 报告结果】

分析包括两部分。定量部分使用描述性统计，计算各分类中条目、各个码类的频数、百分比。如果还能结合到其他变量，如用户的星级等，可进行更复杂的交叉分析、卡方检验、t检验、方差分析等。定性部分，是对某子编码下的所有条目进行梳理，总结出问题点。

要注意的是，频数、百分比不是衡量严重程度的唯一指标。比如我们发现大量系统问题这一分类的用户意见，但基本上说的只是发布失败和速度慢两点。 功能需求这一分类下的意见总数相对较少，但问题有10余种。因此，定性与定量分析的结合，才能反映各分类对整体体验（满意或不满意）的贡献度大小，以及问题聚焦/分散程度。示例如下：

图10：反馈总结示例

进一步的分析还包括对表象所隐含的问题的推断。例如笔者发现图11所示的问题。

图11：深层分析示例

在企业中，内容分析报告的输出形式更灵活，关键在于有效传达问题，推动问题的解决。尤其用户反馈的内容本身比用户研究员的分析归纳更具冲击力，更易引起同理心。

在本例中，笔者的输出物包括：

• 原始数据EXCEL表，按分类将问题分别放在不同sheet里（图11）。在每一张sheet里，可通过筛选功能，看具体某个方面的用户反馈原话。要注意的是，此时会把编码重新转化为文字描述便于理解。
  
  
  图12：EXCEL 输出物示例
• 用户反馈总结ppt，将各分类中的问题汇总罗列，用于向项目组宣讲，并探讨解决方案。陈述问题时，可引用典型的用户原话。比如有10个人反映同一问题，可选取问题表达最清晰或感情色彩最浓烈者的原话。

本文介绍了内容分析，以及内容分析在企业用户研究中应用的步骤与技巧。内容分析的优点有：1）相比实验法、问卷法等，较为节省人力物力；2）内容可被重复分析，可靠性较大；3）无需直接接触研究对象；4）操作过程若产生问题，错误易被弥补。它的缺点在于：1）人为因素（如如何分类、编码）会极大影响结果；2）编码工作需时较长、单调。

下面就是很明显的例子:

 1、浏览网页时，人的注意力最容易被人脸吸引
2、正面的美丽女性人脸最为吸引人 （听上去很废话，呵呵）
看到这篇 How A Pretty Face Can Push Visitors Away，里面用过我之前提过的广告例子。说的意思是：用漂亮脸蛋吸引了观众之后，还要引导观众去看你想要传递的内容。

 好像这幅图，脸蛋没什么问题，看上去舒服，而且专业。

可是，你的眼睛会怎么动呢？

1、看网页
2、看到有PPMM，于是眼睛转移到PPMM脸上
3、看到PPMM的眼睛正在看自己……于是转移开视线
结果就是广告商花了钱让你看了MM，却没能把想传递的信息传递给你。

 下面有一个视线追踪对比测试，给定两个内容相近的广告：

唯一的区别是model的视线，第一幅是直视观众，第二幅则看向产品。
得到的热点图如下：(注意眼睛的位置，这个和上面两张图的位置对调了)

结论很明显：
1、观众会追踪广告中人物的视线。
2、在Banner广告上放美女图片时——注意看看那个美女在看哪里，把你想要传达的主要内容放那里。

 虽然不知道QQWeb输入法官方页面的具体上线日期，但从各搜索引擎中尚未收录“QQWeb输入法”这一关键词来看，上线日期还不是很久。还有官方页面上的 “问题反馈”也还是404，可见之仓促；不过能早一天算一 天，抄得快也是一种能力。

QQWeb输入法官方网站：http://py.qq.com/web/

我一直都是豆瓣“关注”和“朋友”两种关系并存的强烈反对者，我认为豆瓣上的友邻关系，应该更像Twitter，简单松散的follow关系（Twitter原来也是有Friends的，后来去掉了，正确的决定）。

豆瓣的“朋友”关系，给我造成很大的困扰。经常有人要求加我为好友，一来我根本不认识这人，二来他在豆瓣上也没提供多少让我觉得有价值的内容。对于这种加好友请求，我通常会拒绝。但这种请求挺多，总得一一去看过才决定是否拒绝，很是无趣。

作者：白鸦

现在，豆瓣终于决定简化用户关系，只保留“关注” 关系，这种关系无需征得对方同意。但在关注中，增加了一个“同时标记为朋友”选项，就是说，你可以关注某人，同时将他标记为你的朋友。这么做是为了仍然可以把部分日记/相册设为“仅朋友可见”。

我不知道在豆瓣上，到底有多少用户会使用“仅朋友可见”这个选项。不过在我看来，这实在是一个没有必要的选项。反正我没有遇到过只适合“朋友”，却不适合其他人看的内容。“朋友”原本就是个挺虚的概念，适合A朋友的，未必适合B朋友；既适合A，又适合B的，通常对所有人都适合。“仅朋友可见”，降低了社区分享的价值（顺便说，我也不喜欢5G的“好友可见”选项，但这是UCH的设置）。

豆瓣简化了用户关系，是革自己的命，但保留了“朋友”选项，却让这革命显出半吊子的特色。如果一定要保留“仅朋友可见”，那也应该让用户自己给友邻分组，自己决定哪一组友邻可见。

一如既往地，豆瓣的任何改动，都会招致部分用户的反对，即使保留了“朋友”选项，仍然挡不住那股唧歪的声浪。唧歪的人永远都会唧歪，跟你做了什么无关。哪怕你说今晚我们吃土豆吧，他们也会成立一个小组，反对吃土豆，或者反对今晚吃。

我还是那个观点，对网站负责的是你，而不是你的用户，不要听用户的。

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

（update）看到不少误读，我简明一下观点：豆瓣这种生人社区需要充分媒体化，双向关系会阻碍这个发展，这次改变的方向好；展现上建议改进，加好友的时候表现出“朋友”只是一个分组而已（要不要让用户自定义分组，后面可以再说），好友展示的时候更要彻底的表达出“朋友”只是一个分组而已。

1、双向的朋友关系，意味着最关注的是那个人；单向的朋友关系，意味着最关注的是那个人背后的信息。

2、也许你会说社区本就是媒体，媒体本就是社区。但我只是想强调：双向的朋友关系更偏重社区，单向的朋友关系更偏向媒体。

3、鱼和熊掌不可兼得，两者都选，就会别别扭扭，到头来发展受限。豆瓣从最早的双向关系，过度出了一个单双向并存的阶段，中间过程很是尴尬，尴尬的表面是用户体验，实质是产品方向的犹豫。

4、豆瓣终于选择了只有的单向关系，这个选择“对于不对”，只有未来的数据才知道。部分用户的那些反馈，一时浮云，而已。
（改进产品和用户体验的时候，过于听信客服电话、用户反馈，其实是一个杯具。）

5、豆瓣这次的变化对于用户来说，其实很小（不知道哪些人怎么反应如此激烈～）。但对于豆瓣来说，挺大。

6、在这次变化的体验处理上，动作太小。
我建议豆瓣干脆做的彻底点：把“关注的人”从信息结构上去掉仅作为“友邻”的一个说明；在UI上把“好友”属于“所有友邻”的一部分，只是众多友邻一个特殊的标签而已，表现的更清楚。

7、Keso说“好友”这个特殊标签压根就应该彻底去掉，我不赞同。原因有二：

1》已有用户的数据很重要。特别是那些把照片、日志设置了只有好友可见的用户的隐私，需要被充分尊重。充分的引导之下，他们未来也会成为豆瓣媒体化很重要的组成部分。

2》网站的运营路线无须矫枉过正，开放性的信息分享未必要做到极致的开放。“好友”这个特殊标签，可以让豆瓣在开放性关系的媒体路线上，保留一些“私密”的余香，未必是坏事。

有几点值得注意：

   1. 被引用推讯会部分引用目标网页的格式。
   2. 被引用推讯会复制 Twitter用户的背景。

FOR XP
改变系统hosts工具-XP
FOR WIN7
改变系统hosts工具-windows7

其他平台没有试过。
使用 python2.5 + wxpython2.8 + py2exe
功能比较简单。

新版支持的HTML5新特性包括地理位置API、App Cache、web sockets和文件拖曳功能，以及整合了Adobe Flash。更令人瞩目的也许是它的性能：基准测试显示它的SunSpider和V8得分比前一版beta提高了10%，比Chrome 4快30%。它的SunSpider得分是345.6 ms，相比之下Chrome 4.x是483.3 ms，Firefox 3.6.3是876 ms，Safari 4.04为530 ms，IE8是4979ms，IE9平台预览版是783.6 ms。

据谷歌产品管理主管Johanna Wright称，早在2006年时，谷歌就开始测试各种新工具了。她说：“我们只是在等待，等我们的技术发展到目前这个水平。”

微软在11个月之前推出了必应搜索引擎。现在，必应搜索在美国搜索市场的份额已经从最初的8%上升到了12%，但是它获得的市场份额主要是雅虎以前的市场份额。 据市场研究公司comScore称，谷歌的市场份额去年一直稳定在65%左右。

另外，谷歌还启用了新的Logo。新Logo的色彩比以前更加明亮，由红、蓝、绿和黄色四种颜色组成，同时减少了背景阴影效果。谷歌对网络 搜索结果网页作出的最大修改是在网页左侧增加了更多的设置工具，用户可以利用那些工具来设定搜索的范围，比如新闻、图片、博客和视频等。 新设置选项还为用户们提供了很多其他的兴趣主题。 

谷歌以前的Logo中包含了TM的字样，以表明谷歌是一个商标。它这次启用的新Logo去掉了TM的标识，但那并不意味着谷歌放弃了它的商标权。

下载 （请翻墙下载= =！）