ES Styleguide

EdSurge Styleguide is designed to provide simplicity and consistency across EdSurge's websites and applications.

Initiative Details

The Foundational Styleguide is a collection of the global pieces that provide the baseline for our brand's look and feel that are built upon by the Patterns Library and implementation. It includes the definition (in CSS & Design) of our colors, types, forms, buttons, and general look feel and layout of how we present our digital media.

So Why Do We Need this?

By canonicalizing our common visual elements into a reusable theme, we create a corpus of design that is reusable across systems, applications, teams, and designers. It helps contribute to a unified look and feel of our digital properties enhancing our brand and visual style. Developing this 'global theme' will decrease overall decision and implementation costs for designers and developers in producing new digital assets and materials by not having to re-invent the wheel and leveraging the product of previous investment (of time and resources). Additionally, this leads to more contiguous integrations that are the same across the 'website' and applications requiring less code review, questions, QA, etc.

Why A Separate Codebase?

Developing a styleguide is hard. Developing a styleguide with the scope of the full universe of the organization's needs while within a subcontext of _one_ of the applications makes it even more difficult. The purpose of a styleguide is to serve the broader team and organization, and for it to be resilient to the changing needs of the individual applications.

Everything in here can be overridden, re-classed, etc.

We seek to develop this corpus of material in a separate application for a few primary reasons

  • It forces us to think globally vs thinking locally because the other styles and classes in the applications are not present
  • It forces us to ask the question "Is this important to the universe of style and patterns at EdSurge?"
  • It forces us to develop our design language in a way that is agnostic of development framework. We won't design bound to the constructs of React, or Rails, or Angular. We can do it as pure as possible in plain SCSS.
  • It forces us to adhere to our release guidelines - we must package releases and follow the steps we put in place to make it available to the other applications.
  • It makes inadvertently modifying global framework needs to suit anapplication an impossibility. It can still be done at the localapplication level, but you're not modifying the framework for others
  • It mitigates system-level changes from wreaking havoc on other stylistic needs. Our design framework becomes more durable and fault-tolerant.
  • Our styleguide becomes versioned and apps can bind to these versionsfor compatibility sake

Of course, there are a few downsides to having a separate application

  • Our global design changes are not immediately available in a given application. You must go through the review, release, and update process to get changes reflected in the local apps
  • It requires a team of maintainers instead of just the people who maintain a codebase
  • It adds process - changes can't be shotgunned to `master`. There is a change management process and changes need tested and QA'd before version release