Client story

Creating a delivery mechanism, architecture and UI components

Technical details Component driven development
Industry Utilities

The challenge

The biggest challenge was the cycle to continuously overcome roadblocks, present solutions and align people. In particular, all the developers involved had many great ideas and proposed technical solutions that often differed. We needed to make decisions fast without developers feeling unheard.

The solution

One team of Graphics, UX and UI designers was responsible for delivering the designs for the rebranded web pages. While this team was ramping up and prototyping designs with stakeholders, front- and backend developers were sitting idle. We had to create an environment in which we could remove this idle time. A lot of great solutions regarding the delivery mechanism were proposed and discussed. In the end, we continued with a component-driven approach in which each web page is divided into smaller UI components. The designers created an atomic design system for the developers to implement. This meant that front-end developers needed to create a similar system that matched with the components. Angular was used to realize this system. The back-end was a content management system that also needed the necessary changes to match the front-end components.

Search Engine Optimization (SEO) was the next big challenge. Consider what happens to search engine rankings for a company when that company’s name and domain name are changed. Next to this, Angular components were not SEO compatible, since they were rendered client-side. We have solved this by defining static, Angular and web components. A static component contains only HTML and is guaranteed to be indexable by a search engine. Angular components are useful when SEO is not important for these components, but developers are likely to reuse these components (for example, a date picker). In addition to this, web components can be easily rendered by the backend, since they are small packages that are framework agnostic.

Changes in the UI and front end occurred multiple times a day. The backend platform released once every two weeks. If we were dependent on the hosting backend platform it would slow down the delivery drastically. By creating a front-end mono repository, we fostered collaboration between many developers company-wide, beyond the scope of the rebranding project and even across borders. Earlier, the delivery mechanism was described. Having a component-driven approach for all disciplines, design, front- and back-end. This mechanism also emphasized the need for separate CI/CD pipelines.

The results

We invited all involved developers to join a weekly guild meeting in which problems were discussed and discussions followed. The knowledge sharing values we have at Qxperts were adopted by the guild and yielded many great results: the rise of a collaboration culture, a mono repository, a centralized icon set to name a few.

After many iterations, our delivery mechanism paid off. We were able to deliver multiple small testable chunks of software as UI components throughout the design, front- and backend disciplines. Within two weeks, these chunks were developed, tested and shipped to production. Without this mechanism, this could not have happened. At the start of October 2019, the brand new website went live and within 2 weeks most of the site had regained its search index for the new domain. It was heart-warming to see more than 70 people come together at the office around 5 AM on Monday to make this a success. What followed was a very smooth go-live, before 9 AM everything was operational.

The biggest delight from a developer’s point of view was the mono repository for the UI components. We released many times a day, the builds and releases were under 10 minutes and they were stable.