Proposal: have left sidebar only contain Panes, split out Actions to right sidebar

[franknoirot]

Currently our ModelingSidebar appears on the left side of the screen, and contains two lists of buttons:

1. a list of buttons that each toggle a corresponding Panes visibility just to the right of the sidebar
2. a list of buttons that perform immediate Actions
   divided by a horizontal line.

Before:

After:

Here's my reasoning for this move:

1. I want us to support user-authored extensions. Extensions may register panes and/or actions to the app. Therefore, I believe we may run into a UI crowding problem as actions and panes proliferate.
2. Actions and Pane buttons look identical but do different kinds of things. Separating them spatially may make that difference more clear. I have a hypothesis that Actions may be difficult for users to find when Panes are open currently.
3. Moving Actions to the right allows a future where the "commands" button is just another Action button at the top of the right sidebar, which aligns with apps like Obsidian. It also allows "share"-related Actions like the Create Share Link command to be placed in the conventional upper-right position (upper-right is often a spatial metaphor associated with "out", "share", and "export")

One thing I don't like about this is that Load external model feels out on it's own, as it feels somewhat entangled with file tree actions, which contradicts my second point about conceptually separating these button types.

I am okay with not doing this if you all don't like it, I don't think any of my reasoning points are insurmountable, I just have been thinking about final appearance changes to the app before V1, trying to identify the things that will cause the most user pain if we change them after we have users getting used to their workflows in the app, and I think moving the location of UI areas is a big one. So I want to either make this move or stick with the approach we have for the long-term if we can.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated (UTC)
modeling-app	✅ Ready (Inspect)	Visit Preview	Apr 21, 2025 6:04pm

[qa-wolf]

QA Wolf here! As you write new code it's important that your test coverage is keeping up.
Click here to request test coverage for this PR!

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 85.06%. Comparing base (00b779a) to head (727a7e8).

Additional details and impacted files

@@                                Coverage Diff                                 @@
##           franknoirot/adhoc/appearance-tweaks-modeling-view    #6377   +/-   ##
==================================================================================
  Coverage                                              85.06%   85.06%           
==================================================================================
  Files                                                    108      108           
  Lines                                                  46338    46338           
==================================================================================
  Hits                                                   39417    39417           
  Misses                                                  6921     6921           

Flag	Coverage Δ
rust	85.06% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[franknoirot]

Here are some relevant mockups I've been toying around with for panes. We have a different problem than IDEs because the buffers in an IDE are the main event, and while some dev-minded folks might disagree I'd argue it never is for us, but it really can eat up a lot of screen space, especially if we want to support buffers in the future.

[jtran]

"Never" is a strong word. I think there are legitimate use cases for all of these:

• No code. 100% scene.
• Low code. 90% point and click, but I want to see how it's editing my code or I want to make minor tweaks to code when needed.
• 50/50. I'm writing code, but I want to interactively see the scene output.
• 0 scene since all it does is get in the way. I'm writing KCL because point-and-click doesn't support it, and the scene doesn't help me. We could improve this in the future, but it may never help in some cases. I discussed with nrc using the Logs pane for the equivalent of console.log() output. As people make larger KCL programs and we get implicit unit conversion (coming soon Turn on units of measure (BREAKING CHANGE) #6343), debugging is going to be needed. In this case, I might want code on one side and Logs on the other. So maybe this is another 50/50, where the other half isn't the scene, but log output.

Ultimately, I think it has to be customizable. It's only a question of when.

[lee-at-zoo-corp]

@jtran 's breakdown is an excellent reasoning behind why customization is useful: supporting more workflows.

Unfortunately customization has its own costs to bring to life.

Let's find the cheapest way to cover most cases.

[nadr0]

I agree with Jon's points. From an implementation stand point we could implement it based on those 4 points even if most people only use 2 of them. This gives us better flexibility in our workflows in the future. His bullet points are a perfect example of what is a dependency and what we would artificially make a dependency.

[franknoirot]

Yeah @lee-at-zoo-corp I agree with you @jtran "never" is too strong of a word. Those are good examples of code-oriented user journeys, and good things to think of.

[franknoirot]

I agree with Jon's points. From an implementation stand point we could implement it based on those 4 points even if most people only use 2 of them. This gives us better flexibility in our workflows in the future. His bullet points are a perfect example of what is a dependency and what we would artificially make a dependency.

This, along with @jtran's points, are good for future UI improvements. Can we open a discussion or issue about it? I don't think I can't rethink this layout responsibly before V1. Unless you all want to hop on a call together and hammer it out this week.