Loading...

Loading...

Deliver a smooth user journey with a unified enterprise web stack

  • Posted on November 23, 2017
  • Estimated reading time 3 minutes
unified enterprise web stack

Your average Enterprise web stack usually contains multitudes of technologies and platforms, such as Sitecore, WordPress, custom PHP, and legacy ASP sites, to name a few. In theory, this solution should be consolidated to one technology or platform (preferably Sitecore on Microsoft Azure), but it never is. And, to be honest, it probably shouldn't be.


The integration of multiple technologies allows companies to use the most fitting product for each desired task: Azure-based Sitecore for the main site, Linux-hosted WordPress for the blogs, third party community sites, etc. Plus, all enterprises have legacy applications which might continue to live on various old platforms.

Focusing on user experience

While all this infrastructure might be great from a functional perspective, it might not be so great necessarily from the perspective of the people managing and building those services, not to mention, from the end user’s perspective. As you can imagine, the layering of multiple platforms often leads to deteriorated user experience, inconsistent content, development effort duplication, and delays in publishing updates, among other issues.

One of our clients faced this very problem. Their main site was built on Sitecore, they used a WordPress site for blogs, and they also maintained a couple of other sites on various other platforms. The client tasked us to deliver a consistent look and feel for the end-users across all platforms so they would feel like they are in a single experience instead of multiple different experiences. We evaluated several obvious options:

  • Solution 1: Design the header and footer, and let every platform implement it separately.  (This is the standard approach used by many organizations).
  • Solution 2: Let every site continue to use whatever header they already have. (This can be very inconsistent and confusing for the end-users.)
  • Solution 3: Build one header and footer, and federate that to all the sites. (Sounds great, but is this really viable?) 

The third option of course offers the best experience for users and authors, but how complicated and/or expensive would it be to implement? There are definitely challenges in federating code, HTML, CSS and JavaScript to unknown 3rd party sites (i.e. running the same component on multiple platforms through JavaScript). It's possible to build something like this from scratch, but why would we when Sitecore gives us a leg up with Federated Experience Manager (FXM)? So, after some prototyping, that's the solution we decided to leverage.

We overcame several key challenges:

  • Isolating the CSS/JavaScript: loading third party CSS could easily break existing styling on the site.
  • Enabling event handlers for JavaScript: if our header had dependencies on document ready events, those wouldn't trigger correctly after being loaded through JavaScript.
  • Browser cross origin restrictions: browsers could block the header JavaScript since it originated from a different domain.

Leaner, meaner infrastructure

The end result was a surprisingly smooth user experience. Now the end-user doesn't even notice when they move from one site to another. Our Sitecore instance renders the header for all the sites in the environment delivering the same content, html, JavaScript, and CSS run for the main site and all the other non-Sitecore sites. So, a single change will automatically apply to all sites.

The solution had the following benefits:

  • Consistent user experience across all sites
  • Instant content updates to all sites
  • Flexibility to use the best product for each task
  • UX changes automatically deployed everywhere
  • Tracking of the user through the whole experience 

Finding the best FXM fit

There are, of course, several key items you need to consider before deciding if this is a suitable solution for you:

  • Speed: there is a minor delay (usually well under half a second) until the header loads
  • Scale: now every page-load on all your sites will be a page load on your Sitecore instance
  • Fragility: it's easy to break your other sites with careless JavaScript, so regression testing will take more effort
  • Not out-of-the-box: there's effort and complexity necessary to develop and maintain the solution

One additional thing I would mention (which I hammered into the audience while presenting at last year’s Sitecore Symposium), is that, while this solution is possible, it's not trivial. FXM is a very powerful platform, but that's all it is: a platform upon which you can build your end solution.

So while FXM might not solve all your problems, nor does it fit into all scenarios, it is potentially a very powerful tool for the owner of an enterprise web platform to leverage when simplifying and streamlining certain complexities.

Balancing priorities and addressing complex technology solutions is no easy feat. Here at Avanade, we always keep the user experience at the forefront of our digital decision-making. Learn more about what “digital” means to us.

Techs and Specs Newsletter

Stay up to date with our latest news.

Share this page
CLOSE
Modal window
Contract