本文是《众妙之门3》第九章校对版，由人民邮电出版社授权发表。最终出版还要经过编辑校对，现在发出来作为免费试读。

版权声明：自由转载-非商用-非衍生-保持署名

转载请保留原文地址：http://yuguo.us/weblog/web-or-native-2 本章是作为免费发布的第二个章节，也是总共免费发布的两个免费章节中的第二个，第一个免费章节是：《众妙之门3》——第一章：重新设计的商业思考。

《众妙之门3：重新设计网站》（Smashing Book 3: Redesign the Web）是人民邮电出版社出版的继《众妙之门》和《众妙之门2》之后的第3本，前两版也因为广受好评而分别进行了再版和重印。《众妙之门3》不是前两本的再版，而是紧跟时尚潮流，讲述最新html5和css3、移动网页设计的单独的一本书。

《众妙之门3：重新设计网站》整本书为11个章节，人民邮电出版社愿意免费发布其中两个完整章节来试读，我作为前端从业者表示很钦佩。人民邮电出版社近几年不断翻译和出版了很多关于最新信息技术的书，推荐收听他们的官方微博：人民邮电出版社-信息技术分社 。

以下是正文。 你可能知道，用户体验设计是涉及交互式产品设计原则的一门学科。虽然它包含图形设计和情感设计的重要元素，但它最主要还是关于交互设计的。在设计领域，用户体验设计和产品设计的关系是最紧密的。用户体验设计师主要设计的是虚拟产品。此外，因为硬件设计和软件设计如此紧密相连和不可分离，所以产品设计和交互设计之间的分隔线即使存在，也是很模糊的。

Web设计师是用户体验设计师

从本质上说，一个Web设计师就是具备万维网媒体领域的专业知识的用户体验设计师。一个Web设计师应具备核心技术（如HTML，CSS，JavaScript）并懂得一些Web框架（如LESS，Stylus等等；HAML，Jade等等；jQuery，MooTools等等。）和框架组件作为辅助。这些框架和内部组件都是由代码生成的，这些代码决定了设计的局限性和那些组件的行为。

正如一个汽车设计师必须了解各种各样的材料才能去制造汽车一样，一个Web设计师也必须懂得以上知识，才能去设计网站或者应用程序。

作为交互设计师，我们不只是对交互产品的外观感兴趣，还要关注产品的行为。当你设计应用程序（以行为设计为主的产品）而不是文档（以内容设计为主的产品）时，关注产品的行为方式将尤其重要。

设计一款汽车就是绘制一张漂亮的汽车图，同样的道理，设计一款软件也就是绘制一张漂亮的软件图。

设计文档VS设计应用程序

即使是设计交互文档（尤其是用来表现Web的响应方式）也需要专业知识，至少需要理解响应设计原则和渐进增强。另外，绘制漂亮的图画是艺术，不是设计。

然而，交互式产品或应用程序则是完全不同的。交互式产品的设计需要图形设计和情感设计的技能，最重要的是，需要交互设计的技能。一个交互产品最重要的是它的交互行为，这些交互行为是由代码构建的。

不幸的是，由于设计团队成员的分工更加细化，Web设计师和Web开发师的角色被人为地分开。虽然这种分工在团队合作中可能是必要的，但是，这些标签应用来定义团队成员当前的工作，而不是来决定他们所需掌握的知识。或许你应该关注某个领域更多一点（尤其是在特殊项目中），但是你必须明白我们构建产品的首要目标是满足用户的需求，开发团队中的每一个角色都将会影响用户体验。这就是为什么小型跨学科的团队构成才是当务之急，团队的每一个成员都应该总是首先为用户着想。

首先为用户设计

当构建一款产品时，设计主导开发，开发形成设计。这是一个周期循环交替的过程，在这个过程中，目标是不断优化产品来满足用户需求。[1]

[1] 学习这种工作方式，建议阅读敏捷开发方法和以用户为中心的产品开发方法。2003年，敏捷开发过程中，在迭代中增加集成化设计和用户测试被称为以用户为中心的产品开发方法。Smashed.by/cfe

你做的每一个关于产品的决定都应该是源自用户的。你必须首先考虑用户的需求，而不是你自己的需求。换句话说，试着所谓的“由外而内设计”。思考用户的需求和他们的使用情景，设计用户将看到的和可能互动的内容，然后再决定如何解决你提出的问题。

“由外而内”是好的方法，“由内而外”是不好的。

在一个新项目中，你首先思考的是不是要使用哪种服务器端技术，或者哪种数据库模式？停，这是一个错误的方法，你正在尝试解决你自己的问题，而不是用户的。这是由内而外地设计，是一个很糟糕的设计方法。

本章节的目的

在设计过程中，你需要做出的两个重要决定是，是否要设计跨平台的产品，是否应该采用原生技术。

本章节的目的是，鼓励你（作为一名用户体验设计师）去理解你的领域，以便你能正确地回答这些问题，我们先来看下什么是所谓的原生应用程序。

图9-1 是的，这里有很多设备。但是，你的应用程序不必支持所有这些设备。关注用户的设备并确定你的目标用户，使你的应用程序完美支持他们使用的平台和设备。如果你主要创建的是内容型的网站，而不是交互型的应用程序，那么通过渐进增强技术支持大量的平台是很容易的。

“原生（native）”是什么？

你是否看到过一些人不了解“原生”的真正含义却随意使用“原生”这个短语？让我们来改变这一切吧，从了解人们对“原生”的误解开始。

 “原生”是（不是）”0“和”1“

如果我们从通俗的角度来看，“原生”（数字设备相关的）指代供给电脑设备能量的晶体管中是否存在电流。我们通常将这个视为数字计算机的陈词滥调：二进制代码，一系列0和1。我们称这些二进制指令为机器语言。

