Fresset Ltd （一个小型web广告公司）公司的联合创始人Lea Verou在本文中

这是关于W3C工作组的系列文章的第一篇，主要关注CSS Working Group及相关工作。我觉得在我开始发表文章之前，有必要先清除一些关于web标准的广为流传的神话，并简单讲一下标准化进程是如何工作的。

为了简单及精确起见，下面列出了一些术语，这些术语在本文中得以使用，在大多数与标准相关的讨论中也使用了这些术语：

Authors：开发人员，设计人员，或者说任何使用web技术的人。

Implementors：例如，那些提供开发者工具（developer tools）的公司。

Spec editors：撰写标准的人。与人们惯常的想法相反，他们并不是创造web技术的人。在下面你将更多读到关于这一点的内容。

浏览器创新与W3C创新（browser innovation vs W3C innovation）是一个广为流传的二元对立，然而这样的对立是错误的想法。简单来说，W3C实际上是implementors！Web标准是通过在Working Groups (WGs)中达成共识来实现的。这些WGs包括了各implementors的代表，主要是浏览器的代表。每个WG都有少量W3C成员，但他们只占少数。例如，在CSS WG中，现在有74名成员，其中只有4个（5.4%）是W3C成员（Bert Bos, Richard Ishida, Chris Lilley 以及 Liam Quin）。当然，浏览器通常自己先进行创新以后，然后随后再进行标准化（例如，rag & Drop API, CSS transitions, CSS transforms, CSS animations），但这样是很冒风险的，应该尽力避免。如果一个特写在标准化之前就广为流传了，那么，WG可能被迫去解决欠佳语法问题。

如果你是在为一个成员公司工作，成为一个Working Group成员确实要容易得多。当然，除此以外，你还可以成为一个特邀专家（Invited Expert），但这对大多数WGs来说，都是分成困难的。CSS WG现在只有四个特邀专家（Molly Holzschlag, Koji Ishii, Brad Kemper 以及 Anton Prowse），在74名成员中只占5.4%。

然而，如果你想要有所贡献，并不非得是WG成员。每个WG都有一个公开邮件列表，每个好的想法都会被考虑，不论这个想法来自于谁。通常，一直在跟进某个列表的人可能会有更为有效的建议，因为他们对相关术语更为属性，并明白其中可能有的局限，但是这些对于提出一个值得考虑的想法来说，都不是必要的。

类似的，坏的想法都会被拒绝，即使这个想法来自于WG成员。这对于保持标准的高质量来说是非常重要的，因为任何人都可以加入WG。对于一个公司来说，要想成为W3C成员，所要做的只是有足够资金去交年费。任何一个来自于W3C成员公司的人都可以成员W3C成员，只要他们有时间，并且他们的雇主同意他们这样做。

实际情形并非总是如此。W3C采取两种方式工作模式：

1. 先审查，再成文：首先，每一个细节都会在WG中进行讨论，然后editor必须将讨论结果写成正式文字 (正如某人所巧妙表达的那样，”忠实记录工作组的共识”).在这种工作模式下，editor和其他任何活跃参与这个讨论的人有相同权力。
2. 先成文，再审查：editor有更多权力去定义某种技术并在随后对标准的审查中也拥有更多权力。

CSS WG 主要是工作在第一种模式下，但并非每个WG都是如此。

标准(specifications)实际上主要是为implementors写的，比如浏览器提供商（browser vendors）。有一些editors会将标准写得更为 author-friendly，但这并非是必须的。

在实际操作中，一旦一个标准达到候选推荐（Candidate Recommendation ，CR）状态，几乎就不会再有什么重大改变了。早期的一些状态（工作草案”Working Draft”和编辑草稿”Editor’s Draft”）是还在改变过程中的标准，因此，一般都会发生改变。在这些状态下的标准实现，通常是被看做实验性质的，甚至在CSS中，是需要加前缀的，以免与将来成形的更为稳定的对应标准发生冲突。在过去几年里，authors对实验性质依赖太多，将它们当做稳定标准。因此，这些实验性质的标准似乎就是标准，即使不可信，但实际并非如此。即使一个实验性的特性在web上广为使用，大多数WGs对于改变它们也颇为踌躇。这并不太好，因为这些特性往往并不完美，但是又不可避免要去使用，因为用其他方式的话将会使很多站点无法工作。

在CSS 2.1之后，CSS被分解成很多模块，每个模块都有自己的版本。建立在现有CSS 2.1特性之上的模块被称为是”Level 3″，但是新开发出的一些新的特性被认为是从”Level 1″开始的。不幸地是，很多新的起源于Level 3的模块，进一步促进了”CSS3″这个流行语的普及。然而，很多新模块（比如Variables），是起源于Level 1的。

从历史上来看，”CSS3″被用来描述在CSS2.1 之后出现的不管是什么级别的任何模块或者明确是Level 3的模块。这两种定义都有他们的问题。如果它是用来描述出现才CSS2.1之后的任何模块，那么如何区分CSS3 和 CSS4？如果它是用来描述明确属于Level 3的模块，那么它就毫无理由地排除了很多新的CSS模块。

这是测试的一个很有用的功能，但是从推进W3C Recommendation的角度来说，测试只是为了确保标准中特性的可实现性，这意味着当浏览器无法正确实现某个特性时，可能并不是这个浏览器的错。原因可能是这个标准写得不好，或者这个特性很难实现如它描述的那样，或者implementers对这个标准没有足够兴趣。通常，当有至少两个浏览器通过测试以后，该标准就能继续推行。

完全不是这样。当W3C在1994年创建的时候，CSS根本就不存在。除了CSS，很多其他重要的web技术都是由W3C创建的，要么是由它独立创建，要么是和其他标准组织进行了合作：

• HTML
• DOM API
• Selectors API
• XMLHttpRequest
• XML
• SVG
• MathML
• The PNG file format
• SOAP

还包括很多其他重要的web技术。进一步说， CSS WG甚至不是最大的 WG。例如，WebApps WG有146个成员.

• 关于W3C 进程的详细文档
• W3C本身对 CSS Working Group 的内部看法

原文链接：The top 8 web standards myths debunked

您可能也喜欢：
Web APIs vs APIs for Web-based OS	与瀑布模式说”再见”：教你5个步骤实现响应式Web 设计	海豚浏览器CTO刘铁锋：Web App对企业移动开发的影响	LinkedIn和FT再次引发web app和native app之争
无觅

Mathew Marquis在W3C响应图像社区组织发表的一篇帖子中就解决web上的响应图像问题提出了概括的建议。

目前，大多数解决方案需要一定的脚本和工作环境的支持，这就使得很多用户不得不下载一些额外的数据。然而，随着高分辨率显示越来越普及，web设计人员也越来越多地使用web响应设计技术，这就迫切需要制定一种标准以供参照。

Marquis提出了一种关于解决现有’img’元素问题的建议，他增加了新的语法（通过新属性‘set’）来解决多源问题。然而，响应图像社区却提出使用‘picture’元素，利用多个’source’元素来确定特定尺寸或特定象素的设备视口中的图像。

Marquis说，基于’picture’的方法相对于现存的方法而言，开发者用起来更加方便。他还征求了开发者们的意见并在文章结尾提出了多种实现清晰表达的方式。

这些提议引起了很大的争论。虽然开发者们广泛赞同picture方案，适应图像创始人Matt Wilcox说，’set’太糟糕了，语法不清晰，过度地依赖于图像尺寸和象素密度，在“像素已经死亡的时代”使用象素。然而，他也很讨厌’picture’当中的重复。其他人注意到虽然’picture’这一术语的语义与字面不太一致，但至少其语法与’video’元素中的语法是一致的。

作者：Craig Grannell，发表于2012年5月14日

译者：林建光

原文链接：http://www.netmagazine.com/news/responsive-images-proposed-whatwg-121959

您可能也喜欢：
50种响应式web设计的奇妙工具	与瀑布模式说”再见”：教你5个步骤实现响应式Web 设计	响应式图像设计——Part 1	破除八大Web标准迷思：只有大公司才能影响标准制定吗？
无觅

一、移动互联网的主要开发者

技术归根到底是为解决问题而存在的。毫无疑问，移动设备上的相关开发技术同样也是解决IT产业的问题而存在。我们可以比较粗浅地把需要使用移动开发技术的公司分成如下几类：

• 移动互联网公司。移动互联网公司是完全新兴的公司，也是伴随移动互联网公司兴起而诞生出来的新行业。从2008年开始算起，至今不超过4年的时间。而移动互联网确实对移动互联网技术跟进最迅速，也是被移动操作系统的发展驱动的公司。不管是Android在短短的十年时间从1.5的版本发展到现在的4.0，甚至半年之后的5.0版本，还是iOS从07年发展到现在5.1的版本，移动互联网公司都是一路追踪最新的技术发展，成为行业成功范例最多的公司。不管是刚刚被被以10亿美金收购的Instagram，还是刚刚被估值到2.5亿美金, 靠超酷界面咸鱼翻生的Path，还是被誉为最强交互实现的Clear 。移动互联网公司总是利用移动设备的各种特性，为用户带来异想不到的惊喜。

• 传统互联网公司。互联网公司和移动互联网其实一脉相承，游戏的规则并未发生任何改变，而仅仅是流量入口从PC转移到了移动设备。而对于传统互联网公司来说，并无所谓Web App以及Native App的负担，因为他们所有的业务都构建在Web基础之上。

• 传统企业。传统企业是对外界变化响应较慢，但同时却又是从业人员最多，开发需求最贴近真实用户的一个群体。他们会更加稳重，但是更不愿意承担技术选型的风险。

因此，根据这个粗浅的分类，我们能够感受到移动互联网开发技术的传播速度。会由移动互联网公司兴起，然后影响互联网公司，最后辐射到企业开发中来。而移动设备的爆发性增长，同时也激发了企业移动开发的需求与发展。

二、传统企业开发的特点

根据笔者的经验与认识，笔者把不使用IT技术作为主要盈利手段的公司，统一视为传统企业。比如说重度依赖于IT技术的金融业、证劵业，以及轻度依赖于IT技术的零售业，制造业等，甚至于政府的信息化需求，这些都可以认为传统企业。这些IT技术的发展主要针对企业内部需求，开发出的系统和产品主要针对企业自身的员工。

那么，这些企业内部的业务系统开发的主要特点如何呢？

• 以MIS系统为主。企业内部的业务系统，最主要的是依赖于IT技术来做信息的关系。比如大家所熟知的ERP系统、CRM系统、OA系统以及各种和企业业务直接相关的业务系统（比如制造业使用的西门子开发的各种车间管理系统，生产管理系统）。这些最重要的就是信息的输入输出和各种数据系统的应用。

