Well, the View All Site content page is awkward, as everyone seems to have it on their page, but I think you’d miff site admins by removing it from the page. So, I went in and had a look at the code for it - and realised that it was security trimmed. It uses an SPSecurityTrimmedControl:

<!-- View All Site Content -->

<label class="ms-hidden">

<SharePoint:EncodedLiteral runat="server"

     text="<%$Resources:wss,quiklnch_pagetitle%>"

     EncodeMethod="HtmlEncode"/>

</label>

<Sharepoint:SPSecurityTrimmedControl runat="server"

     PermissionsString="ViewFormPages">

     <SharePoint:SPLinkButton id="idNavLinkViewAll" runat="server"

          NavigateUrl="~site/_layouts/viewlsts.aspx"

          Text="<%$Resources:wss,quiklnch_allcontent%>"

          AccessKey="<%$Resources:wss,quiklnch_allcontent_AK%>"/>

</SharePoint:SPSecurityTrimmedControl>

Hmm. Okay. But users with very few permissions were still able to see this link. What gives?

Well, the important part is the PermissionsString attribute - it’s set to ViewFormPages. That’s pretty low - users who’re able to view a library seem to have that. So I wondered, what other PermissionsStrings are there?

A quick search found Zac Smith had been wondering the same thing. And then I thought to check MSDN, and they have a nice list of the permissions and what they mean.

So, I set PermissionsString to ManageWeb, and now the ‘View All Content’ link should only appear for Site Admins.

Ah, but how does the content that doesn’t need a margin get displayed? Well, it supplies an override to ms-bodyareaframe to set the padding to zero - and that is why you should make sure you use the ms-bodyareaframe style!

I found this when working off Heather Solomon’s Minimal Master pages, which don’t include this style.

I’ve even tried using JavaScript running onLoad to match and replace the image sources - but as the TreeView control dynamically loads subnodes when it’s expanded, well, I’d have to hook into that event also, and replace any new images again. Not really practical.

All in all, those images seem to be just baked in.

This posed a problem - some elements needed dark text, others light, and SharePoint gave them all the same style. Looking at the master page, I couldn’t see any way of directly applying my own style - they seem to be built into the delegate controls (though I must confess, I can’t see where). Anyway, I didn’t fancy the delegate controls.

After much head scratching, I realised my mistake - CSS always overrides with the latest applicable style. Thus, in the end all I needed to do was make sure that there was a style which only applied to the items in the ‘global links’ section, and that it came after the ‘normal’ ms-splink and ms-hovercellinactive styles.

Thus, I found that the following style did what I wanted:

/* Style to make the link menus for 'Welcome' and 'My Links' light coloured text */
.ms-globallinks .ms-SPLink a,
.ms-globallinks .ms-SPLink a:link,
.ms-globallinks .ms-SPLink a:visited,
.ms-globallinks .ms-SPLink a:active{
color:#ffffff;
}


The Publishing Console is the control for showing all the ‘edit page’, ‘check in’, ‘approve’, etc. functionality for publishing pages. You’ve gotta use it.

Complaint 1: It assumes that it’s going to be inside a table.

The control produces a table row - a <tr> . Hellooo? Anybody here of accessibility? Trying to avoid Tabled designs? Thanks guys, you’ve made that easy.

Complaint 2: Styling through JavaScript

So, the publishing control has these bits of padding at either end. Irritatingly, they’re hard to get rid of. They also position div tags below the table row that the console produces. This is shown on the right. So, what style contains the code for that? Um, none. That style is set in EditMenu.js, not in any style.

What bloody idiot decided to build such an inflexible, unstylable control, and did it in this way? There is no need for it to be done this way. I’ve now got to fight passed this, or write my own publishing console. Great. I’m happy with the out of box console, I just want to change it’s style a bit - creating a new control is excessive (though instructions are here).

Okay, slightly calmer edit - okay, yes, I can copy and change the Publishing Console itself - the file is straight forward enough - and hook it up as a delegate control. But I shouldn’t have to.

Success - I got rid of the end space. I realised that I could turn off display of the non-breaking spaces that hold the end padding open - and that annoying JavaScript doesn’t turn the visibility of the inner div tags back on!.ms-consoletitleareaframe, .ms-consoletitleareaframebottom
{
width:0px;
padding:0px;
margin: 0px;
background-color: #ffffff;
background-image: none;
display: none;
}

Could not open virtual machine: I:\MOSS003 - OCT07 Base\Windows Server 2003 Enterprise Edition.vmx.

You do not have access rights to this file

Naturally, it struck me that a) I’m admin on my own machine, so privileges seems unlikely, and b) it had worked fine on Thursday. As I: is a USB hard disc, I copied the VM to my local drive, but the problem persisted.

