The Pains of Altering the SharePoint UI

Hirsch’s Brand­ing Effort

I was recently tagged to “brand” a Share­Point instal­la­tion for Hirsch Pipe & Sup­ply Co.  I knew it would be an inter­est­ing chal­lenge, but I had no idea how bad it truly would be.

Share­Point is built on ASP.NET 2.0 which I had worked with in my pre­vi­ous job. I found ASP.NET very pow­er­ful and flex­i­ble. Mas­ter pages, App_Themes, CSS Friendly Adapters, and more made work­ing on ASP.NET inter­faces rel­a­tively pain­less.  Know­ing that Share­Point uti­lized mas­ter pages I thought it would be much eas­ier than it was.  How­ever, it turned out to not be the case.

The Default Mas­ter Page

I was imme­di­ately struck by the mess that is the default mas­ter page.  The mas­ter page is laid out with, of course, tables which is rem­i­nis­cent 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 eas­ier right?  No.  It turns out that Share­Point only uses one stan­dard ASP.NET con­trol (the nav­i­ga­tion con­trol), and the rest are Share­Point spe­cific “del­e­gate” con­trols which made lay­outs with CSS dif­fi­cult.  These are of course stored on the file sys­tem, and the only way to edit them is to cre­ate painful fea­tures.  It looked as though I was stuck with exten­sive tables for much of the layout.

When I did yank out much of the table lay­outs it only opened up a headache down the road.  It was actu­ally more painful to try and lay­out it with CSS then just stick­ing with the table lay­outs.  What made it dif­fi­cult are the exten­sive nuances in the Share­Point inter­face that are depen­dent on oth­ers.  For instance, I would lay it out in CSS, but when I went to edit the page to add web parts every­thing went awry due to depen­den­cies on exten­sive tables for lay­out.  I was able to lay out the major­ity of the default mas­ter page with CSS, but I ended up revert­ing to tables for the main con­tent area due to pain after pain. I did go with Heather Solomon’s min­i­mal base mas­ter page for pub­lish­ing sites which was a bet­ter start then I had.

The CSS

The fun doesn’t stop there.  Share­Point has a core stylesheet that is over 4,000 lines long.  I’ve dealt with more styles in one shot, but look­ing at the stylesheet you would think a 10th grader cre­ated them.  There is a lack of short­hand, units of mea­sure, and exten­sive IE pro­pri­etary styles.  Add onto the fact there are no com­ments in the stylesheet it is absolutely use­less to attempt to decode it.  You also can’t sim­ply remove the core styles; well, you could, but it’s another headache that is ulti­mately not worth tack­ling.  It’s again eas­ier to deal with the bad then try to make it better.

Share­Point does allow you to spec­ify an alter­nate stylesheet which does, thank­fully, get ren­dered after the core styles.  The cas­cade becomes your best friend in alter­ing the styles.  You’ll also notice the “clas­si­tis” that abounds in the mas­ter page and core styles.  They all have a pre­fix of ms– which is unneeded and unhelp­ful.  I wasn’t sur­prised to find a lack of advanced CSS 2 selec­tors due to the pres­sure to sup­port IE 6, but they are hardly any descen­dant selec­tors which would dras­ti­cally decrease the amount of classes in the markup.

The JavaScript

I know Microsoft is now sup­port­ing jQuery which we can only hope will reduce the amount of “obtru­sive” JavaScript through the site.  It reminds me of how I wrote JavaScript back in the day.  Attempt­ing to decode the core JavaScript is a puz­zle I didn’t even attempt.  You are once again forced to use pro­pri­etary JavaScript instead of tak­ing it on to write it any bet­ter.  If they did abstract the obtru­sive JavaScript it would dras­ti­cally decrease the com­plex­ity of the markup sent to the browser. I did end up using jQuery to set the size of cer­tain divs, and I also attempted to clone() and append() DOM ele­ments but it proved fruitless.

Hope for Share­Point vNext

I hope, first that I never have to alter the Share­Point UI again, but that the next ver­sion of Share­Point will con­struct a bet­ter default UI with the fol­low­ing changes.

1. Use CSS for layouts.
2. Ditch the del­e­gate con­trols to use more of the stan­dard ASP.NET con­trols (or at least improve them).
3. Use a well-commented core CSS file with advanced selec­tors to elim­i­nate the need for classes.
4. Switch to an unob­tru­sive JavaScript model.
5. An increased focus on acces­si­bil­ity for public-facing sites.