Roadmap

[Cybertron01Z]

I have following Roadmap in mind. Please correct or extend it :)

1. We need to get the components to the latest state

• @DanOlaru / @culas / @r3dDoX move fixes/enhancements from your project to this repo
• Please sync / create tickets for this matter :)

2. We have a new way of using Figma (Figma Variables)

• Make the new variable tokens work. See this branch for inspiration
• Move all components to the new token format

3. Theme support

• With Figma Variables we can now do themes (Light/Dark Theme)
• We need to enable support for those themes => theme name should be generic

4. Create example applications with the design systen (Angular, React, maybe Vue)
5. Breakpoint support

• With Figma Variables we can now do breakpoints -> one variable has different values depending on the breakpoint

6. Restyling

• The current style of the components is very coorporate (I do not like it too much :D)
• We should do a complete restyle of all components

7. Extend component library with more components

• we should have as many components as possible (ofc only if they make sense), this will make the whole starter more appealing

[r3dDoX]

Sounds solid! I will make sure to finish my documentation PR soon.

There are a few unknowns in there, like themes and the different values per breakpoint. Depending on how generic this should work, we might need a bit of brainstorming for how this can work best in the components.

I would not put too much work into point 5 and 7. For this project it is more relevant to have a working solid approach than to have a fresh design and a ton of components.

[Cybertron01Z]

Regarding the themes and breakpoints. We have some ideas for those topics, however they are driven by what Figma can do now with variables. I think it would make sense to have a meeting with the UX folks once we have integrated and migrated to the new Figma Variables (I hope this won't be a lot of work).

And regarding point 5 and 7. I knew that you won't be a big fan of them :D But that is why it is rather low on the list. Once we have a stable and nicely integrated system, I think we should look at the point of making in appealing. Just because I believe that a first look matters. But as I said, this has absolutely no prio, but I think we should put it anyways on the list.

Also my plan is to do a hackathon day soonish. I will open up the invitation to the web paltform topic team. I hope that since we presented the system last z-day we were able to convince some people to help out.
But I think we should do this once point 1 and 2 are done.

[culas]

From what I've seen from Christian's work, the change to the variables shouldn't be too big of a change. But let's see. 🤞

I agree with Patrick (unsurprisingly to you Mika ;) ) and would even argue that example apps should move from 6 to 4. Having these will make it a lot easier to show of the design system's power and simplicity (from the perspective of app developers). We can just point to the respective app to show them how it's integrated and used.

[Cybertron01Z]

Yeah fair enough, I updated the roadmap and moved the example apps to 4. My thought was that if we add breakpoint support and do the restyling before we would only need to touch the example apps once. But I guess we can improve them over time :D

[r3dDoX]

Totally agree with you two! I just finished my documentation branch yesterday night and opened up a branch for gh pages deployment. So we have a running visible version of it. I'm totally down for a meeting soonish. I think the whole theming is super interesting and relevant! There is also the question of lazy loading themes, I just see that now at my customer, our variables are so big that the resulting CSS is around 6kB just for all the variables. If you multiply this for 3 themes you probably want this lazy loaded.

One thing that I just remembered again, with the example apps, we should definitely also show what's possible with SSR and where it might not work.

[aendu]

Here my 2 cents on the roadmap

First off, thx for putting a roadmap proposal up and starting the discussion around it! ❤️

To consider in 2./3. there is a new api from figma to read variables. I did not look into it yet, but maybe this would make the use of a 3rd party plugin obsolete.

4. I like the idea of an example app very much. :-)

5. (breakpoints)
   How would this support look like? Probably we would need more in figma for this to actually work, outside of just having the definitions.

Regarding 6. (redesign)
The idea was always to have it very simple (and kind a boring) but its not necessarily meant to be used this way.
Also most of the time our clients are corporations ;-)
That said, if anyone has improvements that don't take away the simplicity, i'm all in for it.
I would rather have the example apps have a very nice look as to say:
"With our DS-starter you can take your cool design and wrap it in a design system."

Regarding 7. (components)
Again, it is a design system starter, not an "out of the box design system" (like google material or similar)
So we should have covered what most application use and maybe a couple of nice extras, but the more complex the components get, the more they are part of the design language and need much more detail work than just some variable updates.

Ok, that was probably more like 💰 than 2 cent 😄

[Cybertron01Z]

Thank you for your detailed 2 cents 😉

Regarding the new api from figma do you mean this? If so we can for sure look into it. Maybe we can even automate it. For example we could automatically create a PR once it detects changes in the variables. This would be really cool, since in the PR you could then see the changes from Figma directly in Chromatic as well.

Regarding your comment to number 5. Lou and Christian came up with the idea and I very much like it. I think none of us are really sure yet how this could look. So I think once we come to this point, we should do a kickoff meeting to see what is feasible :)

Regarding the "it is a design system starter" point. I agree with you.
But for example bids where we do not have much time, I do believe having a nice looking starting point, where we can just slap the colors of the company on is very valuable. And it is just my personal taste, I do not fancy the design of the starter right now. And as I said in one of my answers above, I do not give it any priority. But I am sure we can do better than what we have right now :)

The other point you are talking about is simplicity. I do see your point, but I do believe that we should add complicated components. And we can try to make it depend on figma as much as we can. But in the end, if a project chooses this starter and they do not like a component, they can just delete it and write their own version of it. But imagine a project is going to use it, a lot of time was saved since they did not have to implement it themselves. I do not have an example of such a complicated component right now (datepicker is already implemented ^^).

But we need to always have maintainablity in mind, because we work on this in a very limited capability. So take my last point about the simplicity with a grain of salt, I just think very big and I do belive this can be a very cool project that can help jumpstart a lot of other cool projects. So I want this to be as good as it can be.

[aendu]

Just looked into the APIs a bit.
It still seems as if we would need to build sort of a figma object to design token mapper ourselves (basically what the plugin does) or i got it completely wrong...

I hoped with the announcement about code-connect they made some weeks back, the support for design tokens would be more natively. But it does not seem to be the case.

I think the view point about bids make sense, but again i would encourage to have maybe 2 figma branches with customised examples that can be copied and further customised for the specific bid. but maybe this is overkill ;-)

I can give you a lot of examples of complex components, but as said earlier - there is not much value in it as they are dependent on much more than just colors, sizes and fonts - here some examples:

• Page header
• Profile popover
• Main / sub Navigation
• Search result box
• Empty states
• etc.

Maybe you have something different in mind, then please let me know!

[r3dDoX]

@aendu, I see it the same way, this REST API is quite cool, but not in a design token format. So if I'm not missing it, we lack certain info we need for how these variables are supposed to be used. Is it a font-family is it a color and so on.

At my current customer we work with breakpoints quite a bit. CSS custom props are runtime variables and therefore can be changed on certain breakpoints like this:

:root {
  --test-var: 1;

  @media (min-width: 1024px) {
    --test-var: 2;
  }
}

One very annoying thing though: we can't use custom props in mediaqueries yet... So you can't just write @media(min-width: var(--my-breakpoint)).