Rebuilding an aircraft on the fly — A Pattern Library integration at trivago
Evolution and approaches of integrating a pattern library at large scale
We started at the beginning of 2015 with building the first prototype of a pattern library. I stumbled upon HBR’s pattern-lab work flow that they used as part of their redesign. I liked the solution, having the whole development inside a vagrant environment to easily share the code amongst developers and have an easier installation process. Not everybody has a local PHP version or a development ready web server environment on their local machines and we use vagrant internally for most of our development environments.
We forked the HBRGTech Repo and used this as a base setup for our development.
Our Case Study
Our goal was to redesign our company pages and to prove that a design-development process like Atomic Design is more efficient. The planned redesign was a case study for the project trivago and patternlab.
We started developing the first atoms, molecules and organisms and were happy with the first results and ease of development. We especially liked that patternlab does not oppose a special development philosophy on you, e.g. how you write your CSS and JS-code and so we squeezed in our CSS skeleton base which we developed in a Hackathon Project at trivago in 2014.
The first steps
We integrated Grunticon and its build scripts inside the pattern lab and worked closely together with the designers to build the first requested patterns based on Illustrator designs. Everything looked very promising. We started to develop a common language and understanding and were able to present the first patterns within a few days / hours on our local environments. We were sure this is the way to go.
Sell it to the people
By the way, at that time we hadn’t yet convinced the management, that this is now the way we want the development process of new design-rebuilds or iterations to be. Up until then, the existing design-development process was simply attaching JPG file exported from Photoshop to a JIRA-Task. You can imagine what impact this had on the consistency of our design and code.
At this point we decided to go ahead with the new process. We had to prepare for this change to become reality, first of all we had to make the web view of the pattern lab visible for the whole company and we had to prepare a stunning presentation to convince them. Also we had to come up with some workflow proposals.
Our Software Operations Team helped us with setting up a deployment process utilizing Jenkins so that every new change to the repository would be visible on an internal server which can be accessed by everyone. And together with Design we created a stunning presentation and showed it to a huge number of people within the company.
The automation challenge
People liked the idea, but despite a few workflow questions and concerns one question came up which was expected and completely valid: “How do we roll-out the code from Pattern Library? Copy and paste?!” In a fast growing environment with a lot of changes to the codebase in a very short timeframe this was a kind of killer argument against a non-automated update process. As we anticipated this question we made clear that at this point we were mainly focussing on creating the base for a new design system and to establish a new workflow. We were at this moment not even ready to roll-out the code to our core applications because we were still in an evaluation process of new guidelines for writing our front-end code.
Publish early, release often
Nevertheless there was time pressure, as the first design iteration of our company pages should be released soon. We nearly had all components ready inside the pattern library and started with implementing them into the CMS. As the company pages are not using our standard Symfony environment and they were rather simple we didn’t really run into synchronization issues with copying and pasting the code into the CMS but realized soon, that every bugfix and markup change became a chore.
Does it scale?
We started thinking about how we could scale up the pattern lab. As we still used the default edition with mustache while twig is the template language of our choice, we decided to replace it with the twig version. This meant that we had to rewrite more than one hundred existing templates from mustache to twig. In parallel we evaluated the benefits of applying OOCSS and BEM to our CSS code so we started rewriting the templates to twig and adapting the new CSS base.
Adapt it to the needs
Once the first version of the new company pages was launched we identified a few other issues. While our CSS guidelines improved a lot with BEM and OOCSS we feared that not having the appropriate structure in place could be a challenge especially when it comes to rolling out the CSS to different applications. Furthermore we needed the ability to preview patterns in a right-to-left mode as our website is also available in countries like Israel. We also identified the need of having patterns in different layout variations with different CSS builds, e.g. it might be that applications use different base settings like breakpoint definitions. So we had to do some additions to the pattern build process. We implemented different build targets for CSS files inside the pattern library and configured patterns to use those builds. As a result the build process included a different head-include depending on the configuration while building the patterns. Also we added the possibility to preview all our patterns inside the web view in a right to left mode without duplication.
It needs more architecture
We started thinking more and more about something like a component API as a central storage for patterns which can be automatically rolled-out to applications. Our Software Architects became interested and gave us some valued insights. A highly admired colleague of ours built a twig documentation plugin for us. This plugin reads out the documentation of the twig files and puts it into the code panel view. So we were able to document what the variables in the patterns are actually doing. He also built a prototype for a component API, which facilitates the integration of the pattern library templates into our core application, the trivago hotel search. Getting this thing ready for production will still take some time.
In the meantime, to fight the CSS structure problem we found that ITCSS is the way to go. We performed another iteration of our new CSS base and ended up with something we were so convinced of that we kicked off a refactoring project to integrate the base of the CSS into our core product to achieve a smoother transition at later stages.
Our JS Lead Architect became more and more interested especially in the new modular CSS structure and how it would make it easier to build something like web components. We did another proof of concept and began implementing a calendar module inside the pattern library. We added webpack for the JS build process and were happy that is was easy to include the component CSS files from the new structure. We had to tell the component how to find the patterns because we use Swig for client side rendering.
As with the component API those things might still take some time until they become production ready and because we did this refactoring project and told everybody that we can now carry out design iterations more easily, we were asked to implement a new business critical component for our core product, the trivago hotel search.
The final challenge
In less than 3 weeks we developed a new complex UI module for the hotel search and we were ready to implement it as an A/B test into the core product. Did I mention we had no update process yet, nor for the CSS, nor for twig or JS? This now became fun, because performing open heart surgery on a highly business critical UI component is an exciting task.
Guess what happened?
Yes we accidentally overwrote a few lines or forgot to transfer a change. But all in all it went surprisingly well. But we didn’t want to tempt fate and put all our focus on creating a package for the CSS base.
We had one big monolith repository, our pattern lab, which contained everything: the templates, all the CSS, and a bit of JS. As a first step we decided to build a package called trivago-core_patterns which initially only contained the SCSS but at a later stage might also include things like twig-templates. In the pattern lab as well as in most of our applications we use composer for package management and therefore decided to utilize it to integrate this package. We were now in a better position to automatically update the CSS in different applications. Furthermore by using versioning it gave us a better opportunity to maintain, develop, and bugfix the CSS in the future. For example if you have a three month old version in your application and find a minor bug, you can create a hotfix for your tagged version instead of updating to a completely different version inside the master branch.
All in all we made huge progress over the last year. Basically coming from a non-organized and a widely spread and cluttered UI layer throughout the applications we have made a big step forward in centralizing our UI layer and sharing it with our applications. But we still have a long way to go and we are super excited about this.
I will talk at Symfony Live Cologne 2016 and give some more insights about how to integrate patternlab.io into a Symfony project.
