Bringing Fluent Design to Flutter for additional Mobile design options and Desktop nativity

[sampathbalivada]

We already have Material and Cupertino for Flutter, having redmond too can be a value addition while we get ready for Desktop.

I would love to start writing up the code but I just wanted to make sure if someone is already doing it. Even better, if someone on the Flutter team is doing it.

Is it even good or do we have the need to have Fluent design? For the most part, it's a wrap around Material Design.

I'm open to further discussions on this.

[sampathbalivada]

Hey @phanirithvij. Thanks for looping me into this. Seems like the entire project was started hours ago. I think its better if we follow up on this. I'm keeping this issue open for further updates regarding this.

[stuartmorgan]

CC @csells in case he has any thoughts/input here.

[csells]

Certainly there's room for the Fluent design language for Flutter, just as there is room for Material and Cupertino. This has been on the Flutter team's radar for a while but we don't have any plans to tackle it anytime soon. I'd love to see the community take the lead here; I'm happy to help support your efforts.

[phanirithvij]

This would also benefit people after the upcoming UWP support #14967

[sampathbalivada]

Thank you for sharing your thoughts @csells

I think it's good to start an organisation and work as we go. I'll setup one ASAP.

Please email me at me@sampath.dev if you're interested to be a part of the organisation as an owner or editor.

[sampathbalivada]

Following up with the updates on this, we are starting off by creating a package here. Any contributions are welcome. The repo will be completely set up to accept contributions in a few days.

[SKLn-Rad]

Count me in too. I was between making it a top level component like MaterialApp or whether to just make it a component library. Would be nice to get your thoughts.

[cyanit]

Literally started with flutter two days ago and are looking forward to a fluent design option, I just love that design language. Awesome!

[stuartmorgan]

I'm not sure what you are asking exactly, but as mentioned above this is not something the Flutter team is currently working on, or plans to work on in the near future.

[dancamdev]

I'd love to see the community take an active part in building this before or along the flutter team! So definitely count me in on this!

[sampathbalivada]

I'm genuinely sorry for commenting this late but here are the things that stopped the efforts.

• Fluent Design is not well documented. I was confused about a lot of things in their system.
• The entire system is just redundant and is built around the existing design systems and the desktop design system seems ever-changing
• Part of the UI is icons and I would argue, they're primary for any Design System but as it is a fact, Microsoft icons are restricted for use in Office Apps only and they cannot be used by anyone or anywhere else. PS: No one wants to be a part of a lawsuit.

Thanks for the support. I'll be closing the issue now and I would like everyone to take into account the above points I mentioned before building anything with Fluent.

I have no hate or false feelings towards Microsoft or their design language, these are just some facts and restrictions. Hope Microsoft clears them soon

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.

[stuartmorgan]

Re-opening since this is still a valid feature request, with accumulated votes, even if the specific implementation effort above was abandoned.

[Aloento]

I hope there will be official support so that I can migrate my work to flutter.

[wiedymi]

Any updates on this topic?

[Hixie]

For people who are happy with fluent_ui but would still like it to be integrated with the core Flutter framework, I'm curious if you could talk more about what problem that would solve for you. Is it a matter of hoping that if it's part of the core Flutter team's efforts it's more likely to be maintained over time? Is it because you would like the core Flutter team to bless this package to indicate that we believe it is worth using? Is it so that the Material widgets with adaptive constructors (like Switch.adaptive) can automatically use the fluent_ui variants on Windows? Is it for some other reason? It would be very helpful for us to learn what exactly you are lacking from the fluent_ui package.

[ghost]

For people who are happy with fluent_ui but would still like it to be integrated with the core Flutter framework, I'm curious if you could talk more about what problem that would solve for you. Is it a matter of hoping that if it's part of the core Flutter team's efforts it's more likely to be maintained over time? Is it because you would like the core Flutter team to bless this package to indicate that we believe it is worth using? Is it so that the Material widgets with adaptive constructors (like Switch.adaptive) can automatically use the fluent_ui variants on Windows? Is it for some other reason? It would be very helpful for us to learn what exactly you are lacking from the fluent_ui package.

Depending on third parties for something so fundamental to an application is not good

[scottkuhl]

For people who are happy with fluent_ui but would still like it to be integrated with the core Flutter framework, I'm curious if you could talk more about what problem that would solve for you. Is it a matter of hoping that if it's part of the core Flutter team's efforts it's more likely to be maintained over time? Is it because you would like the core Flutter team to bless this package to indicate that we believe it is worth using? Is it so that the Material widgets with adaptive constructors (like Switch.adaptive) can automatically use the fluent_ui variants on Windows? Is it for some other reason? It would be very helpful for us to learn what exactly you are lacking from the fluent_ui package.

1. Sends a message to companies that Microsoft is just as important as Apple and Google and they can rely on first class UI support for Windows apps.
2. Official documentation can then include Fluent examples as well.
3. Authors are more likely to include it in their books and posts.
4. Plugin developers are more likely to support Windows in addition to Android and iOS because of the above.

All of this leads to better adoption and feature parity.

[ghost]

Sends a message to companies that Microsoft is just as important as Apple and Google and they can rely on first class UI support for Windows apps.

As unimportant, I'd say. But yeah, it helps to have Windows UI if you're making a desktop application.

[csells]

tl;dr: it doesn't scale for the Flutter team to own everything that the community might want it to own.

