I want to get my actual Timeline to have colored bars just like this, but I don’t want to recreate duplicate conditional formatting rules in the Timeline view fo every single color in the source table - it’s annoying and also they’ll just break if the source table changes
I thought “INHERITS FORMATS FROM” would help me out here, and even though it says “6 rules” above, it doesn’t seem to actually do anything - removing the (duplicated) format rules causes the colors to fail, even though it still says 3 rules remain:
What the heck is going on here?
Is there any way to get those timeline bars to have colors inherited from an upstream table? (conditional formatting or otherwise)
At least in regular table layouts, in my experience, the formatting inheritance works as you’d expect.
Edit: no, thought about it more, the formatting is being applied to different things I’m guessing. Parent formats impact Status column, child formats impact… whatever you selected (all columns?). Try having the parent format paint the display column (Title) as well as the status column.
Indeed, coloring “All columns” of the source table causes these timeline bars to change colors to match - however, now my source table is a bright mess of colors that’s really hard to read and burns my eyes. Very distracting to the point of making the data inaccessible.
Is there a way to use a Conditional format formula to specify the output color? (not just the if-condition)
Or some other place to apply formulas/logic that affect only the downstream timeline/table?
(I’m thinking, maybe I can read the color of the upstream source table text, and then apply it to the downstream view)
The color of the timeline bar is dependent on the color given to the display column - this is why coloring “all columns” worked for you - because by default it applied it to the display Column in your source table.
So the solve here is to, in your timeline table, set the conditions for colors on the status column like normal but apply them to the display column.
The display Column is the column with the little bookmark icon next to it
You could also apply those formats in the source table to the display column and status column only, and have them inherit on your timeline.
Also, best practice is to have your “source” table always be in a hidden table and used only for development, or setting these master conditional formats for views to inherit.
Then, even if you did apply the format to ALL Columns (which isn’t technically needed) it would matter because the tables you always work out of day to day are in a separate space!
We teach all sorts of principles like this in 30DaysofCoda! A totally free newsletter covering soooo many things.
Yeah I noticed it pulls the coloring from the Display Column (usually a name/title column), but that’s no good. This forces me to make the name column unreadable in the source table.
Hmm, Scott if I do your suggestion (hide the source table and add a dummy table view that people edit instead), I think that won’t work either, because:
Pretty confusing lol
Requires duplicate work: Any time we add something new (eg. a column or rule) we’d have to apply the changes (eg. make the column visible or duplicate the rule) to both the view-table and the actual source-table …right?
Doesn’t solve the problem: If I need to have one view that colors based on one column (eg. Status), and another view that colors based on a different column (eg. Completion Phase), I simply cannot …right? (cuz views can’t inherit from other views, so I can’t have 2 Timeline views inherit color from different dummy table-views, they can only inherit color from the 1 actual source table, specifically: whatever single color the display column is made to be?)
.
Unless that’s^ wrong, I think I’m just gonna have to bite the bullet… and duplicate all the colors in separate conditional formatting rules across my Timeline views. Even though the color is RIGHT THERE and it just cannot use it
Dan, If you want to keep your current architecture, make a new column whose only purpose is being a display column. Formula is =Title. Hide it in the table view. Colour it in the table view with your conditional formats.
(Inheritance has to work this way, where timeline bars are just based on display column, cause what if you had different columns in the source table with different colours? How would the timeline view know which column to pull colour from).
Scott’s right though on the best practice of your base tables living on hidden pages. It lets you have a sprawling doc builder view of every single column, all your little calculation columns nobody is going to see, lets you set inheritable conditional formats from a central control area, etc. And then you make views off of that with users in mind. Arguably overkill for a verrry simple doc but I use it almost every time for a doc that people will actually use day to day.
Only drawback is notifications send people to the base table which is something I hope they fix soon.
If I’m understanding correctly, won’t that inheritance still only support 1 view?
As in, my 2 timeline views can’t have different inherited coloring, because they’d both be coloring based on the source table’s Display Column, which of course can only have 1 color.
(For clarity’s sake, here’s my simplified setup)
Source table, with Display Column A, Column B, and Column C
Timeline View 1, trying to color the bars based on column B’s coloring
Timeline View 2, trying to color the bars based on column C’s coloring
.
In closing, I think I’m still out of luck, but the original question at the top of my post has an answer:
“INHERITS FORMATS FROM” does inherit conditional formatting rules, however, that’s unlikely to actually do anything in a Timeline view (even in Coda’s own Timeline template) because only the formatting of the Display Column is used in Timeline views.
It’s a bummer we can’t make conditional formatting inherit formatting from the column being referenced.