SharePoint Conference 2011– Good Reminder, Few Surprises

Microsoft wrapped up their SharePoint Conference 2011 on Thursday this week.  In attendance were some 7,600 people, all seemingly enthusiastic for the phenomenon that is SharePoint.  While there were few surprises, Microsoft did remind everyone why the platform is so popular.

If you’re interested in a complete review of the conference, check out my posts on the Real Story Group blog:

• SharePoint Conference 2011 day one
• SharePoint Conference 2011 final wrap up

It’s fair to say that we haven’t seen the crest of SharePoint popularity or growth.  Microsoft even made an out of character announcement regarding another SharePoint conference in 2012 being held in Las Vegas.  Two conferences in two years – sounds like something new may be announced.  Stay tuned!

Migrating your Content to SharePoint

Many clients want to take advantage of the on-premise or cloud-based power of SharePoint. However, many struggle with creating the ideal process to migrate their content. Questions like what steps are involved and how can you ensure success can be a challenge to answer without proper guidance. To assist our clients in making good decisions and to help ensure migration success, we’ve created a formalized migration process. 

If you’re interested in better understanding how to manage a content migration, read our Migrating your Content to SharePoint white paper or simply give us a ring.

Does Microsoft need a SharePoint App Store

Yes and no.  You see, its just not as easy as a black and white response.  You could argue that SharePoint needs an app store because there are far too many specific use cases for which it’s out of the box experience is ill suited.  However, SharePoint does ship with a number of “apps” (Microsoft calls them “Site Definitions”) that can satisfy relatively simple needs with little or no work.  The challenge is whether the out of the box archetypes like “team sites” or “document workspaces” in Foundation or “publishing portal” or “search center” in the Standard/Enterprise versions are sufficient; could Microsoft or a 3rd party effectively create additional, purpose-built archetypes to improve end user adoption and overall usage?

To illustrate this point, let’s suppose you need to create a web-based collaboration space to work on a document with a small team of people inside your company.  It’s actually quite simple to use what SharePoint provides immediately. You’d likely start with a “document workspace” (shown in Figure 1).  The workspace can be provisioned while you’re reviewing the document from within Microsoft Word (or another Office product) or from SharePoint’s web-based interface. You can even invite your colleagues from the same interface (within Word) or, again, through the web interface, without any trouble. Once the workspace is provisioned, you’d automatically have a library to store the document (and the document would already be waiting there for you and your team members). In addition, the workspace would show who was participating in the workspace through the members list (with direct links to their individual profile by clicking on their names), a task list to assign & track responsibilities, an announcements function to communicate with your team and a discussion thread for working exploring topics relevant to the document. All of these features are packaged up and provisioned automatically. So what’s the problem?

Figure 1 – Typical Document Workspace in SharePoint 2010

What happens when you want to create a quick, web-based file sharing site and “invite” others inside or outside of your organization?  You’ll quickly find the standard SharePoint site definitions fall a bit short.  SharePoint does have features that support file sharing through sites and libraries; users could even access and edit those files through Office on your desktop or use Office web app through a browser.  There’s also the possibility to let non-employees access the site.  Unfortunately, the collection of features, along with the requisite security model are not available in a shipped SharePoint site definition.   As a result, an end user would have to start with an existing site definition, like a “blank site,” then add a combination of lists and libraries to create the environment they want.  Next, they would grant internal participants access to the site, applying library/list-specific or document-level permissions as necessary.  If the users aren’t in Active Directory (like the non-employees), SharePoint allows you to use SQL Membership to store those non-employee IDs in a SQL database.  However,the non-AD authentication configuration work requires you to manipulate machine-level settings in an XML configuration file, create databases on a SQL server and grant specific application pool identities access to the database.  Most of this effort is typically outside the expertise of an average end user; even if they weren’t, because of the changes necessary to the farm, most administrators wouldn’t want end users changing these settings.

