Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

References should keep styling from original data list #1222

Open
lusebille opened this issue Sep 23, 2024 · 6 comments
Open

References should keep styling from original data list #1222

lusebille opened this issue Sep 23, 2024 · 6 comments

Comments

@lusebille
Copy link
Collaborator

lusebille commented Sep 23, 2024

Today when I create a list in a table and I use it in another table / widget as a reference/or multiple reference, style is not keeped.
For exemple if my orginal list is a choice list with colored tags it tooked me time to do, I will loose all benefit of that landing with a white or grey list.

Notice than in a few days already 4 users complain about it ( 5 including myself ).

I'm joining screenshot and a Grist file.
In the exemple 'Tags' column is used a a references for 'Keyword' column.Styling references_OK.grist.zip

Image
Image

@lusebille lusebille converted this from a draft issue Sep 23, 2024
@lusebille lusebille changed the title Test References should keep styling from orignal data list Sep 23, 2024
@lusebille
Copy link
Collaborator Author

@vviers here the content for the ticket to move to French Administration Board with the good way to write a ticket I suppose

@lusebille lusebille pinned this issue Sep 23, 2024
@lusebille lusebille removed this from Grist UI/UX Sep 23, 2024
@paulfitz paulfitz changed the title References should keep styling from orignal data list References should keep styling from original data list Oct 10, 2024
@RogerPenna
Copy link
Contributor

I wouldn´t say SHOULD keep the styling. But the OPTION to keep the styling would be indeed welcomed.

@lusebille
Copy link
Collaborator Author

Hi @RogerPenna, I would be interested to know in which cases it's interesting not to keep the styling of references.

@RogerPenna
Copy link
Contributor

A referenced value might appear in multiple tables or widgets, each with its own formatting rules to maintain visual coherence. For example, a budget column might show categories in colors within one table, but those colors might clash with or confuse the design of a summary table or dashboard.

Some users may prefer to reduce visual noise when presenting summarized or aggregated data. In such cases, a plain or neutral format can make the report cleaner and easier to read.

In certain roles or widgets, styling may not be relevant. For example, technical staff reviewing raw data in a control table might not need the same visual cues as management, where formatting emphasizes priority or status.

What is highlighted in one table (e.g., priorities with colors) may not need to be highlighted in another. For instance, a table for detailed tasks might use bold or color-coded tags for urgency, but when those tasks are referenced in a high-level overview, such styling might distract from other key metrics.

Again, notice I never said I am against it. I am saying it should be an OPTION, not something by default.

@tayflo
Copy link

tayflo commented Oct 23, 2024

Hoi 👋 I might add that I may also come handy for properties retrievals more broadly, e.g. through lookup and not only through reference.

For instance, I have a table A with a "Type" column (which could have the nature "unique choice" for instance), with style set on each type/choice. Then in a table B I retrieve the item.Type property somehow through formulas. Having the option to import both the value (here, the string of the given type) and the styling of the property could be nice.

@lusebille
Copy link
Collaborator Author

Hi, I added mocks to this ticket , so new user story will be :

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: No status
Status: In Progress
Development

No branches or pull requests

3 participants