?页面跳转中的返回、取消、关闭   在聊 push & pop，present & dismiss 两种页面跳转方式之前，我们先捋一下移动端里在页面跳转场景下，返回、取消和关闭这三种交互逻辑的使用场景，这有助于我们更好地理解 push & pop，present & dismiss 。 首先，从字面意思再认识一下这三个词：

「返回」：指回到一个地方或状况或从一个地方或状况回来的行动。

「取消」：使原有的制度、规章、资格、权利等失去效力。

「关闭」：指企业、商店或学校等歇业或停办，关闭的主体也可以是虚拟的如论坛、网站等。

以上，我们可以形成一个比较清晰的概念了。 1. 对于「返回」—— 回到某一任务流程上一步。 这个行为需要有一个“路径”的存在，即需要在两点之间发生运动，才会有「返回」行为的产生，具有连续性。 例：去教室上课的路上发现作业没带，“返回”宿舍去取。 2. 对于「取消」—— 终止一个当前可执行的动作。 意味着一个行为的“中断”，即后续本应该还有行为的，但是在操作过程中行为终止了。 例：年初买了去英国的机票打算4月份请年假去旅游，没想到发生了疫情这样严重的事，无奈只能“取消”行程。 3. 对于「关闭」—— 退出一个场景或功能。 现实生活中关闭门窗、关闭商场等，网络中关闭页面、关闭弹窗等，虽然这些行为所在的“场”和“空间”不一样，但是关闭行为的特征都是相同的——将一个原本敞开、暴露给用户的“通道”闭合。为什么用“通道”形容，因为对用户的访问是有纵深感的：打开的大门可以任意进出，打开的网页可以让用户徜徉海海内容之中…一旦将这些对象「关闭」，那么这一切都无法再访问。现实生活中，被关闭的事物虽然无法访问，但能看到关闭的那个屏障。而与现实生活中不同的是，在互联网界面中，被关闭的页面看不到。关闭行为不具备连续性，且行为发生较为独立，和之前、之后的操作都没有依赖性。

由此，我们可以梳理出返回、取消、关闭各自的特点： 返回

1. 具有连续性，遵从页面的层级顺序

2. 具有整体性，在产品功能页面关联性较强的功能中，“返回”通过“返回”将产品功能步骤串联起来，为各个页面建立联系

取消

1. 后续还有行为未完成，强调中途“放弃”这一行为 2. 应用于有一系列操作行为的页面中

关闭

1. 具有独立性，与产品当前页面内容无关，如小程序 2. 非连续性，“关闭”为一个行为，操作后立即发生，与上一层级页面无直接关系 3. 行为已结束，用“关闭”而非“取消” 4. 有时候会用“ x ”按钮代表关闭 但需要特别注意的是，有时候，「取消」和「关闭」的界限是比较模糊的。在一些场景下其实并没有明确区分「取消」和「关闭」。但是，我们还是 建议 ：当页面的承载功能仅为浏览查看作用时，使用「关闭」；带有操作性功能(编辑、分享、新建)的场景下用「取消」。 下图中可以发现，微信在两个相似场景下分别使用了「取消」和「关闭」两种方式，其实这两个场景下用「取消」或「关闭」都是可以的，你可以理解为用户想要 「关闭」 加载完成的好友列表，也可以理解为用户打算 「取消」 当前操作。不过，虽然用语的不同并没有对用户的使用产生较大的摩擦，但从严谨性来说，同一产品内并未做到很好的统一。钉钉同样是发起群聊功能，采用的则是与微信不同的「取消」。 (个人思考：在发起群聊操作中，采用“取消”的原因是否是考虑到和右边的“完成”按钮相呼应呢？) 下面我对以上三种交互逻辑的一般情况各找了2种实际场景，可以感受一下，先做一个简单说明： 「返回」——  从当前页面切换到了子页面，当前页面和子页面是有清晰的逻辑顺序的； 「取消」——  支付宝中，在好友聊天窗口里，点击“转账”进入转账页面，想要放弃转账时，点击“取消”退出转账页面；知乎中，点击“写文章”进入文本编辑页面，想要放弃编辑时，点击“取消”退出文本编辑页面(知乎会自动保存草稿，提升容错率)； 「关闭」——  知乎中，“直播”功能与主页面的内容是不耦合的，具有独立性且非连续，因此退出直播直接点击“ x ”，即关闭；支付宝的语音对话界面中，语音对话相较于主页面内容也是独立的一个功能模块，因此退出采用“ x ”按钮。    

一般返回流程

   

一般取消流程

    一般关闭流程