• 以系统的集成为主。 由于企业里面生产企业繁多，一般一个中大型（规模在1000人以上）的企业的内部系统，可能会多达10几甚至是数十总不同的业务系统。因此，如何把信息系统集成，以统一的登录和身份验证系统实现，以及最后以统一的Portal来展现（比如微软的SharePoint），就成为了企业内部系统开发的重点。

• 以工作流的驱动为主。在企业内部，流程的运转和推动，就需要层层的审批以及批复。在国内特有的体制下，审批，签署，甚至于会签等各种特殊的需求都会直接驱动和影响企业的内部系统的构建以及实施。不仅仅是需要工作流系统的搭建，甚至还有配合BizTalk这样的消息队列系统才能够完整实现企业系统的搭建和部署。

• 以业务的需求为主。企业内部系统的搭建，往往更多地需要以客户的业务需求来做各种自定义化的工作，因为不同的行业完全不一样。因此在企业系统里面，有部分像SharePoint/BizTalk之类的平台级的产品，也有Dynamic CRM之内的客户端关系系统，但往往要根据客户的业务需要做自定义的开发。

因此，这就是传统企业应用开发的主要模式。在过去20年的发展中，B/S模式因为没有系统升级、部署麻烦的负担（想像给10，000人的企业升级一个软件）而成为了主流技术。 但是，移动互联网时代，企业面临的最大挑战是如何将这些信息系统搬到智能设备上去。是选择客户端的开发技术，还是沿用B/S的网页展示方式，这成为了一个最大的问题。

三、传统企业开发往移动互联网开发的难点

正如大家所知到，企业业务系统开发的难度在于系统的集成，主要的开发逻辑在于业务需求的复杂。而面对移动互联网的兴起，尤其是移动互联网操作系统的分裂，对企业业务系统的开发带来了极大的困扰。

• 多开发平台带来的学习成本。因为企业系统开发的特殊性，企业业务开发人员的技术需求主要在于处理数据的交换以及处理各种因数据处理带来的业务逻辑的实现。因此，并不需要特别炫酷的技术，一般都是采用相对成熟的开发技术，保证系统开发的速度和稳定。而面对iOS/Android/Windows Phone所带来的新的语言学习成本，开发框架的学习成本以及开发模式的开发成本，都成为了企业业务系统开发人员的最大障碍之一。

• 多平台带来的人力成本的开销。因为多移动平台的存在，因此原先只要使用一种技术，统一在Web里面实现的局面被打破了。企业需要的是懂iOS/Android/Windows Phone开发的三类人员，甚至需要把同一个业务需求做三遍。这对企业来说是非常痛苦的一件事情，而同时因为开发人员的短缺，同时会导致企业的用户成本直接增加。

• 开发团队的管理成本。对于技术管理人员来说，人员和技术的增加，会直接带来管理成本的增加。不仅仅是新的技术的学习和把握，还是需要管理移动开发团队的期望值以及技术发展路线，这都为企业技术管理人员来说，带来了极大的要求和挑战。

因此，在移动互联网时代，企业面对移动开发的需求处于非常纠结的局面。选择进入，成本不可避免地增加，不进入，看起来似乎会落后于时代。

四、Web App对企业的影响

Web App开发能力的发展以及HTML 5技术的发展，正是为企业移动开发带来了非常好的思路和解决方案。

• 开发成本的降低。毫无疑问，如果可以复用PC的开发技术，同时又能无缝地迁移到移动平台上，对企业开发成本的降低是非常直接有效地。因此，这是企业用户对各种跨平台开发技术非常热衷的总要原因，同时这也是推动跨平台技术以及Web App发展的一股重要力量。

• 减少招人的难度。由于可以复用PC的开发技术，那么懂业务系统开发的人员的招募就相对容易，也会直接减少企业内部开发人员的管理难度。

因此，企业内部的业务开发人员以及为企业提供开发服务的技术开发商，都会试用各种跨平台技术，做各种技术实现方案，来尽可能无缝地迁移至移动互联网平台。

五、结语

对于企业移动开发来说，最需要的是什么？

笔者认为，最需要的就是Best Practice。 还有人记得经典的三层结构以及各种展示技术的PetShop/PetStore的解决方案吗？这不知道给多少用户带来了遍历以及提供的技术开发的指导。

因此，对于移动开发来说，同样需要类似的东西。笔者认为需要两个方面的Show Case:

• 纯HTML 5的解决方案。这是一个相对激进的思路。企业可以考虑直接提供移动访问的网站，并且针对移动设备提供非常好的交互体验，从而无缝地由PC往移动设备上迁移。

• 基于PhoneGap类似的跨平台解决方案。根据Vision Mobile的报道，已经有62%的用户了解PhoneGap和Sencha之类的技术来实现的移动解决方案。这是目前最有可能帮助到企业用户的一种解决方案。

如果有这样的Best Practice出现，Web App将会在企业移动开发市场中占据重点的地位，也会更加快速地推动Web App的发展。

本文作者为海豚浏览器CTO刘铁锋，文章原发于《程序员》杂志。

您可能也喜欢：
LinkedIn和FT再次引发web app和native app之争	高通CDMA高级技术总监：下一代App OS是Web浏览器	Google Web App开发指南第一章：什么是Web Apps？	海豚浏览器CTO刘铁锋：Mobile Web App发展现状及展望
无觅

在这篇文章中，

我们正处于Web平台更新换代的过程之中。HTML5通常被用来描述这一过程，尽管更新换代中的技术并不局限于HTML5标准所定义的特性。

我使用了“Web平台”(Web platform)这个术语，代指能被Web浏览器支持的一系列协议、格式以及APIs。开发者使用这些特性来构建时新的一些应用，这些应用支持社会交互，并且充分利用了设备的能力，比如照相功能、麦克风功能以及GPS功能。HTTP、TLS以及WebSockets是Web平台中的一部分协议；HTML、CSS以及Javascript是Web平台格式中的一些例子。Web平台中的APIs包括Geolocation API以及针对<canvas> 元素的2D drawing API等。

最终，如果一个特性能被广泛实现，并且开发人员经常使用它来创建稳定的用户体验，那么这个特性就成为了Web平台的一部分。World Wide Web Consortium (W3C)功不可没，它让股东们坐到一起，统一开发一些免费标准，并创建配套资源，如测试集以及验证程序。

标准作为一个共享协议来说，是非常有用的，但是Web平台包括大量不同成熟度的技术，这些技术并没有都标准化。当开发者使用这些技术的时候，就会遇到一些实际的问题了，其中包括：

• 我该如何减少special-case code？
• 哪些代码现在是足够稳定可以让我使用的？
• 对于那些没有最新浏览器的用户，我该如何处理？

这些问题的答案随着时间发生变化，因此开发者已经制定了切实可行的解决方案，如fallback和“polyfills”（这将在稍后进一步解释）这些方案能让内容在老的浏览器以及最新的浏览器中都可用。在这篇文章中，我并没有关注HTML5标准的状态，而是探讨了一些有用资源，这些资源可用帮助开发者开始使用现在的开放Web平台技术（Open Web Platform technology）。这些资源阐明了使用HTML5的“原理与实现方法”，对标准进行了补充，并最终能加快部署。

platform.html5.org

对一个忙碌的开发人员来说，他该如何跟进最新的特性，了解什么fallbacks 以及、polyfills（如果有的话）是可以用的？我编辑了一个网站，platform.html5.org，它可以让你了解构成Web平台的最新技术。（它是由github repository支持的，我非常鼓励你来帮助维护这个站点，只需要使用forking the repo 就可以了，并发送更新请求）。

这个站点将技术进行了分类，如绘图和排版、多媒体以及存储。站点上的图标代表了每个技术的成熟度。绿色的小旗帜表示一个特性可以使用了。黄色闪电代表“需要谨慎使用”。然而，这些都只是很粗略的指示；要想真正了解这些特性，你需要点击后面的一些有用的链接，如下所示：

• HTML5 Please
• When Can I Use…
• MDN (Mozilla Developer Network)
• 其他一些提供了与特性相关的测试集的站点

特别的，HTML5 Please site值得作进一步的评论。它是由H5BP  developer collective（HTML5 Boilerplate背后的开发者小组）创建的。它根据名字列出了各个特性，并对每个特性的成熟度做出了高屋建瓴的描述。它还展现了一个状态面板，其中显示了各个特性的状态信息（可以使用/小心使用/避免使用，use/caution/avoid）。在某些情况下，”caution” 和”use”关键字后附加了”with fallback” 或 “with polyfill”。在有”with fallback”的情况下，你可以扩大该面板查看究竟如何为该特性提供fallback。

polyfill 是指一段Javascript代码，作为一个特性的某种shim；也就是说，它模拟了一个将来的API，这个API为老的浏览器提供fallback功能。

HTML5 Please的站点管理者让任何人都可以很容易为这个站点做贡献，他们在每个面板上都提供了一个“编辑该信息”（”Edit this info”）的链接，让你可以创建页面内容的副本，并将其提交给该站点。（该机制是由a github repository支持的，任何人对内容的修改都会作为pull requests提交）。该站点的维护者将会对内容进行审查并合并内容。

有时候你希望能看到比HTML5 Please所提供的信息更详细的一些状态信息。例如，你也许想确切知道哪些浏览器支持某个特定的浏览器，以及每个浏览器的哪些版本支持它，或者在移动浏览器中，特性受到什么程度的支持，以及那些浏览器的OS版本是什么。这时候，你就需要查看When Can I Use…站点了。

When Can I Use是由Alexis Deveria维护的。他跟进大量特性的状态，并在新版本的浏览器发布时更新站点。如果有某种特性是你想要了解但When Can I Use站点上还没有的，你可以建议该站点加上。

现在记录在When Can I Use上的每一个特性都有一个表，表中有一列是主流的桌面浏览器（IE, Firefox, Chrome, Safari以及Opera），一列是主流的移动浏览器（iOS Safari, Opera Mini, Opera Mobile以及 Android Browser），每一行是每个浏览器的版本号。和其他站点一样，用颜色标明了每个特定浏览器版本对一个特性的支持度（support/partial（部分支持）, support/no（不支持）, support/unknown（不确定是否支持））。

例如，可以看看 CSS Counters受到的支持程度。充满绿色条目的表说明该特性受到很好的支持。其他支持不是很好的特性是用红色标出的。

When Can I Use站点中的每个特性表都提供了一个”see-also”链接到相关特性的表，还有到第三方站点的链接，这些第三方站点提供了这些特性的使用信息，教会你如何使用这些特性进行开发。

MDN (Mozilla Developer Network)是platform.html5.org 和When Can I Use都加了链接的站点。可以将MDN看作”how can I use”特性使用指南。例如，如果你想要实现Web Workers，需要一些代码示例以及链接到有详细信息的资源，那么，MDN上就有个页面是关于 使用Web Workers的，它对于入门非常有帮助。

