今早师北宸（@beichen）在 Twitter 上说：

真是可怕，创新工场某资深投资经理在 Quora 回答「在中国用 VPN 是否违法」的问题的时候，给出的建议竟然是：「不要谈论关于 VPN 翻墙的话题，不要给别人提供工具帮助他们获取被屏蔽的信息，因为国外有些信息对中国人是有害的」。

师北宸只说出了一部分的事实。

他说的投资经理是黄继新。黄也是本站作者之一。这个 Quora 问题的链接在这里。

问题如下：Is using a VPN in China (PRC) illegal?

黄继新的答案如下（复制于 2011 年 6 月 20 日中午一点）：

Brief points (please forgive me for not elaborating):

1. There is no law about using VPN in China.
2. Building your own VPN to access your office internal network is, of course, no harm.
3. Don’t talk about using VPNs to access banned websites. Don’t provide tools to facilitate that, because there are some information bad for the Chinese people.
4. Any VPN service facilitating bypassing the wall will be eliminated.
5. No one has officially recognized the existence of such a thing as Great Fire Wall in China. The speakpersons only said that the state has the obligation to protect its people from harmful information.

我认为该答案需要进一步说明，所以今早以「Needs explanation」的理由把它 flag 了。目前该答案已被折叠。

请大家自己判断。

昨天在 Twitter 上推了一下 NetNewsWire 的作者布兰特·西蒙（Brent Simmons）写的「当我们谈 RSS 时我们谈些什么」。很多人喜欢叫嚷说「RSS 已死」。西蒙说，死掉的是 RSS 阅读器，以及「看到喜欢的网站，用 RSS 阅读器去订阅之」这样一种用例（use case）。作为协议格式的 RSS 不仅没有死，使用范围反而在日益扩大。

最重要的是：西蒙认为这是好事：用户不必再关心格式。她们只是想读新闻、博客、播客、朋友的状态更新等种种内容。在后 Twitter / Facebook 的世界里，她们希望这种内容以实时更新的方式被推送到自己眼前。至于背后的技术是 RSS、还是 Atom、还是 JSON……睬它都傻。

这让我想到知乎上的一个问题：你会选择什么样的电子书格式？为什么？（需要有知乎帐号方可访问）

问题是这么说的：

当一本电子书同时提供多个格式如 txt、chm、pdf、epub、mobi 等的时候，你会选择哪个格式？为什么？

目前为止有七十一人回答这个问题，每人都有自己的偏好。

这是很有问题的。

在真正的电子阅读时代，你不会去关心电子书的格式，正如看纸书时，大部分人不会去关心这本书用的是骑马订还是锁线胶装。做电子阅读软件的人，也不会把「我们支持 XXX、XXX 格式」作为卖点。她们会说：我们有谁谁谁的书。

在中文电子书的语境里想象这种景况可能比较困难，那么看看英文电子书的老大 Kindle 好了。Kindle 用的格式叫 AZW。懂行的人会告诉你那是封装过的 HTML。但无数掏钱买 Kindle 书的人不需要知道这个，你也很少看到亚马逊吹嘘 Kindle 能支持多少种格式，虽然它的确支持 mobi 和 PDF。

西蒙说，2002 年的普通互联网用户的「geek 指数」高于今天。在当年，网上的人们有耐心和兴趣去研究「订阅 RSS」这件事背后的一整套繁复和抽象的观念。今天不行了。

同理，今天中国的电子书受众有耐心和兴趣去研究各种电子书格式，这本身就说明电子书还完全没有成熟──注意，不是「市场」没有成熟，也不是「产业」没有成熟，是做电子阅读的人、以及她们做出的东西，还没有成熟。研究格式，是软件的设计和开发者应该做的事情，这种工作不应该转嫁到用户身上──如果你想从用户身上赚钱的话。

「内容何以为王」的第二篇，仍然是原载于 A List Apart 的文章。这不是一篇单纯的产业观察，作者卡梅隆·科松（Cameron Koczon）写它有着明确的目的：这是他们正在研发的新产品 Gimme Bar 的纲领。（要知道 A List Apart 的稿费只有一百美元。）它对 Instapaper 所揭橥的一个新内容时代做了很好的抽象归纳，并对目前线上内容最大的问题──如何让创作内容的人拿到钱──进行了发想和挑战。── 编者

我们跟线上内容互动的方式很快就会发生巨大变化，我认为大家应该感到无比兴奋。Instapaper、Svpply 和 Readability 一类的「书签仔」软件指向一个新的未来：内容不再囿于网站，而是漂浮环绕在用户周围。我们和内容的关系的这种变化将迫使我们重新思考现有的署名、发行和盈利模式──它们都会变得更好。

今天的内容

目前网上的大部分内容是固定死的，它们扎根于众多网站和软件当中。由于这种固定性，我们被迫将宝贵的时间用来记录内容的位置，以便再次回头浏览。我们把网站加入收藏夹，把微博上的信息打上星标，在文本文件里创建列表。

在这个系统里，网站是宇宙的中心，而作为用户的我们围绕着这一中心旋转。每当我们想与内容互动时，就会与之联系。这个系统不错，但随着用户把越来越多的时间花在主要用来消费信息的设备──例如 iPad 和手机上时，我们对内容就有了新的要求。

网站的反应很快。CSS3 里的媒体类型查询技术（media queries）和 Responsive Design 令设计师得以针对用户使用的设备类型来定制用户体验。网站在这种宏观层面上的灵活度很重要，但真正的突破还没有到来，那就是微观层面──每一条内容──的灵活度。

