What would a suggested category name for Feature Form and Popup be?

Stepping back I'm wondering if the components are distinct enough that we do away with the categories and list all the examples alphabetically from the home view? I think the one exception would be Augmented Reality - we'd probably still want that to navigate to a sub-menu with the three AR types.

Stepping back I'm wondering if the components are distinct enough that we do away with the categories and list all the examples alphabetically from the home view? I think the one exception would be Augmented Reality - we'd probably still want that to navigate to a sub-menu with the three AR types.

I like that idea.

list all the examples alphabetically from the home view

That would make for a long list and more scrolling. Keeping them grouped in some way (not necessarily the existing categories) helps with that and generally makes examples easier to find.

With only a dozen or so components, and given the fact that we release very few a year, I think we can categorize further later. It's worth looking at what @dfeinzimer's idea looks like.

Here is a category approach I was able to come up with.

• Accessories
  • Compass
  • Location Button (* future)
  • Overview Map
  • Scalebar
• Augmented Reality
  • Flyover
  • Tabletop
  • World Scale
• Data
  • Basemap Gallery
  • Bookmarks
  • Feature Form
  • Feature Template Picker (* future)
  • Floor Filter
  • Popup
  • Search
  • UtilityNetworkTrace
• Other
  • Floating Panel

I like that too. I think FloorFilter could go in Accessories

This is how the top-level approach would look on iPhone 16:

I think FloorFilter could go in Accessories

My approach with the Accessories category is that those would be agnostic to any map or scene and those in the Data category rely on specific data (e.g. a FloorManager, as the FloorFilter does).

Either approach works for me. Maybe ask @dg0yal.

That would make for a long list and more scrolling. Keeping them grouped in some way (not necessarily the existing categories) helps with that and generally makes examples easier to find.

Agreed. I'm OK with the grouping @dfeinzimer proposes.

That would make for a long list and more scrolling. Keeping them grouped in some way (not necessarily the existing categories) helps with that and generally makes examples easier to find.

Agreed. I'm OK with the grouping @dfeinzimer proposes.

I think Phil wrote that when he thought it was the Swift Examples app, not the toolkit examples.

@dg0yal, do you have a preference for any of these approaches?

I think an alphabetical flat list is fine. We don't have that many components