Incorporating Variation Concepts into Planning

Target site administrators do not have to accept everything that is sent to the targets. And the targets can still create their own unique content, even subsite structure. Here's a summary of some of the concepts central to understanding and using variations:

• Variations support unique security permissions Like any other subsites within a site collection, variation sites support broken security inheritance so that each site can be the root of unique security permissions, such as members or roles.

• Not just for languages There is a tendency to always think of languages when Variations are mentioned. That certainly is the default use, but perhaps for your organization Variations can present a solution to other concerns. Variations can provide multilingual sites, multidevice sites, and multibranded sites with equal ease, although you must manually configure some redirection logic in the anchor site welcome page.

• Pages must share content type, not layouts or master pages Sharing Master or Layout templates across variation labels would defeat the purpose of Variations. For content to be pushed from source to target, it must share a content type. If the target site does not have a content type defined in common with the source, you will see an error message similar to the following in the variation log:

  • "The variation system failed to pair up pages

  • http://portal.contoso.msft/ENU/News/Pages/Default.aspx and

  • http://portal.contoso.msft/JP/News/Pages/Default.aspx

  • because their Content Types do not match".

• Separate approval process The approval processes of all sites are respected by the process. The storage locations at the target should be configured so that the arrival of new content will automatically trigger a new workflow. However, in some scenarios, a workflow might not be required. For instance, if you are creating a variation simply to have a "cleaner" site for mobile users and no translation is involved, automatic publishing would be desired. If you were creating variations for your extranet or Internet site of some selected intranet content, perhaps no workflow is necessary.

• Target pages start with source page content The target pages start with the same content type and the same content in the same fields for the pages-they are just presented with different templates. Suppose that on the source site the page has a field control that displays corporate status reports from internal lists or databases and you do not want to display that on some target sites. Simple: do not put the field control on the master or layout page in the target site. The rest of the content will be displayed, but there is no presentation available to build or display the status reports.

• "Flag Control" chooses variation for user Here is the fun part! When the user hits the root site of the variation, information in the HTTP request header will identify certain characteristics of the browser, operating system, and user. One is the language of the browser. So if the "Flag Control" in the redirect page on the root site is set to identify language (because your variations are based on language), the request is redirected to the appropriate language site.

  The flag control does not have to be set to identify language; it can be any attribute of the browser or user. So, if the users are browsing from a Macintosh or Linux do you want to invest in a variation of your site that only supports their browsers? And if the user is browsing from his cell phone, maybe the stock ticker field control would not be a good implementation. Think about the possibilities.

• Hide variation sites in navigation By default, all variation sites will be displayed the Global and Current navigation field controls. However, the Site Collection administrator can choose to hide them in either or both locations in the Navigation settings page of Site Settings. Likewise, a link to the root of the variation hierarchy will be available for direct access by users who click on it in navigation, but it can be hidden just like the subsites. The root site can also be addressed by including the full path to a page that bypasses the variationroot.aspx, such as the original  default.aspx.

• No built-in translation tool Neither Windows SharePoint Services 3.0 nor Share-Point Server 2007 provide a translation service to translate text from one language to another. However, SharePoint Server 2007 does provide tools to assist you in managing the translation process. See the "Managing Translations" section later in this chapter for a discussion of those tools.