Getting Vanilla ready for v1: the roadmap

We have been using our front end framework Vanilla across our sites for a while now, so it might surprise you to know that its first official version (let’s call it v1) hasn’t yet been released.

In preparation for v1 (which we are tentatively aiming for early September), there are a few tasks that we have been, and will be, working on to make sure that Vanilla is as robust as we can make it, and to make the process of using and improving it clear.

Future-thinking: defining a high level roadmap

It’s important that long-term, ongoing projects have defined goals that people can focus on and strive for. Having short, mid and long-term goals makes it easier to prioritise and concentrate efforts on tasks that will get you closer to achieving the ultimate vision for the project.

The first thing we did in order to outline a roadmap for Vanilla was to collect all the things that we felt needed to happen for it to be ready for release, things we’d like to improve, and wishlist items that might not be urgent but that we would like to tackle at some point in the future.

With this list at hand, we organised the tasks by priority and added them to a roadmap board in Trello, which is open for anyone to have a look at. You can see which tasks we are working on during the current two-week sprint, and which tasks are queued to be done next.

The Vanilla framework roadmap Trello board

Contributing: defining the process for adding new patterns

Releasing Vanilla v1 does not mean that Vanilla will then be finished. As a working style guide that is used across Canonical on various different projects with different needs, new patterns will emerge and existing ones will have to be improved to be more flexible.

We thought that it would be good to document the process that a pattern should follow in order to become a Vanilla pattern, so after a little bit of brainstorming, we created a diagram that shows the different steps that should be taken from before submitting a pattern proposal to its full acceptance as a Vanilla pattern.

Most of the steps in the diagram happen in just a few seconds, but it is good to be able to visualise the entire process.

Diagram of the process to submit a new pattern to Vanilla

As Vanilla itself, this process diagram is not really finished. Once we start using it more frequently, we will probably have to make some adjustments to improve it. Also, there are a few branches of the process that we still need to include, namely how a pattern is added to a theme as opposed to the main Vanilla framework, and how an existing pattern (in a website of Vanilla theme) can be promoted to Vanilla.

As part of this task, we also updated the existing GitHub template that pops up when you submit a new issue on the Vanilla repository to include the option of submitting a pattern proposal.

The proposals will be reviewed on a fortnightly basis by the web team during the Vanilla working group meetings. We are pondering how we can make these meetings open to anyone who’d like to participate, as we know that lots of you would like to contribute with new patterns and improvements. We’d be happy to hear your ideas on how this could work.

Defining browser support guidelines

While internally, in the web team, we tend to agree on and follow consistent browser support guidelines, the process isn’t documented.

We want to make sure that Vanilla is built following the latest web standards, and that people can build sites with it that will work on as many form factors as possible, so we thought defining the browser support guidelines that we want contributors to follow was a vital step in preparation for the v1 release.

The document isn’t yet finished, but we are working on it as we speak and will be sharing it soon enough.

Future tasks

You can see the roadmap that we have planned for Vanilla in preparation for v1 and after in Trello, but there are few key tasks that we want to carry out before September that we’d like to highlight:

• Defining the accessibility standards that all patterns will have to follow, and adding automated tests to the build process to ensure they are adhered to
• Conducting an internal accessibility audit and making as many changes as we can to improve accessibility
• Redesigning the dedicated Vanilla website to include the new documentation we are writing and other pieces of useful information, including the style guide itself — all living together in one single site
• And, obviously, making sure that Vanilla has its own logo — as any respectable framework does :)

Final words

This is all from me for now! Barry is writing a companion post that will go into more detail about the technical tasks that are being done on Vanilla, which he will be publishing soon.

We would love to know if you have any ideas on how to improve Vanilla — share your thoughts in the comments.

Originally published at design.canonical.com.