Sharepoint 2007 from an interface developer’s view

Like Cameron Moll (Skinning Sharepoint and Pointedly unskinnable), I’ve been working with Sharepoint 2007 (aka MOSS) recently, and I hope you don’t mind me posting a few articles about my work here. I’ve found far too few blog posts that really go to the depth in explaining how things really work. I’ll try to do that here, but I hope you can respect my wish that this does not turn into a helpdesk.


Let’s start. Sharepoint 2007 very, very hard to customize. If your job is to customize the interface in any major way, you have a lot of work ahead of you. You might think you’re a much better interface developer than me, but you still have a lot of work ahead of you. You need to accept that.

When you read about Sharepoint 2007 on other sites you will find that people are really ecstatic about it. Just check the comments on how to customize the calendar. Reading carefully you will find that he’s comparing it with Sharepoint 2003, not with other products, or even a standard ASP.NET site. That’s a big difference. Sharepoint 2003 was much worse, but that does not mean things are good now. This is a common pattern, people that like Sharepoint compare it to the previous version, not with better ways of doing things.

As most CMS:es, Sharepoint gets sold to customers that don’t know programming. They see a product that can handle all the features they want: blogs, wikis, forums, calendars, document libraries, workflows, and so on. All features you could ever want is included, from what is called “out of the box”. The problem is that the system is built so that all of those “out of the box” features are hard to customize. Things like changing how the wiki renders, is really hard. Often it’s easier to rebuild that feature from scratch, than customizing what Sharepoint ships.

This is the main reason, from my point of view, that you should pick another CMS.


I don’t believe you trust me on my words, so I thought I’d be more specific now, and talk about the issues that make Sharepoint 2007 hard to work with (customize). Let me stress that these are not all the issues, just the major ones that an interface developer has to tackle.


From what I’ve read from larger projects, the recommended development environment for a Sharepoint site is a virtual machine. For us, we needed a 36 Gb image, a size that required me to get a new external hard drive, just to store it. Also, running in a virtual machine means that you only can use about half of your RAM, which means everything gets slow. As if that wasn’t enough, a new virtual machine means you have to reinstall all your programs, browsers, plugins again. Web development shouldn’t have to be like that.


Sharepoint has gotten a lot of bashing for not being accessible, so they’ve added some features to account for that. Some of those are really good individually, but looking at the general mess that is the HTML that Sharepoint spits out, the pretty page above fades in importance. One major problem is that you still need javascript enabled for many of the accessibility features. Enabling “Accessibility mode”, among other things, makes dropdown menus appear as new windows (popups) instead of dynamically writing HTML to the page. And this is after they “fixed” it.

Page size

A standard Sharepoint site uses lots of default Javascript and CSS in two files called core.js and core.css. All in all they add up to over 250 kb. Yes, that’s not a misspelling or extra zero, a default page in sharepoint takes at least 250 kb. This is not counting the HTML, a huge, table-ridden, inline-javascripted, mess of things.

If you go through lots of trouble, you can strip those files out, but that means you can’t use any default components. Since much of Sharepoint depend on those, you don’t really want to go that way. It’s a mess, and Microsoft themselves recommend you try to remove some of it to boost performance. Preferably by using AJAX to load the js file later. Seriously.

Javascript and Browser dependencies

Except from core.js, the javascript is spread out all over the place. As usual in many CMS:es, javascript is not treated as a real programming language, so there’s no structuring whatsoever. Sometimes it’s script tags, sometimes inline, sometimes external mini files, and most often automatically generated code. It’s a real mess, and is a big reason for the HTML size being so large. Many of the scripts do not work in browsers other than IE, which means you really need IE to properly use the admin interface.

From the browser compatability info you can read that there are level 1 and level 2 browsers:

“Level 2 web browsers support all of our basic functionality so that users can both read and write in our content sites, perform site administration, etc. Some functionality may not be available, some functionality may be available in a more limited form, and some visual rendering may not be as optimized as our Level 1 browsers. We also will not support Level 2 web browsers on the Central Administration site.”

These are the Level 2 browsers: Firefox, Netscape, Safari. Opera isn’t even in the list. Is this the new, modern way, of handling cross browser compatibility?

Changing the CSS

I previously said that most CSS is included in a file called core.css. The file in itself if huge, with thousands of class names, and no structuring whatsoever. Heather Solomon has made an attempt to make things workable by making images of what each class specifies. It’s not even nearly a complete reference, and helps some, but using Firebug is a faster way. Another thing the CSS sheet above does, is show how completely unorganized the CSS is. Have a look at it.