I made sure that permissions were the same for this VM and others - they were.

I tried upgrading VMWare from 6.0.1 to 6.0.2, just on the off-chance - the problem persisted.

I was trying to open the VM by double clicking on the .vmx file. I tried opening the VM through the ‘file open’ dialog too - that didn’t work either. In fact, that caused VMWare to crash.

In the end, one of my colleagues suggested removing all spaces in the VMX file name (based on a post in VMWare’s community forums ) - and that fixed it. If I put the spaces back into the VMX file name - errors again. The really weird thing is, though, that I have plenty of other virtual machines with spaces in the file name, and they seem to work just fine. Further, why did it work and then it start to raise errors when the file names hadn’t changed?

Sounds like a bug. Something isn’t right there.

Oh, I’m using VMWare workstation for Windows 6.0.2 on Vista.

I’ve posted this to the VMWare community site here, but I’m blogging it too, as you have to log in to get the the VMWare site, and I don’t know if Google will pick it up.

I guess it sort of agrees with my conclusion of MOSS workflow - that the auditing is awful. I mean, I get that ‘Workflow History’ items fits nicely with the SharePoint ‘item’ idea, but couldn’t we have a table for this? Or at least an implementation of Workflow Foundation that lets us plug-in our own tracking providers?

If I could get a week free, I’d write one and stick it on codeplex (for the glory).

One that I’d not seen before, and set my toes tingling was about Geo-replication in MOSS, by Syntergy. They talked about a number of their products (and their Sharelink product - for integrating SharePoint and Livelink - was interesting), but the main part of the demo was Geo-replication. Basically, you can select (at a broad or narrow level) what you want to replicate, where you want to replicate to, what events you want to replicate, and it does so - including scheduling, and dealing with collisions of changes and resolving them.

- SharePoint allows you to organise your document and processes - but doesn’t mean that you will. You can take a horse to water, but you can’t make it drink - and this is true of every document management, content management and process management app I’ve ever worked with. It is a good point, but it is not SharePoint specific. Books could be (and are) written about getting users to buy into change. Change management is hard, and often over looked by supplier and by the organisation.

- Wikis? WTF? If that’s all you want, install a specialist Wiki app - damn straight, “Keep It Simple, Stupid”. Enterprises don’t just want Wiki’s though. They don’t just want Blogs either. They want content management, collaborative working, extranets, multiple authenication providers, reporting, exposure of business data, including data for other systems, document management, process management - the whole gamut. SharePoint provides all of those things, not as well as a specialist application - but it does it in one, rather than many apps. I’ve said it before SharePoint is like a Swiss army knife - there are better knives, and there are better cork-screws, but this way, I only have to have one tool. You’ve only got one (albeit huge zeppelin) system to administer, only one (huge zeppelin) backup to run, etc..

- Training? Yes, there’s a lot, but the post misses the point that if you had lots of little “KISS” systems, all looking cute and “Web 2.0″ (UCK!) then you’re going have just as much training to do - ‘cos you’re going to have SO many systems to administer. Further, you don’t need to know it all. You’ll have adminstration happening at different levels, and development happening within difference aspects of SharePoint. For example, I specialise more in workflow than my colleagues - they might specialise in search, or content management. SharePoint 2007 is too big for just one person, but that’s true of many enterprise sized systems

- The poster’s “What will they do” section is wrong. Totally wrong. What they’ll do is issue a couple of service packs, or maybe release a SharePoint 2009, it being a patched release. There are a lot of kinks in SharePoint 2007, and they need to be ironed out. But Microsoft will do that - they are actually pretty good about doing that (at least, when there is commercial pressure - or a good open source alternative. Firefox, anyone?)

- Get rid of the hierarchy? Tagging? These lines suggest to me that the author really doesn’t get SharePoint. Content Types are far more useful than tagging. Tagging does not scale Enterprise wide. And as for hierarchy - SharePoint has so much less hierarchy than most of the systems I’ve worked with. It certainly has less than a network file share. Which actually, I take issue with - I think people get hierarchies, and that they have a place.

- Page weight? Bang on, I have to agree with the poster on this. The default pages are too heavy. The Core.js file is too big, and certainly should be easier to remove from a published internet site. And the CSS is just awful. Core.css it vast, complex, and you have rules being overridden from all over the place. Even the neat functionality in SharePoint Designer doesn’t help overcome this. Further, MOSS is not WCAG ‘AA’ accessible out of the box - but this is a requirement for the governmental sector in the UK.

- Search? SharePoint search, used correctly with Content Types is better than Google search. Google is great at full-text search, and I’d have to say better than SharePoint (though SharePoint isn’t bad - I remember ‘Excite’). SharePoint has the advantage of metadata around the document though, and this is what makes it better. Yeah, if you just dump all your documents into a site without classifying them, then yeah, Google will do better than SharePoint - but your system will soon become unusable. Though I don’t like the amount of work you have to do get Search user interfaces the way you want them.