Ultimately, there’s little evidence that SharePoint is wholly unsuited for collaboration needs inside the enterprise.  If fact, you could argue that SharePoint, given its breadth of functionality, has no equal in the collaboration space.  However, there are well-documented challenges in creating you own applications on SharePoint.  Remember that SharePoint, by Microsoft’s own admission, is a platform and not a product.  This means companies are either left developing their own applications or buying from a 3rd party.  This begs the question: should Microsoft devote some of their R&D budget to developing applications on top of SharePoint?  Further, wouldn’t building applications on SharePoint, in fact, be more useful to a greater number of people than adding new features to the platform?  This approach would certainly go a long way to blunt attempts by companies like Huddle, 37 Signals, Box.NET, HyperOffice and others to discredit SharePoint for purpose-build solutions.  Microsoft has demonstrated, historically, their willingness to drive down this path with new site definitions like the “Fab 40.”  Unfortunately, some of these applications were just silly (like the Baseball Team management portal) and they never followed-up with equivalents on SharePoint 2010.

If you’re searching for specific applications on SharePoint today, you’ll need to look to the myriad of 3rd party vendors like Bamboo Solutions, Coras Works, SharePoint Solutions or the app store concept from the larger SharePoint community called Sharevolution.  Unlike Apple and Google (or even Microsoft’s own online store for everything from Windows to XBox to non-Microsoft hardware), Microsoft has not created that one-stop-shop to find specific solutions built on SharePoint.  One can only hope that, in the future, Microsoft does something more creative than simply redirecting the domain sharepointapps.com back to the SharePoint product site on Microsoft.com. 

Technology Just Gets in the Way

The idea that most folks in IT, and even some  on the non-IT side, spend way too much time worrying, thinking and generally kvetching about technology is almost passé these days – everyone knows it true, but they still get wrapped up anyway.  Incredibly, most people tend to see the process of solving business challenges exclusively through the lens of what a specific tool can solve.  This condition is never more obvious than when firms start discussing SharePoint. 

Inevitably, there are discussions that start out well – focused on business needs and what users have to accomplish.  Then, for some strange reason, things go seriously awry.  In the words of Ace Ventura, Pet Detective – “Gee, Chuck, the date started out good. Just before we got to the party she seemed to tense up.”   Perfectly rational people start discussing if SharePoint’s wiki has sufficient functionality, can the firm really use the out of the box search, are the records management features robust enough for the entire enterprise?  All of these questions are very reasonable to ask if two conditions have already been met: 1) you know what problems you’re trying to solve and 2) you have well-defined goals and corresponding metrics to measure if you’ve successfully met those goals (notice I avoided using the word “requirements”).  Unfortunately, most organizations fail to satisfy either condition before pushing head long into a “how do we implement SharePoint” discussion.

If you regularly read this blog, you’ll know that I’ve already said SharePoint is not the answer.  However, this is true of any technology if you haven’t clearly defined what you want to accomplish.  No matter what tools you might be considering, you must be clear about what you’re trying to accomplish AND ensure that your goals are achievable.

Published on the Word of Pie blog, there’s a great post about taking a break from ECM that illustrates this point perfectly (though through the broader lens of ECM).  In the post, Laurence Hart (@piewords) describes all of the challenges with ECM implementations.  He does such a terrific job that I’ll end this post with only one bit of advice; read his post.

Education and Training are Required

The title of this blog is a bit of a mix of themes from Mr. Nielsen’s latest post to his Alert Box.  However, the underlying message was that users don’t actually know how to find content (broadly) and that as search improves, their abilities actually deteriorate.    The implication was that insufficient training and education (both) are provided to users related to information technology.

This scary conclusion was based on research he and his firm have been doing in Asia-Pacific.  He stated that they watched “more than 100 searches for a broad range of tasks.  Only once did I see a user change strategy.”  If you immediately thought, after reading this quote, that changing keyword terms is a change of strategy, Mr. Nielsen offers this retort: “… simple query reformulations don’t count as a strategy change because they were essentially variants on a single approach.”  In Mr. Nielsen’s example, his search research subject was trying to find the differences between a cold or influenza using the symptoms as search terms.  The actual change in strategy is when the research participant started searching for the disease rather than the symptoms.

