logo标签列表

在用户界面中，未经授权的操作应该隐藏、禁用还是导致错误？

user-interfaceauthorization
60

这是一个我一直没有解决的长期问题，所以我想听听你的意见。如果我知道某些操作由于权限不足或对象状态不可行，那么这些操作的UI元素应该被隐藏、显示但禁用，还是显示并在尝试时出现错误？您回答的理由是什么？如果禁用，是否会传达原因，如果是，如何传达？

这是一个Web界面，所以我已经知道需要检查传入的post/get权限并在那里处理错误。我主要是讨论如何处理UI。

这类似于禁用或隐藏菜单项规则，不过我对所有类型的UI元素都感兴趣，而不仅仅是菜单。

举例：

  1. 我有一个新页面，允许用户创建新活动。活动可以是主活动或子活动。创建主活动需要“EditMasterEvent”权限，而创建子活动只需要“EditEvent”权限。我有一个下拉列表，允许选择现有事件作为父级（主事件）或无父级（这是主事件）。如果用户只有“EditEvent”权限，是否应显示“创建主事件”选项。

  2. 删除活动需要成为应用程序管理员或具有适当的编辑权限。在后一种情况下，事件还必须超过5年。删除事件会导致系统中相关数据的重大级联删除，基于法律原因，这些数据必须至少保留5年。由于这个操作对于普通用户来说很少见，典型情况是该操作不可用。它应该总是显示还是仅在实际可能时才显示？

13个回答
51

隐藏 - 这是针对当前用户永远不可用的操作的最佳处理方式。如果没有任何一项行动可以改变这种情况，那么让用户浪费精力去想为什么某个东西被禁用是毫无意义的。

禁用 - 这是对有时可用但目前或在当前上下文中不可用的操作的最佳处理方式。禁用选项应传达两个信息：首先，此时此刻该操作不可用；其次，用户可以采取某些措施使该操作可用（更改某些设置或权限、选择某个项目、输入先决条件数据等）。如果您可以在工具提示中指示需要执行什么操作才能启用该操作，效果会更好。随着用户输入数据或更改上下文，启用/禁用操作提供了有关程序所需内容的出色反馈。

错误失败 - 这是最糟糕的选择。只有在可能成功的操作中才应使用错误报告：你只能通过尝试来确定它是否会失败。

19

就像几乎所有与用户界面相关的问题一样，“答案取决于情况。”

您需要权衡发现性和用户满意度等因素。例如，允许无效操作为您提供了一个机会来解释为什么某些操作是无效的。如果“为什么禁用它”不是显而易见的答案，这将特别有用。对于大多数用户都是初学者的应用程序而言，这很重要。

另一方面，看到一个控件却被告知“对不起，您现在不能这样做”，可能会非常令人沮丧。我继承的一个应用程序在几年前就充斥着这种东西，这使使用该用户界面成为一次挫败感的练习。

完全隐藏功能可能很少是一个好主意。想象一下，您知道某个功能“刚刚还在那里”，但现在它已经消失了。不管它是菜单项、工具栏按钮还是其他任何东西，使它隐藏起来可能会让最终用户感到沮丧。

尝试进行一些可用性测试，即使只是问下一个人“嘿，禁用这个或者显示提示信息是否有意义”。仅一个其他人的意见通常足以让您从另一个角度看待问题。

底线：做最符合用户需求的事情。所有你提到的情况在特定情况下都是有效的。与所有用户界面相关的问题一样，询问自己（或更好的是您的用户）什么最符合他们的需求。

1
好的回答。我有一点不同意隐藏操作。当然，在您提到的上下文中（隐藏通常可见的操作），隐藏它们是令人沮丧的选择，但是永远不可用的东西（参见Stephen C.的回答）应该从未可见。此外，如果某些用户组（您的应用程序在内部没有区分）永远不会使用任何操作，则应完全隐藏这些操作的选项。 - masterxilo
13

我禁用元素而不是隐藏它们。这样用户就知道该选项通常是可用的，我提供了一个工具提示来解释为什么该元素当前不可用。

