选择就是一种创作

几年前,和一个资深的设计师朋友聊天,我拿出我们团队做的一个设计图,请她做点评。我一边向她演示,一边抱怨说:你看这些个元素,都是从网上找的…… 她听出了我的言外之意,跟我解释说:这个设计做的不错,网上有那么多素材,能够找到合适的素材并做出加工让它们变成一个好的设计,就是设计师能力的体现。

在那之前,我认为设计就应该是原创,当然可以参考别人的作品,但把各处找的“别人的”东西拼凑在一起,总觉得有投机取巧之嫌,不是真正的“实力”。自从上面那个朋友跟我讲了那些话之后,我不时会回想起来,渐渐我开始转变看法,我开始相信:选择就是一种创作。并且,这是一种比我之前所理解的“创作”更高级的能力。

这种创作来自于选择的过程

以UI视觉设计为例,目前网络上有无数的素材、模板和案例,采用“拿来主义”看起来毫不费力,然而,在如此众多的选择中,找到适合自己产品的风格,找到风格统一的素材,并不是一件容易的事。这需要设计师对产品的定位和情感表达有深刻的理解,也需要设计师独具慧眼能从茫茫大海中找到那个最适合的素材,尤其是很多时候各种素材都需要深度加工,就更要求设计师能从“素颜”中看出“写真”后的效果。在这个过程中,设计师所付出的心血,甚至要超过直接去“制作”一些明确的素材。

选择是一种更高级的创作

直觉上,从网上去找一个图片来用,和自己手工制作一个图片,似乎后者看起来更“牛”一些。而实际情况却未必如此。在动手“制作”的过程中,操作者思考的重点是“如何制作”,怎样通过一系列的动作来达成目标。实际上,这是一个技术过程,对于经验丰富的人来说,动手的过程是轻车熟路的,甚至不需要怎么思考,下意识就能完成大部分过程。而对于从网上去找这样一个“选择”的过程,操作者的思考重点就不再是“如何制作”,而是去判断某个图片是否合适,操作者脑子里会有一个“理想图片”,会将看到的内容和这个“理想图片”做对比,计算它们的差距,有时候,还要去思考当前的图片经过如何加工才能满足需求。

这样看来,这是两种完全不同的思维模式。选择解决的是“What”的问题,而制作解决的是“How”的问题。一般来说,What的问题,对于一个事情往往起着决定性的作用。

选择是创作的未来

上面举的都是视觉设计的例子,下面再来看个程序猿的例子。在程序猿文化中,有个说法叫做“不要重复发明轮子”,意思是你想实现的功能很可能已经有很多人实现过了,很可能会比你实现的还好,所以你不要再自己重新发明一次,直接用前人的成果就好了。“不要重复发明轮子”这个理念已经被广为接受了,目前网络上各种很好的“轮子”也越来越多,当“轮子”多到一定程度,选择用哪个“轮子”就变得不那么容易了。

现在,“轮子”正变得越来越多,这似乎在引起一个质变:程序猿的主要工作已经从创作代码变成了“选择轮子”!其实,目前我们也在某种程度上这样做了,任何一个项目,基本都要选择1~2个框架,然后再选择若干个第三方库,还要选择一些设计模式将它们组织起来…… 我们实际写的“有效的”代码,一般来说都不到一半。这个比例在未来应该会逐步降低。程序猿的主要精力,会用在选择框架和类库上,而实现具体的功能,会变成相对低级的工作。

对于设计类的工作来说,看起来也没神马不同。网络上的资源已经多到不需要我们再去“创作”,各种强大的工具的发展,也让”制作“过程变得更为简单,设计师的主要工作也将通过做“选择”来完成。“选择”会变成新的“创作”模式,而“创作”(制作)将会变成一种廉价劳动逐步退出历史舞台。

 

程序员最要学好的语言是什么

程序员最要学好的语言是什么?多年前我的回答是C语言,因为C语言很接近机器的执行方式,又不像汇编那样枯燥和繁琐。而现在,对这个问题,我有了不同的答案。

程序员最需要学好的语言是:英语

在程序员的世界里,几乎所有的技术都是来自英语国家,特别是美国。在学习新技术的时候,技术文档和书籍一定是英文先出来,等着翻译版出来,某些细节可能已经改版了。而且读翻译的质量取决于译者的水平,国内真正高水平的译者就那么几个,相对整个技术领域来说,能翻译好的内容简直是九牛一毛。目前市面上的很多技术翻译作品都很烂,甚至会误导你的思路。

