Where do we go with tabs?

[gabalafou]

In the call today, we discussed some directions for tabs.

Tabs can be useful but they also come with a cost. For example, none of these issues would exist if we did not have a tabbed interface: #333, #334, #382.

There are a number of different things we can do, such as:

• Remove tabs
• Fix app URL routing
• Refactor and separate app state for each environment edit form

Here's my step-by-step proposal:

1. Fix app URL routing and remove in-app tabs. This provides a stop-gap solution to the tab issues by allowing the user to leverage the browser's tabs. This also provides a number of side benefits (such as shareable URLs).
2. Give each environment edit form its own place in the app global state. In my opinion, this needs to be fixed no matter what because users expect modern web apps to be more stateful than they were in the past. They expect to be able to make a change, navigate to other parts of the app, and then come back to where they left off. This expectation is currently broken in Conda Store UI. If the user opens an environment form, makes some edits, navigates to another part of the app, then comes back to the environment form, all of their edits are lost.
3. Decide whether and how to reintroduce tabs, taking into consideration things like using Conda Store UI as a JupyterLab extension: should we have our own tabs or should we re-use JupyterLab's built-in tab functionality?

[dharhas]

The original ui mockups did not have in-app tabs, they got introduced along the way during implementation. My vote is to remove them. Currently, I feel they cause a reasonable amount of confusion (especially when embedded inside Jupyter) and don't provide much in terms of extra functionality. I like the idea of proper url routing since that also meens I can email someone an exact link to an environment.

[kcpevey]

Fix app URL routing and remove in-app tabs. This provides a stop-gap solution to the tab issues by allowing the user to leverage the browser's tabs. This also provides a number of side benefits (such as shareable URLs).

This feels like the right solution to me. The only usecase for tabs is comparing/switching between two environments. If you have a lot of environments available in the sidebar, this becomes cumbersome, but with proper URL routing you can use two browser tabs to get the same basic functionality - perhaps better since you can view them side by side.

Also as mentioned, this solution provides the ability to share URLs. This is actually a really useful feature in and of itself - one that I could use several times a week.

[trallard]

Re

Decide whether and how to reintroduce tabs, taking into consideration things like using Conda Store UI as a JupyterLab extension: should we have our own tabs or should we re-use JupyterLab's built-in tab functionality?

I would prefer using the JupyterLab built-ins tbh

[smeragoel]

I agree, I think using the browser tabs instead of in-app tabs would be a nice UX improvement. It is consistent with what users would expect in the context of a browser-based app, and it will simplify the interface as well. Users are already familiar with managing browser tabs, plus they would have access to more advanced features like native tab organisation (if offered by their browser).

[gabalafou]

Per today's sync, I will follow the plan in the original post. We can continue to discuss how we want to bring back tabs, if we want to bring back tabs.