内容的出版方在过去十年里一直享有这种灵活度。RSS 令她们可以轻而易举地将内容分享给订户，省却了订户主动访查内容更新的麻烦。最近出现的一系列书签仔软件慢慢将「使内容活化」的任务由出版方转移到用户，其中的领军者是好评如潮的 Instapaper，它做的事情可以被称作「内容转移」。

内容转移

「……我很确定一点：人们希望将内容从发现型设备（笔记本电脑、收音机等）转移到消费型设备（平板、Sonos 等）上。我也很确定这件事在未来几年会变得越来越容易。」

── Fred Wilson

内容转移令用户可以将自己在某一语境中找到的内容传送到另一语境中阅读。最流行的内容转移软件大概就是 Instapaper，它是用来转移我们在网站上发现的内容的。点一下「Read Later」书签仔，文章就会被从你的浏览器转移到移动设备上。

不过 Instapaper 所做的不只这些。内容转移这个说法让我们的注意力集中于转移这一过程本身，忽略了内容在被转移之前的变化。它首先要被用户找到，从原来的宿主中抽起，并和该用户关联在一起。我把这一过程称作「内容放生」，它正是 Instapaper、Svpply、Readbility、Zootool 和其他书签仔软件的共通之处。尽管内容的转移已经有了强大的力量，但它只是内容被放生之后的诸多可能性的开端。

内容放生

内容的放生分为两步：

1. 提纯。首先要将内容还原至最基本的状态。它可能是一篇文章、一条微博讯息、一份菜单、甚至一整张网页。重要的是只保留核心的东西。但提纯过的内容不是没有出处的。这份内容永远知道自己来自哪里，而你也知道。
2. 关联。提纯之后，原始内容进入了一种自由悬浮的状态，它需要新的归宿。这时我们要将它和用户关联。通常的做法是设立用户帐号，或是在桌面上放一个文件夹，用户可以将内容放在里面。

上述步骤的结果是：原始内容以最纯粹的形态保留了一份版本。这份放生后的内容被关联到某个用户之后，它的命运也就交到了该用户手中。就算最初发布该内容的网站将它删除或修改，也并不会影响到放生后的内容。而用户则逐渐地在积累各种放生后的内容，这些内容的集合就是第三方软件去营造社群和添加功能的基础。

内容集合

内容集合作为一种数据形式的重要性正在日益增加。开发者由此出发可以写出根据用户的特定需求定制的软件。举例来说，Svpply 的用户可以用它列出自己喜爱的产品清单。今后我去商店购物时，我就可以根据我的朋友和那些品味值得信赖的人收集起来的产品清单来选购。

网上有各种各样的数据，但目前其中只有一小部分才有相应的软件帮助我们去收集它们。我认为这一点很快会改变。针对菜单、吉他谱、字体、旅行心得等数据的新软件会逐渐出现，用户可以将这些数据编辑成内容集合，将它们的潜力挖掘出来。「收集和编辑内容集合」很快就会成为具有重大意义的事情──别说我没提醒。

内容控制

放生后的内容的集合有两个可以预见的问题：谁拥有对这些内容集合的控制权？内容本身归谁所有？这里先说控制权的问题，请放心，后面会讲到归属权。

我们还是以 Instapaper 为例。Instapaper 里的文章是由你控制的吗？其实不是。如果另外一个软件做了一个功能，让你可以把 Instapaper 里的文章打印出来，并帮你装订成书，这就必须获得 Instapaper 的许可。你用 Instapaper 收集了内容，Instapaper 就成了你和「任何其她可能将这个内容集合变得有用的人」之间的中间人。如果 Instapaper 的 API 不提供某种功能（也别忘了它是最近才有 API 的），你就毫无办法。这可能让你不太爽，因为毕竟你花了不少时间去收集那些内容。

即便有了完善的 API，这种跟内容打交道的方式从根本上说还是不够直接，而且效率不高。就像是你被一堆软件环绕，必须通过它们才能看到内容。为什么不直接让内容环绕着你呢？

环绕式内容

在用户和内容的新关系里，用户位于宇宙的中心，内容漂浮环绕在她们周围。这种由用户收集起来的「环绕式内容」有如下两个特点：

1. 它是被放生的内容：要么是你自己创造的，要么是你提纯过之后，和作为用户的你关联了的。它是纯粹的，也是个人化的。
2. 它是开放的内容：你是内容的收集者，所以你拥有对它的控制权。没有中间人。如果第三方软件想向你提供某种服务，它要做的不是向另外的第三方软件请求 API 权限，而是请求「你的 API」的权限。这才是最有用的地方。内容可以在无数软件之间分享，在不同的语境之间无缝流转。

于是我们就有了由用户控制的内容集合。它是自由的、纯粹的、开放的、个人化的。最重要的是，它是有用的。你花了工夫从各处收集内容，软件则帮你让这些内容变得有用。这些环绕式内容的集合会让用户更自主，软件更创新。

「你的 API」

在传统的商业模式下，消费者用钱投票。喜欢的东西才买，不喜欢就不买。在环绕式内容的模式下，用户用内容投票。有意思的软件，我会分享内容给它，无聊的软件就不分享。由于内容围绕用户而转，她们直接控制着内容的访问权。软件不会再要求我们填入其他网络服务的帐号和密码，它们只会向我们申请内容的访问权，帮我们将内容变得更有用。