虽然计算机曾经是以二进制的形式被编码的，但我们现在已不再使用这种冷冰冰的编码方式了。然而，我们重新设计的每一种编程语言（像C语言、Python、JavaScript等等）最终都被翻译为机器语言“0”和“1”，这些机器语言又被编译为晶体管中是否存在电流这些技术都是建立在抽象层面的。例如，Python是由C语言写的。每个从高层级（包括现代计算机系统技术）抽象出来的层级都是为了使开发者更容易地开发应用程序，因此，虽然从技术角度来说，将“原生”解释为二进制编码是正确的，但在今天却是一个毫无意义的定义。

那么，现在我们了解“原生”不是“0”和“1”之后，我们再来搞清楚“原生”到底是什么吧。

图9-2 对于某种操作系统来说，Web技术可能是原生技术。这里是一台三星笔记本，它运行着Chrome操作系统，其中，HTML，CSS和JavaScript（Web 应用程序）是原生技术。（图片来源：Google的促销图片）

原生文化

“原生”是指形成平台文化、语言、惯例和规范的技术（即语言和框架）。它是一个底层抽象的概念，包括特定平台的主要符号、手势，以及用户与平台软件互动时的交互行为。这些元素是最重要的元素，因为它们构成了平台的文化和规范。[2]它们也是语言（视觉和行为上的），是用户使用平台时，为了和平台软件进行交流互动而需要学习的语言。反过来说，它们也是平台软件和用户交流时使用的文字、短语和理念。在特定平台中，这些元素越有用，越一致，那么为此平台创建原生软件的优势就越大。

[2] 这些规范通常体现在平台的交互规则中，比如Mac，iPhone，iPad和Android系统平台的人机交互准则。（这里，Android系统不是一个好的平台，因为它不是一个真正的单一平台，它有很多风格，设备生产商和移动运营商都可以定义风格。这也就是Google很难统一控制Android平台用户体验的真正原因。好的用户体验需要掌控，Google却很少能够掌控Android系统手机的用户体验。

一方面我们有Apple的iOS平台，它拥有详细的人机交互准则[3]和优雅一致的Cocoa Touch框架。遵守这个交互规则的原生应用将会在其主要框架中继承平台的可用性，并且和平台其他用户所熟悉的软件保持一致性，进而看起来是用户熟悉的软件。

[3] smashed.by/apple

图9-3 Apple的人机交互规则清晰地表明，iOS平台的原生软件在视觉和操作上是怎样设计的。这些交互规则有利于定义平台文化。

另外，还存在一些像Android那样的原生平台，它们的风格大多由制造商、运营商和用户来深度定制，因此Android系统的手机和软件之间有很少的（甚至没有）一致性。这些平台的原生软件设计师很难提供一致的用户体验。

图9-4 Swype键盘确实很酷。仅仅点击几个字母，它便可以自动猜出你想要的单词。

不幸的是，它不支持所有的Android平台设备，只支持一些；在其他设备上，有的采用和iPhone键盘相似的键盘，有的采用不同的第三方键盘。虽然，最初看起来这些选择很不错，但是这意味着Android平台没有一个一致的用户体验。因为制造商、运营商和用户定义了很多的Android风格，所以Android平台的用户体验也有很多种。这就造成设计师创建应用软件时很难使用一个共同的设计语言。

例如，我的一个iPhone软件，Feathers[4]，它拥有一个定制的键盘，使用户能够输入扩展的Unicode符号。在iPhone中，这个软件看起来很像iPhone的内置键盘软件。实现这些，我虽然需要作出一些努力，但还是能够做到的。然而，我如果要将这个软件引进Android平台，就不得不了解用户安装的是哪一种Android键盘，然后才能定制与之匹配的交互行为。不用说，这将涉及很大的工作量，甚至是不可行的。例如，一些Android手机上的Swype键盘[5]是一项申请过的专利，因此，对于拥有Swype键盘的Android设备，我不能使我键盘的交互行为和系统键盘保持一致。

妥善的方案是，不管用户的系统键盘是什么样的，我设计一个单独的定制键盘。当然，它看起来不像是主键盘，这样也不会像iOS平台上的Feathers那样能够提供无缝的用户体验。相反，在一个软件中，用户将不得不学习使用两种类型键盘，不得不努力学会如何切换这两种键盘。

[4] smashed.by/apple

[5] swype.com

图9-5 将Feathers软件引进Android平台，需要设计不同的软件版本以支持Android平台不同类型的键盘。

相似地，在像Web这样没有一致的视觉语言和文化的平台上，非原生的应用反而会有较少的障碍，在一些情况下甚至可能会提供更好的可用性和用户体验。

非原生软件提升用户体验的一个很好的例子便是Gmail。在Windows这样的操作系统中，使用邮件客户端时，你需要寻找和安装客户端软件，保持更新，保证你的邮件能够在不同设备上同步，并确保你的消息经过病毒和恶意插件扫描。Gmail却很简单，你在任何一个设备的浏览器中输入一个URL地址，便可以打开你的邮件。非常完美！

图9-6 Gmail这个Web软件提供了不同平台之间的一致性体验。用户不必安装任何程序，也不必担心他们的邮件在不同设备中是否同步。

Gmail也说明了，创建优秀的跨平台用户体验需要优化许多特定平台。Gmail软件虽然可以同时支持台式电脑和移动平台，但确实还是有几个高质量的版本。

然而，Web作为一个平台，它自己没有一个一致性的用户体验。虽然，Web应用程序拥有共同的特点，但是它们没有一个有关Web人机交互准则方面的文档（或许应该有一个）。[6]相反，我们致力于编写和维护良好的代码和设计实践，如渐进增强。不同的浏览器（也就是，运行原生Web软件的应用）使用不同的工具来实现软件的主要控制形式。这也就是为什么在不同的浏览器中Web软件的交互行为是不同的，即使软件拥有相同的内容和相同的代码。

[6] 看一下Tantek Celik的“需要Web人机交互规则”一文（smashed.by/wehuin）和Joe Hewitt的需要对Web技术有更多关注和愿景的帖子。（smashed.by/owned).