In our work, many clients try to rely too heavily on search.  They believe good content organization (taxonomy) and tagging (metadata) are unnecessary.  With many of them implementing SharePoint, they often immediately want to install FAST because of a misplaced perception that the standard search technology is inadequate.  In fact, the real challenge is that most users don’t understand how to use search in the first place and most firms don’t invest sufficiently in good content organization.  Further, clients also haven’t provided any education or training as to the use of search, taught their users how to leverage a taxonomy to find content and/or don’t leverage features of the search engine that could improve results or reinforce the right sort of search behavior. 

As Mr. Nielsen points out, search does not solve the findability problem.  And worse yet, as engines get better at figuring out what users want, those same uses continue to degrade their ability to truly engage in research on the web.  

Firms need to invest in education for their workforce if they hope to successfully use technology (any technology).  They also need to invest in training.  The difference?  Training imparts a skill within the context of a specific situation, where education teaches a concept that can be applied in many contexts.   To be truly successful, organizations must provide both.  Then and only then will firms begin to really extract the value they’ve created with the tools they’ve implemented.

What to do with SharePoint when you’re not a Developer

Much of what is published and presented on SharePoint is aimed at a relatively technical audience.  If you review the myriad of SharePoint conferences, SharePoint Saturday sessions and blog content, you’ll find very little content for non-technical folks.  More importantly, much of the content that does exist, wants you to come to one conclusion – SharePoint is the right platform.

Unfortunately, if you’re a manager or an executive trying to understand the strategic choices related to SharePoint as a platform, or perhaps you’re trying to decide what to do with an existing implementation, it’s difficult to find good objective guidance.  Worse yet, if you’re evaluating whether SharePoint is even the right platform for certain requirements, how do you effectively compare your options?

Recently, the Real Story Group and Information Today developed a new conference, the SharePoint Strategy Summit.  This conference is specifically targeted at the non-technical manager or executive.  The program, just a brief two-day affair, focuses on providing you with the information necessary to help you make the strategic decisions necessary for a successful SharePoint implementation (including helping you understand when SharePoint isn’t good choice). 

During these two days, the conference covers topics including:

• SharePoint as an Enterprise 2.0 platform
  

  SharePoint might seem nearly ubiquitous as an enterprise collaboration platform, yet many organizations are still in the process of deciding whether or how to adopt it as part of a broader intranet platform. In the meantime, Microsoft is heavily touting new social and community services in the latest version, SharePoint 2010. Get an objective overview of what works well—and poorly—in SharePoint 2010.

• Strategic alternatives to SharePoint
  

  If you don't go with SharePoint, or chose to put boundaries around the platform, what other alternatives await you beyond Redmond? Learn the pros and cons of SharePoint alternatives.

• Compliance and Records Management
  

  Records management is not a SharePoint strong point. Large SharePoint deployments represent a particular challenge when it comes to the long-term retention, disposition, and discovery of information. This session explores the limitations of the platform and the alternatives you may want to consider. What sorts of steps do you need to take to batten down SharePoint so that it passes regulatory muster?

• The Real Cost of SharePoint
  

  The licensing structure for SharePoint has been a source of confusion for many customers.  However, once you buy the software, the real costs of a solution begin.  What should expect to spend?

• Governance Models and Lessons Learned
  

  Everyone agrees governance is critical—even essential—to long-term success with SharePoint. But how to do it and where to start? Join a panel of consultants and customers who will outline different ways that they’ve gotten SharePoint under control within their organizations. There’s no simple answer here—but you should come away with an approach that works for you.

Unlike other conferences that tend to be heavy on PowerPoint presentations, this conference has a pretty even mix of panel-style debates, moderated roundtable discussions and more traditional presented sessions.  The goal is to create a very interactive experience and enable attendees to get closer to experts, as well as more deeply engage with other attendees.

If this sounds like the right conference for you, visit the SharePoint Strategy Summit registration page.   The conference is just two weeks away and there are just a few remaining slots available.

