Rich Madigan, Senior Project Manager and Kentico Consultant at MMT Digital, on how to implement a global roll-out
Well, world domination might be a bit strong. We’re talking here about the global rollout. On paper, it seems like a straightforward job with a series of manual tasks but the reality is a more complex beast. The key to a successful global rollout is a well thought through strategy. Having been through the process ourselves with Kentico websites, here are six things to keep in mind.
Let’s say you’re a construction company and you have a plot of land. You could choose to build a house or a block of flats (ignoring the reams of red tape that exist in reality!) There are pros and cons to both with each option suiting particular situations.
It’s much the same story with a global rollout. Do you go with a single installation of Kentico per website (the house) or go with an installation containing multiple websites (the flats)? The initial feeling is to go with a multi-site installation as it seems like the best option. But it isn’t so clear cut.
Each installation of Kentico consumes memory, so having all of the sites on one installation is often considered to be much more efficient than having a separate installation per site. However, there are two key questions that you should ask before jumping into a multi-site installation.
Are we going to be sharing objects (master page, CSS, templates, web parts, page types, etc.) across the websites?
If the answer is yes then great, the multiple sites on one installation is the best way forward for you. By keeping all the sites on the one installation you are making development much more efficient across the websites as you are working with the same basic building blocks.
This isn’t to say that you can’t have different master pages, web parts etc. for each website on the installation but, more often than not, in a global rollout, the business is looking to project a shared identity across its country websites.
Have we considered performance?
If you’re doing a global rollout then the chances are you will have sites in all corners of the globe. If you’re hosting from the same data centre then users from the various countries are communicating with that data centre. Should you split the sites out into several installations, e.g. a Europe installation, an American installation, etc.? There are benefits to both performance and SEO in grouping your sites on separate installations but this will obviously have an impact on development and hosting and is something to be considered.
Despite sounding like a villain from an 80s computer game, the Master Page is essentially the template that holds all the common elements of the website – header, footer, navigation, etc. – and is an important piece of the puzzle.
Let’s assume you have gone down the multiple sites on one installation route. As we said earlier, you can have multiple master pages but, in the scenario of a global rollout, it is far more common for that master page to be the same one used across all country sites.
Navigation is easy enough to deal with as the common web parts (hierarchical viewers and list menus) will look at the tree and pull through the navigation you have set up. But there are other elements to the master page.
There’s often other minor elements floating round the master page which can be easily forgotten – the copyright, the phone number and its ‘Get in touch’ text. These items can be hardcoded into the template to make it easy to rollout sites but this can be dangerous. If you’re dealing with different languages you need to make sure that these elements are either content manageable or editable via another method (custom settings, custom page types combined with macros, etc.).
The other thing to think about is the Google Analytics code. If you’re using the same master page, the original GA code will be replicated across sites. So you need to think about how you can manage the GA code for each website. There’s many ways to skin this cat and you need to find the solution that works for your client.
Pages in Kentico sites are made up of a range of building blocks including stylesheets, web parts and widgets. Like a budding architect with a stack of Lego, these building blocks can be pulled together to create all manner of combinations.
When considering multiple sites on one installation, these building blocks are a vital part of the strategy. From the start, it is important to consider how these blocks are going to be used across your web estate. As mentioned earlier, stylesheets, page types, templates, web parts and widgets can be shared across your websites, making it easier to maintain the core functionality and giving you greater control over the visual identity.
But this in itself poses its own considerations. Naming conventions, particularly for templates and page types, are vital in providing clarity to the users and it is important to consider how the different country sites operate and what they may require. The ideal is to find one solution that works for all but your solution should be flexible enough to allow for those unique elements that satisfy specific country requirements.
Like the libraries we all remember from our youth, the media libraries in Kentico are repositories for a wealth of assets, ranging from images through to documents.
When there’s multiple sites on one installation, the key thing to consider is how you are going to use the media libraries. There may be some imagery that is appropriate for specific regions or countries while other imagery may be more generic. Identifying these sorts of requirements early can help you define what media libraries you need and the permissions you need to set.
Qu’est-ce que c’est?
Kentico has the concept of cultures which enable you to create specific language versions of a website. With multiple sites on one installation, setting up new cultures is easy peasy but the common mistake made is only focusing on translating the content. In many sites there are buttons, calls to action and other elements that are often handled through CSS or within the template itself. These often need translating too so it is important to think about this from the off and identify all the elements that need translating and how these are managed – particularly common calls to action that might feature across multiple pages.
With your web estate in place, the editors and administrators should be chomping at the bit to get involved in adding and editing content. But, before you let the editors storm into the CMS like a frenzied mob at the January sales, have a thought for how these users are going to engage with the CMS. And finally we have users, in particular the editors and administrators of the sites across your websites. Like many of the previous items, it sounds easy on paper but it requires some serious thought before jumping in. Kentico provides a wealth of user permissions, document permissions and UI personalisations. You need to understand the range of users that will be administering your websites and plan out what they can see and do (and what they can’t see and do!).
I’ve started so I’ll finish…
Any global rollout is a big undertaking so the items listed above can be seen as the tip of the iceberg. The biggest piece of advice we can give is think before you jump in and map out your strategy.
Rich Madigan is a Project Manager and Kentico Consultant here at MMT Digital. When not managing his own projects and pioneering Kentico standards alongside our own Kentico MVP Ilesh Mistry, he can often be found working on the best strategies for the implementation of the Kentico EMS.
This article appears on the MMT blog.