图9-7 浏览器是一个运行在操作系统环境下的原生操作系统软件。Web软件是一个运行在浏览器环境下的原生Web软件。然而，Web软件不是一个原生的操作系统软件。Web软件和操作系统之间有一个分隔带（浏览器）。相似地，一个Flash软件运行在浏览器的一个虚拟机器中，它也不是一个原生的浏览器软件。（图片：Rosmarie Voegtli，smashed.by/voegtli）

混合的应用程序

原生应用程序包涵了其运行平台的文化，Web软件包涵了其运行的浏览器的文化。但是，我们忽略了第三种应用程序（现在有许多应用程序都属于这种）：混合应用程序。

我们需要理解各种技术并恰当地运用它们。Web编写技术（尤其是HTWL和CSS）有利于创建复杂的文档和漂亮的样式。这样，在需要展现丰富内容的时候，许多原生应用程序的设计师会选择使用HTML和CSS技术。这些应用程序被称为混合应用程序，因为它们是原生和Web技术的结合。

图9-8 iPhone上的Facebook是一个混合型应用程序。

iPhone上的Facebook是一个混合型应用程序，它的某些部分设计（比如那些新闻消息）使用了Web技术。

相似地，根据我们以前看到的，Web应用程序也可以是混合型的。由HTML、CSS和JavaScript编写，并使用Flash展示丰富交互内容的网站，是一个混合型的Web应用程序。

今天的许多应用程序都是混合型的。你如果能够掌握HTML、CSS和JavaScript技术，无论是在现在的平台或者那些未来几十年将变得流行的平台上设计应用程序，你将都不会感觉到吃力。

克服思想偏见

通常，影响我们做技术和设计决定的不是选择最好的技术和工具的渴望，而是思想偏见。Web标准的拥护者往往会置用户的需求于不顾，盲目地为任何项目推荐Web平台和原生Web编写技术。还有一些Web从事者往往也会盲目地为任何项目推荐Flash和原生iPhone或iPad应用程序。“当你只有一把锤子，一切看起来都像是一个钉子”这句话立即涌入我心头。因此，重要的是你要认清这种偏见，基于用户需求而不是思想偏见做出决定。当然，能够认清偏见以便你能够正确地从设计角度来展开讨论，这也是同样重要的。

一些Web标准的拥护者设想，Web平台和Web编写技术本身就是好的。一个不争的事实是，像古登堡印刷术（Gutenberg Press）一样，互联网和Web（扩展点说）对世界确实产生了激进的民主化的影响。然而，Web平台和编写技术本身既不好也不坏，它们能够被好好地运用，也很容易被误用。

对于Web平台来说，最普遍的假设就是它本身就是好的，因为在Web平台上运行的任何一个文档或应用通常都是所有人可以获得的。这对于开放的文档收集（Web早期时内容展现的一般形式）来说，这或许是对的；如果对于今天流行的Web应用来说，这通常是不对的。以Facebook为例，它是一个Web应用，但它不是开放的。它是自由的，但这意味着你和用户都不是Facebook的顾客，你是Facebook的产品。[7]

Facebook将你的个人信息和行为特征卖给它的真正顾客——广告商。难道这就能称得上比从苹果的App Store购买一个商业软件要更好，更开放？

真的不是。

事实上，你可以很容易得出结论：购买商业的iPhone应用是一个更尊重用户的透明的交易。你为它买单，然后便可以拥有使用许可。你变成了公司或应用制作者的顾客，公司赚钱的方式是透明的。在很多方面，这是一个更传统的商业关系。

当然，商业应用程序甚至能够以多种方式来利用你的数据，因此现在注意保护自己的隐私是很重要的。但问题是，仅仅是一个Web应用并不能神奇地使这种情况变好。

[7] 正如Andrew Lewis所说的那样，“如果你不为产品买单，你便不是顾客。你是被出售的产品。”samshed.by/discont

原生应用程序和平台正遭遇灭绝吗？

Jeremy Keith在Update会议上提出一个著名的观点，“编写一个原生的应用像是编码激光视盘。”这里暗含的意义是，像只读硬盘和激光视盘一样，原生平台因为Web的出现将会过时被淘汰。

我当然希望这不是事实，因为Web本身也是一个原生平台，并且随着像Web和Chromium（基于原生Web编写技术的）这样操作系统的出现，Web越来越像是一个原生平台（从传统意义上来说）。我们应该理解，Web要追赶的是一个移动变化的目标。一直以来，新的特征、用户体验的加强和更多内容不断地被加进原生平台之中。Apple则与之不同，他在2012年9月1日宣布iOS已经完成，并且不再创建新的操作系统或新款的iPhone和iPad，在这一点上，Web要花费几年来完成追赶。

我们知道，“原生”指的是一个平台的主要文化和语言，因此，预测“原生”的消亡，类似于说在将来不同的设备将不会有清晰的文化差异。

这个设想本身就是，未来单一文化将兴起。每一个设备上的每一个应用都将通过Web的组成部分进行展现，都将使用原生Web编写语言，甚至这些应用都将服务于Web平台。如果这些实现的话，这将是一个灰色和令人寒心的未来，人们很难控制他们自己的隐私，他们的设备能够轻易地变成无声的终端，这个终端被连接到大公司控制的云存储中。

例如，你不会再使用一个自己购买的处理文字的应用程序，你会在Google Docs中写东西，Google Dos将会分析你写的每个单词和句子，试图进一步理解你，理解你的身份和行为，以便能够更好地利用这些信息来操控你的商业性行为。

这并不能说明Web应用一定很不好，但它们本身不是绝对好的。

模糊不清的界线

一些设计师认为，Web的将来完全取决于丰富的Web编写技术如HTML,CSS和JavaScript，这些技术将能够更好地实现设备功能如可触摸、GPS定位、加速计和照相支持，但我不这么认为。我们很少提到原生应用如何追赶Web应用。在某些方面，原生应用的进步是很重要的，因为它们确实威胁到了Web应用，即使从历史的角度上Web应用享有核心的用户体验优势。

原生应用正在追赶Web应用的三个主要领域是，易于部署和访问，自动更新和无缝访问数据。

