remove unused style; apply 95vw max width to users table in Facility

[nucleogenesis]

Summary

Addresses issue noted in recent bug hunt by @rtibbles regarding the users table's width (or lack thereof).

There's so much screen available - so why would we limit the big table of data to the same width we use for settings forms and such?

The changes here remove an unused wrapper div that duplicated widths enforced elsewhere.

Then using a deep style we target our own main-wrapper style to override the page width specifically for the Users table without affecting the other Facility pages.

Screencast_20250228_091120.webm

References

#13127 lists the issue & links to the relevant Notion

Reviewer guidance

• Try users table on various screen sizes. Does it look okay?
• Check all other pages in Facility and see that they don't have any regressions.

[github-actions[bot]]

Build Artifacts

Asset type	Download link
PEX file	kolibri-0.18.0b1.dev0_git.27.ga7f274c9.pex
Windows Installer (EXE)	kolibri-0.18.0b1.dev0+git.27.ga7f274c9-windows-setup-unsigned.exe
Debian Package	kolibri_0.18.0b1.dev0+git.27.ga7f274c9-0ubuntu1_all.deb
Mac Installer (DMG)	kolibri-0.18.0b1.dev0+git.27.ga7f274c9.dmg
Android Package (APK)	kolibri-0.18.0b1.dev0+git.27.ga7f274c9-0.1.4-debug.apk
Raspberry Pi Image	kolibri-pi-image-0.18.0b1.dev0+git.27.ga7f274c9.zip
TAR file	kolibri-0.18.0b1.dev0+git.27.ga7f274c9.tar.gz
WHL file	kolibri-0.18.0b1.dev0+git.27.ga7f274c9-py2.py3-none-any.whl

[MisRob]

What determines the width of the KTable columns, and are there existing props to make those more flexible? Should there be.

Each KTable column width is configurable via minWidth and width attributes of the headers. There's "Table with custom column widths" section in the docs with examples.

With this I am not suggesting we take this approach - as @marcellamaki says better to chat with relevant folks, perhaps we indeed want to have more space for larger tables. Just a reference if that shows to be helpful.

[nucleogenesis]

@marcellamaki I chatted w/ @rtibbles a bit about the reported issue and he confirmed that the issue he was reporting was the artificial constraint on the width, so that's what I addressed here. I initially was thinking about the guts of the table and stuff but after chatting w/ Richard it became apparent I was overthinking the reported issue :sweat_smile:

IMO this is a pretty quick win because showing a data table using only ~33-50% of the available width is a poor use of the available space in-context. In any case, happy to update this as discussion proceeds.

@tomiwaoLE and/or @jtamiace could you give this a look and let us know what you think of this change?

[jtamiace]

I don't think I can make a recommendation on the best code snippet to use for defining the max width, but in general I do think that using more of the screen space is helpful for data tables like this and this is a good move.

The only case I can think of where 95vw might degrade the UX and make it a little more difficult to read is when someone is using a very wide screen and the text in each cell is distributed far apart from each other. Maybe a non-issue because I assume many of our users won't be managing users full width on 40+ inch screens? But I wonder if it makes sense to introduce an upper limit and if one of the KDS container or grid components can be customized to display these large data tables at a width that feels right.

[MisRob]

Linking https://github.com/learningequality/kolibri/issues/13104

[MisRob]

I wonder if it makes sense to introduce an upper limit and if one of the KDS container or grid components can be customized to display these large data tables at a width that feels right

@jtamiace @nucleogenesis @marcellamaki

Yes, it'd be great if we can be consistent.

I didn't read the whole article, but has some recommendations as for what values to use. It made sense to me - I agree that the distinction between article-like content and other content is important.

(1) Article-like

When determining the ideal width for a text block, a commonly used guideline is to aim for a line length of about 50-75 characters, including spaces.

This is a common a11y recommendation that can be found in many resources. Maximum width could then be roughly determined based on this criteria and our font sizes.

(2) Other content

I think that grids of cards, tables, and such would be this category where we would have larger upper limit than for (1), e.g.:

Websites commonly use a max-width of around 1140px to 1200px because this size works well with 12-column grid systems and is visually comfortable on standard desktop resolutions.

---

We may have two container sizes reflecting this generally. To get to the precise numbers, I imagine we could just play around and let @jtamiace decide what looks best on few sample Kolibri pages?

It's simple to implement, so basically it's just about having an agreement about the numbers.

[MisRob]

By the way @nucleogenesis, @BabyElias saw this, and appreciated the idea to have more space for tables :)

There are more places with tables, so if we can come up with a general guidance, we can improve them all at once.

[marcellamaki]

I've moved this into the 0.19 milestone - let's pause this for now and resume in the course of 0.19 work

[nucleogenesis]

Superseded by #13743