抽空读完了多看版的《创业36条军规》，有不少可以借鉴的，在此做一些书摘吧。

1. 暴风影音的冯鑫的创业四原则：(1)凡事只能靠自己。(2)万事皆有解且有唯一正解。(3)凡是你担心的事一定会发生。(4)享受创业过程。

嗯，可能有时候我们会说，放权给我们的队友、相信团队成员的能力、扬长避短之类的，这不是和“凡事只能靠自己”的说法矛盾么？其实在读这本书的时候，有各种观点会充满矛盾，但实际上最核心的也是这些矛盾，我理解的即是在创业过程中不断地自省以及直面自己内心的独立思考的能力，像“凡事只能靠自己”这句话应该是在自己有逃避责任的倾向的时候需要告诉自己的。同样，万事皆有解且有唯一正解，如果脱离提出它的场合，很容易被理解为独断专行的绝对主义，你也可以说万事万物皆有无穷可能、参差多态乃世界美的本源，但实际上我理解孙陶然老师引用这句话的核心观点是：需要相信你手上的问题能够被处理掉，是坚持做下去的动力。“凡是你担心的事情一定会发生”更是一句自省的话了，如果真要学院派的去做一个统计，你可能会说我担心的事情65.74%都没有发生，这句话是错的，但实际上这是一句让你随时清醒与保持冷静的说辞，得这样来理解。最后“享受创业过程”，是帮助人缓压的办法，既然是你自己喜欢的事情，好好享受就行了，得之我幸不得我命。所以下面的书摘也需要考虑实际的上下文来理解，不然扣上“心灵鸡汤”、“打鸡血”的帽子是最简单和没成本的。

2. 心力强大就是活得明白，能够快速调整自己的心态，一味放纵自己的情绪不但会让情绪在放纵中放大，还会影响到自己身边的人，其结果必然与你的愿望适得其反。如果把自己的心态和心情建立在需要别人怎么对自己的前提下，别人会很累，自己的心态和心情也永远无法和谐，必然陷入永无止境的纠结之中。

这些年最大的感触是，我们心理上的不安的核心来自于对欲望的迫切要求，想要尽可能快的获得‘成功’或‘自由’，就像我们糟糕的教育经常宣传的那种非黑即白的人生观一样，我们有时候会对一些没得到的东西充满贪欲，但实际上首先我们的追求本身不会是完美的，其次我们很多时候又像是在活别人的生活，我们看到的一些书、一些人，很崇拜，所以就去让自己做一些那些人做的事情，把自己的情绪模仿成他人的情绪、移情，核心仍旧是自己对欲望的强烈渴求，但是不管欲望的目的是‘自由’还是‘财富’，也即是不管欲望的目的是所谓崇高的还是所谓功利的，如果太迫切的放任自己以及太过于认真，都会导致心态的失衡。这个时候最重要的应该是‘认识自己’，崔卫平老师有篇文章叫《需要一个低版本的人性观》写得很好，经常翻出来看看，杀菌消毒。

3. 绝大多数情况下，绝大多数人是没有主意的，谁能提出建议并且能够自圆其说，谁的主意就会使团队的主意。

嗯，我经常觉得“我所说的都是错的”，那是因为我从来不相信一个人能够通过逻辑来彻底理解哪怕是世界上最小的一个现象，很多事情无法被证明，就像非常简单的你无法证明眼前看到的世界是‘客观存在’的一样，所以这样的理解带来两个观点，第一是所有的权威都是臆想，特别在我们这个本来就很落后的国度，所以我们都不是精英，做的决策一定不会完美，因此试错是允许的也是合理的，在一个落后的地方建设要从基础开始，所以团队的leader一定不要害怕决策错误，大家又不是在赌命，心态宽松一些，包括在决策没有太好的市场反响的时候，心平气和的改良和复盘，好过苦逼兮兮的抓耳挠腮手足无措。嗯…好像说偏了哇….你看嘛，我说的都是有问题的。

4. 所谓机会就是别人不看好的时候你去尝试了，所有的成功者都是敢于冒险的人。实际上，行动本身就创造了最大的成功机会。所以后来者有六成把握的时候就应该扑上去，小公司只有更多地冒险才能换来更多的机会。

“行动本身就创造了最大的成功机会”，和上一点的观点类似，谁能参透事物的本质呢？无非是走得多了，经验更丰富罢了，像天才一万小时的理论一样，挖掘出来的常识就是，联系得多的人渐渐变成了“天才”，而真正的天才也许存在，但是和我们有啥关系呢，世界上所有美与好的东西又不是全靠真正的天才建成的。所以带着独立思考和自省的态度放心去做即可。

5. 团队成员需要协同作战，有三个原则非常重要：(1)共同的愿景和价值观。(2)彼此信任。(3)注重沟通技巧。

孙陶然老师说注意沟通技巧尤其重要，深以为然，我认为沟通有两点必须做好，一是公开，二是理解，公开无需多说，如果不公开自己内心所想，那还沟通个屁，前提都不成立。其次是理解，核心是能够换位思考，特别是在持不同观点的时候，如果能稍微踩一脚刹车，试着换到对方的角度和思维习惯去理解他说的话的意思，这样能避免由于观点不同导致激烈冲突，而且如果能真正理解对方的观点，在说服对方接受自己的观点也会顺利一些，成功率更高。

6. 西方人习惯用契约来解决问题，先小人后君子。中国是一个喜欢将人情与商业、政治与经济混在一起的国家，中国人喜欢用情义来解决问题。事先你好我好大家好，而一旦出现分歧，这个不行那个不行怎么都不行。你和我讲契约，我和你讲感情，你和我讲承诺，我和你讲道理，纠缠不清。

切记，所有的分歧和意见最后需要形成契约和规定，人人都有选择权，参与还是不参与，但是一旦选择了就按照契约来，把自己讲得很崇高很有理想太容易了，占这样的小便宜真是心头又爽又划算，还可以到处吹嘘，但真要做好事情得都和规矩较真，包括和这个社会的规矩较真。

7. 如果可能，创业要选择最肥的市场入手，在一个大市场中占有一个小份额就了不得了。选对创业方向事半功倍，不要会啥做啥，要抓住用户的强需求来创业，在个人爱好、个人特长及市场需求之间找到一个平衡点。

个人觉得，社团和公司最大的区别在于‘爱好’、‘特长’和‘需求’的顺序，做社团，最大的选择依据是爱好，喜欢什么就扑上去做吧，这样才能慢慢把爱好培养成特长，需求可以最次之，随缘。但是公司得反过来，首先得考虑的是需求，其次是特长，最后才是爱好，要由自己的性子喜欢什么做什么那还是别创业了，那叫求生活，自己一个人玩就行了，一帮人在一起，彼此都是负有责任的，这在我们这样的小年轻居多的创业公司尤其需要多多思索。另外关于需求，书里面有些观点摘抄一下：“什么是需求？用户愿意支付代价的取药就是需求”，但是根据需求做出来的东西不一定能叫“产品”，“如果只是少数人在少数时候才会需要的，趁早别做，那叫概念不叫商品”，“也许用户今天会在网站上停留三小时，但三周不来，他也无所谓”，“需要和购买是两回事，有些需求其实不存在，例如那些可有可无的需求，那些用户根本不愿意为之付出代价的需求，以及那些可以被替代的需求，都属于锦上添花的需求，对消费者而言有了更好没有也无所谓”。

8. 所有的成功都是因为啃下了必须啃的骨头而不是捏到了捏得动的软柿子。

别畏难。

9. 创业期的公司大多业务未定型，核心任务是找方向，寻求业务突破。任何一级领导都不能只管人不管事，尤其是核心高管，不懂业务和不参与业务的高管必然被淘汰。

创业团队没有人能够做到脱离于具体的事物运筹帷幄，有这样的人的话也只说明他是多余的，因为创业初期一切未定的时候，哪里有什么好运筹的，相反最关键的倒是去深入团队所做的每一件事情里面，不是干预，而是深深的了解每一个项目的进程、每一个成员的进度、每一个产品的细节和功能，这些其实是给定方向提供足够的参考，参考越多、越细致的话，决策失败的几率可能越小。

10. 一个被彻底贯彻了的战略好过朝令夕改。

彻底贯彻这几个字本身就是一个不断提高执行力的过程，也是杀怪吃分升级的过程，现在砍不翻大boss没关系，怕的是畏首畏尾，大的吃不下来，小的又不想吃，自己手里的没做好就望着其它地方去了，做项目也是一样，复盘留到项目结束后再来，做项目的过程全部精力都应该是：搞定它。

11. 一个团队的战斗力不是由队伍中最聪明的那个人决定的，而是由战略的正确性和团队的齐心协力决定的。尤为值得关注的是队伍中的“聪明人”，他们是队伍中的危险分子。登山时他们总想抄近路，游戏时他们总想去守株待兔，时不时就脱离预定位置让同事踏空。聪明人总认为自己聪明，所以贯彻领导指示之前总要评估一下领导对不对，往往不会去理解领导的意图而是沉湎于自己的意图。聪明人对团队的贡献在于其创造力带来的鲇鱼效应，但鲇鱼只能敲边鼓不能挑大梁。

