Data views: Add density preference to Table layout

[jameskoster]

Depending on the type / amount of data being viewed, and accessibility preferences, it could be nice to offer users a density option in data views Table layout. In addition to the default spacing, we might offer higher and lower density options.

Increased density

Relaxed density

These options would likely live in the view options. What do you think?

[mtias]

Agreed with supporting this. It's useful for offering extenders flexibility while also recognizing user preferences. It's also somewhat analogous to grid item size for the grid view.

[rogermattic]

+1 on this! we'd use this for payments reporting for sure, we need to support densed views.

I was wondering if you'd consider adding a predefined options for users? Like in Gmail for example where the user can swap between 3 different density levels?

[oandregal]

For the record, I've grouped together issues related to "theming" in the dataviews component issue, so they are visible #55083

[jameskoster]

Yes to predefined options. We need to work out how many to offer, and where the current config falls on the scale.

I don't know that we could create the gmail example with the current component set, that feels like a detail to explore later if we identify other situations that would make use of such a UI.

Initially it might make sense to mimic the 'Preview size' option in grid layout:

[rogermattic]

Thanks @jameskoster !
I'll make two mockups then, this one with the slider and another one for a possible component that we might add later.

feels like a detail to explore later if we identify other situations that would make use of such a UI.

I'll think about other potential cases.

[jameskoster]

It would be good to mockup the tables with different density values too, the ones in the OP were quickly hacked together :)

[rogermattic]

@jameskoster I made the mockups for the Density. In general I feel like three density options to choose from would be enough:

1. Selection with a tick

I think that works well, just the icons are placeholders for now. Do you think that's worth exploring further?

2. Slider

I made a similar mockup to what Veronica (not sure what's her username here on GH) proposed, but I thought it would be better to have just 3 levels not 4 (for Default, Compact and Comfortable)

3. Radio

Was thinking about the simple radio button option but I realised we might not want to use that on the panel, as the component for the items per page and order works as a radio selection..? I made this option then, but understand that might be a bit of a stretch!
3 options squeezed inside that component felt like a bit too much, but I thought we might also want to try just offering 2 options - Compact and Comfortable

What do you think?

[jameskoster]

I still lean towards the slider myself, just because it is consistent with the 'Preview size' option in Grid layout.

We can revise holistically after.

Using ToggleGroupControl is an interesting idea though, it might work nicely with icons? Quick mockup:

[rogermattic]

Using ToggleGroupControl is an interesting idea though, it might work nicely with icons?

I love this! It's simple and gives us the flexibility that we need.

As I mentioned elsewhere I think we should be able to come up with three predefined settings for the general table component (adjusting padding, badge variant if needed, and perhaps choosing a different variant of the body copy size from the predefined typescale).
Then each table, depending on the use case, would initially be set to a different default; for example, a number-heavy table would use a compact view, while a blog post list would use a comfortable view, etc.

That would be hard to solve using the actual default label (in the option where we'd have Default, Compact and Comfortable). If for one table the default would be set close to Comfortable we would need to add an extra grade above etc. The visual only approach doesn't require us to label things, whether it's a slider or a toggle group.

I still lean towards the slider myself, just because it is consistent with the 'Preview size' option in Grid layout.
We can revise holistically after.

Considering using ToggleGroupControl do you think we could settle on this or would you instead still start with the slider?

[ntsekouras]

I think density is something that could be supported by any layout if they want to and in order to do that maybe a first step is to use predefined options (like Default, Compact and Comfortable) and not specific icons for every one.

Would it be okay to start without icons for now?

[rogermattic]

@ntsekouras Thanks for your feedback!

I'm not convinced anymore that we should use text labels, for the reason I mentioned earlier:

That would be hard to solve using the actual default label (in the option where we'd have Default, Compact and Comfortable). If for one table the default would be set close to Comfortable we would need to add an extra grade above etc. The visual only approach doesn't require us to label things, whether it's a slider or a toggle group.

But as @jameskoster said, we can start with a slider approach first; in this case, the default setting would just be captured initially by the slider's position. WDYT?

I still lean towards the slider myself, just because it is consistent with the 'Preview size' option in Grid layout.

Are you happy with a three-grade slider or leaning more towards a continuous line? @jameskoster @ntsekouras

[ntsekouras]

I'm okay with the slider but also checking the code right now to see how we can abstract it better for any layout. It seems we show different density options depending on the viewport width. Is this something we want to preserve? Because it might not make sense in all layouts and we might want to be consistent and always show 3 options.

[ntsekouras]

Now that I'm exploring it a bit more, I don't think we can avoid the labels as the default could be anything for a layout - it could be closer to compact or comfortable. So, I'm not sure we can use a slider..

[rogermattic]

Is this something we want to preserve? Because it might not make sense in all layouts and we might want to be consistent and always show 3 options.

I think we should be consistent and always show the same number of options.

I don't think we can avoid the labels as the default could be anything for a layout - it could be closer to compact or comfortable.

I think we could display it like that:

If the default is comfortable:

If the default is compact:

The in-between state:

However I'm worried about the case when the predefined state for some component means comfortable, then what do we call that 3rd option – i.e. we'd have (sorry for the rough mockups):

I'm wondering if this wouldn't be confusing for the user, why the initial setting isn't a default one :D

It's easier with two options:

Or we need to replace the name default.

[rogermattic]

Something that I'm exploring in parallel is how the Density setting would result in the views , for now just on the table (transactions report, disputes report and the list of pages) example:

I marked what in my opinion should be the initial views for each example with a green dot.
There's more options available, but I think we should still aim for 3 presets – Comfortable Medium Compact.

[ntsekouras]

I created a PR for this here and we can discuss and update the design.

There's more options available, but I think we should still aim for 3 presets – Comfortable Medium Compact.

By implementing this I realised the validity of @rogermattic's point about the default label and shouldn't be used as a preset. It makes sense to have presets like the suggested with increasing density and a consumer could set whatever default value they want.

That also means, that if we agree on such presets, a slider could also be used.

[rogermattic]

@ntsekouras I just saw the screencast on the PR. t looks great! I really love the clarity of this approach—the labels make everything so clear. My only concern is whether longer labels might cause issues with fitting, especially once localized.

By implementing this I realised the validity of @rogermattic's point about the default label and shouldn't be used as a preset. It makes sense to have presets like the suggested with increasing density and a consumer could set whatever default value they want.

Thank you! Sorry if I wasn’t very clear in explaining that point :)

I was thinking about the alternatives to default and medium, we could also used balanced regular or moderate.

[annchichi]

I was thinking about the alternatives to default and medium

I was reading through the convo, and if the options label default and medium, the default name doesn't clarify what it is. Like Google's options (screenshot above), there is a need to click other options to find what default means. :)

[mcsf]

However I'm worried about the case when the predefined state for some component means comfortable, then what do we call that 3rd option – i.e. we'd have (sorry for the rough mockups):

To add another difficulty to that representation: these labels are already snug in English, and they could become very awkward in other languages.