[Crud view] Data-->Databases page: Edit buttons invisible on database editor on crud view

[zuzana-vej]

On small screen laptop, the column "Actions" is completely missing. On larger screen laptop, the column is available with no buttons.

Expected results

Resize so that user with smaller screen can also see. Also have the buttons visible.

Actual results

No buttons are visible. For user with small screen entire section Actions is invisible.

Screenshots

Problem 1: large screen - buttons invisible

Problem 2: small screen - column Actions invisible

How to reproduce the bug

1. Go to 'Data --> Databases'
2. On Macbook 13 inch screen, the column with Action is completely missing
3. On larger screen, the column Action is there, but see the buttons are missing, only display when user hover over.

Environment

(please complete the following information):

• superset version: master
• python version: python --version
• node.js version: node -v

Checklist

Make sure to follow these steps before submitting your issue - thank you!

• [ ] I have checked the superset logs for python stacktraces and included it here as text if there are any.
• [x] I have reproduced the issue with at least the latest released version of superset.
• [x] I have checked the issue tracker for the same issue and I haven't found one similar.

Additional context

Regression/

[zuzana-vej]

(FYI @john-bodley )

[nytai]

@zuzana-vej The buttons only being visible on hover is by design.

There is a mind width on the table, so at smaller screen sizes the table changes to overflow scroll. Looks like 13inch MBP is unfortunately the width for 8 columns to fit perfectly across the screen, so it looks like the 9th (actions) column is completely gone. If you scroll the table horizontally, you'll see the actions column.

All List view tables function this way and it's one of the unfortunate side effects of trying to make these tables flex to fill the available real estate.

We have an open ticket for redoing these tables with a percentage based layout for the columns that came out of here https://github.com/apache/incubator-superset/issues/11689

[nytai]

design rationale around only showing actions on hover

part of the orig cartel design. the other option in this config is to have all actions show at default. that would be way too visually dense if that whole column showed icons at default level. were keeping this interaction for 1.0 we've discussed other options instead of having an actions column that could work nicely. but holding on changing all of this until next version.

@mihir174 or @steejay can provide more context

[zuzana-vej]

Maybe @john-bodley can confirm if he saw the option to scroll - it didn't appear like it from his screenshot, he is the one with 13 inch laptop.

With regards to the buttons missing (appear on hover) as design choice - interesting and thanks for clarifying that. I am not a designer, I personally thought it's a bug and I wonder whether users will think the same, but I am open to wait and see if more people raise this.

[nytai]

The scroll bar does not appear until the list is actually scrolled, that was a change requested by design as I believe in firefox the scrollbar would always render otherwise. As for the buttons on hover, we have had discussions around this internally and it is a contentious decision.

It's great to have this issue open though, so we can continue this discussion and hopefully achieve consensus on the best design for all users.

cc @mistercrunch and @junlincc as you've expressed opinions on these decisions before.

[ktmud]

All List view tables function this way and it's one of the unfortunate side effects of trying to make these tables flex to fill the available real estate.

If this was the case, it seems to me there are quite some real estate left still, at least for the Databases table:

Maybe there are ways to make the column width even more flexible?

[nytai]

We can tweak some column sizing values but it will still continue to be an issue at smaller screen sizes. At larger screen widths the columns would look very dense in some areas. I think the percentage based layout mentioned in https://github.com/apache/incubator-superset/issues/11689 is the more scalable solution, though it requires figuring out what percentage of the full width a column should occupy for each table instance (ensuring all values add up to 100%). Adding a new column would mean recalculating all the values again.

[ktmud]

https://apache-superset.github.io/superset-ui/?path=/story/chart-plugins-plugin-chart-table--big-table

Maybe we should just use dynamic width like in the superset-ui table chart (feel free to resize the container, sort different columns, and click on paginations to see the interaction).

There are ways to remember the initially rendered column width so the UI wouldn't seem so jumpy. Check out the useSticky hook for inspiration.

[zuzana-vej]

the scroll bar does not appear until the list is actually scrolled

how do you scroll horizontally if there is no scroll bar? Like I guess with the mousepad on mac you can, but how about with external mouse? It didn't appear to John to scroll or didn't seem like he saw any scroll bar.

[nytai]

@ktmud I'm still seeing some some column resizing, in your example, happening when sorting by name, and the table still has a min width and it changes to scroll once it's reached. You are correct, the column widths do shrink to minimum possible width (based on content) before the table begins to scroll, which is not a behavior on the list views (only a few column widths change with screen size usually "actions" and the "name" field). Design requested this behavior (only 1-2 columns change width while others remain fixed). This is the behavior of having an auto layout for tables and leaving it up to the table engine to figure things out based on the content provided. I'll spend some more time thinking about this over the break, but I have a feeling I'll still land on fixed percentage based layout being the best all-around solution for all screen sizes.

@zuzana-vej That's a good question. Most external mouses usually provide a horizontal scroll function of some sort, but you are correct not all do. I believe this mainly do to the way scroll bars work on MacOS though, and it is configurable

https://www.nytimes.com/2017/02/02/technology/personaltech/solving-the-case-of-the-disappearing-scroll-bars.html

[nytai]

I do want to highlight that 13in MBP users do represent a significant demographic and this is not an ideal experience and warrants a better solution that "you should just know to scroll" or "change your default OS settings". I just wanted to underscore that this is a hard UI/UX problem (without a perfect solution at the moment) and that there is currently a work around (though not immediately obvious).

[nytai]

I was able to adjust come column widths, as per @ktmud's suggestion, and database list view should now render all columns in view for the MBP 13in full viewport width of 1280px.

It does make things a bit tighter/off-balance on my external monitor set at 3008px, but that's relatively minor.