[RFC] Toolpad navigation surface revamp (WIP)

[Janpot]

What's the problem? 🤔

The left sidebar is designated for all tasks related to navigating the constituents of the project. As we're identifying more parts to be included there, it's getting cluttered. This RFC proposes a reorganization and new UI paradigm to solve the clutter.

What are the requirements? ❓

• Be less cluttered
• Be intuitive
• Focuses on a single navigational task at once whenever possible

It needs to be a home for the following:

• Navigation between the different pages of the Toolpad app. Currently part of the left sidebar.
• Component catalog: The place where you start to drag from into the canvas. Currently slides out from under the left sidebar to the right.
• Page hierarchy: The place where get an overview of the elements that make up the canvas. Currently part of the left sidebar
• Page state: The place where you get an overview of all non-ui page state and where you can open editors to create an update it. Currently this is part of the "page options" panel in the right sidebar when no component is selected.
• Global scope explorer: the place where you can inspect all variables and state that is available to the bindings. Currenlty this is displayed on the right side of the binding editor.
• ...?

What are our options? 💡

warning: very low-fi wireframes ahead

The top of the left navigation starts with a header that contains the page title.

Most of the time the focus of the editor lies on the page content. The UI that gives an overview of the different pages adds clutter and takes up screen real estate. That's why this RFC proposes to make this section collapsed. It can be opened by clicking and a list with pages appears to switch between pages. UX-wise this works like a Select, meaning it is always closed unless it's being interacted with.

We can add a vertical tabs strip for each of the navigational surfaces:

1. Component catalog:
   The same content as what's currently in the slideout

   

   Disadvantages:

   • technically not a "navigational" surface
   • By not being able to show it at the same time as showing the page hierarchy, we take away the option of dragging a new component directly in the hierarchy explorer instead of in the canvas.

   Other options to consider:

   • keep it in a slide out
   • combine it with the hierarchy explorer in a single surface (e.g. add a button on top that opens a popover with the catalog, or split the surface in two and show both surfaces on top of each other)
   • Add a button somewhere else in the UI (e.g. toolbar at the top, like figma) that opens a popover with the component catalog.

2. Page hierarchy
   The same content as what's currently in the page hierarchy explorer

   

3. Page state:
   The same content as what's now in the right side panel An update to the UX of this panel will be part of a separate RFC. The point of this RFC is to find the right surface for this panel.

   

4. Global scope explorer
   The same content as what's now in the binding editor _An update to the UX of this panel will be part of a separate RFC. The point of this RFC is to find the right surface for this panel.

   

Discussions:

• Any more navigational panels to consider?
• Where does to component catalog go?
• Detailed UX of page selector (rename, delete create, settings)
• Detailed UI
• Icons?
• ...?

[apedroferreira]

I like the idea of selecting an active page from an UI that kind of works like a dropdown, and having the information below be more detailed information about that page.

At first thought, I think that maybe 2, 3 and 4 should be alternative options of the same view, while the component catalog should be easy to access at any time and separate from those views somehow... Ideally we can also make the component catalog more discoverable, as we have discussed in the past.
Not sure if we can split the left sidebar into component catalog at the top, and page editor below it? It's just another possibility, it all really depends on finding a good design and the available space...

[bharatkashyap]

App-level sidebar

• Pages
• Code components
• Theme
• Settings
• ... (Connections?)

Page section

Secondary sidebar of collapsible and resizable panels

• Pages
• Page State
• Actions
• Page Hierarchy

New feature: Page State and Page Hierarchy items allow hovering over them to view their currently evaluated values.

Tab	Function
Pages	Same as current
Page State	Automatic queries and Page parameters are merged to form "Page State" which contains all data that is brought onto the page
Actions	We rename Manual queries to Actions and give them a separate section (everything else remains the same)
Page Hierarchy	Same as current

Create/Edit Page State and Actions

The creation of Page State and Actions follows a similar process as the current, with an intermediate dialog which sets the "type" of each:

The actual editing/creation can happen in a proposed bottom panel (similar to the one outlined in #2393 (comment)) like so:

Other app-level pages

Very low-level wireframes

Page	View
Theme
Custom components
Settings

[prakhargupta1]

My thoughts on App level vs page level sidebar:

Toolpad supports building 1 app that can contain many pages. We don't have a Home view now so we need to decide where to put app-level menu items. I suggest we put them in the header bar as:

1. they will be used less and can be away from the main work area.
2. code components can be inside components (like today) and would be better suited on the top bar as it is an editor feature that should be handy. Also removing drawer will give more horizontal space to the canvas/sidebar.
3. current theme is app-level and is definitely in the wrong place.
4. All of these can open in a pop-up/modal.

Having a page-level sidebar will declutter page building leading to a lower cognitive load of seeing everything together in the 4 vertical panels.

1. Page
2. Page hierarchy explorer
3. Page state (All state-related info)
4. Actions
5. Page parameters

Note: Items like Connections, audit logs, org settings are out of the scope of this discussion and definitely can't be placed on the header bar.