和HTML5 Please, When Can I Use以及platform.html5.org一样，MDN也是非常欢迎大家做贡献的，并让这个过程比其他站点更快捷简单：整个站点就是一个wiki，所以一旦你创建了一个账户，你就能编辑任何页面。

测试集（Test Suites）

对于评估一个特性的成熟度来说，没有什么方法比拥有一个完整的测试集更好了。你可以自己运行测试集，并分析结果。对于Web平台来说，并没有一个集中的库，也没有一个单独的地方可以让你看到所有结果，但是W3C已经开始着手建立一个共享测试框架站点，W3C CSS Working Group也在建立一个针对CSS的测试框架站点。

这些站点让你可以浏览各个浏览器以及各个浏览器版本对不同测试集的结果。你也可以在你自己的浏览器中运行测试集，并提交结果，让结果整合到框架结果数据库中去。例如， CSS的多列布局模块测试集的结果数据，或者 可以让你自己在浏览器中运行测试集的启动页面。

结论

前面提到的站点可以帮你跟进新出现的Web平台。我希望随着平台的成熟以及更多人分享他们的代码和经验，更多有用的站点能够出现。我很乐意你去使用我提到的这些站点，并将你自己的发现提交到这些站点，以便让关于Web平台的高质量的、最新的信息让大家都能共享。

原文链接：Developing in HTML5: The What and How

您可能也喜欢：
HTML5设计原理	HTML5游戏开发之将Easel.js和Box2d在画布中结合起来	在游戏中发挥HTML5 Canvas的潜能	Google Web Apps开发指南之项目样例（上）
无觅

避免不必要的复杂性
如果可能，简明的解决方案总是比复杂的解决方案更受欢迎。

HTML 4.01的文档类型是这样设置(因为浏览器解析的原因，我把尖括号省略了)：
!DOCTYPE html PUBLIC “-//W3C//DTD HTML 4.01//EN” “http://www.w3.org/TR/html4/strict.dtd”

XHTML 1.0的DOCTYPE是：
!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN”
“http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”

而在HTML 5中，省掉不必要的复杂性，doctype就简化成了：!DOCTYPE html

支持已有的内容
已存在的内容依赖于预期的用户代理处理过程和行为，来实现预期的功能。

支持已有的内容是指，对已存在的内容100%的支持。

解决现实的问题
对应网页内容面对的问题，不能迎合存在需要的摘要架构是胜不过实际的解决方案的。

举例子，假设我使用HTML 4或XHTML 1，对应一个整块内容，比如一个商品列表好了，有商品图、商品标题、商品简介等，我要分别给这三块元素加上三个相同的链接。然而在HTML5里面，你完全可以用一个a标签包含这三个区块。也就是，a标签包含块级元素。这解决了现实的问题。

求真务实
HTML5中新的语义元素就是遵循求真务实原理的反映。

假如你现在看网页，估计都会有这样的一些代码： id=”header” id=”navigation” id=”main” id=”sidebar” id=”footer” 然而在HTML5里面，新增的标签可以把相应的div替换掉，比如header、nav、aside、footer。别以为这些是id的替换品，不是的，新标签其实是替换class的，因为这些标签可以在页面中重复使用。

平稳退化
应该制定HTML5 文档的一致性要求，甚至利用新元素、属性、API和内容模型。这样，网页内容才能在更老或者能力较弱的用户代理中优雅降级。

就用HTML5表单来说明吧，input新增的type有number、search、range、email、date、url等，这些新type值在不支持它的浏览器里面，将被解释为text。所以，可以大胆使用HTML5表单，它做到了“优雅降级”。

最终用户优先
一旦遇到冲突，最终用户优先，其次是作者，其次是实现者，其次标准制定者，最后才是理论上的完满。

参考：HTML5设计原理–Jeremy Keith在 Fronteers 2010 上的主题演讲
PDF：design of html5

本文来自特邀译者@陈伟华vivien，转载请注明出处。

您可能也喜欢：
HTML5开发：原理与实现	HTML5游戏开发之将Easel.js和Box2d在画布中结合起来	HTML5视频发展状况	在游戏中发挥HTML5 Canvas的潜能
无觅

1.开发阶段：跨平台工具提供从低级到高级的各类开发语言，底层精简的语言比如LiveCode和Lua以及像HTML，CSS和JavaScript这样的web语言，中间层语言如Java、C#/.NET以及像C++这样的更底层的语言。 

许多工具都提供可视化拖放环境，另外一些则只提供限制性的基于模板的app开发流程。一些工具只针对特定的开发人群，例如Impact JS和Lime JS Javascript 框架针对游戏开发者，而RhoMobile和Worklight则用于企业级开发。跨平台开发工具（CPTs）提供不同的语言来满足各类开发者的需求，无论你是脚本开发人员、经验丰富的web开发人员、有创造性的设计者还是核心软件开发人员。

开发阶段的核心部分包括集成开发环境（IDE）、仿真器以及调试器。Eclipse是当前最流行的开源IDE，作为跨平台的开发环境可以在PC、Mac以及Linux上使用。许多供应商在Eclipse之上提供额外的插件和仿真器。一些供应商会专门为企业级应用的开发人员和品牌设计人员提供免安装、基于web的开发环境。 

开发阶段也包括源码控制，团队协作和工作流辅助工具。RhoMobile公司的 RhoHub开发平台使用Git套件进行源码管理和团队协作。Unity、Appcelerator、RunRev提供了一个组件交易市场，设计及开发人员可以通过此交易市场出售自己的组件，旨在利用这些现成的组件帮助他人缩短开发周期。Sencha在2011年11月也提供类似的组件出售市场，而Corana和Marmalade则分别推出了模板库和代码社区服务。 

2.集成阶段：本阶段是有关如何与本地设备功能、云服务APIs及企业数据库进行集成的。 

为了集成本地设备功能，通常的做法是使用JavaScript以及PhoneGap APIs和库，这些捆绑集成在一个称为混合-本地（hybrid-native）的应用程序中。Worklight、AppMobi、Feedhenry和BKrender在他们提供的工具中也包含PhoneGap功能。MoSync和Qt使用类似的方法，将本地APIs和平台无关的APIs抽象集合封装在一起。

开发者使用像JavaScript、Lua、LiveCode或者C++这样的编程语言提供的APIs，来与本地设备功能集成在一起。不同目标平台上功能相似的函数共享相同的工具级别API，这些API在业务逻辑层面上提供更高级别的代码复用，而在UI和特定硬件特性的支持方面的复用程度就没有那么充足。 例如，Mono Touch和Mono for Andriod就没有共享相同的UI APIs，所有与设备特性有关的APIs在不同设备上面的表现也不尽相同。Apps能够在运行时调用设备功能，调用要么在编译期被解释，要么通过运行时提供的桥接功能传递给底层平台。 

集成阶段另一个主要部分是要连接到cloud APIs。Cloud APIs正在逐渐变成一个属于自己的细分市场。对于开发者来说，社交游戏网络显得越来越重要，这里不仅仅指Facebook或者LinkedIn。Apple Game Center、OpenFeint、Scoreloop、Skiller，Papaya Mobile和Swarm都为社交游戏提供基于云的APIs。 

社交游戏APIs仅仅是其中的冰山一角。包括Bango、Social Gold和Paythru在内有超过14家供应商提供应用程序内计费以及虚拟物品交易平台。有超过27个像App Annie、Distimo和Flurry这样的销售分析工具。有超过8个像Bugsense和Testflight这样的app测试工具。VisionMobile的Atlas服务有这些提供商的详细列表。当然，这其中不乏合并的迹象。举个特殊例子来讲，Appcelerator虽然有自己的分析和货币平台，但还是通过收购Cocoafish来集成社交共享和消息推送功能。 

针对企业级（B2B）开发者使用的应用平台通常会提供数据库连接管理服务。RhoMobile推出RhoConnect移动app集成服务，当后台有更新时该服务将更新推送给设备以实现数据同步。Antenna、Feedhenry和Worklight推出的跨平台工具（CPT）提供类似功能的集成中间件。其他专注于企业级应用程序开发的著名跨平台工具有Stackmob，Oracle（ADF），Aperra和Sybase（Unwired Plaform）等。 

3.构建阶段：跨平台的“魔力”通常体现在构建阶段。构建应用程序有许多不同的方法。两种流行的方法：一种是将代码和UI模板直接编译成本地平台二进制码；另一种是将代码打包进本地shell然后在运行时解释执行，这种本地shell可以是一个只包含该代码的“简易浏览器”，也可以是设备自带的浏览器渲染引擎。下一章节我们将讨论构建跨平台apps的技术方法。 

4.发布阶段：发布应用包含将app提交到Apple App Store或者Andriod Market这样的App Store，或者是内部发布并且可以选择是否将app托管到像Feedhenry，Antanna，RhoMobile或者Worklight这样的私有企业App Store。包括Sencha2.0，AppMobi的PhoneGap XDK和RhoMobile的RhoHub在内的许多跨平台工具（CPT）产品都在一定程度上协助管理app发布过程。包括Appcelerator LiveCode和Corona在内的一些提供商将在其网站上展示apps，而Unity则支持将app发布到其他平台上。  

5.管理阶段：提供App管理功能是面向企业级的跨平台工具（CPTs）的特色，比如Worklight，RhoMobile，Antanna和Feedhenry。App管理包括消息推送，数据流管理，远程安装（卸载），策略管理和库存管理。商业Apps管理增加了业绩管理功能（即分析工具），该功能可以由工作方法商合作伙伴提供。例如Appcelerator就将自己的分析工具整合进Titanium，而Ansca Mobile将Flurry的分析APIs整合进自己的Corona SDK中。 

跨平台工具（CPTs）的技术分类

在这份跨平台工具（CPTs）分析报告中，我们甄别出了五种不同的技术方法，即：JavaScript框架，app工厂，web-to-native框架，运行时以及源代码翻译。每种技术都针对特定的开发人群（从非技术人员到经验丰富的开发人员），并且可以满足不同的app用例。这些技术方法并不是相互孤立的，许多工具混合使用这些技术方法。例如一些基于运行时的跨平台开发工具（CPTs）解决方案都会增加一个网页视图组件，从而具有了创建混合web app 包装器的功能。 

JavaScript frameworks：JavaScript框架由许多代码库组成，旨在加速复杂web任务（例如管理触摸屏交互，构架跨浏览器UI， 管理游戏画面等）的开发速度。主要提供商有jQuery Mobile，Sencha Touch， Cocos2D，DHTMLX Touch, Zepto JS, Impact.js, iUI以及Wink。JavaScript框架针对这样一类web开发人员，他们想要创建可触摸UIs，实现跨平台浏览器兼容，提供本地外观和感觉，或者是实现复杂的游戏功能。 

