June 4, 2012

SharePoint Branding: Building vs. Styling

As part of my early efforts to master SharePoint branding techniques, I've set out to build various UI elements which can provide a more interactive experience and also maximize usage of the "above-the-fold" real estate on a web page. I'll be posting in detail on some of these in the future, but first wanted to highlight two different philosophies I've seen regarding how to create such elements.

While researching what others have done to create similar UI enhancements (accordions, tabs, rotators, etc.) I noticed that there are two general approaches being taken. The first and seemingly most popular, is what I'll term "building" - basically using jQuery to write your own HTML code, remove all of the SharePoint-generated HTML, and then extracting the "meat" of a web part (the actual visible content) and plugging it into your custom HTML. This is what the wonderful Kyle Schaeffer does with his WP Tabify solution.

The other approach is "styling," in which you leave the SharePoint-generated HTML as it is and rely solely on CSS and a bit of jQuery to change how that HTML is displayed on the page. This is the approach I strongly prefer, and (as you'll see) took with my accordion-style control. I leave all of the styling to CSS (this is why CSS exists!) and only use jQuery to toggle a web part when it's clicked. The HTML on the page is identical to what you get out of the box save for a class or two I add to indicate which web parts are part of the accordion.

While neither approach is truly right or wrong, I believe the "styling" method is a better best practice because it leaves everything generated by SharePoint intact, and you don't have HTML being generated in multiple pages, which can cause trouble when trying debug or maintain your code. The thought of wiping out the SharePoint code and replacing it with your own simplified HTML can certainly be appealing, and many would consider this practical when compared with having to overcome some of the intricacies of SharePoint, but I consider this in a way to be "the easy way out." I believe that learning to live and work with the standard SharePoint-generated code will serve me better in the long run.

I haven't seen this discussed anywhere else before, but am very interested to hear the thoughts of others. Please chime in with your comments!

No comments:

Post a Comment