在实际工作中需要解决问题时,搜索和社区是少不了的。而Web上的技术内容,绝大多数也都是英语,著名的程序员社区 StackOverflow 、 GitHub 等几乎是全英文的。你真的想用百度来解决一个技术问题吗,搜一个问题可能出来十几个相关的结果,点进去一看,都是同一个转载的。你在 CSDN 问一个问题,很快就得到了10个回答,其中9个是顶,另一个是“同求”。中文的Web内容在解决技术问题上很难真正帮到你(倒是很可能找到一段不明来历的代码copy下来,但你依然不知道为什么)。想真正解决问题,就要来到英语世界。

对一个程序员来说,英语水平会严重影响你学习技术的速度和解决问题的能力。所以,英语是程序员最需要学好的语言。

程序员第二要学好的语言是:汉语

这个还用说,汉语谁不会?可是你真的学好汉语了吗?你有没有遇到过类似的情形?

  • 直到开始写代码了,才开始后悔,我为什么会答应产品经理这么傻X的需求?
  • 这个老板真是太弱了,无论我怎么说他都不明白,这玩意是无法实现的
  • 那个傻X就是会忽悠,什么都不干,还升职这么快,世界太不公平了

在工作中,我们交流和沟通主要还都是用汉语,你有没有想过上面这些其实这都是因为你汉语不好造成的?你是否真正读懂和听懂了产品经理的需求?你能否把一个技术问题清楚的描述给非技术人员让他们轻松理解?你能否理解到真正的问题所在而提出一个非技术的解决方案让上司听懂还能避免自己苦逼的码代码?所有这些,其实都是沟通问题,而沟通问题,对我们来说,就是汉语的能力,理解汉语和用汉语表达的能力。

在程序员的职业发展道路上,从普通的工程师,到项目经理,到技术总监,到架构师,到CTO,对沟通能力的要求越来越高。沟通能力,或者说汉语能力,在很大程度上限制了一个程序员的职业发展。

可以说,英语决定了一个程序员学习技术的深度,汉语决定了一个程序员职业发展的高度。现在你是否也认为英语和汉语是程序员最应该学好的语言了 :- )

《Understanding Comics》——产品经理必读

小时候比较喜欢看漫画书,而这是一本关于漫画的漫画,读了之后,才发现这是一本关于认知心理学的”正儿八经”的书。

我之所以在标题中加入“产品经理必读”字样,是因为:

  • 我做标题党了,也许这样能带来更多点击
  • 本书在对漫画表达和理解过程的分析中,也分析了人类对不同媒体的认知过程和特点。这对数字化产品设计,会有很大的帮助。
  • 本书剖析的漫画创作的六个步骤,也是产品研发的六个层面。

认知分析

有一张图,见过不少产品经理引用:

enter image description here

哈哈,是不是也见过!原来这个图就是来自于这本书?

书中用这张图来解释“卡通化”的过程:逐步去掉各种细节,从而让核心概念变得更加清晰。这也是卡通吸引人的地方,让我们直接感受核心的概念和情感,而不是像观察现实那样,通过大脑的处理,从各种细节中整理和归纳出核心概念来。

产品经理经常用这张图来描述用户范围:最左侧是一个具体的人,从左到右,抽象层度越来越高,所能代表的人群范围也越来越大(一个男人->一群长相类似的男人->某个地区或民族的男人->男人->人)

这个图体现出来的认知特性,还可以用来说明线框图的重要性。在产品设计过程中,线框图把颜色、字体、图片等一些细节简化掉,只表现最核心的产品功能和操作过程。线框图不仅是为了简单,更是为了放大其表现,通过对线框图的讨论和分析,就能比较容易的发现产品设计的问题和不足。

在以前做项目过程中,有人提出这样的观点,在产品设计文档中把大概的颜色和图片都加进来,尽可能的接近最终的产品,这样不是更好吗?当时只是感觉怪怪的,但一时没有发现理论上的错误之处。其实,在设计产品的功能和交互过程中,线框要比带有颜色和图片的“示意图”好很多,像上面说的,线框更突出产品的功能核心,免除不必要干扰,从而更容易发现问题。颜色带来的冲击过于强烈,大脑要努力抗衡颜色带来的冲击,才能看清楚本质,也就是说,有颜色的情况下,更难看清楚产品功能和交互表达的本质。像书中说的,漫画也是这样,多数漫画都是黑白的,不仅是因为彩色漫画成本高,也因是因为颜色有时候反而消弱了漫画自身的表达能力。