App factories：App工厂是能够快速构建简单移动应用的开源可视化设计工具。它们由一个可安装或是基于云的开发环境构成，在此开发环境中开发人员可使用模板、拖拽、或者向导来生成app代码。利用App factories最简单的可以创建基于RSS的新闻阅读器或者经济型apps。在较高层面上，App factories提供基本的可拖拽设计功能。而在最高层面上，App factories提供无须编码的，基于组件的设计方法，包括与设备和云集成。 

非开发人员也可以通过App factories创建他们自己的app。一些app工厂允许开发人员查看和修改自动生成的代码。其他的app工厂提供包括分析，消息推送和广告管理在内的一系列post-download服务。这些App工厂包括AppMkr，AppsGeyser，Wix Mobile，Tiggr，Mobile Nation HQ，Mobjectify，Red Foundry和Spot Specific。 

Web-to-native wrappers：Web-to-native框架是使用web HTML5，CSS和JavaScript技术来生成本地apps的解决方案。web代码和其实现本地功能所需要的库文件被一起打包到本地app shell中。Apps使用web语言编写，能够访问设备上的webView组件（一种“chromeless”浏览器组件）以及JavaScript API扩展，JavaScript API扩展使得app能够使用通知、加速器、指南针、连接性、地理位置以及文件系统这样的平台功能，这些都是超乎浏览器通常所能提供的。 

web-to-native框架主要有PhoneGap，Uxebu’s Apparat.io以及Sencha v2，Sencha v2还将这种包装功能引进到JavaScript框架中来。另外一个例子就是MoSync Wormhole，它可以提供比PhoneGap更强大的API功能集。web-to-native框架针对这样一类web开发人员，他们需要将web apps转换为本地apps并通过app商店进行分销、访问本地设备功能或者做一些优化工作。 

Runtimes：运行时是本地操作系统之上的一种执行环境以及跨平台兼容层。运行时从本质上来说屏蔽了app在不同底层平台上的差异。不同的运行时有不同的大小和复杂性，并且使用不同的方法在设备上面执行代码，例如虚拟化，解释，及时编译或者提前编译。 

Java ME，BREW，Flash Lite和Openwave MIDAS都是早期运行时的先驱。这些重量级的执行环境似乎介于浏览器和完整的操作系统之间。但这些工具在2009年前后就不再流行，原因是：开发者感觉很痛苦（平台分散、无直接市场渠道）；缺乏手机制造商的合作（集成复杂度）；与Aandriod、iOS、HTML5浏览器的竞争。 

现在的跨平台运行时将设备软件层的复杂性转移到了设计阶段的开发工具中来。通常来讲，跨平台翻译部分发生在设计阶段（翻译成进制代码），部分发生在运行时（执行进制代码）。流行的运行时有Appcelerator，Adobe Flex，Corona，AppMobi，Antix和Unity等。运行时针对这样一些软件开发人员，他们需要更宽泛的跨（本地）平台或者跨屏幕（手机，电脑，游戏，电视等）功能。 

Source code translators：源代码翻译器解决方案将源码交叉编译成中间字节码，本地语言（如C++，Objective-C，JavaScript）或者直接转化为更低级的机器码（如汇编语言）。源代码翻译器通常和运行时元素结合在一起使用。 

举个例子来说，Metismo（现在的AG软件）将J2ME应用程序转换为C++，ActionScript和JavaScript，然后编译成能在ARM，MIPS，PowerPC和x86设备上执行的代码。类似的，Eqela将一个使用类C语言编写的app翻译成目标平台可运行的中间码，例如在web浏览器上执行的JavaScript，Java，C或者汇编语言。

Haxe/NME结合本地标准库把类似ActionScript的Haxe(具有类似Flash的API)源代码转换成Shockwave或C++代码。XMLVM使用Java，.NET或者Ruby源码，这些源码先被编译成字节码，然后再交叉编译成JavaScript，C++或者Objective C。其他的源代码翻译工具有MoSync，Marmalade和Xamarin’s Mono。这些翻译工具针对的是高级软件开发人员，他们需要创建逻辑复杂、性能优越的跨平台apps或者需要对app进行优化。 

跨平台工具垂直发展

除以上五种技术手段外，跨平台工具提供商已经开始垂直分化，根据企业，游戏，媒体应用开发者的不同需求，为他们提供不同的解决方案。

企业级应用平台是跨平台的开发工具，它支持应用的整个生命周期（开发->集成->发布->管理），它具有数据连接器、中间件、云服务（如：应用托管、策略管理、信息推送等）。很多这样的平台是面向企业的，而不是面向消费者的应用。比较著名的移动应用开发平台有：Worklight, Kony, Antenna Mobility Platform, Application Craft, RhoMobile 以及Verivo等。

游戏开发工具是专门针对游戏开发者的完整的开发环境。游戏引擎是更为重量级的运行时组件；通常是由低级语言（如：C++语言）与用于编写游戏逻辑部分的脚本语言（如：Lua语言）相结合。Unreal 和Unity在高端3D游戏市场完全处于领先地位。他们提供了一系列的集成开发工具、工作流及协作管理工具。在类似的游戏工具市场上，还有Moai, SiO2, Antix 和 Shiva3D等。虽然Marmalade 和 Corona支持更多的功能（如：支持本机UI元素），但是它们毕竟还是由一个旧版的游戏引擎发展而来的。也有一些像GameSalad这样的稍微轻量级的游戏工具，GameSalad被称为“游戏缔造者”，它将app工厂提供的无须编码方法和游戏引擎工具结合在一起。像Impact JS 和 Lime JS 这样的轻量级JavaScript库被认为是HTML5的游戏框架。

The next table lists over 50 cross-platform tools by technology approach, authoring language and deployment format (web vs. native).

下表列出了50多种跨平台工具，从技术方法、开发语言及部署格式方面（网络或本机）进行了展示。

跨平台工具总表：我们的研究所关注的100种跨平台工具总表如下。

部署格式：Web还是本机？

是用web浏览器来部署移动应用程序还是创建本机应用？这是令许多开发人员长期困扰的问题。Web apps 具有广阔的市场前景，但只能在网络上部署，并且相对于本地apps的用户体验也不是那么好，本地apps具有更好的设备集成度并提供更优秀的用户体验，但是不能跨平台，其潜在市场只能限定于特定平台内。

使用跨平台工具可使这些区别模糊不清，Web程序员可以通过工具（如著名的Appcelerator）来开发本机应用程序。Web开发者可以使用诸如PhoneGap这样的Web-to-native框架在浏览器中动态调用本机设备的功能。

但是本机与web问题在部署时还是存在的。无论是web app还是本机应用，在分销渠道（网站或应用程序商店）和经验积累（肤浅或深入）上都会有很大的不同。

HTML5的确增强了web浏览器的功能，例如：允许精确的可视化布局（画布元素）和对视频、持久存储、地理定位、访问联系人名单、传感器和SQL数据库访问的固有支持。同时，由于各浏览器实现HTML规范的方式是不同的，web程序员必须对由此带来的巨大差异进行处理。在所有的移动浏览器当中，遵循HTML5规范方面做得最好的是Firefox Mobile，获得了最高分10分，紧随其后的是苹果的iOS5平台。与之相对的另一极端是Windows Phone7.5浏览器，它对HTML5规范的遵循程度大约只有苹果的一半。桌面浏览器和电视浏览器在对HTML5规范的遵循程度方面，也存在同样的多样化和两极化现象。上面的图表是移动平台对HTML5浏览器规范的遵循程度的得分情况。

这种“遵约分化”现象导致的后果是：web应用开发者为了使他们的应用能在各主流智能手机平台上实现最优运行，他们需要耗费大量的开发时间以及昂贵的成本。最典型的例子是“金融时报”广受欢迎的HTML5应用的开发商Assanka，该公司花了24人月来开发iPad平台上的HTML5应用—新闻阅读器（news reader），又花了12个月把这一应用移植到Android平台。

Web Hybrid apps弥补不足

开发人员应该选择web还是本地apps? 混合app方法致力于结合web和本地apps两者的优点。像PhoneGap，BKRender，Sencha v2， Worklight和Appcelerator等许多跨平台工具已经可以进行混合apps开发。

从用户的观点来看，混合apps跟本地apps很相似，人们可以通过本地平台app stores来寻找下载混合apps，同时使用相似的过程来安装混合apps。安装完成之后，混合apps可以从iOS这样的主屏幕或者从Android这样的app抽屉(drawer)中启动，并且经常可以在不需要数据连接的情况下正常运行。

从开发人员的角度来讲，开发混合apps和开发本地apps的工作流很相似，只有一点不同的是，开发人员可以使用HTML，CSS和JavaScript来编写混合apps的某些部分。由于混合app开发模型在所有主流移动平台上得到支持，使得不同平台版本的app可以复用HTML，CSS和JavaScript代码。

混合apps由一个包含HTML，CSS和JavaScript的本地代码shell（或者说是一个包装器）组成。当一个混合app运行在一台设备上，该包装器就会启动一个web视图的实例，同时加载其中的HTML，CSS和JavaScript代码。该web视图实例通常是“chromeless”，即它没有web浏览器控件，因此使得混合app看起来类似一个本地app。

下面的表格从技术和商业角度比较了本地，混合以及web app方法的异同。就像表格所显示地那样，混合apps将本地apps的特性和pure web apps的特性结合了起来。 

容易发现和获取：用户可以像找本地apps一样找到他们需要的混合apps。为了支持多个移动平台的用户，需要开发不同版本的app。

更好的用户体验：混合apps提供良好的用户体验。他们允许HTML代码访问本地APIs（以此来提供更丰富的用户体验），当然这是以非本地UI为代价的，因为这涉及到web技术。

用户所有权和条款：就用户所有权和条款来讲，混合apps和本地apps完全一样。开发人员通过本地平台app stores来和客户进行交易，并且必须遵守app store强加的包括准许政策在内的各种条款和约束。

迎合用户：由于混合apps安装在设备上，并且显示在主屏幕或者app抽屉上面，他们在留住用户和重复使用方面和本地apps是完全一样的。用户可以像启动（launch）本地apps一样来启动混合apps，而不用去记住任何URLs，或者像pure web apps一样在主屏幕上显式生成一个捷径。

盈利模式：混合apps的开发者可以和本地apps开发者一样通过相同的方式盈利，这里面包括下载后付款或者应用程序内支付。

最后，对于一些UI信息丰富的app,混合apps允许显著的UI资源共享并且易于web开发。然而就像上面图表显示的那样, 在不同的移动平台上web浏览器的实现都千差万别。结果，充分使用web浏览器功能的高级apps需要自适应来完全支持不同平台的移动浏览器。

我该使用哪个工具？

