Do MOSS Variations really SUCK?
I've been using the MOSS Variations feature for quite some time now. In that time there has been a lot of comment on the web detailing it's shortcomings. The first major comment I remember was Jeremy Jamesons 'Dumping MOSS Variations'. Your favourite search engine will turn it up easily if you haven't read it. Positive comment on Variations have been rare, and largely focussing on some major bugs that shipped with the first release.
So, what's my opinion on Variations? I've been using them long enough in anger to have a view!
Well, first I'd say it's a very powerful feature and that it's good to have at ones disposal. One of the core business problems it contributes to solving is that of delivering multinational Web Content. Delivering web content in multiple languages with localisation of that content is a doozy of a business problem. This technology provides a framework for solving that problem. You still have to expend a lot of sweat and tears to get it right of course. It doesn't translate and localise the content for you!
The second major promise of Variations is that they allow multiple sites to be created and styled such that they suit different mobile devices. There's a lot I could say about this, but it isn't going to get much specific attention in this article.
I was caught up in a bit of hubris after the release of MOSS SP1, as several big issues with variations were fixed. A particular issue was how a Source Variation page could be based on a custom content type, but when Target Variations were created their pages were all based on the OOTB Content Type 'Page'. In other words it was working great until you did some basic customisation on your content types, then suddenly your content went decidedly wobbly! Anyway, finding that fixed after SP1 put me in a pretty good mood. I'd had to write some custom tooling to fix it prior to that. I found myself stating on a Sharepoint forum that Variations were about ready for the Enterprise to trust.
At the time I made that statement, there were caveats. The Enterprise needed to know about and avoid certain foibles of Variations or there would be problems. The thing is, since then my foible list has grown. I'm actually getting a little sick of MOSS Variations.
I expected that the Infrastructure Updates released June 2008 would help Variations function better. Alas from my own personal experience they haven't helped a bit. I'm going to go into a few issues I've faced, and you can see if they would be acceptable to your Enterprise. This is in no way an exhaustive list, and others may have documented them independently. These issues may not happen on all installs either, but that's another story.
1. Variations Get Trashed Easily
OK. Picture the scene - Your Variations are working fine, but a new country needs a variation creating. You create a Variation label and create hierarchies. Halfway through the creation fails, leaving you with a half finished site structure and missing content pages.
A good solution seems to be to delete what was created and have a go at creating the hierarchy again right? OK. Delete the unfinished site structure for the new country. Now go to the Variation Labels screen and delete the label in question. The screen chugs away for way too long. When you view Site Content and structure you don't have any Variations anymore, just unrelated Sharepoint sites. The Relationships List, the heart of how Variations work has just had loads of entries randomly deleted.
I can recreate this error on more than one environment, and I know other Sharepoint Consultants who've seen it too. Should a major issue like this still be in the product? I think not. [N.B. Microsoft contacted me in April 2009 after seeing this article and were able to reproduce the issue. Consider them on the case.]
With the Relationships List being so fragile, Microsoft will have created a utility to fix it right? Nope. That's up to you. Gary Lapointe has written a custom stsadm command to do it, but it doesn't work for my install I'm afraid. Time for a community tool methinks. [N.B. Tim Dobrinski wrote just such a community tool which is available at www.codeplex.com/variationseditor]
2. Navigation not propagated 'By Design'
You create your Source Variation and work on getting it just right. This involves some hefty customisation of how the navigation looks and what it shows. You create your Target Country Variations. Something is wrong here. The Navigation has come out as the default. Where are your customisations??
This is by design we're told. Your Target Variations may well not want the same Navigation layout/settings as your Target Variation. Reasonable huh? Well, actually I see this as a cop-out. I might not want the same navigation settings, but then I might. Since I'm going to the trouble of duplicating my sites to new country specific copies, maybe I want them to look the same too? I'd like the option of propagating my Navigation settings to my Target Variations or not please. 'By Design' means we didn't bother, we didn't have enough resource to get it together in time for shipping MOSS, but we do have an excuse if you'd like to hear it.
Back to custom tooling if you want to do this. Nearest I've seen is by a posting by an Avenade employee on Codeplex here http://www.codeproject.com/KB/spnav.aspx
3. List Items not propagated to Target Variations
Another 'By Design' issue, which I put down to lack of resource when they put Variations together. Only Pages are propagated to Target Variations. Documents in your Document Libraries (for example) are not. Clients have a (not unreasonable) expectation that this will come OOTB. It doesn't. I myself have written some custom code to push them out, which you can find here https://jamiemcallister.com/post/Propagating-Document-Library-Items-In-MOSS-Variations-(in-the-same-way-as-Pages).aspx.
As a side issue, should you want to push your documents etc down to Target Variations, there's also no support for the Language Translation of those documents. None. Which brings me onto....
4. Tools for allowing Language Translation are awful
There's a good chance that your Variations install is going to need site content translated and localised for some or all of your Target Variations. This is such a key feature of what Variations are about that it will be well supported (you assume).
Microsoft states that Content can be translated in the following ways;
Give your translators Edit access to the content in your Target Variations. They can use the web editing tools to translate it.
Or, in Site Content and Structure, open the action menu for your Target Variation and Export Variation (having selected your Translatable Columns in settings first).
Well, I've not yet found an organisation that wants to do option 1. Nor have I found a Translation agency that's keen either. You could make this work, but that sort of access to outsiders has the Risk Managers getting nervous.
The Export (and Import!) Variation option sounds neat. In practice, the XML you get is pretty unfriendly. It's also packaged in a CAB file (with a different file extension), which means it's a fiddle to package it back up for Import to your variation. I also have systems where the Import never works.
The fiddly format means some custom development around this is needed. Also the ad hoc nature of the content export doesn't suit all business problems. Some people want their pages sent for translation as soon as they're pushed out as a minor draft to the target.
If you want it the way you want it, you're heavily into custom Workflow etc. It should be nicer than this.
5. Legacy issues continue to cause problems
Despite the Service Pack and Infrastructure Update, problems that existed early on continue to blight this project. Without custom tooling trawling through the Relationships List and god knows whatever else that is causing issues, our Variations continue to be brittle.
As an example - whenever we rename the URL of a Source Variation (using the UI quite properly) all the Variation links get broken. Site Collections created post SP1 are fine, but we still get this issue having all updates installed.
OK. That was just a brief tour through the little shop of horrors. There's more, but who wants to read an article like this forever?
So, what is my opinion? Variations are an example of a grand vision. They aim to help solve the problems of multinational web content management, and provide Sharepoints answer to Mobile Web Content to boot. If your Enterprise needs that functionality, such a powerful feature OOTB cannot be ignored. However, the caveats are major indeed. You need a specialist on the case, policing what happens to your variations so that your Production environment isn't broken by users innocently performing seemingly legitimate actions via the UI. That Specialist needs to research all the real world experience posted by users on the web, because there's not a jot of official documentation about these problems. Your variations specialist needs to proactively guide the Enterprise to avoid tripping up.
You also need to gather the custom tooling that’s been released by the community, and write plenty of your own. This will (e.g.) limit the number of times you get your poor office intern to make navigation changes by hand to several thousand sites and subsites in your variation hierarchy.
So, bottom line time. Variations are an example of a grand vision... BUT lack of resource (I suspect) and lack of priority during the development of MOSS 2007 has left Variations half baked, bugged, and lacking many of the features you want in the real world.
The community is working on tools to remedy some of this. Microsoft is hopefully listening. I can only have hope the next incarnation of Sharepoint includes a more rounded solution to the business problems Variations try to address. I also hope they call that solution something other than Variations. Too many memories associated with that name if you know what I mean!