As with core.js you can’t really remove core.css, since lots of built-in functionality depends on it. So what you need to do is start deciding which of those rules you need to overwrite and which not. Have fun!

To add to the insult, if you just add your own CSS as an external file and try to link to that on your own pages, core.css is appended as the last stylesheet in the source code. This of course means that all your changes get overwritten, and you need to hack around things by using the <link> tag directly (instead of sharepoint’s own csslink-control), or add your custom files via the admin interface. Since core.css is just a list of simple class names, you can also use CSS Specificity to make your rules count, but that isn’t mentioned in any of the troubleshooting blog posts. None the less, it’s tedious do work around.

Share point and Master pages

Most of Sharepoint is upgraded to use .NET 2.0, and its concept of Master pages and aspx pages. For those of you that don’t develop in .NET the two can be explained as a templating mechanism, where each Master page has general placeholders where you can insert aspx pages. In each aspx page you specify one master page, and all of the placeholders you want to fill with content. It’s a pretty good system.

Sharepoint taps into this system by making up two strings “~masterurl/custom.master”, and “~masterurl/default.master”, that you use instead of specifying your own masterpages. Users then specify masterpages in the admin interface, potentially breaking the entire site. Also, Sharepoint assumes there’s just one masterpage per site, so if you thought you could use one masterpage for twocolumn layouts, and another for threecolumn layouts, you’re wrong. The solution here is to break out of the Sharepoint way and hardcode real urls instead of doing things the Sharepoint way.

There’s also things you can’t change. The admin interface has a masterpage called application.master, which controls pretty much everything that has to do with built-in Sharepoint things. You don’t ever change this file, since it’s quite easy to seriously break things then. The problem is that this file also specify the look and feel of the admin interface, and if you’re building a site where people are expected to add stuff, they will spend time in the admin interface. There isn’t a good way around this, and you probably end up just changing some colors via CSS and let it be.

Default .NET controls

The default master pages that ship with Sharepoint is horrendous and I’ll post more details about them in a later post. But even if you roll your own master pages from scratch you still have the standard .NET-problem with controls. Using controls in .NET is a way to package functionality that you can easily add to your pages. A developer just needs to copy a DLL file, and call the control, optionally sending in some parameters. Easy.

The problem with this approach is that a control consists both of logic and HTML. So if you want some built-in logic that renders, say, the breadcrumb trail, you also get the HTML the author of the control deemed appropriate. In Sharepoint, a breadcrumb trail can be a doubly nested table, with display: none; controls to enable accessibility, and a doubly span nested link. It’s just a terrible mess, but there’s no other way to get to the breadcrumb logic, except from building a new control from scratch. Be prepared to work with terrible HTML.

In summary

If you want to examine the points above by yourself, there’s a MOSS example site up at

This article is a interface developer view at Sharepoint 2007. If you look at the system from other viewpoints, I’m sure there are good things there. That’s not my point. What I’m trying to say is that Sharepoint 2007, is beyond repair when it comes to interface customization, and you should do everything in your power to avoid working with it. If I can give one interface developer the arguments to convince a customer to pick another system, this article was worth it. Thanks for reading.