这对于第三方软件造成了压力，它们必须不断创新以便应对你不断变化的需求。这是好事。如果某个软件怠惰了，你随时可以将内容分享到另外的软件上；或许后者的功能更加完善。举例来说，我在 Last.fm 上积累了很多音乐数据，但由于 Last.fm 控制了这些数据，她们便不必有创新的压力，相反可以坐享其成，不思进取。如果我能把这些数据共享到 Pandora, Rdio 或 Grooveshark，Last.fm 就会有压力，怕我跑掉。如果 Last.fm 还是不思进取，那么其它几家便可乘机开发新的功能。无论怎样，赢家都是用户。

内容的归属权

看到这里，想必不少读者已经愤懑了：为什么你迟迟不提环绕式内容的版权问题？当她人创造的内容被放生时，我们会面对一些棘手的归属权问题。

很多出版方会问：为什么用户有权复制我的内容，并分享到其它语境？这是个很正常的问题，但它关注的其实是另一个点：报酬。如果说读者每在出版方的网站上读一次内容，出版方可以拿到一美元，而内容被共享出去一次，出版方可以拿到十美元，她们当然会尽其所能去共享。复制不是问题，如何获得报酬才是问题。今天的网络环境极不利于让内容创造者获得酬劳。分享工具无数，支付工具几乎是零。

我们可以把环绕式内容视为重新思考报酬问题的机会。能做的事有很多，一旦做成，万维网会成为一个让内容创造者和消费者都受益的地方。这里的关键之一是署名机制。

内容的署名与盈利

署名机制指的是以后设数据（meta data）的形式附加在内容上的关于作者的信息。无论内容被共享得多远，它都不会忘记作者是谁，最初来自哪里。署名机制很重要，但在网上基本已经支离破碎了。随便看看 Tumblr 或是 FFFFound! 上的图片，就知道大部分内容根本很难找到原始的出处。署名机制的缺乏意味着在内容被她人分享的过程中，内容创造者会名利双失。作为网络世界的良民，我们在放生 / 共享内容时不得不时刻注意保存作者的名分。

如果能从机制上确保署名的存在，内容集合与环绕式内容将令出版方名利双收。过去，网站站长通过做流量、抢「眼球」和打广告来盈利。严格的署名机制可以让这一模式发生有趣的变化。我们可以把眼球这一概念推广至「在任何语境下看到了你的内容的人──只要署名保持完整」。若署名能一直跟随内容，为什么不能盈利？RSS 在这方面有先例，它让某些广告可以跟随内容进入其它语境。我们可以更进一步，让广告跟随内容，并且不管读者在主站还是其它地方读到了内容，作者都可以获利。

署了名的环绕式内容可以成为内容创造者和诸多内容消费者之间的沟通管道。我们公司（Fictive Kin）的人很迷 These Are Things 设计的一段名叫「Haters Gonna Hate」的 GIF 动画。这段动画很快在网上传播开来，观看次数以百万计。很多人把它存了下来，或是转发了出去。These Are Things 稍后推出了 Haters Gonna Hate 主题的 T 恤与小海报。要是有署了名的环绕式内容，她们可以轻易地将 T 恤与小海报的信息推给那些收集了 GIF 的人。

一种围绕内容而生的新式应用软件

我们的喜好跟我们的社交圈一样有定义身份的作用。内容放生、环绕式内容和署名机制将催生一种新的软件类型。它们围绕我们的内容和兴趣而建，而不是以我们的社交圈为本。Instapaper、Svpply 和其他书签仔软件代表着这个过程的开端。这几个软件暗示了一些可能性，但我们应该记住：环绕式内容是一个未被开垦的前沿领域，它的形态需要我们去塑造。如果它能够形成规模，我们将催生一个内容生产者可以获得合理报酬、内容消费者拥有前所未见的权力，而线上软件（web app）持续创新和改进的万维网。听起来不赖。

(Translated with the permission of A List Apart Magazine and the author.)

今天下午在 Twitter 上发了这么一条:

赞！广西师范大学出版社新出的简体版章诒和小说《刘氏女》用了真正的中文引号。估计跟设计是（香港人）陆智昌有关。

http://twitpic.com/5afli2

很多朋友问：为什么「」和『』是真正的中文引号？

我一直主张在中文里用「」和『』，而不是 “ ” 和 ‘ ’。最简单的理由是前者比后者好看。对我来说，这一个理由就够了。

从今天大家的反应看，很多人对引号的问题有误解。

首先再次强调：标点符号的用法很多时候没有对错，只有品味上的区别。举例来说，大部分人可能认为英文里 “ ” 是一级引号，‘ ’ 是二级引号。但这是美国的规矩，英国的用法刚好相反。你不能说任何一方的用法是错的。假如你写了一本英文小说，英国出版社的编辑会给你改成英国用法，美国的会改成美国用法，仅此而已。类似的例子还有关于逗号应该出现在闭合引号的里面还是外面的问题，英美也各执一词，前阵子有美国人在 Slate.com 写文章弱弱地支持英式用法。总而言之，你习惯的用法，就只是你习惯的用法，而不是对的或错的用法。

更加重要的一点是：“ ” 和 ‘ ’ 作为引号并不是在任何国家都是天经地义的。它们是英语国家的标准引号，但法国、德国等地都有自己的引号标准。法国是 « … »，德国是 „…“。在这里你可以看到各国引号用法的说明。所以，英语国家用了 “ ”，所以中文也应该用 “ ” ──天下没有这样的道理。

回到中文的问题。今天有人问我是否考据过中文引号的历史。我没有考据过，但我知道一点事实：在不同的历史时期，「」和『』都曾在大陆、香港、和台湾这几个中文地区被用作引号。所以诸如关于这两个符号是「日文引号」、不适合用在中文的说法是站不住脚的。