Article: SharePoint 2010 and the Mobile Experience

Have you wanted to explore the mobile capabilities of SharePoint 2010?  I’ve just published an article on CMSWire that provides an overview of what you get “in the box” and your opportunities to extend the native functionality.

You can read “SharePoint 2010 and the Mobile Experience” on CMSWire’s web site.

SharePoint 2010 is not the Answer

The title of this post may be a bit surprising.  If you’re a regular reader, you know that Consejo firmly endorses SharePoint 2010 as an excellent platform upon which to build your intranet or extranet (internet sites are a different story).  However, we’ve worked with a few clients recently who seem very focused on the upgrade as a solution to their woes (mostly intranet woes).

Certainly, with every situation there’s always context.  I try not to preach to my clients (maybe a little) about why upgrading for its own sake is a bad idea.  Some may have very valid reasons for pursuing an upgrade.  Even when they don’t, many clients upgrade anyway.  However, to be clear, upgrading to the next version of anything is a bad idea if the only reason to upgrade isn’t directly attributable to platform capabilities.  SharePoint is no different.

Don’t get me wrong, SharePoint 2010 is a very robust product.  It has lots of advantages over 2007 and, if you’re a 2003 shop or an enterprise just getting started with SharePoint, I think you’ll be happy with 2010 (assuming the right implementation of course).  Further, 2010 is architecturally it is quite different from 2007 and far better at handling a more diverse set of infrastructure configurations.  It also has loads of goodies for the pedestrian user as well.  Be careful though: with all of this added capability and architectural robustness, there’s a price. 

In many ways, SharePoint 2010 is orders of magnitude more complicated to implement and not well suited for every environment (a 2007 failing as well).  There are new concepts like service applications, managed accounts, document labels, document IDs, content type hubs, external lists and a myriad of other very new and not so easily understood features.  Then there’s the idea that SharePoint can be all things to all people (e.g. a terrific web content management tool at the same time as it enables flawless document collaboration); it’s just not true.   SharePoint is good at a lot of things, but it’s not great or even capable at many more.

That said, clients, especially those in IT departments, seemed to be very taken with this new version.  Often they extol the virtues of managed metadata, better search, high count thresholds for document libraries, remote blob storage (eyes glaze on their business clients at this point) and better manageability (along with the other good stuff).  They heartedly recommend the upgrade to their business user clients and/or they simply say “if you don’t like your current intranet, blame SharePoint 2007; upgrading to 2010 will fix all of your problems and make you much happier.”  Inside of many clients, IT “owns” the intranet and issues an edict that they’re upgrading to 2010.  Worst yet, business users occasionally know that SharePoint powers their intranet and may have come to the potentially erroneous conclusion that SharePoint is the cause of their information management pain; this add further pressure to upgrade.

Honestly though, haven’t we all heard this before?  Wasn’t one of the arguments for SharePoint 2003 or 2007 that “the platform will fix all of your problems?”  Didn’t they (the ones pushing the upgrade) once tell you that SharePoint has loads of features you can use straight out of the box?  Even if part or all of the story was true, didn’t the move and/or upgrade cause you pain?  Don’t you and/or your colleagues, in some ways, have more complexity in your environment, more to manage and, potentially, more dissatisfaction with the intranet?  I suspect that at least some of you will answer “YES!!!” 

As yourself why.  Go ahead…. ask.

I suspect the answer is partially due to infatuation – SharePoint seemed (and seems) really fabulous (especially when that nice Technical Specialist from Microsoft showed you the Contoso Intranet or you attended an Strategy Briefing at a Microsoft Technology Center).  It’s also likely that you had a pretty broken intranet or a severe file-sharing problem.  Or could it have been that your organization had no previous mechanism for allowing various global business groups to share and collaboratively develop content together (save perhaps through very silly and uncontrolled file shares).  SharePoint seemed like it could work.  It seemed like “it” was simply the answer.

