Don't scroll group header rows horizontally

[seancolsen]

Current behavior

• Horizontally scrolling a table page with group header rows looks pretty weird.

  

Desired behavior

• The group headers use position: sticky; left: 0; to prevent horizontal scrolling.

• The tricky part then becomes dealing with group headers that are wide to fit within the viewport. For example:

  

  We would need to figure out some way to making these shrink responsively, using Truncate, similar to how I've done within the navigation header. I suspect that even just getting the group header row to fit the width of the sheet bounds will be a little tough. If we didn't have a table inspector we could size it via width: 100vh;, but that won't work when the table inspector is visible. I might consider reaching for Svelte's bind:width feature here, thereby determining the width of the sheet bounds via JS and then passing that width into the group header row.

@ghislaineguerin @pavish @rajatvijay Does this sound okay to you? If so we can un-draft this and apply a "help wanted" label.

[pavish]

I'm okay with this, but I think whoever's working on this should submit a solid proposal for the UX. As it stands, we need the person to figure out the UX, get approval from the team, and then work on this issue.

[faraz16iqbal]

@pavish I would like to work on this. I'll look into it and submit a proposal for the same. In the meantime, Can I be assigned to this issue?

[seancolsen]

That sounds good @faraz16iqbal. I've assigned this to you. I've removed the draft status and applied the "design" label to indicate that you'll be working on some UX design. Please submit a comment on this ticket proposing the behavior, taking care to consider edge cases and the overall goal of delivering a high-quality user experience.

[faraz16iqbal]

@seancolsen understood, thank you!

[pavish]

@faraz16iqbal There has been no response from your end regarding this issue. Are you still working on it?

[dauinh]

Hi @seancolsen @pavish

Can group header columns have the same width as sheet's columns? For example, group title and id align, group author and title align. This would ensure that group header row won't go out of bounds with the sheet. If the user needs to see content of each group, they can drag out the column or click on the corresponding cell.

[seancolsen]

@dauinh I don't like that design for the following reason. I predict that the most common scenario will be for the user to group by one column, and for that grouping column to have content that is does not necessarily fit into the width of the first column. At some point soon we would like to allow the user so persist column widths after resizing columns. At that point, the id column will likely be pretty narrow on most tables. All of those things taken together would produce a highly truncated value in the grouping row.

[rajatvijay]

Un-assigning due to in-activity.

[dauinh]

@seancolsen Oh, I see how that doesn't work now. If we are fitting all group columns in viewport, can we set a limit of how many groups user can use?

[seancolsen]

can we set a limit of how many groups user can use?

Good question. Such a limit would alter the capability of the grouping functionality, and that sort of change would require that we involve more people in this discussion. While it's hard to imagine users setting up something like ten levels of grouping, I'd rather avoid such limitations if we can, at the very least because it will require more people/time to form an agreement.

That said, I'd be open to hearing your ideas for how the group header might work in a hypothetical world where we could limit the number of grouping levels.

Keep in mind that even if we did impose limits on the grouping depth, we'd still need to face the design challenge of overflow with only one or two levels of grouping due to long content.

[dauinh]

@seancolsen

Can we get the width of viewport from <svelte:window> binding? If so, I'm thinking about setting groupColumnWidth = windowWidth / groupCount. This would align all group columns, but overflowing content would be hidden. If user wants to see the content, they'd have to click on corresponding cell.

What do you think about this approach?

[seancolsen]

@dauinh Sorry, I still don't like that design.

In the ticket description I said:

similar to how I've done within the navigation header

I think we should stick with this. I'll elaborate a bit...

Here is the relevant code that handles the responsive behavior for the navigation header. You can see a short video demonstrating the responsive behavior. The navigation header has a dynamic number of breadcrumb items and uses flexbox to handle the responsive behavior. If all items fit within the container width, then everything is aligned to the left and nothing is truncated. This is behavior is nice because it allows arbitrary items to be quite wide as long as the total width doesn't exceed the container. When truncation is necessary, then longest items are truncated first until all items are the same width.

If this makes sense to you, and you'd like to work on the issue, then I can assign it to you.

[dauinh]

@seancolsen Ah, that makes sense, thank you for your guidance. I'd like to work on this, please assign it to me.

[seancolsen]

Sure @dauinh, go ahead.