sylvia-tomiyama commented on issue #8655: [SIP-30] Remove Tabs in SQL Lab URL: https://github.com/apache/incubator-superset/issues/8655#issuecomment-588372885 +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 :(
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] With regards, Apache Git Services --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
