这对我来说是一个长期存在的问题，我从未真正解决过，所以我想要你的意见。如果我知道用户因权限或对象状态不足而无法执行的操作，那么这些操作的UI元素是否应对用户隐藏，可见但已禁用或可见，如果尝试会导致错误？你答案的理由是什么？如果禁用，您会告知原因，如果是，如何？
这是一个网络界面，所以我已经知道我需要检查传入的帖子/获取权限并在那里处理错误。我主要谈论的是如何处理用户界面。
这类似于Rules about disabling or hiding menu items，但我对所有类型的UI元素感兴趣，而不仅仅是菜单。
示例：
我有一个允许用户创建新事件的新页面。事件可以是主事件或子事件。创建主事件需要“EditMasterEvent”特权，而创建子事件只需要“EditEvent”特权。我有一个下拉列表，允许选择现有事件作为父事件（主事件）或没有父事件（这是一个主事件）。如果用户仅具有“EditEvent”权限，那么“创建主事件”选项是否应显示在下拉列表中或省略。
删除事件要求您是应用程序管理员或具有事件类型的相应编辑权限。在后一种情况下，该活动也必须超过5年。删除事件会导致系统中相关数据的主要级联删除，并且出于法律原因，此数据必须在事件发生后保留至少5年。由于此操作对于普通用户来说很少见，因此典型情况是该操作不可用。是应该一直显示还是仅在实际可能时显示？
答案 0 :(得分：42)
隐藏 - 这是当前用户永远无法使用的操作的最佳方法。没有必要让用户浪费精力去弄清楚为什么某些东西被禁用，如果没有他们可以采取的行动来改变这一点。
已禁用 - 这是有时可用的操作的最佳方法，但目前或在当前上下文中不是。禁用选项应该传达两件事：第一，动作现在不可用;第二，用户可以做一些事情来使动作可用（更改一些设置或权限，选择一个项目，输入先决条件数据等。 ）。如果您可以指出需要做什么才能在工具提示中启用操作 - 那就更好了。在用户输入数据或更改上下文时启用/禁用操作可提供有关程序所需内容的出色反馈。
错误失败 - 这是最糟糕的选择。您应该只针对可能有效的操作使用错误报告：除了尝试之外，您无法判断它是否会失败。
答案 1 :(得分：15)
与几乎所有的UI问题一样，答案是“它取决于”。
除了其他方面，您需要权衡可发现性与用户满意度。例如，允许无效操作使您有机会解释为什么某些内容无效。如果“为什么这种禁用”的答案不明显，这将特别有用。对于大多数用户是初学者的应用程序，这很重要。
另一方面，看到一个控件，点击它，只会得到一个“抱歉，你现在不能这样做”的消息可能会非常令人沮丧。几年前我继承的应用程序充斥着这种东西，并且使用UI进行了挫折。
完全隐藏功能可能不是一个好主意。想象一下，知道一些功能“就在那里”，但现在它已经消失了。无论是菜单项还是工具栏按钮还是完全不同的东西，将其隐藏起来都会让最终用户感到沮丧。
尝试进行一些可用性测试，如果只是询问下一个你看到的人“嘿，禁用它或显示信息对话是否有意义”。只有另外一种观点通常足以让你从另一个方向看问题。
底线：尽最大努力为用户服务。您提到的所有方案在某些情况下都是有效的。与所有UI问题一样，问问自己（或更好，您的用户）最适合他们需求的问题。
答案 2 :(得分：11)
我禁用元素而不是隐藏它们。这样用户就知道该选项通常是可用的，我提供了一个工具提示来解释为什么元素当前不可用。
答案 3 :(得分：5)
这取决于。您是否希望用户知道该操作是否可行，而不是为了他们？在这种情况下，向他们显示按钮，但禁用它。一个例子可能是如果用户没有删除权限，但是其他用户没有删除权限，他们应该知道可以删除条目，因此如果需要操作，他们可以要求某人为他们执行此操作。
另一方面，如果用户甚至不知道该操作（例如，对审计日志没有读访问权限的用户可能不应该知道这些日志存在）应该不能看到按钮，所以完全隐藏它。
答案 4 :(得分：3)
很棒的问题！
有几个注意事项：
如果您将元素放在页面上但禁用它们，那么用户仍然可能会使用javascriptlet来管理系统并启用它们。
如果您根本不显示它们，整体功能可能会让普通用户感到有些困惑。 “这里不应该有编辑按钮吗？”
如果要显示和禁用或显示和验证元素，我会肯定进行服务器端验证。不要将验证交给JavaScript;我认为原因很明显。
答案 5 :(得分：3)
我倾向于以不同的方式处理两种不同类型的情况。这是一个由特权和对象状态控制的动作。
如果此人没有足够的权限进行操作，我会隐藏该选项，他们不知道他们可以执行操作。
如果该选项不可用，因为该对象未处于可以使用该选项的状态，我将其禁用，允许该选项对用户可见，但不能执行任何操作。
从您的示例：
我不会选择“创建主事件”。用户没有足够的权限查看它。
我会让管理员看到“删除”按钮。然后，根据你如何做网站的其余部分（很多可见文本，工具提示，帮助图标等），我会遵循该约定，告知用户此时按钮不可用的原因。并且可能在按钮上方，上方，靠近按钮放置一个计时器，其中包括该帖子的年龄或可以删除的时间。
答案 6 :(得分：1)
根据项目的不同，我们会隐藏它们或禁用它们。如果用户可以访问大型功能，但不能访问其中较小的部分，那么我们将隐藏较小的部分。但是，如果用户可以访问多个大型功能，但不能访问其他功能，我们会将其保留为可见但禁用作为营销策略，以提醒他们如果他们决定需要这些功能，则可以购买这些功能。
答案 7 :(得分：1)
我还看到一些禁用菜单项的程序，并将其文本更改为“登录做等等......”
我喜欢这个，因为它不会留给我“为什么这不起作用？”感觉并立即告诉我如何使其发挥作用。不适用于所有情况，但如果您可以实现它，这是一个很好的方法。
答案 8 :(得分：1)
一般规则是，如果用户可以在UI中执行某些操作以获取权限，则使用禁用。 “已禁用”表示“您可以执行此命令，但现在就不是这样。”“事物的方式”包括当前选择，因此如果用户具有旧对象的EditEvent权限而不是新对象，则使用启用/禁用对象。应该清楚地指出哪些对象是可删除的，以便用户理解为什么对某些对象禁用相关命令（例如，如果用户通常知道记录必须保存5年，一个简单的Age字段可能就足够了，也许是强化的对于5岁以上的记录有图形差异。）
使用消息框而不是禁用，如果没有办法让禁用的原因清除给用户，假设他们具有域的平均知识。禁用控件的工具提示，BTW，是个好主意，但可能还不够。
如果用户在组织中当前的位置（例如，他们不是应用程序管理员），无论他们在UI中做什么都没有权限，请使用隐藏。在这种情况下使用禁用或消息框非常混乱和令人沮丧。就用户而言，他们没有权限的操作不是他们的工作（否则他们就拥有权限），因此关联的控件应该根本不存在于他们的UI中。文档或组织程序手册可以告诉用户如何完成此类操作（例如，“您的主管为您创建新事件。”）。
我在http://www.zuschlogin.com/?p=40处有更多详情。
答案 9 :(得分：1)
我想用包含原因的悬停来禁用。
它可以防止用户想知道到底发生了什么，同时让他们知道在适当的条件下可以采取某些行动。
答案 10 :(得分：0)
我对禁用按钮的应用程序有特别的仇恨。如果您是最终用户 - 您想知道为什么不能使用该按钮。让它变灰不会告诉你任何事情。你如何到达州启用它？工具提示是一种解决方案，但它们并不是最好的，很多用户都会为工具提示而烦恼（除非您与经验丰富的用户合作）。
答案 11 :(得分：0)
我个人的感觉是元素应该永远存在。如果用户没有足够的权限来执行这些操作，则在单击时会产生错误。
我知道翻译人员并不喜欢创建大量不同的“权限被拒绝”错误消息，因此通常不会在本地化应用程序中执行此操作，而本地化应用程序往往会隐藏元素。
在实践中，很多人倾向于隐藏选项，即使在非本地化的应用程序中也是如此。
答案 12 :(得分：0)
其他人提供了有效建议的好答案，以避免隐藏元素，而是禁用它们并提供一些提示。
所以，我想从不同的角度来看待它 - 但是如果用户不需要看到它们，如何隐藏一些UI元素，无论他是否拥有与元素相关的特定操作的权限？
例如，让我们说，某些角色的用户可以访问系统中的卖家记录。
但是商业分析师说：＆＃34;看，这个表格中有卖家列表的下拉列表，我们不应该让某些特定的角色看到它＆＃34;。
开发人员问：＆＃34;所以，我们只是删除＆＃34;阅读卖家＆＃34;这个角色的许可，对吗？＆＃34;但分析师回答：＆＃34;不！此角色仍应能够在卖家页面上查看卖家。它只是这个单一形式，我们应该隐藏某些角色的列表并将其显示给其他角色。＆＃34;
因此，开发人员在表单X＆＃34;上添加了名为＆＃34;显示卖家下拉列表的权限。
哎呀，现在我们遇到了问题。对两个单独的权限控制对相同数据的访问。现在我们必须弄清楚如何将两者结合起来。如果有多个表单的某些角色应隐藏卖家列表，该怎么办？我们如何将它与＆＃34;阅读卖家的列表＆＃34;？结合起来？对于我们这些开发人员来说，很明显＆＃34; Read＆＃34;权限应该具有更高的优先级＆＃34;查看＆＃34;，所以即使用户可以＆＃34;查看＆＃34;一个清单，如果他没有＆＃34;阅读＆＃34;他仍然不应该看到它（或者看到空的或有用的暗示禁用）。允许。我们，系统的开发人员和分析师都知道。但系统管理员应该怎么知道呢？我们应该教他这个吗？我们怎样才能保证管理员不会混淆所有这些＆＃34; View＆＃34;和＆＃34;阅读＆＃34;对于单个数据列表？
如您所见，由于一个原因，一切都变得混乱 - 我们将数据处理权限与角色权限列表中的UI便利混合在一起。
我看到很多项目都变得混乱，因为服务器端的权限与UI过多耦合，这会导致问题和可能的安全漏洞（因为你的角色权限编辑器中有多个项目用于相同的操作相同的数据）。
权限是关于某些特定数据的访问和操作。 UI只能在整个系统中以一致的方式对权限做出反应（禁用提示，隐藏等）。我们不应该仅为了UI目的而发明新的权限条目。
现在问题仍然存在 - 但是我们如何实际隐藏某些系统用户的UI元素，以避免大量总是被禁用的项目压倒他们？一种解决方案可能是角色工作区。如果我们清楚地知道某个角色的用户永远不需要访问某些特定数据，我们会创建一组类似于权限的UI控件条目，但这次我们不会将它们称为权限。我们可以在这里获得真正的幻想，甚至允许用户自己定制他们的工作区并选择他们能够或不能看到的内容。当然，权限始终具有最高优先级，但它只会影响UI元素的数据和状态，而不会影响可见性。
那是我的两分钱。不幸的是，我自己还没有在这样一个系统上工作，在这个系统中，权限和UI工作区选项被巧妙地分开，因为我总是以某种方式对项目来说太晚了，而且已经完成了＃34;损坏了＃34;。但我希望有一天我有机会。我只是希望找到一个很好的例子，如何做到这一点，但不知何故互联网搜索不会给我任何有用的东西。这真的意味着没有其他人得出与我相同的结论吗？我不相信，企业设计模式世界中的某些人应该早就注意到这个UI＆lt; - ＆gt;权限阻抗不匹配。