UX 问题:最好有“严重删除"或有“垃圾" [英] UX question: is better to have "serious delete" or have "trash"

问题描述

我正在开发一个应用程序，允许用户管理一些单独的数据点.我的用户想要做的一件事是删除"，但这意味着什么?

I am developing an application that allows for a user to manage some individual data points. One of the things that my users will want to do is "delete" but what should that mean?

对于 Web 应用程序，向用户提供严重删除或使用垃圾"系统的选项是否更好?

For a web application is it better to present a user with the option to have serious delete or to use a "trash" system?

在严重删除"下(很想知道是否有更好的名称...)，您单击删除"，然后用户会收到警告这是最终的悲剧性操作.一旦您这样做，您就会无法得到 - 在这里插入数据点名称 - 回来，即使你在哭......"然后，如果他们点击删除......它真的永远消失了.

Under "serious delete" (would love to know if there is a better name for this...) you click "delete" and then the user is warned "this is final and tragic action. Once you do this you will not be able to get -insert data point name here- back, even if you are crying..." Then if they click delete... well it truly is gone forever.

在垃圾"模型下，您永远不会相信用户真的想删除...相反，您从主显示"中删除数据点并将其放入名为垃圾"的存储桶中.这让用户不知道这是他们通常想要的，但如果他们犯了错误，他们可以把它找回来.显然，这是大多数操作系统所采用的方式.

Under the "trash" model, you never trust that the user really wants to delete... instead you remove the data point from the "main display" and put into a bucket called "the trash". This gets it out of the users way, which is what they usually want, but they can get it back if they make a mistake. Obviously this is the way most operating systems have gone.

严重删除"的优点是:

• 易于实施
• 易于向用户解释

严重删除"的缺点是:

• 它可能是悲惨的结局
• 有时，猫会在键盘上行走

垃圾"系统的优点是:

• 用户是安全的
• 像一次删除一堆"这样的批量方法更有意义
• 解决支持难题

垃圾"系统的缺点是:

• 对于敏感数据，您会产生一种破坏的错觉，用户认为某些东西已经消失，但事实并非如此.
• 许多细微的区别使实施变得更加困难
• 您最终"会删除垃圾箱中的内容吗?

我的问题是，哪一种是适合现代 Web 应用程序的设计模式?归档"功能如何发挥作用?这就是 gmail 的工作原理.进行足够的讨论以证明您的答案是正确的...很乐意被指出一些相关的研究.

My question is which one is the right design pattern for modern web applications? How does an "archive" function work into this? That is how gmail works. Give enough discussion to justify your answer... Would love to be pointed towards some relevant research.

-FT

推荐答案

我认为你很好地总结了垃圾模型的优缺点:

I think you pretty well summarized the pros and cons for the trash model:

• 优点:总的来说，对用户来说更好.

• Pro: Overall, better for the user.

缺点:总的来说，对开发者来说更​​容易.

Con: Overall, easier for the developer.

对于像我这样的可用性专家来说，这很简单.就我而言，开发人员应该努力工作，让用户的生活更轻松.坦率地说，在 Web 应用程序具有诸如垃圾桶之类的撤消功能之前，我认为我们不会认为它们可用.网络应用程序赶上 1984 年的时间.

For a usability specialist like myself, it’s a no brainer. As far as I’m concerned developers are supposed to work hard to make life easier for users. Frankly, until web apps have Undo capabilities like trash, I don’t think we can consider them usable. Time that web apps catch up to 1984.

其他一些细节:

• 垃圾模型的另一个优点是在大多数情况下不需要确认消息的能力.大多数情况下，用户是故意删除某些内容，因此在确认消息中添加额外的步骤通常是为他们增加工作.更糟糕的是，他们养成了快速打OK"的习惯，这可以推广到他们真正更好地阅读的其他确认.请参阅 http://alistapart.com/articles/neveruseawarning.

垃圾比喻的美妙之处在于它向用户暗示删除不是是永久性的.就像物理垃圾桶一样，可以检索对象.如果您在页面上明显地展示了垃圾桶(以便用户意识到他们可以打开它)，并且在删除"菜单项旁边包含垃圾桶的图像作为图标，这应该足以表明删除不会销毁，而是将东西移至垃圾箱.

Part of the beauty of the trash metaphor is that it suggests to user that deleting is not permanent. Like a physical trash can, objects can be retrieved. If you feature the trash can obviously enough on your page (so users realize they can open it), and include an image of the trash can as an icon next to the Delete menu item, that should be enough to indicate that deleting doesn’t destroy, but rather moves things to the trash.

如果有性能考虑，销毁垃圾箱中最旧的删除可能是可以接受的.这再次符合垃圾桶的比喻:用户可以预期迟早有人"会清空垃圾桶.我认为用户不会关心垃圾箱是否永远不会清空.如果他们真的需要销毁一些敏感的东西，你可以为它提供一个明确的程序(例如，删除已经在垃圾箱中的东西).

It’s probably acceptable to destroy the oldest deletions in the trash if there are performance considerations. That is once again consistent with the trash can metaphor: users can anticipate that sooner or later "someone" is going to empty the trash. I don’t think users will care if the trash never empties. If they need to truly destroy something sensitive, you can provide an explicit procedure for it (e.g., deleting something that’s already in the trash).

这篇关于UX 问题:最好有“严重删除"或有“垃圾"的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！