这篇翻译不完整。请帮忙从英语翻译这篇文章。
简介
一旦你有一个关于Web应用的想法，你应该在进行任何的编码和设计工作之前仔细的规划一下它。对于你们大多数人来数这一点是显而易见的，但是这一点要求并不过分，无论你是在创建一个完全新的应用，还是要扩展一个已经存在的应用。这篇文章包括了在你规划一个应用或准备要实现它时应时刻牢记的主要概念。
注意这是一个简单、普通的流程，用来帮助人们入门；如果你是一个优秀的企业开发者，那你可能会有自己的应用于开放Web应用开发的流程和习惯，那样也不错。
构思
首先，你应该尽量简要的写下应用的预期功能和目标用户，并且你应该设想目标用户可能会使用它的上下文/环境。对于我的简单应用Location Finder，我写下了一下两个列表：
功能
- 尽可能准确的获得设备的位置
- 在谷歌地图上标出这个位置
用户群
- 想要学习开放Web应用和Firefox OS开发的开发者，他们可能是在办公室或在火车上
- 任何想要了解自己身处何地的人，他们很可能是在郊外或离家很远
你应该尽可能的让应用简单；专注于让它只做一件事——或者几件相近的事。当然，你如果想要实现一大堆不同的功能，你可以把它拆分成不同的应用。你的应用在不同的平台上可能需要不同的体验，所以你可能不得不把列表分成桌面版和移动版（或者甚至是平板电脑或电视等）
接下来，尝试为一个应用写一个用户友好的概括，这将吸引人们去下载并尝试它。如果你可以用一句话概括它，很可能你的想法就是一个很适合app的想法！对于Location Finder，我写下：
Location Finder使用地理定位来找出你的位置并且利用谷歌地图API显示一个你周边的环境的地图
不过，对于一个单纯针对终端用户的应用，我一般不会加入技术名称，它最终会更像这样：
Location Finder找出的你位置并显示一个你周边环境的地图
但是既然这个应用大部分是用于技术开发者，我觉得这个描述会更有用
绘制
一旦你决定了你的应用意图和目标用户，向来是从纸上绘图开始最好，尝试粗略画出不同的屏幕来表示应用看起来是什么样子，以及用户会如何使用此应用。你很可能会为桌面、移动、平板电脑、电视等作出不同的素描集。
无论如何，加入每一步所需要的图像资源和函数等，因为这样可以在设计和开发阶段知会你的选择，也可以防止你丢失一些东西。对于Location Finder来说功能非常简单，所以我决定只用一张图：
对于一些更加复杂的程序，你可能需要包含多个屏幕素描来表示主视图以及其他一些代表用户使用时不同流程的视图。
任何程序都可以作为开放Web应用工作？
只要你牢记上面提出的建议，差不多任何页面、程序或网站都可以作为开放Web应用使用；除此之外保持简单。如果应用很复杂的话（比如一个文字处理器或一个大型电子商务平台），它就无法在任何语境下作为app工作，因此你需要考虑针对不同设备创建不同的用户体验比如在移动设备和平板电脑。比如，eBay的桌面网站有广告、不同的搜索方式以及其他一整套的特性。相对而言，网站的移动版本隐藏了大部分的特性和广告，仅仅在界面的最上方呈现了最流行的功能，并且最小化了交互所需的按键个数。
Google Docs是另一个可考虑的有趣例子，他的桌面网站是一个包括许多控制项的功能完整的文字处理程序，但是这如果用在移动端上将是一场噩梦，因此移动端只是利用一个简单的界面让你去浏览你的文档
在这一步，想一想怎么呈现不同的版本。多数情况下你可能使用media选择器来为你的工程在不同浏览器上优化布局和功能。但是，如果你已经收到了把沉重传统的企业桌面网站转化成移动app的任务，或者如果桌面版和移动版的体验根本完全不同，牢记在心，你最好创建一个分离的移动/平板电脑网站或app。
注意：如果你提供了一个根本完全不同的桌面和移动体验，你应该为你的用户提供一种在两种之间转换的方式，不要假装你总是知道什么对他们的最好的。
考虑你所需的技术
一些人会将这一步归入上面提到的“构思“这一步中，但是可以说，技术和功能或布局分开考虑会更好。你应该首先单纯地从什么对客户最好的角度来考虑你的功能性，而不是把一项技术硬塞进一个项目中，仅仅因为它是最新最酷最闪亮的玩意儿。一般来说最简单的方法就是最好的。
我们将在开发网络应用中更加详细的讨论这个问题，但是通常你应该考虑你的应用所包含的主要功能或要求，并且实现这些的最适合技术。例如，你应该问的问题包括：
- 你是否需要离线储存？如果你的应用需要保持数据，你通常需要一种服务器端的语言和数据库。如果你想要离线或安装在设备上之后继续使用它，你可能不得不将数据储存在一个客户端的存储装置中，比如本地索引数据库或者本地储存设备。
- 你是否想要播放或处理媒体？你很可能会需要HTML5特性比如
<canvas>,<video>, or<audio>. - 你是否想要从设备或它的环境中获取信息？你将需要使用众多设备API中之一，比如Battery Status API, Proximity API, or Device Orientation API.
测试方案
另一件显而易见但却常常被忽略的事是测试。你应该尽可能早的而且频繁的测试，毕竟基础错误发现的早相比未来在项目开发已经进行很多的时候发现可以节省很多的时间和金钱。一般的测试方案如下：
- 一旦你写下了你应用的功能和目标用户，与一些同事、朋友和家庭分享它。最初它听起来是不是一个好主意或很荒谬？它是仅仅只需要微调一下还是适度的重新思考？
- 也将你的初略构图作为feedback分享出去。是否有什么明显的遗漏？还有什么可以极大提升体验的东西？
- 然后，创建一个功能原型允许人们进行关键功能的测试和交互也是一个不错的主意。挑选一些开发团队以外的人来测试这些交互功能并看看他们有何表现。如果你无法负担起一个专业的用户测试设置也没有关系，选择一些朋友或家人通常也不错，你可以管理提供恰当的问题和测试。
- 当你进行应用开发的时候，根据实际情况多次重复用户测试的过程。假设你现在正在开发一个真实的应用，在尽可能多的浏览器和设备上测试，从最主要支持的平台和工作环境开始测试。考虑在不同浏览器和设备上的可接受体验是什么，不要仅仅只是测试常用功能——看看应用在一定压力和一些边缘情况下，比如恶意输入数据和相当老的浏览器下的表现如何。
- 在接近项目尾声时，进行一轮严格的QA测试来剔除出最后的邪恶虫子（bugs）；它们经常在你最意想不到的时候在你的脖子上咬一口。
总结：应考虑的几点
希望这篇文章已经给你在成功创建一个开放Web应用之前所需要的大部分内容。下面的列表提供一个总结。
你的应用目的何在？
创建一个列表包括各种任务、你的应用的想法和你的目标用户类型，然后写下一个目标阐述：如果可能在一句话中标明你的应用目的和最重要的用户。例如：为从不进行冲动购物的人提供一个心愿单创建工具。
专注于一个主要案例
很可能你不能在你目标阐述的列表中包括所有任务。没关系，因为极好的软件只做好一件事。如果你的应用尝试做太多的事，考虑一下把这些功能分离到多个应用中去。
人们将如何使用你的应用？
至此，你已经发现了你的主要案例、目标用户和主要特性。你的主要场景也应该考虑到用户使用时的环境。比如，一个在日托所带着孩子的年轻妈妈可能需要你的应用来指出好的婴儿推车（潜在的多任务，停止并在以后继续任务）。另一个不同的用户可能会计划在家、在手扶椅上无中断的买下她的下一个手提电脑。
专注于很少一些关键特性
再看一遍你的任务列表。根据目标阐述过滤你的列表。如果任务与你的目标不一致则从你的应用中排出他们。将每一项核心任务描述为一个特性然后质问你自己，这个特性是否必不可少？或者它只是有了更好而不是目标用户在完成预期任务时所必须的？诚实的对待自己。如果你以一个简短的特性列表结束，那你就走对路了。记住，最好的应用通常只做好一件事。应用常常因为拥有了太多太小的特性而失败。
画出你的应用
一旦你在脑海中有了一些主要交互界面，你可以将这些步骤翻译到屏幕上。你可以画出用户流来表示你的用户如何从一个屏幕跳转到另一个直至完成一项任务。考虑你的应用的功能，然后把与最重要的交互相关的用户界面元素放在最突出的地方。考虑你的应用相对于平板/移动设备在桌面屏幕上看起来如何。
所需的技术
根据功能列表，制作一些备注，关于构建这些需求最可能会用到的技术。
测试方案
在你的项目规划中建立一个合理的测试方案，以此来减少在以后的实现阶段命中”昂贵而又意想不到的惊喜“。