易于部署和访问

Web应用在用户体验上超越原生应用的主要优势是，易于部署和访问。在你的FTP应用选择[8]中点击“上传”按钮，世界上任何地方拥有URL地址的任何人都可以访问你的应用。[9]很简单。

无需下载一个压缩文件，然后寻找一个解压软件，找到存放文档的地方，解压它，然后安装它，运行它，最后发现它不支持你的显卡。那么，Web应用取得惊人的成功，这还有什么奇怪的吗？特别是像Gmail和Google Docs这样运行在可用性差的原生平台上的应用。

[8] 或者，如果你是真的行家，使用一个Git版本控制的话，你可以使用一个post-commit钩子来自动部署你最新代码给服务器。

[9]至少是在URL不被禁止的地方。

图9-9 原生Web应用和原生操作系统应用的用户流之间的界线很模糊。事实上，在基于Web技术的操作系统中，原生Web应用就是原生操作系统应用。

然而，由于app stores的发展，原生应用正在追赶Web应用的易于部署和访问。像苹果的app store，发现应用的过程和在浏览器输入URL一样简单。事实上，你可以输入URL进入App Store中的一个应用，然后在那里简单点击一个按钮就可以下载并安装它。

自动更新

Web应用本身可以总是提供自动更新的版本。事实上，我们甚至不考虑Web应用的版本，因为Web应用本身是没有版本这个概念的。

你一直使用Gmail的最新版本，你从不关注它是什么版本。

它不是Gmail7，它只是Gmail。[10]

相反，原生软件通常有个打扰用户操作流程的更新机制。不过越来越多的原生应用采用无缝的更新，这种情况正在发生改变。例如，你上次注意到Google Chrome更新是什么时候？从来没注意到过，它总是安静地更新。

无缝访问数据

Web应用拥有的另一个优势是，其用户可以从任何一个设备上访问他们的数据。当使用Gmail时，你从来不必担心如何将你的邮件从台式电脑上同步到手机上。它一直在那里。与之鲜明对比的是，原生平台上数据同步的噩梦。

然而，原生应用又在追赶。例如，Apple的iCloud的出现，使手动同步变成了过去式。在你的所有Apple设备上，你的数据一直被自动同步，你可以随时简单地使用它，不必担心同步的问题。虽然iCloud只是主要解决了Apple用户的同步问题，但其他跨平台技术（像Dropbox）也为其他平台解决了相似的问题。

只是又一个客户端

你仔细阅读前几节内容了吗？好的，你或许已经注意到了这三个方面（原生应用追赶Web应用的那三个方面）的发展趋势。这些方面中用户体验方面的优势取决于因特网的特征，而不是Web。Web只是基于因特网的一堆技术（HTTP和URLs）。因此，像Web一样，原生应用也在利用因特网的一些特征，进而追赶Web。

此外，一种新的用户体验形式出现了，那就是连续性客户端（coutinuous client）。连续性客户端体验（这个概念最初是由Joshua Topolsky[11]提出的），是指用户在一种设备上使用某个应用，在切换另一种设备使用该应用时，仍能享有无缝的持续性体验。

例如，你如果正在台式电脑上浏览你的Twitter，然后你又抓起你的手机，那么你就应该能够从相同的地方继续浏览。而且，当你到家的时候，你也应该能够在电视上从相同的地方继续浏览。

关于连续性客户端，一个很好的例子是Trillian即时消息应用。它能够在云端存储聊天信息，也能够实时地在你的所有设备之间共享你的信息，而且也能涵盖和同步你读过的和未读的信息，甚至能够利用“存在技术”（presence）知道你当前是在哪个设备上进行操作的，从而可以将最新信息只发到那个设备上。

[10] Topolsky , Joshua.“一个温和的建议：连续性客户端，”smashed.by/client.

[11] 在“我的网站将只支持最新版本的浏览器”的网站杂志上，阅读“一个版本的宣言”：smashed.by/netsu

图9-10 Kelly Sommers有一个很好的示例应用程序，它体现了连续性客户端的体验：smashed.by/multi.用户能够在他们的Windows Phone7上观看视频，也可以在Web客户端继续观看，当然也可以在他们的手机上继续观看。

如果你设想下，你就会知道在连续性客户端体验时代，Web变成了JAC（just another client仅仅是另一个客户端）。在某种情境下，或许Web是最好的客户端，但用户还是应该能够切换到一些原生客户端的，而且不必担心同步数据的问题。随着高科技的发展，连续性客户端将很快成为主流，而不是一个新奇的期望。例如，iCloud的出现，使开发者能较容易地实现它们。

图9-11 关于连续性客户端体验，即时消息应用程序Trillian便是一个很好的例子。（Image: Trillian Blog, smashed.by/trillian.)

原生是未来的趋势

今天，Web仅仅是另外一个原生平台，展望未来，它不得不凭借自身的独特优势与原生平台进行竞争，而不是凭借Internet赋予它的优势，因为其他原生平台也正在实现并拥有这些相同的优势。

当你决定你的下一个应用是使用Web平台还是其他平台时，你要回答的一个棘手问题是，是采用原生应用来展现用户界面，还是通过访问URL和HTTP服务器，这两种方式哪种更好。

Web应用也正在实现原生平台的一些功能（像本地存储和离线运行模式），Web应用和原生应用之间的界线越来越模糊了。像Palm Web和Google Chrome这样的操作系统表明，原生技术就是Web技术。

我们需要了解，运行在这样一个操作系统上的Web应用是一个原生应用。这样说来，我们只是要决定采用哪种原生操作系统和框架，选择一个能够提供良好用户体验的操作系统。然后，我们还要选择合适的原生辅助技术——原生Web应用上的HTML、CSS、JavaScript、原生iOS应用上的Objective-C、Cocoa Touch、Java、Android应用上的Android SDK、C#和Windows Phone 应用上的.NET等等。

