Upgrade design system

[dcousens]

(this is a draft)

[gautamsi]

@dcousens
I believe this is a blocker for #9186 ?
Do you have any figma/design link we can provide feedback on ? is this going to refresh only the design elements or the design of the page overall? like the hints provided 2 years ago in a developer talk?

[kennedybaird]

@jossmac - How do you test for a wide range of fields, do you run the sandbox with "all the things"?

We used a Status select which made everything read only once past "draft". This showed a bunch of UX that could be improved - they may seem as less common use-cases, but I have noticed a lot of projects that use in this way (and have done myself a few times).

• null values on End Date, Reviewer
• disabled drop down on User, Reviewer, Tags
• Poorly used space with "View User details"

--

We could add a simple checkbox to make them all read only in the sandbox project - wdyt @dcousens?

[dcousens]

@kennedybaird I think adding a checkbox (or cookie, or) that can easily switch between different field modes will be incredibly helpful in debugging UX

[kennedybaird]

@kennedybaird I think adding a checkbox (or cookie, or) that can easily switch between different field modes will be incredibly helpful in debugging UX

@dcousens - to clarify, you'd like this to expand the current tests/sandbox, or a new project in tests/test-projects?

[dcousens]

tests/sandbox, but I think we can defer to @jossmac to know if that is useful in this pull request, or separately

[dcousens]

@gautamsi

I believe this is a blocker for #9186?

Yes, I think this is blocking

Do you have any figma/design link we can provide feedback on?

Unfortunately, the design work completed in 2022 and 2023 (that we intended to make public) was superseded by work in Keystatic

[gautamsi]

@jossmac I am sure you have noticed my work in #9186
We should move in the direction of SSR friendly design so that any SSR only rendering with NextJs 15 and react 19 should not require major rework in this regards.
They are around the corner and my idea is to move towards App router with maximizing SSR use in admin ui.

[gautamsi]

can we add 'use client' here, this is harmless in non ssr but useful in SSR with upcoming changes.

[dcousens]

@gautamsi any reason not to do this in the upcoming changes rather than this PR?

[gautamsi]

I can do that

[jossmac]

Totally on board with SSR friendly! This PR is pretty massive in scope, let's focus on app-router etc. after it's landed.

[gautamsi]

Looking forward to get this design uplift, would love to see this coming. wait is killing!!

[jossmac]

Known issues:

• keystone-ui component instances still litter more than a few corners of the repo
• ui within packages outside "core" haven't been reviewed
• relationship field was a mess, best efforts to update ui but i'm certain there's issues
• multi-select doesn't have filters
• list item selection dissonance between ALL and all in page
• list initialSort isn't respected
• some docs will be incorrect after this lands

Potential improvements:

• the cell contents of numeric fields (decimal, float, integer), and maybe temporal fields (timestamp,calendarDay) should be right aligned
• filter label should own complete render, allowing things like "not published" instead of "published is false"
• support user controlled cell density—needs UI and storage implementation
• support consumer controlled initial column widths—needs implementation
• support user controlled column widths—needs storage implementation
• support user controlled color-scheme—this might need to be prioritised, since old UI portions could be visually inaccessible depending on user preferences
• filter tags offer poor UX on mobile devices; consider something like AirTable's approach with a dedicated dialog. could also be an opportunity to introduce AND/OR functionality
• introduce item "actions" concept, which may solve consumer hacks