Home
Goals for this project:
- Create a single source of truth for visual design across AsyncAPI UI
- Increase efficiency of contributions by defining reusable component libraries
- Promote consistency of visual style
- Decrease time spent on frontend code
- Write documentation and guides for usage and contributions
What does the roadmap look like for achieving these goals?
| Step | Description |
|---|---|
| Step 1 | Understand the reasons why we need the system and what applications it will be serving |
| Step 2 | Define the foundations |
| Step 3 | Establish the problems with the current UI (Research) |
| Step 4 | Iterative design process: Design -> Develop -> Test -> Iterate -> Release (On each component/component group) |
| Step 5 | Write developer-friendly documentation |
We are currently trying to understand how this design system is going to serve the different facets of the AsyncAPI org. We want to make sure that we are not creating a design system for the sake of creating a design system, but that by doing so we are constantly thinking about where it will come into play.
The overall "plan of attack" is definitely not set in stone and is subject to change as we grow, but here is what we are thinking as far as structuring the design system to meet our needs.
The visual output you see in the AsyncAPI Studio is what we are calling the Documentation template, at least for now until we come up with a more unique name. The UI that gets automatically generated as you write your AsyncAPI spec in the editor is what we will focus on for the first part of the design system - in which we are calling it a sub-system.
Now, we don't believe that this sub-system has to be necessarily a full-blown design system in and of itself, but establishing design patterns that are consistent throughout the UI is visibly needed. We also have to take into account who this tool is for, and how they might edit this template to fit into their own design systems, so things like naming conventions and customization options will largely come into play here.
Right now, the only UI tool that is official in the AsyncAPI org is the Studio mentioned above. Since tools/products are ever-changing, it might be the most useful to its progression to implement a full design system approach for this sub-system.
The plan for the product/tool level of the org is to define a system that will always serve as the single source of truth for any contributions made to the AsyncAPI UI tools. You might ask, "how is this approach different than the others?" While it is a tricky question to answer (and we are still sort of asking ourselves these questions), the main difference is that this system will be ever-changing as more features and capabilities are explored and offered through AsyncAPI tooling.
This system might include the following approaches:
- Storybook repo for documenting and testing components of the system
- npm package for releasing updates and new components into the system
- QC process for ensuring that the design and function of each component instance aligns with the master component
The idea here is that we will never stop evolving this system to meet the needs of the tools in our org as we advance.
Although the current website looks great from the viewer's POV, we can definitely work to improve the design from a marketing standpoint as well as work to organize components to be reusable and scalable for our contributors. For this reason, it might be smart to build a UI kit/component library that contains all the sections that you might need to create a new page or update an existing one, all while complying with the brand principles.
The approach to these components will definitely be more brand-focused than the product/tool level approach, as the website is intended to show what the initiative offers and how to get started.
We are currently brainstorming a name for our new design system. Leave your idea here ->
The road on this journey is long, and we need your help to make the best out of it! At AsyncAPI, we value our community and always strive to make our work as transparent and collaborative as possible, which is why we encourage contributions of every kind: whether it's in the form of thoughts, ideas, code, documentation, etc. We are better together! Have an idea? Post an issue ->
Stay up-to-date with the latest, ask a question, talk about the weather, or chat with us! Join our Slack workspace ->