In any case, my work spe­cial­izes in Share­Point 2007 cus­tomiza­tion. Some of our stuff can cur­rently be seen on the net, though for safety-​sake I will not men­tion where. (I’m knew to this job-​related post­ing thing, cut me some slack.) Cameron states that Share­Point is good for CMS or col­lab­o­ra­tion, but using it for both is basi­cally a masochis­tic task branding-​wise. This is basi­cally my job. I do other things too, but for the most part I turn our very tal­ented designer’s visions into real­i­ties. As I stated pre­vi­ously, I manip­u­late the crap out of Share­Point. It is my domain (or so I keep telling myself) and I turn the sad excuse for a vanilla theme into some­thing worth look­ing at.

To be honest: it’s a pain. There is no way around that. I’ve had moments in my still-​new career where I’ve wanted to put my fist through the screen in frus­tra­tion from apply­ing a brand to the system. Now all that aside - I’m get­ting worked up here - It doesn’t have to be a night­mare. There are ways to cas­cade changes through­out a site with­out sac­ri­fic­ing a lamb. This is of course assum­ing you don’t have to also brand the admin­is­tra­tive side of the whole deal. The reason for this is fairly simple: SharePoint’s admin­is­tra­tive tem­plates are pow­ered from the file system, and not through their ghost­ing system.

I’m going to take a moment to clar­ify “Ghosting”. Share­Point oper­ates on a tem­plate basis. That means that when you use what is given by Share­Point, it all points to the same file. The second you go and cus­tomize that file, a new copy is cre­ated in the data­base, and so the orig­i­nal is left in tact. This is called ghost­ing. When­ever you cus­tomize a page, you are effec­tively “unghosting” the page. That is to say that you are no longer living from the pre­de­fined, but making your own file in the data­base. This is a great idea which can help save on server memory (Hard disk-​wise) and I totally agree with it.

So why the hell did Microsoft decide that all the admin­is­tra­tive pages be fueled by a totally dif­fer­ent system? They do indeed say it was pur­posely designed that way, but I call bull on that. What it sounds like to me is that they either ran out of time, or had the front-​end team and the back-​end team kept in dif­fer­ent build­ings, and told never to talk to one another under pain of death. As a result, when you decide you want to brand any­thing in the back end, you have three options:

1. Stick to manip­u­lat­ing the CSS. I wont get into the agony of explain­ing this in detail simply because it would take too long. The short of it is that the CORE.CSS that Share­Point uses is over 4000 lines by itself. Never mind the other eight they have for spe­cial instances. On top of that, you are lim­ited to all the ele­ments that are on the page. This is severely lim­it­ing and at the very least, painful. Find­ing what classes do what can be akin to pulling teeth out with a 9 iron.
2. Make a theme. I hate themes with a pas­sion. They were obvi­ously tacked on as an after­thought and it shows. Who’s the genius that fig­ured that reset­ting the server in order for any changes you made to the core theme folder to appear in your appli­ca­tions. fur­ther more, why in Gods name would you copy the files to the local site instead of ref­er­enc­ing them? That means that if there was a crit­i­cal error in your theme and you’ve already applied it to 60 sites, you now have to go into each of those sites and apply the default again and then apply the now-​fixed theme. I hope who­ever did that was fired.
3. Change the file-​system items. The short of this: Don’t. You can do that, you really can but I will guar­an­tee that this will even­tu­ally end in heart­break. What hap­pens when the updates roll out - and you know they will- and over­write your hard work? Now you have to go back and re-​work every­thing on the page. God only knows what’s changed. This is the minor half of the prob­lem though.

The only viable option is the first one. It sucks on levels all unto itself, how­ever since the second sucks when your site has more then one sub-​site is even worse, and the third option gen­er­ally leads to tears and wasted hours (been there, done that) it’s still the best option in the end.

“But Corey! Surely edit­ing the system files allows for the most cus­tomiza­tion and look/feel!” Absolutely right, and I won’t argue that point. I will argue that I’ll advo­cate against it when­ever pos­si­ble though. Here’s why:

The big prob­lem is that since you are edit­ing file-​system items, they’re shared. That’s right. If you have two totally unique site hosted on the same box, you’re going to notice that one of them is going to the admin­is­tra­tive look of the other site. This could be man­age­able if only admin­is­tra­tors saw it. The odds of this are that at some point you are going to go into a list. the master page for view­ing all lists is one of those shared items. It’s the same one used for brand­ing admin­is­tra­tive panels. See where I’m going with this? Heck, even if its just a col­lab­o­ra­tion site, that will still come up.

Cameron shows off the web­site “Hawai­ian Air­lines” which is a pretty nice site. Simple, to the point, and gets the job done. It’s also had every page cus­tomized (it appears to be that way to me, I could be wrong), and custom parts have obvi­ously played a rather large part of the site. I’m not bash­ing it in any way here, so please don’t mis­un­der­stand. What I’m saying is there was a lot of care put into making that site look the way it does, and I can only pray that they didn’t brand the back-​end with the same zeal as they did the front. If they did, i weep at their commitment.

What I’m get­ting at here is that though there are many ways to brand Share­Point, none of them are pain­less. The best route is trying to con­vince your client/boss/whoever is paying for the endeavor not to bother brand­ing the back-​end. This is a rare treat and you really shouldn’t go expect­ing it. Fail­ing that, I sug­gest going with option 1. It’s a pain in the ass but it’s the eas­i­est in the long run. You can also ease the pain by using tools like Fire­bug and the IE Devel­op­ment Tool­bar. If you have to go beyond that (which I have had to do in the past, and I am cer­tain I will be doing so in the future as well) then I wish you luck. You’ll need it.

The last point I’ll touch on is some­thing Mr. Moll covers in the last para­graph. The user expe­ri­ence in Vanilla MOSS 2007 is depress­ing some­times. Lim­i­ta­tions for no real reason, way too much user effort for min­i­mal gain, and don’t get me started on the many, many use­less steps to achieve cer­tain things. Wel­come to the other half of my job. I won’t get into this part too much, but despite my boss want­ing us to stay away from cus­tomiza­tion wher­ever pos­si­ble, I’ve noticed that to really take advan­tage of what SharePoint’s core abil­ity can do… well you need to be there to cus­tomize a solu­tion to access the power. Don’t get me wrong, Share­Point can do a lot of things, but as I have expe­ri­enced in the past it gen­er­ally makes the devel­op­ment team work- and work hard- for it.

And that’s my two cents on it.I like my job, I really do. I’ve learned what I deem to be ’snoot loads’ but it’s been a hard way get­ting here. I’m glad for it, but seri­ously: fist through the screen frus­trated some­times. Good luck people.