Understanding customer needs and business value in WSS v3 customization

I wrote an article recently which questions the architecture of WSS v3 master pages, more specifically the shortcomings of WSS v3 customization when it comes to the application pages which reside in the _layouts folder. I was happy to see just how much discussion this has generated as this was my intention from the start.

I wanted to build on my original post a little by showing (at least from my customers perspective) the business value in having the ability to fully customize a WSS v3 web/site on a site-by-site basis. Understanding how your customers wish to utilize their WSS v3 environment is the single most important factor in making it successful from every standpoint – customization included.

To better explain, here is an example of how I see WSS v2/v3 being used by customers every day. The following assumes an organization is using WSS v2 or v3 and each separate team within the organization uses a different sub web/site.

Most organizations have several unique teams within them, each of these teams have a very strong sense of identity and as such request completely different customizations. For example: Within Microsoft it’s quite likely that the Vista Team would have a totally different collaboration web/sites than say XBOX 360 (You can thank Amanda for that analogy).

In the above situation I would be called in to completely customize (visually and functionally) the XBOX 360 and VISTA sections of the WSS environment.

The problem arises when clicking through the web/site and the customer says; “Hey Guys, there are several sections of our site that do not have our teams common look and feel that we paid you to customize for us, our cool header and other visuals are missing from a whole bunch of pages, what gives?”

Someone (likely a project manager) is then stuck with the daunting task of trying to explain to the customer that you can only share a look amongst all those pages within their otherwise unique web/site.

Obviously waiting until the last minute to spring this on the customer would not be good for relations so the reach widens even more, now reaching the sales team whom must explain this to a customer up front and ultimately lead to a harder sell.

The reason I wanted to explain this scenario is because I’ve been hearing a “solution” to the original problem as – well you can customize the application.master page. In the scenario outlined above which I assume is fairly common for many others, this simply doesn’t work. Many customers don’t have the means to have separate WSS installs for each team.

It all comes down to understanding customer needs. I’d love to hear more about how you and your customers have leveraged WSS solutions – leave a comment.

You may also like...

3 Responses

  1. alex says:

    This is really frustrating – I’m trying to customize my 2007 sharepoint site and it seems I can only customize the pages that reference to default.master … whenever pages go into the application.master reference it seems like a dead end…

    I tried going to IIS and changing the _layouts virtual directory but even then my changes become global :-s

    There seems to be no site specific way to get all pages to look the same… no easy way I’ve found thus far… any ideas?? is this the way it is or am I missing something?

  2. shane says:


    I have spoken with people from Microsot on the issue and I am confident you will see this addressed via blogs when the time is right.

    While I’m just as hungry for information as anyone, we should keep a few things in mind:

    1) It takes time to make statements about such issues – especially for Microsoft whom is often under close watch. I’m confident several people from Microsoft and the SharePoint team realise this question is out there and will supply an answer once they’ve gathered their thoughts and have a sensible explanation which won’t cause too much fuss.

    2) Due to the nature and size of such a project as SharePoint technologies, sometimes we have to accept that there are development check-points. From our standpoint we think – but hey we really really want this feature – from Microsoft’s standpoint – but hey if we manipulate this code in an otherwise stable build, we introduce the risk of throwing the balance off in other areas affecting potentially 100’s of 1000’s of people and ultimately potentially messing up the launch date. When that happens, we get angry, the team and bosses get angry, and the press gets happy.

    Keep the faith brother – there will be explanations eventually. Also keep in mind that we are using the “beta” which means the team is pushed to the max working on the platfrom; developing, testing, managing and evangelizing it almost round the clock.


  3. Ishai Sagi says:

    Did you contact anyone from Microsoft? I get a feeling this front is pretty quiet in the discussion list, and there are only complaints and not answers.

I would love to hear from you.

%d bloggers like this: