Updated
I've updated my answer (a) because I realized that the OP's suggestion ("disabling" rather than "hiding" links) was quite different from the rule we faced; and (b) to say that the big problem we faced was not because we were told links should be hidden in certain situations, but because of a blind across-the-board rule.
We went through a related issue with our intranet several years ago. We had a leader who was sold on the concept of "no access, no link," and it was adopted (without much thought about the implications) as a principle for our intranet web applications. This variant included the case where the linked-to item had no data (e.g. a link to a user by ID who is no longer in the system), as well as cases where the logged-in user should not have access to the data. In other words, in this leader's conception, the link should not ever appear if it will not lead to accessible, existing data.
I can see how this practice would appeal to some people who just don't like being told "no." But as a general rule it was a really bad idea.
The biggest problem, which others have already mentioned that it seriously impairs the UX principle of discoverability.
Suppose a help page tells me to click on this and that link. I go to the page but can't find the link. How do I handle this situation?
- Did I misunderstand the help, and I'm on the wrong page?
- Do I not have permission to access the link? (Knowing about this option requires that I'm already educated about the "no access, no link" principle, which imposes a training requirement on the user population.) If so, is it because I really shouldn't have permission? or because some roles database hasn't been properly updated for me yet?
- Is that link not applicable for some reason that is not clear from the help, and therefore has been "helpfully" removed from view?
- Does the help page refer to an older (or newer) version of the app, and needs to be updated?
- Am I encountering some sort of browser incompatibility issue?
You can see how the confusion and the inability to diagnose the problem can lead to all sorts of frustration. And that's just on the user side. (Not to mention the burden put onto documentation maintainers to try to explain to users that every link might not show up, and how to find out why and what to do about it.)
On the developer side, adhering to this rule imposes a new load.
For every link I emit, I need to consider:
- Not only the target app, but also the source app, need to understand the mapping from user identity and roles to permissions based on scope, sensitivity, and other criteria.
- This make the target and source apps tightly coupled, either by sharing code for evaluating access criteria, or by not sharing code. In the latter case, the apps can get out of sync, in which case the source app could inadvertently omit links to information that actually should be available to the user!
- This makes it a good deal harder to upgrade the source and target apps efficiently and correctly.
- Performance is impacted, because databases need to be queried when generating the links on the source page, as well as when verifying access privileges on the target page. If the source and target apps are hosted in different locations, the performance impact can be substantial.
- When the source and target pages are in different systems, this means that credentials for accessing the target app's database of roles have to be shared among potentially several different source apps, making it more difficult to keep these credentials synchronized and secure.
When this principle is important, it can be implemented, at significant cost. But it should never be applied as a broad rule.
The principle was never fully implemented in our intranet web sites, because it was impractical. Eventually it was dropped. (And there was great rejoicing.)
I support the compromises suggested, such as not providing a link but providing some indication that there would be a link if the user had access (i.e. "disabling"). However the development costs of this feature can be substantial, and should be weighed against the benefits (vs. clicking on the link and getting an informative error message on the target page). I feel that the benefits are small, but I can see cases where it could be important (e.g. when presenting a long list of links, many of which will lead to "no access" or "not found" errors). It depends on the user's task, and their need for hand-holding.
One situation where I could see a case for completely hiding the information from the user would be if the very existence of a resource is sensitive information. In that case, you're not hiding a link because the user doesn't have permission to access the target data; you're hiding metadata (the existence of the resource) because the user doesn't have permission to access that metadata.
Granted, there is a case for reducing useless or less-useful clutter on the screen so that the useful stuff is easier to find. Especially if the links that lead to nothing useful are likely to be numerous and frequent. But hiding is not the only way to mitigate clutter... that can be accomplished by making "doomed" links smaller, grayed out, disabled, or moving them to the bottom of a page. Omitting one of two links on an uncrowded page is not reducing clutter, it's blindfolding the user.