Bringing Fluent Design to Flutter for additional Mobile design options and Desktop nativity
sampathbalivada opened this issue · comments
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.
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.
CC @csells in case he has any thoughts/input here.
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.
This would also benefit people after the upcoming UWP support #14967
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.
Count me in :)
I'd love to contribute.
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.
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.
Literally started with flutter two days ago and are looking forward to a fluent design option, I just love that design language. Awesome!
@stuartmorgan any flutter team members who are familiar with Fluent design and can give us a headstart?
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.
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!
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
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.
Re-opening since this is still a valid feature request, with accumulated votes, even if the specific implementation effort above was abandoned.
This could be a possibility with Project Reunion (Windows-only tho)
Microsoft is developing a Fluent UI Pipeline using Design Tokens. It will come with a Figma plugin for designing UIs. Perhaps this would be where a Flutter Implementation of Fluent Design could be added?
Edge uses Microsoft's Fluent Design System Provider for Fast to handle it's web UI. So that could also be another avenue.
I came across this package, which is being developed by Microsoft. https://pub.dev/packages/fluentui_system_icons Leaving it here for those who came to the thread and want to know what has happened.
I started building my own library to support fluent ui: https://pub.dev/packages/fluent_ui. It's built based on the official documentation
@alexmercerind the thing is that developers are not designers. I have no idea how to design an app that looks good without following a design system telling me exactly what to do or not.
To my belief, it is kinda wrong to ask for components that "look like native".
Flutter is a completely custom engine/embedder & not using native components at all. It is like the main reason of its versatility in design. One can very easily implement the design one wants without having to deal with limitations of native widgets/components.Every famous application follows its own brand's design language to make experience more "personalised". Take Spotify, Snapchat, Discord or Twitter all look so different (Are they Fluent? Are they Material? Are they Cupertino? And Microsoft doesn't even have something like "Material Theming" to make apps look more personalized. Stick to those exact same boring UI components everywhere). So, why is everyone interested in asking for widgets "look like native", when at the end of the day those will not even end up being used by most apps or will be modified by developers to make experience personalised.
Now, if one decides to stick with the bare "Fluent design" while leaving all the design versatility that Flutter offers behind to make their app "look native", I don't know what to say.On the other hand, let's not talk about Microsoft's design language, they haven't still not settled on one. Windows 11 is again different in terms of design. Not just Microsoft, the new "Material You" is also completely different from existing Material design.
Design is ever changing. And, I feel currently implemented widgets are really really already enough to build any kind of custom design & UI.
The default widgets & themes (Material, and that's great for Flutter as its a Google product) in Flutter are great to build everything ever needed & and a great starting point for higher order of customization. All are very very customisable in nature.Community efforts from @bdlukaa in his fluent_ui are really appreciated & his work is great. And that's how I believe this goal is meant to be done.
The thing here is, Material and Material You are designed for touch devices, not for desktop PCs. Remember when no one wanted to use Windows 8 because of its design? We are in the same situation. Creating a Fluent clone, just like the cupertino theme,will potentiate flutter apps on desktop. Or a win32 theme is also acceptable.
The thing here is, Material and Material You are designed for touch devices, not for desktop PCs. Remember when no one wanted to use Windows 8 because of its design? We are in the same situation. Creating a Fluent clone, just like the cupertino theme,will potentiate flutter apps on desktop. Or a win32 theme is also acceptable.
Except that Google uses Material Design for web apps as well as Touch devices, so there are affordances for hover states there as well.
@alexmercerind if Flutter supports both Material and Cupertino (the design languages for the devices it firstly targeted, Android and iOS), why couldn't it support the macos_ui and win_ui design system? Because Windows and MacOS are now officially supported
I believe one particular design system not being well defined isn't a reason for us to abandon design systems altogether. Microsoft design system is evolving and takes time. It is being architected to support both 2D and 3D spaces.
A design system is not just another button with a style. It's more of the way things work. It also defines how a menu just expands in Material vs how it slides into view in Fluent. The motion, interaction, shape and other things make a play in defining the character of the UI elements.
I earlier closed this issue by giving a series of reasons and yes they held true at the time of writing the comment. As of the date of writing the comment, Fluent was only defined for Windows, Web and Android. I closed this issue as I was intending to use this issue to track the progress of my effort to create a Fluent Design System implementation for Flutter. But it's now being used to track Fluent's Implementation in Flutter and that's good.
a developer is already offered a complete design system to follow within the app by the organization or brand.
Not all apps on the store are built with a huge organisation backing them. Also, a lot of huge orgs actually use these design systems.
at the end of the day those will not even end up being used by most apps or will be modified by developers to make experience personalised.
The Lyft app has a very personalised UI and guess what, it uses Material. The goals of Material Design in the first place kept a lot of decisions in the hands of the developers/designers and make the experience unique while keeping harmony with the OS. And with Material You, the goal is to allow the user to make some of those decisions.
For me personally, it's not a question of whether we want to get an additional design system to Flutter, it's about when? When do we make the call if a certain design system is stable enough to allow an entire ecosystem of developers to build on it?
The thing here is, Material and Material You are designed for touch devices, not for desktop PCs. Remember when no one wanted to use Windows 8 because of its design? We are in the same situation. Creating a Fluent clone, just like the cupertino theme,will potentiate flutter apps on desktop. Or a win32 theme is also acceptable.
Except that Google uses Material Design for web apps as well as Touch devices, so there are affordances for hover states there as well.
A web app is very different from a "native"-like app.
good work has been done here https://github.com/bdlukaa/fluent_ui any plans to introduce it to the main repo here?
@richard457 I don't think it'll ever be merged
@bdlukaa why? is it by design? I would love to only install flutter and have fluent design shipped with it. but if technically not possible with good reason that I would understand.
@dragonDScript
Or a win32 theme is also acceptable.
Which last app you used uses win32? VLC (I know its Qt, still looks "native")? notepad++? All look terrible.
Remember when no one wanted to use Windows 8 because of its design?
I'm almost 100% certain, if Flutter launched during that era, people would have opened issue like this for Windows 8's metro UI.
The thing here is, Material and Material You are designed for touch devices, not for desktop PCs.
A random screenshot from material.io. (Not just web but Chrome OS)
It doesn't look native, that is the problem, if the flutter group would decide to implement the Fluent UI, I am new to Flutter, but I would like to collaborate in the project.
@omensight tho Flutter is a UI framework. It's not made to look native, you can have whatever design you want. It's not Flutter's job to add nativety to the apps. If you want something native, go with native or with react native
@omensight tho Flutter is a UI framework. It's not made to look native, you can have whatever design you want. It's not Flutter's job to add nativety to the apps. If you want something native, go with native or with react native or with react native
Sorry if I sound rude or something, I just was saying, I would like to have a fluent_ui incorporated to flutter framework,
I hope there will be official support so that I can migrate my work to flutter.
Any updates on this topic?
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.
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
adaptiveconstructors (likeSwitch.adaptive) can automatically use thefluent_uivariants on Windows? Is it for some other reason? It would be very helpful for us to learn what exactly you are lacking from thefluent_uipackage.
Depending on third parties for something so fundamental to an application is not good
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
adaptiveconstructors (likeSwitch.adaptive) can automatically use thefluent_uivariants on Windows? Is it for some other reason? It would be very helpful for us to learn what exactly you are lacking from thefluent_uipackage.
- 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.
- Official documentation can then include Fluent examples as well.
- Authors are more likely to include it in their books and posts.
- 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.
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.
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.
@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.
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 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.
@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)
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.
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.
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.
- 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.
- 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!
- 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.
- 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.
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.
@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.
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.
@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.