fallenrogue.com

Working in SharePoint 2007 (Windows SharePoint Service v3 and/or Microsoft Office SharePoint Server 2007) on a daily basis is an invigorating challenge to say the least. Not because the platform is difficult but rather dispelling the mystery of customizing and developing on it to others on your team. If people are not interested in understanding a platform, getting them to enjoy working on that platform is difficult. If you’re used to PHP apps or dot net nuke or mephisto or wordpress or any other number of popular platforms, then asking you to get down with SharePoint is a tall order to swallow. Compound that with the fact that you’re largely working with a product that had many problems in its previous versions and it’s reputation for being unpleasant for developers and designers was cemented in stone. Many professionals decided that it was not a viable option for them without truly evaluating it. ISVs did not do much better in terms of providing best practices and optimism for the platform when their solutions were hobbled together by disparate technologies that seemed to only solidify the notion that the only way to bend SharePoint to your will was to go around it completely (see Coveo Search for WSS v2; a product that uses the WSS v2 SOAP services to index all WSS content…). There was a lot of negative press surrounding WSS v2 and SPS (SharePoint Portal Server) 2003 and much of it was justified.

So when WSS v3 came around, Microsoft was excited to report that the entire system had been reborn in ASP.NET 2.0 (with some help from the new bits and pieces of .NET 3.0). To say that SharePoint had an uphill battle to prove its worth to the development/design community was to put it lightly. Not only did SharePoint have a reputation for being unfriendly to developers but now it was claiming that it was simply ASP.NET + features = SharePoint. Microsoft has made promises in the past that were not made good on and given the previous version’s pain points many have had issue with re-evaluating SharePoint today.

Not making things any easier would be articles like Cameron Moll’s article condemning MOSS’s ability to be customized by a designer. The article is well written and thought out by Cameron (a trait I’ve come to expect from his blog) but is riddled with inexperience. Certainly not inexperience as a designer, he’s a recognized expert in his field, but rather as a SharePoint developer/designer. I have to sigh at yet another frustrated artist who’s limited knowledge of the platform has driven him to rant and derail public perception of a platform which is not given credit for its extensibility and is evaluated on an extremely narrow scale.

I want to respond to Cameron’s article here not as a means to begin a flame war but rather as a means to dispel some of the dev/des FUD surrounding SharePoint as a development platform. It should also be noted for the sake of full disclosure that I’m currently making a living developing advanced enterprise level solutions on WSS v3 and MOSS 2007 and believe in the platform enough to be actively in talks to write a book on the subject. These points are in direct reference to Cameron’s points and I encourage readers to keep this conversation going, so long as it’s a conversation and not some dissertation on your utter disappointment in your CTO for choosing SharePoint over Drupal. We can compare and contrast feature sets in another post. For now… to unlearn what we have learned…

In my talk at CodeMash this year, I focused on doing much the same thing. Dispelling the notion that SharePoint is an island that is unchangeable by developers and designers. Yes, Visual Studio.NET 2003 (another Microsoft product) re-wrote all of your HTML markup in the way that it saw fit (which made us all want to vomit blood) but VS.NET 2005 remedied that. You can’t continue to hold a grudge unless you’re using VS.NET 2003, in which case, you’ve been warned, a best practice exists and you’re welcome to follow it and retain your pretty markup for “switch to the designer and drag and drop” at your own peril. The choice is up to you, just like in SharePoint development and customization. You can hold SharePoint accountable for the sins of its father but you’d doing the son (and your project) a disservice.

Let’s go back to Cameron Moll’s post to better understand the problem set and if there is truly and impossible chasm that cannot be crossed here.

"SharePoint can be used primarily as a CMS or primarily as a
collaboration tool. However, try to use it as both in a single 
implementation and you’ll entangle yourself in a strenuous skinning effort." 

Go on…

"At its core, SharePoint is a robust content management
system (CMS). Just about any flavor of web content can 
be built and maintained by it — public or internal, small scale or large." 

This is true but let me clarify. MOSS 2007 provides CMS features through the Publishing Portal feature set; a value add built upon WSS v3’s infrastructure (all MOSS value adds are features that extend WSS). The feature set is expansive and highly customizable. While it can be leveraged by users of any size, it’s cost, both from a hardware as well as licensing standpoint suggest that it’s a solution for owners with large scale CMS needs. Continue, Cameron…

"Complementary to its core, SharePoint is a massive collaboration 
tool. It can facilitate the many activities common to any workplace 
... have many site owners accessing admin screens." 

Ok… this is where we begin to see that the problems that Mr. Moll faces are not entirely in sync with a traditional web application. SharePoint’s software architecture and flow is unique to SharePoint and shares more in common with complex distributed systems than a single web application for CMS or Collaboration. There is a rhyme and reason to most design choices (I say most because some are legitimate pitfalls held over for backward compatibility) but I’ll let Cameron make his point before I continue.

"Any changes made to Master Pages (i.e. templates for 
the CMS) will not carry over to the admin screens." 

OK. Here we go. This is true. ...to a point. A point that Cameron soon makes…

