Friday, July 11, 2008
#
The Problem
A problem that I have often seen in the SharePoint world is the common request to have a consistent brand across your entire farm, but therein it is required to have minor variations of that brand for various sites within the farm. A frequent use case for this is the banner image/logo. Maybe the main landing page for the intranet has a certain logo, but as you start drilling into the sub-sites, the logo should change (or other brand variations). Logos for different departments like IT, HR, Sales, etc. are often requested. Now, typically inside the master page would the HTML image tags for these logos be found, however, it can be extremely cumbersome to maintain multiple instances of a given master page, especially when the differences between these master pages is small. Also, you as the developer may not know when when/where these variations need to be implemented, thus you need something intuitive for end users to be able to customize the look and feel of these sites. So what other options are available to you when you need these small brand variations in your SharePoint sites?
The Solution
A good solution for this is the use of delegate controls. You can place these controls within your master page, and at design time (via activating/deactivating features), replace them with actual controls that live in the LAYOUTS directory. What will be demonstrated in this post is using a feature to toggle the banner image on the SharePoint Site.
READ MORE...
Friday, June 27, 2008
#
My next two best practices that are a part of my 10 part series, are going to be combined in one post because they are closely related. What's more is that I've already blogged about them, so it doesn't make sense to labor over something twice.
These two best practices are detailed out in my post titled:
How to Effectively Manage your "12 Hive" SharePoint Customizations and Deployments (Part 1 of 2): Keeping your Developers Honest and your Investment Secure with Source Safe
In that post, I discuss the prevalent bad practice of editing SharePoint's files directly within the 12 Hive. Bad! Bad! Bad! Don't do it! If you do, you'll run into all kinds of issues like your customizations don't get backed up regularly, your developer's are overwriting each other's changes, and inconsistency and incomplete deployments across your web front ends. These issues are especially significant if you have a large team.
If you read through that post, you're certain identify two best practices therein. One, never make changes directly to the 12 Hive on the file system, and two, make sure all 12 Hive customizations are in source control in a way that requires developers to use it.
Thanks! And stay tuned, we’re only half way through my top 10 list!
Phil
[cross posted from http://philwicklund.com]
Wednesday, June 18, 2008
#
Many hoped that version three (V3) of Windows SharePoint Services (WSS) would help bring companies closer to compliance with Sarbanes Oxley (SOX) and/or the Health Insurance Portability and Accountability Act (HIPAA). I know from personal experience that my hopes were quite high when WSS V3 released, because I had worked with several organizations on the version two (V2) platform, and these organizations were enduring through pain because of their need to be mindful of such ordinances that would have an impact on SharePoint intranets. In fact, just the idea of a companywide collaboration tool sent most security departments down a path of fear and much concern. As you all now know, the c# statement “if (SharePoint == Compliant)” seems not likely to return “true” at any near point in the future. However, I did come up with a solution that proved very successful for one organization. It’s no silver bullet, but it is a step in the right direction nevertheless.
READ MORE...
[cross posted from http://philwicklund.com]
This next best practice in my top 10 list is definitely a matter of opinion on my part. The best practice revolves around SharePoint themes, and my inability to understand how they can be a benefit to someone. The reason why I struggle to see the value with themes is that every company that I have ever consulted for has always wanted to have their brand consistently applied throughout their entire farm. In their case, themes propose a problem because any end user that has full control anywhere can apply a theme on their site and in effect change mess with the company’s brand. Now I am fully aware that not all companies, especially small ones, are always terribly nit-picky about their brand. However, I do feel confident that from what I’ve seen, most are. Most companies desire a consistent and professional experience for their end users. I’m not a usability expert by any means, but my guess is that variation in the look and feel on an intranet cause more confusion that it does excitement and pleasure. Whenever I bring up the concept of themes to various organizations they all almost unanimously ask how to disable them even before I can tell them that it is even an option.
READ MORE...
[cross posted from http://philwicklund.com]