[SIP-30] Remove Tabs in SQL Lab

[SIP-30] Remove Tabs in SQL Lab

Motivation

SQL Lab is devoting screen space to a custom tab UI that is less effective than that offered natively by the browser. Other upcoming features such as more powerful edit history/undo, and better navigation/discovery make tabs less important. The new design directions coming from the superset design group specify a tabless UI. Browser-based tabs would be a better solution for nearly every SQL Lab use case.

Proposed Change

• Remove the tab bar in SQL Lab
• Include the id of the current queryEditor in the SQL Lab url: myapp.com/superset/sqllab/42
• Links throughout Superset referencing SQL Lab queries should use urls with a queryEditor id
• Implement a user-level flag to switch between the tabful and tabless UI
• Stabilize backend-managed SQL Lab state, and make it the default option.

This change can actually be made without significant changes to state management. SQL Lab state includes some number of queryEditors (“tabs”). Instead of each queryEditor referencing an in-page tab, the SQL Lab url will contain the id of the queryEditor being used.

This will depend on the backend implementation of state management for SQL Lab which is currently behind a feature flag. Without backend SQL Lab state, your local state would accumulate until there is too much to manage, without a practical way to clean it besides clearing your localStorage or editing it laboriously.

One change that will be tricky is offering users a quality migration experience to the tabless UI. More details on that down the page.

A note on preventing lost work in a tabless UI

Nobody wants to write a query, then close their browser and lose it forever. Mitigating that in this new design will be important. The full UI/UX redesigns call for a robust history feature, but there are some things we can do to protect people’s work without the history feature.

When you navigate to SQL Lab without specifying an id in the URL, an id will be generated for you just as if you had clicked the “+ tab” button in the current UI. This will allow users to re-open a closed tab from the browser history, even if they didn’t save the query. If a user wrote a query but didn’t save it, and closes the browser tab, SQLLab should also warn and offer to save the query before the tab closes. If you run or save your query, those will also be ways to recover your work.

Just for reference, here’s the design we’re working towards. This SIP is not about implementing everything on this screen, only replacing the in-page tabs with browser tabs.

New or Changed Public Interfaces

• “Run query in a new tab” button in the query history will open a new browser tab.
• “Share query” should use the new url format, and should save the query if it hasn’t been saved.
• Links in the saved queries screen and query search should use the new url format.
• Remove the ctrl-t keyboard shortcut?

Migration Plan and Compatibility

We should allow users to migrate to the new system at their own pace. Tabs are a heavily-used feature, and should not be ripped out without a proper transition phase to educate and re-orient users.

A per-user feature flag will be added indicating whether they are using the tabful or tabless version of SQLLab. SQLLab will appear unchanged as long as a user’s flag is off, with the exception of a small banner in the corner notifying the user of the new tabless experience, and allowing them to flip the flag on. Once they flip the flag SQLLab will change to the tabless UI. There should be an explanation of the change, with useful info on how to navigate this brave new world.

After some time, we can turn this flag on by default for new users. Eventually when the tabless UI is deemed stable, people are happy with the change, and we’ve made sure that there isn’t a negative impact to existing user needs, we can switch everyone over.

Rejected Alternatives

• Keeping in-page tabs - too cumbersome to use, not as accessible, adds unnecessary state complexity
• Switching over immediately to a tabless UI without a feature flag - too jarring to users, want to give them the opportunity to change to the new system when it’s convenient for them.
• Developing the new SQL Lab designs in a separate screen alongside the original SQL Lab - too much code complexity and chance of breaking changes, not enough opportunity to reuse existing components.
• Re-organizing SQL Lab frontend state around a tabless UI - too much work for now, and breaks compatibility between the new and old version of the page. It will likely make sense to re-organize state in a future release once all users have migrated to the tabless UI.

[graceguo-supercat]

Hi @benceorlai I think understanding some implementation details (the “How”) part will help me make decision. In the current behavior, I can easily see all my old queries in a list of sql lab tabs (and within 1 browser tab). Do we still have this benefit (see all the old queries in a central place) in the single sql lab tab solution? I can find all my queries from query history…but every time i need to switch browser window to do it, which is far less convenient than a single click.

[sylvia-tomiyama]

+1 to all of the questions above. As the folks on this thread are aware, Tabs are a very popular feature in our deployment so we want to be careful about changes and want to make sure we know what we’re voting on. (I also recognize that folks have iterated on the proposal based on feedback, and I appreciate it 😃)

A few additional questions I have: (1) Will users have the option to flip back to the tabbed version if they don’t like the tabless version? (2) If most users choose not to migrate, and/or if they flip back, what will we do then? I assume our goal with this transition period is to ensure that we’re making the experience better for users, so I’d like a clear process and commitment to address major points of feedback if we find that most people are opting out of this. (3) What’s the value proposition for the user? As context, tabs are a heavily-used feature in our deployment, though people also have frustrations with it. Ideally we’ll be able to say why/how this is a net improvement for users. Right now, to me it seems like there’s an idea of a much better experience in the long-term but this is an intermediate step that doesn’t add clear value for users that creates work/requires users to deal with change. In general, I think we should ensure that when we require people to migrate, the benefits should clearly outweigh the costs and for me right now this isn’t super clear. So I’d love to have this spelled out in terms that users can understand (e.g. – does this solve the problem of losing in-progress work when local storage is cleared? Does it make it easier to access the in-progress work?) (4) If the added value isn’t clear, then what are things we could add/modify to this proposal so that it does? For example – making it easier to find saved queries and/or your query history; automatically adding each new tab you create to your saved queries; etc. (5) Can you help me understand whether the proposed will have any regressions relative to the current experience / make sure that the proposal will meet the use cases people have for tabs today? Mainly, people use tabs as a way to (1) organize their work and (2) save in-progress work. A common scenario is that someone may have two or more different subject areas they are running ad hoc analysis on, and that they are working on over a period of days or even weeks/months. I’m not 100% certain after reading your proposal (and its modifications) a few times, so I’d appreciate your help. (6) If this is a necessary step for the long-term plan, and that’s our primary/only reason taking this step (e.g. if this middle step isn’t a clearly better experience for users but we’re doing it because it’s our only way to transition to the ultimate experience), then I’d like clarity/to first vote on what the long-term plan is.

Also, apologies that I didn’t send this sooner – I had a lengthy comment half-written that I lost 😦