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.
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.
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 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.
If you want to examine the points above by yourself, there's a MOSS example site up at wssdemo.com.
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.
By: Geek Lectures - Things geeks should know about » Blog Archive » Sharepoint 2007 from an interface developer’s view (#1)
By: Hasan (#2)
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.
By: Jesper Rønn-Jensen (#3)
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)?
By: Ross (#4)
By: Emil Stenström (#5)
@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 example.com/ 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?
By: Andreas (#6)
How goes the new design btw?
By: Emil Stenström (#7)
By: Jens Wedin (#8)
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.
By: Emil Stenström (#9)
By: Ryan Hamilton » Blog Archive » Feeling the Pain (#10)
By: Donal (#11)
I hope the SharePoint product team take note of this article.
By: Anna (#12)
If you decide to use MOSS, at least avoid forms! You will get a lot of problems with adapting them.
By: Emil Stenström (#13)
By: MOSS should be spelt MOCKERY - Robert’s talk - Web development and Internet trends (#14)
By: Sean Fraser (#15)
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.
By: Ben Robb (#16)
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 http://www.hedkandi.com for a more "design" focused example.
5) Branding blogs and application pages - see the "Community Kit for SharePoint" and "SuperBranding", both on CodePlex.com for examples of how to do this easily.
By: Emil Stenström (#17)
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?
By: Marcus (#18)
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.
By: Emil Stenström (#19)
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.
By: KubuS (#20)
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!).
By: Anthony Grace (#21)
I feel your pain! I'm in the process of branding a MOSS Intranet and was dismayed by the complexity at first, before rolling the sleeves up and giving it some "Irish attitude"! I found the following 7-part series of articles particularly helpful though:
Keep at it,
By: Emil Stenström (#22)
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.
By: Santosh (#23)
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?
By: Emil Stenström (#24)
By: liam (#25)
By: Emil Stenström (#26)
By: justaddwater.dk | Sharepoint 2007, Accessibility, and Impossible UI Customization (#27)
By: Sharepoint 2003 – Sharepoint 2007 – Sharepoint 2010 | PrivatesPortal (#28)
By: LUIS MALDONADO (#29)
By: Emil Stenström (#30)
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.