军垦路街道删除前确认or删除后可以撤销？

首先，讨论这个问题的前提条件是，先进种情况中的系统是可以支持用户删除后撤销的功能的。如果系统本身或者由于其他原因不能让用户撤销删除的话，这里的讨论就没有意义了。比如，电子邮箱里，删除在已删除邮件里的邮件这个操作，只要执行那么邮件就有效从数据里消失，用户是无法寻回的，你能做的只能是在删除前，让用户确认一遍。

　　所以这里讨论的删除并不是从数据库中把数据有效移除，而是指是把数据存放在一个“不可用”的空间里。因此这里讨论的删除在很多开发人员眼中，不过是个“假删除”。

　　什么时候使用删除前需要确认?

　　1.预防误操作

　　删除这个操作，部分的使用场景下，对用户来讲是一个影响比较大的操作，也就是我们常说的“重度操作”。那么，为了防止不是使用者本意的操作高频率的发生，就很自然的增加一个确认步骤。

　　2.用户需要知晓操作的后果

　　一些业务规则下，用户并不清楚进行删除操作后，会发生什么事情，即使你提供了撤销删除的功能。所以有必要给出一个对话窗口，告知其后果并确认其操作。也许他们并不看，但总比你不说强。

　　3.撤销删除成本高，或者没有对用户开放

　　淘宝的订单里有一个订单回收站的功能，不知道大家有没有概念。反正今天我是为了回答这个问题，才仔细的去看了看才知道，并且入口并不是很明显。另外一些网站系统中，用户删除的数据是有留存的，但是一般就不会再呈现给用户看了。

　　什么时候使用删除后可以撤销的方式?

　　如果一个删除操作满足以下的条件，我认为可以考虑采用删除后可以撤销的方式。

　　1.删除这个操作对用户来讲影响不大，是个“弱操作”。

　　2.删除这个行为需要经常发生。

　　3.用户有预期可以撤销删除，并且知晓该如何操作。

　　4.撤销删除的操作的成本。

　　比如邮箱中的删除邮件操作。在用户已知晓怎么找回邮件的前提下，删除操作是一个“弱操作”，并且清空一下收件箱对一些强迫症用户来讲，是一件很爽的事情。所以一般删除邮件时是没有确认的。

　　如下图，Gmail中是直接删除邮件会话，不给确认的，但是会及时给出撤销入口

　　在来看，qq邮箱中也是如此，对于一般的邮件删除，也是直接删除的

　　但是对于几乎不可逆的有效删除，则是删除前确认

　　再比如，苹果的mac操作系统中，是没有删除文件的操作，取而代之的是【移到废纸篓】操作，并且此操作是没有确认对话框的。这里的操作名本身，就给予对废纸篓有些了解的用户较为明确的可撤销的预期。

　　实际项目中如何来判断使用哪种方式?

　　把你基于当前技术和业务规则条件下的，要告诉用户的事情，用嘴说或者用文字写的方式描述出来。然后采用删除前确认和删除后可以撤销的不同的方式来比较一下。侧重比较和分析用户是否对可撤销有概念。然后在后续的可用性测试中，着重访谈用户的情绪变化，比如，是否有突兀感，不自由，不安全感等。

　　但老实说，这里的判断我主要依靠“感觉”，我感觉依据是把你当前的设计方案，转化成为一段对话，然后尝试从一个用户的角度来看这段对话，是否把该说清楚的事情讲清楚了，是否让对方觉得你很贴心，很聪明。

　　我举例苹果操作系统mac和微软的windows系统中的删除操作

　　mac中：

　　我要把这个文件从我的桌面删除。

　　哦，这里只有【移到废纸篓】的操作，我想起来了，刚开始用mac的时候，我学习到可以把文件扔到废纸篓，并且可以找回。

　　好吧，我就进行【移到废纸篓】的操作。

　　删除操作完成。

　　windows中：

　　我要把这个文件从我的桌面删除。

　　哦，发现了【删除】操作，我点击了该按钮。

　　咦?一个对话框出来了告诉我：

　　(确实要把此文件放入回收站吗?

　　恩，我以前学习到，【删除】的意思就是把文件放到回收站中，并且可以找回。)

　　好吧，我确认此操作。

　　删除操作完成。

　　显然mac的操作更加流畅，但前提是用户对废纸篓有概念。pc的做法虽然繁琐一点，但是符合用户的初始认知模型。我要删除，就给删除操作，在后续弹窗中解释删除意味着什么，然后要求用户确认操作。mac很聪明，但是你同时也必须“聪明”一点。pc有点繁琐，但是确实照顾了更大范围的用户。

　　所以不同项目中怎么做，真得看情况。

以上内容由（大宛网络）军垦路街道网站假设为您提供，更多内容：http://www.nyweixin.com/