"in the collaboration scenario, nearly any user can, and will, 
switch between published screens and admin screens to 
complete tasks. Because your skinning won’t be reflected in 
the admin, what should otherwise be a continuous visual flow 
for users instead becomes a jarring transition from your beautiful 
theme to SharePoint’s vanilla theme and back again." 

Again… This is true. ...to a point. Cameron then goes on to mention that…

"...led to an unsuccessful skinning effort that was eventually 
scrapped. This inevitably begs the question: Is SharePoint 
completely unskinnable when used as a collaboration tool? 
No. It’s still possible to skin the interface using CSS overrides, 
but not to the extent which we were customizing it." 

Well, for reasons that only someone from the product team can answer, all pages in the LAYOUTS directory in the 12 Hive (SysRoot\Program Files\Common Files\Microsoft Shared\web server extension\12) use their own master page – application.master. Layouts pages execute in a different fashion that site pages (buy me a beer and I’ll tell you all the intricate details of this process) and therefore certain global (or specific) tasks are performed from layouts (look at the url for all of the actions in site settings you’ll see _layouts in the url). Some of these tasks, like the ones found in site actions, are correctly located in this virtual directory but others like file upload seem misplaced there. This is the issue that Cameron is referring to. He, like many, don’t mind sending the admins to a differently branded area for admin tasks but when the beautiful theme that you worked so diligently to perfect is tossed away in many key sections of the user experience it can be jarring and downright unacceptable.

Well, there are 2 solutions to this problem which I will outline (and subsequently write articles to demonstrate implementation). First one must understand the exact role that master pages serve in asp.net. They are not “themes” in the traditional CMS lexicon but rather “layouts” pages that dictate the markup that is to be used when rendering elements to the page. Pages in layouts expect more elements (just like collaboration pages do) and therefore implement a different master page (application.master) than their site level (web or SPWeb level) counterparts. This doesn’t mean that they can’t. It just means that by default they don’t. So with this information, there are 2 possible solutions to the problem.

1. Backup application.master to something else, account for the additional layouts specific markup expectations in your default.master (or whatever.master) and provision that file to the layouts directory as application.master. Done. That’s it. you’ve done it. Now. It is worth noting that is this permanent and it’s possible (in fact, it’s probable) that in a future upgrade you’ll lose the application.master customizations. Then again, you can prepare for that and fix it as part of the upgrade.

2. The second solutions and the one I favor (and have implemented recently) is to craft a simple SharePoint Solution that installs an HttpModule to the Farm. This module will determine if the currently requested page is a: coming from layouts and b: from a site that has your feature for the admin master swap enabled. If it does… then in 1 line of glorious C# you can swap the master page to one of your choosing. The best part? It scales, it’s managed cleanly through admin sections and is future proof (or at least future compatible).

Yes. This is not documented clearly in the SDK but the use of application.master is and while the practice of theming asp.net is documented separately from SharePoint, it is documented both by the MSDN and in the blogosphere. It’s difficult to know why Cameron and most clients I’ve dealt with give up so easily on this concept but they do. I see SharePoint’s negative image in the world as well as it’s high barrier for entry when establishing an environment for development (Virtual Machine with Server 2k3, full WSS / MOSS installation running, VS.NET tools and various sdks) as the main reason hobbyists are not embracing the platform and subsequently not sharing their successes and creative solutions with the world. But that’s fodder for an IRC chat…

Back to Cameron…

"Lastly, and most importantly, my greatest concern for 
customizing SharePoint was the hope that I’d not only 
be able to paint the app but customize the interaction 
workflow, as well. Not a chance." 

Actually, there’s a large chance. Quite a large chance to be clear. In fact, there is no feature in WSS v3 that cannot be overridden and re-implemented by developers. Cameron’s “Sally” is having a problem changing the logo on her site and has to move heaven and earth just to find the url prior to going into the admin tool and pasting the url in the correct form. Yes. This is irritating. So, if you have a requirement to make it easier (e.g. you can’t call it a feature and training issue…) you can use the WSS v3 platform to solve it in relatively short order. Off the top of my head (and yes, I’ll consider a followup article to implement this concept) hijack the context menu for image files in her web and add a menu item that calls a layout page that changes the url of the site logo for her. Easy. Or! Event better! Create a new admin section altogether that provides a gallery of publicly available image across the entire farm (based on a search, perhaps?) and allow her to choose the one she wants while getting a nice preview of the changes about to be implemented in a cool iframe window. That would be rad! It’s also not impossible nor is it a profound development effort.

I want to leave you with this: I have been customizing WSS v3 since it’s RTM and there hasn’t been one task that I haven’t been able to perform. In fact, I’ve got someone of a reputation with my former employer, Cardinal Solutions, for saying “yeah, sure. That’s easy in SharePoint” when others had hit a wall. Turns out, I had already hit the wall, showed them a better way around and they were on their way. Now the team is teaching me all kinds of great things! In SharePoint, the approach usually required an understanding of the platform to help reveal the strongest path. While I don’t think that it’s always practical to “reinvent the wheel” for every design choice that was made in SharePoint, when you consider that it’s possible to do so without negatively impacting the future viability of the platform, that alone is a compelling argument for implementing it.