科学、科普、设计

科学松鼠会是一个不错的网站,我偶尔上去取取经。最近上面看到了一篇文章,说的是连岳为松鼠会的书写了一篇序,引发了无数争论。我不认识连岳,只知道“问连岳”。对方舟子也不了解,只知道“学术打假”。且不说这些争论,但从连岳的这篇序中,我看到了一些东西。

先摘录两段话:

优秀的科学家说得最多的一句话是“这个问题,我不知道。”科学的进步使人谦卑,科普作者,应该也把谦卑放在第一位,因为他们最知道,在自己身后,其实有海量的更内行的专业人士,只不过,他们没有写文章罢了。

随便抓一个弱势者,你都能从他身上发现诸多不文明、没科学的印迹,用科普的名义暴打一顿,又轻松又愉快,每次都能技术性击倒。但是这种文章你多写几篇,读者就抛弃你,因为他觉得你不过是借了几个科学术语自大而已,你其实并不在乎他缺乏科学知识的痛苦,你甚至希望以他无知的丑陋来衬托出你英俊的科学脸庞。

我要谈的是设计。我担心设计师们(包括 UCDChina 的设计师们,包括我自己)成为这样一种强势群体,以 UCD 的名义把弱势者技术性击倒。有一个很要好的朋友,就曾直接的告诉我:你写文章的语气我很不喜欢。

后来我就慢慢的写的少了,一方面是多实践多思考,另一方面是怕受到鄙视。为什么呢?我后来发现,想清楚了,那些设计的不太好的网站,真的是他们没有能力去设计好吗?不是的,网站是一个很庞大的系统,公司业务、管理、开发,都是很复杂的系统,凭什么我不是他们中的一员,却能够对他们指手画脚呢?我真的了解到事件的来龙去脉了吗?要知道,即使说了一堆似乎可信的原因,仍不能证明XX的设计就是不好。设计的真理太少了。

我对部门的设计师说,除了往前看,还要往后看。每一个设计师都觉得自己的想法是黑夜中的启明星,能拯救世界,或许没错,但是有没有想过为什么之前没去做呢?前人真的是没有自己聪明,没有想到?我相信不是,而是因为当时资源、条件的局限,评估后的结果。

对事物的认识往往是呈螺旋式上升的过程。俯瞰时,似乎全都是A,在一个点上,但从侧面看时,是A1、A2、A3…这个过程是随着发展上升的。当我认为A不对时,我很有可能站在A1的高度上,而实际上对方是站在A2,甚至A3的高度上。

回到设计,说大一点,UCD是一种思想、一种方法论。事实上可以用在所有与人、与使用有关的产品上。从网站到软件,从建筑到装潢,甚至从中药到水库(方同学或许就是掌握了科学的方法)。但是,网站设计师去评论建筑,真的就犹如那什么人看什么一样。交流交流、讨论讨论可以,但勿动了真气,伤了和气。

还是少说多做,不做别说。

查看或发表评论(16) 广而告之:要旅游,找途牛

进行 Web 界面原型设计的一种方法(续)

昨天写到为何XHTML原型会失败?,意犹未尽,再续一篇旧文。

在进行 Web 界面原型设计的一种方法(以下简称MVC/SSI原型法)这篇文章里,漏了一部分,也就是昨天提到的维护或者 CSS/JS 文件共用的问题。其实可以通过下面要讲到的方法,解决一部分。

无论是 XHTML 原型还是程序模板,前端(网页/网站部分)主要包括两大部分:HTML文件和资源文件,其中资源文件又可以分为CSS、JS、背景图(CSS中引用)和内容图(HTML文件中引用)。为了实现可维护、重用,在整个开发过程中,最好的办法是保持一致、只用一个。

以 CakePHP 框架为例(其他框架大同小异),程序渲染用的模板在 /app/views 下,并且分为 layouts、elements 等多个目录。这个分法是很好的,结合MVC/SSI原型法,很利于后期开发。Views 是不能直接查看的,也没有数据内容(样例内容),这一点违背了原型的初衷。应用的根目录是在 /app/webroot 下,为了让原型能够直接给其他协作者查看,可以将原型目录添加在根目录下,比如 /app/webroot/prototype,这样通过 Web 即可以查看。为了让发布版本和原型能够共用 CSS 和 JS 文件(假设目录为 /app/webroot/ui/css 和 /app/webroot/ui/js),需要注意 CSS 和 JS 中的 URL 全部使用绝对路径(不加域名)。

