user-interface - 是否应该隐藏、禁用 UI 中的未经授权的操作或导致错误？

Question

这对我来说是一个长期存在的问题，我从来没有真正解决过，所以我想听听你的意见。如果我知道用户由于权限或对象状态不足而无法执行的操作，这些操作的 UI 元素应该对用户隐藏、可见但禁用，还是可见并在尝试时导致错误？你回答的理由是什么？如果禁用，您会说明原因吗？如果是，如何说明？

这是一个网络界面，所以我已经知道我需要检查传入的帖子/获取权限并在那里处理错误。我主要是在谈论如何处理 UI。

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

例子：

我有一个允许用户创建新事件的新页面。事件可以是主事件或子事件。创建主事件需要“EditMasterEvent”权限，而创建子事件只需要“EditEvent”权限。我有一个下拉菜单，允许您选择现有事件作为父事件（主事件）或无父事件（这是主事件）。如果用户只有“EditEvent”权限，“创建主事件”选项应该显示在下拉列表中还是省略。
删除事件需要您是应用程序管理员或对事件类型具有适当的编辑权限。在后一种情况下，事件也必须超过 5 年。删除事件会导致系统中相关数据的重大级联删除，出于法律原因，这些数据必须在事件发生后至少保留 5 年。由于该操作对于普通用户来说是很少见的，典型的情况是该操作不可用。应该始终显示还是仅在实际可能时显示？

score 47 · Accepted Answer

隐藏 - 这是当前用户永远无法使用的操作的最佳方法。如果他们无法采取任何行动来改变这一点，那么让用户浪费脑力去弄清楚为什么某些东西会被禁用是没有意义的。

已禁用 - 这是有时可用但目前或当前上下文中不可用的操作的最佳方法。禁用的选项应该传达两件事：首先，该操作现在不可用，其次，用户可以做一些事情来使该操作可用（更改某些设置或权限，选择一个项目，输入先决条件数据等。）。如果您可以在工具提示中指出需要执行哪些操作以启用该操作 - 那就更好了。在用户输入数据或更改上下文时启用/禁用操作可提供有关程序所需内容的出色反馈。

失败并出现错误 - 这是最糟糕的选择。对于可能有效的操作，您应该只求助于错误报告：除非通过尝试，否则您无法判断它会失败。

score 19 · Accepted Answer

与几乎所有 UI 问题一样，答案是“视情况而定”。

您需要权衡可发现性和用户满意度等。例如，允许无效操作让您有机会解释为什么某事无效。如果“为什么禁用”的答案不明显，这将特别有用。对于大多数用户都是初学者的应用程序，这很重要。

另一方面，看到一个控件可能会非常令人沮丧，单击它，只会得到“抱歉，你现在不能这样做”消息的奖励。我几年前继承的一个应用程序充斥着这类东西，它使使用 UI 成为一种沮丧的练习。

完全隐藏功能可能不是一个好主意。想象一下，知道某些功能“在一分钟前就存在”，但现在它已经消失了。无论是菜单项、工具栏按钮还是其他完全隐藏的东西，将其隐藏起来可能会让最终用户感到沮丧。

尝试做一些可用性测试，如果只是问下一个你看到的人“嘿，禁用它或向你显示一个信息性对话框是否有意义”。仅仅一个其他的意见通常就足以让你从另一个方向看待问题。

底线：做最能为用户服务的事情。您提到的所有场景在某些情况下都是有效的。与所有 UI 问题一样，问问你自己（或者更好的是，你的用户）什么最能满足他们的需求。

score 13 · Accepted Answer

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

score 5 · Accepted Answer

这取决于。您是否希望用户知道该操作是可能的，而不是对他们而言？在这种情况下，向他们显示按钮，但禁用它。一个例子可能是如果一个用户没有删除权限，但其他用户有，他们应该知道条目可以被删除，因此如果他们需要该操作，他们可以要求某人为他们执行此操作。

另一方面，如果用户甚至不应该知道该操作（例如，对审核日志没有读取权限的用户可能不应该知道这些日志存在），则应该无法看到该按钮，所以完全隐藏它。

score 3 · Accepted Answer

好问题！

几个考虑：

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

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

如果您要显示和禁用或显示和验证元素，我肯定会进行服务器端验证。不要将验证留给 JavaScript；我认为这其中的原因是显而易见的。

score 3 · Accepted Answer

我倾向于以不同的方式处理这两种不同类型的情况。这是一个受特权和对象状态支配的动作吗？

如果此人没有足够的权限来执行某项操作，我会隐藏该选项，他们不知道他们可以执行该操作。

如果该选项不可用，因为对象不处于可以使用该选项的状态，我将禁用它，允许该选项对用户可见，但无法执行任何操作。

从你的例子：

我不会有“创建主事件”作为选项。用户没有足够的权限查看它。
我会让管理员可以看到删除按钮。然后根据您对网站其余部分的处理方式（大量可见文本、工具提示、帮助图标等），我将遵循通知用户为什么此时按钮不可用的约定。并且可能在上面的按钮附近放置一个计时器，说明帖子的年龄或可以删除的时间。

score 1 · Accepted Answer

根据项目，我们将隐藏它们或禁用它们。如果用户可以访问一个大功能，但不能访问其中的一个较小的部分，那么我们将隐藏较小的部分。但是，如果用户可以访问多个大型功能，但不能访问其他功能，我们将让它们可见但禁用，作为一种营销策略，以提醒他们如果他们决定需要这些功能，则可以购买这些功能。

