Folder structure: Controls, Design, Accessibility, Fundamentals

[Jay-o-Way]

This app used to be named "Control Gallery", but has evolved to encompass many more things. The current folder structure - and some file names - are still, inappropriately, centered on "Controls".

• 📂 ControlPages > Accessibility, DesignGuidance, Fundamentals
• File names like "ControlData<Schema>.json" and their content

sub of #1614

---

Suggested

• AppControls
• AppPages
• Samples
  • SampleCode (level "A")
    • Accessibility (level "B")
    • Design
      • Iconography
      • Geometry
      • Typography
    • Fundamentals
      • Binding
      • Templates
      • XamlResources
      • XamlStyles
    • XamlControls
      • 📄 (many txt files)
  • SampleData
    • 📄 (files like AccessibilityData.json, ControlData.json, DesignData, IconData.json, ...)
  • SamplePages (level "A") (not to be mistaken with the current folder with the same name!)
    • Accessibility
    • Design
      • Iconography
      • Geometry
      • Typography
    • Fundamentals
      • Binding
      • Templates
      • XamlResources
      • XamlStyles
    • XamlControls
      • 📄 (many xaml files)

Also

Preview Give feedback

1. use names📁 "AppControls" and "XamlControls" to prevent any ambiguity.
2. looks like 📁 "SamplePages" isn't used? if not, let's remove it.
3. I want to split ControlInfoData into separate files and code.
4. ... then must update ItemPage.xaml.cs and ControlInfoData.cs for ControlInfoDataItem ❗
5. ... a filename like 📄 "...InfoData" is redundant. Info == Data.

[marcelwgn]

Thank you for making this suggestion. We would like to keep the general folder structure the same but I agree control pages is misleading. Of course we are open for name suggestions and would accept a PR if we agree with the naming.

[Jay-o-Way]

Well, the fact that the name changed from "Xaml Controls Gallery" to "WinUI 3 Gallery" is very iconic and shows exactly what I mean with this issue. The app has grown, and things like design, controls (et cetera) are equal parts of WinUI.
For example: Look at ControlInfoData.json - you can see it's centered around controls, not (yet) around WinUI.

[Zakariathr22]

🤔 Hmmm... Do you have any suggestions for the new naming @Jay-o-Way?

[niels9001]

@Jay-o-Way Thanks for the proposal, but IMO this would be a regression as samples and the Gallery shell code would now be intertwined - this is something that we'd like to avoid. We are currently seperate out all the Sample-related code vs the shell itself. I agree that the Design Guidance content could live under samples as well.

[Jay-o-Way]

@niels9001 I'm sorry, I honestly don't follow. What is being intertwined where?
I mean, this hierarchy (in primary comment) looks pretty logical, doesn't it? App UI files are in the AppPages folder, and every WinUI category has a folder too... 🤷🏻‍♂️

[niels9001]

@niels9001 I'm sorry, I honestly don't follow. What is being intertwined where? I mean, this hierarchy (in primary comment) looks pretty logical, doesn't it? App UI files are in the AppPages folder, and every WinUI category has a folder too... 🤷🏻‍♂️

Because we have a ton of different folders with other content as well. If we start putting everything in the root folder again and if I'd be looking for a sample, I need to scan through the entire list of folders to figure out what is what. Today, you'd start in "Samples" and then drill-down to the file you need.

Obviously, there are (naming) inconsistencies, and it's never black-and-white of what content needs to go where. But I think what we have today mostly aligns with how most apps use for their naming conventions and moving everything back to the root folder is more of a regression than an improvement IMO.

[Jay-o-Way]

Oh now I see what you mean @niels9001 You'd prefer the following structure, correct? My though was more like "I'm searching for something in the Design category"...

It's like a 2 dimensional thing; you could choose either variable (A or B) for the first sorting level, which means the second level (of folders) will have to be repeated. I suppose conventions are still choices made by people. My personal preference is that I don't like very, very deep nesting.

If the others agree, I'll put this in the main comment.

• AppControls
• AppPages
• Samples
  • SampleCode (level "A")
    • Accessibility (level "B")
    • Design
      • Iconography
      • Geometry
      • Typography
    • Fundamentals
      • Binding
      • Templates
      • XamlResources
      • XamlStyles
    • XamlControls
      • 📄 (many txt files)
  • SampleData
    • 📄 (files like AccessibilityData.json, ControlData.json, DesignData, IconData.json, ...)
  • SamplePages (level "A") (not to be mistaken with the current folder with the same name!)
    • Accessibility
    • Design
      • Iconography
      • Geometry
      • Typography
    • Fundamentals
      • Binding
      • Templates
      • XamlResources
      • XamlStyles
    • XamlControls
      • 📄 (many xaml files)

[Jay-o-Way]

Also noticed this: I see under Samples\SampleCode that there are numerous folders per control type for a total of 138 txt files, where under Samples\ControlPages there are none for 202 xaml files. We could balance this better ⚖️

[niels9001]

@Jay-o-Way Yeah, I like that structure.. as long as it's part of a root "Samples" folder!

We can then keep the shell folders (e.g. Pages and Controls) as well so they are inline with best practices + their respective namespaces.

I liked @Zakariathr22 proposal for the naming too btw:
#1784 (comment)

[Zakariathr22]

Maybe we can work on this after merging #1664 and #1781 to prevent other conflicts.