Microsoft Windows SharePoint Services (WSS) 3.0 introduces several new possibilities of controlling how the User Interface (UI) is presented to the users. While the mechanism has definitely been improved since the previous versions, there are a few things which doesn't make working with SharePoint easier to the end users.
I've just read a short article by Joel Spolsky on how the menu items should be handled: whether they should be disabled or hidden if not available or always visible. Joel says that you should always leave the menu items visible and enabled and communicate with users if an action cannot be completed.
As I've been working with SharePoint 2007 for quite some time now, Joel's article made me think: did WSS and MOSS teams make right choices? Let's have a close look at various scenario's of how the SharePoint UI can be customized.
First of all we have the security trimming. By leveraging this concept, the users can see only these items that they can actually access (they have required permissions). Personally I think that it's a great feature which limits the content available to users. I believe that it's a great time savior - especially in collaboration scenario's. Comparing this functionality to what Joel says sounds still okay: there are some links hidden from the users, but if they have never seen them, they don't even know about their existence (theoretically).
The problems would start if the users have access to many sites and have different permissions to each one of them. Especially in the beginning they would spent hours looking for some missing options and links. After a while they would figure out that the available functionality depends on their role in particular project, site, etc.
In some scenario's they might really need access to these extra options, so they are likely to request some extra permissions. But then again: how would they distinct whether the particular functionality is not available for them only or hasn't been installed at all? They wouldn't and would spend some time trying to find it out.
Customizing UI using Features
WSS 3.0 introduces the concept of Features: deployment modules for custom functionality. The mechanism is really powerful and since you can hook up custom code, you can do almost everything in SharePoint upon Feature activation - including adding and hiding menu options. Probably one of the most asked questioned about the consequences of that functionality is trying to save a Site as Template after having the Publishing Feature activated.
WSS 3.0 provides a possibility of saving Sites as Templates. It's a great functionality heavily used in many collaboration scenario's. Power users configure Sites, create pages, lists, add Web Parts and then save it all to a Template for later reuse. Unfortunately the Publishing Feature I have mentioned earlier doesn't support Templating. The MOSS team has probably thought, that the best idea would be to hide the 'Save site as template', since the functionality is not supported anyway. I've been wondering whether they have noticed how many people have actually spent hours of trying to figure out why the links is not there?
Don't hide or disable menu items
To repeat Joel Spolsky: "Don't hide or disable menu items". Security trimming is very useful - especially in collaboration scenarios where you don't want your users to spend hours on browsing through all data and clicking on each single link only to find out that they have insufficient permissions to access it. You should however consider it each single time you're about to remove a piece of the UI that has always been there. End users will definitely not appreciate it.