search

asyncapi / brand

AsyncAPI brand guidelines and strategy
6 stars 6 forks source link

Design system: define foundation #22

Closed mcturco closed 2 years ago

mcturco commented 2 years ago

In this issue, we will discuss what AsyncAPI needs the most out of a design system and what those building blocks look like.

The foundation of this design system should include the smaller pieces:

I am thinking this particular design system will be mostly focused towards the AsyncAPI React Component as other things like the website and marketing materials will fall under their own systems (those are not in high priority at this time).

Once we define the base structure, we can begin to iterate on design patterns, starting at a smaller scale. Some examples of smaller design patterns might include the following:

And the list can go on from there. I am thinking once we have a solid foundation, we can move into creating a UI kit that represents the spec.

fmvilas commented 2 years ago

To add a few more:

imabp commented 2 years ago

🌠 This is great @mcturco ! We can start with!!

Style Guide which will allow multiple contributors to create content clearly that cohesively represents the brand It should have the base colors, accent colors, primary colors, hover colors.

Component Library As @fmvilas mentioned, we can create components, following the style guide.

Design System Once we are done with both the things, we can publish it via storybook as Design System for AsyncAPI.

Open to suggestions

mcturco commented 2 years ago

Hi @imabp! Glad to have more support in design!!

Style Guide - see this open PR where the new brand guidelines pages were added to the website. I am currently working on the layout for each page and will present to the team for feedback hopefully by the end of the week!

Component Library - absolutely. There are a few different applications that we will need to make components for: Website, HTML Template/AsyncAPI React Component, Tooling (in general). This will be a WIP over time!

Design System - yes! I think the design system will be a WIP even starting now. I have published the current version of the design system here if you would like to take a look. And yes I think publishing it in storybook is awesome, but wondering if in the future we can add each component to the website as well with code blocks for copying and pasting code for each component.

imabp commented 2 years ago

Hey @mcturco Thank you :)

magicmatatjahu commented 2 years ago

@mcturco @fmvilas @imabp

Hello everyone!

And the list can go on from there. I am thinking once we have a solid foundation, we can move into creating a UI kit that represents the spec.

What do you think, when we should create such a kit (I guess we should have repo for this, yes)? Already we have old issue in the react-component repo where we discuss about renaming that repo (you can read it here) and one of the option is to rename mentioned repo to the ui (or maybe more elegant name 😄 ) and start creating that UI kit there. Another option is create new repo and start implementing that design system in new one. How long it takes to clarify our needs for that design system? I don't think so that we should wait few months to start writing component, we can do it also now and then adjust components with final aggrements about colors/grid system etc.

One time Fran told me that we should go with this direction and I am 100% for that:

And there are few suggestions about components:

magicmatatjahu commented 2 years ago

So what's then? I understand that the whole design system as well as UI kit will take some time, but we have to remember that components (in React) are not only styles but mainly logic and proper architecture that allows the composition of components. I would be in favor of creating a new repo or swapping existing one and start writing components and testing them and then we can add styles. The problem may be in the future lack of time if we will be in the final stage of 3.0.0 version of AsyncAPI integration in our ecosystem and atm we have some free time to start new project.

cc @mcturco @fmvilas @imabp @ayushsoni1010 @yashsehgal

yashsehgal commented 2 years ago

So what's then? I understand that the whole design system as well as UI kit will take some time, but we have to remember that components (in React) are not only styles but mainly logic and proper architecture that allows the composition of components. I would be in favor of creating a new repo or swapping existing one and start writing components and testing them and then we can add styles. The problem may be in the future lack of time if we will be in the final stage of 3.0.0 version of AsyncAPI integration in our ecosystem and atm we have some free time to start new project.

cc @mcturco @fmvilas @imabp @ayushsoni1010 @yashsehgal

Yeah, I think that's a great idea @magicmatatjahu, we can start writing the components in React, which are already designed and ready to go with. Like typography, color palette and buttons. What's your POV on this @mcturco, what components + styles we can start with?

mcturco commented 2 years ago

@magicmatatjahu @yashsehgal Yeah I have no problem with the idea of starting a new repo and building the components as we design them. I think as long as the designers and developers that are working on this are both aligned at all times with the new changes, it shouldn't be a problem.