In practice, you now realize how much you didn’t know.  This is true for most things.  Martin White, of Intranet Focus, once quipped that “SharePoint demonstrated that most organizations didn’t know they had an information management problem because they never managed information before SharePoint.”  Once SharePoint was running, information management may have seemed even more out of control and users, in some ways, were even more dissatisfied.  This brings me back to my original point.  SharePoint 2010 is very likely not the answer to your intranet woes UNLESS you have very specific business requirements that can’t be immediately met with SharePoint 2007 (and potentially some combination of 3rd party tools); the new version is different, but it is still largely targeted at solving the same kinds of problems.

I’m not suggesting you shouldn’t upgrade.  In fact, if you can demonstrate that 2010 will actually solve your challenges in a way that 2007 and ISV products can’t, I would encourage you to upgrade.  We have a few clients that fall into this category and they’ve taken a very prescriptive approach to the effort.  Unfortunately, for most enterprises, this isn’t the case.

Here a few unjustified reasons I’ve heard for the upgrade and how I would (and have) respond:

• SharePoint 2010 has a better search engine and our search stinks
  I hear this a lot.  This is also the same argument, phrased differently, where search is generally the solution to findability.  Search is not the exclusive solution to findability and upgrading to 2010 (or, even better, 2010 and FAST) won’t help.    In many cases, organizations haven’t done the bare minimum to fix search with the tool they have.  This would include adding metadata (as basic as descriptive titles), creating a proper taxonomy, removed erroneous results from the index, created scopes, leverage pre-canned searches, gotten rid of outdated/irrelevant content or even provided search education to their end users (yes you need a little guidance to use search properly just like any tool).  Improve search first, upgrade later.
• SharePoint’s interface is hard to use; SharePoint 2010’s is better
  It’s true that Microsoft has radically changed the user experience for SharePoint 2010.  My colleague, Tony Byrne at Real Story Group, though questions whether the changes in SharePoint’s interfaces are really all for the better.  Even veteran users of SharePoint find the new ribbon challenging, much like the ribbon in Office.  Further, AJAX has made some interface more modern (and somewhat more reactive), much of what makes SharePoint, well SharePoint, is still very apparent.  You’ll also notice that there are still some exclusively IE features (though more compatible with Firefox and Safari), there are loads of forms for uploading things, the interface is still decidedly “SharePointy” and while you can create a theme in PowerPoint 2010, I’m not sure I would.  Good interface design should be handled by a professional designer and a good developer.  Also, end users are still going to need training (still).  You could/can create compelling interfaces in SharePoint 2007 and the approach isn’t much different in 2010.
• We don’t want to be too far behind Microsoft’s development cycle
  I get it.  You don’t want to be stuck on the equivalent of Windows XP ten years after it first shipped.  This is a valid concern.  However, SharePoint 2010 shipped less than a year ago.  Lots of organizations are still successfully using Office 2003 or 2007, as well as Windows XP.  To be fair, it’s far more difficult to upgrade 10,000 client workstations than a few servers and I don’t think there are very many people outside of Redmond that would defend Windows Vista.  However, the “old technology” argument only gets you so far.  SharePoint 2007 is very much still technologically current relative to Office deployments (though perhaps not too “Web 2.0”).  It fully supports the more recent versions of .NET and you can absolutely find vendors who support the platform with add-on products.  If this were February or August 2012, the argument works far better.  I’d also like to bring up my previous point about search.  Like search, few organizations really spent time or money on customized user experiences for their intranet or fully developed a true application on SharePoint.  They expected business users to simply use what Microsoft provided (more of the “build it and they will come” mentality).  In some cases this worked.  Mostly, collaborative sites experienced uncontrolled growth (causing much of the information management pain) and the larger intranet application languished unloved and underutilized.  This argument is a fallacy from the beginning and shouldn’t be considered a truly valid reason, unless perhaps you’re using IBM Displaywrite 4 (you could probably benefit from the upgrade to WordPerfect 5.1).