有人说，你想复古，那为什么不乾脆去掉所有标点？中文本来就没有标点。谢谢这位老兄提醒，但我并不想复古，我只想达到我心目中的易读性和美观的平衡。

还有一种意见认为标点符号的使用应该遵循国家标准。关于这点我要说，这份标准是在中国资讯极其不发达，typography 意识较低的年代拟定的，我不认同。大家都知道中文排版和字体设计目前还很落后，但近几年出现了越来越多对字体排印有兴趣的人，以及像 Type is Beautiful 这样的专业字体讨论网站。我们完全应该甩开那份标准的束缚，通过实验和讨论形成自己的标准。在今天，中文字体领域没有真正的专家──只要愿意认真参与讨论的人都是专家。平面设计师群体、前端设计师 / 工程师群体、程序员群体、字体设计师群体、中文 TeX 群体和出版界都应该参与这一过程，所有的成见都应抹除。引号该用哪种？段首缩进应该是一格还是两格？行末标点应该外挂还是内缩？齐头尾时应该仅仅压缩标点，还是可以调整字间距？中文 web font 怎么办？程序员群体在这件事上能做什么？所有这些问题都应该在摒弃现有假定的前提下公开讨论。若仅仅因为中国大陆的官方标准的存在就放弃了实验的可能性，我认为是可惜的。

除了望着优秀的日文字体流口水，我们应该做些事情。

至于什么是「真正的」中文引号，我无意说服谁。我也不反对别人在中文里用 “ ” 和 ‘ ’。但广西师范大学出版社的简体书用了「」引号，在中国出版界无疑属于异数，把它拎出来是很自然的事情。这是我今天发那条推讯的动机。

–

想知道如何打出「」引号？

两年前我们做过一个系列叫「阅读的未来」。虽然最初的想法是把它做成一本书，但我很清楚这不是一个静态的题目，而书是一种静态的媒介。既然放在了网上，延展起来就很方便了。

今天我们将开始延展这个系列。在过去两年里，「屏幕阅读」这一领域有了新的进展──虽然并不是很多，但也足以让目前这个 1.0 版的「阅读的未来」略显老态。

「内容为王」是近年来我们时常听到的话。通常我不知道说这句话的人是什么意思，也不知道她们知不知道自己想说什么。可以确定的是，这句话在被当作尸体鞭笞了过亿次之后，已经毫无意义了。赞成内容为王的人，对内容未必真有她们所表现出来的那种信心，而更有不少创造内容的人认为「内容为王就是句屁话」。无论在何种语境里，以内容为王为由头开展的话题都难免沦为谈话各方的自渎。

但我相信内容的价值。对我来说，关于内容和渠道的争论跟关于苹果和微软的争论一样无趣。作为喜欢阅读的人，我只想在屏幕上看到好的内容：电脑屏幕、手机屏幕、平板屏幕、电子墨水屏幕。为此，我们等了太久。

今天的屏幕上的内容──这里我们主要讨论文字内容──不好？在无数每天进行着屏幕阅读的人看来，它可以接受，但显然不是没有改进空间。而且屏幕内容也在不断演化：想想十年前的网页和今天的网页就清楚了。在内容得以在真正意义上称王之前，我们要研究一下内容还有什么问题，并问问它何以称王。

今天发布的乔·克拉克的文章《那些无法上网的文档》便是「内容何以称王」系列的第一篇。该系列也会收入「阅读的未来 2.0」。

希望大家读得开心。欢迎将反馈意见发到 Talk [at] Apple4.us 或我们的 Twitter 和新浪微博帐号。

两年前乔·克拉克（Joe Clark）发表在 A List Apart 的文章。原文在此。──编者

关于万维网（web）的起源有着流传甚广但不符合事实的说法。人们说添姆·伯纳斯李发明 HTML 是为了发表物理论文。真是这样吗？这无所谓，反正这个传说至今还起着作用。你尽可以开发一个又一个的线上软件（web app），但万维网主要还是一个用来发表文档的地方。

网上一直有各种各样的「数字化」计划，把各种各样的古旧内容数字化：专利申请文件、书、相片、所有一切。除了相片大概可以以 JPEG 或 TIFF 格式很好地存活下去（残障人士能否访问的问题暂且不提），以上古旧内容大都需要进行「语义标注」才能让电脑读懂。作家面对一张白纸时有着彻底的作为作者的自由，但这种自由在面对 HTML 悲剧的语义能力时很可能会尸骨无存。将文档数字化的迷狂──真的是一种迷狂──迎头撞上了 HTML 的语义标签。

某些文档是无法用 HTML 发表的。在很多情况下，我们应该直接放弃这种尝试。还有一些情况则需要彻底改变文档的样式与结构。理想的状态是大家从现在开始使用定制的 XML 文档类型，或许 XML 最终能成为一种可行的格式。

剧本的问题

把打印出来的文档转移到网上是个难题。电影剧本就是个好例子，这在某些圈子里已经成为传奇了。

想写剧本的人很多，大部分人的下场是一样的：找不到人帮她们把剧本拍成电影，更没人发行。而她们无一例外都要学习那种流传了几个世代的剧本写作「风格」。

《虎胆龙威 2》剧本的一页

剧本的格式源于打字机时代，它的设计是为了让一页纸（在美国被称为「美国信纸尺寸」）的长度刚好约等于一分钟的电影。大部分商业电影是两个小时，所以一份典型的好莱坞剧本的长度会在 118 到 122 页。

剧本的字体排印很糟；旧式打字机上老掉牙的字体被映射为今天我们看到的扁长的 Courier。但从工程师的角度看，电影剧本作为文档是非常出色的。

