While working on VS Code extensions in the Developer Division, I saw the need for a more cohesive set of UI/UX patterns and controls for webviews in VS Code. The extension toolkit is a UI component library for designers and developers to use while building web views for their VS Code extensions.
I initiated this project because I saw a need while working on other projects within team. I lead the initial effort for the toolkit (design, research, and documentation).
Visual Studio Code (VS Code) is a light-weight, open source, code editor that can be customized through first and third-party extensions.
Without extensions, VS Code is a pretty simple text editor, but the extensions bring a lot of the magic. Extensions can provide features like language support, special debugging features, data visualization, etc.
A web view is an iframe within VS Code that an extension controls.
While I was working as an extension designer I continued to run into the same few issues no matter project. I also realized other designers and engineers across Microsoft were struggling to create cohesive extensions for VS Code for a few reasons:
No design system or pre-defined patterns resulted in designers and engineers alike creating one-off solutions. This wasn’t very efficient and lead to more fit-and-finish errors and product inconsistency. Designers not family with VS Code also struggled because the existing patterns and best practices were not well documented at the time.
Maintaining a custom UI is costly and can lead to a number of issues ranging from minor fit and finish bugs to larger accessibility bugs. One of the biggest complaints we heard from teams was integrating VS Code’s color tokens was confusing and sometimes difficult because the tokens had very specific names and use cases. This process requires a deep understanding of how VS Code's color themes work and the ability to predict how other themes handle colors. This is easier when it comes to the themes that ship with the product, but becomes more difficult when third-party themes are introduced.
When I looked across the landscape of first and third party extensions, I realized there were a lot of different design needs. Some applications just needed a data grid, some wanted to make a simple GUI introducing their product, and other wanted to create complex dashboards and experiences all within the webview. That’s a pretty big range of needs, but I decided to start with something I knew and use the Fluent Web design system as a base.
Fluent is Microsoft’s design language and Fluent Web is library of components specific to web applications. I chose this as a starting point because one of my main goals was to improve the experience for designers working inside of Microsoft and many of those creating extensions around the company were converting products and experiences already made in Fluent Web into experiences for VS Code.
After assessing my own experiences and the experiences of other designers and engineers working across Microsoft I had my ah-ha moment. I decided I should createa library of controls to share with the greater VS Code community, in turn making it easier for people to design and build extensions and eventually making a more cohesive product and customer experience.
As I mentioned above, I used the Fluent Web design library as a basis for my new webview toolkit. I audited all the controls and met with the primary VS Code designer, Miguel Solorio, to determine which pieces we felt should and should not be included in our own set.
I then began building out the components in Figma. All of the components are built using Auto Layout, a feature that allows the components to adjust in size driven by things like the amount of text, the number of assets, etc.
The design toolkit includes:
Figma toolkits allow designers consuming the library to gain access to components and styles and use them in other files. Updates to the component library file also appear in files consuming the library. Makes life a bit easier :)
I met with five designers working in different parts of Microsoft that have worked on VS Code extensions; one from Teams, two from the Data Integration Team, and two on the Azure Data Studio team. In each of the interviews, I asked the participants to share their experience with Figma before jumping into discussing the toolkit. The participants ranged in experience, some have only been using Figma for a month or so, while others have been using it for over a year. All the participants had prior experience using toolkits and libraries and only one or two had experience using Auto Layout in Figma.
All of the participants were able to navigate the toolkit and find different components. When it came to consuming the components in another file, some participants used the Assets panel in Figma, while others preferred to copy and paste components from the toolkit file. All of the participants discussed having a difficult time figuring out best practices for webviews in VS Code. Some mentioned looking for guidance in the VS Code Docs but said they couldn't find any. Three of the participants said they would like to see documentation explaining the different surfaces available in VS Code and how to use them.
In addition to the study I ran with designers form across Microsoft, I also worked closely with different designers on my team who use Figma toolkits in their day-to-day. This project was during the early stages of component libraries at Microsoft so it was helpful to get feedback from designers using a variety of toolkits that were organized and maintained in a variety of different ways.
As with most, if not all, projects there's always a time when you move on to something else and another designer takes over. Towards the end of my time working on the toolkit, I knew I was transitioning to a more branding and visual design oriented role. This made me want to make sure the project was in a good state to hand off and easy for others to pick up where I left off.
I determined we needed basic guidelines stating when to use what controls, how they should and should not be used, etc. Because our toolkit was heavily based on the Fluent Web Framework, I was able to heavily leverage the existing documentation and guidelines. I only needed to rework some of the guidelines for our specific use cases.
As a part of this “final prep process” I cleaned up all the files, created documentation, and compiled notes to hand off to any future designers and developers working on the project. A few months after shipping our initial design library, a design technologist, Hawk Ticehurst, began building out web components for extension developers to use when creating their own extensions. Fellow DevDiv designer, David Dossett, later joined the team and began working on the toolkit. Version 1.0 of the toolkit launched on April 7, 2022.
I was struggling with a lack of documentation and guidance, and I worked on the larger design team! This problem was even more significant for folks who couldn’t just walk up to the product designers or developers and ask questions. By solving the problem I was personally facing, I ended up helping a lot of other people.
The best solutions aren't very helpful if people don't know about it. While developing a carefully thought out system was really important, it was also really important to share these resources with the larger community. This is not a one time thing, but a regular action that needs to be taken so everyone is included and made aware of the resources they can use.
Theming extensions in VS Code still remains a challenge for people building their own custom UI, but the toolkit made this issue a bit easier.