• We’ve already paid for the upgrade through our Enterprise Agreement with Microsoft
  This too sounds pretty reasonable on the face of it.  Your EA provides you with the ability to upgrade to the latest version of any included product; why not upgrade?  The reality is that unless you’re not going to renew your agreement during the next cycle, you’ll continue to pay regardless of what version you’re using.    It’s not going to cost you any more or less to stay put on SharePoint 2007 for a while longer (especially if you need to “fix” some of the more serious problems with your intranet).  In the end this argument is just a red herring to distract from the core issue at hand: your intranet doesn’t work for your employees.
• We have too many 3rd party tools for our SharePoint 2007 implementation; SharePoint 2010 provides [insert vendor here]’s functionality out of the box
  Really? I’d double check.  What appears, in some cases, like Microsoft may have covered a previously missing feature, they may not have completely covered it.  For example, metadata.  Microsoft implemented a new managed metadata service that goes a long way to helping enterprises implement a proper metadata scheme within their intranet.  The existence of the service would seem to eliminate the need for tools from companies like SchemaLogic, Smartlogic and more utility-like components from firms like Bamboo Solutions and Layer2.  However, these and other vendors not only appear to have a solid business for SharePoint 2010, they’ve found new opportunities.  If anything, the explosion in add-on products compatible with SharePoint 2010 would anecdotally suggest that SharePoint 2010 continues to have functional gaps.  In truth, there’s probably a better story for ISVs, not because SharePoint has gotten worse, but the platform improvements give these ISVs a far better foundation for valuable add-ons.  Do your homework and don’t get sucked in by good marketing.

Look, I’m on your side.  I love new stuff – especially that new DVD/download smell.  However, distracting everyone from the real problems plaguing your intranet by upgrading to SharePoint 2010 isn’t going to be productive.  An upgrade will likely not fix the real concerns people have about your intranet, nor will the upgrade process be satisfying.  In fact, upgrades usually tend to be migrations; painful, painful migrations.  You aren’t just replacing binaries on the existing servers and manipulating the content database schema.  “Upgrade” usually involves building brand new servers, buying more storage (get it while the gettin’s good), installing a net-new SharePoint farm, licensing brand new add-ons (yes there are still plenty of “opportunities”), licensing/using a migration tool (please don’t try it manually) to move content to the new farm and sending the IT team to training on the new stuff (developers as well as administrators).   Again, when all is said and done, core problems are probably still not addressed, nor have users significantly altered the behavior that lead to this “bad” place; there was simply too much to do getting the “upgrade” done.

In the end: fix what you have.  Get it right now, before you upgrade.  Prove it with real measures of success, then upgrade.  You’ll be happier.

Creating a Multilingual Sites in SharePoint 2010

As we start 2011 and reflect on 2010, one of the major initiatives for many clients was creating globalized, multilingual sites.   The message was especially clear when we spoke to attendees at events like the Enterprise 2.0 conference, KMWorld and J. Boye.  In particular, I was surprised at the number of attendees  planning or that have implemented “localized” or multilingual SharePoint applications.  Unfortunately, as I learned directly, the information available from Microsoft on all multilingual scenarios is uneven.
To their credit, Microsoft has done a relatively good job of making multilingual interfaces within SharePoint available.  Microsoft has released 40 language packs for SharePoint.  These language packs allow organizations to create sites and site collections in any of the languages supported by the language packs.    If your work involves intranet or extranet scenarios (externally facing collaborative sites for trust non-employees), the language packs will serve you well.  If you want a French or Arabic collaboration site, just create a new site and stipulate the language.  Individual users are free to contribute list items in the site’s language and see localized SharePoint interfaces.

NOTE: Tony Byrne, Founder of the Real Story Group, pointed out recently that one of the advantages of using software from larger software companies like Microsoft, Oracle and IBM is that there will be far broader and better tested multilingual support.  Many smaller vendors either don’t provide multilingual support at all or provide a far smaller set of supported languages.  Both issues could be particularly problematic for SharePoint deployments as many rely on 3rd party add-ons from smaller vendors.  You should do your homework on potential solutions to ensure they support the languages you will deploy.

