🌸 `DesignLibrary`: `NeighborhoodNavigation`

[zspencer]

• https://github.com/zinc-collective/convene/issues/1187

OK, so I really like where @anaulin went with the Marketplace::ManageComponent, and I'm trying to imagine what something like that could look like for the entire application.

For a navigation hierarchy that looks something like this:

1. Neighborhood  # Maybe only if current_person.operator?
  a. People
  b. Spaces
2. [Space](edit_space_path(space)
  a. [Members](space_members_path(space))
    i. [Invitations](space_invitations_path(space))
    ii. Groups
  b. Utilities
    i. Stripe
    ii. GitHub
    iii. Add Utility
  c. Rooms
    i. Room A
      1. Marketplace
        a. Products
        b. Delivery Areas
        c. ...
      2. Add Furniture
    ii. Room B
      1. Journal

How far the navigation is expanded is determined by the particular page we're editing. For example:

• If we are on the edit_room_path(room_a) the side panel would show items 1, 2, 2.a, 2.b, 2.c, 2.c.i, 2.c.i.1, 2.c.i.2, and 2.c.ii.
• If we're in the edit_space_room_marketplace_path(room_a_marketplace) the side panel would show the example above, plus 2.c.i.1.a, 2.c.i.1.b, etc.

Ideally, this will build on the sense of location that we've established with our horizontal breadcrumbs, but also provide affordances for navigating sideways and down

From a visual hierarchy perspective, my gut says that indenting deeper and deeper is not going to fly, but perhaps something where we use font weight and size to indicate how far they are from the "trunk" of their space.

Thoughts?

[anaulin]

My instinct would be to separate the "standard space bits" from the "furniture-specific bits".

So we would have a "Space editing" area that would let you deal with invites, rooms, space-wide utilities, etc. But when you go to want to edit or manage a particular piece of furniture, you would pop out into the "edit mode" for that particular piece of furniture, and out of the "Space editing" area. This way:

• there is a limit to the amount of nesting that happens
• furniture coders can come up with their own arbitrary "editing" UIs without having to figure out how to make it fit within the space UI
• accommodates the fact that for some pieces of furniture "editing" isn't necessarily the right fit, such as with Marketplace -- e.g. looking at the Order History is not an "editing" action, but it is a privileged action that makes sense to include in the same privileged area for the Marketplace owners

[zspencer]

I'm down with keeping the furniture / space distant for now; especially given the possibility of significant nesting (i.e. marketplaces#edit is the parent of marketplace::delivery_areas#(index,new, create, edit)