- Installation was no worse than any other enterprise app I’ve had to install - indeed, it was simpler than many!

So yeah, SharePoint 2007 isn’t some neat, tidy, focussed little web 2.0 app. It’s not lightweight - but nor was it meant to be. It is an enterprise grade single application designed to provide a lot of different aspects of functionality. It doesn’t do them as well as specialist apps, but it can save you buying multiple applications, and having multiple things to look after - just like a Swiss army knife.

What I wanted to be able to do for a customer was to create a SharePoint feature that would deploy all my physical files, and in such a way that they weren’t customised. Well, I think I’ve done that.

I pretty much followed the gist of this blog entry by Chris O’Brien (his blog is excellent and well worth a read).

You can also get a feel for it by examining the PublishingLayouts feature that comes standard in MOSS. That feature deploys all of the OOB master pages, etc..

In short, the approach is:

• Create design in SharePoint Designer
• Copy and paste master page code to a new aspx file in your feature, with the same name as the file in SharePoint Designer. (Do not just save the file in SharePoint Designer to the file system. It mucks up the links. Copy and Paste the code - just as Chris says to. Guess who forgot?)
• Save all other relevant files to the your feature.
• Create the Feature.xml file
• Create the Elements manifest file. Note that the XML is case sensitive, and the case used in the blog entry above is wrong.
• Make sure that the permissions on the feature folder are correct and inherited by child files and folders.
• Run “stsadm -o installfeature -name featurename”
• Activate feature at site or sitecollection level.

Attached is an example feature that installs a (rubbish) master page I’ve created called ‘Cairngorm’. To install it:

• Unzip the archive
• Copy the CairngormMaster folder to your Features folder in 12 Hive
• Check its permissions
• Run

  stsadm -o installfeature -name CairngormMaster

• Go to the Site Collection Features page, and activate it.

You should now find that you can select the ‘Cairngorm’ master page from the ‘Site Settings > Master Pages’ page. Select it for your master pages, and you should find your pages go a bit black and orange! You can get the dodgy design I came up with here, but please just use as an example - it looks bleedin’ awful.

• Role-Based Templates for SharePoint My Sites: Under the Hood
• Application Templates for Windows SharePoint Services 3.0: Under the Hood

The application templates one was very interesting stuff - design patterns, and techniques for customisation that I didn’t know about. If you only read one of these documents, read that one.

The role based document was not as good. The first part about Personalization, how it works, and My Sites strategy, is interesting, but the later bit not as much so and it doesn’t really get as far under the hood as the application templates document.

If nothing else, what it showed me is how I need to get a better handle on SharePoint’s XSL

What is branding of SharePoint?

I think the question of what people really mean by ‘branding’ or ‘customisation’ or ‘skinning’ is an essential first question. With so many words for such a wide range of possibilities, there is plenty of room for confusion. Some customers will mean sticking whatever logo they have at the top of each page. Others will mean changing the entire of each page to fit within corporate style guides, and restructuring the elements of pages. Consequently, there are a range of techniques for doing such customisation. I’ll split them into the ‘level’ or ‘type’ of user that would typically make such changes. First though, let’s have a look at some of the technologies used in SharePoint look and feel.

Look and Feel Technologies

Master Pages
Master Pages are an ASP.NET technology, and potentially very powerful. However, in SharePoint they have some limitations. Master pages are a template for things that should go on a page - like the header, logo, navigation controls, etc.. They have ‘content’ controls that display the actual ‘page’. When the ‘page’ is requested, it looks up the master page it should be using, combines the two, and produces the page.

In practice, in a ‘default’ SharePoint system, this means that the (usually white) content area in the lower right of most pages (to the right of the quick navigation menu and underneath the top navigation tabs) is the actual ‘page’. The rest of what you’re seeing comes from the master page - that’s the navigation, title, favourite links, site action button, search box, and so on.

Master pages give you the power to make structural and style changes to the page. For example, if you don’t like the position of the site action button, you can move it. Or if you want to move the quick nav menu to the right of the page, go ahead.

Different Sites can use different Master Pages, and they and be applied to a hierarchy of sites, so you can change a feel for a number of sites simultaneously.

However, SharePoint has master pages for 3 different ‘types’ of content page:

• Normal pages- These master pages affect normal pages that users would typically see, such as viewing a document library or task list.
• Publishing pages - These are used by the publishing features, and can be very ‘non-SharePointy’. They’re designed for the Web Content Management facilities in MOSS, so really they’re designed to let you publish your page exactly how you think it should look.
• Application pages - Such as the Site Settings page, or the ‘Spinny-thing’ you see while SharePoint is busy

