The lifecycle of a component

Vanilla Framework is a living design system for our products that will grow along with our organisation.

Vanilla’s component library is used by many internal and external websites along with the cloud applications JAAS dashboard and MAAS UI. We release updates approximately every 2 weeks, either for bug fixes, improvements or new components. All members of the team can make changes once discussed and agreed upon. We then review and QA carefully before pushing the code to our master branch.

Which in turn makes the component lifecycle a very complex thing to manage.

Pitch proposal

Components are reusable parts of the user interface intended to support a variety of websites and applications throughout Canonical.

Individual components can be used in a variety of different patterns and contexts. For example, the text input component can be used to ask for an email address, card number or password.

With any design system, there needs to be an approval process to stop bespoke components that belong in just one project being introduced into our suite of products. In order to formalise the introduction of new components, we introduced a bi-weekly Vanilla working group for both designers, developers and anyone else with an interest in the framework to:

• Discuss new and existing Vanilla components
• Look at proposals in the GitHub project
• Discuss any other issues, questions, etc

This meeting has proven a success, allowing every member of the Web and Design team to be involved with the framework, and have sight of new and upcoming features. If you’d like to propose a new component or amend an existing one, you can do this via GitHub using our proposal templates.

Design specification

Once a component is validated in the working group meeting, we add it to our backlog for design and/or build. Dependant on whether it’s an update or a new component.

Once the new component has been through design exploration, accessibility testing, and final sign-off. It’s ready to handover to development to build. With any new or existing component we create individual specs which consist of:

1. Visual 
2. Markdown file

As illustrated below the visual shows what the component should look like. And a markdown file that defines the fonts, color, paddings, margins, etc.

Improve or remove

Modify

When any component is needed in a specific section of a website or application, it might need some adjustments and modifications. As a team, we try to find the right balance between flexibility and consistency. Keeping the principles of the framework at the forefront of our minds as we make these decisions.

Above in the illustrated example. We have an existing contextual menu on the left, but in two separate applications, we have two different styles; adding icons, positioning, paddings, etc.

To provide flexibility and consistency, we modified the component to allow icons the ability to be positioned left or right. As well as adding a class to change a button; our default neutral style to any button style you desire.

Deprecating components

When deprecating components in the framework, we’re careful not to remove unnecessary pieces that can cause project regressions. We’re actively reviewing components to ask ourselves:

• Are we actively using the component?
• Could we build it from existing components?
• Has there been an impact on the file size?

When deprecating components in Vanilla, we have a process of removing and should no longer be used in projects. We make the team aware of this in our release notes and newsletter when upgrading Vanilla to a new version.

Status

When we add, make significant updates, or deprecate a component. We update their status so that it’s clear what’s available to use. We’ve created a component status page that documents the component, its status and provides notes with high-level information.

Better consistency and collaboration

A component-based design system breeds visual and functional consistency. In Vanilla, we keep components lightweight using base style elements, on top of which we add classes to define patterns. Having this control enables us to keep styles composable and reusable while keeping a focus on consistency. 

Components encourage better collaboration between design and development, allowing your design language to evolve over time. Ideally, what we see inside our Sketch library is what we build with HTML/CSS and React. And that’s what we continue to do in our workflow.

Consistency and collaboration is everything!