So, might not be news, but SharePoint’s out of box Page Layouts suck. I’ve already described how the page layouts have an image on branding, introducing styles to change the navigation, etc.. This has led me to the conclusion that you shouldn’t use the out-of-box publishing sites – start from a minimal publishing site, and build from the ground up.
But what of customers who have naively thought that, I don’t know, a Collaboration Site Template might be a good template to use for the collaboration site? Well, this is the problem I’ve got now; a customer has used the out-of-box page layouts extensively, and now wants the styles of the text and so on to be consistent. How can I do that? Continue reading “Out-of-Box Publishing Page layouts suck too”
SharePoint designer is so like a wife – I love it to bits, sometimes I hate it, and I fervently hope for a cuter version in the future! No, I’m kidding.
But SPD currently has this persistence in adding a in front of my page’s title field. I don’t need that non-breaking space. I don’t want that non-breaking space. But I keep deleting it, and Designer keeps adding it back in.
For me, it’s a sign one of the two big problems with SharePoint Designer – robustness. When I’m in Visual Studio, I’m comfortable; it’s pretty reliable, normally, and behaves in ways I understand. Even the things that can blow it up are pretty well understood. Much as I hate to admit it, I do think that the reason that C# won out over Java was simpler, robust tooling – Visual Studio.
However, with SharePoint designer all sorts of weird stuff happens… Continue reading “SharePoint Designer – grrr….”
Aka “CAML is the bastard spawn of Satan”.
So, I’m writing a site definition to create a Publishing site. This is a bit of a first for me. One of the things I want to do is deploy a new Publishing Page Content type, and associate some layouts with it.
I started by following Andrew Connell’s instructions for a Minimal Site Definition (as in his book). This all seemed to go pretty well; testing created a new, minimal site.
Next up I wanted to deploy the Content Type and associated page layouts. Well, there wasn’t much information in his book on this – like him, I’d figured I’d write a separate Feature for deploying just the content type and page layouts – but there was very little information in his book about this. Continue reading “Deploy Publishing Pages and Content Types as a feature”
Joel Oleson asks an interesting question:
Why don’t we have a community around our masterpages and themes?
It’s a good question. I can download a million and one WordPress themes, but very few SharePoint ones. Why? Well, I like to answer a question with another question, so here’s a few:
- What’s the market? Who want’s ’em? Well, amongst our customers, corporates mainly. These are the chaps who have expensively developed corporate brands. Off-the-shelf brands and themes aren’t going to meet their expectations.
- Are there small organisations? How many small/non-corportate SharePoint systems are there? The reason so many WordPress themes get written is that there are a lot of WordPress bloggers out there, and lots of hobbyists. How many SharePoint ones are there? Yes, WSS3 is inexpensive – but to work with it, you’re raising the bar on technical expertise requirements. Most blogging plaforms – simple. SharePoint – colossal. And SharePoint Designer costs money – most of the other’s need NotePad, or have a built in editor. Once you’ve started to get into spending money like that, either companies go with the out of the box branding (“we just want the functionality”) or pay (“it must be our brand”).
- Why is it so freakin’ complex? Core .css is 81Kb and 4350 lines long. That’s before you start looking at the other CSS files that you typically need to change – like Controls.css, Calendar.css, Portal.css, DatePicker.css, the HTML editor ones, the menus … ! My styles directory holds 220Kb’s of CSS! Compare that to a WordPress blog. I get why designers and hobbyists build WordPress themes – but what sort of masochist is going to write a SharePoint one for fun?
- Which Master Page? The Default Master? What about the Meeting Workspace Master? And, not wanting to scare anyone, but Application.master and Simple.master, which you can’t change (but can redirect – with code). And your users will see pages that use the Application.master – document upload, recycle bin, viewing all site contents. So a ‘new master page’ is not just one, it’s many, and it takes technical cleverness to replace some of the master pages involved. Most designers are into technical cleverness – nor should they be, it ain’t there job.
- Themes? Themes are good, but limited – there’s no out-of-box way to apply them to a hierarchy of sites, and they can’t make major structural changes to pages. Sure, they can be used sometimes, but again, takes technical expertise. And they don’t style the Date Picker; for some obscure reason, it’s not coded to support themes.
So, I guess in summary, it’s too complex for the typical design crowd, and way beyond the general Web Dev hobbyist community. Most of the designers who can do this sort of work are already doing so – for large companies who pay to have their brand, and don’t want an off the shelf one. I mean, I reckon I can rebrand a SharePoint site pretty completely – though I’ve never tried My Sites (another complexity!), and by the time I’ve done the images, the styles, changes to the master pages, tested it all, wrapped in a feature, you’re looking at, well, days, probably more than a man week, for someone who knows what they’re doing, isn’t aiming for accessibility, and is clear about their objective.
All in all, it’s harder than it oughta be.
I was reading Andrew Connell’s book ‘SharePoint 2007 Web Content Management‘ and it made something crystallize for me. I’ve been pondering this for about 8 months or so, but I believe that several of our customers are using the Publishing features of MOSS incorrectly, and that simply basing sites on out-of-box Collaboration and Publishing site templates is a mistake.
(Well, at least without additional planning) Continue reading “Plan Your Publishing Pages”
Like Heather Solomon, I’m sometimes asked about styling individual web parts differently to the rest. I didn’t know of any way of doing this; instead, we’d typically style particular web part zones differently, but this meant that all web parts in that area looked differently.
Well, Heather has now posted ‘Controling single web parts with CSS‘. Neat. I didn’t know you could do that attribute selection.
The downer about this technique is that you have to set a DOCTYPE – and I can see that causing all sorts of grief as stuff breaks… …so it’s probably not something you’d do unless you’re building reasonably custom master page.
As I’ve mentioned before, I reckon that from now on I’ll do all SharePoint branding through features alone – not using themes or the ‘choose master page’ page. Which is fine, and useful too – one of the questions that has been raised recently is how to automatically apply the branding when a new site is provided. Well, feature stapling is the way to do that.
For those who don’t know, feature stapling is creating a feature which associates another feature with a Site Definition. When a site is provided by that site template the associated feature is activated. So, for example, we might have a BrandingFeature feature, which does all of our setting alternate CSS, setting master pages, etc., and then use a BrandingStapler feature to associate that with some (or all) of our site definitions.
I won’t bother repeating the ‘how to’ of it, as there are plenty of good posts about it.