删除前确认or删除后可以撤销？.pdfVIP

删除前确认 or 删除后可以撤销？ 看到知乎上这个问题的讨论，就想来说说自己的看法 /question 我必须得说，这要看情况 首先，讨论这个问题的前提条件是，第一种情况中的系统是可以支持用户删除后撤销的功能的。如 果系统本身或者由于其他原因不能让用户撤销删除的话，这里的讨论就没有意义了。 比如，电子邮 箱里，删除在已删除邮件里的邮件这个操作，只要执行那么邮件就彻底从数据里消失，用户是无法 寻回的，你能做的只能是在删除前，让用户确认一遍。 所以这里讨论的删除并不是从数据库中把数据完全移除，而是指是把数据存放在一个 不可用“ ”的空 间里。因此这里讨论的删除在很多开发人员眼中，不过是个 假删除“ ”。 什么时候使用删除前需要确认？ 1.预防误操作 删除这个操作，部分的使用场景下，对用户来讲是一个影响比较大的操作，也就是我们常说的 重度“ 操作 ”。那么，为了防止不是使用者本意的操作高频率的发生，就很自然的增加一个确认步骤。 2.用户需要知晓操作的后果 一些业务规则下，用户并不清楚进行删除操作后，会发生什么事情，即使你提供了撤销删除的功能 。所以有必要给出一个对话窗口，告知其后果并确认其操作。也许他们并不看，但总比你不说强。 3.撤销删除成本高，或者没有对用户开放 淘宝的订单里有一个订单回收站的功能，不知道大家有没有概念。反正今天我是为了回答这个问题 ，才仔细的去看了看才知道，并且入口并不是很明显。另外一些网站系统中，用户删除的数据是有 留存的，但是一般就不会再呈现给用户看了。 什么时候使用删除后可以撤销的方式？ 如果一个删除操作满足以下的条件，我认为可以考虑采用删除后可以撤销的方式。 1.删除这个操作对用户来讲影响不大，是个 弱操作“ ”。 2.删除这个行为需要经常发生。 3.用户有预期可以撤销删除，并且知晓该如何操作。 4.撤销删除的操作的成本。 比如邮箱中的删除邮件操作。在用户已知晓怎么找回邮件的前提下，删除操作是一个 弱操作“ ”，并且 清空一下收件箱对一些强迫症用户来讲，是一件很爽的事情。所以一般删除邮件时是没有确认的。 如下图， Gmail 中是直接删除邮件会话，不给确认的，但是会及时给出撤销入口 在来看， qq 邮箱中也是如此，对于一般的邮件删除，也是直接删除的 但是对于几乎不可逆的彻底删除，则是删除前确认 再比如，苹果的 mac 操作系统中，是没有删除文件的操作，取而代之的是【移到废纸篓】操作，并 且此操作是没有确认对话框的。这里的操作名本身，就给予对废纸篓有些了解的用户较为明确的可 撤销的预期。 实际项目中如何来判断使用哪种方式？ 把你基于当前技术和业务规则条件下的，要告诉用户的事情，用嘴说或者用文字写的方式描述出来 。然后采用删除前确认和删除后可以撤销的不同的方式来比较一下。侧重比较和分析用户 是否对可 撤销有概念。 然后在后续的可用性测试中， 着重访谈用户的情绪变化， 比如，是否有突兀感，不 自由，不安全感等。 但老实说，这里的判断我主要依靠 感觉“ ”，我感觉依据是把你当前的设计方案，转化成为一段对话， 然后尝试从一个用户的角度来看这段对话， 是否把该说清楚的事情讲清楚了，是否让对方觉得你很 贴心，很聪明。 我举例苹果操作系统 mac和微软的 windows 系统中的删除操作 mac 中： 我要把这个文件从我的桌面删除。 哦，这里只有【移到废纸篓】的操作，我想起来了，刚开始用 mac 的时候，我学习到可以把 文件扔到废纸篓，并且可以找回。 好吧，我就进行【移到废纸篓】的操作。 删除操作完成。 windows 中： 我要把这个文件从我的桌面删除。 哦，发现了【删除】操作，我点击了该按钮。 咦？一个对话框出来了告诉我： （确实要把此文件放入回收站吗？ 恩，我以前学习到，【删除】的意思就是把文件放到回收站中，并且可以找回。） 好吧，我确认此操作。 删除操作完成。 显然 m