If you take the top 10 or 100 or 1000 packages on pub.dev, you can make the same set of arguments that they should be baked into Flutter. However, there's only so much that the Flutter team itself can own and maintain. The best way to use their limited resources is to spend them on things that only they can do, eg regular launches, fixing high priority bugs, heavy duty optimizations, maintaining pub.dev, enabling a rich programming and plugin model, etc.

The rest can be handled by the Flutter community as a whole. In this particular case, the Windows design language implementation for Flutter is very well done by the community today and there's nothing blocking the community from using and improving it as they see fit.

[scottkuhl]

@csells by that logic then shouldn’t the Apple stuff be moved into the community? IMO, once the core team took on Cupertino it sent a signal that it was supporting the UI paradigms of the platforms it was available on. Not supporting Fluent says Windows is not as important and will reduce adoption.

[bdlukaa]

Maintaining a whole new UI design is expensive, takes time and a lot of effort. I don't think it's worth supporting Windows UI into the core framework. There are many other things that should be prioritized

[csells]

@csells by that logic then shouldn’t the Apple stuff be moved into the community?

At this stage of the Flutter lifecycle, I'd say that's a viable option for sure.

[ghost]

@csells by that logic then shouldn’t the Apple stuff be moved into the community?

At this stage of the Flutter lifecycle, I'd say that's a viable option for sure.

Moving something into the community means less new features, less bugfixes, less responsible codeowners, and overall a material design monopoly. (Which might some day kill flutter)

[csells]

The Flutter community has many amazing, high quality packages and plugins on pub.dev, far more than the Flutter team could ever hope to build and maintain on their own.

[scottkuhl]

Has the team ever approached Apple and Microsoft about owning these features themselves? My guess is Microsoft might be open to it and Apple would laugh at you.

[Hixie]

Folks, the Flutter team is just a part of the larger Flutter community, and anyone can join the core Flutter team just by contributing (see our contributing guide), there's really no meaningful distinction.

@dragonDScript

Depending on third parties for something so fundamental to an application is not good

Integrating the fluent_ui package into the Flutter repository would not change who works on it. You would be depending on exactly the same people either way.

@scottkuhl

1. Sends a message to companies that Microsoft is just as important as Apple and Google and they can rely on first class UI support for Windows apps.

To be clear, there's been discussion of moving the material and cupertino packages out of the core repository as well. The main reason we have not split out the material package is that we want the default template to use the Material widgets, because that's the highest-quality platform-neutral widget set we have. The main reason we haven't split out cupertino is that material depends on it. You can see more discussion about this in #101479. In practice this is largely just the result of historical accident. Originally all of flutter was just a package on pub and we happened to build material and widgets at the same time (and later added cupertino). When we changed how the SDK was distributed we didn't really think through the implications and that's why they're not in pub now. (There's also a lot of momentum behind having those packages in the main repo, like how our test infrastructure would have to change a lot if we changed this, and the minimal value we see in changing it.)

Please do not interpret the presence of material and cupertino in the main SDK repository as meaning that Apple's mobile UI language and Google's UI language are any more important to the Flutter team than the many other UI languages out there (like macOS, fluent, Ubuntu's, etc). Also please don't assume that because it's in the main SDK it's better maintained than a package. Looking at the git history, I would say fluent_ui is actually under more active development than cupertino.

2. Official documentation can then include Fluent examples as well.

Nothing is stopping anyone from contributing documentation that uses fluent_ui. We have no policy that prevents documentation, whether on docs.flutter.dev, api.flutter.dev, YouTube, or anywhere else, from using packages, especially those marked Flutter Favorite!. Indeed I would definitely recommend that Windows-specific documentation use fluent_ui at least as much as material. Please send PRs!

3. Authors are more likely to include it in their books and posts.

I can't speak to that, except to encourage people to use packages in their works.

4. Plugin developers are more likely to support Windows in addition to Android and iOS because of the above.

I suspect that the main thing that would help plugin developers to support Windows is patches to their plugins to implement the features on Windows, not anything about whether fluent_ui is in the main repo or not.

[thomassth]

I'd think holding material in main repo is fine, a framework can have its own preferred design language after all (even if you claim otherwise)

But keeping both apple and material design in the main repo, while "communities can do" fluent, gnome, KDE etc designs just looks like double standard.

[Hixie]

@thomassth There is no meaningful distinction between "communities" and the team who works on this repo. This is an open source project with a very open contributor policy. The fluent_ui repo is also an open source project with a very open contributor policy. Indeed glancing through the commits I see at least one person who has contributed to both repos.

[TomzBench]

Just popping in as a flutter newbie checking out flutter for the first time. I'm actually interested in using flutter for windows desktop because I cant really find a native alternative from microsoft that is any good. See Here for a humorous opinion on the matter.

I dont even care about cross platfrom, or what repo my widgets come from. But these docs signal to me as a newbie - hey, make your desktop app look like an phone app. Theres no docs on Windows wigets so I'm using material widgets on my windows app. The docs seem offical and there is no windows widgets on there. Its as simple as that.

[h3x4d3c1m4l]

@TomzBench Yes, but that's not all docs right? There's also docs that tell you what pub.dev is and that there's Flutter Favorite packages which are favorite because they are well documented, have high platform support, are well maintained, and so on.

Why would we actually need official Flutter support when there is this: https://pub.dev/packages/fluent_ui (which is Flutter favorite).

It's very complete, both used and maintained by numerous people (even people that contributed to Flutter itself). I myself use it for multiple projects.

[flutter-triage-bot]

The triaged-desktop label is irrelevant if there is no team-desktop label or fyi-desktop label.