Your submission was sent successfully! Close

Thank you for signing up for our newsletter!
In these regular emails you will find the latest updates from Canonical and upcoming events where you can meet our team.Close

Thank you for contacting our team. We will be in touch shortly.Close

  1. Blog
  2. Article

Karl Waghorn-Moyce
on 21 November 2019


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
Vanilla framework repo proposals

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.

Heading icon design spec

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.

Modifying a component

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?
Step-by-step process

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.

Component status table

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!


Related posts


Bartek Szopka
10 January 2022

Release of Vanilla framework v3.0

Ubuntu Article

We’ve just released Vanilla v3.0 – a new major update to our CSS framework. It includes a few significant updates and improvements around spacing variables, responsive breakpoints, a new expanding search box and various updates to existing components. Important aspects of the release include dropping a noticeable chunk of deprecated style ...


Bartek Szopka
18 July 2023

Vanilla 4.0 release

Design Article

Last week we released a new major version of the Vanilla framework. Vanilla 4.0 introduces the elements of the new style used for a current rebranding of Canonical’s brochure websites, including typography changes of headings utilising new variable Ubuntu font, wider grid width, removed rounded corners, some updated colours, and updates t ...


bethcollins
17 March 2022

How we implemented an interactive Live Demo Box

Design Article

The Vanilla squad recently spent a two week sprint prototyping an interactive live demo box. We were tasked with coming up with a proof of concept, to enable demoing of each variant of our examples dynamically. A few guest developers were able to joined us, which meant four of us were able to dedicate a ...