我们追踪调查过超过100个跨平台开发工具，他们都各不相同。如果避开他们支持的编程语言和目标平台不谈，我们可以发现使用跨平台开发工具开发的app有一些收敛的类别（a convergence in the categories of apps）。开发者调查报告显示，如果不考虑主要的开发工具的话，35%的调查对象认为企业级apps是其首选。生产力，游戏，教育/参考和实用工具排名前五。

与此同时，这些开发工具不能被化为到具体的app类别中来，当然开发人员在决定使用哪个跨平台工具之前，应该考虑他们的应用背景以及需要。下面这个表格提供了一些指导意见。

 相关文章：上一篇：跨平台领域的淘金潮——为什么跨平台领域工具会改变现状

您可能也喜欢：
跨平台领域的淘金潮——为什么跨平台开发工具会改变现状	海豚浏览器CTO刘铁锋：Web App对企业移动开发的影响	PhoneGap开发初体验：用HTML5技术开发本地应用	PhoneGap之深度探索–理念、目标和宗旨
无觅

跨平台的淘金

2012年标志着移动平台领域的一个拐点。Apple的iOS和Google的Android平台已经推进到以前无法想象的高度，截至2011年年底，在这两个平台上，分别有超过540,000和350,000种应用程序，这些应用程序来自成百上千的开发者。正因为所谓的网络效应（network effects），Apple和Google对竞争者已经建立起巨大的壁垒，即使是像微软这样花费超过10亿美元进行营销的竞争对手，仍然远远落后于Apple和Google。

然而，正当Apple/Google的双寡头垄断看起来似乎坚不可摧之时，对诸如Microsoft的 WP7 以及 Samsung的Bada这样的竞争者来说，前进道路上的障碍正在被扫除：跨平台的工具让开发者可以针对多个平台进行开发，让代码有较高的重用率，从而让增长的开销较小。

简言之，跨平台的开发工具（CPTs）允许开发人员开发针对多个平台的应用，针对各个平台的开发可以基于相同的核心代码库，或使用相同的设计工具。CPTs的影响是两方面的，它们可以减少移动开发进入壁垒，又使得开发者转向新的开发平台更容易，从而对某个平台的黏度降低了。 

开发的民主化 首先，跨平台的工具允许开发人员为他们之前所不能进行开发的平台进行开发。 CPTS使得进入门槛降低了，例如，现在Web开发人员仅使用HTML和JavaScript就能够创建本地智能手机应用程序。CPTS可以提供易于使用的语言和开发工具，并便于模块化开发和软件组件重用。有些工具还允许开发人员使用相同的代码库来针对多种屏幕进行开发—— 并且，这种开发不止局限于手机，还针对平板电脑、游戏机、台式电脑和电视机。这便是软件开发的“民主化”，即平台可以开放给所有类型的开发者。

减少开发者的平台固化 跨平台工具的第二个影响是战略性的。CPTs减少了平台的退出壁垒，也即“开发者平台固化（developer lock-in）”。例如，CPTs让开发者在为iPhone开发的同时也可以为Android和Windows Phone 7开发。在App的生态系统中，竞争体现在四个方面：app的数量，top app的可用性，app投入市场的时间（一个app很难同时出现在所有平台的app stores中）以及总体的app质量。在理论上讲，跨平台的工具使得网络效应减小了，从而使非Android和Google平台更容易参与竞争，比如现在Bada平台就更容易参与竞争了，因为CPTs允许开发者在为Android开发的同时也能为Bada开发。换句话说，跨平台的工具让小的平台不仅可以在数量方面与大的平台竞争，也能在app的可用性、到达市场的时间和质量方面进行竞争。

众所周知，Apple试图通过在Apple的设备上禁止Adobe的Flash runtime来增加开发者对于Apple的XCode工具以及iOS API的黏度——它成功做到了。然而，跨平台工具让打破Apple的限制更为容易，它们可以将runtime和app进行打包，或者在编译连接的时候将与平台无关的代码翻译成本地代码。

正如我们将要看到的那样，2012标志着跨平台工具在技术上的成熟。使用Flash或者Java这种通用的方法已经失去了其吸引力，新的基于thin runtimes、cross-compilers 以及 hybrid web apps的方法更为喜闻乐见。2011年在初创阶段受到批评的工具现在要么获得了VC，要么被收购，要么发布了主要的产品。例如，MoSync 2.7使得网络编码变为可能，并且它和Marmalade一起增加了实时本地UI元素。此外，Sencha已经准备发布Touch version 2.0，在该版本中，Sencha推出了自己的web打包方法（web wrapper solution）以及流水线式的构建流程。其他的，比如LiveCode Android deployment pack以及Mono for Android，都是在2011年才正式发布的。

与此同时，HTML5系列的技术已经过了狂热的高峰期正在慢慢走向低谷（此观点来源于Gartner’s Hype Cycle）。HTML5还没有真正成为一个平台；它缺乏一些必要的元素，比如实施的一致性、主流的发布渠道（也即app stores）以及除mobile ads以外的盈利模式。然而，因为跨平台工具的存在，HTML5（包括Javascript）正让mobile app逐步发展。有好几十个工具致力于让web开发者使用现有的技术构建‘native’ 或者 ‘hybrid’的手机应用，这其中包括Appcelerator, PhoneGap, Rhodes, Sencha 2.0 以及Worklight。同时，mobile frameworks在致力于让web apps能提供一个“near native”的用户体验，这其中包括jQuery Mobile, Sencha, iUI, 以及适用于游戏的Impact.js.。CPTs以及为HTML5扫清了道路，不仅让它可以成为一个平台，而且会成为智能手机apps的主流开发技术。

跨平台领域的赢家与输家

在写这份报告的时候，跨平台开发正十分流行，随处可见收购、资产剥离和融资。Adobe的Flash，曾经作为跨平台解决方案的经典方法，正面临退出，Adobe在2011年11月，宣布了将会停止为mobile browser开发Flash插件。同时，Adobe会同时终止Flex SDK，而将力量集中于ActionScript-only开发。从2011年中期起，跨平台工具提供商方面的收购包括RhoMobile, Metismo, Aptana, ParticleCode, Nitobi, Strobe和Worklight。另外，Alcatel Lucent在2010年收购的Open-Plug因为资金缺乏而不得不停止它的产品（本章后面的案例研究将会谈到这一点）。同时，Sencha，一个高调的开发native、touchscreen UI的Javascript框架，在2010年和2011年完成了两轮融资，筹到了2900万美元。下面的三个表列出了跨平台工具领域主要的收购、退出以及VC融资。 

投资涌入

正当投资者们正在寻找下一个经济增长点时，跨平台工具出现在他们的视野，在这个领域，筹集到超过两亿美元。在主要风投资金的支持下，Appcelerator扮演了中间人的角色，它自己在试图app的生态周期中提供更为端到端的解决方案，收购了Particlecode, Aptana 和Cocoafish。Worklight在被卖到IBM之前，获得了2100万美元的投资，而Pyxis在筹到100万美元以后，重命名为Verivo。

CPT中的资产剥离：OpenPlug案例

在一片大好的投资环境下，跨平台工具的竞争中也出现了一些失败的例子。2010年9月，Alcatel-Lucent收购了OpenPlug。这个电信基础设施供应商，希望建立一个电信运营商和开发者之间的战略平台。然而一年以后，在2012年12月，OpenPlug宣布终止运营，因为它吸引不到足够的开发者。

这个公司最初是有着嵌入式软件背景的公司，曾经为非智能手机（feature phones）开发过名为ELIPS Suite的操作系统，这个系统在2008年大量生产，尤以和Sony Ericsson的结合最为出名。那时候，手持设备代工生产商（handset OEMs）将注意力从非智能机转向了在智能机中采用Android以对抗Apple的iPhone带来的竞争压力。

结果，OpenPlug转向了生产跨平台的runtime和toolset，并于Adobe MAX 2009会议上发布了beta版，该版本以ELIPS Studio冠名。它的目标用户群是那些想要从桌面端拓展到智能机的Adobe开发者。这样是不合时宜的，因为这个时候恰逢Adobe为iPhone推出了Flash packager，为Mobile推出了AIR。ELIPS Studio那时候使用的还是Adobe丰富的应用框架（Flex以及MXML），这个框架很快便受到HTML5的挑战，并最终被Adobe所淘汰。OpenPlug还被指责说不能让toolset和Adobe的MXML 和AIR APIs更为兼容。

最终OpenPlug没能找到一个盈利模式，它面临的最主要的问题是劝说习惯了免费增值产品的用户付费试用它的支持功能和专业服务。它的竞争对手Appcelerator让这一问题更为严重，因为Appcelerator有丰富的VC资金，因此Appcelerator的产品都是免费的。和其他产品不同，OpenPlug没有任何云服务产品，也就没有其他销售来源。

OpenPlug的母公司Alcatel-Lucent，作为一个运营商，显然不能帮助OpenPlug找到开发者。相反，这个公司发现，开发者们都没有把运营商看做mobile app生态系统中的一个重要部分。在终止运营以前，OpenPlug聚集了22,000注册开发者，但只有少量是活跃用户，大多数人只是尝试写过“Hello World”后便不了了之了。

跨越赶时髦的阶段

跨平台工具已经度过了“赶时髦”的阶段，而成为现今的主流了。一个工具提供商——Sencha——声称有160万开发者，并且有30万注册社区用户。游戏开发平台Unreal声称有100万的SDK安装量。Unity在2011年有很大增长，它有80万注册开发者，其中有20万是活跃用户。Appcelerator原本有25万用户，现在随着它收购Aptana并将它的“Titanium”技术整合到流行了Aptana IDE中，它的用户猛然增加了160万。PhoneGap已经被下载60万次，并且被整合到几十个移动应用平台以及App builders中。跨平台工具对于消费者也有影响。Corona声称用它的工具创建的应用已经有6000多种，这些应用在2011年的下载量有3500万次。Appcelerator声称用它创建的应用有35000种，并且有4000万设备部署(device deployments)。  

在跨平台工具出现的背后

跨平台工具的出现主要是为了处理在mobile apps开发中出现的三个市场上主要的障碍：平台碎片、进入新平台的壁垒以及管理开发资源。

处理平台碎片

跨平台的工具出现之初便是为了解决设备和平台的碎片化。Java ME可以处理几十种2000s系列的由定制操作系统驱动的手机——但是开发者需要能支持超过200种设备，以便能为在任何一个国家内的80%的设备做开发。Mobile web站点也是因为浏览器对标准执行很差而很难找到通用解决方法；即使在现在，Windows Phone上的IE对HTML5的支持度只比得上Apple的Safari所能支持的一半。另外，要能够发布类似于app感觉的应用，HTML5还有很长一段路要走，还需要不菲的调整。为iPad以及Android tablets开发了Financial Times HTML5 app的Assanka，说它为了开发iPad 版本的Financial Times HTML5 app，花了24人月（估计为US$400,000），然后又花了另外12人月将这个app移植到Android上去。

