So, I went to the SUGUK meeting last week on the 16th at LBi’s Truman Brewery building on Brick lane. I was looking forward to it, though was disappointed to find that the brewery is now offices. Anyway,the subject was WCM best practices with Chris O’Brien and Riaz Ahmed, who’re always entertaining speakers.
Session 1 : Web Content Management in MOSS, real life case study by Riaz Ahmed
A thought provoking presentation by Riaz on their work for the bank Standard Chartered. This is a fairly massive customisation to SharePoint, including a number of very interesting Features:
- Much of the page content is driven by search. As SharePoint search didn’t give the features they wanted, a third party search engine (Endeca) was used, and this allows things like facetted searching, saved searches, etc.. Really, the site is driven by search – they’ve done away with a browsable heirarchy. Interesting concept – though I can’t see any of our customers going for it (except maybe the Filenet Panagon users).
- The pages use User Controls, not Web Parts. Now stop, and think about that. It seems weird, but actually, it makes sense. It has a lot of advantages:
- You can use proper source control
- You can control the output HTML much more easily (accessibility anyone?)
- Deployment is simply into one folder in 12 Hive
- You can use code behind (hurrah!)
Sure, you’re throwing away the user-configurability of web parts – but in the context of a regulated WCM site with specific style guides, that could actually be a plus point. And if you really want, you could still put web-part zones into the user controls – but I doubt you’d want to much.
As part of using User Controls, all Page Layouts do is define what user controls are used. The pages themselves are just a couple of lines long.
- Custom Document conversion – To author content for this site, users were using Word. Now, as I’ve noted, the Document Conversion Service with MOSS isn’t great – no images, styles are an issue, etc.. LBi tagged up their Word template with XML (which is invisible to the users) to let them pluck out the actual content, and they then wrote their own custom conversion service. Damn them, those are things I’d wanted to try!
- Custom Email service – As they were sending out thousands of emails, they found they needed a custom email service, rather than just SharePoint alerts.
- No Variations – the sites had to be multilingual, but they didn’t use variations (not much of a surprise – variations suck). Instead, they built their own.
All in all, a really impressive site (and look at the page code – no tables!) However, it raises questions. Given that they didn’t use SharePoint search, document conversion, web parts, page layouts, variations, alerts, and they were using the ASP.NET membership provider for user logins, was it still worth using SharePoint? Or if they were doing it again, would they use bespoke ASP.NET. Riaz described this question as ‘contraversial’, and Chris answered that actually, it still gave them a lot – much of the administration and back end is done through lists, and so they don’t have to build a user interface for all that.
That’s true, but as I thought about it on the train home, I’m not sure I’m sold on that. ASP.NET’s data access controls (Gridview and so on) can give you a UI with little effort. Also, given ASP.NET MVC, I’m not sure how hard that would be either.
However, I sort of think that Chris missed another main point of using MOSS – the publishing features, including approval workflows. It’d be a pain to have to write a workflow engine too. I guess I’m undecided – and I can see why it’s a contraversial question.
So I guess the things I took away were that they’d used a number of interesting approaches, and that they’d really bought into ‘SharePoint as a development platform’. Also, the use of third party tools matches what I keep suggesting regarding workflow. SharePoint is a Swiss army knife; there are better tools for other jobs. However, this can be a tough sell – if a customer has just bought SharePoint, and SharePoint ‘has’ workflow (or document conversion, or search) they wouldn’t want to pay for another system. Interesting stuff.
Session 2 : Best practices/lessons learnt: building MOSS Content Management sites – Chris O’Brien
Well, as Chris said, there’s so much to MOSS you could talk around just bits of it all evening. He went through the main topics of discussion quickly (e.g. Security, Accessibility), and then just started discussing his tips. There was a lot of content in it; too much to note them all, but the ones I took away with were:
- Reduce your page size and improve security by removing the core.js from published WCM pages – and remove the Site Actions menu.
- If doing a really custom site, build your own UI – probably as User controls (as mentioned above)
- The first time you go to a SharePoint site you’re prompted to install a control. It’ll not happen again (ever) but it’s still a pain
- Deploying content you’ve got a choice of Features or Content Deployment.
- Make sure you’ve added links to the Site Actions page to ease administrators lives (obvious, but easily missed)
- Capture unhandled exceptions using an HTTPModule. You can then log them productively.
- Use Tracing – it allows you to find errors
Dammit, there was just too much content to really summarise, and a lot was very techy. Chris is a sharp cookie, and his blog is well worth a read.
Actually, the main thing I took away from this was the idea of the HTTPModule to record errors. SharePoint’s logs, well, suck. However, using this, you could write your own. And for development they were emailing errors back to the dev team – nice. I’m not sure we could use it on live – automatic emailing of errors would bypass our normal support system. Still, I’ll be pushing for us to build something similar.
There is a bit of a downer, though – SharePoint throws unhandled exceptions by design, so you’d have to deal with that.
Final thought – you could also have your tracer use the Reflectance API to get the method that is logging something.