Where documentation for multilingual sites falls short is in the internet scenarios – specifically creating multilingual “publishing” sites (think about the typical corporate web site).  There is some limited content in blogs, technet and MSDN.  However, this content either discusses language packs and variations abstractly or, in the case of most blog content, applies to SharePoint 2007.  All of it falls short of the quick reference needed by many organizations deploying publishing SharePoint sites. 
In an effort to provide some small assistance to other folks implementing multilingual sites, here is a quick reference list of sorts that provide details on some of the basic setup.
Variations
Publishing sites (SharePoint sites created using the “Publishing” or “Publishing with Workflow” site definitions) use a concept called “Variations” to enable the presentation of site content in multiple languages.  This concept has little to do with language packs and more to do with a basic copy process.  When you setup a multilingual publishing site in SharePoint, you designate a root site, a “source variation” site and other “variation language” sites.  As you create content in the source language site, a SharePoint timer job copies content (e.g. pages) and site structures (e.g. sub sites) from the source variation site to each of the other variation sites. 
The root site is merely the default URL for your web site; when web users navigate to the root URL, they are automatically redirected to the variation site that matches their browsers language setting.  As a developer, you can even change the logic used to redirect users to a specific language site by modifying the variations landing page called VariationsRoot.ASPX.  In doing so, you can enable SharePoint to handle other redirection processes like redirecting based on a previously selected language preference stored in a cookie or redirecting based on profile data (e.g. you know the user is based in Belgium and prefers French over Dutch).
Finding the Variations Setting and Beginning the Setup
There are two settings that control variations at the site collection level.  Both settings are found in Site Settings under Site Collection Administration.  To begin the process, you click on the Variations menu option.

By clicking on Variations you begin setting up how variations will be configured for your site collection.  In the subsequent interface, the “Variation Home” is what is called “Root Site” in this post (and what Microsoft typically calls it as well).   The variations interface is shown below:

Variation Labels
Once you’ve setup the global variations feature, you need to setup each variation label.  Variation labels represent every variation site you want to include in your public web application, including the source site.  For example, if you want to have a French (France), German (Germany), English (UK) and Arabic (United Arab Emirates), you’d need a total of four variations.  Of those variations, you’d pick one to be your source variation; the rest would receive content created in the source. 
When you create the labels for the first time, you start by creating the source label.  In our example, we’ll call our UK English site the source.  There are a few fields to complete:

Field Name	Description	Example Value
Label and Description	This is essentially the portion of the URL that designates the site. If your web site URL was http://www.mywebsite.com/ the label portion would be inserted after the last slash like http://www.mywebsite.com/[variation label].  In most cases, the label is going to be the two-letter ISO code for the language, followed by the two-letter ISO code for the country.  Wikipedia has a complete list of the current ISO language codes  and ISO country codes.	en-gb
Display Name	This field is what will be used to not only describe the variation in the management interface, but it will also be the default name of the site when the variation site is created.  Typically the display name is the localized title of your web application.  If your web site was called “My Web Site” in English, you would enter that value for our UK English site.  For French, you might enter a display name like “Mon site Web”	My Web Site
Locale	Use this setting to specify the language represented by a specific variation.   There are numerous languages show in the drop down and potentially multiple versions of any given language (e.g. Spanish in Spain vs. Mexican Spanish).  You should choose the appropriate language that fits your needs.  This setting is used by SharePoint to match a user’s browser language setting to the appropriate variation.	English (United Kingdom)
Hierarchy Creation	This setting determines what portions of the source variation SharePoint will replicate to other variation sites.	Publishing Sites and All Pages
Source Variation	This sets whether the variation you’re currently defining is the source variation.  This setting is something that is set once on a specific variation and can’t be changed after you’ve created the hierarchy.  This option also sets the specific site definition used in creating all variations.  NOTE: only publishing site definitions (e.g. Publishing Site) are there by default.	Publishing Site with Workflow

Here’s a screen shot of the form in SharePoint:

