弹窗发展简史（二）：Confirm弹窗

2. Confirm弹窗

上一篇讲的是软件交互的三大弹窗类型之Alert弹窗，今天要讲的是三大弹窗类型的第二种：Confirm弹窗。又叫确认弹窗、确定弹窗。这种弹窗也是模态打断用户当前操作，需要用户在Yes和No之间做出一个选择，然后再根据返回的布尔值来进行后续的交互。

Confirm弹窗的使用场景是需要用户在“Yes”和“No”之间做一个抉择，以决定后续支路流程的进行，同时如果需要，用户选择后产生的布尔值结果可以保存至云端，所以Confirm弹窗的后续流程是一个多支路可选的、可云端存储的流程，特别适用于二次确认重要操作行为、协议签署、允许系统调用传感器、退出时提醒保存等场景。

普通的Confirm弹窗

我们举一个简单的例子，假如系统需要确定用户是否吃过早饭，并会根据用户的回答给出不同的系统反馈，同时把用户的选择结果记录到云端，交互流程如下：

Confirm弹窗的交互流程

你可以在浏览器地址栏输入如下代码来体验一下这个过程：

javascript:if(confirm("早饭吃了吗?")){alert("恭喜你！")}else{alert("好遗憾！");}

在移动操作系统iOS和安卓中，也引入了这个基本的弹窗控件，并保留了其基本形式，并在提示文字的基础上，新增了一个标题的文字区域。

移动端Confirm弹框有标题和正文文字区域

同时iOS和安卓等移动操作系统在普通Confrim弹窗控件的基础上，还新增了多选弹框，这就极大程度上拓展了Confrim的使用场景和应用范围，毕竟有很多时候，我们需要做出的选择不是“Yes”和“No”，而是“选择一”、“选择二”......“选择N”。

多选Confirm弹窗

当然在使用这种多选的弹窗控件时，返回值也不再是一个布尔值，而是一个UInt（unsigned integers）数值。系统会根据返回的Int数值决定后续流程的展现和记录到云端的工作。

和Alert弹窗一样，产品设计者和开发者也发现了原生的Confirm控件有时候无法满足用户和应用更美观、更易用等要求，于是自定义Confirm弹窗控件也就应运而生了。

自定义控件

自定义控件的好处是产品设计人员开发者可以随意定制Confrim弹窗上的任何元素，包括标题、正文样式、“确定/取消”按钮的文字、新增其他字段，甚至还可以增加图片和改变弹窗的外观。这样就可以根据设计者的不同要求定制不同的Confrim弹窗，让Confrim弹窗的使用范围更加扩大化。

自定义的布尔值Confrim弹窗

多选的Confrim弹窗

但不管Confirm弹窗的形式怎么变化，我们还是很容易就能凭借它的特点把它从众多的交互控件中辨认出来，那就是Confrim弹窗会模态地阻断用户当前其他交互并强制用户在几个选项中做出选择，系统能够根据用户的选择给出的选择提供不同的后续流程。Confirm弹窗和Alert弹窗一样，已经成为了GUI界面上最最基础的交互控件。