score 1 · Accepted Answer

我还看到一些程序禁用菜单项并将其文本更改为“登录以执行等等...”

我喜欢这个，因为它不会给我留下“为什么这不起作用？” 感觉并立即告诉我该怎么做才能让它发挥作用。并非在所有情况下都适用，但如果您可以实现它，这是一个不错的方法。

score 1 · Accepted Answer

如果用户可以在 UI 中执行某些操作来获得权限，则一般规则是使用禁用。禁用意味着“您可以执行此命令，但不是现在这样。” “方式”包括当前选择，因此如果用户对旧对象具有 EditEvent 权限但对新对象没有权限，请使用启用/禁用。应该清楚地表明哪些对象是可删除的，以便用户理解为什么对某些对象禁用相关命令（例如，如果用户通常知道记录必须保留 5 年，那么简单的 Age 字段可能就足够了，或许可以加强超过 5 年的记录有图形差异）。

如果假设用户对该领域有平均的了解，那么如果无法向用户说明禁用的原因，请使用消息框而不是禁用。顺便说一句，禁用控件的工具提示是个好主意，但它们本身可能还不够。

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

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

score 1 · Accepted Answer

我会说禁用包含原因的悬停。

它可以防止用户想知道到底发生了什么，同时让他们知道某些操作在正确的条件下是可能的。

score 0 · Accepted Answer

我特别讨厌禁用按钮的应用程序。如果您是最终用户 - 您想知道为什么不能使用该按钮。将其显示为灰色并不能告诉您任何信息。您如何到达该州以启用它？工具提示是一种解决方案，但它们并不是最好的，很多用户都会对工具提示感到困惑（除非您与有经验的用户一起工作）。

score 0 · Accepted Answer

我个人的感觉是元素应该始终存在。如果用户没有足够的权限来执行这些操作，则单击时应该会生成错误。

我知道翻译人员并不真正喜欢创建无数种不同的“权限被拒绝”错误消息，因此这通常不会在本地化应用程序中完成，而是倾向于隐藏元素。

实际上，即使在非本地化的应用程序中，很多人也倾向于隐藏选项。

score 0 · Accepted Answer

其他人提供了很好的答案和有效的建议，以避免隐藏元素，而是禁用它们并提供一些提示原因。

所以，我想从不同的角度来看待它——但是如何在用户不需要看到它们的情况下隐藏一些 UI 元素，无论他是否拥有与元素相关的特定操作的权限？

例如，假设某个角色的用户可以访问系统中的卖家记录。

但随后业务分析师说：“看，这种形式的卖家列表有一个下拉列表，我们不应该让某些特定角色看到它”。

开发者问：“所以，我们只是从这个角色中删除“阅读卖家”权限，对吧？但分析师回答：“不！这个角色应该仍然可以在卖家页面上查看卖家。只是这种单一的形式，我们应该隐藏一些角色的列表并显示给其他一些角色。”

因此，开发人员添加了名为“在表单 X 上显示卖家下拉菜单”的权限。

哎呀，现在我们有一个问题。对相同数据的访问由两个单独的权限控制。现在我们必须弄清楚如何将它们结合起来。如果有不止一种表格应该为某些角色隐藏卖家列表怎么办？我们如何将它与“阅读卖家列表”结合起来？对于我们开发人员来说，“读取”权限应该比“查看”具有更高的优先级，所以即使用户可以“查看”列表，他仍然不应该看到它（或者看到空或禁用有帮助提示）如果他没有“读取”权限。我们，系统的开发人员和分析师都知道这一点。但是系统管理员应该怎么知道呢？我们应该教他这个吗？我们如何保证管理员不会混淆所有那些“查看”和“阅读”

如您所见，这一切都变得混乱有一个原因 - 我们在角色权限列表中将数据处理权限与 UI 便利性混合在一起。

我已经看到许多项目变得混乱，因为服务器端的权限与 UI 耦合太多，这会带来麻烦和可能的安全漏洞（因为您的角色权限编辑器中有多个项目，用于对相同数据的相同操作） .

权限是关于对某些特定数据的访问和操作。UI 只能在整个系统中以一致的方式对权限做出反应（通过提示禁用、隐藏等）。我们不应该仅仅为了 UI 目的而发明新的权限条目。

现在问题仍然存在 - 但我们如何真正为某些系统用户隐藏 UI 元素，以避免大量始终禁用的项目使他们不堪重负？一种解决方案可能是角色工作区。如果我们清楚地知道某个角色的用户永远不需要访问某些特定数据，我们就会创建一组 UI 控制条目，类似于权限，但这次我们不称它们为权限。我们可以在这里变得非常花哨，甚至允许用户自己自由定制他们的工作空间并选择他们可以看到或看不到的内容。当然，权限始终占据最高优先级，但它只会影响 UI 元素的数据和状态，而不会影响可见性。

那是我的两分钱。不幸的是，我自己没有在这样一个系统上工作过，权限和 UI 工作区选项被巧妙地分开，因为当“损坏已经完成”时，我总是以某种方式来得太晚。但我希望有一天我会有机会。我只是希望找到一个很好的例子来正确地做到这一点，但不知何故，互联网搜索并没有给我任何有用的东西。这真的意味着没有其他人得出与我相同的结论吗？我不相信，企业设计模式世界中的某个人应该早就注意到这种 UI<-> 权限阻抗不匹配。

user-interface - 是否应该隐藏、禁用 UI 中的未经授权的操作或导致错误？

13 回答 13

Related

Reference