--- tags: website --- # FluentUI Website Questions ## Reason There are a number of decisions that affect the FluentUI website that are still contentious. There are some decisions that HAVE to be made before moving forward, and some limits to what we can do until all matters are resolved. Getting answers to these questions are important before creating a website proposal. ## FluentUI questions - Where will FluentUI controls live (repo/branch/path)? - What is the inner loop, and do docs have a role in it? - At what point do we recommend entire apps be built with FluentUI? - If the prev answer is 'now': - Do we recommend mixing Fabric + 1.0 Fluent - Do we recommend mixing pre and post 1.0 fluent (this feels fragile) - Do we recommend only using 1.0 Fluent + their custom controls built on our createComponent - CSS solution for __our__ component styles. It'd be beneficial to use the same approach on the site? ## Website Build Questions - Where will the FluentUI website code be hosted? - What CSS solution should we use? - How do we approach theming? - If 1.0 FluentUI control is not available, what should we use? - Fabric controls? - pre-release FluentUI control - Custom control - What tech will convert MDX into html pages (gatsby, next.js, custom react app) ## Website Content Questions - Where will design and developer content be hosted - I can see control related docs in OUFR repo next to controls, but what about general how-tos, best practices, theming, composition etc - What controls will the initial FluentUI website include (related to #3 above)? - only 1.0 FluentUI controls - Fabric + 1.0 FluentUI controls - Stardust (<1.0 FluentUI) + 1.0 FluentUI controls - All 3 - Doesn't matter because all FluentUI will be 1.0 by then (not likely) - How does a user navigate to developer documentation (especially for non visual control/utility)? - This teases out the single page vs multiple page per control question - What are the page templates (Angela is working on these, but it's still an open issue) ## Serving product (partner) components Website needs to be able to display partner (product specific) component that would live in its own repo but would follow agreed set of principles. This can be for example achieved by exporting the website as NPM package that the partner teams can consume in their build.