除了设备间的碎片，平台碎片也是很严重的。Android因为它的运行时碎片而臭名昭著；在2012年2月，有三个不同版本的Android平台（API levels 7,8 and 10），互相之间只有超过2%的相同点。所有这三个版本都落后于最新发布的版本，这个版本是API level 15的，前面过渡性的API levels (11-14)是针对平板电脑的（由Gingerbread发布）。

对了应对碎片化问题，跨平台工具提供商在云中提供了一些设备相关优化手段以及web资源重新表现方法。数据库中的设备详细参数和性能可以帮助优化图像大小、重新确定布局以及用户界面、实施一些折中而非强迫开发者一定要找到通用的方法。从传统上讲，设备性能数据库（device capability databases）是由像Wurlf, DotMobi 以及 DetectRight.这样的专营公司提供的。慢慢的，device databases有了更多来源，比如通信架构公司（如WDS, Ericsson, mFormation, Ascom），通信公司本身（如AT&T device capabilities API），以及已有的跨平台工具（如Netbiscuits, Mobile Distillery, Sevenval）。BKRender，另外一个跨平台解决方案，提供了含6000种设备的数据库以及一个HTTP反向代理（an HTTP reverse proxy）来优化移动在站点。

一些CPTs因为内部咨询项目的碎片化问题需求而成长起来。其中的一个例子是Enough Software，，它是给Java ME apps提供优化工具的。Enough Software走的是跨平台工具领域中的典型路线——先解决他们在自己的项目中遇到的碎片化问题，然后将解决方案转化为一个商业工具。这条路随后被Pyxis (Verivo),、Netbiscuits、Marmalade 以及 DragonRad所模仿。

尽管CPTs开始解决一些平台碎片化问题，但是又出现了新维度的碎片化。Handy Games的CEO Christopher Kassulke说，“现在的碎片化已经是4D matrix的了”。他提示开发者要处理平台间的碎片化，如软件平台，计费平台（以及定价模型），广告平台以及社交平台。

让为新平台以及设备开发成为可能

对于参与到我们的在线调查的2500位开发者来说，我们发现影响跨平台工具选择的最重要的因素是该工具支持的平台广泛程度。除了占统治地位的iOS平台以及Android平台，许多平台都在争夺亚军位置——包括Windows Phone 7, Bada以及BlackBerry，更不用说针对各式屏幕的平台了，比如针对桌面机屏幕、游戏机屏幕和机顶盒平台屏幕。我们发现开发者都将iOS和Android作为起跳板，并在随后拓展到新的平台。现今非常流行的Appcelerator 和Marmalade工具的用户中有超过90%是定位在iOS，有超过80%是定位在Android。而CPT的整个用户群中有超过70%是定位在iOS，有超过60%是定位在Android。

在VisionMobile Developer Economics 2011年度报告中，我们发现开发者平均关注的平台个数为3.2个。大概过了一年，在跨平台工具报告中所作的调查里，我们发现开发者平均关注的平台个数变成了人均3.8个平台——而对于跨平台工具活跃用户而言，这个数字增长到4.5.换句话说，跨平台工具让开发者可以同时使用的平台数目增加了。

从经济角度来说，开发者可以同时使用的平台数据增加是有利于节省开销的。对于一个开发者而言，针对另外一个平台重写一个应用耗时耗力。通常要为一个新平台再做开发需要增加超过初次开发开销的50%。两外，由于各个平台和不同app stores相对应，app的提交和宣传开销也会增加。

我们同时还发现CPTs被用来处理新屏幕，也即新的联网设备、台式机、机顶盒和游戏机。在我们的调查中，27%的人提到他们还会应用他们主要的跨平台工具去处理Windows PC，另外有24%人会借用跨平台工具处理Mac台式机。由于Eric Schmidt预言说2012年中期在北美有超过半数的电视机将使用Android驱动，对新屏幕的处理能力将会成为跨平台工具的一个主要的增长点。由于我们的调查时间稍微靠前，在2011年底才出现的智能电视，没有表现出多大的势头。只有一个被调查者希望能有对智能电视的支持，还有一些人提到了智能电视平台，比如Google TV 和 LG TV。另外有一些开发者希望能有对Playstation3 和Vita、 Xbox 以及 MS Surface Table的支持。Linux被证明是最流行的备选平台，这是我们之前没有看到的，有76个受访者指出他们在处理嵌入式、服务器以及台式机问题时会应用Linux平台。

管理开发资源

跨平台工具出现的第三个重要原因是开发者资源管理问题。不管是单人开发还是顶级的五个游戏软件供应商联合开发，在为移动端进行开发时，都要面临这样的问题。

每一种主要的智能机、PC或游戏平台都有它自己的指定语言、它自己的API集、它自己的开发环境和它自己的app store。下面的表展示了主要的智能机平台的区别。 

假设一个例子，有一个小的apps公司，它为iOS，Android以及Windows Phone7开发。他们需要雇佣三个团队，这三个团队擅长的技能都不一样。他们需要维护三套不同的代码库，并在功能增加或者修复bug时同时对这三套代码库进行操作。这是一个很大的挑战，也是为什么很多apps在不同stores的发布时间有几个月的延迟。另外，随着各个团队的工作进行，质量以及设计的一致性都会发生改变，尤其是将对新平台的开发外包给第三方的时候。为多个平台开发时，后期维护也很困难，因为三个平台需要各自建立开发文档，内部用户支持文档也需要三份。

因此，跨平台工具能为软件工作室提供产品投入市场时间的优势、为其节约开销。“我们发现通过使用跨平台工具，我们的产品投入市场的时间平均减少了70%。” InRuntime的CEO Paulius Uza如是评价。他接着说：“即使我们只是要为单个平台构建单个应用，我们也会选择跨平台工具。”

您可能也喜欢：
深入解析跨平台工具：背后技术、对应开发阶段及垂直发展	PhoneGap之深度探索–理念、目标和宗旨	HTML5开发：原理与实现	Firefox上Web开发工具库一览
无觅

你也许认为你和你的团队都已经拥有了个人电脑。

但是根据Lextech Global Services（一家移动app设计与开发公司）的CEO Alex Bratton的说法，你并没有真正拥有。

Brathon说：“如果安装了合适的app，移动设备就是首要的真正的个人电脑：可以装在口袋里，7*24小时可用，最重要的是，移动设备不是为大众市场而设计的，而是为你的个人需求而设计的。这才叫人个电脑！”

Bratton说，移动设备上的app相比PC机和笔记本电脑上的app具有很大的优势。便携性和可用性是指雇员的“智能代理”可以在口袋里默默地接收数据。

始终在线，保持机警，时刻准备着为雇员解决问题或抓住机会。你的企业app就应该设计和部署成这个样子。

Bratton说：“大多数app不是这样子的。”

为什么呢？大多数移动web app都是简单地将web app进行压缩后放到移动设备上的。根据Bratton的说法，这种做法是完全错误的。好的app应该源自一种与软件功能性完全不同的思维方式。

往app中增加100个功能几乎不用费多大心思。而要想实现一个核心功能就需要对业务目标和用户需求有很深入的理解。这需要付出很大的努力，并且要遵守Bratton提出的构建移动app的10条建议：

1. 目标决定一切。好的移动策略基于稳定的业务目标：降低成本，减少浪费，改善服务，做出更好的决策，适当地加强沟通和团队协作等等。不管怎样，总是要从你的目标出发，因为……
2. 永远不要让技术来左右你的目标。好的app应该是利用合适的技术来实现先前已经设定好的目标。永远不要让技术（尤其是新热点技术）来决定你的目标。选择正确的技术来实现你的目标。虽然技术是很重要的业务工具，但它决不应该影响策略。
3. 不要违反你的最佳实践。好的app可以使用户以最简洁、最准确、最有效的方式来工作。查明完成某项任务的最佳方法，然后构建app来实现这些方法。
4. 要有较高的资产收益率。对工作流和沟通的改进，至少要使每个雇员受益5千美元以上。设定较高的目标可以驱使你更严谨地、富有创造性地思考，以通过为雇员们提供合适的工具而优化他们的工作过程。
5. 遵循5%的规则。选出一小部分需要做得很好的事情。移动app只可以很好地实现web app中5%的功能。不要试图将所有东西都展现给每个用户。
6. 开发之前请深思熟虑。开始写代码之前请明确需求。该app是否需要在脱机情况下运行？该app如何与后台系统交互信息？什么样的工作流对目标用户来说才是有意义的？
7. 请在1到3个月内完成项目。需要长期开发的app太复杂了。永远不要试图实现太多的功能。相反，只实现有限的功能，将这些功能做到极致。
8. 让最终用户不断地参与。只有有用的功能才是最好的功能。最终用户就好比是客户。让他们接触并评价早期的系统原型，以确保开发过程一直沿着正确的方向。
9. 确定和衡量成功。建立客观的度量衡：用户数量，节省或收益的数额，改进大事记，远程访问量的增加等等。你的成功标准要以业务目标为基础并且要可度量。
10. 永远不要为了耍酷而耍酷。永远不要创建以外观为重点的app。只有可以产生重要的并且可度量的结果的app才是最酷的。

作者：

eff Haden，在制造业工作，业务和技术知识广博。还有很多其他内容是从ghostwriting books书中摘录的，是关于他认识的一些最明智的领导者的，请关注 @jeff_haden。

译者：林建光

原文链接：

http://www.inc.com/jeff-haden/build-killer-mobile-enterprise-app-10-rules.html

您可能也喜欢：
如何设计一个优秀的儿童应用？	如何开发实用的企业级应用？	海豚浏览器CTO刘铁锋：Web App对企业移动开发的影响	深入解析跨平台工具：背后技术、对应开发阶段及垂直发展
无觅

恭喜你终于使领导们信服：你的下一个Web 设计项目需要进行响应式设计。虽然说服他们相信是一件非常艰难的事情，但是你现在不能在荣誉上休息。现在项目最关键的问题是：如何带领你的团队去构建响应式设计？

响应式简介

你可能熟悉典型的“瀑布模式”的开发过程：从系统需求分析开始，然后着手设计，接着开始前后台开发，最后进行评估并且实施。线性性质是瀑布式开发的主要特点：当这一阶段完成，下一阶段紧接开始，两者配合的几乎天衣无缝。“瀑布模式”开发过程是通过设计一系列阶段顺序展开的，只需朝一个单一的方向推进工作，而不幸的是，随着问题的不断积累，不得不放慢脚步，来应付各种棘手的问题。

“瀑布模式”开发过程演示图：