最后，无论哪一个平台和技术赢了，很明显地，将来的趋势都是原生，Web仅仅又是另一个客户端。现在，关键问题不是“我们是要Web还是原生？”，而是“我们的新产品应该支持哪一个或哪几个平台，应该采用哪种客户端技术或哪些客户端技术？”

要回答这个问题，我们需要了解我们产品的本质，特别是，我们的产品介于文档和应用之间时。

文档和应用之间

Web产品一般会被分为内容型和行为型两种。我们通常将内容型的产品称为一个网站，行为型的称为一个应用。你的产品可能不属于这两个类别中的任何一个，可能是处于这两种类别之间的。

当一个产品更接近内容型时，我们会使用渐进增强的技术分层实现基本功能和基于内容的核心交互动作，以此保证更多的人们能够访问到。这些渐进增强的功能通常既不是先进的格式或布局，也不是一些别出心裁的导引类交互行为。我们可以使内容适合于不同尺寸的屏幕，使有限的导引类交互行为适合于不同的输入机制。这不是一项简单的工程，但也不是不可能实现的。 图9-12 文档和应用之间

然而，当产品从文档型向应用型转变时，实现渐进增强将变得更加困难。事实上，这也可能会变得完全没有意义或不可能。例如，你将怎么优雅降级一个图片在线编辑器？在一个不能显示图形的功能型手机上，一个图形编辑器应如何工作？你将会使其显示什么内容？

图9-13 当Web还只是用来收集文档的时候，Web的创建者Tim Berners-Lee提出了Web的通用原则。这不太适用于应用程序的设计，因为应用程序有着不同的设计限制和要求。在.Net magazine(smashed.by/netmag)上可以看到Lea Verou对John Allsopp反驳的评论。

应用不是内容型的，而是行为型的。无论应用程序是什么内容，我们对其进行优雅降级将不总是有意义。应用通常是完全由行为构成的，这些行为促使用户去创建内容。再来看图片编辑器的例子：图片编辑器本身没有任何内容，但它能够使用户创建内容。

为了创建卓越的用户体验，我们需要保持专注，尽可能以最好的方式去满足我们用户的需求。

假设时间和资源不受限制，我们可以优化我们的应用在每一个设备和平台上的用户体验。然而，假设在实际项目中我们的时间有限，预算也有限，我们就必须要选择满足哪些用户，解决哪些问题，优化哪些平台和设备上的产品。我们这么做不是要去除不必要的用户，而是因为我们意识到，为每个人提供卓越的用户体验是不切实际的。

毕竟，没有哪个产品团队有足够资源来创建一些能够为每个用户都提供卓越用户体验的应用。

移动文档式产品（网站）设计考虑的因素

对于连续文档流的网站，它更倾向于是内容型的，一个网站包括内容和内容的展现形式。内容可以是文字、图片、声音和视频等等，为了添加语义结构，这些都是由HTML语言标记的。内容的展现形式包括视觉布局和交互元素（比如不同页面或状态之间的导引），通常这些是由CSS和JavaScript一起实现的。

如果你有一个网站，你首先应该做的是在一个移动环境下测试它，看下它是如何显示和执行的。我曾经遇到过许多公司，他们都忽略了网站移动化的重要性，直接创建了一个原生应用。你要小心以免犯这样的错误，尤其是网站是你的重要收入来源。对于文档型的网站来说，只要有可能，你就可以使用渐进增强技术来分层实现网站内容和引导类、娱乐类的核心交互，尽可能使更多用户访问到这些内容。

你如果要这么做，可以按照以下这些步骤：

1. 确保每个人都可以访问你的内容，使用合适的语义标记内容，将内容和展现形式分离是关键。
2. 渐进增强你的内容，使之为使用不同屏幕的用户提供更良好的体验（这也是当前响应设计所主要提倡的）。
3. 渐进增强你的内容，使之为一系列拥有特性和潜在能力（例如，可触摸技术）的设备提供更加良好的体验。换句话说，在不同设备上使网站的行为方式达到响应，而不仅仅是布局方面。在这一点上，你是在优化功能，不是某种设备（也就是说，优化支持触摸的所有手机设备，而不仅仅是iPhone）。
4. 渐进增强你的内容，使之支持各种设备的独特文化和能力。在这一点上，优化某种设备是正确的。试图创建尽可能优秀的用户体验没有什么错，即使是某段时间内只为了某一部分用户而设计。

确保在实际的设备上测试你的设计

当你在开发应用时，一个模拟器或仿真器可以很好地测试代码变更的效果，但是他们不能使人感知到设备本身具有的独特的人机工程学特征。使用情景也是一个影响移动体验的关键因素，例如：在有着完美光照条件的办公室中，能够很好工作的设计产品，在强光照的室外，它可能就不能很好地工作。

同时，你要记得，当你使用模拟器测试时，驱动运行这个应用的是你的电脑硬盘。而当应用运行在实际设备上时，你可能会看到一个更慢的反应速度（即使是很简单的操作行为）。

当然，这些步骤将很花费时间，也很花费资源，你将需要根据情况制定计划和预算。但是，如果在特定例子中，制作响应式的网站不能满足你的用户需求，那么你应该怎么办？或许你需要在计划的时间和预算内提供一个比渐进增强更加优化和专注的体验，或者你需要一个不单单支持浏览器的一级设备？在这种情况下，你可能会开始思考是否要创建一个应用，如果要创建的话，是否要创建一个支持多平台的应用，然后你应该使用哪种技术来创建它。

跨平台还是单平台？

运行在跨平台上的应用能满足用户的需求，还是运行在单平台的（至少是最初）能满足？

当回答这个问题时，你要记住，创建一个单平台的应用并不意味着你以后不能为另一个平台创建应用。它只是意味着你刚开始将在一个平台上（或者可能甚至是一个单一的设备）专注你的设计和开发。

这本身也并不意味着你是要用自然二进制创建应用，还是要利用设备的本地组件来创建应用。（使用跨平台辅助技术来优化一个单平台应用是完全可能的。）

