《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.

Shellshock 再次震惊全球

我们都是人性这部巨大躯体之中的细胞

这两天,Linux 又爆出了一个非常严重的漏洞 —— Shellshock (CVE-2014-6271)。 之所以用“又”,是因为就在今年 4 月,Linux 才刚刚爆出了 openssl 的“心沥”漏洞 ( 关于 Heartbleed(心沥) 漏洞 ),想必大家还心有余悸。

这个漏洞是由 Linux 上广泛使用 Bash shell 引起的,因此称为“Shellshock”,不知道是不是可以译为“壳震”,也有中文报道翻译为“破壳”和“壳裂”。

Shell Shock 一词,还有一个意思是“战争后遗症”或“弹震症”。一般指那些参加过战争的士兵,在经历过战争的精神和身体的折磨回到和平之后,还会经常出现的紧张、恐惧、失眠、疼痛等症状,严重的甚至出现无法自控的情况。

漏洞原理

这个漏洞的原理依然很简单,一句话就可以说明:Bash 在处理环境变量的时候,对其中函数定义后的内容,会继续作为代码来执行。例如:

$ env var='() { ignore this;}; echo vulnerable' bash -c /bin/true  

这个漏洞看起来还是很低级,但是比起前面的“心沥” 来说,还是要好一些,造成“心沥”的,可谓是一个最最低级的代码错误(长度检查)。而这里,应该是逻辑上没有考虑严谨。

小心余震!

早先的关于这个漏洞的修复,并没有完全修复完整,又引入了另一个漏洞 (CVE-2014-7169), 被称为 “Aftershock” ,也就是“余震”。

Mac OS 未能幸免

OS X 使用的 shell 是bash的变种,也带有同样的漏洞。可以使用如下的代码来测试改漏洞是否已经修复:

$ env x='() { :;}; echo vulnerable' bash -c 'echo hello'

如果shell输出了 vulnerable,那么,你的系统还是带有漏洞的。如果没有,也不要高兴太早,因为还有可能有“余震”。

关于余震漏洞的测试和漏洞修复参见 http://apple.stackexchange.com/questions/146849/how-do-i-recompile-bash-to-avoid-shellshock-the-remote-exploit-cve-2014-6271-an/146851#146851

Windows 逃过一劫

就想逃过上次 “心沥” 一样,Windows 又逃过了 “壳震”。Windows 做的更安全吗?不是,只不过 Windows 没有使用 linux 上被广泛使用的技术而已。如果你认为更多的不被广泛知道的漏洞会更安全,那这样说的话,Windows 更安全。

互联网还靠得住吗

今年接连爆出的超级严重的漏洞,让我们不禁感慨:互联网还靠得住吗?

我的态度是:互联网靠不住,但我却愿意依赖它。

作为一个程序员,我可以深刻体会到,软件开发不过就是这样一个过程:后来的程序员修复前面的程序员留下的漏洞,同时又造成新的漏洞,让再后来的程序员来修复,如此循环,无穷尽也。

程序员这么容易出问题,真是很差劲呀。没错,程序员是很容易出问题,但这却不应该责怪程序员。并非为程序员辩护,任何一个职业都是如此。程序员作为普通的人类,无法超越人类自身的局限,人类总是会犯错。而因为互联网的影响之大,程序员犯的一个小错可能带来非常严重的后果。这就像,驾驶员的错误会引起车祸,飞机机长的错误会让数百人丧命,而一个国家元首如果犯个错误,后果可能是数百万人的生命。

我们通过提高汽车性能和智能来减少和避免驾驶员的犯错;我们通过增加副机长、自动驾驶、地面控制等方式来减少机长的犯错;我们通过智囊、增加流程和议会等方式来减少一个国家元首的犯错。但是,在软件开发中,对于程序员的犯错,尤其是会产生严重影响的软件的程序员的犯错,我们做的还非常原始。

只有我们更多的关注互联网,更关注程序开发工作,让关键的程序有更多的人来审查和测试,才有可能降低出现错误的概率。但如同其他所有的行业一样,错误和事故却不可能完全杜绝。希望最近这些不断爆出的安全漏洞,能让我们更加严肃的看待软件开发。

参考资料

Git Flow 和那些 Git Workflows

好的工具,可以改变我们的思维方式

什么是 Git Flow

2010 年初,荷兰的程序员 Vincent Driessen 在他自己的博客 http://nvie.com/ 发表了一篇文章 《A successful Git branching model》 ,在开源世界引起了一阵不小的关于 Git 工作流程的讨论,这篇文章里提出的 Git Flow 也成为了很多软件开发的事实标准。

Git Flow 就是 Vincent Driessen 在使用 Git 的过程中总结出来的一套工作流程(一种 Git Workflow)。这套流程非常适合互联网项目开发,这个流程约定了一些 Git 使用方法,让开发者可以井井有条地组织 Git 的 commit 和 branch 等操作,方便地完成项目的开发、测试、发布等环节。

几年来,这个流程已经成为业界的事实标准,关于它的介绍到处可见,在此只对其中几个要点做摘要:

  • master 分支只做发布
  • 每一个特性开一个 feature 分支(或者叫做 topic 分支)
  • feature 分支来自 developer 分支,也将被合并到 developer 分支
  • release 分支来之 developer 分支,将被合并到 master 分支 (或合并回developer分支)
  • 修改线上bug时,从 master 分支开一个 hotfix 分支,将被合并回 master 分支

事实上,Git Flow 并不能算是个非常简单的工作流程,其每一步的操作,都需要若干个 Git 命令来完成。 作为一个自称 “tech enthusiast who breathes code and loves creating beautiful software” 的极客,Vincent Driessen 当然不能容忍这种机械且易错的流程,很自然地,他开发了一个 Git Flow 工具 gitflow