无论是一个人的设计团队,还是多人,都可以将 prototype 目录也加到版本控制中。同时为了使绝对路径能够生效,可以在本地配置 apache(以 PHP 为例,呵呵),比如 local.example.com 访问 /app/webroot/prototype 为原型,www.example.com 访问 /app/webroot 为上线版本。虽然 prototype 不能自动当成 views 用(这有些痴人说梦了),但已经能解决一部分问题了,在某种程度上已经很好维护了。MVC/SSI原型法的优点就是 prototype 目录结构和 […]

一直以来伴随我的一些学习习惯(四):知识结构

自从建立了 TopLanguage 以来,发现在上面待的时间越来越多,与高手讨论问题是个粘性十足的事情,一方面,分享自己的认识是整理不成熟的想法的极好途径,另一方面,互相之间视角不同,所以往往自己忽视的地方会被别人发现。在讨论中不断精化既有的知识体系。以下这段基本上摘抄自(略有整理和添加)在 TopLanguage 上的发言:

抓住不变量

我喜欢把知识分为essential的和non-essential的。对于前者采取提前深入掌握牢靠的办法,对于后者采取待用到的时刻RTM (Read the manual)方法(用本)。

如何区分essential和non-essential的知识想必绝大多数时候大家心里都有数,我举几个例子:对程序员来说,硬件体系结构是essential的,操作系统的一些重要的实现机制是essential的,主流编程范式(OO、FP)是为了满足什么需求出现的(出现是为了解决什么问题),是怎么解决的,自身又引入了哪些新的问题,从而适用哪些场景)。这些我认为都是essential的。我想补充一点的是,并不是说硬件体系结构就要了解到逻辑门、晶体管层面才行(其实要了解到这个层面代价也很小,一两本好书就行了),也并不是说就要通读《Computer Architecture: Quantitative Approach》才行。而是关键要了解那些重要的思想(很长时间不变的东西),而不是很细的技术细节(易变的东西)。《Computer Systems: A Programmer’s Perspective》就是为此目的,针对程序员的需求总结出那些essential knowledge的好书。

再来说一下为什么需要预先牢靠掌握这些essential的知识:

根据Joel Spolsky同学的说法(原文),编程语言技术是对底层设备的封装,然而封装总是会出现漏洞的,于是程序员被迫下到“下水道”当中去解决问题,一旦往下走,漂亮的OO、N层抽象就不复存在了,这时候不具备坚硬的底层知识就会无法解决问题。简而言之就是这些底层知识会无可避免的需要用到,既然肯定会被用到那还是预先掌握的好,否则一来用到的时候再查是来不及的,因为essential的知识也往往正是那些需要较长时间消化掌握的东西,不像Ruby的mixin或closure这种翻一下manual就能掌握的东西。(英语也是这样的essential knowledge——上次在PyCN上看到一个招Python开发人员的帖子将英语列为必备技能,却并不将自然语言处理列为必备技能,正是因为英语不是可以临阵磨枪的东西,而且作为知识的主要载体,任何时候都少不了它,如果不具备英语能力,这个就会成为个人知识结构的短板或瓶颈,而且由于需要长时间才能获得这项能力,所以这个瓶颈将持续很长时间存在。我们曾经在 TopLanguage 上讨论过如何花最少的时间掌握英语)另一方面,在问题解决当中,如果不具备必要的知识,是根本无从思考的,再好的分析能力也并不是每个问题都能分析出该用哪些知识然后再去查手册的,很多时候是在工具和问题之间比较,联想,试探性的拼凑来解决问题;这就使得一个好的既有知识基变得至关重要。(实际上以上这个是一个较大的话题,希望有一天我能够把它详细展开说清:)) 如果你不知道某个工具的存在,遇到问题的时候是很难想到需要使用这么样一个工具的,essential knowldge就是使用最为广泛的工具,编程当中遇到某些问题之后,如果缺乏底层知识,你甚至都不知道需要去补充哪些底层知识才能解决这个问题。 你必须首先熟悉你的工具,才能有效地使用它(须知工具的强是无敌的,但这一切得以“了解你的工具”为前提,甚至得以“了解目前可能有哪些工具适合你的问题”为前提)。一门语言,你必须了解它的适用场景,不适用场景(比如继承能解决你的问题不代表继承就是解决你的问题的最适合的方案,须知问题是一个复杂系统,解决方案总是常常引入新的问题)。你必须了解它支持的主要编程范式,此外你还必须了解它的traps和pitfalls(缺陷和陷阱,如果不知道陷阱的存在,掉进去也不知道怎么掉的。)这些都是essential knowledge,如果不事先掌握,指望用的时候查manual,是很浪费时间的,而且正如第2点所说,正因为你不知道这些知识(如适用场景),从而用sub-optimal的方式使用了一门语言自己可能还不知道(最小白的例子是,如果你不知道语言支持foreach,那么可能每次都要写一个冗长的循环,较常见的例子是不知道有很方便的库设施可以解决手头的问题所以傻乎乎的自己写了一堆代码),因为人的评价标准常常是:只要解决了最醒目的问题并且引入的新问题尚能忍受,就行。注意,熟悉并非指熟悉所有细节,而是那些重要的,或者无法在需要用到的时候按需查找的知识。比如上面提到的:适用场景不适用场景,编程范式,主要语言特性,缺陷和陷阱。

