Hi，五·一假期大家过的怎么样？灿烂的阳光，有没有出去撒丫子跑呢？自从上次更新后，我偷懒了一段时间。有几位朋友已经开始催稿了，让我五一期间也倍感压力呢！还好我抗压能力不错…淡定的去玩了，没错，我就是这么淡定。
拖了两天，今晚抽空把一篇新鲜热乎的文章翻译了，分享给大家。
这篇文章来自Airbnb的官方博客—《Behind the Scenes: Building Airbnb’s First Native Tablet App》。
好久没听歌了，今天从《La Belle Dame Sans Regrets》开始吧。
PS：连续几篇和工作内容相关的文章了，希望不会让大家厌倦。我在准备别的素材了，希望下次分享大家会喜欢。
幕后：开发Airbnb的首款原生平板应用
在Airbnb，我们（译者注：Airbnb团队）在尝试创建一个能够让人与人相互连接并属于全世界的地方。不论你是正在旅行，打算和朋友去旅行，或者是在沙发上躺着盘算着你的下一次冒险，几乎都是通过移动设备在Airbnb上来进行联络、预定或幻想。而我们的平板电脑用户可能已经惊奇地了解到截止目前我们还没有原生的平板应用。不过，去年夏天我们团队决定改变这个情况了。我们开始思考Airbnb在平板上应该是什么样，而今天我们想和全世界分享这一过程。这是一个具有挑战的壮举，我们要保持现有的手机应用不断地更新和运作，同时还要去打造一个全新的平台；接下来我们将告诉你在这个过程中，我们什么做对了、什么做错了，以及我们最终如何完成的。
（译者注：横屏模式的Airbnb的平板应用，列表的滚动是横向滚动的。感觉就像在使用windows8，不错。）
第一小步很关键
在去年夏天完成品牌化后，我们组建了一个小团队去落实为平板进行开发的基础。为了开发平板应用，我们采用了许多从品牌化中学到的技术知识。例如，就像品牌化一样，我们期望通过几个版本的迭代，然后发布官方版的平板应用。就这样，一个由设计师们和三位开发工程师（两位iOS工程师和一位安卓工程师）组成的团队开始构建应用的基础部分，并不断探索平板应用开发领域。
我们不可能重写整个整个手机应用，同时为了保证使用体验，我们必须使用一些在手机应用上已经应用的视图样式。之后，我们重新评估了手机应用上的每一个界面、每一个功能，以估计每个界面的设计成本和开发成本。与此同时，我们快速地意识到一个问题：我们的顶部导航系统“AirNav”并不利于转换到平板应用上。以至于我们不得不重新设计这些界面。（译者注：以前Airbnb的导航栏位于顶部）
Airbnb变成标签导航
我们一直力争在Airbnb上实现无缝的跨平台体验，不论用户用什么设备、什么尺寸的设备都能得到一致的功能和体验。这意味着我们所选择的导航系统在平板和手机上都能有相似的表现。为了快速找到一种覆盖面足够广的导航解决方案，团队分头设计了尽可能多的原型方案。我们的一个设计师——凯尔·皮克林，甚至去自学Swift以便自己构建功能原型。最后一周，我们有几个以各种各样的形式展现的原型，如用线上代码开发的功能齐全的原型（尽管变态）、用Swift开发具有基础功能的原型、用Keynote或After Effects制作的原型，之后我们把这些原型给用户研究团队并得到了一些真实用户对这些设计的反馈。Airbnb团队文化的一大特点是快速行动、快速实验，而不是等到最后。在部分手机（译者注：应该是指iPhone6 Plus）可以使用横屏模式后，我们决定使用标签导航。
由于移动团队的大多数还在忙于开发新功能，我们不得不悄悄地开发并测试我们的新导航，而我们的测试方法是在不需要重启应用或者中断用户操作的情况下，启用或者关闭我们的新导航（译者注：A/B测试）。最终，通过我们收集了几个月的数据，我们在2014年11月推出了我们的新导航系统并应用到我们即将推出的平板应用中。
有趣的事实：直到平板应用推出，这两个导航依然在使用中，并且能够通过实验性标识控制开/关。（译者注：①左为旧导航，“汉堡包菜单”； 右为新导航，标签导航）
试水MVVM（某种意义上）这一段涉及iOS开发，我勉强翻译，见谅
在iOS平台上，MVC是一种开发设计模式。
我们传递的只是一个通用的二进制文件（译者注：其实是想表达“程序”）；我们并不打算拆分目标或者推出两个应用程序（指手机和平板）。但是就代码架构而言，通用应用有可能会让我们的代码随着时间的推移而变得臃肿。不需多久，这种方式就会使得代码库充斥着散裂的逻辑、为了试验而复制-粘贴的代码、重复的跟踪调用。同时，我们并不希望把各个平台上的视图控制器类（译者注：view controller classes）作拆分，这就要求我们重新考虑以前屡试不爽的MVC模式。
我们意识到，在我们的数据层中（消息、用户、愿望单等）的model对象几乎都有三种UI表现方式：一个表格视图单元、一个集合视图单元和视图控制器。
这些表示方式在手机和平板上都不一样，所以与其让使用这些对象的地方存在逻辑分支，不如去请求model如何去显示。所以我们建立了一个视图model协议，允许我们为任何model对象去请求它的“默认表示视图控制器”。这个model返回一个适用于特定设备的视图控制器，起初我们只用这个视图model对象只需要返回适用于手机的视图控制器；当我们需要适配平板时，我们仅需要改变一行代码即可适配平板的显示。
这样令我们减少了大量的代码重构工作，还可以把工作重心放在完善视图控制器上，同样的也避免了代码分裂，只需要检验几个类而已。之后，我们便把应用于手机的视图控制器代码过了一遍，并把追踪、试验的逻辑加入到手机与平板共用的视图控制器中即可。最终MVVM可以让团队继续在手机应用上努力，而新增加的实验性功能和新特性会自动转入到平板应用中。
踢球上坡
2015年1月，平板开发团队全员待命，设计方案也已经可以进入开发。我们有大约两个月进行开发，一个月进行测试和修bug。设计制作了几个能够完全演示的交互原型和UI动画，在这些代码驱动的演示原型中，设计团队能够更早的在正式开发前发现一些陷阱。然而，还是不可避免的冒出了几个问题。
这个程序中的几个滚动页面，设计师要求做轻微的滚动回弹；当时的想法是希望滚动视图能够减速到完美渲染其中的内容。这不是一种革命性的设计，但是在大尺寸的平板设备上，这样的交互反而会惹恼用户。一个用户将这种设计称之为：“在山坡上踢足球”。虽然，最终的结果是令人满意的，我们没有完全地砍掉这个功能。
回到问题，在此之前，当用户完成了滚动操作时，我们会预先计算其目标内容最接近的捕捉偏移处，然后回弹。但是我们发现这样设计存在一个问题：我们并没有考虑到用户的意图。如果用户用手指滚动一个页面并以抛球的方式脱离屏幕，那么这样的设计是很好用的。但如果一个用户有目的地停止滚动，然后在最靠近滚动回弹的点完成触摸操作，这个时候就会发生“上坡踢球”效应。我们决定当滚动速度低于某一个值时禁用掉滚动回弹，将控制滚动体验的权利交给用户。实现这些小功能并真正地理解用户的意图，将是应用程序的体验和可用性达到更新的高度。
时刻准备着
当我们冲破终点，按时完成这个项目（大部分）后，我们花了一点时间来回顾我们在这个大项目里都做了些什么。我们始终谨记老童子军的口头禅：“时刻准备着。”虽然整个团队在短短几个月里就完成了平板的应用，但这是建立在之前一年的默默准备工作之上的。设计师们学写代码和准备原型，并早在发布平板程序之前的几个月之前就把平板的导航模式迁移到手机上，这些准备工作都确保了我们能够按时完成目标！我们已经准备好。
（Airbnb团队）
译者写在后面：
1.这篇文章其实有可以拓展出很多篇文章，比“如汉堡包菜单与标签栏菜单的比较”、“为什么横屏时使用横向滚动而不是统一的纵向滚动”、“为什么Airbnb的平板应用把私信独立成一个tab而手机应用上不这么做”等等。这些问题可以留到以后再统一整理。
2.有部分涉及开发的术语（包括view、model、controller等）不知道如何去准确翻译，还是原汁原味比较能理解。
3.深感“未雨绸缪”的重要性，而不是临时拍脑袋。
最后，伴随着《Let you win》的音乐，结束这一次分享。
