In the first phase, we familiarised ourselves with the new design. This had been provided by creative agency Damm & Bierbaum Interactive (DBI).
We then analysed the design to determine the need for adaptation in the frontend. We provided the design templates as a visual and technical reference via InVision. This approach not only simplified the analytic process, it also helped us later in our consultation with project stakeholders and during the actual implementation.
During the redesign, existing modules and features as well as content structure and contents remained unchanged. There were also a few elements that were to keep their current look because they were not being redesigned. That is why we planned minimally invasive adaptations – as much as necessary but as little as possible.
We also took into account overarching changes where necessary for the modules, such as changes to the page layout.
Implementation of the Redesign
Why the in-depth preparation? A website of this magnitude and its surrounding systems work a bit like a complex machine. The processes are like the cogs and require fine-tuning to work seamlessly. Change one of the cogs and other functionalities and dependencies may change automatically.
In our case, one of those cogs might be changes to the HTML code, for instance. With every change, the complexity of the project increases, and every change may trigger time-consuming adaptations to the backend.
Retaining the Existing CMS Modules
The ALH Group manages its website content in Sitecore and does this primarily on a modular basis.
There is an existing set of modules for different text volumes or the use and presentation of media. These are available on specific websites where needed and contain editor-generated content.
Replacing entire modules for the redesign would have triggered the migration of existing content. To avoid this extra work, we kept all Sitecore modules in place for the redesign. Where the new design required adding elements to existing modules, we used default settings to ensure that the changes that editors would need to make afterwards were kept to a minimum.
Retaining the Existing HTML Markup
As well as the content, the interactive features of the websites were also to remain unchanged in the new design. This included sliders, switches and navigation. As these are mostly linked to the HTML structure of a website, we retained the HTML markup of the individual modules and just changed the appearance via the stylesheet.
Of course, we could not apply this ideal solution to all modules.
Beautiful Curves – but What About Loading Times?
Every redesign of a website comes with its own peculiarities, driven by a desire for change. At ALH Group, it was the curves.
There are both symmetrical and asymmetrical curves, and they are a challenge in themselves because the internet is still a “rectangular” pixel construct.
As part of a proof of concept we investigated different options to best display these curves. We knew from the get-go that CSS would not allow us to realise all curves completely in line with the CI. As an alternative, we considered using code-heavy SVG files.
We paid for the precise implementation of the desired design in additional lines of code. The downside: Depending on the required number of SVG files, the “weight” and therefore also the loading time of the website would have increased, plus designers would have to generate new SVG files for every change.
In the end, we agreed with the customer to use both options. Where possible, we used CSS as a tool to maintain good performance and a high level of flexibility. In other places, we used SVG files.
Multi-Level Quality Assurance
The quality check of the frontend code was carried out in several consecutive steps. In the first step, a second developer checked the code via a peer check. Only then was it committed to the code repository. From there, the team deployed the frontend code to a dedicated preview environment to test it as a prototype.
In the next step, we integrated the code into the Sitecore backend and performed more tests. To make these tests as realistic and high-quality as possible, we had migrated production content from the customer’s integration environment to our development environment at the beginning of the project.
After this three-stage process, we handed the new design over to the customer. A final test was performed in this integration environment, before the changes were deployed to the individual websites.
Contact for your Digital Solution with Unic
Are you keen too discuss your digital tasks with us? We would be happy to exchange ideas with you: Jörg Nölke and Gerrit Taaks (from left to right).