Support Design System Package import/export

[romanr]

Thanks for the great library!
The missing link between design and development is ability to import and export to/from flexColorScheme.

Figma, AdobeXD, Material Theme Builder all support Design System Package (DSP) format.

Import is more difficult to implement, but if we have at least export to JSON, that will create essential link between flexColorScheme and design workflow.
I'll be glad to help with documentation or anything else.

[rydmike]

The Themes Playground is a the moment only a tool intended to help Flutter developers that do not want to use the FlexColorScheme package API directly, to make an API configuration using the Playground as a visual and interactive API configuration tool and then copy-paste the FlexColorScheme API code for viewed configuration.

The Playground was originally even just a tutorial step to show an example of how you can make an app that supports in-app dynamic theming, as done in examples 2 to 5. Example 5, is the Themes Playground app, it is built and deployed from there.

Over time the Playground grew into something quite a bit more, than just a tutorial step. It is still however not the product, the package FlexColorScheme is. Due to the Playground's humble roots, it has the same very simplistic architecture as example 2, 3 and 4. If you look them, it may be a bit surprising, that you even can build a thing like the Playground, with such a simple Flutter architecture.

The current architecture used in the Playground is however a bit of a roadblock for adding features that venture outside of what it does now, as it was all it was planned to do. It does for example not have a proper data model that can be conveniently converted to JSON or any other serializable format, for export or import. It just has a large bunch of individual key-value pair settings that are persisted in local storage. The storage keys and properties they impact, are internal and do not represent the FCS API, that has strict version control promises, the Playground internal settings do not have that, their implementation have changed as needed.

The hand written and tuned code generation from Playground UI config props, to FlexColorScheme API output, could of course get another equivalent that would output some form of hand made JSON. As for if the DSP format referenced can be supported, I'm nor sure, perhaps. It depends on how well the FlexColorScheme API properties can be mapped to it.

Anything can of course be refactored, developed and changed. Potentially a future version of the Themes Playground might even do so. More thoughts on this topic can be found here https://docs.flexcolorscheme.com/playground#future-plans

More detailed requirements and ideas?

I would love to get some more input one what you are looking for. What would the process be like?

As I see, for it to work, I'm just spit balling here though, you would have to define theme's ColorScheme colors in FlexColorScheme, as well as the color mapping from ColorScheme to widgets/components, and other styles like border radius, elevation in the Themes Playground. Then you would export these styles and import them into Figma?

To get the same in Flutter, you also copy/paste the same Playground config as API config to Flutter.

You then design the app UIs in Figma using ColorScheme and component style defined in FlexColorScheme the was export from it and imported into Figma?

Once you have the UI designs done in Figma you would then build the UIs in Flutter?

Since the Figma design components and Flutter MaterialWidgets then share the same ColorScheme and other theme styling, the components would look the same automatically in Flutter like the Figma designs used, so they would automatically match? Is that the idea?

I don’t have a clear idea of what you are looking for and how you see the process working. I only wrote down what I though, perhaps might be feasible. I don’t use use Figma or AdoebXD personally, I have only tried them casually, have not really needed them. I do plan to spend some time getting up to speed on Figma and its Material and Flutter tooling later.

About the Material Theme Builder are you referring to this one?
https://github.com/material-foundation/material-theme-builder

It as two variants, the web builder https://m3.material.io/theme-builder#/dynamic
and a Figma plugin * https://www.figma.com/community/plugin/1034969338659738588/Material-Theme-Builder

As far as I see they only support colors, which is simpler than including all the component/widget theming/styling as well. In addition to obvious border radius and elevation changes, FCS does a lot of nuances to Material state interactions in Flutter too. I'm not sure yet if it is possible to make a Figma plugin that support all those features, perhaps. 😄

[romanr]

Once you have the UI designs done in Figma you would then build the UIs in Flutter?

Since the Figma design components and Flutter MaterialWidgets then share the same ColorScheme and other theme styling, the components would look the same automatically in Flutter like the Figma designs used, so they would automatically match? Is that the idea?

You're describing exactly how it happens, you got it :)

Project flow:
At the beginning of a project, design language is created first, it contain everything, chosen colours, fonts and other parameters like outline thickness and corner radius. The Design System is a document to keep all that together, it's used to communicate design to everyone including developers.
When developers go on to work on UI they have Design System as reference how things supposed to look. And actual product design that is done using same Design System.