创作步骤

书中关于漫画的六个步骤(或者说六个层次),也是关于艺术创作和产品研发的六个层面。这让我们更能清楚的理解:为什么有些巨资投入的画面超炫的3D大片看起来依然空洞无物,反而不如一些小成本故事片那样直指心灵;为什么多次越来越炫的界面改版依然无法挽救一个网站,而有些明显跟时代不符的简陋到连图片都没有的页面却能让我们流连忘返;为什么一款画面粗糙没有音效的卡牌游戏,可以狂卷数十亿美金,而不少聚光灯下出身名门的游戏大作,只有在我们多年后搬家时才发现它在一个被遗忘的角落里落满了灰尘…

书中提到的漫画创作六个步骤(层次)是:
1. 点子(IDEA/PURPOSE)
2. 形式 (FORM)
3. 风格(IDIOM)
4. 结构(STRUCTURE)
5. 工艺(CRAFT)
6. 外表(SURFACE)

我们来向数字产品研发过程做个类比:
1. 点子(IDEA/PURPOSE):点子还是点子,很多人每天都会有很多点子冒出来,但大多数人止步于此了。
2. 形式 (FORM):实现一个点子,需要做什么类型的产品?是做一个网站?还是做一个手机App?还是做一个微信公众号就够了?
3. 风格(IDIOM) 这一点我觉得在产品中,可以对应到一个流行的词——“情怀”。这个词有点大,目前行业中也看不到多少“情怀”,可能在这个互联网初级阶段,还没有多少产品能到达这里。
4. 结构(STRUCTURE)这个应该是行业中狭义的“产品”,也就是产品设计:产品的核心功能是什么,通过什么样的形式来表达这个核心功能?产品需要设计哪些特性,各个不同特性之间的关系是怎么样的?什么方面应该强化,什么方面应该弱化?产品应该怎么样发展和变化,等各种设计问题。
5. 工艺(CRAFT),产品研发中,就是“技术”,通俗说就是编程了。从这个层次也可以看到,技术对产品来说,是相对表层的部分,对产品的影响力有限。
6. 外表(SURFACE),数字产品中,就是“界面(UI)”。这个层次中所指的UI,是比较狭义的UI,指界面的视觉效果等。例如:扁平化啦,毛玻璃效果啦,阴影啦 等等。在实际中,界面往往和交互紧密相连,而交互一般都带有产品设计思路,属于层次4的内容。这部分是最容易做到的,但对于产品来说,影响是比较小的。

这六个步骤,像书中说的,实际的发生顺序是 1,2,6,5,4,3 ,对比下数字化产品,多数产品能做到5,能把4做好的,就是比较成功的产品了,而做到3的还很少。

看来这真是一本产品经理必读的漫画哎。

最后,我非常喜欢书中对艺术一词的解释 :)

Art, as I see it, is any human activity which doesn’t grow out of either of our species’ two basic instincts: survival and reproduction!

《YC 创业营》

最早知道YC(Y Combinator),是在09年,当时我们计划做一个基于地理位置的社交App,当时我们研究一个已有的类似应用,这个应用叫Loopt . 于是,我们知道了 Y Combinator 这个著名的孵化器,也知道了硅谷的创业教父 Paul Graham. 那时候,我才发现,原来自己一直使用的 Dropbox,也是从YC孵化出来的,还有著名的 reddit,也是YC的项目。同样09年,李开复创建创新工场,认为是参考YC模式。YC在国内逐步被广为了解。

11年,我一直订阅的“阮一峰的网络日志”作者阮一峰翻译了 Paul Graham 的文集《黑客与画家》。在国内程序员圈内立即流行开来,这本书让我对这位创业教父充满敬仰。

《黑客与画家》让我大快朵颐,可惜当时并没有看到YC更为充分的描述,近日闲暇,怀着对硅谷创业教父 Paul Graham 不减的敬仰,读了下《YC 创业营》

这本书很单纯的记录了 YC 某一期的创业学员的学习过程,没有多少理论和观点。然而每一个鲜活的创业故事还是会让有类似经历的创业者感到共鸣。在目前铺天盖地的创业“神话”的狂轰滥炸下,这种真实的记录显得更有价值。

