向最终用户显示访问权限......我应该吗？我不应该吗？
在使用需求管理应用程序时，有些人说，不要向用户显示那些他们无法访问或没有权限的区域，只显示可访问的部分......这对我来说听起来不太好，你们觉得怎么样？
when using Requirement Management application, some ppl say, dont show your users, those areas which are not accessible for them or no permission, only show the accessible section... It doesnt sound good to me, what do you guys think?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这取决于。
It depends.
我突然想到了三个原因，说明为什么您希望避免向用户显示他们无权访问的区域。
您不断提醒他们有些功能无法使用。这可能会导致他们感觉不被信任或不够重要。
你浪费了用户的时间。在我看到的一些实现中，允许用户完成任务，例如填写表单，并且只有当他们提交表单时，他们才会被告知他们没有足够的权限。这可能会导致用户感到沮丧。
你分散了用户的注意力。最佳实践是将最少量的信息和选择摆在用户面前（此规则也有例外）。让您的用户能够完成他们的特定工作，而不是通过完成所有工作的选项来分散他们的注意力。
如果您担心用户界面不一致，那么您可能应该重新审视一下 UI 的布局方式以及任务的分段方式。
一般来说，您应该将应用程序分成任务（用例）部分，并将权限与应用程序中的特定任务相关联。
例如，如果用户 A 只能从系统中提取报告，那么他们只能选择进入应用程序的“提取报告”部分。如果用户 B 可以提取报告并添加订单，那么他的屏幕应该为他提供“添加新订单”的选项，或者进入与用户 A 完全相同的“提取报告”屏幕。这些屏幕在用户 A 之间不应有所不同。大多数情况下的用户。他们的菜单/导航选项将根据他们的权限进行上下文关联，用户 A 甚至永远不会选择单击“添加新订单”选项。
显然存在这样的情况，例如当某些用户具有删除权限时，当其他用户仅具有读取权限时，他们会看到删除按钮。在这种情况下，您的 UI 会因用户而异，但会以适当且上下文相关的方式有所不同。
有人曾经说过，界面不是在没有什么可以添加的时候完成的，而是在没有什么可以删除的时候完成的。
Off the top of my head I can think of three reasons why you would want to avoid showing your users areas that they do not have access to.
You're constantly reminding them that there are features that they cannot use. This can lead to feelings of not being trusted or of not being important enough.
You waste users time. In some implementations I have seen of this the user is allowed to complete a task, for example filling out a form, and only when they submit it are they informed that they have insufficient privileges. This can lead to frustrated users.
You distract the user. Best practice is to put the bare minimum amount of information and choice in front of the user (there are exceptions to this rule). Enable your users to get their specific job done, rather than distracting them with the possibility of the option of getting all the jobs done.
If you are worried about inconsistencies in your user interface then you should probably take another look at the way you have laid your UI out and how you have segmented the tasks.
Generally speaking you should break your applications into sections of tasks (use-cases) with the permissions being tied to the particular task in the application.
For example if User A can only pull reports from a system then they should only be offered the option of going to the "pull reports" section of the application. If User B can pull reports and add orders then his screen should offer him the option of either "adding a new order", or going through to the exact same "pull reports" screen as User A. These screens shouldn't differ between the users in most cases. Their menu/navigation options would be contextual based off their permissions, and User A would never even have the option of clicking the "add new order" option.
There are obviously instances such as when certain users have a delete privilege then they are shown a delete button when other users only have the read permission. In this case your UI would differ from user to user but in an appropriate and contextual manner.
Somebody once said that an interface is done not when there is nothing left to add, but rather when there is nothing left to take away.