转载

快速构建Android应用原型实践

导读：本文作者Juhani Lehtimäki，现任Fat Robot联合创始人兼CTO，在过去三年里一直负责游戏《Lands of Ruin》的原型制作，由此撰写了自己在构建Android原型方面的实践经验。

以下为译文：

我最近更文较少，原因有两个：

Android最近优化了很多，没有太多可抱怨的地方。各家公司都开始了解：理解Android设计并进行正确的设计有多重要。最多就是说说新G+应用？

这个是主要原因：之前我一直在忙一个项目，努力将长时间的兴趣变成真正的产品。我和朋友怀抱一腔热情，开发了一款名叫“Lands of Ruin”的新型混合模式的模型游戏。这是一款Android的微缩模型游戏。

在过去三年多以来，我一直在负责构建这款游戏的电子部分（制作Android应用原型），并发现其实在Android平台上，只需使用本地原生代码，就能快速建立起原型。

缘起

在详细解释我们的工作内容和工作方式之前，先说一下我们正在做的事情。

Lands of Ruin包括桌上模型游戏以及同名的平板电脑应用。这样的应用前所未有，尽管混合型的游戏也有人尝试过，但我们的游戏跟之前那些有本质上的不同。简单来讲，我们想要在物理实体游戏与电子世界间建立平滑的交互。换成是你，要如何做呢？我们没有能够借鉴的样本，也没有可以照搬的想法，只能从头开始，从无到有地创建这样的交互。

第一步：纸

所有伟大的项目都是从一根笔和一张纸开始的。在快速原型构建上，纸和笔就是无价之宝。无需写下一行代码，就能了解需求，最棒的是，这部分的工作可以通过协作完成。智慧的头脑乘以2>所有其余的部分加起来！

我们最早的纸上原型甚至没打算画出平板UI，而是通过纸笔，找出需要追踪的地方和需要自动化的部分，这时讨论UI还为时过早。首先，在讨论“怎么做”前，我们必须先解决“做什么”的问题。

很遗憾早期的图纸都找不到了，不然还能跟大家分享一下，它们大多都是画在纸上的备忘列表。

常规迭代

在项目最开始，理解速度很快，迭代也非常频繁。我们必须为这个作为业余爱好的项目建立一个工作日常。我们的解决方案是在每周抽出一个晚上进行测试，最终决定的测试日是周四晚上，三年来一直如此。每个周四我们用目前的原型玩一局游戏，然后讨论改进想法和下一步的工作。然后为下个周四设立目标，再分开各做各的事。在未来一周内，我们会执行各自的任务计划，同时进行头脑风暴类的对话（一般在酒吧里），来解决遇到的问题。这种办法非常有效！

周四游戏夜还在继续并非偶然。不过如今的游戏夜，一般会有访客到我们办公室来，一边玩游戏一边喝上一两杯，虽然我们对互动的改进仍在进行。我们将在会话时发现的问题记录下来，希望在下个周四前修复掉。

第二步：功能性的“内容”原型，或者验证概念

在最初的纸面阶段过去后，我动手编写了第一个Lands of Ruin应用。这时我们在UI和功能的表现方式上花的心思很少，第一个原型还是用来理解应用需要涉及的内容，

在构建某个全新的东西时，有一个值得思考回答的问题：

引用

“为什么以前没人做过这个？”

对于这个问题，一般大概有三个答案：

概念太蠢不值一做；
没人想到过；
之前缺乏支持的科技。

如果回答是2，那么你有可能是在骗自己。地球上的人那么多，很多聪明人的智慧远超你我。

要想回答这个问题，我们决定：要对概念进行验证。就是抱着这个目的，我们开始编写代码，得出的成果如下：

快速构建Android应用原型实践

此时的结果，无论在UI还是体验上都还差得远，不过这两者也并非我们设计这个原型的目的。这个原型让我们能够第一次真正的体验这款游戏。这个应用已经定义了有限的规则及功能，因此我们可以通过推敲，得出完整产品的规则和功能。

