许多，尤其大多数年轻设计师是依据他们的直觉来创造一款产品的。尽管这在大多数情况下行得通，但这有些公认的通用标准可以帮助你从逻辑上建造有根据的的UI解决方案，而不是依赖你的直觉。

在这篇文章当中，我们将会一起探索用户界面中模态的通用标准，讨论为什么只有两种基本的视图类型并分析app和网站是如何在将信息架构和用户流程转化成直观的用户界面中失败的。噢，我们要从一只猫说起。

让我们以一个大胆的断言开始我们的探索：

世界上只有两种类型的视图

1、模态视图 

2、非模态视图

让我来解释一下。几乎，任何你能够想象出来的视图都能归入到这两类视图中。为了理解模态视图和非模态视图中的不同，我们先来定义一下模态视图。

什么是模态视图？

模态视图的例子

模态视图依据不同的形状和尺寸有以下几种：

• 全屏模态视图
• 弹出式窗口
• 气泡弹窗
• 灯箱弹窗
• 警告/通知
• 对话框（多步骤）

• ...

模态视窗和非模态视窗都是子视图，意味着他们从属于app的主视窗。但他们之间有一个重要的区别：

“【模态视窗】创造了一个使主视窗功能失效，但保持其可视，即模态视窗作为子视窗，出现在主视窗前面的模式。用户必须与模态视窗交互，然后才能回到父应用程序。” ——维基百科

大多数模态视窗，尤其是桌面应用，能够被轻易地辨认出来，因为他们在视觉上覆盖了主视窗。对于在背景中淡出主窗口的弹出窗口，弹出菜单和弹出对话框，灯箱，警报等，都是如此。

然而，在移动设备上的屏幕空间是有限的，所以许多模态视窗会占据整个设备的屏幕。他们不再使得底层的主视图可见，因此我们更难从非模态视窗中区别出模态视窗。

iOS示例：在手机上的模态视窗通常会完全覆盖主视图

所以主要区别在于它们与每个屏幕交互的方式。非模态视窗允许用户轻松地返回父视图，而模态视窗要求用户在返回主视图前完成一个操作（本例中的“保存”）或者取消当前行为。

非模态视窗最明显的视觉指示器就是导航信息是否可见（本例中的“标签栏”）。即使身处于在子页面中，非模态视窗也允许用户在主导航上来回跳转。另一方面，模态视窗要求用户在能够再次使用主导航前需要关闭当前窗口（本例中的“保存”或者“关闭”）。大多数app失败就失败在忽略了这个差别。

为什么需要使用模态？

模态视窗解决了一个简单的问题：用户非常容易分心，所以你不得不想尽办法去抓住他们所有的注意力。模态视窗正是这么做的：它要求用户在继续其他操作之前专注于当前任务。

“模态通过直到用户完成当前任务或者忽略一个信息或视图，防止用户做其他事情来产生专注。” ——Apple

什么时候需要使用模态？

现在，我们知道了模态视图长什么样，怎么样将它与非模态视图区别开来和它的目的是什么，那么我们要问问自己“在什么情况下我们要用到模态视图”。

我之前答应你的猫咪，现在就开始吧：让我们想象一下我们正在打造一款创意十足的硅谷app：“purrrfect”——一款猫咪数据库，允许用户上传，浏览和评论可爱的猫咪动图。绝妙的想法。

来源：https://giphy.com/gifs/tDgXAst2PhIYw

我们app的（简化的）用户流程可能是这样的：用户打开这个app，她进入了几个可用的选项卡（我们的猫咪数据库）中的一个，点击其中一个猫咪（进入详细的单只小猫视图），然后点击评论部分（进入评论部分）。

• purrrfect用户流程
• 
  

此外，用户可以在每一个阶段执行补充操作。例如，她可以在猫咪数据库视图中添加其他的猫咪进数据库。或者，她可以在猫咪信息视图中编辑信息。完美。

现在，在这些视窗中哪些是模态视窗，哪些是非模态视窗呢？区分开来绝非易事，下面介绍我个人的经验法则：

       为自包含进程使用模态视窗，为其他的一切使用非模态视窗。

“自包含进程”指的是有着清晰的开始和结束节点的行为。在这个动作的有限时间内，它让用户跳出一般的用户流程，使用户专注于当前行为，之后再将用户带回到她开始的地方。

谷歌的措辞如下：使用模态视窗（对话框）获取...

      “关于特定的用户任务，决策，或者确认的关键信息” ——谷歌

在我们的purfffect应用当中，这意味着主用户流程（通常是探索一个应用）不是模态。然而，像添加猫咪，编辑猫咪和写评论这样的有时间限制的特殊行为，就是模态。

在用户被带回到主流程之前，用户需要取消或者成功地完成所有模态行为。因为这个，模态视窗使用的是取消和保存按钮（或者其他相似的行为），而不是返回按钮。在非模态视窗中，如果你的返回按钮同时触发了保存行为，你也许需要考虑将其转换为带有取消和保存按钮的模态视窗。换句话说，如果在你的模态视窗中，取消和保存按钮并没有意义（因为他们会触发同样的结果），那么你可能需要考虑将其转换成非模态视窗。在这种情况下，主导航（例如，标签栏）在屏幕上应该仍然保持可见的状态。

