james mckay dot net

For the past few weeks I’ve been pretty snowed under with some Sharepoint development work for a client. Since MOSS 2007 (Microsoft Office Sharepoint Services) is much more closely integrated into the whole Microsoft Office suite, you can’t afford to ignore it if you work in IT. Since Sharepoint development is a relatively new arena for me personally, I thought I’d post some of my initial perceptions of it.

Sharepoint development has a pretty steep learning curve. It’s a complex system with a lot of nooks and crannies to hide things in, and stacks of idiosyncrasies to get used to. Take managing the content and structure of your website, for example. You can do this through the web-based explorer (which you find on the main site administration menu under “Manage content and structure”), through another option on the same site menu entitled “View all site content” (which performs broadly the same function but with a totally different approach, even down to the context menus that pop up for each individual item), or through Sharepoint Designer. Like the web-based explorer, Sharepoint Designer gives you a view of your website in a hierarchical tree-like structure. However, the hierarchy is different. It took me ages to get used to the fact that one put the master page gallery directly under the site root as “Master Page Gallery” and the other called it “masterpage” and put it in a subdirectory entitled “_catalogs”.

Sharepoint Designer also seems to have something of a mind of its own when it comes to telling you what has been checked out and what hasn’t. There were several files in the site that it persistently and obstinately flagged as checked out even immediately after I had checked them in using Sharepoint Designer itself. This was a major irritation as it meant I had to go into the web-based interface to check them out again: being fully under the delusion that they were already checked out, Sharepoint Designer refused to give me that option on any of the menus. You can get round this by using the web-based explorer, but it’s rather annoying nonetheless. The Sharepoint expert who has been working with us on the project told me not to worry about this. “Sharepoint Designer is full of bugs,” he said. Very reassuring — not!

Then there’s the whole issue of accessibility, standards compliance and the horrendous markup that Sharepoint sees fit to churn out. Sharepoint has a very bad reputation for accessibility, and while MOSS 2007 has improved over Sharepoint 2003, it still has quite a way to go. WCAG “A” standard is probably within your grasp for a public facing website, but “AA” standard is considerably harder. Some of the markup that Sharepoint produces is seriously ugly. If you use Web Parts it insists on nesting them within tables within tables within tables — I found one place where the table nesting was no less than six levels deep, for instance. I came across an article the other day that tells you how to make your public facing Sharepoint website produce valid XHTML. It looks quite helpful, but I couldn’t resist the temptation to try running the article (which itself appears to be hosted on a Sharepoint installation) through the W3C’s validator service to see if it itself validated. It didn’t.

I’m pretty surprised that Microsoft hasn’t made it a priority to get products such as Sharepoint to produce valid XHTML 1.0 strict out of the box, with a totally clean separation between HTML markup, style sheets and Javascript. It’s likely to be a major stumbling block towards Sharepoint uptake, especially in the public sector. It’s all the more embarrassing when you consider how well some open source tools do in this respect. MediaWiki is one of the best examples I’ve come across to date, for instance. Although anyone can (and does) edit it, sometimes making it look pretty messy or even downright vandalised, it is always valid XHTML every single time. In fact, I defy anyone to find (or create) a page on Wikipedia that fails to validate.

What concerned me most, however, was the complexity of deploying your Sharepoint solution. It is unbelievably bitty. I’ve discovered the hard way that being able to perform deployments and upgrades in one or two easy steps is essential if you are to minimise the risk of making mistakes, and having clean, well-defined places to put things makes it much easier. However, Sharepoint takes a perverse delight in scattering the places that you have to put things to the four winds and complicating the process as much as it possibly can. You have to put compiled code into the Global Assembly Cache, some things into your web application’s virtual directory in IIS, and other things into a whole raft of subdirectories of:

c:\Program Files\Common Files\Microsoft Shared\web server extensions\12

You also have to make quite a bit of use of a command-line tool called stsadm.exe, which is in a subdirectory buried deep within the bowels of the above mouthful, and, guess what, the Sharepoint installation program doesn’t even think of adding it to your PATH environment variable, so you have to grub around with the search facility just to find it. Deploying your content itself involves restoring the content database from a backup, which may or may not work properly depending on a whole lot of parameters including the phase of the moon and what you had for breakfast, and if you make a mistake, the chances are pretty high that it will bluntly inform you, “Sorry, an unspecified error has occurred.” (Hint: set <customErrors mode="Off" /> in your web.config file to get any idea of what’s going on there.) And that’s before you get onto having to do an iisreset /noforce every time someone in Istanbul blows their nose.

Posted at 21:38 in SharePoint