Over a six-week period, I built almost 100 pages in Sitecore for a website migration project. Both the CMS and I survived (just!), and I thought I’d reflect on what I learned, what went well and what I’d do differently next time.
I’m a huge fan of starting a project with content.
When everyone is familiar with the amount, quality and quirks of what’s actually going on the website (or any digital platform), it makes it easier to design a build a solution that will work. As this was a site migration, we knew what we were dealing with from the beginning.
We started the project with a content inventory and identified which pages were coming across in their entirety and which ones needed to be rewritten, absorbed into other pages or removed. Once we had our new sitemap nailed down, I used Gather Content to stay organised.
I was able to replicate the sitemap in Gather Content and create page templates that would be used across the site. I then used their drag-and-drop functionality to build out each page, indicating where blocks of text, images and video, as well as the calls to action, would go.
While there were times where I felt I was duplicating efforts (I built 100 pages in Gather Content just to build them again in Sitecore), it was worth the time up-front so both the client and agency project teams were aligned.
Paired with our page template designs, this platform allowed the client to easily visualise what the content on the page would look like. I was able to add suggested word counts and guidance on what type of media could be used to best effect.
The workflow process in Gather Content can be set up to move content through the creation and approval process with minimal fuss. It was a great tool and I’ll definitely use it again.
On nearly every digital project I’ve worked on, the problem of images is constant. Low resolution, poor composition, the wrong orientation or the lack of any imagery whatsoever leads to website pages that lack visual consistency and are out of balance on the page.
While my content inventory gathered the page content we’d need to migrate, we didn’t talk about the images that were required for each page soon enough. That meant we were trying to find workarounds as we were building the pages.
A lot of our pages used a CTA component that had an image at the top, a headline, teaser copy and a button CTA. By default, we assumed a landscape image would be used, but we had a mix of portrait and landscape. When we used a portrait image, they came out quite stretched.
To solve this, we created a parameter which could be applied to each CTA component to tell it how the image was orientated and the proper styling could be applied. In essence, it created a window frame within the component, so regardless of which image we used, it would always fit within the frame.
By applying this new parameter and some front-end magic, we were able to use both landscape and portrait images in the CTA image window.
On another page, this one to list out some product accessories, we had approximately 25-30 images of varying styles, sizes and quality. Some products had images and others didn’t. We started with a grid of CTA components, but the lack of consistency and the slow loading times on the page were proving problematic.
Instead, we changed the format of the page and added a table with the product names hyperlinked to the image file in the media library. Customers could still see the image if it was available, but our page looked a lot cleaner and the loading time was much faster. Next time, I’ll do an image audit as soon as we kick off the project.
It’s fair to say I wouldn’t have gotten through the project without the help of the project team, both client-side and internal, but I relied mostly on the help of my front-end developer. Sitecore can be a tricky CMS to work with (they all are to be honest), and there will always be challenges with the look, feel and functionality that will be beyond most marketers.
So my advice: make friends with your devs. Bake them cookies, do the tea run or, if like me you work in a different part of the country to them, find other ways to build rapport and work together effectively.
We made this work by:
Using Slack for quick questions on the build, for banter, to send emojis (mostly the crying ones) and to bond over our shared CMS woesCatching up daily in the afternoons to share progress on page builds and talk through thornier challenges that needed more time and collaboration
Using a shared Google sheet listing all the pages with details about the build, such as:
o which page template we were using
o whether the pages were in build, dev review or ready for QA
o what the staging site URL was for each page
o if there were queries that were sitting with the client
We set the client up on a Slack channel as well, which was great to have a dedicated place where everyone was able to get the answers they needed quickly. Find the communication channels that work for you and share often.
One of the great features of Sitecore is that the presentation of the content sits separately to the content itself. This means we can create content once and pull it through to various components on whatever page we need.
This was really helpful when working with standard calls to action, promotional banners or repeated information. Rather than duplicating that content on each page, we stored it in a sitewide folder and were able to reuse it across multiple pages.
It’s a great way to future-proof your website: if that content needs to be updated, the content manager only has to update it in one place rather than trying to find each instance of it across the site.
As I was building, there were times when I would create the content at the page level only to realise it would need to be used elsewhere. Sitecore makes it really easy to move content around in the Content Tree, so I was able to move things around and simply double check that the components on the page were pointing to the right data source.
There are definite strengths to both the Content Editor and the Experience Editor, but I found myself drawn to the Content Editor, especially when working with pages that shared a lot of the same formatting.
As soon as I had a page with the basic format in place – the lead banner, the intro paragraph, the CTAs – I would copy that content to a new page in the Content Editor and then edit the content there rather than switching to the Experience Editor.
Once I had the bulk of the content created in the Content Editor, I would jump into the Experience Editor to build out the layout of the page. Then it was a matter of simply pointing the components to the existing data sources and checking to ensure the presentation was correct.
I found working in the Content Editor to be a lot more efficient and the CMS seemed to save a lot faster too.
It’s easy to get caught up building the pages with the content near to hand, but one thing that I’ll do sooner next time is to look for those pages that have third-party integrations or that need other departments and agencies to feed in.
If you’re setting up an API to pull content into the site, if you need to hook up live chat or if you have forms that need to pass data between parties – start early. It will always take longer than you think and will likely take several tries to get it right.
For content migrations, use your page inventory to note which pages have difficult functionality and start the conversations as soon as you can.
It’s been a great project and I’ve personally gained a lot more confidence in working with Sitecore. It’s a powerful platform and I can’t wait to get started with the personalisation work we’ve planned out.
But I can see how front-loading the project with more due diligence around content, images and integration activity will save time and effort during the build stage and cut down on feelings of urgency as the go-live deadline approaches.
Bring on the next build!
If you’d like to find out more about working with Sagittarius for your Sitecore migration project, get in touch with us on 01233 467800 or drop us an email at hello@sagittarius.agency
This blog was originally posted via Sagittarius on 28th January 2019.