Fluentui: Build 2020 Feedback Thread - Fluent UI React

[paulgildea]

Welcome Build 2020 participants! Did you get a chance to watch our pre-recorded session? We'd love to hear from you!

Feel free to leave feedback on any of the following (and please keep feedback constructive and respectful):

Likes
Dislikes
Bugs
Areas for improvement

Thank you!

[wictorwilen]

Where can I find the recording, nothing on the official Build site...

[abdullahsalem]

Areas for improvement:

• Updating the Contributing section in the Wiki pages to be matched with the current huge upgrade. (Previously, I was able to contribute because that section was very helpful and clear, but I think it is now out-of-date)
• Adding the capability of changing the direction (RTL and LTR) in _the demo package_. It was there in the _previous demo package_, but I cannot see it anymore!

[ecraig12345]

Thanks @abdullahsalem for the feedback! If you don't mind opening a separate issue about what you're finding unclear with the contributing docs we'd appreciate that, so we can fix it. I thought they were still pretty up-to-date for the primary scenario of contributing to @fluentui/react (former office-ui-fabric-react), but that may not be the case. Also the docs don't currently attempt to cover @fluentui/react-northstar (though there's some info on that elsewhere) or @fluentui/react-next (because we're still figuring that out), but those scenarios shouldn't be relevant to as many people.

[abdullahsalem]