很多所谓的创业者,是听着无数的创业“神话”或长大的。社会用这些神话来鼓励人们创业,投资人用这些神话来诱惑人们创业,人们都喜欢听“神话”,”神话”总是会让人热血沸腾跃跃欲试。好听的神话,多数是在创业成功之后整理出来的故事,而和这位成功的创业者同时开始创业的另外99位失败的创业者,就成了沉默的证据,没有人为他们写故事。

《YC 创业营》做到了这一点,它在这些创业者刚刚开始的时候,就开始记录他们的故事,没有人知道他们当中谁会成为下一个Google或Facebook。这种纪实看起来似乎有些枯燥,缺少传奇色彩,缺少振奋人心,但这才是真实的创业,真实的生活,不是吗?

在2010年冬季项目中得到 YC 资助的独立创业者 Chad Etzel 在离开 YC 一年后写了一篇文章,讲述了自己的后 YC 经历, 题为《Startups Are Hard》。他说,他是在那些让人以为“任何人都可以在一念之间动起创业想法,然后不出几天就能在来自天使/风投的钞票的海洋中遨游”的阳光故事中,给人看一点现实的写照。

这篇 “Startups Are Hard” 我也找了一下,在这里 http://blog.jazzychad.net/2011/05/02/startups-are-hard.html

Markdown 编辑器 Mou 和 StackEdit

去年初,我开始用 Markdown 写 blog (Markdown 是什么和我为什么用 Markdown). 我使用过很多Markdown编辑器,到目前为止,我使用最多和最喜欢的还是 Mou (http://25.io/mou/

Mou 是一个国产独立软件,最早是天津程序员 Chen Luo 的个人业余项目。随着 Mac 和 Markdown 的普及,Mou 也得到了更多人的喜爱,三年间,Mou积累了30多万用户。去年底, Chen Luo 完成了一个众筹 (https://www.indiegogo.com/projects/mou-1-0-markdown-editor-on-os-x-for-you),建立了正式的团队来全职进行 Mou 的开发,其中,知乎和 Coding.net 是这个众筹中出资最多的,分别为 $5000.

最近,我又发现一个很好用的 Markdown 编辑器,StackEdit(https://stackedit.io/),这是一个在线的编辑器(当然,也可以在浏览器中离线操作)。作为一个浏览器中的编辑器,StackEdit 的用户体验也基本到了极致,和原生的App已经差别很小。另外,StackEdit 是真正Web思维的编辑器,所有的操作都是Web:内容保存在Web上,可以“另存为”到GoogleDrive,Dropbox等,其中,我最喜欢的功能是可以直接发布到我的 wordpress 。

StackEdit 使用了一个叫做 MonetizeJS(https://monetizejs.com/) 的支付服务,这个服务让开发者可以不用做服务器端集成就实现支付功能,看起来非常不错,这个思路很让人喜欢。

扯远点,09 年的时候,我写过一篇 blog 开放的WEB才精彩,那个时候,我觉得真正的开放式Web已经初具雏形,一个充分互通互联的web即将形成,全新的开发思路和软件使用模式马上就会逐步建立,展现在大家面前的,将是一个全新的时代。

然而,5年过去了,我的“预言“似乎还没有完全应验。要知道,在互联网的世界,5年就是一个时代。一个时代都过去了,还没有应验的”预言“,那不是很愚蠢吗?

我没有预期到的,正是目前所有人都知道的,这5年,或者这个互联网时代发生的事情——移动互联网。没错,就是这个移动互联网,它如此的火爆,以至于吸引了所有人的眼球,绝大多数的资源和程序员(包括我自己),都被吸引到了移动互联网上来,创造了这次让所有人都震惊的移动互联的革命。这5年里,移动互联网发生了太多的故事,几乎所有的聚光灯都投降了移动互联网。然而那个造就和孕育了移动互联网的传统互联网,似乎在不经意间被冷落了,5年来,传统互联网的发展真是超级缓慢,几乎所有传统互联网服务在这5年内做的,就是占据移动端,发展app。新诞生的互联网服务,多数也是围绕移动端,为移动开发生态圈服务。因此,对于传统互联网来说,虽然一个时代过去了,但并没有得到应有的发展。

很无耻的解释了自己的愚蠢,脸皮又厚了一层,更像个创业者了。

扯这些,主要是试试这个编辑器,来吧,发布下看看。

Written with StackEdit.