MOSS Intranet Portal Branding Lessons Learned 1: Omissions & Test Results
We've spent the past four days doing user acceptance and regression testing on our branding, and I've found a couple of essential additions. Expect more as the testing wraps up over the next week or two:
- Branding the "Operation in Progress" Page. Another GIF you may want to replace is GEARS_AN.GIF if you need to adhere to strict color/look & feel guidelines.
- Templatepick.aspx. Users generally only see this one if they're creating meeting workspaces from calendar events. But if they do... it inherits from application.master, which seems a strange choice, since there's no site (and therefore no theme) yet when you're hitting this page. We haven't fixed this one yet, but I'm thinking the best way to go is to follow Heather Solomon's advice and embed the necessary styles directly in the page (following KB944105 or using an HttpModule redirect, of course), or re-master it with something a little more like simple.master
- Site Content & Structure Page (LAYOUTS/sitemanager.aspx). This page doesn't use any master page... if you want to brand it, you'll have to do so by direct customization (using a supported method like the KB944105 methods or a redirect via an HttpModule). Interestingly, this page does NOT include the <SharePoint:CssLink/> like all the other pages accessed via the Site Settings page... haven't figured out why yet, but I'll let you know when I do...
- HttpModule applicability. This should also work for the other virtual dirs like _controltemplates, not just _layouts. You'd definitely want to test this idea first - I've only used the KB944105 methods for customizing CONTROLTEMPLATES files in my sandbox, as we didn't need to make any changes in my customer's environment.
- BrandingUpdate app gotchas. We ran into two issues when installing the branding on a number of existing test sites:
- Site locks. Sites that are locked as no access or read-only can't be updated. Branding updates to these sites will fail, since you can't modify them. :)
- "Apply Themes" permission. I thought it'd be clever to disallow users from changing themes in addition to applying the new custom theme (you do this through Central Admin > Application Management > Site Permissions for Web App). This is a disaster - it prevents BrandingUpdate from changing the theme on existing sites, AND it prevents site owners from firing off the theme change on the receiver assembly when they create new sites. New approach: leave this permission turned on, but hide all the OOTB themes in SPTHEMES.XML. Users can select from a grand total of exactly ONE theme. :)
- More reasons to avoid use of ISAPI filters. Many thanks to my MCS coworker Suman for reminding me of my need to start studying IIS7... check out this article on how you can do a lot more with managed code to extend IIS7 than you could with IIS6: http://www.iis.net/articles/view.aspx/IIS7/Extending-IIS7/Developing-a-Module-using--NET/Developing-a-Module-using--NET .
Also, I wanted to emphasize the near-inevitability of the need to customize the LAYOUTS components. There is no escape... ;) Here's a far-from-complete list of a few high-visibility components in the LAYOUTS directory that the most common role used in collaboration sites (Members) will have access to:
- Upload.aspx - Collaboration users have, on occasion, been known to upload a document or two. :)
- Subnew.aspx & MySubs.aspx (AKA the New Alert page and the My Alerts page) - Extensively used, especially by teams led by productivity nuts.
- Viewlsts.aspx - this is used for the "Documents", "Lists", etc. pages in sites.
- Recyclebin.aspx - Perhaps the most requested enhancement from SPS2003/WSSv2.. A few folks might use it. :)
- Userdisp.aspx - Used when somebody wants to see user details for themselves or another user (i.e. when clicking on a user name in a "Modified By" field).
Take a few minutes to see what Visitors have access to and you'll get a smaller list, but enough to cause a jarring user experience if you've done anything more than modify the theme. And don't forget this big one... If you're deploying personal sites - everybody's a site collection admin and sees all the LAYOUTS pages.