然而，这个问题的答案将决定你在不同平台上必须做的优化量。如果你关注用户体验，你必须优化你们的应用在每一个平台上的体验。这也将影响你必须做多少测试（因为你将需要测试你产品支持的每一个平台），你的支持部门的大小（因为你将需要排除每一个产品支持平台的用户问题），以及你需要为这些功能分配多少时间和预算。

一劳永逸的秘密

我曾经遇到的许多设计师会犯的一个普遍错误是，他们使用跨平台辅助技术编写一次程序，然后使用在各种平台上，这是一个谬论。这么做将会使设计师大大低估了跨平台设计的复杂度。

使一个应用很好地运行在多平台上的唯一方式是，优化应用在每一个平台和设备上的体验。就像先前提到的，每一个平台都有它自己的文化、语言和规范，这也是用户期望应用遵守的。并且大多数用户不关心你的应用运行在几种设备上——他们只关心应用在他们设备上的体验。

设计师如果不考虑各个平台的独特文化、习俗、语言和规范，那么将不会使他们的应用名声在外。应用将会看起来很陌生、不必要地花俏、更加傲慢和简单，因为他们缺少文化。

你的应用可能是运行在多个平台上的，但这很少（如果有的话）能意味着他们在这些平台上运行得很好。

因为我们不想让我们的应用出现这种情况，所以我们必须优化我们的应用在每一个平台上的体验。我们的目标是在各个平台上创建具有相应语言、规范和习俗的应用。否则，我们便是对我们的某一部分用户不尊重。

千刀万剐

当然，你可以做的最糟糕的事情是，创建一个要求很低的应用，在任何平台上体验都很差，从而平等地不尊重你的所有用户。在这一点上，你的应用将会是最容易失败的。因为运行在大量的设备和平台上，你的跨平台应用即使可能有潜力获得大量用户，但它在各个平台上的用户体验都很差。坦率地讲，谁关心它是否在某个特定平台上体验很差？

更重要的是，在这些平台中的某个平台上，如果有一个设计优秀、精美优化、用户体验愉悦的竞争对手出现，那就会发生什么？

那如果是不同平台上出现不同竞争对手呢？

在不同的平台上，你的应用会因为优秀的替代品被放弃很多次，这将是千刀万剐。除非你的应用能在多平台上运行得很好，要不然支持多平台不是一个优势。你可能会率先占有市场，但很快就会被更好的竞争者所打败。

编写一次，优化各个平台

一劳永逸是一个危险的神华。有竞争力的跨平台应用的诀窍是编写一次，然后优化其在各个平台上的体验。你必须要理解这意味着你的预算和时间规划要足够用来优化、测试和支持你每个平台上的产品。

请不要被各个工具供应商误导“在5分钟内可创建一个跨平台应用”，他们不懂这个，除非你是在创建最简单的to-do列表应用。一个开发技术的真正测试不像你创建一个5分钟小样那么简单，也不像完成7%目标那么快速，更像是解决过去的3%的开发问题一样简单，这包括占据1%的所有重要的用户体验优化。在开发应用过程中，这些细节最终占据了你大量的时间和精力。

Web和其他跨平台技术

广义地说，跨平台技术可以被分为两类：创建原生二进制的技术和那些其他的技术。我们也可以按照是否使用原生框架来对它们进行更一步的分类，二进制-框架矩阵图如下：

图9-14 二进制-框架矩阵图

原生二进制是一个可以由某种设备的操作系统直接驱动的应用程序包，这是我们提到原生应用时通常会想到的。

然而，最重要的原生测试是判断应用是否利用了原生框架。这些框架体现了平台的文化、语言、姿态、风格和规范。

包裹着自然二进制的外来应用（披着羊皮的狼）

不使用iOS中Cocoa Touch框架的本地组件，而使用像Adobe的PhoneGap这样的技术来创建一个iPhone的自然二进制是可能的（也是很容易的）。PhoneGap包裹了一个现有的Web应用（该应用使用了本地Web组件），创建了一个原生操作系统应用（在上述的例子中，创建的是一个本地iOS应用）。虽然你的应用在iPhone的主屏幕上看起来像一个原生应用，运行起来也像原生应用，但应用的用户界面使用的是Web组件[12]。

你的二进制应用只是一个包括WebKit组件的外壳，这个WebKit组件使你的Web应用使用了Web组件。因为Web组件不能满足原生预期，所以我将不会推荐使用PhoneGap来创建像productivity这样的非沉浸式应用。[13]

然而，当创建像电子书和游戏这些沉浸式应用时，使用缺乏原生框架的相似技术将不会是一个大问题。Adobe Flash、ActionScript、Unity和Ansca的Corona都是原生游戏和电子书应用制作商喜欢使用的，即使它们不使用原生框架或组件。这是因为沉浸式应用很少（如果有的话）使用原生组件。相反，它们的设计师致力于创建一个拥有自己的规则、交互动作和文化的完全不同的世界（或许看起来和操作起来更像是真实世界的一本书）。

就像我不推荐使用PhoneGap创建非沉浸式原生应用一样，我不推荐使用Adobe Flex（或使用Flash框架的一些应用）：它们不遵守原生平台的文化，操作方式也不同于其他原生应用。

总之，当创建一些不使用原生组件的自然二进制应用时，你要额外小心。这些应用虽然看起来像是原生应用，但它们的操作方式与原生应用截然不同，因为它们没有使用原生框架中的原生组件。使用jQTouch框架的PhoneGap应用运行在iPhone上时，可能看起来像是一个iOS的table view，但这只是巧妙利用CSS和JavaScript来达到相似的视觉效果。它看起来是一个iOS table view，但它不能实现真正的从Cocao Touch框架组件中iOS table view应有的交互行为，最终创建了一个原生应用的预期但却不完整。[14]

创建一个不能满足的预期严重影响了应用的可用性，我们要避免这么做。

沉浸式VS非沉浸式应用

理解沉浸式和非沉浸式应用之间的区别是很重要的，因为对于沉浸式应用来说，应用的原生性不是问题。