• 剧本的文字缩进可以形成一门学科了。在剧本里，文字极少「居中」（好像从来没有过？）；所有缩进都是以 tab 为单位──这是一个被 CSS 彻底铲除了的集体记忆。（在 CSS3 里可以用 ch 这一单位来设置左边界，但没人这么幹。）
• 这些细致的缩进设置让人们能够轻松地速读一页剧本。全大写的单词有其语义上的意义，可以帮助我们扫视内容。CSS 为其赋予了「text-transform」这种机械化的名称，显然不合适。而现在人们又想将这种格式完整地转移到网页上。这是行不通的。
• 网「页」只是一种比喻，它和上面说过的「跟电影时间对应的一页纸」这个单位没有关系。（这已经意味着剧本上的许多页眉和页脚必须消失了，因为网页其实只有一「页」。）
• 没人会指望线上版的剧本能具备纸版的功能：发给人去读，被买下，最终拍成电影。这些都发生在纸的世界里，而不是 Firefox 里。
• HTML 本质上是不可扩展的。虽然后来有了「可扩展的 HTML」（XHTML），但其实它也一直没有被扩展。于是以下众所周知的事实还是没法改变：HTML 的标签种类不足以应付剧本的语义需求。在剧本里，几乎所有东西都需要单独的标签。
  • 对话似乎问题不大，但对话中往往穿插着屏幕说明和对演员的指示。在 HTML 里，两者都会被标为段落（p），尽管它们的功能以及应该呈现的样式都很不同。
  • 各种各样的标题怎么办？对话人的名字、时间、语气（这些通常叫 slug 或 slugline）。HTML 里的标题标签「很多了」──一共有六个──但它们是按层级而非功能排列的。用类（class）来区分真的够了吗？「h2 class="slugline"」、「h2 class="charactername"」这样就可以了？不，不可以。剧本的标题和 HTML 的标题是两种东西。

1. 其中之一是专有格式 Final Draft，它在剧本界的地位等同于 Word 在办公室中的地位。开源狂热分子会觉得这是个抨击专有格式的良机，但编剧可没空关心开源问题。不管怎么说，Final Draft 8 的默认文档格式已经是 XML 了。
2. 另外一个选择是 PDF。电影圈不用关心文档能否让残障人士方便地访问的问题，因为就算没有增加这方面的功能的 PDF 作为剧本格式也足够了。你也不需要加了标签的 PDF，它的语义能力还是不足以应付剧本。（理论上你可以自己写 PDF 标签，反正那只是 XML 而已。）

将剧本搬上网的壮举让我们想起其它的「类型错误」（Martin Amis 语）。我们逐渐发现电子商务并不是说要在网上建一个「商场」，让人们可以虚拟地「漫步其中」。「杂志」和「产品目录」并不是一页一页的供人们翻阅（而且还加了音效）、折角。「网站」的样子跟杂志排版并不相同，它没有多栏文字和加了箭头的图片说明文字。

这一壮举让人想起早年的电视。传统智慧告诉我们，早期的电视节目看上去更像是用摄像机录制的舞台剧。把剧本搬到网上这件事的成果还远不如录下来的舞台剧。

我们从中应该能学到点什么。

必须承认，有人尝试过将网页做到跟打印版的剧本一模一样。这方面的明星是编剧+资深博客约翰·奥古司特（John August）。奥古司特写了一个叫 Scrippets 的插件，可以用在 WordPress、Blogger 等系统上，它已经最大限度地做到了「点石成金」。奥古司特设想了几种用例，其中之一是如何让读者通过 RSS 阅读器能看到完美的剧本格式。要做到这点，唯一的办法是使用包含样式的 HTML 和 inline 样式。自然，这些做法在前端开发里早已过时。

奥古司特是这样描述 Scrippets 的：「Scrippets 可以让你在博客中以文字区块的形式加入『具有漂亮格式的剧本』。」这句话其实是对问题本身的描述，而不是解决方案。他试图继续依赖「页」这一比喻，试图复制打字机的字体效果，试图重现「一分钟一页」的版式，这些尝试都失败了。剧本格式对于纸张来说是「漂亮」的，对于网页则是错误的，哪怕只是「一小块一小块」的剧本内容。

更糟的是，Scrippets 忽略了 HTML 语义对标记剧本的贡献（无论这贡献有多小）。所有元素都被标为段落，但它们并不都是段落。这比为 h2 标签加上一堆类名称更要不得。如此种种，都是试图在网页上标记剧本语义格式这一惨烈斗争中的例子。

剧本的解决方案

要把剧本搬上网，需要在样式上动手术。这不是没有先例的：由剧本改编的书已经拥有了一个健康的市场。事实上，「拍摄用剧本」在美国是一个商标（由 Newmarket Press 拥有），用来指根据电影剧本改编的一系列书籍。

• 某些书只是把打字机打出来的剧本的幅面缩小了。你在读这种书的时候可能感觉自己很专业，但事实上你被欺骗了：你花了钱，但读到的只是作家在打字机上打出来的手稿。扁长的 Courier 字体缩小了之后更难看。
• 另外一些书则是完全重新设计了打字机打出来的剧本，让它成为图书出版领域的「原生」（native）格式。通常的做法是把对话人的名字和她们说的话写在同一行，文字两边加上书籍里常见的边距，并大幅缩减垂直的白空间。打字机打出的剧本在它自己的语境里阅读是很舒服的，而剧本书在它自己的语境里阅读同样很舒服。（重新排过版的剧本有时也用来当作语言教学的辅助材料。）

