Front-end Architecture by Unknown

Author:Unknown
Language: eng
Format: mobi, epub, pdf

Project Alpha

This past year I was given an opportunity of a lifetime when asked to architect a solution for Red Hat that would let them share their existing website “bands” across multiple company web properties. Having been on the initial build of Redhat.com I knew the challenge ahead of me, but it also meant that I’d had time to establish the development team’s trust, and was given full control over the entire architecture of this project.

I call this an opportunity of a lifetime because it was! Our chicken or egg dilemma had been cracked. My team was given the opportunity to build a design system of significant scale, with sufficient technical support, that would eventually be displayed on a site with an incredible amount of traffic. This would be the project that I’d use to promote Front-end Architecture to my next project...and the project after that.

A Slow, Powerful Start

Our team was incredibly fortunate to be working with Red Hat at that particular time. Having just launched the original site redesign we were in a bit of a feature moratorium. This meant, while we occasionally had a couple bugs to squash, we were otherwise freed up for a number of months to explore ideas of how we’d create and distribute this shared library.

Dispute the sheer amount of legacy code still in production at Redhat.com we were given a blank slate to work with. As a website built on the concept of bands (row after row of unique content), we were fortunate to have a very clean global style state, and the new elements we built would sit under or over existing bands. There were no sidebar styles to override, no HTML tag styles constantly changing around us. We were practically building a brand new website right inside the old one. And just like replacing every board on a ship, one by one, we are hopeful that we could eventually retire the old theme system, and rely solely on our own.

With such freedom in front of us we knew we had an opportunity to create a large wish list....and actually get most of it! That wish list included:

Modular Content - We were big fans of atomic design principals and wanted to reuse small components rather than creating unique band after unique band

Exhaustive documentation - With a large team of front-end developers, back-end developers, designers, marketing managers, ops and various product owners, we had a HUGE audience. We wanted to make sure that whatever we built had documentation that met each one of their needs.

Comprehensive testing - We’d been burned too many times by large chunks of front-end code being merged into master breaking code written months prior. So we were determined to test our design system with the same level of coverage as we had at the application level with behavior testing.

Streamlined processes - We wanted to mirror the git flow system that worked so well at the application level, but we needed to break feature branches into smaller component sized code chunks.

Download

Copyright Disclaimer:
This site does not store any files on its server. We only index and link to content provided by other sites. Please contact the content providers to delete copyright contents if any and email us, we'll remove relevant links or contents immediately.