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.
Andy Burns' Blog 
The pages use User Controls, not Web Parts – Infact not even User Controls,
it should contain custom field controls.
http://www.andrewconnell.com/blog/archive/2008/10/09/Publishing-sites-field-controls-or-Web-Parts.-that-is-the.aspx
Thanks for a great write up Andy 🙂
WOW! What a great evening we had last week at the London SharePoint User Group meeting. Not only did we have record breaking attendance of just over 200 people, but the food/drink and presentations on SharePoint Web content Management went down very well indeed.
I would like to personally thank the WCM guru Chris O’Brien for presenting on MOSS WCM lessons learnt, Microsoft for paying for catering, the lovely staff at LBi (Derek, Natasha and Mona) for looking after the 204 folks during the evening and assisting me in organising it all and the LBi events team for letting us use the Truman Brewery, a magnificent venue for hosting this special evening.
Thanks for coming along, from the enormous amounts of feedback I’ve received, it looks like the evening was a great success and everyone had a great time.
Slides for the night are up here:
http://suguk.org/blogs/sharepoint_blog_1/archive/2008/10/22/14631.aspx
Until next time, see ya 🙂
Riaz Ahmed
Head of Microsoft Solutions, LBi
http://www.linkedin.com/in/riazahmed
http://www.lbi.com
Hi Madhur,
Indeed, that’s an interesting point from Andrew Connell – I’d not gotten around to that one on my feed reader yet!
Yup, the points he makes regarding URLs, versioning, etc. are all correct, and certainly I think he’s right, for WCM using Field Controls over Web Parts is a good idea. Chris mentioned many of the same points.
What the LBi guys had done, though, was they’d pulled those field controls out into seperate User Controls. Field controls would still be in a SharePoint Page Layout; what LBi did put the Field controls in User Controls that were on the file system, and amenable to source control in TFS. Also, by using User Controls you can reuse those controls on different pages, rather than having to repeat the code each time.
Not my idea really – I’d read his post (which I’ll edit into the bottom of the post above!) I’m not sure I’m convinced about pulling nearly all the page out into User Controls like they’ve done, but I’ve not looked into it!
Hi Riaz,
Blimey, I didn’t expect you’d notice my post! Yeah, it was a really good evening, thanks for hosting. It’s always really interesting to see how other folks have actually used SharePoint – especially when they’re trying new techniques. Even if you’re not sure about some of the techniques or choices and so on, it’s always stimulating!
(I’m still pondering on bespoke ASP.NET vs MOSS, but tending to MOSS now – I mean, versioning, very flexible views on lists, workflow – all that infrastructure is, as Chris said, useful in the back end)
Looking forward to the next one too! SUGUK has come a long way from the 20 or so people who turned up for the first meeting I went to.
P.S. – Nice building!
Andy,
Nice write up of the evening. I missed it due to working in Manchester that day.
Very interesting debate to be had about this. I do like several of the points that Chris and Riaz make, but some of it really does seem to be throwing the baby out with the bathwater!
Main issue for me is that of using User Controls instead of Field Controls. (Chris also mentions not using Page Layouts). I really am not sold on that idea. Field controls, (along with Custom Field controls) and Page Layouts are a good approach to WCM. There’s really no need to dispense with them.
In addition, I like to think of myself as someone who has finally got Variations dancing to my tune. It takes some custom development to do, but far less than seems to have been done for Standard Chartered. We have lot’s of working country sites now. Much of the solutions to variations issues are now documented on peoples blogs for other adopters of variations to use.
What would my client say if I threw out all the WCM features of MOSS to build a bespoke way of working and billed them for the privilege? What would new joiners of my project or third party support say when they had to learn a new bespoke WCM system for each large implementation of MOSS they worked with?!
Looking at Chris’ own write-up I like his tips 2-5, but tip 1; Implement HTML markup in user controls, not page layouts in SPD is very difficult to buy into.
That said some good insights there, and nice to see the sheer extensibility of the product being proven.
Once again, thanks for the write-up of the evening.
Hmm. Yes, I’m still unsure about using User controls. However, I’d point out, User Controls are not the same as Field Controls. User controls are much more akin to Web Parts – encapsulated areas of functionality, rather than individual fields.
And I think that on that front, Chris is probably right – for a lot of WCM projects, web parts aren’t necessary, and making them accessible is a pain. I also like the idea of being able to put them into Source control. That said, someone pointed out in the meeting (at length!) that sometimes WCM projects do need/want web parts. I guess that’s what you have to scope up front.
Like you, I’m not sure about abandoning Page Layouts, or at least using the ASP.NET master page functionality.
Multilingual support seemed to be pretty lightweight too. There I think it might have been a choice of ‘do it myself, or spend even longer getting variations to work’. I’d find myself in the same situation – I’ve looked at variations a couple of times (out of interest) and never got them working. I probably could, but at what effort? And I’m a developer; as far as many of our clients are concerned, they’d be ‘just plain broken’ and something simple like what they did for Standard Chartered might just be within their ability in-house.
Ah, the question of not using out-of-box functionality. It’s always the challenge with SharePoint – the one I tend to see is “but SharePoint has workflow. Why would I buy K2?” This has most of the same points as you mentioned – including that just ‘cos MOSS can do something out-of-the-box doesn’t mean that it’s the best, or even adequate, functionality. Communicating this is the challenge, and it’s not one I feel that I’ve figured out yet. Often it comes down to technical detail that can be challenging for the non-technical to understand.
I guess ultimately, it’s a question of the client’s trust in you. Tough one.