July 14, 2016 Toolkits, Pattern Libraries and how we use them at Madgex James Wragg, Front-end Development Team Lead

Toolkits, Pattern Libraries and how we use them at Madgex

Front end web development is constantly evolving. Websites are more complex than they have ever been. Dealing with steadily increasing complexity has pushed website creators to rethink how best to build and maintain websites.

One popular solution is to break down a website’s constituent components into ‘lego blocks'. Simple, reusable, self-contained chunks of UI that can be assembled in numerous ways to create a website.

Taking the idea a step further, these chunks of UI can live independently from the actual website, forming a product in its own right. There the building blocks can be designed, built, tested, maintained and documented, and then consumed by a website.

Such a product goes by a variety names. A Pattern Library, UI Toolkit, Living Style Guide, UI Toolkit, and so on. At Madgex we call ours a Front-End Toolkit.

Why are Toolkits needed?

Consistency

As a website reaches a certain size and complexity a consistent user experience becomes harder to achieve.

Say for example a new form is added to a website. How should it look and behave? If the developers don’t have a form pattern to reference they may end up creating something that doesn’t fit with the other forms on the site, leading to an inconsistent user experience.

Toolkits solve the problem by becoming the single source of truth about how UI elements should look and behave.

Documentation

For designers & developers alike - an inventory of UI - this is how we do this [forms/pagination/share widget] at Madgex and on this product.

It’s a collaboration tool for the designers and developers, while helping with on-boarding of new starters.

Maintainability

One of the most exciting things about toolkits is it’s possible to build chunks of UI in one place and then use them wherever they’re needed. This allows developers and designers to iterate in one place.

Take the example of the design team wanting to update the style of buttons across all websites. If the websites are using the CSS from the toolkit, all that needs to be done is to update the code in the toolkit. The live websites would then automatically receive the modified style.

Making websites easier to maintain has obvious benefits for a design team, but in addition, the benefits also trickle down to the users. When a website is easier to maintain, users receive updates, UX improvements and bug fixes more frequently.

What is Madgex doing in this area?

The design team at Madgex created a toolkit to help us build the Course Board product. Although it started life as the Course Board toolkit, we quickly realised it would be useful for any other products we create. So we split it into a ‘core’ and ‘product specific’ toolkit.

The core toolkit documents and generates production-ready code for use across all new products and websites. The product-specific toolkits then plug the gap when certain product-level UI patterns are needed.

Splitting up and sharing the toolkit in this way gives us the opportunity not only to create consistent, easily maintainable individual sites, but also a consistent and unified suite of products.

The future

Assets like CSS, images and JavaScript can be easily pulled in from a CDN and used cross-website, even cross-product. HTML is different. It’s difficult to reuse HTML because it’s delivered from the back-end and its contents change depending on the situation it finds itself in.

An important rule in software engineering is that duplication is best avoided as it can lead to inconsistencies. Currently, duplication of the HTML in the toolkits is unavoidable because the only way to get the HTML from the toolkits into the websites is to copy and paste it. If we could use the HTML in the toolkits to power the products that would be a huge boon.

Over time we’ve experimented with various open source projects to help us build our toolkits. Our current choice is Fabricator. It does a great job of documenting toolkit components and generating production-ready assets, but currently doesn’t address the problem of sharing HTML.

The holy grail of using the HTML from toolkit components in our products may be achieved with a new crop of tooling, notably Fractal.

Fractal is made by the Brighton-based web design agency Clearleft. It aims to address the problem of sharing HTML with live websites by making it easy to use a templating engine that suits one’s needs.

There are some technology hurdles to overcome, but we’re extremely excited with the progress made so far. We’re already starting to see the benefits of using a toolkit. Quicker development, easier maintenance and a more consistent user experience is not just good for the developers, it’s good for our clients and their users too.