This is a guest post by Mikael Blomberg, Senior Developer at SC5, our partner agency from Finland. SC5 has recently integrated Contentful on a website of their client – an online insurance company – and in this post Mikael is talking about why the transition was necessary and how editors, designers and developers benefited from it.
About the company
SC5 Online is an 80-person consultant agency that specializes in digital customer experiences. Our services are digital business consultation, service design, and software service development. In 2014 our turnover was 6,4 MEUR. We do not only build IT-systems but better customer experiences. Working smart improves our customers’ bottom line.
POP Vakuutus is a Finnish online insurance company that has been in business since 2012. Unlike other insurance companies in Finland, POP doesn’t have any offices and instead focuses heavily on creating easy-to-use online services.
POP Vakuutus started building their website with SC5 in 2012. One of the early requirements was the support for internationalization in case we needed to translate the site to more languages. The solution was to use gettext with Jed on the front-end, and a tool called Rosetta for translating the texts.
We ended up running all the text on the site through Rosetta. Every piece of text had a unique ID and could be translated. While Rosetta worked well enough for translating all 3,500 text snippets on the site, it wasn’t that good for updating them. There were numerous problems with using Rosetta for managing content:
All text slots on the site had to be defined beforehand by the developer. For example, a user might have wanted a new block of text in the header, but that wasn’t possible without the developer creating a new translatable text ID there. Because of this, existing text blocks sometimes were exploited by breaking out of them by closing HTML tags in the translation. This made it harder to update the layout or reuse the translation elsewhere.
The Rosetta UI is very basic and doesn’t offer any support for styling the text or structuring the content. Because of this, normal text updates were run through developers to make sure the updates looked good on the site.
The update cycle became very long. Gettext files were part of the version control and were mostly deployed to production along with other code updates. Even minor text changes often took days or even weeks to get to production which was frustrating.
Overall the system was quite fragile. Translation files would sometimes cause merge conflicts and there was no built-in support in Rosetta for restoring old texts.
Requirements for the new CMS
POP Vakuutus had a number of content-heavy pages with very simple functionality. An example could be a static product page for vehicle insurance. The page has a wealth of information but only tries to direct the user onwards to actually purchase a vehicle insurance. Because these pages play a key role in the sales funnels, we wanted to be able to change them rapidly to test different variations and to respond to marketing campaigns.
POP Vakuutus and SC5 set out to replace these mostly static pages with something we could edit freely without waiting for the code to be redeployed. At first we compared different content management systems, including Wordpress and other well-known CMS solutions. The trouble with hosting a traditional CMS is that it adds its own burden on maintenance, and from a security point of view increases the overall attack vulnerability of a website.
From these considerations emerged a requirement that the CMS should be able to output static HTML pages which could be served in production without the CMS being visible to the world.
Another clear requirement was that it should be possible to update the static pages in production separate from other code updates. On top of that we wanted regular users to be able to update the pages themselves without involving the developers.
Other requirements included:
Creating elements that could be reused across all pages
Focusing on mobile experience with mobile-first development approach
Making the site responsive
Structuring the data in a way that made sense for editors updating the site
Allowing designers to create new pages on the fly
A key idea was that using static HTML pages would mostly solve the update cycle issues. They could be just copied in place and our web server would be configured to serve them instead of running any application code.
However, the requirement to output static pages does not completely rule out any CMS. Even if a CMS didn’t support it out of the box we could have built a script that would take the the output from the CMS and copy it elsewhere.
After comparing several CMS solutions, we decided that Contentful provided the highest flexibility and allowed us to rapidly develop a proof-of-concept implementation. Our solution was to create the structured content in Contentful and to have Metalsmith, a static site generator, build the static pages using Contentful API.
We built a few templates which map Contentful content types to given sections on a page. For example, we created a template for the landing pages which can be used to create generic product information pages. Each page can use a number of smaller modules, for example a list of benefits or collapsible content highlighting different features of a product. These modules are mapped to the Contentful content types and have a small amount of module-specific CSS and JS. They significantly simplified implementing the responsiveness.
The compiled static pages are then copied to staging, and later to production. The staging is primarily used for quality assurance. The page templates and styles can be edited by POP Vakuutus designers and naturally there is a need to verify that everything works properly on all devices. The static pages are then versioned and copied to production. Versioning is used so that rollbacks are possible in case something unexpected happens.
“Contentful looked very promising as it was quite simple without the legacy other existing options have” said POP Vakuutus’ Lead Designer Juhana Schulman.
One of the main benefits is the separation of content from presentation and page creation. Each phase is independent and every step can be changed without affecting the other steps. Allowing content creators update the content themselves without having to fear that something breaks unexpectedly is very valuable.
SC5 is very happy with the solution as the architecture enforces separation of concerns that improve maintainability. Development was rapid and Contentful was a joy to use.