设计之外 - UCD大社区

Ps Play——移动端预览Photoshop设计零阻力

admin — 2013-04-10 19:44:12

还在为繁复的导出设计稿到手机上查看效果烦恼吗？没错，业界有不少小工具可以帮到大家，但是它们给力吗？很显然，在公司超级强大的网络架构下，它们无用武之处。所以，【Ps Play】应运而生，下面为大家介绍下这个微创新产品。

1、Ps Play 可以通过WiFi，实时在终端设备上预览电脑上Photoshop的设计稿，可同步调试及截图保存到移动终端，并可以通过Email、QQ、微信等工具即时分享。

2、具体介绍

以便捷、快速的方式，辅助设计师准确把控设计效果，解决长久以来导入设计效果图到终端设备测试的繁复问题，并可以快速通过即时聊天、社交软件进行分享和讨论。

具体操作如下：

（1）确认您的电脑与iPhone手机连接是同一个无线WiFi网络；

（2）在Photoshop菜单[编辑>远程连接]下开启连接，需确定您的Photoshop版本在CS5.5以上才能使用此功能；

（3）在手机Ps Play可用连接菜单中找到开启的Photoshop连接热点，并点击连接；（注：Tencent FreeWiFi 比较复杂，无法自动检索到Photoshop热点，所以需要手动加入连接，如你在家中等比较简单的局域网，Ps Play会自动帮你搜索到热点，轻松连接）

（4）尽享Ps Play即时预览Photoshop工作画面的愉快体验，同时还能为每个工作阶段快照记录并分享

微创新点：

（1）同一局域网可连接IP地址前2段一致的服务器（例如10.66.53.192和10.66.53.67、 10.66.53.192和10.66.67.23两组示例都可以正常连接）；

（2）兼容自动搜索和手工添加服务器两种方式；

（3）预览素材超过预览设备屏幕像素尺寸时，支持上下左右滑动，可固定比例缩放、1:1实际尺寸及全屏展示；

（4）预览方案时能快捷截图记录，可查看历史记录；

（5）可直接运用微信、Email、QQ等工具分享；

（6）支持手动刷新，已克服网络不稳定情况；

技术实现原理：

（1）本发明利用SOCKET/TCP协议，无线或有线接入Adobe Photoshop中的远程连接（Remote Connections），并对Adobe公司的Photoshop进行实时远程操作和实时获取的Photoshop文件的信息。

（2）通过零配置网络技术（Zero configuration networking）进行自动搜索，或通过手动加入域内远程连接的IP接口，并对其操作进行保存记录。

（3）从Adobe Photoshop中获取的图像信息，信息的尺寸大小将对移动设备的屏幕进行自适应，无论时正常屏幕或高清屏幕。

（4）本发明根据设备的方向检测，作出横向屏幕/纵向屏幕的自适应。

（5）设备可对当前状态进行抓屏操作，并把抓屏信息作出分享和保存。

（6）抓屏信息利用第三方通讯软件（如微信）的应用程序编程接口（API）做出即时分享，或使用电子邮件（Email）技术进行传递。

（7）抓屏信息可通过应用程序编程接口（API）传递到其他软件进行操作。

产品体验地址：http://x.rdm.3g.qq.com/a/4049 （稍后推出iPad、Android版）

手机扫描即可下载体验

产品CE平台：http://ce.oa.com/psplay

源地址：http://djt.qq.com/portal.php?mod=view&aid=456

设计师的知识管理

yosign — 2013-03-04 09:48:32

人们每谈到设计很自然的就会联想到创意、想法。作为设计师，好像我们的大脑里就理所应当地充满了各种创意，然而这些创意是本来就存在于大脑里的吗？显然不是。有人说创意来自冥想，我不否认有些天赋超人的设计神人可以通过冥想产生内容，但是对于非神设计师来说，冥想只是一个将脑海中的旧有内容进行重新组合并且呈现出来的一个方法。所以创意的内容其实不是来自冥想，而是来自设计师平时的积累，积累的越多，设计知识越丰富，创意和想法也就越多。经常听到这样的话：作为一个设计师想要提高水平，就要多看多思考多实践。于是很多人把业余时间都投入到无尽的图库之中，试图以此提高自己，但是在被各种优秀的设计作品吸引的同时，往往忽略了更为重要的知识管理。

你是不是经常遇到这样的情况？
做东西时候想起某个效果很好，却不记得具体的样子，想看看但怎么也找不到在哪；每天都看很多的作品，却零散毫无秩序，最后感觉什么也没有积累下来；经常会冒出一些小的想法，可是没多久就忘记了，再也回忆不起来。
如果有以上情况之一，那么学习和完善自己的个人知识管理对于你来说是值得尝试的。

什么是设计知识？

广义上讲设计知识包括：资源，常识，方法，思维
资源和常识是确定的知识，一般是一些设计结论（完成的作品）和结论式的方法，这些知识相对固定，不具备拓展性。例如：某海报，黄金分割定理等。而方法和思维是活的知识，可以根据自己的需求灵活的适配、修改，甚至可以在产生另一种新的设计思维。比如：栅格设计，极简主义，以用户为中心的设计等。

那么这么多的知识如何管理呢？

我给设计知识的管理分了四步：

1.浏览

浏览是无时不刻的，眼睛一睁一闭一天就过去了，如果你眼中的画面不卡，那每秒最少有 20帧，每天 16 小时就至少有 1152000个画面 …这么多画面肯定会存在那么一些让人赏心悦目的，比如漂亮的衣着搭配、微妙的车窗与背景的结合、晚霞、美女 ……等等，这些都是可以用相机或者手绘记录下来的。
知识爆炸的时代，信息在互联网上，它们不再难以获得，却变得难以选择，取得有效的信息成了如今获取知识的重要环节，我的信息来自这几个地方：

2.收集

信息看到了然后如何处理呢？我们要学会收集和整理信息，这个环节决定了你以后寻找已知信息的效率，我是这样做的：

在平时浏览中，我会用花瓣（或Pinterest）收藏下喜欢的图片，然后用Evernote记录文章，如果你用Chrome的话，那太方便了，插件让你的收藏只需要一次点击，然后可以简单的分类一下。

3.消化

想要的信息都被摆好了，也看过了，这些信息就属于你了吗？显然没有，到此前你已经为每条信息进行了快照，没有为信息标注，到了要使用信息时你是无法在脑海中检索的。
这时就需要我们对已有的信息进行消化，比如打开花瓣，看看收集的图片，从构图，排版，色彩，光影几个纬度分析一下图片，然后根据设计的目的用作者的角度想想为什么这样做，他用了什么方法？以图片为例：
经过自己的消化总结，之前收集的信息就更清晰了，很多内容可以被提炼为设计方法，在日后需要时就可以随时使用了。

4. 回顾、思考、创新

这是最重要也是最难的一步，通过第3步，你已经积累了一部分设计的方法，做设计时候去应用这些方法，通过各种组合来完成作品，在这个过程中，要留意每种方法的应用环境、适用主题、表达的情感等，同时多交流多分享，口头沟通心得，产出PPT，这都能很好的回顾记忆积累下来的设计方法。当方法积累到一定的程度，你的各种设计思维就会慢慢形成、逐渐完善，生成独到的理解和认识，做出属于自己的创意设计。设计思维的形成很像树的成长，在各种营养的滋润下，方法与思维相互依存，共同成长。

关于抄袭和创新：

如图的四层管理，如果你做好第一层那你可以很好的拿别人的作品做设计了，如果做好第二层那你可以拿别人的方法做设计了！如果做到第三层那你可以拿别人的思维做设计了！如果你还能做第四层那你可以通过冥想做设计了。
不知你发现了没有，这四层分别叫：抄袭，借鉴，微创新，创新。
知识管理能帮助你建立属于自己的设计思维，并且形成一套有效的设计问题处理方法。可以将设计资源积累下来，从而方便的进行搜索、调用、分析，提高解决问题的能力和效率。尤其是在系统而深入的了解知识管理之后，你会不知不觉发现自己具备了解决问题的新思路，各种创意在脑海中不断的迸发，这时候各种各样的设计需求就是一件很美妙的事情了，因为这些需求为你溢出的创意提供了丰富的载体。

最后，设计师是一个生产创意、传达信息的职业，他需要的不只是构图，色彩，手绘，软件使用，更需要其他的知识去丰富自己的视野，在理解各行各业各种知识的同时从中领悟出自己的设计思维，在明确传达信息的同时，做出更好的更有意义的富有情感的作品。

转载请注明出自”百度MUX”

源地址：http://mux.baidu.com/?p=4013

移动产品设计书籍推荐

kent.zhu — 2013-02-28 20:47:12

这是我曾经在知乎上对一个问题的回答，最近也有好几个朋友在公号里向我提问，对于做移动产品设计，有没有一些比较值得一读的书来推荐。我把这个问题重新梳理了一下，更新到这里。

移动产品设计，狭义上的理解就是设计手机及Pad上的应用和Wap站，包括ios、android、WP等几个主流的平台。这个答案也是围绕着这个狭义的定义来的。

1、各个平台的设计指南，也就是我们常说的Guidelines

这是当前而言，所有的移动相关的书籍中，最最最最最基础的，也是最最最最最为重要的。所有的从事设计相关工作的人，都必须至少读3遍以上，甚至更多。

在Guidelines中，以ios的编写最为规范与完整。这套指南会很详细的告诉你，ios系统是一套什么样的系统，为什么要做ios的设计，什么样的ios设计是适合与这套系统，然后告诉你有哪些基本的模式，再然后是具体的设计。迄今为止，还未发现讲ios设计的资料有超越这套资料的。

基本上来说，熟读了Guidelines不看其他什么书问题也不大。强烈建议新入行做移动产品设计的同学，在没有读过Guidelines之前，不要读任何的其他书籍。

2、《简约至上 – 交互设计四策略》

副标题看，这是一本讲交互设计的书。但，实际上，这是一本产品设计的入门书籍。讲述如何站在主流用户一边，以及如何从他们的真实需求和期望出发，简化设计，提升易用性。

这本书推荐给所有做产品的人看，同时，建议不要再读《don’t make me think》，这本书其实只需要读标题就成了。里面的例子和内容都不太实用。

3、《Tapworthy（触动人心）》

这是一本讲述如何从iphone的角度来思考并设计一款ios应用的书籍。书中有不少的实例。

4、《移动应用的设计与开发》

这是一本相对比较老的书，其中有些例子与数据可能不太适用了。不过，书中很详细的对整个移动生态系统做了描述，这是很值得一读的章节。因为，只有我们理解了所处的生态系统，才能很好的在这个系统中去设计应用。

5、《移动应用UI设计模式》

很早的时候关注了这个姐姐的博客及要出的书，今天去看了一下，发现已经有翻译版本了，准备入手一本来看看。这本书分10大类介绍了70个移动应用设计模式(包括反模式)，用了400多个屏幕截图和图解。基本上，是一个工具书了。

注：

以上书籍收录于我的豆列“移动产品设计书籍”。

另外，补充一些素材网站：

1、pttrns.com

这个网站会不定期的分享一些APP的截图，同时，网站还按照不同的分类将这些APP截图做了整理。

2、mobile-patterns.com

跟pttrns类似，不过更新好像没那么勤快。也是根据不同分类整理APP截图的

3、appsites.com

这是一个收集展示APP网页的网站。简单说就是很多APP的介绍和下载页面的收集整理

4、花瓣网的APP频道

唯一的缺点是网站和APP混在一起的，且内容没经过筛选，质量并不是很高，不过，其中有几个用户的专辑是很赞的！

——

如果，你也有跟移动产品设计相关的书籍、站点、资料推荐，欢迎邮件我哦～

—— 微信添加 iamkentzhu 为好友，有更多精彩等着你

源地址：http://www.ikent.me/blog/4411

知心怪蜀黍NO.28 产品新人的玻璃心

纯银 — 2013-01-29 19:31:07

我是某互联网公司无线部门的产品助理，工作到现在半年，有些困惑。

面试时谈的是会先做一些基础的工作，但慢慢会给机会参与产品，于是答应了，入职才知道原来是接替别人的职位，而这个职位之前的工作的就是商务接口人，负责协调每月三次的Android APP发版。当时心中有不好的预感，可是想着入职前说的话，决定踏实地干下去。

干着干着，发现自己面对陌生人还是很胆怯，性子又太直，因此在发版时的沟通中出现了很多问题，如何磨练自己，做到有效沟通，成了努力的方向。快一个月时候，终于开始给自己安排一些竞品分析之类的任务了，心中欣喜，却发现自己的思维并不够慎密，交上去的东西能够被挑出N多的毛病……只能不断地改，稍稍上了点道，不到两周，发现安排给我的事情很少很少，而且都是很小的事情，工作很空闲，有大片的空白时间，感觉自己要被葬送了，自己心里渐渐有些躁动。

虽然时间很富余，但每天各种繁琐的沟通，仍旧把自己弄的精疲力竭，甚至空闲时间的自我学习效率低得一塌糊涂。时间真的好快，眨眼工作就快4个月了，终于参加了次真正的项目，但其实干的是测试的活，根本没有什么机会。每天回程的地铁上都不知道自己干了什么，明明一整天都在努力的工作，从来没有像人家那样偷懒，可是，回忆起的只有空白，因为根本就没有干什么有意义的事情，成长好少……

想知道，您当初那一年半的冷板凳是怎样的？您是如何努力改变现状的？在没有实践机会的情况下，通过什么验证想法，锻炼产品能力的？谢谢。

这个产品新人啊，都希望能落到牛奶与蜂蜜的碗里去，有个好师傅传帮带，又被委以重任，手把手地教你怎样观察方向，策划产品，把握节奏，在半年里蹭蹭蹭地成长起来，左脚尖点右脚背右脚尖点左脚背分分钟就上了房顶。

其实，我也很想追求高树玛丽亚。或者汤唯也行，或者范冰冰也行。

产品助理是个什么样的岗位呢？是个打杂的岗位。意思是，产品经理不愿意干的，枯燥的繁琐的没创造力的活儿，都丢给助理。这些活儿新人不做，难道让有两三年经验的策划去做，然后抱着新人的腰把他抬上位？

认清现实，同学，你没经验没资历，自己都说一开始竞品分析毛病多多，能做什么呢？打杂，当然是打杂。如果不安于现状，打杂的机会都没有。上司也不是你亲姐夫对吧，为什么要特意栽培你呢？

用一个老练的产品经理，配一两个给他打杂的助理，是很合理的项目配置，好让PM集中注意力在非他不可的重要环节上。说难听一点，助理就是军官身边的勤务兵。

如果带着这样的怨气去工作，你恐怕就真的是个天生勤务兵了。

来信里，你无限沮丧地提到自己干过测试的活儿——测试，天啦，你知道这是多好的机会吗？意味着你可以了解前端后台的每一个功能点，逐个把玩。我手上有份蝉游记App的测试用例，大约500条，运营妹子空下来想跟我学设计，我跟她说，先从测试开始，一条条用例去读懂，去验证。动手跑上两轮之后，对设计思路与细节就有全面了解，不理解的地方再来找我咨询。

你居然认为这是无意义的事情。

还有竞品分析——见鬼，还得上司交待下来你才去做竞品分析。在那之前，有人用枪指着头不准你了解竞品吗？主动做竞品分析会脱掉裤子弹你鸡鸡吗？

可以想象的是，如果态度这么被动，多半上司安排你做多少竞品分析，就依样画葫芦咯，所以觉得“安排给我的事情很少很少”。再加上“被挑出N多的毛病”，我要是你上司，干脆换个工作更主动，更有产品天分的助理算了，懒得耐心带你成长。毕竟我也不是你亲姐夫对吧。我希望干活儿的人能让自己省心，而不是费心，我招的是帮自己减压的助理而不是徒弟。

你在马赛克里还提到了市场的事情。Android市场铺货有多枯燥，我当然知道，我还可以告诉你这个任务中能有哪些额外的收益：

1、分析不同市场的特点，了解渠道特性

2、跟踪竞品的排名与下载量，了解市场起伏

3、浏览竞品的用户评价，了解用户心理

4、寻找更好的应用命名、简介与配图，参考着来优化自家的产品包装

5、和一些谈得来的市场人员搞搞私交，未来的帮助很多

如果你把铺货当成铺货来做，自是索然无味。就像你把勤务兵当作勤务兵来做，当然沮丧得不能行。你没意识到的是，这些都是近距离接触产品运作的绝佳机会，有人求都求不来，有人看都看不上。做产品主要靠自学，自己给自己找活儿干。有态度，有天分，每天摸着摸着就上手了。嫌弃没有实践机会？满地都是实践机会，只是你看不见而已。

