ftr*_*ter 13 user-interface user-experience
我正在开发一个允许用户管理一些单独数据点的应用程序.我的用户想要做的事情之一是"删除",但这意味着什么？
对于Web应用程序,最好是为用户提供严重删除选项或使用"垃圾"系统吗？
在"严重删除"下(很想知道这个名字是否更好......)你点击"删除",然后警告用户"这是最后和悲惨的行动.一旦你这样做,你将无法做到在这里获取-insert数据点名称,即使你在哭......"然后如果他们点击删除......那么它真的永远消失了.
在"垃圾"模式下,您永远不会相信用户真的想要删除...而是从"主显示"中删除数据点并放入称为"垃圾箱"的存储桶中.这使得它不受用户的影响,这是他们通常想要的,但如果他们犯了错误,他们可以将其取回.显然,这是大多数操作系统的方式.
"严重删除"的优点是:
"严重删除"的缺点是:
"垃圾"系统的优点是:
"垃圾"系统的缺点是":
我的问题是哪一个是现代Web应用程序的正确设计模式？"归档"功能如何适用于此？这就是gmail的工作原理.给出足够的讨论来证明你的答案是合理的......希望能指出一些相关的研究.
-FT
在我个人的特殊观点中,每一个不可逆转的行为都是一个严重的设计错误.这些"你真的,绝对,非常肯定吗？"消息框是纯粹的垃圾,因为用户很快就能够点击"确定"并完成它.事实上,尽管有过几次这样的对话,但我已经丢失了重要的数据.
换句话说:这些对话框不会添加有效的故障安全屏障,只是一个可用性障碍.
甚至垃圾系统都有这个问题(他们只是推迟了这一刻); 从可用性的角度来看,最好的解决方案是无限的历史.当然,实现这一点可能带来禁止成本(例如,在内存使用方面).
永久删除敏感数据可以(并且应该!)通过一切手段来实现:它很少需要.唯一的问题是向用户说明数据通常不会丢失.使用历史而不是垃圾可以在这里提供帮助:垃圾桶可能被误解为永久性删除,而(可见)行动历史不会给出这种安全错觉.
我认为您很好地总结了垃圾模型的优缺点：
优点：总的来说，对用户来说更好。
缺点：总的来说，对开发人员来说更容易。
对于像我这样的可用性专家来说，这很简单。就我而言，开发人员应该努力工作，让用户的生活更轻松。坦率地说，在 Web 应用程序具有诸如垃圾桶之类的撤消功能之前，我认为我们不会认为它们可用。Web 应用程序赶上 1984 年的时间。
其他一些细节：
垃圾模型的另一个优点是在大多数情况下无需确认消息的能力。大多数情况下，用户是故意删除某些内容，因此在确认消息中添加额外的步骤通常是为他们增加工作。更糟糕的是，他们养成了快速打“OK”的习惯，这可以推广到他们真正更好地阅读的其他确认。请参阅http://alistapart.com/articles/neveruseawarning。
垃圾比喻的部分美妙之处在于它向用户暗示删除不是永久性的。就像物理垃圾桶一样，可以检索对象。如果您在页面上明显地展示了垃圾桶（以便用户意识到他们可以打开它），并且在“删除”菜单项旁边包含垃圾桶的图像作为图标，这应该足以表明删除不会销毁，而是将东西移至垃圾箱。
如果有性能考虑，销毁垃圾箱中最旧的删除可能是可以接受的。这再次符合垃圾桶的比喻：用户可以预期迟早“有人”会清空垃圾桶。我认为用户不会关心垃圾箱是否永远不会清空。如果他们需要真正销毁敏感内容，您可以为其提供明确的程序（例如，删除已经在垃圾箱中的内容）。