因此，如果我们要把剧本搬上网，你必须放弃「复制剧本格式」这一想法。你必须做出一套属于网页的设计。你要考虑到上面说过的几点：HTML 的语义标签不够丰富，网页并不是真正的「页」，或者说，一共只有一页。

• 你可以用 HTML 的定义列表（dl）来标注对话。这在 W3C 的 HTML 里是明确允许的，但在 Ian Hickson 的 HTML5 里是明确禁止的。（那么在 HTML5 里就用 dialog 好了，虽然其实 dialog 的子标签 dt 和 dd 同样也是 dl 的子标签。）
• 你可以用 pre 标签去实现假的缩进和换行（但没法假装把整本剧本切分成页面）。
• 你也可以无视缩进，乾脆直接用居中。
• 你可以在一定程度上用表格来排剧本。
• 你也可以不去想太多语义方面的事情。角色名字和对话加粗写在同一行，HTML 标题标签能用就用。

其他搬上网时需要转换的印刷格式

• 版权栏。这是指列明杂志和报纸里谁负责什么工作的那一栏。它的语义其实挺复杂的，因为每人的职位或是所在部门似乎都要用一个标题标签来标记。但如果你用 HTML 的 h1 到 h6 来标记版权栏，就会「污染」到周围的内容。
• 图示和边栏。这些结构对于杂志、报纸和非虚构类的书是常见的，但每当你想把它们纳入一个有效的文档树结构时就会出现严重问题。（你希望读者在整个标签流的什么位置开始读图示和边栏？）
• 脚注。HTML 里没有包含脚注这一结构（带标签的 PDF 里有）。工程师们用了各种各样的歪招，包括用 JavaScript 来实现显示 / 隐藏的小挂件，以及各种乱七八糟的链接和反向链接。对于文学爱好者而言，HTML 没有脚注令到已故的大卫·福斯特·沃雷斯（David Foster Wallace）的作品基本无法在网上阅读（尤其是他的脚注中的脚注）。
• 含有大量注释的图片（Charticle）。通常人们认为这起源于《Spy》杂志，它跟 Flickr 上那些充满注释的照片在功能上一样。但 HTML 也没有针对这种情况的标签。
• 数学和科学内容。没错，又是老问题。别提 MathML，网上几乎没人实际在用它，因为写起来太难。物理学家雅克·迪斯勒（Jacques Distler）是极少数在网页上用 MathML 的人之一。

怎么办？

了解了上述情况之后，我们接下来会怎么做？我的预测是：什么都不会做。大家还会继续试图复制剧本格式，并用奥古司特那种水平的代码（在 HTML 里直接写样式）。但我们还是有些别的法子。

剧本的例子不是独立的，用 XML 来标记文学作品一直很难，剧本只是其中一个变种。多年来人们一直在尝试，但目前为止几乎没有哪个 DTD 获得了认可。大家只想继续用 HTML 来标记所有东西。搞不清状况的作家更是把所有东西标记为段落，或 div。

有人说 HTML 是万维网上的通用语，大家可能太把这话当真了。HTML 源自 SGML，XHTML 是把 XML 这种旧酒装进了新瓶子。这里就已经有四种标记语言了，但人人都表现得好像只有 HTML 一种似的。（大部分情况下浏览器会把 XHTML 当成末尾加了斜杠的 HTML 对待。）连电子书都是用 HTML 标记的──EPUB 格式其实只是被包裹在容器里的 XHTML 1.1──但这让 EPUB 变得既是 HTML 又是 XML。既然这样可以接受，那么其他 XML 的变种也可以咯？

浏览器无法显示格式正确的 XML 的时代早已过去。今天的浏览器们完全可以做到这点。各种各样的文学文档和文献在网上实现已经有了技术上的可行性。但由于它们沉寂了太久，如今似乎没人愿意去理会它们。毕竟不都说 HTML5 才是未来吗？就像过去我们都认为 XHTML2 是未来一样。

结论

万维网无疑是伟大的，但它的语言无法表达很多东西，包括一些人类已经在别处顺利表达的东西。我们应该接受这点：某些文档在搬上网时，格式必须重新设计──至少，如果你的目标是用 HTML 标记它们的话，就一定要重新设计。如果你想为网页文档赋予打印文档的语义丰富度，在今时今日，XML 已是可行的方案。

(Translated with the permission of A List Apart Magazine and the author.)

前两天在 Twitter 上提到乔布斯就苹果新总部大楼给美国加州库布提诺市政厅做的讲演。这段视频里有一个细节很值得注意。讲演开始后不久，乔布斯用幻灯打出地图，向众人说明旧总部和新总部的相对位置。这时库布提诺的市长 Gilbert Wong 突然打断说（视频的 4’20” 处起）：

「乔布斯先生，你可以直接用手在上面画，我们很高科技的。（笑）」

乔布斯回复说：

「我其实用不着直接在屏幕上画，我想大家都应该都能看清。」

但凡仔细看过苹果的发布会的人都不会问出王（黄？）先生那个问题。苹果的幻灯片一向注重动画效果──这里说的不是 Keynote.app 软件内建的那些三维立方旋转或文字特效，而是通过和讲者的口白同步的画面变化──增字、减字、画圈等等──来将信息传递给观众。

是的，的确用不着在屏幕上画。只要设计时充分考虑过观众和幻灯片的距离（用以选择合适的字号），并通过上述动画视觉提示来传达信息，大家当然能看清。

这是一种相当低科技的方法，本质上仅仅是把一张张图片按照一定的顺序放给你看。但它非常有效。所有关于讲演的教程里都会写：你才是讲演的主角，幻灯片只是辅助工具。你不要傻到被幻灯片抢了风头。讲演应该一气呵成，应该和观众保持目光交流。显然，在幻灯片上指指画画时，你的目光必须指向幻灯片，而非观众。