gitflow 提供一系列抽象层次更高的命令,来更快捷的完成 Git Flow , 例如:

  • git flow feature start [] // 开始一个特性的开发
  • git flow feature finish // 完成一个特性的开发
  • git flow release start // 开始一次 release
  • git flow release finish // 完成一次 release
  • git flow hotfix start // 开始一个线上bug修复
  • git flow hotfix finish // 完成一个线上bug修复

这些高层的命令调用了 git 的分支操作来实现其目的,让整个流程更加便捷,也减少了错误的产生。

有人说 Git Flow 的一个缺点就是需要用命令操作,多数图形界面还是要手工操作 git 命令。也许曾经是这样,但是大名鼎鼎的 Git 图形界面工具 SourceTree 早已经官方支持 Git Flow 了,这也可以证明 Git Flow 是一个已经被广大开发者所熟悉和接受的工作流。

说了半天,Git Flow 到底有什么好处,这个嘛,谁用谁知道。

其他的 Git Workflows

既然 Git Flow 只是一种 Git Workflow,这么说,还有其他的 Git Workflows 咯?

GitHub Flow

这个是 GitHub 自己使用的流程,也就是他们开发 github.com 使用的流程,而不是这些开源项目使用 GitHub 的流程,哈哈。
也许是他们认为 GitFlow 太复杂,更可能的是因为 GitHub 早于 Git Flow 诞生,所以 GitHub Flow 是一个非常简单的流程,大致的要点如下:

  • master 上任何一个 commit 都应该是可部署的
  • 要做改动,从 master 开一个新分支
  • 改动完成,开一个 pull request
  • 某个负责人确认了改动之后,就可以将其合并到 master 了
  • 合并到 master 之后,应该被立即部署

这个流程简单到吓人,GitHub 大概有 15 到 20 人在同一个项目(github.com)上使用这个流程,每天,他们可以完成数十次部署。

这个流程简单的让人流口水。然而,只有内功达到一定程度的高手,才能使用最简单的兵器御敌制胜。“飞花落叶皆可杀人”,可不是人人都能做到的,口水先咽到肚子里吧,盲目跟随,小心死得很难看呀.

Centralized Workflow

集中式工作流程 (https://www.atlassian.com/git/workflows#!workflow-centralized) 实际上,这就是 svn 使用的工作流程,大家在同一个集中管理的仓库上开发,各自在更新的时候负责解决冲突。是的,我们在 svn 时代一直使用这种工作流程,现在看来,是不是很难忍受了?

Feature Branch Workflow

https://www.atlassian.com/git/workflows#!workflow-feature-branch
这个工作流程已经很接近 GitFlow 了,或者说,它是个简化的 GitFlow,只是强调了 feature branch,没有 developer 和 release, hotfix 等分支概念,它和前面提到的 GitHub Flow 也很类似。

Forking Workflow

https://www.atlassian.com/git/workflows#!workflow-forking
这是一个基于多个代码仓库的工作流,每个开发者在自己的仓库上进行开发和提交,然后在不同仓库直接进行合并。在自己的仓库中,又可以按照独立的分支管理方式(工作流程)来进行开发,最后,向上游管理者发起 pull request 来进行合并。GitHub 上的大多数开源项目都用了这个工作流程。

更多 Git Workflows …

小结

为什么在 svn 时代,没有产生这么丰富的工作流程? svn 也有 branch 的概念,为什么大家没有像用 Git 这样来用 svn?

svn 里的分支,并不是 svn 本身的概念,而是用户使用svn时候的“约定”,也就是说,“分支”对于svn来说,就是一种工作流程,“分支”所在的抽象层次,相比 svn 提供的抽象层次,已经高出了一级。

对于一个工具来说,在用户熟练使用后,一般可以衍生出一些使用“文化”,也就是一些约定的”惯用法“或“工作流程”,然而这些“文化”一般只比工具提供的抽象层次高一个层次,也就是说,这些“文化”是可以通过工具提供的基础功能进行重复、组合等方式来实现的。

svn 里的“分支”,就是利用svn基本的目录功能来实现的,并不是 svn 直接提供的,因此,它是在比svn 抽象层次更高一级的层次上的。而本文提到的 git 的丰富的工作流程,多数是由“分支”这个概念衍生出来的,对于 svn 来说,这种工作流程已经是高于其两个抽象层次的逻辑,对于人类这种生物来说,可能确实比较困难。

而 git 中,有了 branch 等更多的基本概念,使用 git 完成各种工作流程,还是仅仅提高了一个抽象层次而已,对人类来说没有障碍,所以各种流程百家争鸣。git 不过是比 svn 提高了一个抽象层次,却给开发者带来了更广阔的天空。

乘法确实就是加法的叠加,但从这种运算中涌现出了新的力量,如果我们只把乘法看成是加法的重复,就永远不可能掌握这种力量,只满足于加法,就永远得不到 E=mc^2
— Kevin Kelly

参考资料

  1. http://nvie.com/posts/a-successful-git-branching-model/
  2. http://www.syntevo.com/smartgit/documentation/6/show?page=git-flow
  3. http://www.jiangyouxin.net/
  4. 基于git的源代码管理模型——git flow
  5. git flow的简单使用
  6. https://guides.github.com/introduction/flow/index.html
  7. http://scottchacon.com/2011/08/31/github-flow.html
  8. http://blog.endpoint.com/2014/05/git-workflows-that-work.html

无觅相关文章插件,快速提升流量