It would be nice if you could programmatically hide and unhide columns on a layout.
Example:
I’m trying to recreate a Quicken type register. I’ve got it mostly working but I’ve hit a snag with splits and transfers. I made a creative way to handle both but here’s the challenge. If an item has a column that indicates it is a split, I’d like to be able to see the split information when I open the record. However, if it isn’t a split, then I don’t want to see those fields as they can be confusing. Same thing with transfers. If an item is a transfer from one account to another, then I’d like to see the information for the transfer but if the item is not a transfer, then that information should be hidden during edit.
This could be a feature not just in layout of a table but could also be handy in the canvas itself. Right now I do have some items using IF statements and just using “” if I don’t want to see anything but that often leaves on the page which is annoying. I believe using " " removes the but it still leaves the little empty block. But…if one could set the attribute for the formula on the canvas to hidden then BOOM, little box wouldn’t show and the information would show if the if statement conditions were met.
And yet another case for wishing we could hide/unhide things.
I have a client who books appointments and based on the type of client, they might have different required inputs. Fine, but even within that they might have another need for this when choosing a location for the service.
Example:
Client might have services at a school, business, home, or some other place. If one has a choice field where they choose the type of place, you can lookup the address for the school, business or home but if it’s other, then that needs to be input. But leaving an OTHER field on the form at all times makes it confusing as some people think everything must be filled in. Having the ability to hide or show a field based on a formula in either a detail view or an input form or even on the canvas would be fantastic!
Hiding\unhiding columns with a button and with a formula would be a game-changer for me too. To hide\unhide columns in table, detail, chart, form would cover a lot of use-cases. And it would make coda feel a lot more like app.
This was once an experiment that allowed this (there’s even a gif of it)
But my plugin injected itself into the internal Coda client app apis, which is unsafe, could bring Coda extra problems, and is generally against ToS.
While I agree having this would be cool, I’m not so sure this is conceptually right to do. At the same time, I believed Canvas columns were conceptually not right for Coda, yet now we have them.
Thank you, Paul! I’m not surprised that you already tried to hack this shortcoming and you succeeded
My vote in favor of this feature is user-focused. Currently many layouts are very overwhelmed simply because there is no conditional display of columns. Examples are hundreds.
Only today I was asked “What if there are more than one phone numbers per contact?” The answer could only be “We have to either add 1-2 extra columns for all contacts or you just keep only one phone number”.
When there’s multiple phone numbers per contact, the correct answer would be to make a table of phone numbers, with one row per phone number, linking it back to the contact. Or, alternatively, just enter them all into a single cell in some conventional format, e.g. separated by ; and then split
This is what I usually do but when we need 5-6 such sub tables it gets crowded and sometimes user don’t even need to see an option unless a condition is met. I know it might be a bit too much to ask, but would be super cool UX, and UI would look much better too.
Paul Danyliuk is right: subtables are the answer. And the ease with which subtables can be added makes me wonder why this is an issue if keeping multiple numbers can be important. In my documents, I have more than six subtables for one main table and it doesn’t make things crowded. Many rows have only one entry in a subtable, but where it is needed, it works like a charm.
Maybe I am not making myself clear enough. The number of linked tables is absolutely not an issue and this is exactly what I do. But visually it’s a problem when details to be added vary depending on the previous entry.
Here is a case: A table for contacts. These contacts could be individuals or companies. Companies have completely different fields to fill than those of individual. Then if the individual is foreign we need different data than local. So whether to show a reference table would depend on some conditions defined by select list of the current or another reference table. Sounds a lot like filtering but whether the field is visible in the layout or not.
Among the simple examples is also that although there might be 10 phone numbers per contact (company) one might not have to/want to see these. Either because it’s too much on the mobile screen or because they are not supposed to see them.
Workarounds are many but they are not making a doc looking better or feel nice on mobile. And, yes, I am more concerned on use on mobile devices. On 45” screen I don’t care about space.
@Paul_Danyliuk As a proud patron I watch all your videos (sometimes a couple of times )
@Stefan_Stoyanov , my feeling is you look for a solution know as branching in forms, you only show related questions and this assumes you can reference questions (columns) to hide or show them.
cheers, Christiaan
@Christiaan_Huizer That’s the UX expected. On the background I see this as hiding and unhiding columns in different table views. If there is a button to hide/unhide column, then any of these cases should be quite achievable. Maybe later for forms (I personally prefer this first for View, Edit and Publish first).
)
(I personally prefer this first for View, Edit and Publish first).