原中文标题为『一种抽屉导航的替代方案』，后接受Pinapps的5key老师批评，更换为『一种抽屉导航的改进尝试』，特此说明
关于抽屉导航（三线icon/汉堡包菜单）的文章和讨论已经够多了，如果你对它的起源和发展感兴趣，可以点我。本文无意加入这些讨论，只是想寻找一种更好的替代方案，毕竟抽屉导航的缺陷早已成为公论：
效率低下：交互有够麻烦的
导航性差：不知道自己在哪
塞满了各种乱七八糟的功能
先来看看有哪些常见的导航模式
在此之前我想先老生常谈一下：每一款产品都是为特定用户群体而设计的，你需要仔细琢磨用户的使用场景，一些方法兴许适合你，但对别人却未必。
1. Swarm和标签导航
在Swarm by Foursquare的1.0版本中，点击左上角的头像是前往个人中心的唯一途径。
Swarm by Foursquare
这看起来很机智，还有比头像更能代表个人中心的icon嘛？但实际情况却是除了设计者之外没有人能理解这个交互，呵呵。所以只过了一个月，Swarm就把个人中心挪到了底部标签栏。
标签导航是最常见和实用的，尽管会占据一些屏幕空间，但它的好处确实足够多：
可见性强：全都在你的屏幕上
结构清晰：最多只能五个标签
交互方便：只需点一下，搞定
即便是自2010年起便在使用抽屉导航的Facebook，也从2013年开始投入了标签导航的怀抱。更多关于标签导航 Vs 抽屉导航的讨论
不过Swarm的导航还有精进空间，比如他们的导航只有icon没有文字。诚然icon会更直观和形象，但这对icon的要求会很高，它必须要易于理解，不然还是像Facebook那样用文字说明一下比较好。
Swarm&Facebook
如你所见，Facebook为每个icon都加上了文字，就算是像「设置 - 齿轮」这样约定俗成的隐喻。而Swarm则使用类似于蜂房的icon来隐喻个人中心，理解成本显然较高。
也许没我说的那么严重，但许多对设计者而言显而易见的事，对别人来说却可能难以察觉，这却也是事实。
【译者注：恰好Be For Web也翻译了一篇关于icon和文字的文章，同样推荐。】
2. Tinder和滑动导航
我把以Tinder、Snapchat及其他APP为代表的导航方式称为滑动导航。
这类导航模式的特点在于体验的自然性，它与滑动手势相得益彰：整个APP就好像是一块水平长条的大屏，无论你如何滑动都只是切换到大屏中的某一部分而已，这使你几乎可以抛弃「点击」操作。
有得必有失，滑动导航的一大缺点是你无法直接从第1个页面切换到第3个页面，更重要的是，作为页面标题的导航icon至多只能显示3个，其余的会被隐藏起来，你需要遍历所有页面才能够知道这个APP有哪些页面，他们分别在哪，这确实不够直观和便捷。
不过对于只有3个主页面的APP（比如Midpic）来说，滑动导航可谓如鱼得水。
Midpic
也许我们可以通过「无限水平滑动」来改进这一导航模式，这能够消除用户在最左端/右端2个页面时的碰壁感。
Tinder
3. BAG和下拉导航
BAG的设计者Nacho Rapallo引入了一种全新的导航方式：下拉屏幕——就像下拉刷新Feeds那样，不过需要拉得更多——切换页面。
BAG
这种交互模式的讨喜之处在于，它类似于抽屉导航，但却没有抽屉导航的部分缺点：
不占地儿
五个标签
交互很快
抽屉导航最大的问题在于当你切换页面时，你需要先点击汉堡包icon（或右划），等待导航打开，然后再点击目标icon，如果你不小心点错了，就得再来一遍，这太浪费时间了。而通过这种交互方式，你的手指完全不需要离开屏幕，效率大大提升。
不过这种交互方式并非没有缺陷，如果你的APP包含Timeline，而用户滚屏后需要切换页面时，要首先返回顶部才能进行进行该操作。同时，作为一种不可见性的交互方式，用户需要被引导，这会很困难。因此我不太推荐初创企业过多使用创新型的交互模式，这会使早期用户赶到迷茫。
4. 我的替代方案
经过深思熟虑，我尝试出一种能够避免上述所有缺点的导航模式。我把BAG的下拉改成了侧滑式，这样一来就能避免滚屏的麻烦。我们来看看它长什么样：
Slide navigation pattern by benjamin berger
我承认它还不够完美，比如导航依旧是被隐藏的，用户需要去学习和习惯。此外它还与我们常用的右划返回手势会发生冲突。不过它确实要比抽屉式导航更好。
（之后的内容和前文关系不大，故略去）
译后记
俺赶脚应该紧跟潮流，叫Force Swipe比较好。
不过，BAG这种方式也是双刃剑：有Feeds的APP用这种导航方式学习成本会更低，主流程也会更清晰，但需要返回顶部确实是个麻烦；而其他类型的APP没这个麻烦，但学习成本也就更高了。
另外抛开这个不谈，译者认为根据用户场景来看，这种导航方式最多最多只能容下3个Tab，毕竟大多数用户屏幕下拉的初始高度不会很高（本来屏幕就大），4个的话，每个Tab的下拉距离空间就太小了。
至于原作者提出横向滑动，其实也很蛋疼。横向滑动的空间本来就小，这样一来最多容纳5个功能了不得了，而抽屉原本的优势之一就是扩展性强，这下等于连这个优势也没了，所以意义何在呢。
不过这篇文章还是提供了一种视角，这也是我为什么要翻译它。毕竟当初抽屉导航被各种抛弃，和屏幕变大不无关系。而在大屏的当下，滑动显然是比点按更高效的一种交互方式，但二维手势始终是有限的。
所以我们看到苹果将「点按」扩展到了三维空间下，提出了Force Touch，而滑动其实也能扩展到三维——像BAG一样给它一个位移（拉力大小）的概念，而且这还不需要硬件支持。也许真的可以试试，不过方向应该不是在导航上。
网友评论
然后，说说文章本身，其实主要是想说说作者设计的新交互方式。本人并不是交互设计师，但对于交互设计很感兴趣。我认为作者的新方案可能存在以下几个方面的问题：
产品&体验层面：
1、抽屉设计近几年来一直被业内人士诟病，但它依然是用户认知程度最高的交互设计之一，想要使用没有抽屉icon用来提示的手势替代用户习惯，难度可想而知；
2、抽屉的设计固然有许多不便，在许多时候增加了用户操作的难度。但，很多时候我们需要这种增加用户操作难度的设计。作者的新设计让用户很容易实现产品人员不太愿意让用户看到或使用的页面或功能（比如退出，退款），给用户以强提示，这显然是不可取的。
也许你认为这种做法可以应用到图片或者导购之类的应用上，用作浏览，很遗憾，这在逻辑上是错误的，主要是因为在交互规则中横向代表同一种类的不同属性，纵向代表不同种类，就像我们在使用购物网站在填写订单时，你所看到的让用户选择不同支付方式时，采用的横向的展开，而你只能选择其中一个，而在你填完了地址后，需要填写纵向的表单“联系电话”，你需要把每个纵向的表单都做选择--填或者不填，填什么，这就是不同种类，这些都是逻辑；
3、正如大家看到的，抽屉导航往往出现在页面的左上角，而不是右上角，原因就不解释了，仔细考虑使用场景就知道为什么了。而作者的新设计中居然使用了手指右滑，出现导航并切换页面的做法，这个显然是作者并没有考虑到实际使用场景，是不合理的，因为抽屉起源于欧美，也盛行于欧美（国内更流行底部tab），作者也应该是欧美人士，所以如果要采用滑动切换的方式的话也应该向左滑动，因为数据证明欧美用户更习惯用左手操作手机，而如果用左手手指（大拇指）向右滑动的话，一方面可能长度不够，另外一方面手指会挡住菜单。
技术层面：个人认为作者太理想化了，当前在国内我们打开一个APP的页面其实都不能算是十分流畅，即使国外的网速远胜于国内，想要在数个页面流畅切换，想必至少也需要一个加载缓冲的时候，所以在第一次使用时，这种等待，尤其是等待后且发现并不是自己想要的内容时，它势必会成为一种致命的煎熬。然后如果该设计应用在浏览性质的应用时（如Twitter、path），会怎样呢？要知道这类用户关注时效性，那么该设计在滑动切换时能够及时刷新吗？如果不能，用户还需要再次下拉刷新才行，这就造成了二次操作。诚然，在摩尔定律的推动下，这些都不是问题，一切都只与“设计”关联，但至少现在无论是在实现上还是在用户认知上，都存在问题。
“它确实要比抽屉式导航更好”，这句话在某些方面上确实正确，想要凭借一个简单的小设计去击败一个已经成功的小设计，恐怕绝不简单。
作为一个非专业的交互设计爱好者，我仅提出自己的想法，可能存在纰漏或是错误，万望见谅。
根据右划的位移长度决定切换到哪一个，而不是一直按住等待自动切换。
不过还是有点麻烦就是了。
但我翻译这篇文章并不是为了说这个方案好。