所谓的“响应式Web 设计”，它是指在网站建设过程中，利用同一套代码，使网站内容在PC、平板电脑以及智能手机浏览器上都能正常的显示。那些为了发布同样的内容，而创建PC，mobile等多个版本的日子一去不复返了。现在你可通过构建一个非常灵活的网站去应付所有的运行环境。

“响应式”设计过程如下图所示：

那么，为什么要使用响应式设计而不是采取瀑布模式？瀑布模式只按照标准的桌面浏览器进行设计，除此之外，几乎没有考虑任何其它的设计开发环境，这是它最大的缺点。而敏捷的响应式设计从一开始就考虑到这些跨平台问题，从而进行更详细的前期框架构图，设计和测试，而这些工作恰恰在瀑布模式中被省略了。基于响应式设计的网站一旦完成实施，将正确的呈现在PC、移动设备和平板电脑上。

响应式设计在不同设备上的效果展示图：

既然如此，那么如何在团队中实施响应式Web 设计呢？下面，我们将回顾典型的瀑布模式的开发步骤并且说明如何使他们变为响应式设计模式。

如何实现响应式Web 设计

第一步：计划

瀑布模式开发

在瀑布模式开发过程中，框架图主要由布局和小部件构成。它们被设定为一个特定的尺寸（通常基于像素），并且几乎没有调整的余地。这些框架图给出了具体的网格/布局的尺寸大小，但是不同的屏幕分辨率会导致布局发生变化，这时一切都变得毫无意义。最终，导航条菜单无法使用，无法进入表单页面，并且界面也会变得凌乱不堪。

响应式Web 设计

解决此问题并不困难。你需要为不同的视图设计不同的部件，并且不要将一个页面当成一整“页”。页面不是最小的组成单元——而是滚动条，文字内容，表单和其他成份是组成整个页面的最小元素。框架图必须考虑不同的屏幕尺寸，因此布局尺寸也是不固定的。布局可以从三列变至两列，在最小的显示设备上（移动智能手机），甚至可将其调整为单列显示。

同时，你也需要改变网站的用户体验——在小尺寸的屏幕上，要求滚动条不仅仅是可以通过鼠标进行操作，而是人们用手指也能够控制它。这样框架图仅仅是一个原型设计工具，而不再是模板，并且需要通过一些开发和测试来确保其能在显示屏上执行。如果在这些初步测试之前开始设计的话，一些未知的开发问题就会接踵而至。不管怎样，项目根本的愿景必须是保持不变的，因此，保持部门之间开放的沟通渠道是必不可少的。

第二步：设计

瀑布模式开发

在瀑布模式开发中，接下来将按照框架图来进行设计，并且通过字体、颜色、间距以及其他设计工具、手法使其变得丰富多彩而富有生机。通常情况下，设计会进行来回的修改，并且通过设计的不断更新，来逐步完善品牌和设计的规范。

响应式Web 设计

为了更好的使用分配的项目时间和资源，响应式的Web 设计应该设计不同尺寸的布局和部件。响应式的Web 设计不再使用基于像素的完美设计。我们认为在不固定的网格中设计灵活的部件，设计不同尺寸的布局和部件的工作量是可控的，虽然完成可以兼容桌面浏览器的设计就已经极具挑战性了。

让HTML采用在所有环境中的流体布局来提高设计品质。不去专注于用户的总体体验，而考虑每一种浏览器宽度是非常浪费时间的做法。例如，需要确保在小型移动设备上操作rotating banner的原件是快速反应的，并且按照行业推荐的最小的44px作为标准的人类手指尖的尺寸来进行设计。对于用户体验的设计和针对所有屏幕尺寸进行外观设计是同等重要的。

第三步：开发

瀑布模式开发

在瀑布式开发方法中，一旦客户确认了设计图，接下来的前端开发中，就会发现在小型屏幕中存在各种问题。不幸的是，由于瀑布模式的线性特征，这些不可预见的问题只能随着项目的推进而出现。

响应式Web 设计

在敏捷的响应式的开发过程中，设计必须以灵活网格为基础。需要由开发者对部件进行规划和原型设计，并且在每一个阶段都进行测试。为了确保部件是可能的最小的组成单元，需要对代码进行优化。因为部件可以容易的加入到布局中和从中移除，所以在最初的设计中并没有规划出来。通过开发者、设计师和策划者之间良好的协作来规避由于必需的修改而引起的各种问题。这样，团队中的成员达成共识，就可以早点发现和解决问题。

第4步：耐心的测试

瀑布模式开发

在标准的瀑布模式开发的最后阶段是通过单元测试和功能测试来评估站点。在这个阶段发现的问题，可能会要求重新规划项目最初的设想，甚至有时候一个新上市的设备可能对项目造成沉重的打击。需求分析团队和设计团队不得不重新规划和设计以顾及到这些变化，并且将花费更多的时间来进行修改。

响应式Web 设计

在响应式开发过程中，每一个阶段都会在多种浏览器和不同尺寸屏幕中进行测试，因此问题可尽早发现。这样也可发现某种移动环境与框架图不匹配的问题，以及了解该设计在不同平台上的性能。响应式Web设计会尽早的完成项目原型，让客户更早的检查成果以实现双赢。

第五步：尽早发现问题，尽早解决

瀑布模式开发

传统的瀑布式开发过程中，没有通过设计和界面迭代的过程。瀑布式开发忽略项目建设过程中的小细节，从而引起一些问题并与客户期望相冲突。虽然通过不断的及时与客户沟通，最终问题解决了，但是这些糟糕决策的严重性却仍未察觉。

响应式Web 设计

响应式解决方法，在取得同样进展的同时，采用动态代码向客户展示每一步的实现过程。这样，这些早期的工作有利于推动下阶段工作，并且可以在截至日期之前进行关键的修改。

总结

采用敏捷的响应式Web设计，可以将你从瀑布模式中解放出来。它将简化你的设计和开发工作，让你的工作更有效率，并在所有可能的平台上最大化宣传你的品牌形象。真正的挑战是跳出瀑布式开发模式而成为一个响应式设计团队。但只要按照以上的五个步骤去做，你就会与瀑布模式说“bye, bye”，而对响应式Web 设计说“hello”。

客座作者Travis Sheppard是BGT Partners的技术副总裁。BGT在2010,2011,2012被《广告时代》评为15个最好的工作地方之一。它为全球的企业提供互动营销和技术解决方案，以帮助企业加强品牌宣传，挖掘更多的合作伙伴和进行业务变革。

原文出处：Bye, Bye Waterfall: 5 Steps to Implement Responsive Web Design

您可能也喜欢：
看好HTML5，Financial Times Web App开发公司被FT收购	[PPT]构建一个面向未来的友好Web	破除八大Web标准迷思：只有大公司才能影响标准制定吗？	'WTF Mobile Web'：发掘糟糕的移动Web设计
无觅

在Ethan Marcotte的文章《响应式web设计》以及他的畅销书中最早首创介绍了建设响应式站点需要的三个元素：

1. 灵活布局、流式网格
2. 响应式图片
3. 媒体查询

另外也有很多文献涵盖了响应式web设计领域相关的主旨，

初期工具

在您开始编制站点之前，最好弄清楚整个页面的元素框架以及它们如何自动适应不同的浏览器窗口尺寸，因为不同的设备的分辨率和屏幕都不尽相同，而且要避免脑海中原来那些关于桌面应用设计时的思维影响，以及不要事后再去考虑剩下的哪些响应式迭代（可以参考Stephanie Rewis的评论）。

（译者注：为了方便读者搜索相关资料，对关键字原文进行保留不译了，每一种工具都附有截图）

1. Responsive Web Desigh Sketch Sheets

这是一个响应式草案图表的集合，由Jeremy P Alford设计，是一个优秀的启点工具，可以帮助您规划页面的各个部分在不同解决方案时的转换。

2. Responsive Design SketchBook

如果您更青睐于保持框架不动，那么或许可以考虑一下这本包含了50个响应式草案图纸的线装本书，由App Sketchbook公司出品。

3. Responsive Wireframes

制作响应式站点的一个难点是，使用wireframe来显示响应时设计如何工作。Adobe公司的James Meller把实验工具集合在一起来为您展示复杂的布局如何通过响应式wireframe工作。

4. Multi-Device Layout Patterns

在筹划一个响应式设计的时候，如果能看看别人以前都是怎么做的，对您可能帮助十分大。所以Luke Wroblewski的多设备布局方式，列出了很多流行的方式，还连接到了样例，是对您可能有极大帮助的。

5. Style Tiles

Samanatha Warren的Style Tiles在响应式设计时代提出了一种新技术，而不是使用混合的设计模型。使用了类似调色板的东西来显示设计的进展概要而并不需要深入粒度细节。

灵活的/流动的网格相关工具

正如之前所说的那样，响应式设计需要的第一个组件是Flexible/fluid Grid.以下介绍了一些已经预构建的东西，您只需要下载就可以迅速在它们的基础上设计更有响应式功能的站点了。

6. Golden Grid System

Joni Korpi是开发了Less Framework的那位，近期已经发布了这个可靠的Grid系统的新版本。因为其易于适应从16个到8个到4个栏，被视为“折叠式”。Golden Grid System还具有另一个特色，可以在测试时用一个小型浏览器覆盖您所制作的页面上的Grid。

7. Foldy960

Paravel公司才华横溢的男人们发布了960.gs的修改版并用它来做响应式工程的基础。

8. SimpleGrid

由Conor Muirhead设计，基于火热的响应式技术，因此易于学习并应用到您的响应式站点工程中。

9. 1140px CSS Grid

另外一个伟大的响应式Grid系统是1140px CSS Grid，由Melboume 的设计师Andy Taylor制作，可以从宽的桌面解决方案缩小到移动应用。

10. Columnal CSS Grid System

Columnal CSS Grid System由Pulp+Pixels aka的富有创造力的主管Nick Gorsline出品，基于1140px grid system，但是又有一些额外的优点，例如带草图框架的开发包和wireframing模板，以及CSS调试方式。

11. Semantic Grid System

像Sass和LESS的预处理的CSS扩展应用越来越流行了，Tyler Tate做的Semantic grid system使用了它们来最大地渲染grid系统，并宣称没有不需要的类或者元素。详情请访问这个链接：http://coding.smashingmagazine.com/2011/08/23/the-semantic-grid-system-page-layout-for-tomorrow/

12. SUSY

像Semantic Grid System一样，Oddbird的SUSY创建了一个Grid系统并不适用额外的标记语言或者特殊的类来实现。不过SUSY的目标用户只有Sass.

13. Gridpak

Erskine Design公司出品的Gridpak是最新的响应式grid生成器之一，它允许你设置你的栏，并且约束了一系列的断电，然后输出CSS，JavaScript或PNG文件，来保障您的整个团队都能从同样的出发点展开工作

14. Gridset