让我们回到我们颠覆性的app中：purfffect的界面有可能是像下面这样：

purrrfect可能的用户界面

在现实世界中，模态视窗和非模态视窗的区别通常是不那么明显的。例如，在大多数app中，一张图片的全屏视图是模态的，尽管它不是一个进程或者对话框。为了集中注意力，模态视窗在其他特殊的情况里是说得通的。如果猫咪信息页是一个没有像是编辑和评论等其他行为的终点视图，我们可以考虑使用模态（全屏视图）。但如果它允许用户导航至更深的信息架构中以及提供多种额外的操作（显示更多评论，编辑等），即它没有明确的终点视图，因此它是主流程中的一部分，是一个非模态视图。

评判一个行为是否是独立的或仅是app总体探索流程中的一部分，然后决定模态在这是否行得通是一个设计师的责任。如果有疑问的话，记住苹果的话：

“尽可能减少模态的使用。一般来说，用户更喜欢以非线性的方式与app进行交互。考虑只在需要引起某人注意时才使用模态，例如，只有完成或取消某个任务才能继续使用这个app，或者保存重要的数据时。” ——Apple

免责声明：当然，即使不严格区分模态和非模态视图我们也可以创造一个能够完美运行的界面。然而，模态的概念已经深深嵌入苹果，谷歌，微软等企业的界面生态系统中，用户也有了相应的期望。

如果苹果不一次又一次地打破自己的规则，那苹果也不会是苹果：例如，新的App Store 在“今天”板块中以模态视窗的方式突出显示每张卡片中的内容，但仍然允许用户导航至更深的推荐模块（在模态视窗的底部）中，即没有明确的终点。在这个过程中，用户无法去到其他板块，也无法在子页面中关闭模态视窗。让我们打开相同的应用程序页，而不是“今天”板块的卡片底部推荐模块的推荐结果，其显示的是非模态视窗。这个页面保留了标签栏和返回操作（再次点击当前标签栏图标可以回到主视图）。

不一致的苹果界面

上图左边的不一致可以通过下面两种方法进行修正：

• A：卡片以非模态子页面的方式打开，保留标签栏和返回按钮。

• B：当用户点击模态视窗内的链接时就关闭模态视窗，然后继续在应用程序的父级上使用非模态子视图。

模态应该怎么使用？

到现在，我们应该对什么时候使用模态有个大概的了解。现在唯一的问题就是，“我们应该如何设计它”。下面是一个模态视窗的快速检查表：

• 总在顶部导航栏显示关闭按钮（或取消/放弃/最小化/...）。当用户丢失自己的位置时，它可以容易地关闭当前的覆盖层并导航至app的顶层。

• 取消按钮通常被放置在iOS和安卓系统导航栏的左上角。安卓系统倾向于关闭/“X”图标，而iOS更倾向于“取消”文本。然而，图标按钮在iOS系统上也十分常见和被广泛理解。

• iOS和Android系统中的保存按钮都默认被放置在导航栏的右上角。然而，这个位置在较大的设备上难以被点击。因此，在屏幕底部固定浮动位置或是我个人比较推荐的内联于页面尾部都是不错的选择。

多步骤模态

当模态对话框包含了多个步骤或者子视图时，事情就会变得复杂。默认情况下，继续按钮放置在右上角。点击继续不会打开一个新的模态视图，而是作为一个非模态子视图在当前的模态层上显示。

当把主要操作（“保存”，“应用”或者“继续”）放置在屏幕底部（就像之前推荐的那样），模态的第二步的右上角区域为可选的取消按钮腾出了空间。尽管取消按钮从左边跳到了右边，但相较于没有提供关闭当前模态视图的子视图功能的app，这个布局还是好太多了。

动效

至此，iOS和Android系统在使用模态视图的方法上还是十分相似的。然而，在动效的表现上，这两个系统是有差别的。

• iOS：在iOS上的动效是高度标准化的。非模态视图自右进入框架内。标签栏和在屏幕底部保持不动。导航栏在顶部保持不动，但其内容在自定义的转换中会淡入。这个动效也为用于返回的边缘滑动手势奠定了基础，该手势适用于无法触及返回按钮的情况。 模态视图自下向上覆盖整个界面（新的顶部导航栏）。他们不使用边缘滑动手势，如果没有什么需要保存的话，自定义下拉关闭手势可能有用。
  
  

• 安卓：安卓上的动效更加多样化。谷歌在Material设计指南上推荐使用“有意义的过渡”。当顶部导航栏淡入其内容时，“子元素在点击时升起并在适当的位置展开”。然而安卓并没有明确区分模态和非模态视图之间的动画。

结论

许多设计师根据自己的直觉来设计产品。有时候，直觉比规范更重要。但重要的是要去了解公认的标准，以便在其有意义的时候适应或者忽略它。

在我看来，模态的概念是当今应用最容易被忽略的用户体验原则之一。跨平台的应用程序和基于Web的混合功能让使用平台指南和规范变得更加困难。但是模态的一般概念是一个参考，为了在必要的时候打破它，你需要去熟悉它。

Powered by Froala Editor