这个原型还有一个重大的意义，就是能让其他人试玩了。当然，最初的体验者想要顺利玩下去，需要我们提供很多协助，不过这些体验是非常珍贵的。我们能够了解到这种概念的优势，并确定继续往下做。

我花了大概两周的时间，在晚上编写代码。虽然UI几乎没有，不过核心已经出来了。游戏角色有了，动作可以执行，玩家还能用平板通过WiFi与其他人对话。

第三步——快速建立原型

一旦对想做的东西有了足够的了解，就该思考如何构建了。这时，是时候开始构思真正的UI了。我们做了差不多有15个测试版来累积经验，关于交互还有很多不明白的部分，特别棘手的就是电子与现实世界之间的连接，在我们的设计中，应用需要大致了解在战场上模型角色所处的位置。

我们需要更多信息，用概念验证原型无法测试最复杂的那些设计理念。是时候再多花些时间在应用上啦。

最开始我们坐在一起，在纸上画出想要的东西。在纸笔快速迭代阶段过去之后，我们开始利用Omnigraffle画些更具体的内容。

快速构建Android应用原型实践

此时想要用纸原型玩游戏不再可行，我们用Omnigraffle线框图进行讨论，然后决定这个概念值得一试。

成果如下：

快速构建Android应用原型实践

此时离直观或美观还相距甚远，不过已经包含了游戏所需的一切功能。游戏蓝图已经有了，并且运作良好，这是第一次可以按照我们预想的方式来玩游戏了，此时我们在这个项目上已经花了6个月的时间。

问题

现在，随着原型的保真度更高，我们开始了解存在的问题。尽管距离最终的解决方案还差很远，不过理解问题所在的第一步已经有了。

这时候事实已经非常明显，操纵角色并不容易，也不好玩……如果某款游戏的互动无法令人开心的话，就不能算好游戏。

我们开始进行设计迭代，并非视觉上的，而是功能上的。我们想要在小小的7寸屏上找出足够的空间，让用户很容易便能访问所有的组件。我们增加了折叠式抽屉（sliding drawer）控件，以查看更多细节；又增加了view pager控件，以快速切换角色。

下面是其中一个迭代：

快速构建Android应用原型实践

下一次迭代：

快速构建Android应用原型实践

再下一次：

快速构建Android应用原型实践

我们不断移动物体、修调其大小并进行重排，每次都会感觉距离目标更近一些。游戏测试者越来越多，每版的反馈也越来越好。

碎片功能（fragments）非常强大

我想要指出一件事，与你听说的可能有所不同，Android的fragments在设计原型方面非常强大。

我们的游戏UI到了现在还全都采用的本地代码。作为Android开发者，这是我最了解的方式，也是我能最快得出结果的环境。截屏中可见UI的各个部分都是独立的碎片，在上面的截屏中能看到5-7个碎片，每个碎片都了解各自需要展示的内容，并订阅着中心游戏状态（gamestate）的变更。碎片之间不会直接对话，所有通讯都通过事件总线的方式来去耦。

这一架构允许我们进行快速迭代。无论该碎片位于哪里，或者其他碎片是否可见，碎片中当前游戏状态下角色应当如何表现都是有规则的。

这种去耦的事件总线架构让我可以将某部分UI完全从一个原型改成另一个，而无需担心影响其他部分，也不需要对UI进行整体调整，而游戏修改后的版本仍是可玩的。

第四步——设计

最终我们进行了足够的测试，收集了充足的数据，因此可以进行下一步了。目前的原型太过简单丑陋，很难在公开场合展示。刚好我们有个机会，参加当地的制作者盛事Make Munich，将游戏公之于众。

我们需要这个机会。我们决定在Make Munich上发布我们的游戏，因此先将这款应用在Google Play商店上架，进行封闭测试，希望能找到更多团队之外的人试玩，从而找到视觉设计人员。

Rick是LoR团队的设计师，他接受了这个挑战，成为了我们的视觉设计师。结果，我们获得了这个UI：

快速构建Android应用原型实践