用户界面中的未授权操作是否应该隐藏，禁用或导致错误？
对于我来说，这是一个长期的问题，我从来没有真正解决过，所以我想要你的意见。 如果我有一些行为，我知道用户由于权限不足或对象状态而无法执行，那么这些操作的UI元素是否对用户隐藏，可见，禁用或可见，如果尝试，则会导致错误？ 你的答案的理由是什么？ 如果残疾，你会沟通的原因，如果是这样，如何？
这是一个Web界面，所以我已经知道，我需要检查传入的post/获取权限，并处理错误无论如何。 我主要是在谈论如何处理用户界面。
这与关于禁用或隐藏菜单项的规则类似，尽pipe我对所有types的UI元素（而不仅仅是菜单）感兴趣。
例子：
-
我有一个新的页面，允许用户创build一个新的事件。 事件可以是主事件或子事件。 创build主事件需要“EditMasterEvent”特权，而创build子事件只需要“EditEvent”特权。 我有一个下拉，允许select一个现有的事件作为父（主事件）或没有父（这是一个主事件）。 如果“创build主事件”选项显示在下拉列表中，或者如果用户只具有“编辑事件”权限，则省略。
-
删除事件要求您是应用程序pipe理员，或者具有相应的事件types的编辑权限。 在后一种情况下，该事件也必须超过5年。 删除事件会导致系统中相关数据的大量级联删除，并且出于法律方面的原因，此事件必须在事件发生后保留至less5年。 由于这种操作对于普通用户来说很less见，因此典型的情况是操作不可用。 是否应该总是或仅在实际可能时才显示？
和几乎所有的用户界面问题一样，答案是“视情况而定”。
除了其他方面，您还需要权衡可发现性和用户满意度。 例如，允许一个无效的动作给你一个机会来解释为什么有些东西是无效的。 如果“为什么这个禁用”的答案不明显，这是特别有用的。 对于大多数用户是初学者的应用程序，这一点很重要。
另一方面，如果看到一个控件，点击它，只会得到一个“抱歉，你现在不能这样做”的消息，这可能是非常令人沮丧的。 我几年前inheritance的一个应用程序，充满了这种东西，它使用户界面在挫折中的锻炼。
完全隐藏function可能不是一个好主意。 想象一下，知道一些function“在一分钟之前”，但现在已经消失了。 无论是菜单项还是工具栏button或其他东西，隐藏起来都可能是最终用户的挫败感。
尝试做一个小的可用性testing，如果只要问下一个人你看到“嘿，这是有道理的禁用这个或显示你一个信息对话”。 另外一个意见往往足以让你从另一个方向看问题。
底线：做最好的服务用户。 你提到的所有场景在某些情况下都是有效的。 与所有用户界面问题一样，问问自己（或者更好的是，用户）什么才能最好地满足他们的需求。
隐藏 – 这是对当前用户从不可用的操作的最佳方法。 如果用户没有采取任何行动来改变这种情况，那么用户就不必花费精力去弄清楚为什么有些东西是被禁用的。
禁用 – 对于有时可用的操作，这是最好的方法，但不是在当前或当前的情况下。 一个被禁用的选项应该expression两件事情：第一，这个动作现在是不可用的，第二，用户可以做一些事情使得动作可用（改变一些设置或许可，select一个项目，input先决条件数据等等）。 ）。 如果您可以指出需要做什么才能在工具提示中启用该操作 – 一切都会更好。 在用户input数据或更改上下文时启用/禁用操作可提供有关程序所需的极好反馈。
失败，错误 – 这是最糟糕的select。 你应该只求助于可能有效的操作的错误报告：除了尝试之外，你不能说它会失败。
我禁用的元素，而不是隐藏它们。 这样用户就知道这个选项通常是可用的，我提供了一个工具提示来解释为什么该元素当前不可用。
这取决于。 你想让用户意识到这个动作是可能的，而不是为了他们？ 在这种情况下，向他们显示button，但禁用它。 例如，如果一个用户没有删除权限，但是其他用户可以删除，那么他们应该知道可以删除这个项目，所以如果他们需要这个操作，他们可以要求某人为他们这样做。
另一方面，如果用户不应该知道该操作（例如，没有对审计日志具有读访问权限的用户可能不应该知道这些日志存在），则不应该能够看到该button，所以完全隐藏它。
好问题！
几个考虑因素：
如果您将元素放置在页面上但将其禁用，那么用户仍然有可能使用javascriptlet来处理系统并启用它们。
如果你根本不显示它们，整体function可能会让一般用户感到困惑。 “这里不应该有编辑button吗？”
如果你要显示和禁用或显示和validation元素，我肯定会做服务器端validation。 不要把validation留在JavaScript的手中; 我认为这个原因很明显。
我倾向于处理两种不同types的情况。 这是一个受特权和对象状态支配的行为吗？
如果这个人没有足够的特权去做一个动作，我隐藏了这个选项，他们不知道他们可以执行这个动作。
如果该选项不可用，因为该对象不处于可以使用该选项的状态，我将其禁用，允许该选项对用户可见，但不能执行任何操作。
从你的例子：
-
我不会有“创build主事件”作为一个选项。 用户没有足够的权限来查看它。
-
我会让pipe理员看到“删除”button。 然后根据你如何做网站的其他部分（很多可见的文本，工具提示，帮助图标等），我会遵循该约定关于通知用户为什么此时button不可用。 并且可能在button附近的上方附近放置一个定时器，该定时器可以是多长时间，或者多长时间才能被删除。
根据项目，我们将隐藏它们或禁用它们。 如果用户可以访问大型function，但不能访问其中的较小部分，那么我们将隐藏较小的一部分。 但是，如果用户可以访问多个大型function，但不能访问其他function，那么我们会将其保留为可见状态，但将其作为营销策略予以禁用，以提醒用户如果他们决定需要这些function，则可以购买这些function。
我也看到一些程序，禁用菜单项，并将其文本更改为“login做坏事…”
我喜欢这个，因为它没有给我留下“为什么这不工作？” 感觉，并立即告诉我该怎么做，以使其工作。 在任何情况下都不适用，但如果您可以实施它，这是一个不错的方法。
一般的规则是使用禁用，如果用户可以在UI中做些什么来获得特权。 被禁用的意思是“你可以做这个命令，但是现在不行。”“事情的方式”包括当前的select，所以如果用户具有旧的对象的EditEvent特权而不是新的对象。 应该清楚地指出哪些对象是可删除的，这样用户就能理解为什么关联的命令对某些对象是禁用的（例如，如果用户通常知道logging必须保存5年，那么简单的Age字段可能就足够了，对于5岁以上的logging具有graphics差异）。
使用消息框而不是禁用，如果没有办法让用户明白禁用的原因，假定他们对域有一般的认识。 禁用控件的工具提示，顺便说一句，是一个好主意，但可能不够。
如果用户永远没有权限，那么无论用户在UI中做了什么，都要使用隐藏（例如，他们不是应用程序pipe理员）。 这种情况下使用禁用或消息框是混乱和令人沮丧的。 就用户而言，他们没有特权的行为不是他们的工作（否则他们有特权），所以相关的控制应该不存在于他们的UI中。 文件或组织程序手册可以告诉用户这些行动是如何完成的（例如，“你的主pipe为你创build新的事件”）。
我会说停用含有原因的hover。
它可以防止用户想知道到底发生了什么，同时让他们知道在正确的条件下某些行为是可能的。
我有一个特殊的仇恨应用程序，禁用button。 如果你是最终用户 – 你想知道为什么你不能使用该button。 把它变成灰色并不能告诉你什么。 你如何到达国家来启用它？ 工具提示是一个解决scheme，但它不是最好的，很多用户会与工具提示（除非你正在与有经验的用户工作）斗争。
我个人的感觉是元素应该总是存在的。 如果用户没有足够的权限来执行这些操作，那么点击时应该会产生一个错误。
我知道翻译人员并不喜欢创build一个不同的“许可被拒绝”错误消息，所以这通常不会在本地化的应用程序中完成，而这往往会隐藏元素。
在实践中，很多人倾向于隐藏选项，而不是在非本地化的应用程序中。
其他人提供了很好的答案和有效的build议，以避免隐藏元素，而是禁用它们，并提供一些提示的原因。
所以，我想从不同的angular度来看待它 – 但是，在用户不需要看到它们的情况下，如何隐藏一些UI元素，无论他是否具有与元素相关的特定动作的权限？
例如，假设某个angular色的用户可以访问系统中的卖方logging。
但是业务分析师说：“看，这个表格中有卖家名单的下拉列表，我们不应该允许某些特定的angular色看到它。”
开发人员问：“所以，我们只是从这个angular色删除”读卖家“的权限，对不对？ 但分析师回答：“不！这个angular色应该仍然能够在卖家页面上查看卖家，这只是一个单一的forms，我们应该隐藏一些angular色的列表，并显示给其他angular色。
因此，开发者添加了名为“在X表单上显示卖家下拉”的权限。
哎呀，现在我们有一个问题。 访问相同的数据由两个单独的权限控制。 现在我们必须弄清楚如何将两者结合起来。 那么如果有多个表单需要隐藏某个angular色的卖家名单呢？ 我们如何将它与“阅读卖家名单”结合起来？ 对于我们这些开发人员来说，“阅读”权限应该比“查看”更高，因此，即使用户可以“查看”列表，他仍然不应该看到它（或者看到空的或禁用的提示）如果他没有“读取”权限。 我们，系统的开发人员和分析人员都知道这一点。 但系统pipe理员应该怎么知道呢？ 我们应该教他这个吗？ 我们如何保证pipe理员不会混淆单个数据列表的所有“查看”和“读取”？
正如你所看到的，由于一个原因，这一切都变得混乱 – 我们正在angular色权限列表中混合数据处理权限和UI方便性。
我见过很多项目，因为服务器端的权限与UI耦合太多了，因为这会造成麻烦和可能的安全漏洞（因为angular色权限编辑器中有多个项目用于相同数据上的相同操作） 。
权限是关于某些特定数据的访问和操作。 UI只能在整个系统中以一致的方式对权限作出反应（禁用提示，隐藏等）。 我们不应该为了UI目的而发明新的权限条目。
现在问题仍然存在 – 但是我们如何实际上隐藏某些系统用户的UI元素，以避免使用大量始终禁用的项目压倒他们？ 一个解决scheme可能是angular色工作区。 如果我们清楚地知道某个angular色的用户永远不需要访问某些特定的数据，那么我们创build了一组类似于权限的UI控件条目，但是这次我们不称它们为权限。 而且我们可以在这里变得非常有趣，甚至允许用户自由定制他们的工作空间，并select他们可以或不可以看到的东西。 当然，权限将始终占据最高优先级，但它只会影响UI元素的数据和状态，而不会影响可见性。
那是我的两分钱 不幸的是，我自己并没有在权限和UI工作区选项被整齐分开的系统上工作，因为当“损坏已经完成”时，我总是以某种方式来得太迟。 但是，我希望有一天我会有一个机会。 我只是希望find一个很好的例子，如何做到这一点，但不知何故，互联网search不给我任何有用的东西。 这是否意味着没有其他人得出和我一样的结论？ 我不相信它，企业devise模式世界中的某个人早就应该注意到了这个UI < – >权限阻抗不匹配。
