In Spite of Its ASP.NET 2.0 Window Dressing, SharePoint Still Suffering from the Worst of the 1990s Web

Here, as we end the year 2008, Microsoft SharePoint is still suffering from Web design horrors from the 1990s. Both SharePoint products, WSS and MOSS, are preoccupied with data-management infrastructure issues that make data-intensive developers like me show our sincere respect. However, Microsoft still fails violently in the visual design facilities for customizing SharePoint.

What this means is that I cannot in a few easy steps customize the actual “look” and the actual “feel” of SharePoint. This apparently “trivial” issue is actually a huge showstopper in the real world of superficial, non-technical managers still running most of the world. As I developer/designer, what I need to do is quickly make any SharePoint installation look like anything I want in order to ‘fool’ management into using SharePoint.

Currently, I am aware of three known ways to customize SharePoint:

1. Risk destroying your entire SharePoint installation by adding your custom Theme.
2. Customize only a subset of your Site by editing the default.master Master Page in SharePoint Designer 2007.
3. Build your own “extended” read-only Web that is fed by data from an ‘unmolested’ SharePoint site.Option #3 is the most responsible to me—but this is exactly the option most “business leaders” would avoid investing in proactively. So, now, I will spend the rest of this writ recording why options #1 and #2 suck.

SharePoint customization options #1 and #2 both involve changing SharePoint files on the file system. For those of you who saw, “Customizing a Windows SharePoint Services V3 site with the SharePoint Designer 2007,” you should know that SharePoint Designer can change Master Pages in the content database—but you will be tempted to change application.master, which is located on disk in C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\LAYOUTS. This temptation is so strong that a Microsoft Employee, Steve Caravajal (a co-author of SharePoint 2007 and Office Development Expert Solutions), in his MSDN Blog post, “SharePoint Branding and Application.Master,” answers “a number of folks”:

Q: How can I edit application.master using SharePoint Designer?

A: Short answer, don’t do it. Unlike default.master and other master pages in SharePoint sites, the application.master is not exposed to SharePoint Designer by default. This is for VERY good reason. Application.master lives in the _layouts directory and this location is not displayed when editing a site using SPD. If you navigate to the _layouts directory to edit and view the application.master you’ll find that you can’t view it in design mode. This should be a hint that maybe you shouldn’t be doing it. Editing pages in this folder will likely result in corruption so DON’T do it. I know, I know….if you’re like me you’re probably opening designer to do this right now because you were told not to…….don’t say you weren’t warned.

Steve Caravajal is probably one of only a handful of Microsoft Employees that would admit that “…a master page called default.master is created and added to the Master Page Gallery. This page defines the chrome of the page and serves as the foundation for customization using SPD [SharePoint Designer] to achieve a branded site. Unfortunately, default.master is not the master page for all pages in the site.” This is extremely important information that can save professionals who value their time hours of fun.

Now more fun: even when you are vendor-compliant and editing default.master in SharePoint Designer you will be tempted to add more master pages to the Site content database. This temptation gets very strong after reading Microsoft’s SharePoint MVP, Heather Solomon, her article, “Minimal or Base Master Pages,” and downloading her “Base Master Page for Collaboration Sites and WSS Sites.” Even Microsoft tempts us with “How to: Create a Minimal Master Page.”

The problem is that you could end up not being able to delete one of your master pages because you are unable to unset it as the default or custom Master. In SharePoint Designer, you might see an error message like, “One of the selected files cannot be deleted because one of the files is currently set as the default or custom Master page for the Web site.” Should you get the idea that you can delete the Master page from inside the SharePoint site itself, you should have the same problem Eric Kraus solved in MOSS but the command he used is unavailable in WSS.

Okay. Okay. Let’s assume you are having no problems customizing SharePoint to your satisfaction. Let’s go further and grant you the super-power of customizing SharePoint files on disk without fear of Microsoft corrupting your changes with a Service Pack or simply by running the SharePoint Products and Technologies Configuration Wizard. Let me direct you to the bottom line as described by a SharePoint consultant in “The Pains of Altering the SharePoint UI”:

I was immediately struck by the mess that is the default master page. The master page is laid out with, of course, tables which is reminiscent of why Microsoft is such a joke in the designer world. Well, I decided to rip out the tables, and surely that would make it easier right? No. It turns out that SharePoint only uses one standard ASP.NET control (the navigation control), and the rest are SharePoint specific “delegate” controls which made layouts with CSS difficult. These are of course stored on the file system, and the only way to edit them is to create painful features. It looked as though I was stuck with extensive tables for much of the layout.

…

The fun doesn’t stop there. SharePoint has a core stylesheet that is over 4,000 lines long. I’ve dealt with more styles in one shot, but looking at the stylesheet you would think a 10th grader created them. There is a lack of shorthand, units of measure, and extensive IE proprietary styles. Add onto the fact there are no comments in the stylesheet it is absolutely useless to attempt to decode it. You also can’t simply remove the core styles; well, you could, but it’s another headache that is ultimately not worth tackling. It’s again easier to deal with the bad then try to make it better.

It would irresponsible to use SharePoint as a public-facing Web presence or in any situation when precise visual design is required. Now that I am finished shaking a stick at SharePoint, I can now move on to its strengths: SharePoint facilitates the sharing of data with an (relatively) easy to use Web interface. As of today (and probably for a few years), it is an error to regard this Web interface as anything else other than a user-friendly data entry point. Both MOSS and WSS provide RSS syndication for its default data collections that can feed third-party Web front-ends. This RSS feature alone should make SharePoint the number one choice for the Microsoft Office enterprise needing to ‘ship’ their data to third parties. By the end of 2009, I should have stable and time-tested solutions for using SharePoint ‘data islands’ as tiered hubs for my custom Web sites.

rasx()