1
当用户永远无法调用操作时，您是否会这样做？也就是说，该操作需要“DeletePermission”，而用户没有该权限，因此他们永远无法执行它？ - tvanfosson
好主意- 在那种情况下，我通常会将其隐藏。有时候不宣传用户不需要知道的功能是一个好主意。 :) - Jon Tackabury
不要忘记工具提示！没有比看到你想要的选项就在那里却灰色显示且没有解释更令人烦恼的了。 - sep332
我认为这个答案太笼统了，不能适用于所有情况。它在很大程度上取决于控件的目的、用户的知识水平（或者不知道）、以及一系列因素。 - Bryan Oakley
5
这要看情况。您是否希望用户知道该操作是可能的，只是对他们不可用？在这种情况下，显示按钮但将其禁用。例如，如果用户没有删除权限，但其他用户有，则他们应该知道可以删除条目，因此如果需要该操作，他们可以请求其他人来完成。
另一方面，如果用户甚至不应该知道该操作（例如，没有读取审计日志访问权限的用户可能不应该知道这些日志存在），则不应该让他们看到按钮，因此完全隐藏它。
当你愿意让用户知道它可以被完成，但是不由他们完成时，我喜欢保留这个想法的可用性。 - tvanfosson
3

好问题！

有几点需要考虑：

如果您将元素放在页面上但禁用它们，仍有可能用户使用javascriptlet篡改系统并启用它们。

如果您根本不显示它们，则整体功能对普通用户可能会有点困惑。 “这里应该有一个编辑按钮吗？”

如果您要显示并禁用或显示并验证元素，我绝对会进行服务器端验证。 不要把验证留在JavaScript的手中；我认为这些理由是显而易见的。

没错。我总是进行数据和权限的服务器端验证。 - tvanfosson
1
即使您完全隐藏控件，仍有可能高级用户使该功能对他们可用，如果没有进行服务器验证... - Simon Bengtsson
3
我倾向于针对两种不同的情况采取不同的处理方式。这是一项由特权和对象状态控制的操作。
如果用户没有足够的权限执行某个操作，我会隐藏该选项，使其无法知道可以执行该操作。
如果该选项不可用是因为对象不处于可以使用该选项的状态，我会将其禁用，允许用户看到该选项，但不能执行任何操作。
根据您的示例：
1. 我不会将“创建主事件”作为一个选项。用户权限不足以查看它。
2. 我会让管理员看到删除按钮。然后根据网站的其他部分（大量可见文本，工具提示，帮助图标等）的做法，我会遵循通知用户为什么此时该按钮无法使用的惯例。可能在按钮上方、上面或附近放置一个计时器，显示文章的年龄或直到何时才能删除。
1

根据物品的不同，我们将隐藏或禁用它们。如果用户可以访问一个大功能，但无法访问其中的一个小部分，则我们将隐藏该小部分。然而，如果用户可以访问几个大功能，但无法访问其他功能，则我们会将它们保留为可见但禁用状态，作为一种营销策略，提醒他们这些功能可以购买，如果他们决定需要它们。

1

我也看过一些禁用菜单项并将其文本更改为“登录以执行某事...”的程序。

我喜欢这种做法，因为它不会让我产生“为什么不能工作？”的感觉，并且立即告诉我该怎么做才能使其工作。虽然不是每个情况都适用，但如果您能实现它，这是一种不错的方法。

1

通常的规则是如果用户可以在 UI 中执行某些操作以获取权限，则使用禁用。禁用意味着“您可以执行此命令，但由于当前环境的原因，现在不能执行。”“当前环境”包括当前选择，因此如果用户对旧对象具有 EditEvent 权限但对新对象没有，则使用启用/禁用。应清楚地指示哪些对象是可删除的，以便用户了解为什么某些对象的相关命令被禁用（例如，如果用户普遍知道记录必须保存 5 年，则一个简单的年龄字段可能足够，也许可以通过使用与超过 5 年的记录不同的图形来强化说明）。

如果用户对特定领域的平均知识水平无法理解禁用的原因，则使用消息框而不是禁用。禁用控件的工具提示是一个好主意，但本身可能不足以解释禁用的原因。

如果用户在组织中没有特权（例如，他们不是应用程序管理员），无论他们在UI中做什么，都不会有特权，则使用隐藏。对于这种情况，使用禁用或消息框会使其变得混乱和令人沮丧。就用户而言，他们没有特权的操作不是他们的工作（否则他们将拥有特权），因此相关控件应简单地不存在于他们的UI中。文档或组织流程手册可以告诉用户如何完成此类操作（例如，“您的主管为您创建新事件。”）。

我在http://www.zuschlogin.com/?p=40上有更多详细信息。

1

我建议使用悬停来禁用，同时显示原因。

这样可以避免用户对发生了什么感到困惑，同时让他们知道在正确的条件下某些操作是可能的。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接