同样是产品新人，有的被当宝，有的被当草。我上面说的这几条，你要是能做到，到哪里都是个宝。做不到，抱怨发呆抑郁，那就接受作为草的人生设定吧。野火烧不尽，春风吹又生。

——————————

很久没写知心怪蜀黍专栏了，不是我不想写，是没什么有回复价值的来信。

这几个月来信多为千篇一律的新手请教，择业求助，去看看之前的怪蜀黍回复吧，你们和别的新手没什么不同。

还有一些来信，全文都是马赛克，要求不予公开，私下回复。拜托，我这是专栏，不是私家电话热线。

其实来信也未必是提问，坐而论道也行。关于产品，职场，互联网行业。

对知心怪蜀黍提问，请看：

http://firecacada.blog.163.com/blog/static/70743762011112010292641/

源地址：http://firecacada.blog.163.com/blog/static/707437620130287434840

绽放升华 ——【百度广告管家排期2.0】设计总结

百度联盟UEO--刘曼 — 2012-12-17 13:46:43

本文来自：百度UEO http://ueo.baidu.com/?p=1612

百度广告管家是一款面向中高端媒体的稳定、高速、易用、免费的广告管理系统。排期1.0自2011年上线以来，为网站主随时记录和更新广告位的售出情况，避免了资源冲突。但也面临着一些问题，寻找影响用户使用线上系统进行排期管理的主要因素，挖掘排期的核心需求，找出使用的痛点，提供贴心的功能亮点，由此排期2.0应运而生。

源地址：http://ueo.baidu.com/?p=1612

【CDC翻客】翻客来袭！Fanke is coming！

CDCer — 2012-12-01 14:47:24

　　翻客，是腾讯CDC 一个专业而学术的翻译团队。紧扣此主题，LOGO设计简洁有力又不失学术气息。主体是眼镜图案，两个镜片由CDC LOGO中的“D”翻折构成，也隐喻“翻”的字面意思。

　　翻客，CDC blog的翻译团队，旨在提供精选的原创译文。

3年前，一次偶然的驻足，我结识了CDC blog，从此，它便成为我步入用户体验行业的指明灯；

　 3年后，一次幸运的面试，我加入了CDC blog，于是，它开始记录我在专业道路上的成长印记。

　作为互联网的新一批从业人员，不断学习、放眼世界是基本素质和要求。

　翻客的诞生，是CDC blog放眼世界的开始，我们会为提供优质译文而尽绵薄之力。

　翻客提供的译文：

内容：以原创翻译为主，原文主要来自同行们熟悉或不熟悉的国外原创内容站。我们尽量挑选在用户体验行业中有学习和收藏价值的专业博文来做译文，同时也希望我们提供的内容，可以为有缘踏足本站的朋友们提供点滴阅读价值。

　质量：翻译队伍是一批充满激情、乐于分享的业余爱好者，翻译质量可能还远不及专业人士。我们非常欢迎大家提出宝贵的意见和建议，也真诚希望大家之间多多交流。

　数量：每周，我们都会翻译一篇营养价值高的文章以飨读者。

　翻客的成长有赖于以下这群激情而专业的成员们！

梦想多大，舞台就有多大！

　我们诚邀CDC更多喜爱翻译、乐于分享的朋友加入翻客。

　请将您的经验和智慧传递给更多成长路上的朋友们。您的分享为这个快速发展的时代埋下一颗思想的种子，这种子终会生根、发芽、释放光芒。