用遥控器翻页也是一样。和躲在电脑后面不断按空格键相比，在保持自然肢体动作的情况下不经意地按下遥控器的 Next 按钮显然更「高科技」。但高科技不是重点，重点在于「保持自然肢体动作」。好的演讲要让观众感觉到你这个活人在跟她们交谈，而不是忙着在操控一台机器。（从这点上说，Phil Schiller 和 Scott Forstall 等人的讲演技巧都还有待磨练；我们能明显察觉到他们讲演时按遥控器的动作。）

苹果数十年来做的各种事情反复暗示着他们对「人」在技术宇宙中的核心位置的重视。正因为这样，他们的人机介面设计指南叫「Human Interface Guidelines」而非「User Interface Guidelines」（嗯，本站首页边栏的图片上的译法要改）。正因为对人的重视，他们才会如此推崇那些毁誉参半的现实风格 UI：Notes.app 上的皮革质感、iBooks 里的木质书架、等等等等。当我们对他们「发明未来」的野心和想像力表示惊叹时，不要忘记他们的产品中的那一点「人肉的味儿」。

估计这位香克曼老兄是实在憋不住了才写的。原文在此。── 编者

这篇文章本来该叫《所有社交媒体专家赶快去死》。不过做人要厚道。

但标题说的是实话。若你自称社交媒体专家，请别给我发简历。

任何公司都不该设这样一个职位。同理，它们也不该设上师、摇滚明星或专家学者这样的职位。每月给一名社交媒体专家发工资完全是浪费钱。

社交媒体专家擅长的事情好比「把三明治从冰箱里拿出来」。或许你拿三明治拿得比别人都好，但你知不知道，做出一份美味的三明治才是正经事。如果你一辈子都在从冰箱里拿三明治的话，我担保你肯定做不出好吃的三明治。

社交媒体只是市场营销和客服的一部分。跟我重复一遍。一直要重复到牢记在心。写在你的手上，挂在您的门前。社交媒体本身是帮不到你的。

第一轮科网泡沫时的错误正在重演。每个人都曾经以为在公司标识后面加个 .com 就算是不落伍了。错。如果你只会这个，那只是进一步强化了贵公司有多悲剧。你所做的并不是「打造全新概念，引领消费者一起分享，参与炫酷新媒体变革」。不，你只是个白痴，你的公司六个月内就会倒闭。

但你猜怎么着？十年过去，大家毫无进步！我们又饥渴了，又开始给自己打鸡血。我们不去好好拥抱新技术，将其与过去学到的东西结合，而是开始裸奔狂欢、手舞足蹈。是啊，今时不同往日，今时比往日牛多了！

「现在不是做个网站那么简单了！比这要酷！Facebook、粉丝群、关注、参与感、影响力……」

可以闭嘴吗？不然我怕我要吐到你鞋上。谢谢。

做好营销，做好客服，由此产生收入，这些才是正经事。自盘古开天辟地以来就是如此。

保持透明度才是正经事。不要欺骗顾客，不要以为出了事在 Twitter 上认真道个歉就万事大吉。这样想你就输了。顾客会成群结队地跑走，因为她们随时有别的选择。她们想选哪家就选哪家，无论她们过去对你有多忠诚。你要是欺骗她们，就等着被曝光，然后卷铺盖走人吧。

让你的受众帮你讲故事和推广才是正经事。她们愿意向别人讲你的故事，是因为你为她们提供了她们应得的服务。美联航空搞的「United Breaks Guitars」事件算不上利用社交媒体的好例子。恰恰相反，这只是一次条件反射式的危机管理。要是美联用心把客服做好，危机本不必发生。

推送有意义的信息才是正经事。公司每次有产品打折就在 Twitter 上喊一声，这不算「有意义」。你要搞清楚你的顾客都是些什么人，并想办法找到她们。假如你的顾客根本不上 Twitter，那么在 Twitter 上发打折消息的阁下就是个白痴。营销先要了解受众，并向正确的人群发送精准的、定制过的推广信息。

「社交媒体专家」不懂这些。她们会给你建一张粉丝网页。过一阵子发现这些努力无法转化成销售数字时，她们就说，「嗯，我们要再多发点。」

不要当这种人。真正的营销专家知道何时该用传统手法，何时该用社交媒体，何时该用口碑营销。你可以试着问一个社交媒体专家，问她旅行社的旅行规划师是幹什么的。她开始在 Google 搜答案的时候，你就可以偷笑了。

简明扼要才是正经事。你知道那些自称社交媒体专家的人缺乏什么能力吗？（当然她们缺乏的能力不只一种。）写作能力。这类连一个像样的简单句子都写不出的「专家」还真不是一般的多。假如我们要在三秒内将信息传达给一个新顾客，你觉得最重要的是什么？

不是 Twitter 关注者数目。不是 Facebook 粉丝数目。不是 Foursquare 签到的次数。不，最重要的是优秀的写作能力，就这么简单。好文字是简洁的，而简洁有利于推广。你知道有什么方法能确保让贵公司失去我这个顾客吗？只要在你的宣传文案里添上一个语法错误就好了。

最后，了解你的顾客、让你的顾客能想到你才是正经事。巴里·狄勒（Barry Diller）执掌派拉蒙时每天早上都拿出通讯录给十个人打电话，只是为了打个招呼。于是整个好莱坞都记住了这个默默无名的高层的名字，因为他愿意花时间去联系你，去跟你沟通。于是这一行为最终令派拉蒙在其他电影公司挣扎求存的年代里财源滚滚。