沉浸式应用通常占据整个设备，创建他们自己的文化和语言。游戏便是一个很好的例子。对于奔跑、跳跃和射击这些操作来说，一个游戏可以有它自己的控制系统。一个好的游戏不必遵守平台文化，可以使用户沉浸在应用创建的世界之中。沉浸式应用通常很少（如果有的话）体现平台的传统文化，他们主要使用非原生技术。

这解释了为什么Web上的游戏通常会使用Flash来表达沉浸式体验，而不是使用Web的原生组件；也解释了为什么iOS和其他平台上的许多顶端游戏通常会使用Unity，而不是使用Cocoa Touch中的原生组件。

非沉浸式应用（像productivity应用）通常会使用像按钮和table view这样的标准用户界面元素。他们会使用平台特定的交互规范，像在iOS平台上他们会使用“master-detail”切换全屏，在Windows或OS X平台上，他们可能会使用树状视图控制。非沉浸式应用使用运行平台的原生语言，遵守原生文化和规范是如此地重要。

虽然这么说，但对于沉浸式应用，场景表现仍然很大程度上决定了游戏是要使用原生技术，还是使用非原生技术。为了表现很炫的效果，某种游戏（像第一人称射击类游戏）会细化场景的每一点表现。在这些情况下，一些非原生技术可能就不能满足这个需求了。例如，早期，iPhone上基于Flash技术的应用的速度很慢，虽然Adobe公司已经对iOS系统上的最新版本做了提升，但情况还是不容乐观。

由非原生语言转化而来的原生应用

如果你的目标是提供一个优秀的用户体验，当创建非沉浸式原生应用时，一个好的跨平台方法是使用原生框架和组成。但这不意味着你必须使用相应平台的原生编程语言来撰写你的应用。

例如，使用Appcelerator的Titanium Mobile SDK时，你可以编写JavaScript来实例化和引入原生组件。[15]这样，在iOS平台上，当你在Titanium Mobile中创建一个table view时，一个原生的Cocoa Touch table view组件将被创建在你的用户界面中。这不仅看起来像是原生table view，而且确实也是一个原生table view。更重要的是，它能像原生table view一样运行。

你使用像JavaScript这样的脚本语言时，程序编写会更容易，而且使用团队现有开发技术的同时，你仍能享有在原生应用中使用原生组件那样的优势。

同样，Tianium Mobile是一个跨平台技术，因此它可以为你的原生iOS应用实例化原生iOS组件，同时也可以为你的原生Android应用实例化原生Android组件。优势很明显：你使用一种脚本语言（JavaScript），只需维护一个代码库，而不必学习和使用iOS的Objective-C和Android的Java，维护两个代码库。

缺点是，你要处理一个抽象层。最终，你应用的质量将取决于Appcelerator在它的抽象框架中编写的代码的质量。你将要考虑Appcelerator对原生框架和SDK新特性的发行速度。虽然Appcelerator在Titanium中尽可能使平台之间的差异透明化，但仍然还有一些差异（不是所有的文化）需要我们去强调和优化（记得编写一次程序，优化每一个细节）。

[12] PhoneGap 没有使用任何一个Web UI框架（例如，JQuery Mobile）。它只是让你在原生应用中包裹了一个Web应用。然而，无论你使用哪种UI框架（或者甚至你决定不使用任何一个Web UI框架），使用的组件也将是Web UI的组件，不是应用运行平台的原生UI组件。

[13] 相同的说法是，Web应用被加进了手机的主屏幕。问题是，Web应用看起来像是原生应用，运行起来也像原生应用，但是操作起来就和原生应用截然不同。运行中浏览器中的Web应用不会有这些缺点，首先因为它不创建原生应用这个预期。运行在浏览器中的Web应用是一个原生的Web应用，原生Web应用（就像是其他平台上的原生应用）有着自己的文化、传统、语言、规范和预期（即使在一些其他原生平台上这些可能不被明确地定义）。

[14] 你犯的最大的可用性方面的错误是，使一些非本地组件看起来像本地组件（就像JQTouch框架那样）。看起来不像本体组件的组件至少提供了不可能像本地组件那样操作的视觉线索，但非本地组件佯装成本地组件，视觉上一样，但操作上却截然不同，这迷惑了用户。所以你不要创建一种行为预期却不能实现它。

[15] 不要混淆Titanium Mobile和Titanium桌面这两者的概念。Titanium桌面的工作方式和PhoneGap一样。Appcelerator最近开发了一个开源的Titanium桌面（现在被称为桌面），同时也在集中精力提升Titanium Mobile：smashed.by/tita。

图9-15 一些常见的原生技术和跨平台技术之间的对比

原生并不一定更好，但它是原生的。

如果你要创建一个遵守既定平台规范（也就是文化和语言）的应用，那么唯一方法是使用原生技术。例如，在Web平台上，被创建的Flash应用将看起来和感觉起来都不像是使用原生Web编写技术（像HTML、CSS和JavaScript这样的）编写的原生Web应用。相似地，在iPhone这样的平台上，使用Cocoa Touch框架中的组件创建的应用，将看起来和感觉起来不像是原生iPhone应用。这并不说明，Flash应用没有HTML应用好。在某种情况下，特别是像游戏这样的沉浸式应用，Flash应用可能会提供更好的用户体验。举个例子，Machinarium是iPad上基于Flash技术的一款既可爱又漂亮的游戏。特别是对于像游戏和电子书这样的沉浸式应用，一个像Unity或Corona这样的跨平台技术可以减少开发时间，更容易地实现那些对于原生技术来说较难实现的功能。（比如一个3D环境或物理引擎）。

图9-16 iPad上的Machinarium，由Flash技术创建的一款沉浸式原生应用。

这不是说，你应该害怕跨平台技术，但你需要仔细思考，权衡利弊，最后做出一个明智的决定，是否要在开发过程中添加另一个抽象层。每一个跨平台技术都有不同的优势和劣势，各自适合某种类型的应用。Corona可能是2D图形化游戏的完美选择，Titanium Mobile则适合创建一个跨平台应用。