Exporting to code:
Design Tokens is basically a set of variables that describe theme, not just colours but also fonts, distances, line heights, outline widths, corner radius, etc. This allows to standardise and automate transfer between design and code. Design system in Figma
There are plugins and tools that extract Figma variables into tokens to produce theme definition class for iOS , Android, Flutter, React, etc. and produce whole design systems out of tokens.

• Nobody wants for developers to apply styles to every widget one by one.
• If design changes were made to the theme, we don't want developer manually search-and-replace individual colors and theme parameters one by one. We can export theme class form Figma and replace existing theme class with new one, making whole app update its look at one and without any work.

With FlexColorScheme is part of workflow, it's not connected to design. I was thinking that importing from flex Colour Scheme into Flutter may work. But it is a slow process and creates new problems.
the direction:
Design and development process is going in direction of Design --> Design system --> Export tokens --> Add Generated code to project.
With tools like Theme Builder we can design colors and to update theme l all it takes is then push to project's git repository.
It's only logical to have FlexColorScheme import theme designed in previous step and be part of the process.

Semantic colors
There's other significant thing that this solves: externalising themes and making FlexColorScheme more open and integrable. Currently schemes seem to be defined as constants in lib/src/flex_colour.dart, as flat list and then transformed into schemes using arbitrary composition.
Theme composition is coded manually and it looks to me as semantic colour system, only it is not declared so.
For a good example of semantic colors in design systems check out this example: https://docs.tetrisly.com/foundation/colors#understanding-color-system - If colors have semantic references it would make themes configurations readable and clear.

Colours would be stored in JSON or Yaml. Such file can be generated in Figma or other design tool, then imported into Playground and code.

While FlexColorScheme offers a lot of variety in different fantastic schemes, it's fairly rigid towards adding new ones. You can make a copy and create custom theme in it, but it rather be done in Figma or similar tool.
And with most products you have to bring brand colors into scheme and build scheme on them, it's done in figma or other design tool.

[rydmike]

Thanks @romanr for taking the time to write down this and confirming the process, plus providing additional insights into it, much appreciated.

This is definitely something I would love to support and add in a more a more advanced refactored version of FlexColorScheme and Themes Playground.

It would also be interesting to add a new abstraction layer on top of Flutter's theming to support a more designer friendly design system, with semantic labels, while still using native ThemeData under the hood to produce the results in a Flutter native way.

The Tetrisly design system is a good example of it, thanks for the link.

Current version of FlexColorScheme was mainly made to help devs use and setup the rather confusing theming in Flutter. Plus to potentially in some cases use it to help them meet exceptions passed down from designers. There is is certainly a lot of room and areas to improve when moving into design process support.

Common custom approaches

Most big dev shops tend to have their own design system, that they built on top of Flutter to integrate with their design process. And big "app" companies do some variation of that too, but tuned exactly for their app and brand.

Sadly most that I have seen in Flutter, don't even use theming correctly and may often depend on custom component wrappers. Often using nicely semantic named const values as defaults in these wrappers, but only in rare cases to component themes, and if used, not consistently.

While this works, it is has the following limitations:

• Onboarding
  New devs must know the right replacement composed "custom" widgets to use instead to get the correct design. When you use a theme that matches your design, you can use all built-in Material widgets and they follow the design, no need for custom wrappers. Sure and of course complex composed new components you might use, is a separate case. You can handle those with custom themes and ThemeData theme extensions, if you want to be fancy. Still the bulk just becomes using vanilla Flutter widgets that fits by default. Devs don't have to think about it, just use them.

• Theme transitions
  If you bypass the Flutter theme, you loose theme change transitions. Unless you implement your own. I'm talking here of when you transition from one light mode theme to another one. Very few apps do that, so it is often not an issue. Depending on how they implement things, they might still get it for light/dark switches, but I have seen many that looses that too.

FlexColorScheme 10

I don't have enough time available to start working on this right now, but when I do I hope I can keep you in the loop for feedback and input, and if you want to help that is welcome too.

I'm thinking here something like a FlexColorScheme 10 and Themes Playground 10. It would become a parallel track to current FCS7 (sure /8/9 if I need to break something in the API, I try not to) that would be more of a maintenance and minor feature add track. FCS10 would be almost like a fresh restart, certainly reuse parts that make sense, but probably also break things with past versions a lot, to make it much better. It would basically mostly be a new thing, but build on the recognition FlexColorScheme has managed to gather so far in the community and of course experience while making it.