有一般情况，就会存在特殊情况。可能由于业务方的要求，或者产品在功能和用户转化上有所考虑，在架构层级上会对「返回」的路径做一些改动。所以「返回」不一定会按原来的路径回去，典型的例子为网易云音乐。在这我们不谈这种做法的好与坏、对用户带来怎样的影响(可能见仁见智)，仅就这样的逻辑自己品一品吧：

另外还有一种是「返回」和「关闭」同时存在的情况。这种场景我们可以认为是对于一个具有复杂或者多级结构的内容，用户既可以逐级「返回」到原页面，也可以直接「关闭」这个独立流程回到原页面。但我并不喜欢这种方案，个人认为这样的设计并不容易理解(至少很长一段时间我不会区分这两个按钮，而是随缘点击)。   ?Push & Pop 与 Present & Dismiss   做了这么长的铺垫，我们应该能轻松理解这两种页面跳转方式了。 Push & Pop 最常见的页面跳转方式，意符为新页面从右向左滑入；返回时新页面从左向右滑出，老页面回到界面当中。采用这种跳转的页面一般有逻辑上的连续性和清晰的层级关系。页面与页面通过 push & pop 相连接，能够体现一个流程/功能的完整性。 这种跳转方式会采用的回退用语为「返回」、「关闭 / X」，如何使用需要结合具体场景具体分析。

简单说一下为什么 push & pop 中可能会用到「关闭 / X」。可以观察一下微信公众号点击进入文章页的左上角按钮，此时为“ X ”，即关闭。 因为文章内容已经加载出来，这个行为就已经产生并结束，且公众号文章属于第三方输入内容，具有独立性，所以使用「关闭」。不过 在这个场景下跳转方式没有很严格的限制，  push & pop 和 present & dismiss 两种方法都会存在各自的道理，包括用「返回」其实也是说得通的，所以不需要纠结这个。 Present & Dismiss 一般是从下往上滑入一个新页面，为present；再从上往下滑出从而释放，为dismiss。不过在安卓中，有时候并不会出现上下滑入滑出的动效，而是直接跳转的方式解决(具体场景可以观察一下 ios 端的知乎 - 直播与 android 端的知乎 - 直播)。所以，观察交互动效是判断交互方式的充分条件，但非必要条件。需要明确区分交互方式的话，还是得仔细分析产品的逻辑。

使用 present & dismiss 的场景可以概括为： 不依附于原页面的功能，或者独立模块，与原页面信息 不耦合 。即在主流程执行过程中嵌入了一个流程 B ，流程 B 与主流程无强相关性，且流程 B 执行完毕后期望 再次回到主流程 中的情况。例如微信、支付宝、钉钉小程序，豆瓣、微博发布动态，微信聊天窗口中发红包、发照片，动态发布、登录注册等操作。 这种跳转方式常常会采用的回退用语为「关闭 / X」、「取消」，如何使用需要结合具体场景具体分析。

  ?One more thing…  

复杂场景下(比如在一个连续流程中嵌入了额外的独立流程，完成独立流程后回到原流程的场景)需要根据流程的性质来合理选择回退用语，以及什么时候用什么回退用语。主流程和插入流程千万不可采用一种跳转方式造成混淆，必须合理运用不同的跳转和适时的回退用语来引导用户，让用户获得可预见的能力，即用户应该知道现在点击返回或者关闭他可以回到哪里。 规则是死的，但是设计是活的。现在很多产品已经摒弃原生的交互效果，在遵循基本规则的前提下进行自主的交互动效开发(可以观察一下知乎在页面跳转时 navigationbar 会发生什么)。这样的创新不会打破认知规律，能在无感知、潜移默化的过程中给产品带来一些体验上的提升，甚至能带来显著的数据转化。 另外，近几年很多产品中已经出现了更大胆、有新意的跳转交互，不管是在纵向还是横向上都对页面的路径进行了拓展，比如说“2楼”、app中的“负一屏”的概念等等，这让产品挣脱了系统设计规范所束缚的枷锁，让自家产品更加灵活。如下为微信读书、知乎、QQ和虾米音乐中非常规的一些交互跳转，这里不具体分析了，可以自己体验一下。

   ‍‍‍

   

  ?思考   不论是遵循系统设计规范来选择跳转交互方式，还是在规范的基础上做一些体验上的创新，产品内设计的一致性始终是需要放在第一位的。一致性能让用户快速学习上手我们的产品，让用户觉得我们的产品是健康、稳定且可靠的。 然而，当前许多产品在页面跳转和回退逻辑上依然没有做到很好，容易引起用户的迷惑，导致易用性不佳。甚至是我们常用的微信，其实也并没有做到这一点(例如聊天对话框中，转账和其他独立功能的回退方式不一致)。 一致的控制方式构成功能的一致性，增加了产品的可预测性，没有达到这一点，用户在使用中便会遇到阻塞，增大用户与产品交互的摩擦，影响体验。