It's very clear now!
Thanks a lot @ecraig12345 for pointing out to that implicit CONTRIBUTING.md for @fluentui/react-northstar and all packages/fluentui/**, that's exactly what I was looking for but never noticed it.

[ecraig12345]

@abdullahsalem Glad that helped! We still need to figure out the story for having two sets of contributing docs within repo (obviously we'd like one process eventually, but that will take awhile). At minimum short-term we ought to update the wiki with disambiguation between the packages' processes and pointers to the react-northstar contributing docs.

[ecraig12345]

@paulgildea or @aneeshack4 do you have a link to the talk from //build that we can share?

[abdullahsalem]

@wictorwilen I was looking for the same, and I've found this: https://www.youtube.com/watch?v=ccjvRloreXg
I hope that meets your need.

[paulgildea]

@wictorwilen @abdullahsalem Yes there were a series of pre-recorded BUILD talks published on Microsoft 365 Dev account.

As you pointed out you here’s our talk: Fluent Design System - Fluent UI Talk

If you have any questions or feedback, let us know what you think!

[abdullahsalem]

Thanks, @paulgildea!
So glad to know that amazing new tool Design to Code, I believe that tool and the concept behind it will make Fluent Design System more efficient than other design systems, and it will provide so productive development experience 👌🏻👏🏻

[paulgildea]

@abdullahsalem That was a very early proof of concept - so we are definitely in the early stages of gauging interest and feedback from the community. We're happy that you find the concept interesting and valuable.

[andrewconnell]

I watched the recorded session Build SK131 & read the blog post... and one thing that was stated in the session (at this timecode) that FluentUI React is supported in the SharePoint Framework.

Is that accurate, because SharePoint Online only supports up to Fabric React v7? We've seen plenty of issues in github.com/sharepoint/sp-dev-docs (_I'm an issue list moderator/maintainer_), in our experience & talking to the SharePoint product team that this (FluentUI supported in SPFx projects) is not the case.

When Fabric/FluentUI/Stardust repos were being merged in early CY2020, we asked "what's going on?" and were told, "wait until Build". We waited a few months and, with all due respect, we're even more confused and frankly, very disappointed this was the only session related to FluentUI that's been found (maybe there are others, but so far, we're coming up with blanks).

From a session feedback POV (and from the aforementioned blog post): you shared futures, but the TODAY story is cloudy & unreliable so much so, the guidance should be to continue to use Fabric React v7 in SPFx projects.

From a product feedback POV, we want to use a single design language. We want to use what MSFT is using in your products to make our customizations look more native. We've been begging for a good story for _Y_E_A_R_S_ and it's still not clear or reliable (OOTB breaks in SharePoint Online that can be attributed to breaking changes being rolled out, even some just this week with Fabric React v7).

Can you point us somewhere that these questions are cleared up?

[abdullahsalem]

I've been closely following the most important milestones of Fabric, for a long time, and as a contributor I totally agree with @andrewconnell, in particular the following point that leads to many questions:

but the TODAY story is cloudy & unreliable so much

I am still trying to clearly figure out the main goal of the current merging process and the target benefits, so I am going to think aloud:

We all know that Microsoft has announced its inclusive design system (Fluent Design System) which implicitly applies the Microsoft design language (Fluent Design Language), and as many other design systems, Fluent Design System would contain the code implementation for multiple platforms (e.g., Web, Windows, iOS and Android).

UI Fabric (formerly, Office UI Fabric) was introduced as the Web implementation within that design system and will be used by MSFT products, so I (and might many others) would think that any current and future improvements on that web framework would be cumulative and on the same direction.

However, when I knew about the new name of UI Fabric which is Fluent UI, I thought it was only about renaming the framework with additional CUMULATIVE improvements, but unfortunately that wasn't the case, I figured out that it was also about MERGING two web frameworks (UI Fabric and Stardust UI)!!

Stardust UI was new to me, and I never heard that it was apart of Fluent Design System or it even was driven by Fluent Design Language! All what I know, so far, Teams was built using Stardust UI.

All the above led me to may questions:

• Why two web frameworks (they actually two even if they live in one monorepo)?
• Why not just to keep developing the current UI Fabric web framework (Fluent UI), which follows the principles of Fluent Design Language
• Why to distribute the effort into two directions, while it is ONE DESIGN LANGUAGE and one target platform (Web)?
• I am not a Design Language expert, but at least I don't see all the Fluent Design Language characteristics on Stardust UI, so that I think the merging process would cost much

Regardless all that considerations, I am so glad to see that huge enhancement of the design system, and appreciate all the work!

[paulgildea]

@abdullahsalem @andrewconnell I just wanted to say I saw your posts over the weekend and that I try not to post on the weekend because I don't expect others to, but I know that's probably the time when we all do our deep thinking and reflection :-). So I just wanted to acknowledge you and thank you for the time you put into your questions and feedback.

I'll try my best of answer as many of the questions as I can with timeliness - but just from the sheer number of questions you folks have I think it might make sense for some more long form content (blog posts) on the engineering details of Fluent UI React, and tell a little bit more on our efforts, share our roadmap, and give more insight into our engineering plans.

Do you think that would be helpful?

[andrewconnell]

@paulgildea Yes... it would be, but I don't think that's what people are asking. I get what @abdullahsalem is asking, but he's going much further than what I'm trying to get to the bottom of.

My comment above boils down to one question: what is currently SUPPORTED & RECOMMENDED when it comes to SharePoint Framework (specifically in SPO) & Microsoft Teams WRT FluentUI?

Because what I saw in the Build session (_saying it worked in both_), what I see in reality, and what I hear from talking to the SharePoint team don't sync up. As such, I'm still recommending SharePoint developers not use FluentUI.

Against better judgment, I'll pile on: it's really frustrating when we were in this messy state, then things got cleaned up for a while, and it feels like we're falling back into this mess of what is/isn't supported, what you can/can't rely on because of breaking changes introduced underfoot after you deploy.

IOW, let me be very direct: I don't care about your plans ATM as much as I'm just trying to get the state of the world today. Repeating what I said above:

When Fabric/FluentUI/Stardust repos were being merged in early CY2020, we asked "what's going on?" and were told, "wait until Build". We waited a few months and, with all due respect, we're even more confused and frankly, very disappointed this was the only session related to FluentUI that's been found (maybe there are others, but so far, we're coming up with blanks).

[paulgildea]

@andrewconnell Just wanted to check in to let you know that I'm looking into the specifics on of what's currently supported and recommended when it comes to SharePoint Framework.

I've been looking through the public documentation and I'm following up folks on the SharePoint team so that I can help clarify the recommended support. To your frustration about being in a messy state, I want to ensure I'm being helpful here and not just creating more confusion around what is/isn't supported.

Thanks for bringing this up and advocating for your customers and I hope I can help create some clarity around the state of the world today.

[paulgildea]

@andrewconnell Just wanted to follow up with status. I've been working and learning from @KevinTCoughlin about the current SPFx landscape, what versions of Fabric are used in practice, and what the current support is for the latest package of the v7 codebase.

Once we have good confirmation - we'll update accordingly. 👍

[abdullahsalem]

Thanks, @paulgildea! Yes, that blog posts would be very helpful if they technically explain the current situation and the roadmap.

[YannickRe]

@paulgildea I'm (still) super confused about @fluent/react-northstar (formerly known as @stardustui/react & even @fluentui/react v0.x.x) vs @fluentui/react v8.x.x. When v8 comes out, will it have the functionality northstar aimed to achieve? Will v8 be the defacto standard ALSO for Teams development, or will northstar remain where the Teams team puts their effort separate from v8?
Will v8 then allow for transparant theme switching depending on where I run my code? Be it in SharePoint, Teams, or wherever? Will v8 have a Teams specific theme?

[paulgildea]

@YannickRe I apologize for the confusion around the packages, the versioning numbers, and some of the roadmap questions you have around theming and theme switching.

We're drafting an initial FAQ and will be posting it on the wiki shortly and will continue to add to it as more feedback like this comes in.

Just to help me understand your context a little more - can you tell me about the develop you do? Are you building in SharePoint and want to host that content in Teams?

[YannickRe]

@paulgildea I am delivering a session on Friday, I hoped for a bit more straightforward answer 😉

I am a build once, use everywhere kind of developer: build solutions/reusable controls for a Teams app, and then reuse them in SharePoint. Or the other way around. And preferably the end result looks like Teams in Teams, and SharePoint in SharePoint.
This used to be the promise of Stardust 🙂

[paulgildea]

Ok here's some progress on recommendations. We've added this FAQ to the wiki: FAQ Fabric and Stardust to Fluent UI

@andrewconnell @abdullahsalem @YannickRe Let us know if you have feedback on it.

I'm following up with Kevin again to get more crisp on the which version of v7 code that's working in SharePoint.

@JustSlone - FYI

[wictorwilen]

Thanks @paulgildea - this is a good starting reference point to understand what's happening. Since I'm focusing on Teams apps generation, this docs specifies clearly that I should continue to use northstar.

Is there any way we could have some sync between the northstar Fluent team and what we're trying to achieve with the Teams App generator (https://aka.ms/yoteams) which already today promotes react-northstar as the prime UX library? I'd love for Yo Teams to be one of the primary showcases of the future of the Fluent design patterns.

[YannickRe]

@paulgildea Thank you for the FAQ document. I kind of hoped that with v8 we would no longer have _northstar_ and everything would have converged into one. A naïve dream to have one UX library to rule them all.

[abdullahsalem]

It's helpful FAQ. Thanks, @paulgildea!
So excited about the ultimate goal that was mentioned:

Our end goal is to unify these things. One styling solution, one theming solution, one set of utilities, one set of component authoring patterns, one set of components, one documentation site.

and one UX that's derived from Fluent Design.

[andrewconnell]

Thanks for the FAQ... yes this helps.

One question, maybe specific to @KevinTCoughlin - what's the supported version in SharePoint Online today? @fluentui/[email protected]?

[paulgildea]

@YannickRe @abdullahsalem The eventual goal is to have one solution that everyone can use - however we just know pragmatically we won't be able to get there in version jump 😄 .

The reality is: folks are using Fabric and folks are using Stardust and the feedback we got from them was that moving to a "next new thing" in one jump is a non-starter.

And so incremental adoption is a key principle across our team. Internally, our team refers to this as "Leaning the towers." The towers being our collective code bases and we are committed to bringing the best aspects of them together into one solution, but doing tha in a way that can be incrementally adopted by customers overtime.

@wictorwilen I'll reach out to some of the folks on the team to see who's someone you could chat with. As I've demonstrated 😅 , I'm not an expert and up to date on the latest extension models for SharePoint and Teams, but I'm learning 😄

I just wanted to reiterate that this feedback is super valuable to our team. I recently highlighted this thread in a sync meeting to evaluate the importance of the simplest of things like package structure has an impact on our collective communities.

So thank you!

[Ray-B]

Hi @paulgildea. Thanks for making this feedback thread.

I'd like to piggyback on the sentiment that has been conveyed already, that is, that we will benefit collectively from clear and comprehensive communication.

We have a whole community of developers who have used, and continue to use, the various permutations of Semantic UI (semantic-ui-react, et. al.), and who are interested in adopting Fluent UI, which is the next logical stage in this journey.

To illustrate the (mostly minor and easily rectified) gaps in communication that I see, let me explain our particular situation (maybe it will resonate with other developers):

I have an internal project at my company that is relied on by a hundred or so of our developers, and which is the principle piece of our CI/CD system; Its UI is built off of Semantic UI React.

I'd like to eventually switch to using Fluent UI; accessibility, better multi-device compatibility, bug fixes, styling, more components, etc.

However after much time over the years being spent trying to balance the risk/reward for "upgrading" libraries, my engineer brain is still saying "nope", because:

• There isn't yet any sort of formal documentation to indicate if Fluent UI is at "feature" parity with Semantic UI React.
• Related to the point above, there is no comparison chart about what Fluent UI offers/doesn't offer compared to Semantic UI, or any of the other main UI "platforms". Sounds trivial, but with so much functionality, this would be a huge time saver. "Wheres the value proposition?" "How do I convince higher ups switching to Fluent UI is a worthwhile expenditure of engineering time?"
• There isn't any easy-to-find official stance (that I've found, anyways) on whether Fluent UI for Web is considered "production ready", or when that will happen.

There's another perhaps more nit-picky item too that I think has been overlooked (probably unintentionally) for too long:

• We are missing a "history" section for Fluent UI that touches on the contributions and history of all the work done by the hundreds of open source contributors (@jlukic, @layershifter and @levithomason just to mention a few) to the projects that preceded Fluent UI. Without their work, Fluent UI would look very different than it does currently. This is something I think is important, and its something we can easily remedy. Adding a "History of Fluent UI" section to the main README.md, or alternatively, a detail blog post about it. I think this history is important to understanding the direction of Fluent UI. A lot of important lessons have been learned over the years by a lot of volunteers, and we should share that.

To further illustrate what I think we need here in terms of better communication and documentation, I want to point to a great example of some simple and clean communication done by another MS team, Windows Terminal:

They have a great dev blog: https://devblogs.microsoft.com/commandline/introducing-windows-terminal/

They have a good Readme: https://github.com/microsoft/terminal/blob/master/README.md

They have a good release cadence: https://github.com/microsoft/terminal/releases
WRT to the above, notice that they are making great use of the realease tagging so people have a clear picture of what is changing. Fluent UI currently has 5000 releases, and a not-so-great or easy to follow changelog.

Thanks for all your hard work!

[paulgildea]

@Ray-B Thanks for the thoughtful feedback. Sorry it took me a bit to internalize everything so that I could provide a mindful response.

I too am relatively new to the Fluent UI project (I'm coming up on 1 year now) and I can totally empathize with you on missing the "history" section of the project. And I think you've hit it on the head here in that Fluent UI is really the combination of many project lineages (Semantic, Stardust, Fabric, and now FastDNA) coming together as one team and one community of contributors and that needs to be documented and celebrated.

Also I'm still relatively new working on an open source project that has a lot of usage - so personally - I'm still learning and all your recommendations are super helpful for me and the team as we are trying to come together to produce one project and one library that can be seen as another good example of an open source project made by Microsoft.

Thank you for the callouts to Windows Terminal. That project and projects like VS Code are the north start examples of what we would like to be.

I think one of the interesting things that makes our project unique is that we have many folks (with a diverse set of backgrounds and opinions) contributing to the vision of the project and not just one sole maintainer of the project. I'm actually very proud that we have such a diverse mix of folks contributing the project. Sometimes that means progress might be a little slower than if one individual is setting the vision of the project 😄.

So thank you for the thoughtful feedback. Here's some of things I took away from it:

• Have a great README - including project description, value prop, links to important wiki articles like the project history, and comparisons to some existing libraries in the project's lineage
• Have a blog (long form communication channel) - Chronological record of announcements, information, new features, and sharing out long form content
• Provide clear and navigable releases and release notes (across the various packages)
• Engage on social media channels (e.g. Twitter) - Short announcements, pointers to blog, new releases, feedback polls, etc.

I think the biggest piece of feedback I'm hearing is the lack of clear and comprehensive communication - which is super fair and I agree with you and that we need to spend some time and focus there.

Since I started engaging more on GitHub these past 3 months, I've probably touched 300+ issues and it's been challenging to say the least to try to ensure progress is being made on each issue and establish and maintain a consistent communication channel. I'm not using that as an excuse, I just wanted to share my current experience as a contributor to the project. And as I start to look at the mountain of feature requests that the project has accumulated as it's grown over the years that's another area where I think we can do better providing clarity for the project as well.

Once again thanks for your feedback. Thanks for taking the time to invest in the project and folks on the team do read these responses and want to make the product that folks want to use and contribute to so agin thanks for the support.

[Ray-B]

@Ray-B Thanks for the thoughtful feedback. Sorry it took me a bit to internalize everything so that I could provide a mindful response.

...

Your summary of items to focus on pretty well nails it.

I want to emphasize that a lot of the teams using the solutions that pre-date Fluent UI would really benefit from some clear information on:

• Is Fluent UI ready for us to use on projects? I realize this might mean different things to different people, but some sort of minimum standard where the team can say "Yep, we think this project is _generally_ "good to go".

• How do users of the major solutions migrate to using Fluent?

• How does Fluent stack up to other open source projects? Where does Fluent fit in?

[paulgildea]

@Ray-B Love it. I'll be sending some time over the next couple of weeks focusing directly on this feedback.

I'll need some time on the historical timelines to make sure I can represent those projects accurately.

My main focus will be centered on the basics around improving the repo experience for developers - Readme, Wiki, Roadmaps, Iterations, Triage Process, and Historical reference.

One of things we're going to try is to encourage more community contributions to the library so building up the collateral to support that goal should touch on the points that you called out before hand. Thanks!