当然，Titanium不是唯一能创建原生二进制和使用原生框架的跨平台技术。如果你的团队拥有C#和.NET开发方面的技术，你可能也会考虑使用Mono（具体来说是iOS的MonoTouch和Android的Mono）。Mono和Titanium的工作原理一样，但不是使用JavaScript创建原生应用，而是要使用C#语言（注意，还有其他.NET编程语言）、.NET模式和工具。

Web应用程序

如果你正在读这本书，那么你要么已经是，要么正在学习并努力成为一名Web设计师或Web开发者（或者两者都是）。作为一名Web设计师，你可能会设计一些文档集（在这种情况下，你将主要凭借你的图形设计技巧），也可能会设计一些行为式应用（在这种情况下，你将要练习你的交互设计技能）。

当设计你的产品时，你拥有一系列工具可以选择。根据你用户的需求，你可能会选择像HTML、CSS和JavaScript这样的原生Web编写技术来创建原生Web应用；相应地，你也可能会使用像Adobe Flash或Unity这样的非原生跨平台技术来创建非原生Web应用。第三种选择是，你可能会使用原生和非原生相结合的编写技术来创建混合型Web应用。例如，最初由HTML、CSS和JavaScript创建的一个网站，最后使用Flash技术展现了一个丰富的游戏体验。

无论你是选择原生Web技术，还是选择非原生Web技术，被部署到世界范围Web平台上的应用就是Web应用。简单来说，这意味着你的网站或应用会拥有一个URL[16]，能够通过HTTP服务器被访问。

单平台原生应用

通过以上的学习，你可能会决定为单个平台或设备设计你的应用，投入你有限的时间和预算来优化那个平台的用户体验，从而最好地满足用户的需求。

如果你确实决定支持单个平台，你仍然可以选择使用哪种技术。如果你正在设计一款游戏或其他沉浸式应用，你可以选择使用一个跨平台技术从而使你的应用更易编写，比如：Ansca的Corona、Unity或Adobe Flash。

如果你正在创建一个非沉浸式应用，你仍然可以选择使用像Titanium Mobile或Mono这样的跨平台工具。这样做的缺点是，你的开发过程将涉及一个额外的转换层，你将较少地控制应用的优化，因为你将在一定程度上依赖Titanium开发工程师编写的原生代码。即使你不使用Titanium（或像Mono这样的相似框架），记得你仍然将不得不学习你开发平台的原生框架（或APIs）。学习新的框架比学习新的编程语言要更加困难。一个经验丰富的程序员能够在短短几天内就学会像C语言这样的编程语言。然而，如果要让他们完全理解和适应框架（像Cocoa Touch这样）的形式、文化和复杂性的话，则要花费几周的时间（如果不花费几个月或几年时间的话）。

最后，你也可以使用你平台的原生工具。例如，你可以使用Xcode（使用Objective-C语言编写的）和Cocoa Touch来创建一个原生iOS应用，或者使用Eclipse（由Android软件开发者包组成的）来创建一个原生Android应用，或者使用Visual Studio（使用Objective-C语言编写的）和.NET框架来创建一个Windows 手机应用。

这意味着，你将要学习一种新的编程语言（iOS平台的Objective-C语言、Android平台的Java语言和Window Phone平台的C#语言），或者你要雇用一个了解语言和体验过原生框架的队员。就像刚才说的那样，学会一种新的语言很容易，但学习一种新的框架很难。你要时刻记住这一点，特别是你团队中没有人拥有这项技能，而你要决定是否走这条路的时候。

使用原生技术创建一个原生应用的优点有很多。首先，你可以灵活优化应用的用户体验。当你使用原生组件并遵守相应平台的人机界面交互规则时，你的应用将会和平台的文化、语言和规范保持一致，你的应用也会更容易被理解和使用。同时，你不必依赖于一个额外的抽象层或转换层，将会使用开发商最新的代码和框架，使你的应用较好地适应平台新的特性和更新。最重要的是，集中精力支持单个平台意味着，你可以首先把精力放在优化应用本身的用户体验上，然后如果有必要的话，再支持其他平台。

为人类而设计

你决定使用的平台和技术将影响到你的产品如何被获取，你的产品看起来和感觉起来怎么样，是否能满足（或超出预期）你用户的需求。这不是一个轻易的决定。

如果你关于平台和技术的决定仅仅是因为你先前短期的商业目标或你团队当前的能力，那么你正在作的决定解决的是你自己的问题，不是用户的。这可能会为你带来短期的利益，但你将不能解决用户的问题，不会走得很远。你应当基于用户的需求，作出关于平台和技术的决定，不带有任何思想偏见，不因短期利益而放弃长期目标。

记得，我们已经有很多这样失败的例子了，我们不再需要更多，我们需要一些成功的例子。做一些明智的、合理的、娱乐的和愉悦的事情，使用正确的工具和技术。

[16 更精确来说是URI，URL和URE之间存在一些技术上的差异，如果一个W3C标准偏执者粗略区分它们之间的差异，那么他将会口吐白沫的。

关于译者

钱叶丹 就读于浙江大学工业设计系，曾经是一名工科学生，却与设计偶遇。曾获得德国红点设计大奖等多项国际奖项，目前在腾讯ISUX团队实习。擅长整合设计和创新设计，在设计过程中重视与客户之间的合作方式和沟通方式。

爱行走，也爱坐过山车，想从山顶乘滑翔伞而下，让自由包围自己。爱音乐，也爱小动物，爱这些生活中的美好瞬间。有设计师的职业病叫固执，也有一种情怀叫热情。总之，想活的丰富真实一些。

关于校对

余果 曾经在西安电子科技大学学习软件工程，却热爱前端开发，因为前端做出人人都能直接体验的产品。目前在腾讯ISUX做前端开发。比起文字，我更喜欢图像；比起技术，我更喜欢设计；比起坐而空想，我更喜欢动手完成一个产品。空闲的时间喜欢读书和开发软件，以及享受美食。