(本文出自腾讯CDC博客: http://cdc.tencent.com/?p=6518)

源地址：http://cdc.tencent.com/?p=6518

Tower，起航

牛言 — 2012-12-01 14:26:38

2006年，在新西兰定居了16年的侯德健拿着台湾护照在香港申请回大陆定居，他搞不清楚自己究竟应该属于那里，台湾，新西兰，还是中国大陆；同样，在3年多的时间里客户遍及商业地产，出版，运动健身，运营商之后，我们同样也搞不清楚，我们究竟是做什么的。

一直以来，我们以软件设计团队自居，可做着做着我们就变成客户的项目经理或是产品团队。我们前期分析客户产品的需求、受众和市场；中期我们分析软件的信息结构、交互设计，有时候还会从头到尾的开发；到了后期我们还要参与运营，提出改进的相关建议，并根据实际效果进行设计或功能调整。我们深入的进入客户的行业，在某些行业竟变成业内翘楚，掌握的信息有时比客户还熟悉，所以在项目的后期客户总是对收购我们的团队感兴趣而很少想收购我们的产品。

投资圈的朋友在和我们沟通的时候，总是对我们提出委婉的批评，希望我们能尽快的明确方向，找准公司的定位，可有的时候我们还以“就业型的创业公司”洋洋自得。当时间如宝驹过隙流淌而过的时候，我们团队的平均年龄在一年一年的增长的时候，我们满足于我们能活下来，甚至还能活得不错，可然后呢？

佛家讲究醍醐灌顶，讲究顿悟。现在我们想，是时候了。

去年，我们就开始尝试，推出Teamcola，一款基于互联网的团队工作日志软件。目的很简单，就是让团队内的团员简单直接的知道自己在项目上花了多长时间，队友花了多长时间，公司在项目上总的花费了多长时间。因为按照我们的理解，时间就是小团队最最重要的资源。用这款工具，团队再不用每周花上半天的时间来开会，阐述自己上周都干了什么事儿，团员也对自己的工作一清二楚，不用开会的时候抓破自己的脑袋回想上周究竟做了些什么事情。截止到今天，已经有8,509个团队在上面记录了1,745,899个小时的工作日志。

今年9月，我们推出DesignBoard，一款简单好用的设计方案讨论工具，当然，也是基于互联网的。我们希望通过它，解决设计团队内设计稿呈现缺乏整体性，对设计图的沟通低效且无效，多版本管理混乱的问题。虽然只是解决一个小的问题，但是我们用心的设计使得DesignBoard倍受好评，也成为很多互联网产品公司设计流中的绝佳工具。

TeamCola & Design Board

在今天，我们隆重推出一款简单好用的团队协作工具，我们给他取名Tower。

从08年开始，我们便通过使用互联网产品来提高团队的协作效率，我们先后尝试过国内国外的多款协作工具，但是大部分的工具不仅没有让我们的工作轻松，反而加重了团队的负担，原因有很多，国内的产品大多不堪入目、无法使用，国外的产品一部分华而不实，而有幸遇到一款非常棒的，又因为祖国和世界的距离而时常无法使用，所以我们一直有野心设计一款真正好用的以项目管理为中心的团队协作工具给大家使用。于是，今年8月，我们开始打造Tower，我们希望他像机场的塔台一样，成为24小时运转的在线工作室，团队可以快速的处理任务，开展讨论，检查项目进展，随时和团员紧密协作，减少内耗，大幅提高工作效率，通过任务、讨论、文件汇总团队的信息，我们用我们认为最合适的方式对这些信息进行呈现，唯一的目的，就是以最简单的方式，让团队高效的沟通起来。

现在，我们认为他已经足够好用了，虽然只完成了我们预想的一半，我们也希望让大家能够尽早体验Tower带来的沟通的快乐，并且和我们一起完善他。

从今开始，我们将重新起航。可能你已经注意到，我提到“简单好用”很多次，对的，这就是我们的信仰。做“简单好用”的基于互联网的团队项目管理，时间管理，客户管理工具，这就是我们公司的前进方向，我们将在这个方向上投入我们所有的资源，无论遇到什么困难，我们不会放弃。曾子曰：“士不可以不弘毅，任重而道远”，我们不怕“道远”，在行进的过程中欣赏沿途的风景正是我们团队的人生哲学；冯小刚导演希望躺着就把钱挣了，我们没那么高的奢望，站着挣钱一样很快乐。

侯德健在酒店住了四十多天后拿到了签证，回大陆定居，并写下“你问我想不想重新再来一遍我只有望着蓝天在白云间寻找你的脸”。希望我们能和你的团队一起成长，最终也能仰望蓝天，在白云间寻找彼此的脸。

源地址：http://blog.mycolorway.com/2012/11/26/tower_startup/

工具型网站的体验设计——从广告平台出发

CDCer — 2012-12-01 14:26:06

题记：从2010年进入公司至今2年半的时间，我一直负责广告平台部门的产品设计。从陌生到熟悉，不知不觉间我竟已对这些产品倾注进了感情……

工具型网站的特点剖析

工具型网站万变而不离其宗地围绕两个关键词在展开属于它们各自的情节，那便是：功能与数据。所以谈至“体验”，其实设计目标也就更加清晰和明确——

１.在保证功能流程顺利走完的基础上，让用户的感觉更加舒适；

２.在面对大量数据时，让用户轻松找到自己所需要的而不被满屏幕的字符折腾地焦躁不安。

工具型产品普遍业务逻辑复杂且迥异，数据量大，往往还涉及不同角色的场景分类……套用一句老话：水很深。设计目标则成为了一盏心中的明灯，时刻提点自己要留神脚下的四伏的暗礁。

功能设计之我见

一级准备

在处理功能设计之时，我奉行一句话：先弄明白了再下手。因为个体功能的修改牵涉到整个流程的走向，往往会在原有的基础上增加操作分流；而平台中的功能增加更会和其他的功能模块发生交互行为或产生影响。在设计师自己还不能对该功能的设计了如指掌的时候就匆忙动手，其结果就是设计进行到一半，问题暴露然后返工，更悲剧的是全套设计稿看似高效地做完，之后却面对全盘洗稿的惨剧。

“脑图”在这个阶段的作用就变得至关重要。用什么工具出脑图？专业软件Mindmanager、Xmind、FreeMind也好，最原始的笔和纸也罢，只要能全面清晰地表现“关系”和“影响”就已经完成了使命。

上个月正值“广告经理”在原有的支持PC端用户建立广告位并制作广告，查看效果的基础上，增加支持移动平台业务的功能。牵一发动全身，移动平台业务的功能加入使得整个“广告经理”众多模块都受到影响。下图便是在与产品经理召开需求会议的同时诞生的关联模块草图。这张草图既能在设计开展前期就相对准确的估计新版本的设计方向与工作量，又能在设计过程中保证设计侧重点与功能设计的完整性，作用不可小觑。

“脑图”不仅仅有宏观把控的全局意义，而且也同样可以具备指导设计工作细节的现实价值。

同样以此次“广告经理-移动平台版”为例，加入了移动业务，必然导致各原有主功能的走向出现分流，而基于广告的业务逻辑，不同平台上的广告大到展现形式，小到允许输入的字符数等等都会出现不同的变化。静下心来通过“脑图”梳理分流时的各种情况，然后淡定的打开设计工具开始工作，这肯定是比自以为很清楚，做到哪算哪来的科学和高效的，不是么？

功能的平台表现形式

功能模块具体落实到网站中，其表现形式大体包括：表单及其对应控件、按钮、信息反馈及提示，相互之间的关系便如下图所示。

如此一来体验设计也便有了出发点和依托。举几个在广平系统中用到的设计案例吧。

在智胜广告平台（AdWIN）的设计中，用户登录后便直接进入“个人首页”，在这里我们需要放置本平台最基础同时也是用户所有活动的出发点：创建广告。因此我们有理由在这个页面强调该入口，使它即能对新用户起到传达本平台的最大功能同时引导操作的作用，又能让老用户在登录之后直奔工作主题。

广告系统的设计特殊性还表现在页面的操作流程很大程度要参考广告业内既有的规范，这样便于用户理解流程的同时也能更高效的帮助用户完成目标工作。因此在设计过程中也会诞生很多“为广告而生”的表单与控件。根据实际业务的不同，对待某些重要的业务流程，设计师在理解业务的基础上，完全有必要跳出以往常规控件的束缚，为产品专门定制设计方案。比如为排期与资源专门设计的特别定制、视频广告的关联设置等。

业务性较强的功能，用户所需要填写的表单项势必远远超过单屏，应此将用户表单输入做到恰到好处地贴心，也是工具型网站的一个细节设计点。

在聚赢广告平台（MobWIN）的设计中，遇到过广告推广语的输入字数限制十分苛刻的业务要求：“推广语1”字数不得超过10个汉字，同时不得少于9个汉字；“推广语2”字数不得超过12个汉字，同时不得少于11个汉字。这是由WAP1.0和WAP2.0或触摸屏广告位可显示的字数决定的。如果直接用文本告知用户：“您只能输入9或10个汉字”，首先文本信息很可能会被用户忽视，其次如果不做任何即时判断，在用户完成漫长的表单填写后，点击提交却因此受挫，那必然是十分苦恼的。因此针对这个文本输入框给出了如下设计方案：

功能的增值设计

功能模块在完成它自身价值的同时能不能产生额外的价值？这貌似应该是产品经理在策划这个功能之初就要想到的问题。而设计方能为功能增值做些什么呢？我们完全可以通过对页面结构的设计和流程的微调让它更好的达到增值的效果。

再用广告经理这次的移动平台新功能的设计做案例。新建广告位的流程是用户建立广告的必经之路，我调整了本该放在基本表单中的“平台选择”RadioButton，把该属性提取出来，作为信息传达重点，加入了设计元素。想必这种形式更能使“广告经理已经支持到移动平台”的信息深入人心，其价值也超过了功能本身。

数据的处理

在实用型工具类网站中，用户均被打上了“业内人士”的标签。他们大多出于工作或商业等目的希望获得对自己有用的专业数据。在广告平台的这些项目中，我们使用了如下几种信息处理方法：

分角色显示数据

从最外层就先为不同角色的人匹配了他们各自需要的数据，进行了第一步数据去噪。当然能够使用这种处理方法必须是建立在角色与诉求够清晰分明的前提下。

数据搜索与过滤

无法按角色或已经按角色去噪之后还留有海量数据之时，数据的搜索与过滤就提到了体验设计的第一位。搜索项是否符合用户实际操作逻辑？搜索中用到的控件是否合理与便利？搜索条件何时取交集，何时又呈现并集，又该如何清晰传达给用户？哪些项可以放入高级搜索？……随着设计的深入这些问题便会应运而生，而它们确实值得设计师深思熟虑。

业务上需要的搜索项过多，而选项全部罗列会导致搜索模块过于庞大时，可以类似Google Adwords采用点击激活浮层来进行单项设置，用户在操作时也相对专注。收起检索条件模块，不让复杂的搜索条件干扰用户对结果列表的阅读。甚至可以基于业务特点为用户提供保存查询条件的个性化服务。

数据本身的展现形式

这里我们不谈视觉效果令人为之惊叹的信息可视化处理。传统数据的展现形式不外乎：列表、饼图、柱状图、趋势图等以及它们之间的组合。设计师在运用时，不但要了解页面中不同数据所对应的展现形式，还要将它们有机的结合排布以达到良好的阅读体验，必要时可以对传统的展现形式做一些设计上的处理。

用户自定义

上面就说道过，工具型网站的用户普遍定义为专业用户，他们对数据获取要求也是严格的。在对重要数据的展现中会出现更高级的操控功能，以满足用户对数据的自由获取。

写在最后： “还可以更灵活，还可以更好用”，再回头看这2年来的设计稿，我常常会有这样的想法。工具型网站的体验设计的确还有很多值得深入挖掘研究的地方，业务逻辑和需求的不同更会延伸出多样化的设计解决方案。

(本文出自腾讯CDC博客: http://cdc.tencent.com/?p=6528)

相关话题：UED团队设计分享源地址：http://cdc.tencent.com/?p=6528

【CDC翻客】移动端App测试实用指南

CDCer — 2012-12-01 14:22:00

译者注：本文从测试人员的角度出发，提出了100多个在测试移动App过程中需要考虑的问题。不管你是测试人员、开发、产品经理或是交互设计师，在进行移动App开发时，这些问题都很有参考价值。我和Queen合力译出此文，分享给大家，希望有所帮助和启发。

英文原文: http://mobile.smashingmagazine.com/2012/10/22/a-guide-to-mobile-app-testing/

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

　　测试人员常被看作bug寻找者，但你曾想过他们实际是如何开展测试的吗？你是否好奇他们究竟都做些什么，以及他们如何在一个典型的技术项目中体现价值？

　　作者将带你经历测试人员的思维过程，探讨他们测试移动app时的各种考虑。本文的目的在于揭示测试人员的这一思维过程，并展示他们通常所考虑内容的广度和深度。

测试人员需要询问问题

　　测试人员的核心能力在于提出有挑战性的相关问题。如果你能将调查、询问技巧和技术、产品的知识结合起来，渐渐地，你也会成为一个好的测试人员。

比如，测试人员可能会问：

·　这个App应该在什么平台上使用？

·　这个App到底是干什么的？

·　如果我这样做，会发生什么情况？

　　诸如此类。

测试人员能从各种场景中发现问题，它们可能来自对话、设计、文档、用户反馈或者是产品本身。这些可能性太多了……因此，让我们一探究竟吧！

从哪里开始测试

理想情况下，测试人员应该掌握所测产品的所有最新细节资料。但事实上这很少见，因此，像其他人一样，测试人员只能将就使用手上有限的资料。但这不是不能测试的借口！测试人员其实是可以从内部和外部多种不同的来源处收集信息的。

这个阶段，测试人员可以问这些问题：

· 　有哪些信息：规格？项目会议？用户文档？知识渊博的团队成员？有支持论坛或者是公司在线论坛提供帮助？有现存Bug的记录吗？

·　该应用是在什么系统、平台和设备上进行运作和测试？

·　该应用是处理什么类型的数据（比如个人信息、信用卡等等）？

·　该应用有整合外部应用（比如API和数据来源）吗？

·　该应用需要用到特定的移动端网页吗？

·　现有消费者如何评价这个产品？

·　有多少时间可用于测试？

·　测试的优先级和风险是什么？

·　哪些用户使用起来不愉快，为什么？

·　如何发布和更新？

基于以上收集的信息，测试人员可以制定测试计划了。通常预算决定测试方法，一天测完，一个星期或一个月测完的方法肯定不同。当你逐渐熟悉团队、工作流程以及这类问题的解决方式时，你就更容易预测结果了。

案例：Facebook App的社会评论

当作为一名测试人员收集信息时，我喜欢选用Facebook App作为案例，因为用户的抱怨到处都是。以下仅仅展示了部分遇到难题的用户在iTunes App Store中发表的评论，网络上还有很多。

iPhone上的Facebook App有很多负面的评论

　　如果我接受挑战去测试Facebook这个App，我肯定会考虑这些反馈，否则就是傻子。

测试人员的创造力

你可能知道这个App原本想做的事，但是它究竟可以做什么事呢？用户实际上是如何使用它的？测试人员擅长作为旁观者来思考，尝试不同的事物，以及不断地询问“如果。。。会怎么样”和“为什么”的问题。

比如，移动端的测试人员常常以不同的用户角色进行测试——当然有点夸张，但是，这种把自己当成不同用户进行思考、分析和设想的能力对测试是备受启发的。

测试人员可能会设想自己是以下用户：

·　毫无经验；

·　很有经验；

·　爱好者；

·　黑客；

·　竞争对手。

当然还有更多可选的角色，这主要取决于你们所开发的产品是什么。其实除了角色特点外，其操作行为和工作流程也很重要。人们使用产品方式常常很奇怪，比如：

·　在不应该返回的时候返回了；

·　不耐心而且多次敲按键；

·　输入错误的数据；

·　不理解该怎么做；

·　可能没有按要求进行设置；

·　可能会自以为是地认为自己知道该怎做什么（比如通常不阅读说明）。

测试人员遇到这些问题时，也常常发现意料之外的Bug。有时候，这些Bug微不足道，但是更深入的调查就会发现更严重的问题。

很多问题是可以被预先确定和测试的。测试移动端App时，以下的问题并不都有关，但是也可以尝试问问：

·　是否按照所说的来做呢？

·　是按设计完成任务的吗？

·　不是按设计完成任务的吗？

·　如果处于一直被使用或者负荷情况下，状况会怎么样？会反应迟钝吗？会崩溃吗？会更新吗？有反馈吗？

·　崩溃报告会反馈到App吗？

·　用户可能有哪些创造性的、逻辑性的或是消极的导航方式？用户相信你的品牌吗？

·　用户的数据安全如何？

·　有可能被中断或是被破解吗？

·　运行到极限时会发生什么状况？

·　会要求打开相关服务吗(如GPS、Wi-Fi)？如果用户打开会怎样？没打开又会怎样？

·　将用户重新引向哪儿？去网页？还是从网页到App？这会导致问题出现吗？

·　沟通过程和市场反馈是否符合该App的功能、设计和内容？

·　登录流程是怎样的？能在App上直接登录还是要去网页端？

·　登录是否整合了其他服务，比如用Facebook和Twitter帐号登录？

案例：Run Keeper’s gy Update

RunKeeper，是一款能跟踪你健身活动的App，最新发布的版本里有个“目标设置”的功能，对此我很感兴趣去体验一下，一部分从测试人员的角度来看，更多的是作为一个真心喜欢产品的用户来体验。但我发现了一些问题：

1. 默认单位是英镑，我却想要把公斤作为重量单位；

2. 英镑和公斤间的切换根本不好用；

3. 当设定目标后，会导致展示错误的数据和图表，这让我很迷惑；

4. 由于第3条，我想删除目标，但却根本找不到删除的地方；

5. 为了解决这一问题，我不得不改变的个人体重的值，直到 “目标设置“范围之内，这样目标达到了，就能重新设定目标了；

6. 我会再次尝试添加目标；

正因为以上疑惑，我花了更长的时间把玩它，看能不能找到其他的问题；

以下是一些发现问题的屏幕截图：

该App的最新版本包含了一个新的“目标”部分。设置日期的时候，我发现开始和结束的日期都可以从公元1年开始，另外，为什么有两个1年可选（译者注：年份那列从上往下应该显示为“1、2、3”）？

另一个Bug，是“当前体重”部分的一个拼写错误，当清空数据时会出现拼写错误的“Enter“（应用中用的是Etner），这只是一个小Bug，但是看上去非常不专业。

发现问题没有捷径，你只能反复的慢慢的试用。每个App及其团队都会面临很多不同的挑战。但是，测试人员的典型的特点就是：超越极限，做一些非常规的、可以改变周围事物的事情，保持长时间的测试（测试几天、几个星期甚至几月，而不是几分钟就测完），即使明明知道这些事情是不可能发生的。这些也正是可以找到和引出的场景所在。

哪儿有所有的数据？

测试人员喜欢从数据上找问题，这让开发人员有时候很郁闷。事实上，用户或者是软件开发人员在信息流中确实太容易迷惑了，因为可能会出现很多错误，所以基于数据和云的服务更为重要

也许你可以尝试在以下场景中检查出问题：

·　移动设备数据已满；

·　测试人员移除了所有的数据；

·　测试人员删除了App，那数据怎么办？

·　测试人员删除并重装了App，数据怎么办？

·　过多或者过少的内容导致设计和布局的改变；

·　在不同的时间段和时区使用；

·　数据不同步；

·　同步被中断；

·　数据更新影响其他的服务（比如网页和云端服务）；

·　快速处理数据或是处理大量的数据；

·　使用无效的数据；

案例：Soup.me的错误

我试用过的Soup.me，是一个可以通过地图和颜色将个人Instagram 中的照片进行分类的网页服务，但是我却没用多久。当注册时，它提示我Instagram上的照片不够多，然而我的账号中明明有500多张照片。我并不清楚问题出在哪儿，也许是数据问题，也许是表现层的问题，也有可能是该App出错提示的问题。

另一个案例：Quicklytics

Quickytics是一个iPad上的网页分析应用。在使用过程中，尽管我已经从Google Analytics中删除了网站配置，但它仍然存在。这里有一些问题：

·　我已经删除了网站配置，为什么还是有这些信息？

·　左边模块没有解释为什么“该操作无法完成”，那么是不是可以改进以避免迷惑用户呢？

测试人员也很喜欢测试极限数据下的情况。他们常常是作为典型用户来了解这个App，所以极限下的测试并不会花很长的时间。数据是混乱的，所以测试人员要考虑到软件的用户类型，以及在不同的数据场景下如何进行测试。

比如，他们可能尝试以下场景：

·　测试用户可输入的极限值；

·　用重复的数据进行测试；

·　在全新无数据的手机里测试；

·　在老手机上测试；

·　预先安装不同类型的数据；

·　考虑聚集大家的资源来进行测试；

·　让一些测试自动化；

·　用一些超出预期的数据去测试，看它是怎么处理的；

·　分析信息和数据是怎么影响用户体验的；

·　不管用户看到的是否正确，都要一直问问题。

创建出错提醒和消息

这里，我不是从设计师的角度来要谈论好的错误消息的设计，而是想从用户或是测试者的角度来看这个问题。出错提醒和消息是测试人员很容易发现问题的地方。

关于错误信息要问的问题:

请考虑以下问题：

·　出错提醒的UI设计可以接受吗？

·　错误信息内容可以理解吗？

·　错误信息是否保持一致？

·　这些错误信息有帮助吗？

·　错误信息内容是否合适？

·　这些错误是否符合惯例和标准？

·　这些错误信息本身是否安全？

·　运行记录和崩溃是否能被用户和开发者获得？

·　是否所有的错误都被测试过？

·　用户处理完错误信息后，将处于什么状态

·　是否在用户应该接受错误信息时，却没有错误信息弹出？

错误信息会影响用户体验。然而，不好或无用的出错提醒无处不在。虽最理想的状态是避免用户遭遇错误信息，但这几乎不可能。出错情况的设计、实现和确认可能与预期相反，但是，测试者往往善于发现意料外的Bug，并能仔细考究是否改进它们。

错误信息的案例

我非常喜欢举iPhone上Facebook App这个例子。这些冗长又晦涩的文字不仅仅试图涵盖了许多不同的场景，而且还可能无端地丢失。

可能如下的消息提示框可以列入反例“名人堂”了？

看看这款iPad上的The Guardian应用，如果我不想“重试”，该怎么办呢？

特定平台上的注意事项

对于任何项目团队成员来说，了解相关平台的业务、技术和设计上的限制，都是至关重要的。

那么，移动端App的测试人员应该找出哪些平台相关的问题呢？

·　是否遵照了这个特定平台的设计规范？

·　与竞争对手以及行业内的设计相比如何？

·　是否适应外围设备？

·　触摸屏支持手势吗，如：轻拍、双击、长按、拖动、摇动、夹捏、轻拂、滑动？

·　这个App可以被理解吗？

·　当转动设备的方向时，有什么变化？

·　可以使用地图和GPS吗？

·　有用户指南吗？

·　电子邮件的工作流程友好吗？

·　通过网络分享时，它运行得流畅吗？是否整合了其他社交应用或网站？

·　当用户正在进行多任务工作，并在不同App间切换的时候，它还运行正常吗？

·　当用户更新它时，它是否会显示时间进度？

·　默认设置如何?有经过调整吗？

·　使用音效会有不同吗？

案例：ChimpStats

ChimpStats是iPad上一个查看邮件广告详情的应用。我第一次使用这个应用是处于横屏模式。当我需要输入API密码的时候，我被困住了。我根本不能在水平模式中输入API密码，直到切换成竖屏模式，才输入成功。

连接和中断的问题当连接断断续续或是意外中断时，很多有趣的事情就可能发生了。

你是否尝试过在以下场景中使用App：

·　走动环境下？

·　Wi-Fi连接下？

·　没有Wi-Fi的情况下？

·　3G模式下？

·　间歇性地连接？

·　设置为飞行模式？

·　一个电话打进来时？

·　接收到一条信息时？

·　接收到一个提醒通知时？

·　在电量很低甚至自动关机时？

·　被强制更新时？

·　收到一条语音留言时？

　　这类测试最容易发现错误和Bug。我强烈建议你在这些情况下进行测试（不仅仅只是开机、确认它可以正常工作，还要尝试用户使用的整个流程，并在特定的时间间歇内强制连接和中断）。

·　这个App提供了足够多的反馈吗？

·　数据传输为用户所知吗？

·　它会慢慢停止，然后崩溃吗？

·　开启时会发生什么？

·　任务完成中会发生什么？

·　是否可能丢失未保存的操作？

·　你可以忽视通知提醒吗？忽视后会发生什么？

·　你可以对通知提醒做出响应吗？响应后会发生什么？

·　对某些问题，使用错误信息是否恰当？

·　当登录过期或超时会发生什么？

App的维护

想要加快整个测试的过程很简单，只需测试一次就一劳永逸了，对吗？请三思。

此刻我遇到的一个问题是： iPad上的一些App在更新后，再也不能下载了。对于一个用户来说，这是非常令人沮丧的。

可能，这也是开发者控制不了的。谁知道呢？我只知道它对于用户来讲是不能用的。我也尝试卸载App，然后重装，但这个问题始终未能解决。我在网上大量的搜索，除了找到一些关于更新操作系统的建议外，没有任何其他解决方式。可能，下次有空时候，我还会再试试看。

关键问题在于：如果一个应用只被测试过一次，且只有一次（或仅在很短的一段时间内测试过），很多问题你都发现不了。一个App自身可能不会发现变化，但外界条件却可以让这些问题发生。

当外界环境持续变化时，App又会受到哪些影响呢？让我们问问自己：

·　我可以下载这个App吗？

·　我可以下载并安装更新吗？

·　更新之后还能使用吗？

·　当很多App处于等待更新状态时，我能更新它吗？

·　系统更新后，它会发生什么？

·　系统未更新，它又会发生什么？

·　它会通过iTunes自动同步下载到其他设备吗？

·　它自动执行任务或测试有意义吗？

·　它会连接到网络服务吗？这会带来什么不同？

移动端的App每一个版本发布后，最好都去测试一下。每次发布新版本时，先定义最高优先级测试，确保其能在各种条件下进行（主要是在主流的平台上）。随着时间的推移，测试可以变得自动化。但请记住，自动化不是灵丹妙药，发现问题，只能通过人的眼睛。

案例：iPhone上的Analytics应用

　　我使用这个App已经两年了，之前它一直没有什么问题。但是现在，它却显示出我某些网站数据为零（但实际上，不止一个人一个月内访问过我的网站！）。从App Store的评论来看，我不是唯一一个遇到这个问题的人。

另外一个案例是iPhone上的Twitter。更新并启动这个App后，我瞬间看到了如下这个提示语：“你的时间线数据显示为空，你至今没有关注任何人” (但我是拥有5年经验的活跃用户)。我担心了一会儿，庆幸的是，这个消息很快就消失，然后加载出历史数据。

测试不是对错判断

我们讨论了移动测试的一些方面，但这些前提是：带着问题，才能发现问题。

通常，测试被认为是完全合乎逻辑的、可计划的和可预测的，过程包括：测试脚本和测试计划、通过和失败、正确和错误的反馈。走完这些测试流程就离真相不远了。

当然，如果必要，我们可以用上述方法进行测试，但这并不是测试的目的。我们不仅是为了创建测试用例、发现Bug，更重要的是找到关键的问题，为项目组决定什么时候发布App提供有价值的信息。而找到那些关键问题的最好方法就是：提问！

了解“CDC翻客”，请移步：【CDC翻客】翻客来袭！Fanke is coming！(链接：http://cdc.tencent.com/?p=6518)

(本文出自腾讯CDC博客: http://cdc.tencent.com/?p=6545)

源地址：http://cdc.tencent.com/?p=6545

360手机桌面专业版3.0新视觉项目总结

依宝 — 2012-11-20 17:41:51

项目背景

360手机桌面专业版是针对android平台推出的一款桌面管理产品。
产品在2.0版本上存在不同层面的问题；具体包括：
Chapter 1.视觉：logo品牌表现力，认知感弱、系统icon表意不清晰、平台整体视觉体系不统一等
Chapter 2.交互：产品功能模块不清晰；交互流程太复杂、不统一等
综上，3.0版设计目的，优化2.0产品视觉，统一产品视觉体系，以全新的面貌提升产品的视觉形象和品牌价值。

产品定位分析→用户群体调研→思维发散→交互输出→高保真图形输出

从前期调研我们归纳出目前市面上桌面类产品所强调的定位，及人们对此类产品提出的感受在功能上主要强调的特点：内容丰富、娱乐趣味、酷炫交互、多变主题。

通过调研取样调查，我们产品的主要受众群体大概范围在18-35之间

综合以上，产品在色彩取值上我们表现更年轻化，娱乐化、多样化。

品牌形象是用户认知产品的重要途径，在lOGO的设计上，保留原logo的优质元素，进行全新创造一个新的品牌形象来提升品牌的影响力，扩大用户认知度以及对品牌的忠诚度。
在形状上融入360品牌元素的形体，以传承360企业品牌的统一化。

连续图形效果类logo设计的特点在于运用一连串图形进行组合或有层次的叠加排列，通常在色彩上运用同一饱和度的彩色渐变或同一基调的色彩组合。
这种类型的logo视觉上给人比较轻快活泼的感觉，同时也表达一种和谐、发展、包容、团结的设计理念。

桌面系统icon，在形态上：延续LOGO的DNA元素；在表意上：视觉传达更清晰；在设计上：轻、薄化而不失质感表达

品牌的DNA在整体launcher设计元素，在视觉传达上和交互体验上高度的保持一致。以保证平台的统一性。

个性化定制widget

结语

基于设计趋势结合产品目标，快速准确的找出产品问题，并给出合理有效的解决方案；以用户体验为产品保驾护航，提高用户的满意度。

在视觉上将产品带入一个新的台阶。在满足产品功能需求的同时，提高设计的品质并融入微创新型设计理念，让成果更完整有效的落地实施并为产品带来价值和赢得用户的认可。

平台的背后更重要的是团队的协作。在敏捷开发和快速迭代的企业文化下，我们奔跑着前行…

UXC GUI Team
感谢您的阅读
手机桌面产品官网http://mobile.360.cn/index.html

源地址：http://uxc.360.cn/archives/1063.html

iOS和Android的设计指南

白鸦 — 2012-11-10 14:21:04

近几年并没有真正深入的做过几个复杂的移动互联网产品设计，而且我这人本来就懒不爱读书，也就一直没有好好去研读ios和android的设计指南。几年来这两份一直就在那里，不离不弃。最近得空，把HIG刚刚读完，正在开始读Android Design。

HIG(Human Interface Guideline)是apple为确保ios上各类app的用户体验质量和一致性，为产品设计师们公布的一份设计指导。这份设计知道俨然就是一个移动互联网入门者的教科书，非常值得一读。它适合所有移动互联网从业者，尤其是产品经理、UI设计师、号称公司首席体验官的O们。

Android Design虽然写的没有HIG好，杂乱且质量不高。但也是Android相关产品经理、设计师们的必读物。

我们很多的APP设计非常糟糕，很多设计不伦不类莫名其妙，基本上都是因为设计者根本没有好好研读过设计指南所导致的。

我越来越认为：
移动互联网的产品经理、设计师，如果没有研读这两个基本资料的话，是没有资格去做移动互联网的一线跟界面相关工作的。以后我团队招人时没有读完这两份东西会是很重的减分项，包括开发在内所有人员在开工之前必须认真读完这两份东西。当然，不读指南那是胡来，读了只能也不能背其所限。

昨天晚上在微信上得瑟了一下“不认真把ios和android设计指南分别认真读完的产品经理和设计师，怎么好意思说自己是做无线互联网的呢？连我这种懒人都看完ios开始看android的了，不就熬几个晚上吗”，结果一早起来不少朋友要求分享资料地址，好吧，看来比我懒的大有人在。

iOS人机界面指导手册（iOS Human Interface Guideline ）
在线地址：http://t.cn/hb5g1R （点右侧PDF可直接下载）
一个不错的中文翻译：http://xuexiao.me/2011/03/ios-human-interface-guidelines/

安卓设计指导（Android Design）
在线地址：http://developer.android.com/intl/zh-CN/design/index.html
一个不错的中文翻译：http://www.topfun.us/adchs/index.html

源地址：http://ucdchina.com/baiya/?p=921

大话产品经理

Evan — 2012-11-02 21:42:11

“产品经理”, 一个重未被真正定义的争议角色. 他有时是模糊的, 有时却又清晰无比. 有时他是产品的缔造者, 但更多时候他却是开发和设计人员眼中的公敌.

很早以前就想抽时间来写一篇文章, 说说我对 “产品经理” 这个角色的想法. 后来一直因为时间关系没有动笔. 再后来自己也懒得动笔了. 再后来, 随着我遇见过的产品经理越来越多, 加上自己也亲自做了一年多产品经理, 从不同角度再次认识了这个职位. 今天, 我想把这些经历分享出来, 聊一聊产品经理.

因为没有清晰定义其职责范围, 所以在下文中我提到的 “产品经理” 将会是很宽泛的概念. 我会尽量以目前业界的事实标准来界定产品经理的职责范围并进行讨论.

一. 我了解的产品经理们

1. 新蛋产品经理: 分而治之

第一次接触到这个职位, 是在新蛋做对美业务时. 所有的需求文档都是美国直接发过来. 写需求文档的被称为 “BSA”, 意即 “商业系统分析”. BSA 会将详尽的需求文档发到项目参与人员手上, 然后进行电话沟通, 传达项目的背景与商业目标. 确定大家没有问题之后, 就会开始项目排期, 进入到开发阶段. 对于稍大型的项目, 还会有 “BSD”(商业系统开发) 参与, 负责所有技术资源的调动. 有的项目里 BSD 还会参与 coding, 负责技术方案, 架构和底层实现等. 下面的开发人员会根据 BSA 的需求和 BSD 的方案进行开发, 直至提交测试和最终上线.

大体上在新蛋 “产品经理” 的职责是由 BSA 与 BSD 两个职位来分担的. 前者负责需求, 后者负责实现. 而一个小项目往往从属于更大的项目, 因此 BSA 实际负责的会更多. 项目进度的把控也是由两个角色共同负责. 一般来讲, BSD 会负责掐住开发时间, BSA 则负责整体进度. 与其它公司不同的是, 除 BSA 提出需求之外, 还有另一个被称为 “WM” 的团队专门负责提出和验证需求, 并交由他们选定的 BSA / BSD 去执行.

值得一提的是, 新蛋的 BSA 与 BSD 都相当专业. 我接触过的几位 BSA 都会和我详尽沟通需求, 对问题尽其可能解答. 那时候 BSA 通常选择在电话里直接沟通需求背景, 而在文档中则详尽描述需求对应的每个功能点. 对每个功能都配上 UI 界面与交互流程. 后来我在阿里时, 一位同事拿他的 Axure 给我解释什么叫 “高保真 PRD”, 看着他那图多字少, 流程混乱的文档, 我只能蛋蛋一笑.

BSD 也不是虚职. 我遇见的 BSD 都有极强的代码功底, 他们本身往往就是项目的技术架构师, 在项目里负责根据情况调整技术方案, 协调技术资源和与进度把控等工作, 类似其它公司的架构师 + PM.

要注意的是, 新蛋的 BSA 们似乎没有涉及到与运营相关的工作. BSD 们更不会涉及. 这块工作通常交由 Marketing 部门去做. 当然也有可能 BSA 们会做运营相关工作, 只是做为底层开发人员的我并不知晓 :-(

2. 阿里巴巴产品经理: 大包揽

后来我来到了阿里巴巴 B2B. 在这里真正零距离与传说中的 “产品经理”, 阿里称之为 “PD”(Product Director/Designer)一起工作.

在阿里巴巴, 一个合格的 PD 首先必须是成功的 saler. 阿里内部有 “打鸡血” 的传统, 每次做项目, Kickoff 都恨不得能办成晚会. 做为项目发起者的 PD, 必须有良好的 “忽悠” 功底. 当然, 我说的 “忽悠” 是褒义词. 因为在大公司, 特别像阿里这样的巨型航母里, 不见得每个项目都有意义, 做了都能看到实际的成效. 怎么调动项目参与人员的极积性, 让他们认为自己手上的项目是最逼的? 这必须要求 PD 会说, 有些时候还要善于画大饼. 除此之外, 阿里的 PD 们相更贴近用户, 更加 “草根”. 由于公司的轮岗制度, 大多 PD 以前做过运营甚至客服, 在这些一线职位摸爬滚打几年后, 对公司的用户群体会有更深入和直白的理解.

其次, 阿里的 PD 还必须是团队的 CEO. 从产生想法, 需求调研, 到 PK 项目资源, 向项目组传达需求和目标, 再到 kickoff, 进度跟踪, 随时根据情况迭代需求, 再到安排测试 case, 验收功能, 产品上线, 直至产品运营推广, 数据分析, 用户反馈和版本功能迭代等, 都由 PD 一人负责. 并且 PD 还要为产品的表现背最大的 KPI 指标. 所以好的 PD 必须是好的 CEO, 上窜下跳, 费尽口舌为项目做好三件事: 找方向, 找人, 找资源.

当然, 做的事多了, 就很难精通某个方面. 所以我合作过的 PD, 大都会遇见以下问题:

MRD, PRD 不清晰. 特别是 PRD, 由于产品需求经常一变再变, 甚至到了开发阶段仍然状况不断. 加上项目时间永远不够(有趣的是, 我从没有参与过时间充足的项目, 每个项目都号称时间紧迫资源紧张)因此很多时候 PRD 成了一纸空文, PD 不会持续更新, 就算写也只是草图画画. 到最后各种需求变成了口头交流.
流程进度把控能力较弱. 我做项目时就常遇见为赶 deadline 或初期没想清楚中途再改需求导致增/砍功能的情况. 常常搞得 UED / 开发团队一片怨声.
PD 大多不了解(广泛意义上的)技术却又自持理解用户. 这是个很大的问题, 常常导致 PD 想做的东西开发人员并不真正理解, 而开发的问题又很难被 PD 真正重视. 长期以往, PD 与开发产生了各种互不信任.

但即使有各种问题, 公平的说阿里的 PD 们还是具备强大的专业能力与敬业精神. 特别是在用数据说话这方面, 我遇见过多位强大的 PD. 但我的映像是, 阿里的 PD 们总是缺乏一些互联网 sense. 当然, 一家之言.

3. 创业团队产品经理: 铁人汉堡

离开阿里后, 我加入了一家创业公司. 在那里我的身份由开发人员转变为了团队管理和产品经理. 和老大谈职位时, 做为 UEDer 我聊了很多对产品设计的空想. 于是老大让我负责这块东西. 就这么着我开始了产品经理的生涯. 前后一年多时间, 做出了一个移动端产品. 这次亲身体验, 让我有了机会从另一个角度看待产品经理.

在创业团队里, 要求每个成员都能够 “一专多能”. 如果说阿里的 PD 是 CEO, 那创业公司的产品经理无疑是 CEO 中的铁人. 在事情的每个环节上, 都要求产品经理想得更清楚更加深入. 因为这时候产品经理背的不再是 KPI, 而是公司的方向, 甚至是公司这么多兄弟的饭碗(这么说一点也不夸张. 虽然有的公司老大很强势, 但也需要下面一帮产品经理帮着去实现他的想法). 这时的心理压力和所处环境与大公司做项目是不一样的. 事情变得极其琐碎, 需要搞定内(老板, 开发人员)外(商业, 渠道, 媒体等)各种事情. 至于客串 HR 招人, 清洁员工打扫卫生那更是便饭.

在创业初期, 基本没有自己的休息时间. 产品开发时我跟着开发一起加班, 连续一个月凌晨两三点回家. 产品刚上线时又常在周末被电话叫起来看数据. 所以那个时候, 我真的成了铁人.

同时, 创业公司的产品经理又是 “汉堡”. 为什么呢? 因为产品经理常常被夹在老板与开发人员之间. 老板看到的方向, 想做的事, 由产品经理负责转化为产品功能. 另一方面对于 UED, 开发等团队而言, 因为信息不对称常常不理解为什么要做这样的功能? 所以产品经理需要不断与团队成员沟通, 分享数据, 解释问题. 但要命的是, 一方面产品经理们没那么多精力, 另一方面并不是所有需求都能事前想通, 事情总在不断变化. 所以产品经理的想法经常修改, 难以执行下去. 久而久之, 产品经理成了大家的出气筒. 老板认为产品经理执行力不强, 而开发们则总认为产品经理没有想清楚, 不想投入太多资源和精力. 这是我在一年多的创业里所体会看到的.

二. 真的 “人人都是产品经理” 吗?

每个职位都有几本人人推崇, 称之为 “必读” 的入门书籍. 做前端的有 O'reilly《xxx 权威指南》动物书系列, 交互有 Alan 写的《交互设计之路》或《Don’s make me think》. 而对于产品经理, 放眼望去最具人气的应该是《人人都是产品经理》了吧. 可惜的是, 前几本书都经受了时间的考验,确为经典. 而后者近来却质疑不断.

当然, 首先声明我这里并非要讨论这本书. 因为我没有完整读完它, 仅仅看过一些片断, 在阿里内网里看过作者的一些东西. 这里只是想说说它的书名: 人人都是产品经理.

真的吗?

其实我十分理解作者取这个名字的用意. 但这个名字就如同魔盒, 一旦开启便失去了控制. 特别是对那些和我一样没有读过本书的人. 它似乎在告诉大家, “产品经理” 没什么了不起的, 人人都可以做. 就像滥大街的 “客户经理”, “销售经理” 一样. 但产品经理门槛真的这么低, 这么好做以至于刚毕业没任何经验的大学生也敢来应聘这个职位?

其实通过上面我所描述遇见过的产品经理们可以发现, 和任何职位一样, 想真正做好产品经理并不轻松. 很多时候甚至是痛苦. 《人人都是产品经理》告诉人们拥有哪些特质就可以成为产品经理, 而我则要列出一些点告诉你缺乏了这些不能够成为产品经理.

缺乏抗压能力.
如同上面谈到的, 虽然产品经理在不同的公司团队职责不一, 但都背负着极重要的责任. 对于大公司而言, 你的眼光和思考决定了项目组一票兄弟 KPI 是否过关, 大家忙活了几个月能否看到实际的功效反馈, 是否让大家觉得在做的事情是有意义的.
而对于小公司或创业公司而言, 产品经理认定的方向更有可能关系着大家伙吃饭的问题, 马虎不得.
除这些职责之外, 你还得做好准备随时被老大叫到办公室臭骂一顿, 亦或者每天被设计, 开发同事呼来唤去, 还得两边陪着笑脸, 一定不能崩溃掉. 在前期过需求讨论时, 请随时做好接受众人从不同角度的全方位 “拍砖”, 直到你觉得自己做互联网这一行就是个错误为止. 当然并不是说不该拍砖, 我只是把这些真实的日常会发生的常景说出来, 给没有任何经验的同学一个参考.
另一个压力来自于高层想像出来的 “需求”. 往往这些东西被称为 “行政任务”, 虽然和自己的理念不合, 但抗争无效后还是只能强加在当前版本里. 这等于是把压力推给了下面的开发同学, 搞得开发不配合, 老大又不停催促. 只能让自己夹在中间, 两边受气.
所以, 做产品经理, 请做好准备担责任, 受委屈, 背黑锅.
不能接受工作时间碎片化.
刚工作的朋友可能对这条不是很理解. 但有经验的朋友都知道, 当我们集中精力认真投入一件事时, 不仅效率非常高, 心情也会十分愉悦. 但如果你选择成为产品经理, 那就请和这种状态说 bye bye 吧.
产品经理的时间被分割得极碎.通常一天的工作时间都会在不同的需求会议, review 会议, 头脑风暴会议, 数据分析会议等等各种大小会中渡过. 真正写 PRD 画产品原型的时间, 往往只有等到下班后自己补上. 特别是在创业公司, 好不容易坐下来理清思路开始写文档画原型, 老大一个电话叫到办公室, 聊上几小时, 出来后发现不仅文档不用写了, 整个项目都可能暂停重来.
所以, 做产品经理, 请做好准备随时变化/被变化, 和 “专注” 说再见, 多线程运作起来.
没有一线工作经验.
个人觉得这是最忌讳的一点. 如果没有任何一线工作经验, 请从基层做起, 产品经理并不是捷径. 前些日子我总在思考什么样的人才适合做产品经理, 有很多感悟. 其中最重要的一条, 如果一个人没有积累大量的基层工作经验, 那么是无法胜任产品经理职位的.
因为从专业性上来说, 产品经理要求必须打通横向技能, 对 UED(用户心理/体验, 交互设计, 视觉表达等), 开发(实现的边界在哪里, 怎么合理安排资源), 运营推广(产品外部环境, 渠道, 成本), 内容(产品气质, 玩法, 功能), 数据(指标) 等几大模块都要有相当深入的了解, 进而形成自己的见解.
从产品上来说, 只有当产品经理对上述各模块融会贯通有机吸收后, 才能够做出真正贴合用户需求, 甚至如乔帮主般产生用户需求的东西. 才能够合理设计产品功能和规则. 才能够知道在什么时候应该坚持什么, 放弃什么.
而要做到这点, 需要花费大量时间精力去研究每个模块. 这并不是简单读几本书, 说几个专业名词, 或者扒几句别人的 blog 就可以的, 这需要学习和积累, 漫长的学习和积累. 但眼下整个行业却弥漫着浮噪, 我们一边标榜着乔帮主信徒, 一边肆意抄袭. 各种粗放的产品应接不暇. 产品经理们活在自己的世界里考虑各种用户需求和场景, 唯独忘了想想用户真的要什么.
在知乎上看到有人问 “产品经理（尤其是创业的）需要懂技术吗？懂到什么程度？”, 感觉挺杯具的. 提这种问题, 是没有真正认识 “产品经理” 的人. 做产品, 就好像手工艺人打造玉器, 或农民耕种土地. 如果对 “石” 或 “土地” 不了解, 看再多教科书也无法烧出温润的玉品, 耕出成片的麦浪. 看看缔造出我们身边真正可以称之为 “成功” 的互联网产品的人们, 谁不是从最基层做出来的? 马云从销售做起, 挨家挨户做推广开启了阿里巴巴; 李彦宏, 马化腾, 张小龙自己就是技术出生; 现在的 “反流氓大王” 360 当年不也是从流氓开始做起来的吗?
所以, 做产品经理, 请做好准备摆正心态, 不停学习, 先做专家再做大师, 切忌浮噪.
不了解自己的用户.
这点是接着上面的话再讨论. 由于缺乏一线工作经验, 不清楚自己的用户在哪里(对于开发而言, 技术就是他们的 “用户”), 不了解他们是怎么样一群人, 有着什么样的生活习惯, 价值观和追求, 常以虚拟的 “用主角色” 聊以自慰. 或者潜意识里把自己当成了典型用户. 这样设计出来的产品也难怪表面好看, 实际打不中用户的需求点.
还有另一种产品经理, 几乎从来不用自己的产品. 下班回家就和产品脱了节. 这样的产品要么太高端, 和衣食住行这样的平凡生活不搭勾, 要么就是产品经理自己都不愿意当产品的重度用户. 这样做一是发现不了产品有哪些毛病, 二是是将最后一条了解用户的路给堵死了. 我在这点上走过很多弯路. 在阿里和创业公司时都犯了这样的错误, 即把自己当成典型用户来设计产品, 又不愿多投入精力来用自己做出的东西. 到最后才发现, 我不用, 也没有其它人会用.
所以, 做产品经理, 请做好准备成为自己产品的头号重度用户, 在不同的地点时间场景下, 使用它.
缺乏必须的沟通能力.
沟通能力分为口头表达与书面表达. 口头表达, 要求产品经理能够条理清晰的阐述产品意图和思路, 能够给老大或开发讲清楚用户的需求和对应的功能点之间的关联. 书面表达则需要产品经理能将脑里的产品蓝图化为文档, 原型, 流程图等一一展示出来.
除此之外, 做为项目组 “CEO”, 你还得随时关注项目成员们的工作状态和情绪, 有什么不满的地方, 必须及时与他沟通. 一般跨度稍长或压力特别大的项目, 随着时间推移大家都会滋生出各种负面情绪. 这时候仍然需要你不断沟通来鼓舞士气.
所以, 做产品经理, 请做好准备练习保姆心态与三寸之舌, 通过沟通不断 push 大家前进.

想走上产品经理这条路的人们, 能停下来问问自己这五个 “准备” 有做好吗?

三. 产品经理: 我的反思

知乎上曾经有一篇神贴: 《豆瓣的产品经理面试题, 你能做出来么? 》(现在已被锁贴了), 相信很多人都看过. 贴子的回复里很多人都在对产品经理这个职位做反思. 有人问, 中国互联网已经发展到了需要职业产品经理的阶段了吗? 你看看当年的 QQ, 阿里巴巴, 百度, 哪一个是 “产品经理” 做出来的?

话是不错, 但眼光未免稍显狭隘, 忽略了当时与现在的环境差别. 暂且不论国内互联的发展阶段, 看看现实就知道, 产品经理职位确不可缺.

产品经理扮演着将不专业甚至不懂行的老板的想法转化成产品的角色(以及质疑推翻这些不合理的需求的角色). 所以老板们需要他. 有了产品经理, 老板们可以放开手来做更专业的事: 找方向, 找人, 找资源.

产品经理扮演着 “保姆” 的角色. 给团队打鸡血讲需求, 找成员聊天谈心画大饼, 为大家订饭搞活动. 同时产品经理也 “解放” 了很多技术人员, 可以让他们远离碎片化需求的干扰.

但不得不承认, 现在行业里的产品经理们是有问题的. 在上述 “真的人人都是产品经理吗?” 一节中提到的诸多不利于做产品经理的因素, 实际上就是我自己身上表现出来亦或观察到别的产品经理身上的毛病.

我认为现在各个公司似乎夸大了对产品经理的需要. 实际上有些工作可以由运营人员或技术去完成. 大包大揽导致人为扩大产品经理岗位缺口, 让很多没有经验的朋友误认为产品经理是 “万金油” 职业, 是没有技术要求的职位, 甚至是一块敲门砖, 摇身一变成为产品经理, 去决定他们的用户应该使用什么功能. 但大量同质化, 粗放的产品告诉我们, 这样做是有问题的. 并不是人人都是产品经理, 人人只是一个网站.

理想情况下产品经理不应该成为一个人的 “目标职位”, 而应该是顺其自然, 水到渠成的职位. 也就是说, 不应说 “我要当产品经理”, 而是当各方面积累到一定程度后, 自然而然转变为 “产品经理”. 很难想像一个有充分积累的人一点不会关心产品本身.

本来只想写写我见过的产品经理, 没想到花了三天时间写出这么多. 权当成对自己几年工作里的一些想法的总结吧. 欢迎大家和我讨论.

源地址：http://uxat.me/2012/11/evan-talk-about-productor/

网站统计中的数据收集原理及实现

耗子吴 — 2012-11-01 21:14:00

网站数据统计分析工具是网站站长和运营人员经常使用的一种工具，比较常用的有谷歌分析、百度统计和腾讯分析等等。所有这些统计分析工具的第一步都是网站访问数据的收集。目前主流的数据收集方式基本都是基于javascript的。本文将简要分析这种数据收集的原理，并一步一步实际搭建一个实际的数据收集系统。

数据收集原理分析

简单来说，网站统计分析工具需要收集到用户浏览目标网站的行为（如打开某网页、点击某按钮、将商品加入购物车等）及行为附加数据（如某下单行为产生的订单金额等）。早期的网站统计往往只收集一种用户行为：页面的打开。而后用户在页面中的行为均无法收集。这种收集策略能满足基本的流量分析、来源分析、内容分析及访客属性等常用分析视角，但是，随着ajax技术的广泛使用及电子商务网站对于电子商务目标的统计分析的需求越来越强烈，这种传统的收集策略已经显得力不能及。

后来，Google在其产品谷歌分析中创新性的引入了可定制的数据收集脚本，用户通过谷歌分析定义好的可扩展接口，只需编写少量的javascript代码就可以实现自定义事件和自定义指标的跟踪和分析。目前百度统计、搜狗分析等产品均照搬了谷歌分析的模式。

其实说起来两种数据收集模式的基本原理和流程是一致的，只是后一种通过javascript收集到了更多的信息。下面看一下现在各种网站统计工具的数据收集基本原理。

流程概览

首先通过一幅图总体看一下数据收集的基本流程。

图1. 网站统计数据收集基本流程

首先，用户的行为会触发浏览器对被统计页面的一个http请求，这里姑且先认为行为就是打开网页。当网页被打开，页面中的埋点javascript片段会被执行，用过相关工具的朋友应该知道，一般网站统计工具都会要求用户在网页中加入一小段javascript代码，这个代码片段一般会动态创建一个script标签，并将src指向一个单独的js文件，此时这个单独的js文件（图1中绿色节点）会被浏览器请求到并执行，这个js往往就是真正的数据收集脚本。数据收集完成后，js会请求一个后端的数据收集脚本（图1中的backend），这个脚本一般是一个伪装成图片的动态脚本程序，可能由php、python或其它服务端语言编写，js会将收集到的数据通过http参数的方式传递给后端脚本，后端脚本解析参数并按固定格式记录到访问日志，同时可能会在http响应中给客户端种植一些用于追踪的cookie。

上面是一个数据收集的大概流程，下面以谷歌分析为例，对每一个阶段进行一个相对详细的分析。

埋点脚本执行阶段

若要使用谷歌分析（以下简称GA），需要在页面中插入一段它提供的javascript片段，这个片段往往被称为埋点代码。下面是我的博客中所放置的谷歌分析埋点代码截图：

图2. 谷歌分析埋点代码

其中_gaq是GA的的全局数组，用于放置各种配置，其中每一条配置的格式为：

1	_gaq.push(['Action', 'param1', 'param2', ...]);

Action指定配置动作，后面是相关的参数列表。GA给的默认埋点代码会给出两条预置配置，_setAccount用于设置网站标识ID，这个标识ID是在注册GA时分配的。_trackPageview告诉GA跟踪一次页面访问。更多配置请参考：https://developers.google.com/analytics/devguides/collection/gajs/。实际上，这个_gaq是被当做一个FIFO队列来用的，配置代码不必出现在埋点代码之前，具体请参考上述链接的说明。

就本文来说，_gaq的机制不是重点，重点是后面匿名函数的代码，这才是埋点代码真正要做的。这段代码的主要目的就是引入一个外部的js文件（ga.js），方式是通过document.createElement方法创建一个script并根据协议（http或https）将src指向对应的ga.js，最后将这个element插入页面的dom树上。

注意ga.async = true的意思是异步调用外部js文件，即不阻塞浏览器的解析，待外部js下载完成后异步执行。这个属性是HTML5新引入的。

数据收集脚本执行阶段

数据收集脚本（ga.js）被请求后会被执行，这个脚本一般要做如下几件事：

1、通过浏览器内置javascript对象收集信息，如页面title（通过document.title）、referrer（上一跳url，通过document.referrer）、用户显示器分辨率（通过windows.screen）、cookie信息（通过document.cookie）等等一些信息。

2、解析_gaq收集配置信息。这里面可能会包括用户自定义的事件跟踪、业务数据（如电子商务网站的商品编号等）等。

3、将上面两步收集的数据按预定义格式解析并拼接。

4、请求一个后端脚本，将信息放在http request参数中携带给后端脚本。

这里唯一的问题是步骤4，javascript请求后端脚本常用的方法是ajax，但是ajax是不能跨域请求的。这里ga.js在被统计网站的域内执行，而后端脚本在另外的域（GA的后端统计脚本是http://www.google-analytics.com/__utm.gif），ajax行不通。一种通用的方法是js脚本创建一个Image对象，将Image对象的src属性指向后端脚本并携带参数，此时即实现了跨域请求后端。这也是后端脚本为什么通常伪装成gif文件的原因。通过http抓包可以看到ga.js对__utm.gif的请求：

图3. 后端脚本请求的http包

可以看到ga.js在请求__utm.gif时带了很多信息，例如utmsr=1280×1024是屏幕分辨率，utmac=UA-35712773-1是_gaq中解析出的我的GA标识ID等等。

值得注意的是，__utm.gif未必只会在埋点代码执行时被请求，如果用_trackEvent配置了事件跟踪，则在事件发生时也会请求这个脚本。

由于ga.js经过了压缩和混淆，可读性很差，我们就不分析了，具体后面实现阶段我会实现一个功能类似的脚本。

后端脚本执行阶段

GA的__utm.gif是一个伪装成gif的脚本。这种后端脚本一般要完成以下几件事情：

1、解析http请求参数的到信息。

2、从服务器（WebServer）中获取一些客户端无法获取的信息，如访客ip等。

3、将信息按格式写入log。

5、生成一副1×1的空gif图片作为响应内容并将响应头的Content-type设为image/gif。

5、在响应头中通过Set-cookie设置一些需要的cookie信息。

之所以要设置cookie是因为如果要跟踪唯一访客，通常做法是如果在请求时发现客户端没有指定的跟踪cookie，则根据规则生成一个全局唯一的cookie并种植给用户，否则Set-cookie中放置获取到的跟踪cookie以保持同一用户cookie不变（见图4）。

图4. 通过cookie跟踪唯一用户的原理

这种做法虽然不是完美的（例如用户清掉cookie或更换浏览器会被认为是两个用户），但是是目前被广泛使用的手段。注意，如果没有跨站跟踪同一用户的需求，可以通过js将cookie种植在被统计站点的域下（GA是这么做的），如果要全网统一定位，则通过后端脚本种植在服务端域下（我们待会的实现会这么做）。

系统的设计实现

根据上述原理，我自己搭建了一个访问日志收集系统。总体来说，搭建这个系统要做如下的事：

图5. 访问数据收集系统工作分解

下面详述每一步的实现。我将这个系统叫做MyAnalytics。

确定收集的信息

为了简单起见，我不打算实现GA的完整数据收集模型，而是收集以下信息。

名称	途径	备注
访问时间	web server	Nginx $msec
IP	web server	Nginx $remote_addr
域名	javascript	document.domain
URL	javascript	document.URL
页面标题	javascript	document.title
分辨率	javascript	window.screen.height & width
颜色深度	javascript	window.screen.colorDepth
Referrer	javascript	document.referrer
浏览客户端	web server	Nginx $http_user_agent
客户端语言	javascript	navigator.language
访客标识	cookie
网站标识	javascript	自定义对象

埋点代码

埋点代码我将借鉴GA的模式，但是目前不会将配置对象作为一个FIFO队列用。一个埋点代码的模板如下：

这里我启用了二级域名analytics.codinglabs.org，统计脚本的名称为ma.js。当然这里有一点小问题，因为我并没有https的服务器，所以如果一个https站点部署了代码会有问题，不过这里我们先忽略吧。

前端统计脚本

我写了一个不是很完善但能完成基本工作的统计脚本ma.js：

(function () {

    var params = {};

    //Document对象数据

    if(document) {

        params.domain = document.domain || '';

        params.url = document.URL || '';

        params.title = document.title || '';

        params.referrer = document.referrer || '';

    }

    //Window对象数据

    if(window && window.screen) {

        params.sh = window.screen.height || 0;

        params.sw = window.screen.width || 0;

        params.cd = window.screen.colorDepth || 0;

    }

    //navigator对象数据

    if(navigator) {

        params.lang = navigator.language || '';

    }

    //解析_maq配置

    if(_maq) {

        for(var i in _maq) {

            switch(_maq[i][0]) {

                case '_setAccount':

                    params.account = _maq[i][1];

                    break;

                default:

                    break;

            }

        }

    }

    //拼接参数串

    var args = '';

    for(var i in params) {

        if(args != '') {

            args += '&';

        }

        args += i + '=' + encodeURIComponent(params[i]);

    }

    //通过Image对象请求后端脚本

    var img = new Image(1, 1);

    img.src = 'http://analytics.codinglabs.org/1.gif?' + args;

})();

整个脚本放在匿名函数里，确保不会污染全局环境。功能在原理一节已经说明，不再赘述。其中1.gif是后端脚本。

日志格式

日志采用每行一条记录的方式，采用不可见字符^A（ascii码0×01，Linux下可通过ctrl + v ctrl + a输入，下文均用“^A”表示不可见字符0×01），具体格式如下：

时间^AIP^A域名^AURL^A页面标题^AReferrer^A分辨率高^A分辨率宽^A颜色深度^A语言^A客户端信息^A用户标识^A网站标识

后端脚本

为了简单和效率考虑，我打算直接使用nginx的access_log做日志收集，不过有个问题就是nginx配置本身的逻辑表达能力有限，所以我选用了OpenResty做这个事情。OpenResty是一个基于Nginx扩展出的高性能应用开发平台，内部集成了诸多有用的模块，其中的核心是通过ngx_lua模块集成了Lua，从而在nginx配置文件中可以通过Lua来表述业务。关于这个平台我这里不做过多介绍，感兴趣的同学可以参考其官方网站http://openresty.org/，或者这里有其作者章亦春（agentzh）做的一个非常有爱的介绍OpenResty的slide：http://agentzh.org/misc/slides/ngx-openresty-ecosystem/，关于ngx_lua可以参考：https://github.com/chaoslawful/lua-nginx-module。

首先，需要在nginx的配置文件中定义日志格式：

log_format tick "$msec^A$remote_addr^A$u_domain^A$u_url^A$u_title^A$u_referrer^A$u_sh^A$u_sw^A$u_cd

^A$u_lang^A$http_user_agent^A$u_utrace^A$u_account";

注意这里以u_开头的是我们待会会自己定义的变量，其它的是nginx内置变量。

然后是核心的两个location：

location /1.gif {

    #伪装成gif文件

    default_type image/gif;

    #本身关闭access_log，通过subrequest记录log

    access_log off;

    access_by_lua "

        -- 用户跟踪cookie名为__utrace

        local uid = ngx.var.cookie___utrace

        if not uid then

            -- 如果没有则生成一个跟踪cookie，算法为md5(时间戳+IP+客户端信息)

            uid = ngx.md5(ngx.now() .. ngx.var.remote_addr .. ngx.var.http_user_agent)

        end

        ngx.header['Set-Cookie'] = {'__utrace=' .. uid .. '; path=/'}

        if ngx.var.arg_domain then

            -- 通过subrequest到/i-log记录日志，将参数和用户跟踪cookie带过去

            ngx.location.capture('/i-log?' .. ngx.var.args .. '&utrace=' .. uid)

        end

    ";

    #此请求不缓存

    add_header Expires "Fri, 01 Jan 1980 00:00:00 GMT";

    add_header Pragma "no-cache";

    add_header Cache-Control "no-cache, max-age=0, must-revalidate";

    #返回一个1×1的空gif图片

    empty_gif;

}

location /i-log {

    #内部location，不允许外部直接访问

    internal;

    #设置变量，注意需要unescape

    set_unescape_uri $u_domain $arg_domain;

    set_unescape_uri $u_url $arg_url;

    set_unescape_uri $u_title $arg_title;

    set_unescape_uri $u_referrer $arg_referrer;

    set_unescape_uri $u_sh $arg_sh;

    set_unescape_uri $u_sw $arg_sw;

    set_unescape_uri $u_cd $arg_cd;

    set_unescape_uri $u_lang $arg_lang;

    set_unescape_uri $u_utrace $arg_utrace;

    set_unescape_uri $u_account $arg_account;

    #打开日志

    log_subrequest on;

    #记录日志到ma.log，实际应用中最好加buffer，格式为tick

    access_log /path/to/logs/directory/ma.log tick;

    #输出空字符串

    echo '';

}

要完全解释这段脚本的每一个细节有点超出本文的范围，而且用到了诸多第三方ngxin模块（全都包含在OpenResty中了），重点的地方我都用注释标出来了，可以不用完全理解每一行的意义，只要大约知道这个配置完成了我们在原理一节提到的后端逻辑就可以了。

日志轮转

真正的日志收集系统访问日志会非常多，时间一长文件变得很大，而且日志放在一个文件不便于管理。所以通常要按时间段将日志切分，例如每天或每小时切分一个日志。我这里为了效果明显，每一小时切分一个日志。我是通过crontab定时调用一个shell脚本实现的，shell脚本如下：

_prefix="/path/to/nginx"

time=`date +%Y%m%d%H`

mv ${_prefix}/logs/ma.log ${_prefix}/logs/ma/ma-${time}.log

kill -USR1 `cat ${_prefix}/logs/nginx.pid`

这个脚本将ma.log移动到指定文件夹并重命名为ma-{yyyymmddhh}.log，然后向nginx发送USR1信号令其重新打开日志文件。

然后再/etc/crontab里加入一行：

59 * * * * root /path/to/directory/rotatelog.sh

在每个小时的59分启动这个脚本进行日志轮转操作。

测试

下面可以测试这个系统是否能正常运行了。我昨天就在我的博客中埋了相关的点，通过http抓包可以看到ma.js和1.gif已经被正确请求：

图6. http包分析ma.js和1.gif的请求

同时可以看一下1.gif的请求参数：

图7. 1.gif的请求参数

相关信息确实也放在了请求参数中。

然后我tail打开日志文件，然后刷新一下页面，因为没有设access log buffer，我立即得到了一条新日志：

1351060731.360^A0.0.0.0^Awww.codinglabs.org^Ahttp://www.codinglabs.org/^ACodingLabs^A^A1024^A1280^A24^Azh-CN^AMozilla/5.0 (Macintosh; Intel Mac OS X 10_8_2) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/22.0.1229.94 Safari/537.4^A4d612be64366768d32e623d594e82678^AU-1-1

注意实际上原日志中的^A是不可见的，这里我用可见的^A替换为方便阅读，另外IP由于涉及隐私我替换为了0.0.0.0。

看一眼日志轮转目录，由于我之前已经埋了点，所以已经生成了很多轮转文件：

图8. 轮转日志

关于分析

通过上面的分析和开发可以大致理解一个网站统计的日志收集系统是如何工作的。有了这些日志，就可以进行后续的分析了。本文只注重日志收集，所以不会写太多关于分析的东西。

注意，原始日志最好尽量多的保留信息而不要做过多过滤和处理。例如上面的MyAnalytics保留了毫秒级时间戳而不是格式化后的时间，时间的格式化是后面的系统做的事而不是日志收集系统的责任。后面的系统根据原始日志可以分析出很多东西，例如通过IP库可以定位访问者的地域、user agent中可以得到访问者的操作系统、浏览器等信息，再结合复杂的分析模型，就可以做流量、来源、访客、地域、路径等分析了。当然，一般不会直接对原始日志分析，而是会将其清洗格式化后转存到其它地方，如MySQL或HBase中再做分析。

分析部分的工作有很多开源的基础设施可以使用，例如实时分析可以使用Storm，而离线分析可以使用Hadoop。当然，在日志比较小的情况下，也可以通过shell命令做一些简单的分析，例如，下面三条命令可以分别得出我的博客在今天上午8点到9点的访问量（PV），访客数（UV）和独立IP数（IP）：

awk -F^A '{print $1}' ma-2012102409.log | wc -l

awk -F^A '{print $12}' ma-2012102409.log | uniq | wc -l

awk -F^A '{print $2}' ma-2012102409.log | uniq | wc -l

其它好玩的东西朋友们可以慢慢挖掘。

参考

GA的开发者文档：https://developers.google.com/analytics/devguides/collection/gajs/
一篇关于实现nginx收日志的文章：http://blog.linezing.com/2011/11/%E4%BD%BF%E7%94%A8nginx%E8%AE%B0%E6%97%A5%E5%BF%97
关于Nginx可以参考：http://wiki.nginx.org/Main
OpenResty的官方网站为：http://openresty.org
ngx_lua模块可参考：https://github.com/chaoslawful/lua-nginx-module
本文http抓包使用Chrome浏览器开发者工具，绘制思维导图使用Xmind，流程和结构图使用Tikz PGF

源地址：http://www.codinglabs.org/html/how-web-analytics-data-collection-system-work.html

淘宝彩票移动项目开发实践

hangu — 2012-10-11 20:52:43

作者按：如今越来越多的互联网产品开始在移动终端发力，终端产品越来越丰富。但是，平台差异带来的开发成本浪费很让人头疼。一段时间以来，淘宝彩票前端组也在努力寻求移动终端项目开发最佳实践，尽管诸多方面不甚成熟，但抛砖引玉，希望我们的总结整理会对大家有所启发。

淘宝彩票客户端产品目前有两条体系：

1、原生应用：包括iPhone和Andoird上原生的客户端应用
2、嵌入式应用：作为子应用的软件包形式提供，嵌入到第三方的客户端软件中，比如淘宝主站客户端以及支付宝客户端等

由于产品的共通性，这两类应用都是需要考虑较多复用性和开发成本的。在原生App中，有不少内容是可以用简单的HTML5来实现的，比如iPhone客户端中的“订单页”：

而在子应用的软件包里，则有更多的地方可以运用HTML5来实现，包括一些复杂的富交互。例如支付宝客户端中各彩种的实现：

App的形式

目前移动终端上的应用主要以Native App为主，这种应用的优势是：

1，性能快，体验好；
2，可访问本地资源，更有效的利用设备，节省流量；
3，并且已有一定规模（App Store）,付费模式明朗。

缺点是：

1，开发成本高，移植性差；
2，所有发布需要经过App Store的审核。

当然，目前还存在一些Web App，用户可以直接通过浏览器来访问，例如Gmail。这类App的开发和维护的成本低，可以天然的在各种终端上执行，并且容易迭代更新，无需用户进行安装。不过就现阶段而言，无论从速度上还是交互上，用户体验与Native App的差距还是比较大的。既然两种App都各有利弊，那么我们就干脆将二者相结合：用原生控件做外壳和交互，保证流畅的用户体验和完整的推广渠道；使用HTML5来展示内容，保证内容的迅速迭代更新，即时响应用户需求。于是就诞生了Hybrid App，这也是目前最流行最合适的一种App形式。

对于前端工程师而言，在移动平台上没有了IE系列的困扰，HTML5的很多特性都可以大胆的运用。不同的是，我们需要设置一些针对移动终端的Meta属性，以及更合理的利用Media Query（主流移动设备的分辨率信息）。

JS框架的选择

找到适合使用HTML5的场景，这时就需要考虑JS框架的选择。首先需要明确的是，类似jQuery和YUI这种“重型”的库，由于包含了很多处理兼容性方面的代码，且API设计过于细致而显得太过庞大，并不适合移动端。我们可以选取一些专业的用于Mobile开发的JS类库，例如jQuery Mobile，Sencha Touch等。jQuery Mobile是目前最流行的一个移动开发的框架，文档丰富，社区活跃，有很多的UI控件供我们使用，并且提供对多页面的支持（通过Ajax方式读取内容，并提供页面切换的过渡动画）。我认为jQuery Mobile的最强大之处就在于其UI方面的支持，但这一部分恰恰不是我所需要的。Sencha Touch是ExtJs的移动版，对于不熟悉ExtJs的人来说有一定的学习成本。

我们选择了zepto.js作为底层库，使用sea.js进行模块的管理和发布，原因是基于CMD规范的模块文件最终需要打包入应用的软件包里，或是打包后发布到线上；此外，我们使用backbone.js为基础的MVC架构，用来剥离应用的数据部分；使用underscore.js做为前端模板引擎（backbone重度依赖）；使用iScroll.js为我们提供模拟滚动的功能。这些都是一些专业的“小库”，很适合移动端的开发。当然，具体情况需要具体分析，没有万能的框架，只有万能的开发者。如果时间允许，也可以自己来定制一套满足自身需求的基础库。毕竟在移动端，一切以 “精简”为主。

应用架构的选择

首先抛出两个小问题：

1, OPOA近两年来在互联网得到了广泛应用，相比于之前的多页面切换和跳转的方式，这个方法也更优雅，用户体验更好。那么在移动端，OPOA是否依旧适用呢？
2, HTML5最大的优势就是跨平台，只需要开发一套代码，就可以完全通用于不同的终端。但是，真的一套代码就能“吃”尽所有移动终端么？

先解答第一个问题。其实我们在开始尝试的时候，完全是参照PC端的OPOA来进行的，把很多的内容都放在一个Page里面，通过URL或Hash的方式来管理页面的显示。但实践表明，在移动端这样做是有很大弊端的。首先，在PC上显示区域比较大，我们可以先给用户展示一个框架，然后在分块的去显示内容，但是移动终端由于屏幕变小，往往同时只能展示一个区域，那么我们首先要根据URL判断显示哪个区域，然后再去加载这个区域的内容，这样一来，让本来在移动端就变慢了许多的页面更加的雪上加霜。其次，为了减少请求，我们通常会把大量的前端模板都塞到这个仅有的Page中，不仅导致页面体积变大，性能降低，而且维护困难。因此，我认为，在移动端最好的方式还是传统的多页面开发。

那么肯定有人会问，这样子的话岂不是会损失页面切换的流畅性，让用户不爽么。这个问题我们是可以解决的。第一就是采用jQuery Mobile的方式（Web App中非常适用），切换时用Ajax去请求新的内容，然后再渲染到页面中。这种方法在某些特定条件下会有问题：我们仍然需要使用URL来进行历史的管理，如果将这些页面作为静态文件打包在客户端中的话，在一些Android系统的手机中，硬件会将这些带后缀的文件当成一个完整的文件去查找（例如 index.html?page=XXX），然后发生错误。第二个方法就是在Hybrid App中，我们可以借助客户端来帮助我们进行页面的切换。你只需要告诉客户端即将要跳转的URL路径（可以是网络请求，也可以是本地静态文件），然后由客户端进行跳转。这样就可以在客户端代码里面设置Webview切换的动画效果，使客户端的整体风格更加的统一。

针对第二个问题，我们刚开始的目标就是用一套代码来自适应所有的客户端。结果发现，在iPhone和Android上，尽管风格差别较大，但是整体的结构和布局是很相似的，那么只需要设置两份CSS文件，再提供一份API，分别在两个平台上做实现就可以了，维护起来很方便；但是在iPad 上，由于布局和交互变化比较大，为了复用，不得不在原代码上增加分支，不但破环了原代码的完整性，而且维护时会产生一些意想不到的错误。这样就得不偿失了。因此，如果手机客户端和平板电脑客户端差异很大的话，最好还是分开单独进行处理，而不是为了“复用”而复用，大家可以根据具体的情况制定自己的策略。例如彩票的iPad客户端，我们就是纯粹基于HTML5为pad量身定做的：

Webview及其与HTML5的通信

Webview是手机中内置的一个基于webkit内核的SDK，是搭载Web页面的容器，也是负责Web页面和Native App之间相互通信的桥梁。在不同平台上Webview的实现是有较大差异的。

在Android平台中是支持JS方法和Java方法的直接调用的，我们通过下面的代码即可实现互相调用。

//将JAVA对象绑定到JavaScript中

mWebView.addJavascriptInterface(new JsToJava(), 'stub');

//在JavaScript中调用Java方法

window.stub();

function invokedByJava(data){

      //do something

}

//在Java中调用JavaScript方法

public void onClick(View v) {

      mWebView.loadUrl("javascript:invokedByJava('java_data')");

}

//打开webview，调用页面

mWebView.loadUrl("file:///xxx.html");

但在iOS平台上，SDK没有原生提供JavaScript调用Native代码的API，只有反向调用的方法。要想在JavaScript中调用Native，一般有两种方法：一种是Phonegap采用的iframe方法，也是比较推荐的，如下所示；另一种是直接修改页面的location，在大部分情况是可用的，但是有时候会产生一些莫名其妙的错误。这两种方法的原理都是相同的：利用Webview去截获JS发起的特殊的网络请求，然后对其进行处理。

//Objective-C
- (BOOL)webView:(UIWebView *)webView
    shouldStartLoadWithRequest:(NSURLRequest *)request
    navigationType:(UIWebViewNavigationType)navigationType {
        NSURL * url = [request URL];
        if ([[url scheme] isEqualToString:@"gap"]) {
            //在这里做js调用native的事情
            //...
            //完成之后回调js
            //[webView stringByEvaluatingJavaScriptFromString:
                       @"alert('done')"];
            return NO;
        }
        return YES;
}

//通知iPhone UIWebView加载url对应的资源，url格式为: gap:something
function loadURL(url) {
    var iFrame;
    iFrame = document.createElement('iframe');
    iFrame.setAttribute('src', url);
    iFrame.setAttribute('style', 'display:none;');
    iFrame.setAttribute('height', '0px');
    iFrame.setAttribute('width', '0px');
    iFrame.setAttribute('frameborder', '0');
    document.body.appendChild(iFrame);
    //发起请求后将其从DOM上移除
    iFrame.parentNode.removeChild(iFrame);
    iFrame = null;
};

除此之外，不同平台的Webview还需要进行一些特殊的设置，才能让其和原生的浏览器的行为表现相一致。例如：在Android Webview中，JavaScript和localStrorage都是默认禁止的，需要提前启用；Android的物理后退键默认是会关闭当前的 Bebview的，而不是执行history.back()；在iOS5.0以下的系统中，设置格式检查的Meta属性会偶尔失效，需要在 Webview中直接关闭其格式检查等等。在D2沙龙的PPT中有详细的描述，大家有感兴趣的可以看下。

速度/性能

对于一个互联网产品的用户体验来说，速度和性能几乎是最重要的因素。但令人遗憾的是，这也是目前阻碍Web App发展的最大的障碍。原因主要有以下几个方面：

１　低端设备多，受硬件的限制。根据木桶原理，一个木桶的水量是受最短的板的限制的。与之类似，我们在衡量页面性能的时候，也需要看其在中低端机型上的表现，尤其是广大的Android千元智能机。如果Android所有的机型都能有Samsung Galaxy的表现，我们也就不用愁眉苦脸了，但是在更多时候，我们不得不为了在HTC野火上能够正常的展示而放弃在Samsung上看起来非常帅气的效果。

２　简化的浏览器实现。本来相比桌面版的浏览器，移动版的浏览器已经在功能上做了一些简化，性能上有些差距。但是，与原生的移动浏览器相比，Webview会更慢。下图为一个页面分别在Mobile Safari和Facebook的iPhone客户端中的运行结果，我们可以发现，UIWebView中的JS运行时间大概是Mobile Safari的３－４倍，这恐怕也是Facebook放弃HTML5转向原生应用的一个原因之一。

针对上述原因，我们总结出一些性能优化的小Tip：

１　用HTML5的离线存储和本地存储进行缓存，或者将页面直接打包到客户端中，减少在网络下载中的耗时。
２　减少DOM数量，尽可能少的使用position:relative，减少对DOM的操作
３　用CSS动画代替JS动画，在Android平台上可以平稳退化，放弃动画效果（包括CSS3动画）
４　避免GIF图片的使用（消耗内存）
５　如果只是在移动端使用的话，请使用iScroll-lite来代替iScroll（iScroll里面增加了很多额外的功能，比如在PC上模拟滚动），在允许的情况下，可以关闭滚动条（滚动条也是创建的DOM元素）

关于滚动，还有一些其他的想法，大家有兴趣可以一试：

１　将页面拆分成多个Webview，这样子在每个Webview中就都是原生的实现了，但会增加一些页面间互相通信的代价。
２　用Canvas来代替Scroll，但是文字的渲染可能会有些问题。

由于篇幅原因，这里就不赘述更详细的性能问题了～

移动终端的网络环境

移动应用最大的特点就是方便、随处可用。但无论是2G还是3G，我国目前的网络状况都难以满足移动应用的要求。相比于Native App，Web App除了要下载数据和图片外，还需要下载一些额外的js/css文件，这些动辄上百K的静态文件对于平均速度还不到10K的2G网络来说实在是太庞大了。因此，目前最好的应用场景还是将页面打包到客户端中，版本变化时提醒用户让其主动进行更新。尽管这样会损失一部分web页面的灵活性。

调试

开发时的调试相对方便，可以基于浏览器进行。但开发环境和最终的执行环境还是有一些差异的，需要对终端的View中的“页面”进行调试，现在我们的做法是 “打点”，即使用一个Log代理控件给代码埋点，输出log，以此来辅助我们的调试。目前常用的工具有Weinre和JSconsole等。这些工具的原理是比较类似的：通过网络在其他机器上连接了一个调试的GUI，捕获待调试网页的JavaScript运行环境来查看代码输出或者对代码求值，并可以监控和修改调试目标的DOM和CSS样式。但是由于调试不是真正的发生在移动设备上，所以无法设置和捕捉断点进行debug。

在最新的iOS6中，Safari（仅限Mac桌面版）中自带了web检查器工具，可以让我们更方便的对iPhone/iPad上的Safari进行远程调试。

更多内容可以点击下载我在7月28日D2沙龙（北京场）的分享。

设计师的“通天塔”—浅谈设计沟通

珊珊 — 2012-10-09 19:49:49

前听过这样一个故事，南方的孩子没见过雪，所以不知道雪是什么东西。老师说雪是纯白的，儿童就将雪想像成盐；老师说雪是冷的，儿童将雪想像成了冰淇淋；老师说雪是细细的，儿童就将雪想像成了沙子。最后，儿童在考试的时候，这样描述雪：雪是淡黄色，味道又冷又咸的沙。从这个故事，是否可以联想到设计师和产品经理或营销专员之间的那点儿事？这里聊聊我对于设计时存在的沟通问题的理解，和总结的一些沟通方法，希望能给刚入行或正为此事伤脑经的你一点帮助。

在工作中，设计师是否经常遇到类似这样的问题：

需求方指着设计稿说，按钮应该更大点儿。颜色改个红色的会更好。不够大气！#￥%&*）（…。再或者，因为沟通不顺畅、不透彻，导致设计师对产品或对需求理解有误，后期花了大量的时间去再讨论，去修改或优化。

诸如此类的问题的确让设计师苦不堪言，我们经常抱怨产品经理没有眼光，或者表达力有问题，浪费大家的时间。殊不知，这是双方沟通出了问题。

在我看来，设计之初的沟通是至关重要的，设计作品是团队共同的结晶，一起捏的小人儿。需求没有描述清楚，出来的儿子产品经理怎么看都不像是亲生的，当然不悦。当前期就商量好这鼻子嘴巴耳朵长什么样了，捏的过程中再不断商榷细化，那么结果就自然是皆大欢喜的，儿子再丑也是咱亲生的，在双方共同努力下诞生的，这样也就避免了后期不必要的纷争，降低了后期沟通成本。所以，及时有效的沟通是很重要的。

什么是沟通？

沟通是一门博大精深的学问，在任何领域，任何分工，都避免不了沟通。无论是上下级汇报，或同事间协作。设计师也毫不例外，当接到需求或介入需求的时候，我们需要与需求方沟通，做用户调研则需要与用户沟通。前言中雪的故事，归其原因，是因为沟通不畅，或信息传达不对称不完整所导致。所谓沟通，是人与人之间的思想和信息的交换，是将信息由一个人传达给另一个人，逐渐广泛传播的过程。这是百度百科对“沟通”一词做的解释。没错，简而言之，沟通就是信息的传达。

需求方与设计师之间的关系

在一个项目里，产品经理职责是对整个产品负责，他决定了产品的整个命运，也就是整个项目的需求方，设计师是需要满足产品经理对产品的任何需求，但也并不是他说什么都算。有时候产品策略，或营销方案与用户体验相冲突时，设计师有义务有权利对需求提出自己的见解和更好的设计方案。有不同意见可以讨论，相互协调，而非有既生瑜何生亮的感叹，学会多角度换位思考，不应有谁一定对一定错的定论，但是最终决定权，应该依然属于产品经理或营销专员。往往一个好的产品经理一定是半个好的设计师，好的设计师也是半个好的产品经理。两者你中有我，我中有你。

双方存在的沟通障碍

A专业层面上，需求方过多干预（视觉、交互、用户体验）

对于专业层面上的问题，例如色彩、质感、样式等此类问题。诸如此类问题大多存在于营销推广设计上，建议可以在设计之初，与需求方沟通，明确以下几点问题，可以大幅度的降低后期返工的几率。

设计主题是什么
目的是什么
根据搜集的信息，与需求方明确大致风格（最好能明确到色彩、质感、主要的设计元素、布局等，前期达成意见一致后，可以避免后期返工）

B 信息传达上不一致，对产品理解不一致

此类问题，基本存在在产品设计上，在产品设计上，大方向由产品经理把控，包括产品的决策，产品的发展和前途，在此前提下，设计师把控用户体验。建议设计师提前介入项目，越早越好，了解项目背景，及发起这个项目的原因，现存的问题及要优化的点，取消信息不对等情况。避免产品经理说一点做一点，到最后在不了解项目背景、整体规划的情况下，跟完整个项目，这势必会出现前言中，学生描述雪一样的问题。

心理预期

所谓术业有专攻，设计师必须明白，产品经理，或营销的专业度，如对产品的理解、文案的把控、营销手段的拿捏等专业技能。产品经理或营销专员也必须清楚自己的产品或营销目的，他们有必要完善自己的方案后再与设计师沟通。而设计师必须相信自己的专业能力，有对于用户体验独到的理解和判断。

沟通的最终目的是在目标一致的情况下，达成共识。但我们必须清楚一点，就是并非每个上线产品或专题页面都是最优方案，所有的产品、设计，都是在不断迭代更新中不断完善优化的。所以，设计师应该学会适当的妥协和欣赏残缺美，退一步海更阔天亦空。

我们该如何有效沟通？

当我们要向对方索取认同，或避免后期意见不合时，首先要了解对方需求和也许隐藏着的真正目的，抓住沟通的问题本质，知其然知其所以然，才是制胜法宝，无论是设计之初的讨论阶段，中期对产品对设计优化，还是后期对需求和产品设计方案的意见纷争上；其次，通过有效的对话机制，传递专业精神和观点见解，以设计师的身份传递专业精神和观点见解，以达到设计师和需求方双方共识共赢为目标。最后，有效沟通要讲究策略和方法。

前阵子，读了一本《佐藤可士和的超整理术》，他的观点与我的看法，不谋而合，综合了他的一些看法和我的观点，兴许会对设计师与需求方的沟通有帮助。

1.倾听——了解现况

倾听是为了收集信息，掌握现有情况，收集需求方的想法。一些需求方的个人想法，例如对产品的认识规划及对产品的期望、背景、对于现有方案的意见等，这些都是存在在需求方的脑海中，设计师应该努力将这些信息都可视化，这些因素对你的设计将会有很大的启发和灵感激发。此外，倾听还是种美德。

2.问诊——抓住问题本质

问诊，这是佐藤可士和提出的说法。设计师=医生问的本质是通过问诊，找问题关键因素，帮对方整理思绪。通过多次的讨论，思想的碰撞，舍弃其余含糊不清的多余信息，理清问题本质，这是最关键的一步。

3.分析——导入观点

对问题本质的分析解读，以各种角度检视信息，根据关键因素，给出设计师专业看法和见解。

4.解决——给出方案

通过与需求方的探讨，给出最终的相应解决方案。

“按钮”案例分析：

倾听需求方说：我希望按钮更大点!

问诊设计师说：为什么要放大？按钮放大真的很不美观！

需求方说：我希望用户去点击，让用户觉得这个按钮能够让用户更有点击欲望，更明显一点。（原来是这样，关键因素是：希望通过对按钮的优化增加用户的行动力）

分析设计师给出专业意见。按钮变的更大一点儿，是唯一可以实行的方法吗？答案是否定的，站在用户的角度考虑，按钮太大会让人产生不舒服不协调的感觉，影响视觉表现效果。或许按钮可以变成使人更有点击冲动的颜色，或许可以增加一些质感，或者按钮变一种形状，这些方案都可以达到按钮更醒目，更有点击欲望，而非仅仅使它变大。

解决和需求方沟通后，得出结论，只要按钮变个颜色，再增加一些质感就可以达到预期效果。于是给出方案，原本蓝色的单色按钮变成橙色带渐变的微质感按钮。皆大欢喜。

总而言之，沟通是成为一个优秀的设计师的必修课之一。明确设计师和需求方之间的交融关系，并能够明白两者之间沟通障碍的原因，摆正好心态的前提下，找出解决方法的本质，抓住问题的关键因素，给出正确的观点，给出完美的方案，就能进行顺畅的沟通。这篇博文，并不是针对某个特定的问题去展开说明的，只是针对设计过程中沟通本身的一些浅薄的想法，希望各位受用。

微信营销分析

胖胡斐 — 2012-10-06 11:42:03

这两个月，微信营销像疯了一样在蔓延。我也一直在关注这个新玩意，渐渐的，有了一些看法，今天不妨分享一下。

我先是关注了“王力宏”，我跟他说一句话，他很快回过来一长段语音，然后再说，就不搭理我了。从一开始我就知道，这一定是机器做的，出于好奇，我时不时跟他说说话，不大有回复，有回复也是那种跟谁说都可以的打哈哈的话。有一天突然接受到王力宏发来的微信，里面说了他在嘉兴演唱会的情况，我想这也是录好通过微信平台统一发送的吧。

然后我因为一个麦当劳的Campaign，关注了“麦食大盗”，然后每天他都给我推送一个多媒体信息，有的是图文，有的是链接，打开之后是短片或者录音，大体都是说这个叫“麦食大盗”的Campaign的一些情况。每一次，我都觉得他有点自娱自乐。

去灵隐寺星巴克点大磁大杯的时候，通过一个二维码加了“星巴克中国”，结果连续三天给我推送星巴克的促销信息和新品预告。

好奇的我加了很多这样的号码，大都是一样的结果。

我问自己，这东西火么？答案好像是肯定的。

我问自己第二个问题：这种玩法火的范围在哪里？

问了周围的很多人，反馈大都是一样的，用微信加了品牌为好友，得到的大都是“推送信息”，同时，“被骚扰”和“没什么用”被提到的次数猛增。我问他们会不会点里面的链接时候，回复是好奇会点，但发现是广告之后就不点了。

我又在网上各种营销界的论坛之类的地方看，得到的信息却不一样。品牌商和营销组织普遍认为，微信营销很有效，能够让用户主动关注，并且能够“很精准”地推送信息，信息到达率100%，很少有CPM成本这么低的渠道了。

我坚信一点，一种成功的营销方式，一定要让品牌商和消费者都开心，都乐于从中获利。而目前的微信营销方式，似乎达不到这个标准。

我又问自己，品牌商为什么会很喜欢这种方式？

之后我收集了目前受追捧的几种方式，并且写出了我认为的实质。

通过这个整理，我发现，品牌商追捧的这些形式，有一个共同点，那就是特别适合“推送信息”。
相比微博，相比品牌主页，微信太好了：

品牌商的信息一对一发送，给人“专享”的感觉。比大众媒体的感受要好。
信息足够精准。100%的到达率，而且每个人都是主动看的（包括漂流瓶也是自己捞上来的）。
用户看到信息的界面纯净度够高。品牌商早就受够了自己在微博上发的信息，实际上是跟黄色笑话放在一条时间线上展示的做法了。微信多好，一个界面，只有你的信息和用户的手指头。
还可以不花钱，哪里去找比这个CPM成本更低的渠道啊？
多媒体让营销看起来很洋气。
结合地理位置，很多花样可以玩。
品牌商要做的事情很明确也很简单，让用户感兴趣加好友，然后整理内容定期推就好了。

我一直劝自己冷静，想想除了这些，还有什么原因，让品牌商们如此青睐微信。
品牌商早期通过大众媒体来做营销，后来发现这样成本太高而且不好监测，所以当SNS和微博出现的时候，品牌商们趋之若鹜，纷纷开设微博账号，设立品牌主页，希望在那里能够和用户建立关系。而建立关系的最终目的，很遗憾，还是推送信息，让自己的信息不断被用户在时间线上看到。后来大家发现，好几年了，品牌商还是没有找到在微博上靠谱的玩法。原因呢？他们习惯了站在高处，对着下面的粉丝说话。相反，他们没法习惯在微博上谦卑地进行所谓“互动”。
于是，微信出现，太好了，既能“精准”，又能“互动”。

不过，“精准”说的是推送的目标有列表，“互动”说的是“能说上话”，是单向的。

有错么？有，消费者理解的精准和互动好像是不是这个意思。
消费者认为“精准”是“我需要的时候你给我”，而不是“我喜欢过你你就给我”；
消费者认为“互动”是“我有需求你给我反馈”，而不是“搭讪”。

话说回来，微信是个什么东西，是一个用户之间交流互动的多媒体平台，社交属性很强。社交属性越强，用户就更希望平等，这种平等不再是你高高在上跟我喊话，也不是你发传单我扔掉，而是我们之间能够有沟通。这也是微信产品的初衷，张小龙说，永远不会让广告主推送信息，但实际他们就是这么用的，只不过先骗了好友而已。

上面，就是我看来看去，觉得现在微信营销走偏了的原因。
品牌商坚定不移的要求推送信息，而用户并不希望收到这些垃圾。

现实的表现也是这样，越来越多的用户开始取消对那些品牌微信号的关注。

我继续问自己，微信营销应该怎么做？
这个问题我没想透，我是从这几个角度去考虑的？

首先，什么样的品牌适合做微信营销。

我认为，可能是两种品牌可以做，一个是很大众化市场的品牌，另一个就是很利基市场的小众品牌，走两个极端。大众化品牌应该把微信作为一个互动的平台，而不是广告推送平台，真的，你都已经地球人都知道了，人家喜欢你，加你为好友，把你当朋友，你还每天发小广告，谁受得了。比如KFC如果做一个微信，我说我想吃汉堡了，他再告诉我哪里最近，然后给我一张折扣券，或者订餐电话之类的，就会很好。千万别一到吃饭的点，就推送一条“要吃汉堡么？”另一种，一家很有特色的餐厅，通过微信告诉有限的客户怎么走，以及最近发生的故事，会是一个情感沟通的好方式。

第二，如何得到用户的需求。

我们说用户不希望被推送，那怎么知道他想吃汉堡呢？想到Siri了么？苹果做了多NB的一个东西啊，告诉Siri就好了。当然中文的Siri弱爆了，而且跟微信也不搭边，那么，微信做一个中枢，然后去挖掘需求，再由品牌商提供内容，这样子的“开放平台”会不会跟有价值呢？

第三，必须结合地理位置。

为什么微信成为继QQ之后最NB的互联网产品？因为设备动起来了。所以，地理信息一定要用起来，哪怕是给附近的人推送，都比只给粉丝推送要来的有价值。那些有大量分店的品牌，很适合用这种方式来做。
O2O概念特别热，而所谓O2O实质就是带客到店。结合手机，到店就变得非常好办，所以，别推送了，看看怎么摇出来周围的人，然后拉他们来吧。

第四，在互动上多下功夫。

大量品牌的微信通过机器人完成，谁想跟一个机器人沟通呢？我跟王力宏发生的互动，跟打95588听到的“xxx请按2”没任何区别。所以，如果品牌要做微信营销，一定要解决怎么做互动的问题。如果我问星巴克的微信，哪里有最近的星巴克，他都没法回答我的话，“人情味”就太弱了，还不如微博呢。
我曾经把“人情味”拆开成“人气”“情感”“味道”，这里也是一样，能聚来人，但没有情感，没有味道，这种冷冰冰的高高在上的方式，放在“一个相对私密的一对一的”沟通环境中，对品牌情感的伤害会比想象的大。

小结一下：
1. 微信是个好平台，但现在很多微信营销走偏了。
2. 品牌商要推送信息，而消费者其实不希望收到传单。
3. 微信营销需要创新，需要在找需求和互动上多下功夫。

好了不扯那么多了，我们也没有实际的经验，因为还在摸索，欢迎大家探讨。

源地址：http://www.panghufei.com/?p=10914

《百万微爱——全球暖化》——视觉形象设计

CDCer — 2012-09-12 16:08:27

当提起全球暖化时，人们仅联想到的也许只有冰川融化，温度比往年高了少许如此简单，气候变化影响全球的水文和生物状况，或者说它影响着一切，包括风、雨和温度，它们都是相互联系的。

我们试图先去了解相关的信息。

图1 热浪
2008年受热浪侵袭的纽约街头，一个人试图把瓶中的水倒在身上降温。在最近的50到100年中，酷热热浪的发生频率比往常高出了两到四倍。

图2 干旱
当世界上的一些地方被风暴和泛滥的洪水袭击时，另一些地方却遭受着干旱的威胁。随着气候变暖，专家估计旱情可能至少增加66%，旱情的增加使供水量萎缩，并且导致农作物生产的质量下降。这使得全球的粮食生产和供给处于危险之中，人们面临饥饿威胁的危险越来越高。

图3 冲突和战争
气候变化的影响，优质粮食、水源和土地的减少，会使威胁全球安全的隐患增多，从而引起冲突和战争。

图4 北极熊自相残杀求生
但是由于全球气温升高，海洋冰层融化，使得北极熊很难在海洋上捕食，这种大型食肉动物开始寻求其他的食物来源，包括自己的同类。

前期构思
全球暖化带来的危机还有很多，作为公益的项目这便是我们第一次做展览思考最重要的问题。强烈的视觉风格，良好的识别性是展览视觉设计必要达到的，但通过怎样的传达才能让更多的人明白全球暖化与自身生存环境有哪些相关的影响，不只是一次好看，好玩的概念活动，全球暖化导致气候恶劣带来的后果，将会摧毁人类生存的家园。
形象设计与标准色系的灵感来原于图片中元素提炼，工厂排放着废气，正在融化的冰川，被淹没的屋顶。在后期，希望LOGO融合暖化的概念，特意设计片头动画表达这样的寓意。

明信片–让互动传递信息
过程中设计师一直在想有没有更好的方式，明信片通过粘土场景故事形式表达也成为视觉表现上一次新的尝试与亮点不仅告知活动信息，更重要能告诉人们全球暖化为我们生活带来的影响，希望大家看到这些信息时候不只是枯燥的文字解说，所以采用了拟人化粘土制作如此亲和力的场景来描述会发生的危害。

最后特别感谢富侨传播公司对地铁广告的赞助；
热心的fido对粘土制作的帮助指导；
在最后的日子里加班到深夜的工作人员；
所有相关人员的配合支持与推广才让活动圆满完成。

附：限量版全球暖化体验杯仅剩少量在形象店官网售卖http://qqimage.paipai.com/

(本文出自腾讯CDC博客: http://cdc.tencent.com/?p=5982)

相关话题：UED团队设计分享源地址：http://cdc.tencent.com/?p=5982

设计师的自我修养

slan — 2012-09-12 16:06:28

我一直有个习惯就是喜欢观察别人是怎么做事的，然后对比到自己身上，学习好的地方，剔除坏的习惯的。

这几年见过的、合作过的设计师怎么也有数十上百位了。总结下来，出现在设计师身上的优/缺点大概有以下这些

优点：

1、有灵气。好的设计师思维活跃，交流中经常能迸发出一些有意思的线索。更多出现在艺术类出身的设计师身上。

2、认真专注。好的设计师有条理的工作计划，认真、专注的工作态度。

3、责任心。好的设计师对产品负责，主动推进项目，项目完成后依旧关注用户的反馈。

4、上进心。好的设计师自我学习的意识和能力都很强。他们不会仅止于把工作做完，会利用时间去学习周边的知识。

5、专业化。好的设计师会比普通的设计师思考的更多，不只是按着需求依样画葫芦，而是在设计里融入自己的思考，从产品的全局出发去考虑每一个细节。这样的设计师能提交超出期望的设计方案，更能说服别人，也更能得到认可。

6、职业化。交付的文档细致周全，回复的邮件清晰明了，讨论时条理的表达观点。在与人合作的细节上处理的很“职业”，让对方感到和他合作很舒服，舒心。我一直认为对于做用户体验的人来说，怎么样让你的合作伙伴得到良好的体验也极重要。

7、有很多idea。好的设计师不会安心于只为公司、为产品经理做设计，他们自己就有很多好的点子。不少设计师都有自己的手册，记录自己平时突发的想法和灵感。

8、把idea变成现实。好的设计师不只是YY，他们会想办法把自己认为牛逼好玩的产品做出来，然后忍不住想让全世界都看到自己的作品。

9、阅读。好的设计师花时间阅读。

10、追求完美，关注细节。

缺点（基本上我每条都犯过，很多现在还这样）：

1、不用心。抱着应付的心态去做设计，第一价值观是“差不多就行”。不把产品当自己的。

2、拖延。基本每个设计师都有拖延的习惯。有些熬到自己最后两天要通宵，有些最后导致项目延期。

3、不开放。不接受建议，自我感觉过于良好，顽固。

4、懒惰散漫。工作时间松散，效率低，总是偷懒怠工。

5、不关注细节。在开发中后期还纠结产品逻辑，就是因为设计师在初期考虑不周。视觉稿的不准确也会浪费前端很多时间。

6、不喜欢设计。很奇怪为什么有不喜欢设计的设计师？

7、工作计划太差。对项目工作量预估不准，或轻视了设计工作量，或故意夸大工作量以换来足够拖延的工作时间。

8、不会经营自己。默默无闻的埋头苦干，不会找机会让别人知道你的成绩，不善于建立自己的声望。

9、太会经营自己。让人觉得功利、浮夸、不踏实。

10、抱怨。好吧，所有人都喜欢抱怨，尽量少抱怨为妙。

11、不准时。

其它待补充，上面有哪些说中你了？

源地址：http://slanyao.blog.163.com/blog/static/7688050420128753744180

带着热爱和信念前行：手机搜狐成长的印记（一）

粗线条儿 — 2012-09-04 13:46:26

手机搜狐网一直是七零八零后脑海中记忆的一个符号：手机上网上搜狐。

WAP,WAP…移动互联网沉寂多年以后，终于醒来，新的时代来临：智能机成为主流。移动互联网开始经历野蛮生长期…，HTML5的大幕也已开启…

冥冥之中，一股新生的力量，在助力手机搜狐网一个华丽的转身，是使命在召唤。

在搜狐网络大厦，一群80、90的童鞋们跟随梦想走到了一起，组成了MPC团队，重新扛起了这面大旗，秉承大道即简的真理，“手机搜狐网”更名为“手机搜狐”，续写传奇。

2012年6月，见证奇迹的时刻：

1. 手机搜狐的logo和icon的变化

2. 手机搜狐界面的统一升级，用手机体验sohu.com

有这样一群人：俗称APP ( Accountability, Professional, Passion)，在为手机搜狐的未来奋斗着。有爱，有梦想，有思考，有动力，有力量，有欢乐；用心研究手机，研究平台，研究新技术，研究一切新鲜玩意儿；急用户之所急，思用户之所虑，想用户之所想 …遇到这样一群人，你的移动精彩生活才刚刚开始。

用心和产品对话，产品才会因人而变，给足期待。倡导优质高效的APP们工作生活梦想汇聚的地方一定是舒适的办公区，在五道口城铁西北方向->搜狐网络大厦的一个神秘区域。

2012年8月，MPC办公区做了小小的调整，开辟出了读书区和会客区，小放照片两张：

认准路标…

新书陆续上架…

更多的照片持续更新中：持续的办公区海报、MPC独家限量版T恤真人秀、新产品抢鲜靓照……

敬请期待

本文出自搜狐MUED博客，转载时请注明出处

源地址：http://mued.sohu.com/2012/09/growing-mobile-sohu-1/

童年那些有创举的交互

anni.wy — 2012-09-03 09:55:23

如果在每个80后的心中有份深藏的记忆，43款经典的任天堂红白机带给我们的是永远的感动。童年是痴迷于超级马里奥（Mario）、俄罗斯方块、冒险岛、沙罗曼蛇、绿色兵团单纯的岁月… …那样的故事情节那样的画面甚至每个关卡给我们带来的惊喜，在我们不懂用户体验不懂交互的童年时代，却跟随着宫本茂和他的马里奥快速走进了一切以用户为中心的科技时代。

那些牛逼的交互创举公司

谈到用户体验谈到交互设计上有创举的公司，我们首先想到的无论是苹果还是亚马逊，微软、facebook…… 甚至迪斯尼这样的公司也可能会榜上有名，这些公司不仅仅是因为它们能让用户彼此交互，更重要的是通过全新的沟通工具尝试了新的对话方式。例如iphone在人机交互设计方面带给用户的是“信息就在指尖”，苹果公司带给我们的惊喜耳熟能详，从八十年代Macintosh计算机，定义了至今无人能够超越的图形用户界面（GUI）到创新性的iPod系列音乐播放器和iTunes在线音乐商店引发的数字音乐革命，任天堂则是被遗忘的角落。事实上，被称作马里奥之父任天堂的传奇设计师宫本茂，在交互设计领域做出了不可磨灭的贡献，我们今天很多习以为常的产品设计都是从任天堂开始的，并最终成为了行业惯例。

做有剧情的游戏

八十年代初期的PC游戏大多停留在一味追求高分的阶段，没有故事情节，只有多彩的画面，早期的游戏多处在非常低下的硬件水平，所有的游戏用户之间拼的就是高分，这很大一部分限制了游戏的发展，没有文化底蕴，题材单一，同时也导致了用户粘度低，容易视觉疲劳，不能够可持续的update，同时很大一部分也限制在自己的领域里，无法拓展一些周边的产业，比如漫画，电视剧，玩偶，人文传说都不能很好的结合并且发展，也限制了游戏本身的发展。

是否还记得小霸王学习机里的这款经典游戏: 玛丽医生（Dr.Mario）

这是一款在FC平台上发行的电视游戏，是在俄罗斯方块的基础上，增加了一些想象力，使之变为一款新游戏，游戏的目的只有一个：丢掷相应颜色的药片消灭虫子。初玩这个游戏的时候觉得很新奇，但随着关卡的深入，虫子的增多，单一的投掷而越显的游戏的乏味。这也反映了那个年代游戏产业的一个通病。

另一个例子是80年NAMCO的一款《PAC-MAN》（国内称"吃豆人"）。

80年代是游戏行业的一个重要转折点，任天堂游戏也因为宫本茂的加入和当时一部非常有影响力的电影《金刚》发生了质的改变。宫本茂在电影《金刚》中得到启发，认为游戏也可以是有情节的，有情节的游戏才能增加趣味性，提高用户的粘度。1981年任天堂著名的《大金刚》（Donkey Kong）诞生，宫本茂设计的是一个英雄救美女的故事，这也是街机历史上最为成功的游戏之一。

而此后，英雄救美的情节，也以多种多样的形式在任天堂之后的各种游戏系列中频繁出现。比如：

《影子传说》（Legend of kage）故事一开始，公主Kiri就被邪恶忍者绑架，这时，主角影从一片树林后跳了出来，前去营救公主。这是一部极具电影感的游戏。

包括后面会提到的《塞尔达传说》（The Legend of Zelda）。

永远的《塞尔达传说》

宫本茂说，市面上不一定只能有那种需要按图索骥，让人耗神费心的游戏。我们希望可以看到新型态的游戏用不同的面貌和消费者见面。我们不该只想着利用新科技做为未来发展游戏的筹码，真正该做的工作是开发可以吸引到更多民众的游戏。好比任天堂就是一个让五岁到九十五岁的民众都着迷的好例子。

尽管《大金刚》第一次给游戏加入了故事情节，但是在表现形式上，它和当时那些以获得高分为唯一目的的游戏依然没有太大的区别。《大金刚》的空前成功使任天堂和宫本茂意识到，未来的游戏，应当拥有更丰满的剧情，讲述更加引人入胜的故事。《塞尔达传说》沿用了英雄救美的故事情节，这款游戏融合了动作、冒险、解谜、角色扮演，还包含了少量的平台跳跃，潜入，竞速等等的元素，并融入了三个伟大的交互创举。

1. 饱满的故事情节

《塞尔达传说》系列不存在“经验”和“升级”这个概念，在这款系列游戏中让用户告别了之前不停地刷高分上排行榜为目的的老套中，他呈现在用户面前的是一个个饱满的故事情节，这使得用户在游戏中感受趣味性和和新的交互体验。

2. 保存进度，读取存档

在之前的游戏设计中，并没有设计保存进度这一功能，以至于用户为了刷高分，通宵达旦的沉浸在游戏中，一旦中断，必须重新来过。《塞尔达传说》的一伟大交互创举是能够在使用电池的主记忆体中储存游戏进度，这也是用户一直期盼和渴求的。记得小的时候游戏玩到正high的时候被妈妈叫去睡觉，每次都会很生气的说，这个死掉就去睡，好不容易玩到这关。任天堂这一历史性的创新，让用户眼前一亮，也让游戏开发商们可以大胆放心无限制的去设计游戏情节，而不必再担心游戏的漫长用户无法一次性玩完。此外，最初的设计中存档就是直接保存在游戏卡里而不绑定主机的，因此用户们可以方便地把自己的游戏进度随身携带，不管身处何方，只要掏出游戏卡插上任意一台主机就能继续玩下去。写到这里的时候，突然很想对任天堂道一声感谢，他倾听到了用户的心声，知道他们最需要的东西是什么，并针对这一方向无限制的创新。

3. Action Role Playing Game（ARPG）动作角色扮演类游戏

从游戏发展来看，最初是先有RPG（Role-playing game），ARPG是从RPG发展出来的分支。《塞尔达传说》开创了允许用户自定义角色的姓名，这样用户可以切身的把自己带入到游戏情节中，倘若我们把RPG的三大特性定为：故事性、艺术性、交互性，那么ARPG恰恰是在交互性上取得了巨大的创新。在这方面，ARPG吸收了动作游戏的特长，将激烈的打斗场面融入其中，使得节奏大大加快，更容易也更直接地调动了用户的参与欲望。

总之，《塞尔达传说》是游戏界的里程碑，ARPG的鼻祖，包括之后1998年发布的《塞尔达传说-时之笛》首先引入了三维游戏Lock on系统，完美解决了以往三维游戏的视角问题，Lock on系统在现在几乎任何一款三维游戏身上都能看到。因此，这可谓是三维游戏进步的一次大革命。在《塞尔达传说》身上数不清的创意，这么一款游戏性极高的游戏是其他游戏所无法相比的。

结束语

从游戏剧情到读取存档，以及后来的十字方向键到体感控制，任天堂在游戏行业的用户体验和交互设计领域长期扮演着开拓者的角色。他关注全年龄段的休闲娱乐，把用户锁定在5-99岁的人群，无论是白领女性还是老年用户，都是任天堂希望的用户群体，也因为这样的游戏用户定位创造了Wii和NDS的销售奇迹。任天堂不断尝试新的游戏交互设计，并且用最低的成本来呈现，把交互方式融合到游戏体验中。最后感谢任天堂陪我们度过了难忘的童年时光。

源地址：http://ued.alimama.com/posts/334