两点：团队的核心成员需要重视大局多余重视自己的才能的展示和发挥，因为核心成员是挑大梁的，要更有责任心。其次，我认为这里所指的聪明其实并不是真正的聪明，就像我之前听人说的某种“中国式的智慧”，去你妈逼的智慧，既短视又自以为是还他妈的不反省，有哪个聪明的人会这么做呢？真正聪明的话，多多考虑别人，多多付出结果才会双赢。

12. 不要认为你自己是产品的用户，当你研发产品的时候你已经不是用户了，因为你每天沉醉在产品里边，对产品的熟悉程度已经远远超过普通用户，你已经不可能理解普通用户的使用体验了。

这又是一个不结合上下文理解的话容易误解的观点，自己做的产品自己不是用户的话也趁早别做了，这句话的意思是这样的一个反省：当自己太熟悉自己的产品的时候，可能对普通用户对产品的需求、体验上的判断容易错误，比如一些功能因为是自己设计开发的，可能自己很清楚，但是看普通用户的使用才发现不是这样。举个更远的例子，我发现我们长时间使用电子类产品所以对它们建立起来的各种理解在那些不常用电子设备的人身上是完全无效的，一个很简单的小叉按钮我们看着明白是取消、删除之类的意思，但是不怎么使用电脑的用户就可能不知道，所以核心还是，别自以为是，多留一些余地，多思考多实践来找方法。

13. 人生最关键的是两件事：想清楚和坚持住。想清楚两点：(1)根本目标–你想过什么样的生活。(2)最高准则–你想成为一个什么样的人。坚持住两点：(1)上进心–立志让自己成为同学之中的出色者之一。(2)执着劲儿–坚持自己的追求，遇到任何苦难都不放弃。

一直以来觉得人生本质是很荒诞的，因为面对“既然我们都会死亡，那活着有什么意义”这个问题的时候，所有的答案从某些方面来讲都是虚无的，但实际上我们在生存的时候依然具有喜怒哀乐之类的情感，是因为我们天生的会喜欢高帅富真善美，所以我们为什么每天兴致勃勃的做着做那，充满希望的生活下去，无非是舍不得那些让我们感到充满欢喜的事物，而我个人想要的，无非是自由的在一个拥有这些美好体验的环境中生活，而我也期待能在这个环境中创造出一些美好的事物来，这是我的最高的生活目标。

我们在做一些网站项目的时候，可能会遇到需要把某个全局变量注入到所有页面的情况，比如我们做一个在线商城，那么可能需要将用户的资料：比如用户的账号、用户的姓名等注入到每个页面里面。

TeamCola中每个页面右上角都会出现的用户名

但是如果用常规的方法，也就是在每个views方法中通过render_to_response方法注入用户数据的话，这样就会做非常多的重复工作，就像下面这样：

def views_meth1(request):
    return render_to_response('template_1.html', {'user': request.user})
 
def views_meth2(request):
    return render_to_response('template_2.html', {'user': request.user})
 
def views_meth3(request):
    return render_to_response('template_3.html', {'user': request.user})
 
# ...剩下的N个方法

这在需要传入的变量比较简单、数量较少的时候还行，一旦需要注入的变量多一些，或是需要经过一些额外的计算才能生成的时候，那就麻烦大了。所以如何避免这种repeat yourself的2B模式呢？我们可以选择如下的一种模式：

在每次创建新的django项目的时候，一般来说我们都会在根目录中创建一个类似名为utils.py的工具module，在这个module中，我们可以通过定义一个自己的render方法，来为每次模板的渲染注入指定的全局变量：

# in utils.py:
def mp_render(request, template, context={}):
    context['user'] = request.user
 
    return render_to_response(template, context)
 
# in views.py:
from utils import mp_render
 
def views_meth1(request):
    return mp_render(request, 'template_1.html')
 
def views_meth2(request):
    return mp_render(request, 'template_2.html')
 
def views_meth3(request):
    return mp_render(request, 'template_3.html')

很好理解吧，这样以后有新增加的全局变量需要注入的话，只需要修改mp_render方法就行了。嗯，这是很普通的方法，既然是普通方法，那就再来个文艺点的吧。

先来看看django文档里面对于render_to_response这个方法的定义吧，在’Required arguments’里面，有提到这个方法的第三个参数，叫context_instance，对于这个参数的说明如下：

The context instance to render the template with. By default, the template will be rendered with a Context instance (filled with values from dictionary). If you need to use context processors, render the template with a RequestContext instance instead. Your code might look something like this:

return render_to_response('my_template.html',
                          my_data_dictionary,
                          context_instance=RequestContext(request))

大意是：“默认的，render_to_response方法的第二个dictionary参数会被填充为一个Context对象注入进html模板文件里面。如果你需要使用context processors，那么需要使用一个RequestContext对象来渲染模板。”

那么什么是context processors呢？看完这一段文档的定义以后，应该一切就很明了了。

首先需要明白在django模板系统中，有两种封装模板变量的类，一个是django.template.Context，这是最常用的，我们在使用render_to_response方法的时候传入的第二个dictionary参数，就会被这个Context类封装一次，然后传到模板当中；另一个是django.template.RequestContext，它和Context类相比有两个不同之处。第一个不同的是，在生成一个RequestContext变量的时候，需要传入一个HttpRequest对象作为它的第一个参数：

c = RequestContext(request, {'foo': 'bar', })

第二个区别是，它会增加一些自动注入模板的变量，这些变量从哪儿来呢？在django的settings.py里有一部分是配置TEMPLATE_CONTEXT_PROCESSORS的，这个配置中的那一个个的tuple元素其实是一个个可以被调用的方法，而这些方法都会接收一个HttpRequest对象作为参数，而最终return一个dictionary，这个dictionary里面的元素就会成为RequestContext中自动注入模板的变量。我们看看settings.py中TEMPLATE_CONTEXT_PROCESSORS的某一个元素 django.contrib.auth.context_processors.auth 对应的代码吧:

# in django/contrib/auth/context_processors.py
def auth(request):
    """ ignore doc string """
    def get_user():
        ....
 
    return {
        'user': SimpleLazyObject(get_user),
        'messages': messages.get_messages(request),
        'perms':  lazy(lambda: PermWrapper(get_user()), PermWrapper)(),
    }

可以看到，auth方法最后返回的一个字典中，包含了三个元素，所以如果在使用render_to_response方法时，传入了第三个RequestContext参数，那么在它所渲染的模板中，就可以获取到对应的user、messages、perms变量了。

所以最后文艺解决方法是，在每一个需要注入全局变量的views方法中，调用render_to_response的时候，都传入第三个RequestContext对象参数即可：

def views_meth1(request):
    d1 = {'method': 1}
 
    return render_to_response('template_1.html', d1, context_instance=RequestContext(request))
 
def views_meth2(request):
    d2 = {'method': 2}
 
    return render_to_response('template_2.html', d2, context_instance=RequestContext(request))
 
def views_meth3(request):
    d3 = {'method': 3}
 
    return render_to_response('template_2.html', d3, context_instance=RequestContext(request))

这样需要注入的全局对象，就可以通过扩展TEMPLATE_CONTEXT_PROCESSORS来实现，灵活性更高，更易扩展。当然，在一般的项目开发中，个人觉得普通方法也足够用，所以就根据项目来做取舍吧。

最近在做的一个项目中需要使用到HTML5中引入的WebSocket技术，本来以为应该很容易就能搞定，谁知道在真正上手开发了以后才发现有很多麻烦的地方，虽然彩程是一个以前端开发和设计见长的团队，而且作为一个二手程序猿又长期不被待见，但是为了让有同样需求的朋友少走些弯路，我还是决定把实现方法贴在这个地方。

关于WebSocket的基本概念，维基百科上解释的很清楚，而且网上也能搜出来一大把，这里就略过不表，直接进入正题。

这次的问题首先有一个前提，就是得用Python来实现这个服务器，如果对具体语言没有限制的话，推荐大家首选Node.js的一个第三方库：Socket.IO，非常好用，10分钟不打针不吃药搞定WebSocket Server，而且用JS来写后端，相信也能对上很多文艺开发者的胃口。

但是如果选择用Python，google搜索的结果几乎都不能用，最要命的问题是，WebSocket协议本身还是一个草案，所以不同浏览器支持的协议版本有所不同，Safari 5.1支持的是老版本协议Hybi-02，Chrome 15以及Firefox 8.0支持的是新版本协议Hybi-10，老版本协议和新版本协议在建立通信的握手方法还有数据传输的格式要求上都有所不同，导致网上大多数实现方式只能适用于Safari浏览器，并且Safari和C&F浏览器之间无法互相通信。

首先第一步需要解释的是新、旧版本WebSocket协议的握手方式。我们先来看看三个不同浏览器发送的握手数据的结构：

Chrome：

GET / HTTP/1.1
Upgrade: websocket
Connection: Upgrade
Host: 127.0.0.1:1337
Sec-WebSocket-Origin: http://127.0.0.1:8000
Sec-WebSocket-Key: erWJbDVAlYnHvHNulgrW8Q==
Sec-WebSocket-Version: 8
Cookie: csrftoken=xxxxxx; sessionid=xxxxx

Firefox：