似乎Gridset笼罩着一层迷雾，因为在作者写这篇文章的时候它实际上还没有发布。但是这一款由Mark Boulton Design制作的工具是一款承诺定制的，非规范性的Grid系统，可以在线保存并管理Grid。

15. A Better Photoshop Grid for RWD

Ellot Jay Stocks建议放弃旧的960像素的Grid事实标准并使用基于1000像素的标准，这样能让百分比计算容易处理。如果你同意，他做了一个PSD你可以用它展开工作了。

16. Fluid Grids

如果你的设计高度专业化，您需要创建自己的自定义网格，您可以使用获取.net新人提名奖的杰出青年哈利罗伯茨的流体网格计算器。

17. Responsive Calculator

另一个像素百分比计算器，但是这个由Stu Robson做的计算器比其他人做的更近了一步，可以为您生成CSS规则，这意味着你只需复制黏贴到你的样式表就可以了。

响应式图文的设计工具

响应式web设计的另一个关键组件。实现获取流体图像的技术是直接，优化性能和为不同设备页面加载，这似乎是在响应式web实际中最大的挑战了，以下是一些相关的资源。

18. Responsive Images

Filament工作组想出了一个办法发送合适的尺寸的图片，基于屏幕的解决方案。这个实验使用移动优先的尺寸相应，并且响应式调用两个不同的图片尺寸参考。

19. Adaptive Image

Matt Wilcox收到了Responsive Images工具的启发，创造了Adaptive Images使用PHP和一些小的JavaScript来为用户设备伺服图片，并不需要额外的标记语言。

20. Sencha.io Src（原来叫 Tinysrc）

Sencha提供了一个云服务，从云端发送适合用户设备尺寸的图片。如果您想看如何使用，请点击链接。

docs.sencha.com/io/src/

21. FitText

Paraval公司的另一个宝贝是FitText.js，是一个JQuery插件，使用头版头条风格的web响应式设计来设计并适应用户设备的尺寸。细节请看链接。trentwalton.com/2011/05/10/fit-to-scale/

22. slabText

受到了FitText和SlabType算法的启发，Brian McAllister做的slabText是一个jQuery插件，让粗体文本块响应式重新调整尺寸的同时还能报账定义的宽度。

Media Query的工具

估计现在您已经有了应对不同设备访问时页面布局的策略，流体Grid和流体图像，现在您需要Media Queries来把页面元素改成响应式的状态了。

23. Respond.js

响应式设计的一个问题是，有些浏览器太落伍，不能读取媒体查询。或许这并不是你的目标受众的问题，但这仍然是一个适用旧版本浏览器的用户的好的实践方法，Respond.js是由Scott Jehl制作的，只需要支持属性的最大最小宽度即可。需要了解更多请点击链接。http://filamentgroup.com/lab/respondjs_fast_css3_media_queries_for_internet_explorer_6_8_and_more/

24. CSS3-Mediaqueries.js

这个工具是由Wouter van der Graaf制作的，使得老版本IE或其他浏览器用户能够有效地测试和应用各种media queries.

25. Adapt.js

Nathan Smith，是960.gsgrid系统最初版本的作者，他编写了Adapt.js是一个能检测浏览器规模的脚本，并且能够伺服所需要的样式表，就像Media queries一样但不使用Media Queries，意味着可以在老版本浏览器上也照样能运行。

26. Categorizr

这个设备检测是使用完全相反的视角来进行。Brett Jankord的Categorizr脚本假定了用户都是移动设备，除非检测到桌面浏览器或平板电脑。这样是你的服务资源对各种浏览器更加和谐了。

响应式设计（以及移动开发）的模板工具

有效率的响应式设计的工作流的灵魂就是让模板来方便整个设计过程，让工作流从设计浏览器时更早地移动到下一个缓解。大部分模板工具都结合了上述的那些工具整合进一个package中：一个灵活的GRID，使用脚本语言加强，同时来实现移动优先，内容输出的哲学思想。

27. 320 and Up

Andy Clarke的320 and Up是一款移动优先的模板工具，它继承了很多流行的web设计工具，比如LESS和Bootstap等。这款工具是个轻量级的敏捷方法，能迅速让一个站点建立并运行起来。您也可以点击链接看一下我们对Andy的访谈（http://www.netmagazine.com/interviews/andy-clarke-new-320-and），这篇文章他更多地对我们讲解了新版本的性能。

28. Gridless

Gridless是一个HTML5与CSS3的模板工具，可以作为您的响应时设计的服务基础，它更关注拓扑以及跨浏览器的整合性能。

29. Skeleton

与之前描述的两种模板工具不同，Skeleton开发工具的起点是最小化的解决方案。这款工具由Dave Gamache设计，基于960.gs Grid system把规模减小到移动领域。Skeleton同时自诩是一个伟大的样式框架并适合在其之上构建系统。

30. Bootstrap

由Twitter构建，并且现在已经是开源的了，这是一款框架和一系列的组件，适合快速在线构造一个站点，他的第二个版本各个核心部分都已经是响应式工作的了。

插件，shim和polyfill

（译者注：shim与polyfill暂保留原文，为不影响关键词的理解）

尽管现在的浏览器和软件都趋于变得更加适应响应式设计，但是有时候我们也不得不使用一些额外的工具来保障用户的一致性体验。

31. Responsive Plugin

Marios Lubinski写了一个WordPress插件，能保障任何当前的WP主题方案变成响应式的。这个插件如何工作做着目前也不清楚，因为在本文的撰写时这个插件还没有编写完，但是如果它真的如它所说的那样，做出来之后一定很有用。

32. Overthrow

对于桌面浏览器来说内容一处的处理已经做得不错了，但是旧版本的移动浏览器做的却还不行。这一款叫做Overthrow的Polyfill是由勤勉的Filament工作组为不同设备的访问制作，能确保所有移动用户在可能的情况下能够获得最好的体验。

33. MediaTable

这个是Marco Pegoraro制作的jQuery插件，与Respond.js一起工作，可以帮助您处理大数据量表格如何在小尺寸屏幕设备上显示的问题，可以让栏更加响应式，增加了显示/隐藏功能来增强适应性。

测试，测试：123…

另外一个响应时设计工作流的重要方面就是您需要知道您的目标设备以及解决方案并且测试一下了。下面开始介绍一些测试工具。

34. resizeMyBrowser

这是一个由前端开发人员Chen Luo（看名字像是华裔了）制作的测试工具，带有许多事先预定好的浏览器尺寸以方便您测试各种浏览器，当然，如果没有合适的尺寸您也可以自己创建所需要的像素。

35. responsivepx

与之前说的resizeMyBrowser很相似，这个responsivepx是由Remy Sharp制作的，它可以用一个窗口加载你的页面，并且你可以指定测试的宽度和高度来试试你的媒体查询生成的情况，还可以在设计时加入断点。

36. Responsive Design Testing

这是一个由设计师/开发人员Matt Kersley制作的测试工具，强大到让人难以置信：您只需要简单地输入您所设计的响应式站点的URL，这个工具就能看到各种不同的浏览器尺寸的显示结果了。

37. The Responsinator

只需要输入一个URL，这个响应式机器人就会为您显示在许多常见的设备尺寸中的显示效果，以一个无感情的机器人一般的效率。Tama Pugsley和Andy Hovey现在负责这一款工具。

38. Responsive.js

另外一款页内设备仿真模拟器，Responsive.js让您只需要输入一个URL就可以迅速的重构各种不同的尺寸，这一款工具是即将出现的Typercast app的制作团队研发的。

39. Screenqueri.es

这也是一个浏览器尺寸测试工具，但是这款工具是Mandar Shirke制作的，不同的地方时它拥有扩展的手机和平板电脑的集合，并且想网格标尺一样让测量更加容易。

40. Aptus

这是一个测试站点的app，可以使用很多预定的尺寸，但是Aptus是基于Mac系统的，可以轻松地通过Mac App Store获得，增加了很多额外的特点，例如方便的截屏和线下支持等。

41. Responsive Design Bookmarklet

Victor Coulon制作了一款简单有效的书签工具，它就放进工具栏里面，您可以在任何也免激活它然后您就可以从普通屏幕尺寸和不同的预设尺寸之间切换并且查看区别了。

42. Responsive Design Test Bookmarklet

这个书签工具是由Benjamin Keen制作，支持更加自定义风格的策略，可以让您定义自己的设备尺寸以及其他您希望的尺寸。激活它之后它就可以显示各种您选定的尺寸进行显示以方便您比较。

43. Screenfly

这是由QuirkTools公司出品的工具，使用它您就可以测试在不同解决方案时的站点效果，可以包含桌面，平板，移动设备以及电视。桌面测试目前还局限于Safari，平板和移动设备的浏览器有很多的选择，不过电视访问的浏览器也只支持Opera。

44. Media Query Indicator

Johan Brook提供了一个纯CSS的方式来测试媒体查询，以浏览器方式出发。这款工具很好用，可以设施断点进行测试和运行。

45. Shim

重新设计波士顿环球报时使用的工具之一，RWD运动的海报男孩（这可能是个典故，译者并不清楚所指是什么）Shim是一个Node.js，他可以在同一个Wifi网络中运行一个页面还支持很多不同的设备，使得跨设备测试更加容易。

46. Drive-In

如果您并没有Node.js服务器部署以支持Shim，那么这款由Scott Jehi做的叫做Drive-in的简单版本在功能上和Shim一样，不过它使用PHP，Apache和一个.htaccess文件。

47. Adobe Shadow

Adobe公司继续推进web技术，退出了这一款远程调试工具。安装Shadow之后还需要Chrome浏览器在Mac或者Windows平台上扩展，现在还增加了Android和iPhone的客户端，然后您就可以在不同的设备之间分享页面体验了。

48. Opera Mobile Emulator+Remote Debug

安装Opera以及OperaMobile Emulator是一个十分简单的方式以便调试移动页面，二者之间使用远程调试选项通讯。其建立过程简单快捷，测试起来比webkit更加有效。

未来的启发

想知道别人都怎么设计响应式功能么？

49. MediaQueri.es

可能您还没见过它，但是这个MediaQueri.es站点的访问量在持续增长，已经要超越响应式站点了。

50. @RWD

Ethan Marcotte运营着一个推特账户，发布最新的）RWD响应式页面设计）新闻和工具，以及Showcase案例

您还在寻找更多的灵感么？那么去看看我们的姊妹站点这个博文吧《最顶级的75个CSS和JavaScript技术》

概念以及技术等，所以希望通过本文可以让您更加理解响应式设计。

您可能也喜欢：
与瀑布模式说”再见”：教你5个步骤实现响应式Web 设计	W3C组织关于响应图像的提案引发争议	关注Web响应式设计的局限和误区	18款精美CSS3 Web设计
无觅