你了解你的受众吗？你有花时间联系她们吗？我不是说跟她们发微博，我说的是真的去联系她们。问问她们觉得你有什么不足，问问那些近期较少光顾的顾客在什么情况下会再来。发送打折信息和积累粉丝是不够的。拜托，你不至于那么天真吧。

你不会让实习生去写公司财报发布会的新闻稿，那么为什么当二十二岁小朋友说「我们要搞点社交媒体营销，这才是最酷的」的时候，你会去听，去信？

社交媒体不「酷」。赚钱才酷。社交媒体只是众多营销工具中的一种，这些工具是用来增加收入的。如果你指望用社交媒体来幹任何其它事，请把这些工具砸烂吧，我估计再也不会见到你了。

六月七日凌晨一点。（美国旧金山时间六月六日上午十点。）

直播地址如下：

Twitter.com/apple4us
Weibo.com/apple4us

我们的程序员 Willow (@chengyinliu) 可能会到现场。

今年看点当然是 iOS 5，Mac OS X 10.7 (Lion) 和 iCloud。苹果之前做的 web 服务都比较鸡肋，且看这次如何。有人说 iCloud 不是用来取代 MobileMe，而是用来取代 iTunes 的。但愿如此。

还有一个传闻是苹果将在 iOS 5 里深度整合 Twitter。看来 Twitter 的确正朝着网络基础设施和协议（「不指定收信人的通讯协议」）的方向演变。Dave Winer 更觉得苹果应该收购 Twitter：一来苹果现金够多，二来苹果自己做社交产品总是做不像，三来 Twitter 几次试图加点盈利的设计都被骂惨（例如 Promoted Tweets 和「Dickbar」），不如卖掉，对投资人也是好事。

今晚见分晓。

一家名不见经传的公司，突然就处在了风口浪尖，成为众口所指。

最早是 PCalc 这个 iOS 上的计算器软件的开发者詹姆斯·汤逊（James Thomson）收到了这家名叫 Lodsys 的公司通过联邦快递寄去的律师信。Lodsys 声称 iOS 里的 In-app Purchases (IAP) 技术涉及到了她们所拥有的专利权。苹果虽然为此专利支付了授权金，但该授权并不允许苹果转授给第三方开发者。Lodsys 因而要求汤逊为使用 IAP 而单独购买另外的授权，限廿一天回复。众人哗然。

稍后又有其他几位 iOS 第三方开发者收到了同样的律师信，其中包括开发 Twitterrific 的公司 Iconfactory。消息爆开后，Lodsys 似乎是临时架设了一个博客，对事件做出了回应。据昨天英国《卫报》报道，苹果已经开始「积极调查此事」。

老实说，若不是精于专利权和知识产权的专业法律人士，是不容易厘清整件事的来龙去脉的。好在事件过去几天后，一位名叫弗洛里安·穆勒（Florian Mueller）的软件版权专家在 FOSS Patents 博客上写了一篇非常详尽的问答体分析文章，我根据自己读过之后的理解写几个要点。

我并非法律专业人士，以下转述若有讹误，完全是我的责任，望方家不吝指正。穆勒的文章虽然长了点，但非常精彩，单单是为了给自己普法就值得一读。

一、事情很棘手。目前为止，Lodsys 的律师信都是发给小公司和难以负担高额律师费的第三方 iOS 开发者。若开发者决定和 Lodsys 对簿公堂，律师费会比 Lodsys 索要的授权金高出很多。Lodsys 正是知道这一点才采用了这么一个赚钱的法子。

二、穆勒认为不排除 Lodsys「挟第三方开发者以令苹果」的可能性。Lodsys 在博客文章中说苹果已经获得了授权，但这一授权并不允许苹果再将相关权利转授给其她人——比如第三方 iOS 开发者。穆勒认为 Lodsys 可能是想让苹果再付一笔授权金，以获取将相关权利转授给她人的权力。这样一来，苹果花钱解决了第三方开发者的困境，维系了 iOS 生态圈，而 Lodsys 则能赚一大笔。

三、开发者目前面临一种两难的局面。如上所述，大部分独立第三方开发者没有能力负担律师费用和 Lodsys 打官司，同时她们很可能相信采用 IAP 对用户体验有正面效果，因而能提升软件的盈利能力。出于这种考虑，她们可能会选择向 Lodsys 支付授权金以获得继续使用 IAP 的权利。但一旦有几家开了这一先例，Lodsys 的腰板会更硬，未来会继续用这种方法向其她使用了 IAP 的第三方开发者发律师信敛财。尽管这种做法很下作、而且会招来骂名，但它并不违法。而 Lodsys 本来也没有什么名声需要维护的。

四、Lodsys 声称自己持有的跟 IAP 相关的专利权仅在美国有效。这里的意思是只对以美国为销售市场的软件有效，跟开发者的国籍与所在地无关。所以从理论上说，妳的软件只要不在美国 iTunes 店销售，即便用了 IAP，Lodsys 也告不了妳。（并非 100% 确定。）

五、Lodsys 不是第一家通过专利诉讼敛财的公司。一家叫 MacroSolve 的公司最近就告了十家小规模第三方开发公司——注意，Lodsys 还是先发律师信警告，MacroSolve 则是直接告上法庭。

简单来说，Lodsys 很流氓，第三方开发者很无力（除了 Mike Lee 号召的杯葛行动之外），目前大家都在等苹果的正式回应。

有了新的消息后我会更新本文。

（本文最初以问答形式发表于知乎，转载到 Apple4.us 时有修订。）