当然,以上作为程序员的essential knowledge列表并不完备,关键是自己在学习新知识的时候带着第三只眼来敏锐地判断这个知识是否是不变量,或不易变的量,是否完全可以在用的时候查手册即可,还是需要提前掌握(一些判断方法在上文也有所提及)。并且学会在纷繁的知识中抽象出那些重要的,本质的,不变的东西。我在之前的part里面也提到我在学习新知识的时候常常问自己三个问题:该知识的(体系或层次)结构是什么、本质是什么、第一原则是什么。

另外还有一些我认为是essential knowledge的例子:分析问题解决问题的思维方法(这个东西很难读一两本书就掌握,需要很长时间的锻炼和反思)、判断与决策的方法(生活中需要进行判断与决策的地方远远多于我们的想象),波普尔曾经说过:All Life is Problem-Solving。而判断与决策又是其中最常见的一类Problem Solving。尽管生活中面临重大决策的时候并不多,但另一方面我们时时刻刻都在进行最重大的决策:如:决定自己的日常时间到底投入到什么地方去。如:你能想象有人宁可天天花时间剪报纸上的优惠券,却对于房价的1%的优惠无动于衷吗?(《别做正常的傻瓜》、《Predictably Irrational》)如:你知道为什么当手头股票的股价不可抑止地滑向深渊时我们却一边揪着头发一边愣是不肯撤出吗?(是的,我们适应远古时代的心理机制根本不适应金融市场。)糟糕的判断与决策令我们的生活变得糟糕,这还不是最关键的,最关键的是我们从来不会去质疑自己的判断,而是总是能“找到”其他为自己辩护的理由(《错不在我(Mistakes were made, but not by me)》)又,现在是一个信息泛滥的时代,于是另一个问题也出现:如何在海洋中有效筛选好的信息,以及避免被不好的信息左右我们的大脑(Critical Thinking)关于以上提到的几点我在豆瓣上有一个专门的豆列(“学会思考”),希望有一天我能够积累出足够多的认识对这个主题展开一些详细介绍。

最后分享一个学习小Tip:

学习一个小领域的时候,时时把“最终能够写出一篇漂亮的Survey”放在大脑中提醒自己,就能有助于在阅读和实践的时候有意无意地整理知识的结构、本质和重点,经过整理之后的知识理解更深刻,更不容易忘记,更容易被提取。

杨军在 TopLanguage 上也曾分享了三篇非常棒的学习心得的文章,字字珠玑:

[1] 有些事情做起来比想象中容易 [2] 有关读书方法的一点想法 [3] […]

Category

Archives