I think the only thing I would like to bring up is the difference between a design system and a UI kit. The design system is to serve as a standard for all visual elements and the UI kit is to be a collection of larger components that can be used by developers in this org making contributions. The biggest gray area for me is the fact that we will need UI elements across the 3 different types of platforms the org currently has:

  1. Website
  2. Tooling
  3. Documentation Template

I am curious to know what others think about how we should move forward with this. Our top priority right now is creating a UI kit for the Documentation Template. (Forgive me if that's not the right label, not too sure what to call that without confusion)

magicmatatjahu commented 2 years ago

Yes, you mentioned to me that we will have 3 "areas" with our design, but it's not a problem for us. Even if we should prioritize that "documentation" area (I guess you have react-component in mind) I think we need that same components for each area like buttons, forms, headings, grid system, so we can create base of all of it and then adjust for given area. Logic (I mean JS logic) will be the same but styling will be different. Of course there can be another components only for given area, but it's not a problem at all :)

fmvilas commented 2 years ago

Logic (I mean JS logic) will be the same but styling will be different.

@magicmatatjahu watch out because some components will not change just in style but the component entirely. For instance, instead of rendering cards for each server, we might choose to use a Tabs component. I'm sure we'll do a lot of these changes so my recommendation is that y'all start aligning first with wireframes and mockups.

And speaking of logic vs styles. I'd consider doing something like https://headlessui.dev/. These are components without styles and without markup (HTML), just logic, i.e., "headless" components. This leaves the door open for high customization from our users.

The problem may be in the future lack of time if we will be in the final stage of 3.0.0 version of AsyncAPI integration in our ecosystem and atm we have some free time to start new project.

That shouldn't be a problem. We're not in a rush :) I think it's important we don't apply pressure on designers so they can come up with the best solution instead of just something that's good enough. We've been using the current designs for over two years. It's ok if we stay like this a bit more :) Let's favor quality over speed.

magicmatatjahu commented 2 years ago

watch out because some components will not change just in style but the component entirely. For instance, instead of rendering cards for each server, we might choose to use a Tabs component. I'm sure we'll do a lot of these changes so my recommendation is that y'all start aligning first with wireframes and mockups.

Just how does this relate to my previous comment? I'm not talking about writing Server or Message components right now, just smaller ones. We will need both Tabs/Tab and Card components. Composition of these components is the song of the future. And I already mentioned about https://headlessui.dev/ in an earlier comment 😄

mcturco commented 2 years ago

I suggested this on slack, but looping the idea into this discussion:

I am wondering if we should create a separate repo for design-system or even rename this repo to that and then use it as a sandbox for developing new components. Since the design system might have shared components across the 3 UI kits that we will need to make, maybe we develop them here first and then when they are finalized they can get moved into the asyncapi-react (which that repo also needs to be renamed 😅 )

magicmatatjahu commented 2 years ago

@mcturco I think that we should go with different repo, design-system is good, then we can later rename it to e.g. elon 😆 brand should stay to brand stuff and design-system to design (including UI Kit). About asyncapi-react we can rename it, but not now. Probably we should have separation for UI kit as reusable components and asyncapi-react for UI docs, but is a discussion for future :)

fmvilas commented 2 years ago

Just how does this relate to my previous comment? I'm not talking about writing Server or Message components right now, just smaller ones. We will need both Tabs/Tab and Card components. Composition of these components is the song of the future. And I already mentioned about https://headlessui.dev/ in an earlier comment 😄

Sorry, I thought you wanted to start rebuilding the other components. And yeah, you mentioned Headless UI 10 days ago, that's like a century for me 😅

mcturco commented 2 years ago

I think that we should go with different repo, design-system is good, then we can later rename it to e.g. elon 😆

Haha @magicmatatjahu you're really pushing for the elon name aren't you! 😆 Yeah I agree that we should create a new repo for design-system. I don't have permissions to create new repos in the org, so pinging @derberg... maybe he can help us create the new repo 👍

mcturco commented 2 years ago

Closing this issue as we have the design-system repo now to handle this!