33 responses to “Sharepoint 2007 from an interface developer’s view

  1. Pingback: Sharepoint 2007 from an interface developer’s view
  2. Hey man.

    I feel that Sharepoint is more directed to Intranet, but recently I saw a good deal of sites using Sharepoin.

    Ya Sharepoint customization can be messy and annoying, but I feel it is really powerful.

    Try using Sharepoint Designer.

  3. Hi Emil,
    great article. I hope that you continue to follow up with more examples and findings. I did not know that the condition of MOSS 2007 was that bad.

    One question: What about pretty URLs? Are there methods provided to make all urls pretty and accessible (i mean, directly linkable with no postbacks required)?

  4. I’m glad to see some examples from people about the MOSS shortfalls rather than just general bashing. My only comment is on the page size; when I check the properties on our OOTB sites they appear pretty small, so maybe I’m missing something….

  5. @Hasan: Sharepoint Designer (aka a upgrade of Frontpage), does not help with any of the issues I bring forward here.

    @Jesper Rønn-Jensen: Thanks Jesper, I’ll sure keep writing about Sharepoint.

    Pretty urls are “semi-possible”. Each url point to one aspx-page (no MVC here). Each site you create turns into one directory, and each site has a default aspx-page it redirects to. So you can build urls like store/electronics/ sweden.aspx, where “store” is a Sharepoint site, “electronics” a subsite, and “sweden.aspx” is a page in the electronics site.

    @Ross: Thanks, I thought this kind a article, with real arguments, was missing too. With page size I means both HTML, and core.css and core.js. You can get the full site by using Firebug, clicking the “Net” tab, and reloading. Is it still small?

  6. Whoa, sounds absolutely horrible. Thankfully I’ve been able to avoid MS-products so far in my career.
    How goes the new design btw?

  7. @Andreas: It’s going forward, but I’m not done. I implemented the design I showed you and tested it with my own articles. It was unreadable… So I need to play around with the colors some more. I’ll keep you posted with any progress.

  8. Thanks for the insight in MOSS.

    I would like to say that Intranets should also be accessible, not only public websites. There is of course people with accessibility problems using Intranets as there is people using public websites.

    Browser support is also important, you never know when the IT department decides to switch and instead of using IE start using OP or FF. That happened on IBM when they tried to go from IE to FF. Because so many Intranet applications where built for IE they could not make a big shift.

  9. @Jens Wedin: I fully agree that even intranets should be accessible. Doing accessible sites in Sharepoint is very hard though, there’s some point when you work so much against the product that you are writing your own CMS. As with all things, it has to be a balance.

  10. Pingback: Os 5 Problemas do Sharepoint 2007 para Desenvolvedores » RuanWeb
  11. Thank you. You have hit on all the major issues i loathe about SharePoint. I am hugely frustrated by master pages in particular. Talk about taking a great feature and bastardizing it to make it actually less useful.
    I hope the SharePoint product team take note of this article.

  12. Thank’s for a good article! Some months ago we built a public Sharepoint web site for a Swedish authority that had special demands on accessability (Verva’s guidelines). We also performed a usability test with visually handicapped persons. We experienced that especially the forms were a big issue since they are using a lot of JS. Web forms can otherwise, with high accessability, be very helpful for handicapped persons, but not with MOSS.

    If you decide to use MOSS, at least avoid forms! You will get a lot of problems with adapting them.

  13. @Anna: It’s great to hear that authorities in Sweden take time to do that kind of tests, and it’s of course sad that they pick Sharepoint for their website. You didn’t test the publishing of things did you? I suspect any testing on the admin interface would fail horribly.

  14. Very informative article. And, Yes – Everything you wrote is true.

    Though, you can skin the admin interface with some branding elements and colors.

    CSS Specificity works flawlessly provided one uses

    body id =""

    . Specificity also allows one to overwrite in-line styles (of which MOSS has an incredible amount) by using !important.

    As to your comment about SharePoint lack of blogs with detailed help: you can find all sorts of programming help but nearly all of the articles are written by persons that do not seem to have heard about Web Standards. (Heather Solomon being the exception.) And, most of the fixes are ASP.NET 2 complicated.

    From the amount of new articles on Web Standards sites (like yours), it seems that MOSS instead of IE6/7/8 has become the new poster child for Web Standards education.

  15. Hi – some of your points are valid, but I would say your conclusions are flawed. I think you need to have faith and work through the examples of how to get “better” html output from SharePoint. For *public facing websites*, you don’t really need the majority of SharePoint controls, and you can quite easily remove core.js and core.css from your page via an HTTP handler for anonymous users (this isn’t officially supported, but since it is something than can easily be switched back off, you can quickly get back to a supported state).

    Not going to go through your points one by one, but a few things occured to me:

    1) VPC size. I don’t know what you’ve been doing to your images, but my dev vpcs are all about 8GB in size. I’d look at optimising your vpc builds…

    2) Accessibility. This is a known issue, which the Accessibility Kit for SharePoint is fixing in part. For public facing webs, you have more flexibility, but the editing functionality is always going to be a problem from an accessibility point of view (which is not limited to MOSS, btw).

    3) Control adapters can help with OOTB controls such as the menu / nav controls. See the ASP.NET CSS Control Adapters for more info.

    4) You can brand SP sites, see for example for a more “design” focused example.

    5) Branding blogs and application pages – see the “Community Kit for SharePoint” and “SuperBranding”, both on for examples of how to do this easily.

  16. @Ben Robb: Isn’t the purpose of a system like Sharepoint to help you? Sure, you can go through all the hassle you describe above just to get a decent site running, but picking another tool is a much more effective way of doing the same thing. Really, you can’t really think Sharepoint is a good way of developing websites?

    1) No matter what size you have, it’s still half the RAM and processing power. No other CMS requires that. Period.

    2) That it’s known and partly patched in a 3rd party addon does not make it OK. MOSS adds accessibility problems that most other tools does not have.

    3) Yes, you can hack around the controls that are there to save you time.

    4) Yes, I know all about hedkandi, it’s just as customized as the site I’m building. That you can add pretty images and custom CSS does not make it a good CMS (or other) tool. You can do that with any tool out there, anything else would be insane. MOSS requires you to hack more than any other one I’ve used.

    5) Why do you need to download additional unsupported components to change things like blogs? Really, is that reasonable?

  17. Pingback: SharePoint noise « Grumpy Wookie
  18. Emil,
    I’ve read through a few of your MOSS/WSS postings. With all due respect, I don’t think you quite understand what SharePoint is. Calling SharePoint a CMS system is like calling Exchange (or Domino, if you prefer something non-MS) an SMTP server.
    I have to agree with Ben on most of his remarks.
    In additon, only a compiled .Net control will have a combination of logic and presentation, and only then, if the developer of the control made it that way.
    .Net itself emphasises the seperation of logic and presentation. If what you’re getting out of the box doesn’t suit you, write your own or look on codeplex or any of the other million developer sites (and they’re not “unsupported”, as you state).
    Bottom line is, building elaborate internet facing sites based on WSS or MOSS only makes sense if you intend to also leverage the underlying framework for functionality (authentication systems, integration with AD/CRM/Exchange/etc, collaboration functionality, personalization etc etc etc).
    Otherwise, that would be like (to use my example from above) installing an Exchange Server as a simple mail relay and – I agree with you there – way too much work.

  19. @Marcus: So what should I call it? “Portal” or “platform” is far to ambiguous to make sense to people… and the fact is, most people use it as a CMS of some kind.

    About .NET controls. The problem is that virtually all controls that come with Sharepoint are built with a mixed frontend and backend. You can build any controls you want (except if you want webparts, you have to mix them then), but we’re not talking about just any system now, we’re talking about Sharepoint.

    About codeplex: Sure, you can download stuff from there and use them instead, but wasn’t the reason you paid immense amounts of money for MOSS to not have to download stuff? The default Sharepoint stuff needs to be much more customizable.

    I’ve working in a project where we’re pushed MOSS to the limits, making sure the customer are free to use everything that comes out of the box (all the things you mention). The problem is that the defaults are of such bad quality, that we often have to patch or hack them to make them usable. Or replace them fully by something from codeplex. That’s not a good way to build stuff.

  20. Emil, you are so true about all the SharePoint shortcomings. I’ve been developing SharePoint based solutions for over a year, and I must say that customizing it is a real mess.

    I like SharePoint for its power of integration, but every time a client asks me about a CMS/intranet portal, I advise him NOT to use SharePoint, because of the painful development process (especially with its high price tag!).

  21. @Anthony Grace: Thanks! I wish I had read the article you point to earlier, now I had to figure all that out by myself :/. Almost no documentation is available from Microsoft, of course.

    I’m actually done with the customization on the project that triggered this article, and it’s live and used by over 10 000 people. I must say, the bugs, tricks and hacks I had to do to get there, you wouldn’t believe me. I will try my best to never work with Sharepoint again.

  22. How would you propose handling look-and-feel customization?
    Also, in case I need to add additional conditional alerts which are not available out-of-the-box, what would be your recommendation? Should we just live with what we have or should we go with the customization per business needs?

  23. @Santosh: There’s no single way to handle gui customization. The easiest way I’ve found is only using Sharepoint as a backend, and write your own front-end that gets data out of Sharepoint with your own controls. That way you have full control over the markup. I don’t have an answer to your second question.

  24. You think that is bad? Try taking over a failed Sharepoint project with a ton of bad customizations… My advice is use Sharepoint the best you can. Throw your conscience out the window, employ hacks wherever needed and try to ignore all your best intentions (see: Best Practices) because things are going to get dirty.

  25. Hello emil, thank you for your wonderfull posts. I use them to learn what people that HATE SharePoint or anything MS for that matter have to say about a product that is proving itself in manye different areas. One question I do have is: if you HATE sp so much, why use it; why even bother to make your living from it; hell as you say there are so many other wonderfull products out there like lotus notes; websphere and the like that beat MS to a pulp and don’t have all of the problems you mention on all of your articles you should be proposing those prodcuts instead of wasting your wonderful time writing about such a useless product that is being use by DUMB customers and used to make an honets wage my quite a few developers…. hummm… I guess beating on MS makes people feel good.

  26. @LUIS MALDONADO: You should start by reading the article before commenting.

    Here’s a summary: I point out the exact areas where the product is failing, so that they can easily fix them. I point out that this is one viewpoint, and that there may be others. Please don’t waste people’s time by trolling.

    And yes, I won’t use Sharepoint again after that single project unless there’s a big change in the architecture.

Comments are closed.