对我来说这是一个长期存在的问题,我从未真正解决过,所以我想要你的意见.如果我知道用户因权限或对象状态不足而无法执行的操作,那么这些操作的UI元素是否应对用户隐藏,可见但已禁用或可见,如果尝试会导致错误?你答案的理由是什么?如果禁用,您会告知原因,如果是,如何?
这是一个Web界面,所以我已经知道我需要检查传入的帖子/获取权限并在那里处理错误.我主要谈论如何处理UI.
这与关于禁用或隐藏菜单项的规则类似,但我对所有类型的UI元素感兴趣,而不仅仅是菜单.
例子:
我有一个新页面,允许用户创建一个新的事件.事件可以是主事件或子事件.创建主事件需要"EditMasterEvent"特权,而创建子事件只需要"EditEvent"特权.我有一个下拉列表,允许选择现有事件作为父事件(主事件)或没有父事件(这是一个主事件).如果用户仅具有"EditEvent"权限,那么"创建主事件"选项是否应显示在下拉列表中或省略.
删除事件要求您是应用程序管理员或具有事件类型的相应编辑权限.在后一种情况下,该活动也必须超过5年.删除事件会导致系统中相关数据的主要级联删除,并且出于法律原因,此数据必须在事件发生后保留至少5年.由于此操作对于普通用户来说很少见,因此典型情况是该操作不可用.是应该一直显示还是仅在实际可能时显示?
Stephen C. S.. 44
隐藏 - 这是当前用户永远无法使用的最佳操作方法.没有必要让用户浪费精力去弄清楚为什么某些东西被禁用,如果没有他们可以采取的行动来改变这一点.
已禁用 - 这是有时可用的操作的最佳方法,但不是当前或当前上下文中的操作.禁用选项应该传达两件事:第一,动作现在不可用;第二,用户可以做一些事情来使动作可用(更改一些设置或权限,选择一个项目,输入先决条件数据等. ).如果您可以指出需要做什么才能在工具提示中启用操作 - 那就更好了.在用户输入数据或更改上下文时启用/禁用操作可提供有关程序所需内容的出色反馈.
失败错误 - 这是最糟糕的选择.您应该只针对可能有效的操作使用错误报告:除了尝试之外,您无法判断它是否会失败.
隐藏 - 这是当前用户永远无法使用的最佳操作方法.没有必要让用户浪费精力去弄清楚为什么某些东西被禁用,如果没有他们可以采取的行动来改变这一点.
已禁用 - 这是有时可用的操作的最佳方法,但不是当前或当前上下文中的操作.禁用选项应该传达两件事:第一,动作现在不可用;第二,用户可以做一些事情来使动作可用(更改一些设置或权限,选择一个项目,输入先决条件数据等. ).如果您可以指出需要做什么才能在工具提示中启用操作 - 那就更好了.在用户输入数据或更改上下文时启用/禁用操作可提供有关程序所需内容的出色反馈.
失败错误 - 这是最糟糕的选择.您应该只针对可能有效的操作使用错误报告:除了尝试之外,您无法判断它是否会失败.
与几乎所有UI问题一样,答案是"它取决于".
您需要权衡可发现性与用户满意度等.例如,允许无效操作使您有机会解释为什么某些内容无效.如果"为什么这种禁用"的答案不明显,这将特别有用.对于大多数用户是初学者的应用程序,这很重要.
另一方面,看到一个控件,点击它,只会得到一个"抱歉,你现在不能这样做"的消息可能会非常令人沮丧.几年前我继承的应用程序充斥着这种东西,并且使用UI进行了挫折.
完全隐藏功能可能不是一个好主意.想象一下,知道一些功能"就在那里",但现在它已经消失了.无论是菜单项还是工具栏按钮还是完全不同的东西,将其隐藏起来都会让最终用户感到沮丧.
尝试做一点可用性测试,如果只是询问你看到的下一个人"嘿,禁用它或显示信息对话是否有意义".只有另外一种观点通常足以让你从另一个方向看问题.
底线:尽最大努力为用户服务.您提到的所有方案在某些情况下都是有效的.与所有UI问题一样,问问自己(或更好,您的用户)最适合他们需求的问题.
我禁用元素而不是隐藏它们.这样用户就知道该选项通常是可用的,并且我提供了一个工具提示来解释该元素当前不可用的原因.
这取决于.您是否希望用户知道该操作是否可行,而不是为了他们?在这种情况下,向他们显示按钮,但禁用它.一个例子可能是如果用户没有删除权限,但是其他用户没有删除权限,他们应该知道可以删除条目,因此如果他们需要操作,他们可以要求某人为他们执行此操作.
另一方面,如果用户甚至不知道该操作(例如,对审计日志没有读访问权限的用户可能不应该知道这些日志存在)应该不能看到该按钮,所以完全隐藏它.