It is worth noting that Application pages use a system-wide master page which cannot be changed without development (i.e. it can’t be changed simply as an administration task). (There are some links regarding doing this here )

A good description of what a master page at Heather Solomon’s blog. (In fact, if you really want to know about branding, subscribe to her blog and visit her site now).

Themes
Themes allow you to change the styles applied to a page, and thus allow you to make stylistic but not structural changes to a page. You can use themes to change colours, fonts, background images, etc.. However, this is not to say that changing the style of a page is easy. To put this in perspective:

If you have attempted to override the styles on an out of the box SharePoint site, you know that it isn’t a very easy thing to do.

• The core.css file that contains the basic rules has 979 different style rules.
• The core.css file uses a palette of 132 colors and 143 images.
• The default page of a newly provisioned team site uses only 61 of those rules.

So, unless you have branded a lot of SharePoint sites and are intimately familiar with core.css and the default master pages and page layouts, just figuring out where to start modifying can be a daunting task.

This is before you consider that there might be overriding styles being applied by the master page and, of course, the theme you’re using. If someone tells you it is ‘easy’ to change the styles of a SharePoint page, ask them to try it - the core.css file is huge.

However, one of the worst things about themes, in my opinion, is that you can’t make them inherit, or apply them to a hierarchy.

More information on themes (in SharePoint 2003 - but the same things apply in 2007) at Heather Solomon’s blog, again.

Web Parts
I find that it’s worth remember that Web Parts are a way of customising your page, and although they don’t control the ‘chrome’ of you SharePoint site (i.e. the styles), they can be used to control the structure of a page. There is a huge array of Web Parts, and SharePoint is designed to let you add more; discussion of all of them is beyond the scope of this document.

Themes or Master Pages?
Which should you use, and when? A good analysis at Heather Solomon’s blog. (See a pattern anywhere?)

The synopsis:

If you are using the SharePoint site intact with the navigation that comes with the site, and you just need to update the colors and images and add a header to the site, a theme can handle all of that for you.

With master pages you can implement your own navigation systems, custom code and design elements, move elements around on the page or hide SharePoint components you don’t want to use. It is a more complete solution for totaling changing the way SharePoint looks.

Levels of User - and Customisation

(Note - this doesn’t include the designer, who would typically not be a site administrator or developer. A technically accomplished designer might also be the ‘Web Designer’ role, or this role might be filled by a developer. Just don’t let techies design look and feel, okay?)

There are 3 levels of customisation and these match up with 3 different types of users quite well. In increase order of control and effort, they are:

Site Administrator
It’s worth bearing in mind that part of the point of SharePoint is that Site administration can be pushed down to Business Analysts or Power Users, while the Farm administrator looks after the SharePoint infrastructure. Thus, a Site Administrator could be anyone from the Farm Admin down to the user in charge of organising the company fun day. To this end, Microsoft have exposed a number of ways of changing the look and feel of a site to Site Admins. They can:

• Change the logo
• Change the items shown on the navigation elements (within some limits)
• Add or customise Web Parts
• Apply an existing Theme
• Apply an existing Master Page

Web Designer
Designers will mainly be using SharePoint designer to customisation to SharePoint. This allows them to make changes to the master pages and styles within SharePoint, which is great. Also, such changes are stored in SharePoint directly, and consequently they’re under version control!

Most serious SharePoint branding and customisation will happen at this level.

However, what isn’t so great is that customisations made to a master page this way are not so easily transferred from system to system, as they aren’t features.

Developer
Developers can use SharePoint designer to create their custom master pages, and then take the custom page and package it up into a feature. This is described well here. Once you’ve done this, you can then install your master page as a feature on many systems.

Developers can also create features for the ‘Delegate controls’ - essentially they can build features to replace things like the navigation or search controls. Also, if you want to change the master page use for your Application pages then you’ll need to do some development.

Conclusion

SharePoint does provide a wide scope for customisation of it’s structure and style, but with multiple techniques available you really need to identify early what it is you want to do, so that you can then figure out the route you’re going to take. Try to consider what it is you’re trying to achieve, and determine the value of what you’re doing - reskinning a SharePoint site for the sake of it is wasteful.

If you want to familiarise yourself with some of the themes and master pages, try changing them on a system using the Site administration pages. It is quite informative!

Links

Branding SharePoint, parts 1 and 2

CSS Reference for styles in SharePoint 2007 - note: doesn’t cover all of the CSS classes used, but is a good starting point.

Minimal (i.e. Base) master pages - Yes, Microsoft do their own, but Heather’s is, apparently, a more minimal ‘minimal’

Parts 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14