I created this really nice Federal grant evaluation table, and in it I designed the perfect canvas column to manage the scoring process of each grant opportunity. Everyone loved it and our grants team was blown away. It uses a canvas column for a specific ranking process.
> … if you can create a really cool canvas for scoring grants, can you also create another embedded layout for writing the grant white paper?
Of course, I said yes and created exactly that capability in a second canvas column. But then, I noticed my first canvas column now looked exactly like my second canvas column field. Is this not possible? Two canvas columns each with different layouts?
But, both canvas columns seem to default to whichever layout was most recently selected for either column. It seems that the layout selected for any given column should be persisted and possibly established in the Canvas Options.
@Bill_French — what you’re seeing is not a Canvas column. Not only the canvas column actually — what you’re seeing is the good old Detail Layout of this row. See how there are all the other fields around, and your two Canvas columns are just the two fields in there (Pitch content and Pitch instructions).
Basically, a Canvas column is basically a Text field but better — a Text field cannot have tables and certain other blocks in it but a Canvas can.
And whenever you click on a Canvas column content/icon, it does thisRow.OpenRow() basically.
What you need to do here is this:
Make another view of this table and select a different layout
Make a button that would open thisRow.OpenRow(ThatOtherViewName)
TL;DR: You’re not limited to one canvas, just like you’re not limited to one Text column. Clicking on a Canvas basically expands a row. So the limitation you’re seeing is a different one: there’s one row layout per view. To have multiple detail representations of the same row, make multiple views and open them with buttons. Basically check out the thread linked above.
I was able to follow your Mega Trick example earlier and it was extremely helpful in resolving my UX objective. However, I’m still puzzled why Coda didn’t embrace a simple construct - i.e., setting a layout at the column level such that any drill-down of the “canvas” icon would enforce the Maker’s intent which is to provide different editor UIs that are indigenous to each column.
Based on the inference provided by the UI (above) as I established two different layouts accessed through each “canvas” column, I mistakingly assumed I was building unique editing dialogs for each canvas field. This, I now understand, is a misconception, but it was a surprising outcome. The first rule of software engineering - don’t surprise users unless its a delightful surprise.
Shouldn’t the “Canvas Options” simply include a selector that allows us to choose which layout to assert for OpenRow() actions for each specific column?
Once I realized that layouts were not assignable at the column level, I figured - well, perhaps I simply need a formula on each canvas column to assert the desired layout much the way your Mega Trick accomplishes this. Any column should/could have an action and I assumed that must be the right way to assert the desired editor in each column context. But that is also not possible (e.g., why the Mega Trick exists), resulting in what we might describe as “going around the barn twice just to open the door”.
Indeed, I’m old and I miss a lot of stuff, but in this specific journey, my own logic which drives my expectations seems to be invalid and actually worked against me.
Given Coda’s amazing capacity to build arbitrary layouts doesn’t it create an even greater duty to make it possible to assert layout editors for OpenRow() click events?
UPD: I realized I could just delete the whole reply and explain all with one picture:
and they did it this way because of Notion.
What I wrote earlier
Feel free to send them some /feedback on this
What I think happened here is this:
The “expected” result of clicking on a Canvas column is to show that canvas only. I mean all by itself with no other fields from this row — similarly to a Big Text value like this:
However it’s not how Notion does it, and IMO Coda did this feature solely to be on par with Notion and to satisfy all those complaints that “waaah in Notion each row is a page, we need this in Coda now!!”. Notion does not show a row’s “canvas” on its own — it shows the title, creator, tags etc — all the other fields from the row!
So what Coda decided to do is also to not show a page on its own but include a “page header” with those fields. Which are the fields from the row. Which is what we’ve had since forever with “Expand row” layouts…
…and these were always one layout per view.
There’s no easy way to go around this. Showing just the Canvas without the row details is not gonna be nice UX wise. Maybe a “Select layout” setting on a Canvas column would help. After all, unlike Notion, Coda allows to have multiple pages per row, not just one.
LOL. Yes - I often say that my comments would be a lot shorter if I had more time.
So here’s my reaction to that - if you have the opportunity to shape the event handlers to provide direct access to specific editors and the context is easily understood (i.e., users choosing to click on specific objects within specific rows - not the open row icon), why enforce the same outcome for three different click events? It seems wasteful and ignorant of the context and there’s an opportunity to add additional elegance to the UX.
If this is the way Notion works, it’s not good either. I don’t really care what Notion does and I think it’s possible to support an elegant option while sustaining Notion’s poorly-designed approach.
I see this as no different than selecting the open row icon which results in a different [data] behavior depending on the row selected. So, why not extend that model to allow Makers to connect specific editors (i.e., layouts) for specific columns? If events at the row level are contextual to the data in each row, shouldn’t the UX be [optionally] contextual to the field you feel compelled to click on without a complicated Mega Trick?
Circling back to the open row icon and taking this a little further - it’s my assertion that open row events should also [optionally] support conditional editor layouts. Given the nature of the data, one can imagine an app that asserts a specific editing layout to ensure ideas like data integrity, or data completeness based on specific selections or data patterns within the row. Maybe this has been hashed out elsewhere in the community - sorry if I’m on a rant.
These fields indicate they have “canvas” options, ergo, my assumption that they are indeed canvas columns.