GET / HTTP/1.1
Host: 127.0.0.1:1337
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20100101 Firefox/8.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive, Upgrade
Sec-WebSocket-Version: 8
Sec-WebSocket-Origin: http://127.0.0.1:8000
Sec-WebSocket-Key: 1t3F81iAxNIZE2TxqWv+8A==
Cookie: xxx
Pragma: no-cache
Cache-Control: no-cache
Upgrade: websocket

Safari：

GET / HTTP/1.1
Upgrade: WebSocket
Connection: Upgrade
Host: 127.0.0.1:1337
Origin: http://127.0.0.1:8000
Cookie: sessionid=xxxx; calView=day; dayCurrentDate=1314288000000
Sec-WebSocket-Key1: cV`p1* 42#7  ^9}_ 647  08{
Sec-WebSocket-Key2: O8 415 8x37R A8   4
;"######

可以看出，Chrome和Firefox实现的是新版协议，因此只传输了一个”Sec-WebSocket-Key”头以供服务端生成握手Token，但是遵循老版本的Safari的数据中有两个Key：”Sec-WebSocket-Key1″和”Sec-WebSocket-Key2″，因此服务端在生成握手Token的时候，需要做一次判断。先来看使用老版本协议的Safari，Token生成算法如下：

取出Sec-WebSocket-Key1中的所有数字字符形成一个数值，这里是1427964708，然后除以Key1中的空格数目，这里好像是6个空格，得到一个数值，保留该数值整数位，得到数值N1；对Sec-WebSocket-Key2如法炮制，得到第二个整数N2；把N1和N2按照Big-Endian字符序列连接起来，然后再与另外一个Key3连接，得到一个原始序列ser_key。那么Key3是什么呢？大家可以看到在Safari发送过来的握手请求最后，有一个8字节的奇怪的字符串“;”######”，这个就是Key3。回到ser_key，对这个原始序列做md5算出一个16字节长的digest，这就是老版本协议需要的token，然后将这个token附在握手消息的最后发送回Client，即可完成握手。

新版协议生成Token的方法比较简单：首先把Sec-WebSocket-Key和一串固定的UUID “258EAFA5-E914-47DA-95CA-C5AB0DC85B11”做拼接，然后对这个拼接后的字符串做SHA1加密，得到digest以后，做一次base64编码，即可获得Token。

另外需要注意的是，新版本和老版本握手协议回传给Client的数据结构有所不同，在附件中的server源码中写得很清楚了，看看就能明白。

完成握手只是WebSocket Server的一半功能，现在只能保证这个Server能够和两个版本的浏览器建立链接了，但是如果试着把Chrome中的消息发送给Safari，会发现Safari无法接收。导致这个结果的原因，是因为两个版本的协议的Data Framing结构不同，也即是在握手建立连接后，Client发送和接收的数据结构都不一样。

首先第一步需要获取不同版本协议下Client发送过来的原始数据。老版本协议比较简单，实际上就是在原始数据前加了个’\x00′，在最后面加上了一个’\xFF’，所以如果Safari的Client发送一个字符串’test’，实际上WebSocket Server收到的数据是：’x00test\xFF’，所以只需要剥离掉首尾那两个字符就可以了。

比较麻烦的是新版本协议的数据，按照新版draft的解释，Chrome和Firefox发过来的数据报文由以下几个部分组成：首先是一个固定的字节（1000 0001或是1000 0002），这个字节可以不用理会。麻烦的是第二个字节，这里假设第二个字节是1011 1100，首先这个字节的第一位肯定是1，表示这是一个”masked”位，剩下的7个0/1位能够计算出一个数值，比如这里剩下的是 011 1100，计算出来就是60，这个值需要做如下判断：

如果这个值介于0000 0000 和 0111 1101 (0 ~ 125) 之间，那么这个值就代表了实际数据的长度；如果这个数值刚好等于0111 1110 (126)，那么接下来的2个字节才代表真实数据长度；如果这个数值刚好等于0111 1111 (127)，那么接下来的8个字节代表数据长度。

有了这个判断之后，能够知道代表数据长度的字节在第几位结束，比如我们举得例子60，这个值介于0~125之间，所以第二个字节本身就代表了原始数据的长度了（60个字节），所以从第三个字节开始，我们能抓出4个字节来，这一串字节叫做 “masks” (掩码?)，掩码之后的数据，就是实际的data…的兄弟了。说是兄弟，是因为这个数据是实际data根据掩码做过一次位运算后得到的，获得原始data的方法是，将兄弟数据的每一位x，和掩码的第i%4位做xor运算，其中i是x在兄弟数据中的索引。看得眼花是吧，看看下面这个代码片段也许就能明白了：

def parse_data(msg):
    code_length = ord(msg[1]) & 127
 
    if code_length == 126:
        masks = msg[4:8]
        data = msg[8:]
    elif code_length == 127:
        masks = msg[10:14]
        data = msg[14:]
    else:
        masks = msg[2:6]
        data = msg[6:]
 
    i = 0
    raw_str = ''
 
    for d in data:
        raw_str += chr(ord(d) ^ ord(masks[i%4]))
        i += 1

至此，已经可以顺利取出两个版本浏览器发送来的原始数据了。接下来，就是将这个原始数据封装成不同协议版本的需要的Client数据，发送给对应浏览器就可以了。支持老版本协议的Safari还是很简单，如果从Chrome或者Firefox发送来的原始数据是字符串’test’的话，按照之前解码的方式，前面加上一个’\x00′，最末加上一个’\xFF’，变成’\x00test\xFF’就可以发送给Safari接收了。如果是从Safari发送来的原始数据’test’，同样需要做解码的逆运算，唯一简单的，是不需要再用一个masks来生成一个兄弟数据了，从Server端发送原始的数据给Client就可以了。

还是来模拟这个过程，首先数据的第一位仍旧是1000 0001(‘\x81′)，接下来获取原始数据的长度data_length，根据长度是否超过125位，来生成1个字节或是3个字节的代表长度的位数（附件中的源码省略去了使用9个字节表示数据长度的情况，因为实际的Server不会传输那么大量的数据），最后再将该字节串和原始数据拼接起来，就可以了，代码片段如下：

def send_data(raw_str):
    back_str = []
 
    back_str.append('\x81')
    data_length = len(raw_str)
 
    if data_length < 125:
        back_str.append(chr(data_length))
    else:
        back_str.append(chr(126))
        back_str.append(chr(data_length >> 8))
        back_str.append(chr(data_length & 0xFF))
 
    back_str = "".join(back_str) + raw_str

这样生成的back_str，就能够发送给使用新版协议的Chrome或是Firefox了。

至此，这个简单的WebSocket Server就完成了，能够同时兼容老版协议和新版协议的Socket连接，以及不同版本之间的数据传输。该Server的源码请点击这里下载，需要注意的是里面用到了twisted框架来跑TCP服务，代码写得不怎么样，仅供大家参考。

参考文档：

1、The WebSocket protocol draft-ietf-hybi-thewebsocketprotocol-17
2、How to (de)construct data frames in WebSockets hybi 08+?
3、基于Websocket草案10协议的升级及基于Netty的握手实现
4、ABC of WebSocket

转载果合为彩程设计CTO Shawn作的一篇专访，原文点此处进入。

Shawn来自于国内交互设计团队彩程设计。他是一个不折不扣的技术派，设计开发了数个 iOS 的应用。也同时精于交互设计，提出了很多关于移动应用设计方面的精彩见解。同时，他还喜欢自己制作音乐、远足和品茗。你会在下面的访谈中看到他对移动应用开发和产品设计方面的见解。

你怎样得到应用的设计灵感的？

两方面吧，一方面是通过多看别人的作品，并且不限于同类作品。一张CD封面，一幅油画,一张照片都有可能成为设计的初始灵感。另一方面就是大自然了。我很喜欢徒步去无人的高山中住上几天，保持所有的事情都以简单的状态存在，也许这是我的另一个灵感之源吧。

你的设计或者开发流程是什么？

我们的开发流程分为几个步骤：概念 > 低保真原型设计 > 高保真原型设计 > 交互原型设计 > 编码测试。至于编码和测试，任何一本从0开始学XXX的书都会花很大的篇幅介绍这方面，我就不浪费口舌了。

在我们的流程中，简单地介绍一下：

1 – 概念设计首先是个发散的过程，我们会不考虑任何约束（无论是营销、设计还是开发）的情况下设想功能。通常这个阶段的结果就是一个”要你命3000”级的概 念（当然，这不是产品）。其次是个收敛过程，我们会选定一个痛点（没错，只选一个），然后把所有的发散聚焦到这个痛点上。若有不能聚焦的部分，就砍掉这部 分。

2 – 低保真原型设计是把概念设计落实到实处的一步。这步决定了每个特征页面上的信息元素，以及特征页之间的关系。这步十分重要,因为它决定了这个产品最终该怎么耍。

3 – 高保真原型设计是通常意义上的视觉设计。它最终决定了产品是什么色系，长什么样。

4 – 交互原型设计是把高保真原型的结果放到实际设备中，拿在手上实际操作。这步会发现很多视觉上的设计错误，例如按钮的大小是否合适，按钮的位置是否合适。等等。

概括一下，概念设计决定了产品的精，低保决定了产品的神，而高保决定的是产品的皮肉，最终交互原型让她活起来。

你给应用开发者的三个建议是什么？

1 – 有且只有一个重点。详情在《iOS App 体验设计》这篇文章中提到。

2 – 先设计后编码。即便是看起来这个应用是多么的简单。

3 – 扩展知识面。设计的哲学是一个产品的灵魂，而灵魂不是由C++或ASM获得的，而是也许完全不相关的东西（例如音乐）。

你的 iPhone 的首页上有什么（你最常用的应用是什么）？

系统工具：备忘录、Mail、日历、音乐 其他的有：

• Reeder （看RSS利器，设计十分棒）
• Evernote （绝对的天天使用）
• 微博
• 微信
• Photosynth （全景图拍摄工具）
• Keynote Remote
• Wunderlist
• ProtoView
• DoodleJump

你最喜欢读什么（博客和书）？

我喜欢读的都不是一些技术性的（当然我也读技术性的，但并不能算喜欢）而是一些设计和哲学方面的。博客不太固定，但是比较喜欢 Smashing Magazine、Signal vs. Noise、Derek Sivers。其他的一些就不相关了，例如音乐方面的。

关于书，和行业相关的：

• Zen of Palm
• About Face
• Getting Real
• Rework
• The Design of Everyday Things

不太好把喜欢的书全罗列出来，和彩程设计的其他人比起来，我读书并不太多。

你是如何发现优秀应用的？

一般是逛 App Store疯狂下载试用，或者通过 RSS 订阅中发现。我订阅了一些 App 设计师的博客，例如 TapTapTap 的设计师 Devin

你工作用的软件和硬件是什么？

软件：

• Adobe: Photoshop, Illustrator, After Effect
• Apple: XCode, Logic Pro
• Ableton Live
• ScreenFlow
• Espresso
• ProtoView for Mac

硬件：

• MacBook Pro
• MacBook Pro（黑色版）
• Dell U2410
• Apple Trackpad（我已经很久没有用鼠标了）
• M-Audio ProFire610
• AKAI APC40
• Roland A-800Pro

你如何比较不同的移动操作系统平台的产品开发的差别（尤其是 Android 和 iOS）?

其实，我到是没有觉得操作系统会给产品的设计方法带来差异。毕竟产品的设计是针对人的，而不是针对所使用的技术。喝豆浆的时候，人们都关心的是豆浆 好不好喝，谁会管是机器研磨的还是用磨推的呢？我认为在产品的设计也不应该去关心技术本身。虽然产品设计会受限于技术，但是技术不是前提。

至于要对比 Android 和 iOS 的话，有个有趣的现象： Google 是技术引导型的公司，Apple 是设计（或者说体验）引导型的公司。这种基因会传递给他们的产品，例如 Android 是技术引导型的，而 iOS 是设计引导型的。更有意思的是，随之两个平台吸引了不同的人群：Android 被很多技术人员追捧，而 iOS 吸引的更多是设计师。于是两个平台的产品就天生性地带有一类气质。

作为一个技术的 fans，我很喜欢 Android，喜欢开源，喜欢所有可以折腾的东西。但是如果当我作为一个产品设计师的时候,我反感这一切。毕竟在吃包子的时候，使用了更先进的技术生产 的包子并不能改变你在味觉上的体验。同样地，那我们到底是在吃包子呢？还是在吃包子的生产技术？ 我认为这是个关键。

因此，如果把 iOS 比喻成 Leica M3，Android 比喻成 Canon 5D，而我是摄影师的话，我当然希望大家欣赏的是我的摄影作品，而不是我摄影所用的 Leica M3。

2011年5月19日，iFanr的编辑记者@周昶帆在东直门东方银座2楼Costa咖啡跟我约了个创业团队访谈，原文详见爱范儿iSeed访谈，在这儿转载下。

ifanr：彩程设计最早是做什么领域的？后来为什么转到 UED 设计这块？如何理解“用户体验设计”？

我：彩程设计的前身是 05 年末成立的成都彩程数字科技，起初是个外包作坊，做得很杂，06 年主要做川渝两地客户，平面网页多媒体都接；07 年给某集团公司当雇佣兵，做 VoIP 方面的产品设计、开发与运营，深圳上海北京几个地儿乱跑。

我：08 年初我们回到成都，熬过 512 汶川地震、度过基本的生存关之后我们意识到不能再做得这么杂了，往小了说我们得更专业才更有价值，往大了说公司得有方向、愿景和使命感。过去的两年我们团队跑了不少地方也看了不少企业，我们看到用户体验设计方面的需求正在各地蓬勃兴起，除了阿里巴巴、淘宝、腾讯等一线公司建立了自己的  UED 部门，很多有 IT 系统优化需求的公司能找到的还只是美工，无法帮助他们解决软件和系统从信息架构到视效提升到交互实现的系统性问题，我们觉得无论从市场需求和团队专长两方面来讲，用户体验设计都是一个我们值得投入的方向和领域。08 年 10 月份，我们的 CEO 老沈作了一个具有历史意义的 PPT 演讲——《RUN TO UED MARKET》，确立了我们进军用户体验设计的方向，那是我们历史上的遵义会议。

“用户体验设计”听起来象是某些别有用心的二杆子专家用来忽悠人的概念，试图把“洗脚”换成“浴足”然后把服务的价钱翻几倍，但实际上它是个涉及到美学、逻辑、心理等多门类学科，以及平面、IT、硬件等多领域技术的严肃领域，需要大量的实践和创新。我们认为它要解决的问题或者说终极目标，就是人如何通过设备与数据自然交流。

ifanr：在转型时，你们思考自己的优势在哪里，劣势和风险是什么？决定转型后的一段时间内，团队内心变化是怎样的，焦灼吗？对未来的不可知是怎么处理和度过的？

我：“彩程”这个名字，本来就代表了我们团队的特色，“彩”代表设计计，“程”代表程序，合起来代表设计和程序的完美结合，我们在视觉效果和前端交互上的技术积累一直比较深厚。我们的优势在于软件的设计、开发、运维都做过，习惯站在实现客户商业目标、给客户增加实际价值的角度来设计方案，每个关键环节都有成果输出物，让设计流程的各个环节对客户而言变得可见、可控、可预期。我们的劣势在于我们在二线城市，“用户体验设计”的概念还不普及，有需求的中低端客户还是习惯于把它打包到开发里面作为整体解决方案的一个部分，有需求的高端客户数量不多而且有很高的进入壁垒，十分熟悉他们的行业和业务是一个方面，一些资源型和关系型的企业系统也不是我们这样的纯技术团队能够染指的领域。我们面临的风险在于如果不能找到一个典型客户在一个具体的项目改造中获得巨大成功从而获得市场关注，就会在高不成低不就的尴尬中郁郁而终，不得不回到客户需要什么我们就满足什么，拼关系拼价格拼十项全能的老路。

决定转型后的一段时间内，团队内部一度也有些担心过不去这个坎儿，但认知上基本一致，知道简单满足客户需求没有出路，在用户体验设计设计这个领域，除非你有精准独到的见解和实施落地的能力并真正协助客户走向成功，否则不会赢得市场的尊重。出来创业，首先“愿赌服输”的心态必须有，其次要习惯于把未知当有趣。最坏的结果不外乎是做失败了，但至少我们已经按照自己想的那样去活过——听起来这已经不算是个坏结果了（笑⋯⋯）。我想我们必须感谢亚信联创及时找到了我们，给了我们这样的一个舞台，而我们在四川移动经营分析系统设计上的优异表现也为团队找到了第一个突破口。

ifanr：现在回过头来看转型是成功了，“选择”、“坚持”以及“取舍”这几个关键词上有什么样的思考可以分享？

我：相对于“成功”这个词，我更倾向于用“干得还不坏”来形容（笑⋯⋯），我们并未成功，我们还在路上。

“选择”代表方向，这比什么都重要。过去的三年里我们确实在用户体验设计外包领域生存下来并获得了不错的发展，但可能也丧失了在其他领域获得更高速发展的机会。我们不认为有绝对意义上的最优选择，弯路也自有其价值，相比选择去做什么，我们看中的是选择和谁一起做。

“坚持”是一个团队的基本素养，但必须以方向正确为前提。我们采取的策略是阶段性坚持，一个阶段后根据成效决定是继续、调整还是终止。

“取舍”应该是最让人纠结的部分吧，不管是小到一个功能、一个项目，还是大到一个产品，一个人，放弃都是艰难的。我们的基本原则是在正确的方向上把核心优势最大化，每个功能每个人都不可或缺，而非可有可无。

ifanr：为什么又要在设计外包之外，开始做自己的产品？现在还接什么样的外包？判断接不接的标准是什么？

我：从理想主义的角度来说，我们想站着把钱挣了。一个产品是一个团队理解力、执行力和资源整理能力的综合体现，同时也是人格的投射和梦想的承载，通过产品来提供服务、传递价值观终而影响世界，对一个团队来说是终极诱惑；从经济规律的角度来说，我们想躺着也能挣钱。只有把我们的技术和解决方案产品化标准化，才能消除对人的绝对依赖和实现爆炸性增长。所以⋯⋯我们不是被迫，而是主动迈上了自己的产品之路。嗯，是的，我们总不能通过向别人宣称我们工作环境宽松自由而且有阿姨给我们做饭来建立自豪感。

我们现在还在接小规模的外包。一些是保障客户关系的延续，但我们会挑选一些移动互联网方向的来做。另外一些是为了产品本身的拓展，比如为了百家 iPad 电子杂志解决方案能更好的推广和发挥方案最大的优势，我们也会承接一些样刊的制作；又比如为了接下来要推出的房地产售楼助手能够有个很好的样板客户，我们也会选择给某地产集团设计开发他们想要的一些 APP，融洽客户关系。

ifanr：决定做自有产品的开发，比如为什么决定第一个产品做 iPad 电子阅读相关的产品？通过对电子阅读产品内容上的选择，看出你们团队的气质，怎么去选材的？

我：实际上我们并未一开始就决定做 iPad 电子阅读相关的产品，而只是想给我们团队一个喜欢上牛博网的家伙送出一份特殊的生日礼物——比如从牛博上抽十篇文章来编一本叫做《牛壹周》的电子杂志。后来我们发现⋯⋯原来这份礼物居然还有那么多人喜欢，于是就一直做下去了。

这本杂志一方面是我们用来成熟技术和设计创新的大牲口，前后经过了五个版本的迭代；另外一方面也是我们这个团队爱好与志趣的一种表达，我负责主编和文学，古龄负责时评，老沈负责经济，ET 负责图片，Shawn 负责科普，文章主要来自牛博网，1510 部落和科学松鼠会，但也没什么限制，来自天涯和传统平媒体的好稿子也有不少，文章选择的的标准很简单，那就是我们喜欢——我们喜欢所有经过独立思考和小心求证，又被平和理性且幽默表达的东西。

ifanr：介绍一下你们做的电子阅读产品吧，在电子阅读这块做产品的团队很多，彩程设计的优势是怎么体现出来的？

我：嗯，我们自己在 iPad 上办杂志办得挺 High 的，也收到了很多反馈。除去那些说我们牛逼或傻逼的邮件，很多个人和机构也表达了他们想在 iPad 上办杂志的意愿，问我们该怎么做，收费几何。我们想独乐乐不如众乐乐，为什么不发挥我们的长处，干脆开发个 iPad 杂志出版平台呢？于是我们就做了“百家” iPad 出版平台和对应的 App，它让不懂苹果开发技术的人也能在 iPad 上发布自己的电子杂志并自定制交互，因为国内个人出版还有一些法律和政策上的限制和风险，目前我们主要面向的是杂志社、出版社和类型的企业客户。

不光是电子阅读产品，其实在任何一个公开竞争领域，有想法和行动力的团队都很多，与其去寻找一个别人都没发现的蓝海，不如结合自己的资源和竞争优势去根据需求定方向，差异化生存，品牌化发展。一方面彩程设计在用户体验设计领域深耕了三年多，在信息架构、原型设计、视觉设计、交互设计、技术实现和系统开发上，有自己一套经过实践检验的流程；另外一方面彩程设计血液里天生涌动的学习能力和创新基因会让我们近乎本能地怀疑已有的成规，并尝试探询新的最佳路径。我们是移动互联网界的新兵，优势如果非要说有的话，那就是历史经验与进化速度。

ifanr：彩程与铁皮人美术合作 iPad 上儿童动画书，对这一块的电子阅读市场有什么看法？

我：和铁皮人美术的合作纯属偶然，因为团队最初为自己的产品定方向的时候不知道要干什么，就是想找一个我们喜欢，而且会倾注爱的方向。CEO 老沈说，咱给麦兜（我女儿，当时三岁多）做个好玩的东西吧。我说好。我们第一个想法其实是做个教学类的应用，叫“神笔马良”。后来在设计和画工上都不太过关，我们自己内部就把这个项目停掉了。但在这个过程中，我发现小麦兜很喜欢看动画书，于是想不如我们也来做一个，于是就找到了我的朋友，铁皮人美术的老总魏纬，于是⋯⋯就有了《小鸡快跑》等一系列动画书的上架，第一本是免费的，叫做《了不起的爸爸》，尽管后来通过统计数据我们发现其实更受欢迎的题材是妈妈，但这并不影响我们的幸福感和成就感——单是《小鸡快跑》系列动画书全球的下载量就已经达到了 45 万。：）

iPad 作为一个教具，对于早教和幼教来说的好处显而易见，iOS 的人性化设计体验也让小孩的使用没有任何障碍。无论是从商业模式还是市场前景，我们都认为这都是一个值得长期投入也大有潜力的领域。不过虽然我们在这方面的试水很成功，但最终还是选择了把解决方案转让给了铁皮人美术，原因也很简单——动画书的核心价值还是在内容（原画、动画、音乐、故事）而不在程序框架——我们不想在一个无法释放彩程设计核心价值的方向上走得太远。

ifanr：最近推出的一个产品 Teamcola，它的诞生背景是什么？怎样在电子阅读之外，成为了自有产品开发的新方向？它是干什么用的？

我：嗯，TeamCola 是我们最近（5 月 23 日）推出的一款适合小团队的工时记录和统计软件，它通过开放透明的工作日志来建立团队信任，加强成员协作，细化时间管理，提升工作效率。

我们认为一家公司一个团队最有价值是人，而最值钱的是他们的时间。当你真正尊重他们的想法并尽量给他们时间管理上的自由，那么他们就能迸发出最大的激情与价值——TeamCola 的出现，则是为了确保这种自由不是散漫和失控。嗯，让那些诸如“中国人素质不高”，“中国人不诚信所以没法管理”，“在中国最不值钱的就是人的时间”说法都去死吧。

彩程以前是做设计外包的，最主要的客户是各地移动运营商，我简单统计了下，三年里我们参与了 7 个省市运营商的大小 47 个项目。09 年是我们设计外包业务全面开花的一年，整个团队才 9 个人，要飞赴各地做项目，高峰期一个月机票是两万块。为了让分布在不同地区每个人能团队协同作战而且有效工作时间内有效产出最高，我们开发了一个团队内部使用的小软件叫做 PowerMatrix，那是个根据我们自身需求不断设计和调整，包含了工时统计、考勤统计、项目管理、差旅费和通讯录功能的 Adobe Air 客户端，也是 TeamCola 的前身。后来我们决定给它做做减法把它产品化，以解决类似我们这样的小团队所面临的问题和需求，于是，TeamCola 诞生了。

我们目前比较象一个刚学会走路的小孩，因为有了自由行走的能力所以对这个值得探索的世界充满了各种各样的兴趣。我们还在一个寻找方向的阶段，并不天生认为自己就是应该做电子阅读或者团队管理软件什么的，我们做产品只有几个简单的原则：第一，我们喜欢且有起步的条件；第二，我们熟知且最好每天都在用；第三，我们自己可以把控产品的设计、实施和运营，不对外界有过多的资源性依赖。如果我们在一个好的方向上撕开一条口子，可能会选择放弃其他不温不火的产品而全力进军那个已经被市场初步验证而且最有希望获得成功的方向。我们正在路上，面临一万种可能，包括掉沟里（笑⋯⋯）。

ifanr：你们内部没有使用互联网公司产品经理这样类似的叫法和体制，那采用了什么体制？好处是什么？

我：我们没有产品经理这个说法，但有个对应的称谓叫“船长”。产品经理这个称谓在我们这个团队就好象程序员一样不招人待见，基本上“你们全家都是程序员”在我们这儿就算是骂人最狠的话了（笑⋯⋯）。当然，我没有嘲笑产品经理和程序员的意思，我只是想说，在彩程这样一个设计师文化主导的团队里面，我们天生会对正经刻板，不够好玩的东西有距离感。我们团队是个纯扁平的体系，所有人的名片上都没有印 Title，也没有印职位。我们内部的管理体制叫做“海盗船”模式，产品的掌舵人是“船长”，具体参与设计和开发的人叫“船员”。

其实不管叫产品经理也好，船长也罢，核心就是需要有一个人对产品的设计有绝对的话事权。这个人选，在我们团队里，不是至上而下委任的（比如 CEO 委任一个人当产品经理），而是自下而上产生的。比如你有好的 idea，理论上就可以申请做一个新的产品并担任船长。首先，你的产品定位、市场和财务规划必须通过 CEO 领衔的市场营销团队的评估（我们不做那种只做用户量但不考虑盈利的产品，开始做产品的第一天就必须考虑盈利）；其次，你得招募到愿意上你这条船的船员（其他人有拒绝上船的权利，除非他们自己认为船的方向没错，船长的技术和人品也都值得信赖），如果满足以上两个条件，你的船就可以出海了。CEO 和市场营销团队会辅助船的远航，并根据当初设定的阶段目标来阶段性地验收成果并决定这艘船是否继续、加油、调整还是停航。在船航行期间，船长就是最大的老大，做出的决策连 CEO 都无权阻止，管理层和其他人只有建议权。除了每周五必须到公司进行面对面分享和交流以外， 船长和船员在什么地方办公，什么时间办公均由自己决定，没有船长的同意，管理层也无法支配和调度船上其他船员的资源。年终该产品刨去成本之后净收益的 30％ 会归船长来支配，他可以都奖励给自己（这样可能下次就没人跟他干了），也可以根据船员的贡献进行合理分配。我们团队的成员都有个基本的工资基数，平时没有意外就按照这个发放，一些临时性的奖励政策，比如某某船员工作比较辛苦或者做出了特殊贡献，船长可以评估后决定给他发多少。在我们团队当中，大家基本工作层面上的能力都很优秀，但基本的技术和技能之外，总会有些人商业眼光和创新能力会更胜一筹，或者管理能力以及人格感染力上更胜一筹，也唯有这样的人，才能成为新一代的领军人物。至于能领成什么样，拿成果来说话，拿数据来说话就好。对于管理层而言，要考虑的不是我们什么时候才能成功，而是在这之前我们能承受多少次失败——每个个体越强，团队成长得越迅速，我们离成功也就越近。

ifanr：你们的工作氛围很欢乐，团队成员有什么趣事吗？

我：作为一个由文青、愤青、 演员、乐手、厨子、画师、驴友、自行车手以及健身教练所组成的团队，也许注定了欢乐不可阻挡，趣事亦无法避免。因为笑料和典故太多恐怕需要再来两三个专访才能讲完（笑⋯⋯），我想不如就单聊下一位叫文静的朋友给我们团队画过的一幅叫做《彩程大爆炸》的画儿吧。

这张画儿说的是在浩淼的宇宙中，天才与疯子如流星般划过，有些与我们擦肩而过，有些则降临到一个叫做彩程的星球。在这颗诡异行星之上，不仅有爱喝绿茶的帅哥、骑车进藏的怪咖，装逼死挺的妖怪、还有穿越时空的 UFO 与尖叫的外星人等诸多非人类。尽管他们面临的状况经常是如此的混乱和未知，但他们深爱的一句话却是《银河系漫游指南》封底上那句“Don’t panic!”

最后，谢谢爱范儿，谢谢所有使用我们产品还听我们唠叨的人。想了解我们更多趣事儿欢迎访问我们的网站或 Follow 我们的新浪微博 @彩程设计。

iOS APP体验设计不像互联网的体验设计那样，有一堆的方法论和可以“借鉴”的案例。 目前除了苹果的<Human Interface Guidelines>和前Palm的<Zen of Palm>外，没有找到更好的设计哲学和方法论。

事实上，即便认真地研读了HIG和Zen of Palm，甚至是Oolon Colluphid的哲学巨作你也无法严格按照Guideline设计出一款出色的APP。其原因，我得从程序猿和设计湿说起。

程序猿 vs 设计湿

最被思想处于上世纪初的人理解的软件设计开发是由 1. 美工 2. 程序员 3. 项目经理 构成。我这里讲的设计湿不是美工！这是前提。因为美工只关心好不好看，他们几乎不关心（或者不懂）产品的易用性。

如何鉴别程序员和设计师呢？ 你无法用会不会写代码来区分他们（毕竟很多设计师是会写编程的，例如彩程设计的设计师们，反之亦然），但是你却可以用通过他们平时思考方式来区分他们。

程序员： “哇！这个功能好！我们能不能在我们的APP中加上呀？”  这种场景常发生在他们看到了一个很 “COOL” 很 “绚丽”的APP后常发出的感叹（或者心里的感叹）。

设计师答：“我们凭什么要加这个功能呢？”

程序员更倾向于关注功能本身，希望把所有好的东西都加到自己的作品中。例如，好的设计模式，高效的算法，看似绚丽的特效。一般程序员的作品有两类，第一类是功能比北京的车子还要多，你需要一本牛津字典一样厚的说明书才能搞懂如何使用。另一类有十分绚丽的特效，界面飞来飞去，一走神就以为自己在耍杂技了。

设计师更倾向于关注产品整体，他们通常都有产品的功能洁癖。他们通常会从摄影中找到共鸣： 一张好的照片有三个要素  1.有一个鲜明的主题。 2.  画面中的元素可以快速地把观众的注意力转向这个主题。3. 只有一个主题，所有有主题不相关的重点通通砍掉。

不幸的是，很多iOS的开发者是从程序猿跳出来做的。 泪流满面地用咆哮体高喊 “我们程序猿也终于可以赚钱了！！！有木有！！！有木有！！！” ， 于是他们做出来的东西可以用下图简要地说明：

没错！问题不在于功能是不是足够的多，而是体验是否足够的好，是否能解决问题。而尤其在做iOS的APP设计的时候，由于设备的本身特点直接决定了设计完全不同于网站的体验设计。

我们认为，主要区别有以下三点：

1. 视觉焦点&操作焦点

所谓视觉焦点和操作焦点的问题，我们可以从传统的电脑使用说起。 我们控制电脑通常是通过鼠标， 手用鼠标控制屏幕的指针， 移动到某个位置， 点击、双击、拖动等完成操作。 我们看到的是屏幕，操作的是鼠标。我们的视觉焦点是屏幕，操作焦点是鼠标。属于视觉焦点和操作焦点不同的类型。

而有触摸屏的设备和电脑最大的一个区别就是它们的视觉焦点和操作焦点是同一个点。 因此，我们想打开一张图，只需要用手点一下图。

视觉焦点和操作焦点同一的最大好处就是十分容易学习使用这类设备。但是正是因为两点同一，当我们在操作的时候同时也会挡住焦点。

这一特性会影响到很多UI设计，例如：拿出你的iPhone，把手放在iPhone上，你会发现你的iPhone最大宽度也就4个手指的宽度。

我们用圆圈代表被挡住的区域，其中绿色区域是安全区域，代表我们心理上认为一定可以准确地点到的区域；而黄色区域代表我们心理上会有点忐忑，不能确定是否能点中的区域。例如某拍照软件的设计：

没错，问题不言而喻。 从UI的设计上来看，如果是个网页的话，视觉的确没什么问题（当然，删除按钮放在修改的旁边本来就是愚蠢的做法，这一点就先不说了）。但是由于视觉焦点和操作焦点同一的原因，点击修改就变得十分困难与紧张，何况旁边还是一个删除按钮。

2. 空间感知

传统的互联网网页间的跳转，我们都熟知的是利用链接。链接可以在整个网站甚至是网站间任意跳转，点了链接后就进入了一个全新的空间。空间感知为网状的，没有头没有尾，在任意一个点通过网址都可以进入。

在移动设备的应用程序设计中，进入APP通常都是一个固定的点，每个操作就带入另一个空间，如果失去了空间感知，就像失去了地图，用户会很容易有迷失的感觉。

而由于屏幕的大小等因素，APP不能直接告诉用户空间是什么样的，但是可以通过各种手段来给用户以暗示。例如：

Camera+中，两个主要的场景，一个是拍照，一个是照片管理。两者之间空间是上下的关系，当用户在拍照场景下点击相册时，界面会向上推动显示照片管理的场景。反之亦然。此时向用户暗示的场景如图所示：

更复杂一些的空间暗示，如Reeder iPhone版。空间中的每个位置十分清晰，并且用动画的方式流畅地向用户暗示这种空间感。不仅如此，Reeder iPhone版的加星去星的空间感知不是上下左右，而是前后的关系。请自行购买后体验。

除此之外，Reeder iPad版本和Our Choice的空间感知也做得十分的棒。以Our Choice和Reeder iPad为例（视频）。Our Choice在选章节的场景进入章节内文时，选章节的场景会缩小，通过“近大远小”的常识在一个平面内暗示两个场景间的空间关系。 Reeder 也采用了类似的方式。

3. 体位化设计

以iPad为例子，通常我们使用iPad的时候有两种体位，第一种是把iPad放在桌面上进行操作，这种体位使用APP，无论按钮在哪里，点击都需要用一只手完成，两个步骤间的按钮距离远近也不会成为负担。 而当手握着iPad的时，这种特殊体位，问题就出现了。

（如果你有手机，请现在拿在你的手上）倘若你只希望用一只手完成操作，你会发现，你用大拇指点击屏幕中所有点，却只有绿色区域是很易点击的。如下图所示，iPad的易操作区域也是分布在弧形区域内。

接下来用一个视频还说明坏的体位化设计和好的体位化设计的区别。

前半部分坏的体位化设计，是因为设计没有考虑到操作姿势，以至于左边一排不常用的功能占据了最重要的黄金区域，而常操作的区域却远离易操作的区域。 操作起来就比吃掉一只死苍蝇还难受。 而后者，好的体位化设计，所有的常用功能，一只手，不需要太多移动就可以全部完成： 上篇文章，下篇文章，标记未读，标记加星。

当然，如果你是我们《牛壹周》的忠实读者，那你一定记得我们的风火轮（详见牛壹周1.2之无敌风火轮）和一阳指(牛壹周1.1更新手记)？ 没错，我们坚决地去掉了一阳指，因为这是一个漂亮却难用的设计（至少不是一个好的体位化设计）。 我们在架构上保留了风火轮（当然，只是在程序中保留，但并未启用），因为这是一个很好的体位化设计案例。 例如，在阅读杂志的时候，我们常要翻下一篇文章，传统的操作是先进目录，然后再找到要看的文章，再跳转。 而使用风火轮，如视频所示，你的手完全不用离开屏幕，无论你的手有多大多少，无论你是左撇子还是右撇子。

在即将发布的iOS5中，iPad的键盘设计也很好地体现了所谓体位化设计的精髓：

结束语

iOS设备，甚至是包括Android在内的所有移动设备，他们都因为独特的使用场景，似的设计不同于网页设计。 很多“美工”，甚至程序员从网页设计转变角色来设计移动设备APP时常忽视这些隐形的因素，最终导致产品设计水平难以提高。如果说近年来交互设计师在网站设计中的地位越来越高，那在移动设备的设计中，他们的地位会更为重要。视觉焦点/操作焦点、空间感知和体位化设计这三个iOS设备的特点事实可以类比到Android甚至更多的设备中，当然也不局限这三个特点。

当然，也正是因为这些原因，当我们听到别人兴奋地告诉我们：“哇！HTML5可以做到所有设备自适应ye~”的时候，我们通常是不屑，心里默想“程序员！”。 当然，这里并非贬低之意。只是，有一点不得不承认，不同尺寸的设备，不同的分辨率，若想获得最好的体验，“自适应”让机器适应了却让人难以适应。例如一个按钮本来有1厘米高宽的，一个自适应，在iPhone上就只有原来的1/3时，你叫人怎么点击？ 当然这样的例子很多。 大多数这种不花功夫还大赚的宣传，就犹如电线杆贴满的小广告，通常都是缺少优质应用的病入膏肓的硬件厂商为了快速解决痛楚而买肾的做法。当然，对技术敏感的工程师就不自觉地帮着一起吆喝罢了～

我们彩程设计对移动设备还会持续观察思考。更多的设计方法和哲学会持续和大家分享。 敬请关注。

在我们公布TeamCola产品化的消息后，有不少朋友通过网站(http://teamcola.com)、新浪微博(@teamcola)、邮件(m2@teamcola.com)等找到我们，询问有关测试账号申请和邀请码的问题，这里给大家做一个解答。

TeamCola是一个小团队工作日志工具，虽然作为个人使用也没什么问题（事实上有人就是这么干的），但是TeamCola的定位还是在于记录和展现小团队的工作，所以我们只会给那些愿意以小团队规模（3-20人）参与试用的朋友发放独立账号，并且需要提供一些必要的信息以完成账号的建立，当然，也不存在所谓的邀请码了。

而在此之前，我们会让申请测试的朋友亲自试用一下TeamCola以后，再决定是否让自己的团队加入到试用中来。具体的方法是，我们会建立一个用于测试的团队，然后邀请各位希望参与试用的用户到这个测试团队中来进行试用和评估，稍后各位会收到我们发出的邀请邮件。

如果在个人试用后，决定让自己的团队也试用TeamCola，请给m2@teamcola.com发送申请邮件，我们会和你联系，并为你创建独立的团队账号。

最后想说的是，TeamCola还是一个开发中的产品，基于我们自己和一些兄弟团队的使用情况来看，它的核心功能没有问题，所以我们愿意拿给各位朋友来试用，也很希望能听到你们的意见和建议，以帮助我们完善它的设计。

谢谢 ：）

屋外炮声隆隆，又一年过去。年终岁首，想简单回望下彩程的2010——毕竟于我而言，彩程已非一家公司，而是一种生活方式。

年初的时候，我们引入了投资合伙人，在保留彩程原有品牌的前提下重新注册了公司。“彩程数字科技”从此变身为“彩程设计”，注册资本比以前大了一个数量级，公司也搬进了成都最好的商业写字楼之一的力宝大厦。

凭借2009年在移动运营商客户中打下的品质基础与良好口碑，2010年我们在运营商应用系统垂直领域的设计业务也一直开展得水到渠成——除了支持四川移动、云南移动、重庆移动等周边地区的移动项目改造，我们还承接了亚信杭州、北京移动、辽宁移动等更远地域的项目外包设计。有段时间，S、我、古灵、竞总、Maklu、小龙、Fish还有梅西相继打着飞的征战四方，团队一个月的机票费是两万块。

在这里，我想我们必须感谢我们最大的客户——亚信联创所给予我们的各种合作机会，尽管在过去的一年之中，因为产能的关系，我们所推掉的合作大大多过我们最终所承接的。

对于团队而言，过去一年里最大的收获，还是人——1月Shawn猛龙过江，2月Maklu前来报到，5月小龙应召入伙，10月ET越洋而至，12月豪哥重新归队。

当一群才气相当、意气相投的人聚在一起，会形成一个团队一家公司，同时也会形成一种气场一些态度。

比如，一方面我们觉得通过给一些优秀的公司做设计外包来获得收入是“把事儿做对”了；另外一方面我们觉得不仅要挣钱还应该做点能表达我们对这个世界的善意、理解与期许的东西——我们称之为“做对的事儿”。

年中的时候，我们迈出了自己的第一步：做了一本iPad上的电子杂志——《牛壹周》。杂志办到年底，有了三万多个下载，四个版本升级，五万多次更新——这样的成绩，我们自己也有点小小的吃惊。杂志是免费的，但通过这本杂志，我们认识了很多有趣又有料的人，也享受了信息自由流动的快感，以及与用户直接沟通的酣畅。

后来我们再接再励，开发了“百家”APP与自助出版平台，协助个人与企业在iPad上编辑、发布和管理自己的电子杂志。我们运用这套系统不仅为多个商业客户打通了一条通往移动互联新媒体的管道，还帮几位我们所喜欢的知名作家免费出了他们作品的iPad版，比如冯唐老师的《冯唐文字》以及关军老师的《大脚印儿·奥运阴影下的2008》

出于对幼儿教育的偏爱，也因为某种机缘巧合，我们和成都插画出版届的老牌劲旅——铁皮人美术走到了一起。我们联合开发了iPad和iPhone上的一系列有声读物——包括已上架的《小鸡快跑》系列动画书（6本），以及年后会陆续上架的《中国神话故事》系列动画书（4本）、《爆笑西游》系列漫画书（8本）以及《漫画三国》系列漫画书（8本）。

《小鸡快跑》系列动画书自12月4号在APP Store上架至今，两度杀入新品推荐首页，在全球一共被下载七万四千多次，最高的一天，有六千多个下载——嗯，小鸡跑得挺快，接近贴地飞行。

过去的一年，对外打怪，对内升级——除了产品开发与外包业务，我们也一直在健壮自己的IT支撑系统：UI前端代码库平台“CCW UI”升级成了“有爱库”，项目管理软件“PowerMatrix”也升级成了“TeamCola”，而这些增强内力的修炼，也让我们有别于江湖上许多仅仅靠邪门兵刃与凌厉招数取胜的剑宗。

年假之前，我们上线了2010年内的最后一款iOS应用——“拜年财神”。该应用上线四天后，冲入中国区News & Worthy首页，娱乐分类第二名——对我们来说，这确实是一个Happy ending.

就像所有精彩的影片都有续集，这一年内我们所攒下的人品也还没有耗尽——2011年1月30日，也就是放假后的第二天，我们与行走在同一条路上却资源互补的新朋友敲定了一笔战略投资，同时也共同确定了一条驶向大洋深处的新航路。

蓝海深处的宝藏与海妖正在向我们发出召唤，亲爱的彩程湾海盗们，新的一年，愿我们志趣不凡，所向披靡，Color～Our～Way～

对于电子杂志，不管是媒体还是风投，都已经在07年左右下了“已死”的结论。互联网周刊在07年的《电子杂志已死？》一文中，对电子杂志运营公司惨淡经营或者狼狈逃离做了深入的解读。也正是在07年，我跟poco的姚总因为项目合作见过一面。当时大家互相介绍，姚总说poco是IDG投资，做社区和P2P下载的。电子杂志？提都没提。

然而，2010年乔帮主推出的iPad，让电子杂志业重新燃起了希望。Times，Wired等国外知名杂志品牌，连iPad都还没看到，就投入了Apple的怀抱，在iPad上市时同步推出电子杂志，还是收费的。在电子杂志尸横遍野的中国，大家仿佛一瞬间就明白了，原来电子杂志应该这么搞。从2010年8月开始，各种电子杂志开始登陆iPad，其中有从坟墓中爬出来的，如zcom，读览天下等，也有新锐，如周末画报(iweekly)，第一财经周刊(CBN)等。

基本上，从坟墓中爬出来的僵尸，还是07年的思路。他们扫描几百个杂志，然后弄个App把扫描图贴到iPad里来卖钱，就像以前把扫描图放到PC版的电子杂志阅读器一样。他们期望通过iPad这个神器，能够把以前卖不出去的东西变成黄金。同样的，对于PC时代饱受诟病的电子杂志阅读体验，他们仍然视而不见。那些扫描图上的正文小的跟蚂蚁一样，用户看杂志，需要用手指双击页面，上下左右拖动，才能完整的阅读一页；完全不支持多媒体，别说链接，声音和视频了，甚至连目录都可以没有。这个模式的代表是读览天下，看看阅读界面的截图（点击图片查看iPad上的实际浏览效果）：

《计算机世界》

《三联生活周刊》


竖版

我为了观点尽量客观，花钱买了《三联生活周刊》，怀着平静的心看了30分钟，在放大缩小和移动过程中认真阅读， 最后实在是生理上受不了了，头昏眼花。群众的评价也从侧面说明了读览天下模式的短命，它只获得了2星。具体看这里。

如果说电子杂志可以借iPad这样的移动阅读终端来转世，那僵尸们扫描卖钱，大力鼓吹跨平台，忽视用户阅读体验的做法，肯定会在不久的将来再次将自己送入坟墓。

关于电子杂志的转世，我们必须搞清楚它的生命力是什么。

一、内容

对《三联生活周刊》这样的品牌杂志来说，内容是第一生命力。他们有强大的稀缺内容生产能力，包括独家专访，深度报道，连载专栏等。这些内容的价值是恒定的，并不因媒介的不同而有差异。

内容的质量，不仅跟文字和图片有关，排版也是关键因素。网媒跟杂志在信息展现上的重要区别，就是排版。网媒的传播速度快，是以损失排版质量为代价的。同样，杂志每周一期，或者每月一期，在损失速度的同时，换得的是专业质量的排版。

对内容消费者来说，他们选择电子杂志的逻辑是：网站上的内容太多太散，电子杂志阅读起来舒服，漂亮。如果电子杂志的质量违背了这一点，他一定选择网站。

所以，精美排版的内容，永远都是电子杂志的第一生命力。

二、用户

iPad等移动阅读终端的出现，给杂志创造了一个他们梦寐以求的第二生命力，用户。

要知道，杂志业从诞生起，就只有订户，没有用户。他们的尴尬在于，不管你内容做的多么好，都必须付出高昂的印刷成本，才能接触到订户，而且这种接触还是单向的。

在移动阅读时代，他们终于可以以零边际成本的方式，把有价值的内容直接送到用户手中，与用户互动，投放效果更棒的多媒体广告，甚至在杂志内嵌电子商务模块，让用户在看杂志的时候下订单。

对于用户来说，选择电子杂志，在携带和收藏方面的便捷优势显而易见，而且，还有可能价格更便宜。

三、速度

杂志业，在业务模式上，跟建筑业没有太大的差别，属于最传统的方式。对于移动终端上的内容发行方式，他们必须通过技术团队来实现。要么外包，要么自建团队。这两种方式的各有优缺点，但最大的缺点是速度。当你的杂志决定要发行电子版时，下属汇报给你的周期起码是不会少于三个月，这还不包括后续功能升级的时间。

很多杂志正是因为技术条件的限制，才急功近利的把内容授权给僵尸们贩卖，在看到可怜的销售成绩后，又被吓的裹步不前。

在我看来，在未来，没有电子版的杂志，就像现在没有网站的报媒一样，会像熊猫一样成为稀缺动物。

内容和用户，是电子杂志业转世的核心生命力。做好这两点，需要杂志业以挑剔的思维和态度来对待用户的阅读体验，就像互联网企业对待他们网站或者软件的用户体验一样。

目前，这两点做的最好的是周末画报(iweekly)和第一财经周刊(CBN)。他们愿意针对iPad这样的移动阅读设备，把杂志内容重新排版，提供从内涵到外延都堪称精美的内容。同时，提供专业的app设计，让用户的阅读成为享受而不是负担。

在速度上，问题的症结在于缺乏工具。杂志业的出版工具已经电子化了，但针对iPad等移动阅读终端的制作工具却是空白。昨天看到Adobe推出了电子出版的解决方案（Beta），以InDesign插件的形式解决多媒体出版的工具支持问题。但是，它沿袭了美国大公司的一贯作风，庞大而复杂。

我们在出版牛壹周过程中的体会，促使我们推出了百家自助出版平台，希望能够给中国的杂志业带来新的选择。目前正在赶工的Web版本，已经能够实现页面跳转，外部链接，图片，音乐和视频交互，预计下周会向内测用户开放。

另外，透露一下，我们的终极目标，用户不用写一行代码，就可以用iPad直接制作和Time，Wired同等质量的电子杂志，敬请期待。

我们希望能够帮助杂志业克服技术的障碍，光荣的实现转世，就像Discuz帮助广大站长脱离技术开发一样。

上一篇文章“小鸡快跑发布啦”曾经提到要揭秘一些《小鸡快跑》系列设计过程中我们的想法和心得，介于《小鸡快跑》1.1也已经正式上架，下面就来谈一谈我们几个设计中细节吧。

1. 关于iPhone4与iPad与404错误

很多用户发表质疑，我们为什么仅仅支持iPhone4而不是所有的iPhone平台？一方面，由于机器性能的限制，我们做过测试后发现，普通iPhone在运行《小鸡快跑》时，动画的表现效果并不能达到100%的完美，会出现很多由于性能所产生的瑕疵；另一方面，更重要的是，虽然iPhone3gs和itouch不会受限于机器性能，但由于iPhone和iTouch的屏幕分辨率是480×320，在画面细节表现力上要远低于iPad和支持Retina屏幕的iPhone4。为了让用户有最佳的产品体验；为了保证为《小鸡快跑》的用户，其用户体验不会由于机型限制而大打折扣，我们决定暂时不支持除了iPhone4，iTouch4和iPad之外的平台。

那我们又如何能给用户传达我们的信息呢？相信，在App Store中下载app的用户并不会仔细阅读app顶部的说明文字，那我们就必须在产品内部给用户以提示。其作用就好比是Web中常见的404错误，只不过，Web上提示的是”page cannot be found”，而《小鸡快跑》中，则应该提示不支持该机型。

说到错误提示，在app中最常见的是什么？你一定想到了，是弹出式的警告框。然而，警告框的体验效果类似于Web上太多千篇一律的404页面，不免会让用户产 生一种紧张感。我们知道，404错误页面是网站相当重要的一个页面，也是一个站点中经常被忽略的部分。一个好的404错误页面能够建立起站点与用户之间的 信任，能够吸引那些初次访问错误页面的访问者，使之成为站点的读者，甚至忠实订阅者。同样，在app中，一个好的错误提示方式，能够缓和用户遇见错误之后 的紧张心理，最大限度的改善用户的体验。

常见的404错误页面与app的弹出框

百家平台的创意404——maklu童鞋 is 囧ing~

于是，我们给出如下设计，如果您不是iPhone4与iPad的用户，您会遇见这个精美设计的，还伴随着背景音乐的画面。是不是有点“植物大战僵尸”的影子呢:)

《小鸡快跑》给非iPhone4和iPad用户的错误提示

2. 关于导航模式

不论在Web还是电子书中，导航都是核心的一个部分。在传统的有声读物中，我们常常能够见到“手动翻页”与“自动翻页”的选项。然而，这种区分是否绝对有必要，尤其是在交互极其丰富的《小鸡快跑》动画书中呢？

我们分析用户阅读时具体的场景：当用户端着iPad阅读时 ，他更倾向于看故事而非交互与娱乐；当用户开始尝试触摸屏幕，他会更倾向于交互娱乐而非阅读。于是我们将用户阅读动画书分为了两个状态：“阅读”和“玩”。在不做任何交互的情况下，系统判断用户处于阅读中，动画书自动进入“自动翻页”的状态。而在用户尝试交互的情形下，则app自动进入“手动翻页”的状态，直至翻到下一页之后，又会自动回到“自动翻页”的状态下。于是，我们就解决了导航时还需选择“手动翻页”和“自动翻页”的问题。

因此，我们的导航页的设计也就更为简洁：

改进前与改进后的导航页

如果你观察的足够仔细，你也会发现，在改进后的导航页上，中英文选项上的男孩女孩也会因语言状态的不同而有着不同姿势:)

3. 关于下载

在《小鸡快跑》1.0版本中，书架页拥有令人impresive的画面和动画。但是，下载进度条和提示组件采用的是Apple自带的默认组件，在可爱的儿童画风中难免不是一种瑕疵。另外，由于动画书的文件比较大，根据爱爷爷相对论的原理，我们可以推断出，在长时间的下载过程中，如果有令人眼前一亮下载提示，则有助于缓和用户感官上的等待时间。于是，在1.1版本release之前，我们花了很多时间思考如何改善下载过程中的体验，最终，1.1版本中便产生了这个方案：一只向前爬行，走着太空步的可爱的小蚂蚁。我们希望，他给您在下载等待过程中带来的感觉，能够类似于“冰河世纪”片头片尾中的那只小松鼠，给您的下载体验带来惊喜。

1.0版与1.1版下载进度条

其实，正如我们以前说过的，我们并不是那种“关在地下室，悄悄地筹划一项颠覆世界的举动的团队（即便是在筹划颠覆世界，我们也会乐于并敢于和大家分享我们的看法）”。所以，我们设计过程中的心得，都很愿意和您分享。您可以follow我们的twitter与新浪微博：@mycolorway。如果您想给我们拍转，也欢迎来信：team+ipad@mycolorway.com。

如果你对小鸡叫叫感兴趣，可以在iTunes下载小鸡快跑1.1。如果您想成为《小鸡快跑》的beta tester，也欢迎将给我们来信，并附上您的iPad或iPhone4的UUID号。您可以提前享受到尚未上架的动画书以及给我们拍砖的权利，而我们也很乐意听取您的意见和建议。