Other Language Variants
After you’ve setup your source variant, you setup the other language variants you want to represent.  The setup process is similar to setting up the source variation, except that the check box indicating the variation is the “source” will be greyed out and disabled.
Once you’ve completed creating the other variants, click the Create Hierarchies button to begin the creation process.  NOTE: Creating the hierarchies is handled by the timer job.  As a result, you will either have to wait for the timer job to run or manually initiate the job to see the variations.  This is also true of other timer job-dependent activities like site structure and page propagation.   More information on timer jobs is provided below.
Timer Jobs
Technically there are multiple timer jobs that each handle a different aspect of the propagation process.  Each timer job runs on a different schedule.  Here is the list of variation timer jobs and the default interval:

Timer Job	Description	Default Execution Interval
Variations Create Hierarchies	This job creates the hierarchies defined in the variation labels section of the variations settings.  As you add new labels, this job takes care of creating the corresponding variation site	Every 24 hours
Variations Create Site	This job creates variation sites if the automatic creation setting is disabled in the Variations section of the site collection settings.	Every 5 minutes
Variations Propagate Site	This job creates variation sites if the automatic creation setting is enabled in the Variations section of the site collection settings.	Every 5 minutes
Variations Create Page	This job creates new pages in each of the variation sites once the page has been created in the source site.	Hourly
Variations Propagate Page	This job updates existing pages in the variation sites once an update has been made to a source page.	Hourly

Depending on your needs, you can modify the default interval to match your publishing schedule.  For example, if you publish pages frequently, you may want to increase the timing of your page propagation and creation to 30 minutes instead of an hour.
Keep in mind that there’s a version of these timer jobs for every SharePoint application (think URL).  This means that you’ll have 3x the number of application configured for variations to manage.  Thankfully, Microsoft provides a view of timer jobs per application.
A screen capture of the time job definitions for a sample site is shown below:

Additional Notes
Like much in SharePoint, the choices you make should be based on your specific requirements; there is usually more than one way to satisfy a need and multiple ways to develop a solution.  To that end, here are some notes about variations setup to help you make these decisions.

• Variations can be used for more than just language versions of content.  Microsoft documentation points out that the logic to redirect users to specific variations could be used just as effectively to redirect a client to a mobile device.  In this case your label could simply be “M” for a mobile version of your site.
• The timer jobs do not replicate other lists or libraries from one variation to another.  This means that you must create lists and libraries in each variation manually after the hierarchy is setup.  This is also true of content in those lists and libraries; the timer jobs focus on structure (e.g. sites and sub sites) and pages.  However, if secondary lists are important for your solution, consider creating a custom timer job.
• Variations are site collection bound.  This means that all variation sites are housed in the same site collection.  If, for some reason, you think you may need more than one site collection, you’ll have to recreate your variation setup for each site collection.  Each site collection would be managed independently.
• When possible, use features and feature stapling to modify the nature of any particular variation (if necessary).  For example, if you need a specific SharePoint list or library created in each variation, use a feature and staple it to each variation as it’s created to ensure the list exists.
• Content contribution is a bit trickier with variations, since each variation is essentially it’s own “web site.”  As such, you will need to spend more time training content contributors and more time supporting them.
• If you use the new managed metadata feature in SharePoint, you’ll need to provide translations for terms as well.  Since all variations are housed in a single site collection, you can even use managed metadata bound to a column vs. enterprise managed metadata to isolate terms that may be specific to your site.
• You are required to setup a root SharePoint site for the site collection.  However, once variations are setup, no one will likely see the root site (since the VariationsRoot.aspx page will be set to the home page of that site).  As such, you don’t have to do much with it.  However, you could use the site to store more global resources, like images and documents, for use across all variations.
• Especially during development, you should execute the timer jobs manually by going to Central Administration, go to the Monitoring section and click on Timer Job Definitions to find the right job.  When you click on a specific timer job, you’ll have the opportunity to run the job manually.  Manually running the timer jobs will allow you to see what’s actually happening within your sites without having to wait for the job to run automatically.

Please share your experiences with multilingual sites and what challenges you’ve had through comments on this post.  There is a lot more detail to setting up and managing variations, so the more feedback the better.

Continue to part 2 of this series