The reason I often end up with tables with 200+ columns.
(Half of them are buttons and bypassing Coda flaws with tricks.)
2 Likes
The problem, I find, is with naming all those columns! How do you maintain names that are not a disaster for other people?
2 Likes
Use a lot of layout/modal views. Most of the users are not Makers (98%) and tables are currently pretty bad UX on mobile, so I use layouts and there I name the fields appropriately.
One of the reasons I still use Coda over Clickup is that users donât necessarily have to deal with 200 columns at a time and all menus and stuff in the UI of Clickup. Most users need 1/5 of the data in raw format and fields for editing. So, the problem with the column naming for the users is mostly selecting what to show and what not.
Also, I use the column descriptions - either for the users or the co-makers.
For Makers we also try to follow structure of naming the columns, e.g.:
h_ - hidden and used only for calculation
t_ - formula text for layout UI purposes only
d_ - formula used only for design purposes
f_ - formula used to filter data (usually on canvas)
b_ - button
v_ - used in in layouts for visual formula content
db_ - database relations column
DEV_ - columns in development
DEL_ - columns to delete at some stage
And I often create screenrecs for some more complicated cases.
What is your way to handle the column naming?
3 Likes
Love the prefix system. Iâve been doing something similar but yours is more comprehensive.
And yes, most of the columns in the table tend also to be helper columns or buttons, for similar reasons.
Iâd be curious as to how you optimise for mobile? Just lots of smaller detailed views with a subset of fields that are opnened via a dedicated button?
2 Likes
Prefixes are useful (and common practice among programmers).
But I prefer to add suffix symbols when designing data models in Coda (or other no-code tools).
Two years ago I posted the following article about this approachâŠ
It has the advantage of not being intrusive (much) for users (and even adding clarity in some cases). The big advantage is the improvement in productivity and accuracy.
ă
â¶âă
1 Like
I have given up on mobile coda.
Instead I get users to use the desktop-view in their regular browser (and NOT install the coda mobile app).
Then they see the same layouts as desktop users⊠OR⊠we can create separate views for them.
ăâ¶âă
2 Likes
thanks! this was helpful. My struggle with putting everything in fewer tables comes down to column naming. How do you avoid ending up with 100 columns???
1 Like
you only use modals and not tables? what about when you need to display information for comparison? and how do you keep track of which columns belong in which modal?
1 Like
Having fewer tables is NOT my goal.
I use my Agile Architecture Framework to help makers define the minimal set of Business Objects needed to automate their business process.
Most of these objects are implemented as separate TABLES. So we create the RIGHT number of tables needed to model the business process correctly.
This is known as a â3rd Normal Form Data Modelâ or just âRelational Databaseâ for short.
And each table has only the minimal number of COLUMNS needed to model the object within the business process.
So we almost NEVER end up with dozens (let alone hundreds) of columns in a table.
And the naming of those columns is pretty obvious as you architect the database. Most columns need only a single word for a name, two-word names occasionally.
The important advantage of this architecting process is that the resulting set of related tables ACCURATELY represents the data needed for the business process, and insertions, deletions, and updates all occur efficiently.
If you try to have as few tables as possible without using a good architecture, you will run into problems with how to insert new objects, delete old objects, and modify attributes in a consistant way.
This is what I mean about makers hitting barriers if they do not have any knowledge about analysis and design techniques.
I did have a client who had hundreds of columns in some of their tables. They came to me because they were having serious problems trying to tailor their Coda docs to meet the needs of their different departments. They had just slapped-on extra columns to their master job table in an attempt to record the needs of all their departments.
When I normalized their database, they had a dozen tables for all the different business objects they were trying to track, but each table was simple and manageable and easy to understand.
As a result, their user-interface was far more eligant and fit for purpose.
EVERYTHING becomes way easier in no-code when you have the appropriate data modeling architecture!
Respect,
ăâ¶âă
1 Like
Using MODALS (aka âdialogsâ) for the user-interface is extremely useful in Coda.
It lets us design the best screen-layouts to help users see what needs to be done at each point in the process (known as the âaffordance architectureâ). ie. its âobviousâ what to do.
But you must remember that modals allow us to include TABLE-LAYOUTS as well.
So it is easy to display tabular information, charts, select-lists, etc. Thanks to Codaâs amazing UI capabilities.
As I have said above: when you use the Agile Architecture Framework, you end up with a well designed set of tables which then map to a well designed set of modal layouts that represent the entire business workflow in an âobviousâ and easy-to-use UX.
As you point out, âhow do you keep track of which columns belong to which modal?â would be a big issue if you didnt have a good design.
One extra advantage of the use of modals is that we can add ânavigation buttonsâ to each layout so the user can effortlessly navigate their way through the whole application.
And these buttons will also contain the necessary business logic for inserting, deleting, and modifying, rows in the database tables to reflect the choices made by the user.
Respect
ăâ¶âă
1 Like
Hi Ariella,
Listen to Max. I consider him a mentor in how to work with data structure in Coda.
I use tables and usually they display up to 5 columns which are mostly a summary (Canvas columns with selected data displayed). I have not given up on the Coda app and mobile experience yet because of the notifications and comments on rows (2 powerful features but not accessible in published mode - another stubborn decision of Codans who deny to accept that they are incapable to build proper UX, especially on mobile).
Comparison happens with buttons and additional table. Iâve built reservation models and analysis and non of the data is in a table; itâs on the canvas triggered by buttons.
Very relevant question on the naming for the modals - honestly, I donât have a system for that. Just follow the UX logic, like Max noted, using buttons for navigation experience. I am not developer; I am a business innovation manager. For why, I am interested in the UX and build according to it.
1 Like
@Ariella_Messing @Daragh_O_Shea1
Absolutely agree with Max!
I need to learn more about achieving less columns per table because there are still use extra columns for filtering purposes, summaries, visualization, etc.
In most cases, though, tables have many columns because items have many characteristics. Right now building my business innovation practice for my second real-estate company and properties have many characteristics - 182 to be exact. They are so many that I canât even fit them in the same modal so I split them in views.
(And yes, I am guilty for building for UX, which Coda really sucks at, and thatâs why several of the extra columns in this table are the buttons needed for that top menu. At some point I will get the buttons out of the table but not until the business sets up)
I have a lot to learn from Max and Paul and Chris and other champions. And at some point I just admit that I donât know enough, and need to hire experts.
1 Like
I dont see anything wrong with building for the UX.
Thats like saying âI am guilty of building for my usersâ!
I know some developers who build the âidealâ data model with no regard for the UX.
As a result they model all kinds of features and complexity thats not needed nor used by the users.
I prefer to place the data model entirely in service to the final UX - pairing it down to the minimal architecture needed for the users usage.
We can always add on more bells and whistles later when the users need them.
Its not good to push tons of details and features at the poor user just because you designed the âultimateâ data model. They should only see whats needed to do the job and not a byte more.
Designing a SIMPLE and ELEGANT user app is much harder than throwing in everything and the kitchen sink.
2 Likes
Thanks, Stefan. It was actually the expert I hired who left me with tables with 100 columns! When I started it was around 10-20 per table!
1 Like
The thing about using buttons (which I am using!) is that they donât work in either cross doc or sync pages!
2 Likes
Actually⊠we are providing buttons on our cross-doc tables.
We used to avoid cross-doc tables due to their limitations, and we used lots of âwebhookeryâ to send and receive data from our back-end docs.
But recently we have started using 2-way-cross-doc tables (now that they work a lot better, thanks @Nina_Ledid!) and we have had to find ways to provide buttons on them!
So we have special cross-doc pages that include a cross-doc table but also has extra columns defined (locally) that include computational-formulas and action-buttons.
They are not officially part of the cross-doc table, but they work just like formulas and buttons would on a regular table.
The only trickery thing we still need is a way to trigger the client-side refresh of a 2-way-cross-doc table. Edits go from the client to the server-doc in (almost) real-time. But the âhourly refreshâ option is too slow for our uses - so we force a refresh using buttons.
This is still a bit of an experimental work-in-progress - but I will post a detailed how-to if people are interested.
ăâ¶âă
1 Like
I definitely would like to see a sample setup.
(Recently, I tested a table with a series of buttons in combo with _Delay() to trick automation runs. Not sure how this affects performance of the doc and havenât implemented the idea in a real doc. Just mentioning. Ignore if irrelevant 
)
1 Like
Iâm not sure that the goal specifically needs to be to use âfewerâ tables or to use âonly modalsâ but rather to have a backend where you store the data and not worry so much if you have a couple of columns that are blank for a use case.
For example, I have to have a database for quotes. A quote takes on different forms. There is the backend entry where I actually put the data in, then there is what the customer sees, then there is the edits and adjustments that need to be accounted for. so Instead of creating 4 different tables to store this basic change of information, I created a single table, then created subpages which contain the views for each of the respective needs. Within the views, I have different row layouts.
For this use case, I take the quote table database and I only display the columns that i need to enter. the back end stuff, like, the cost I pay for the product, the discount Iâm using, the internal notes about the transaction, the special discount codes I generated for the sale, etc. Then, I enter the % of mark up I wish to use as my quote basis. I donât see any of the fancy stuff the customer sees in this view. I only see my stuff. Then I click a button and it moves me to the customer version, where I can adjust as needed to make it fit on my PDF, and then I âprint to PDFâ and boom - customer quote ready to go. Now, that is stored in its own view.
I think the bottom line is just making sure that your entities are broken down properly. If they are, then itâs unlikely youâll have an inordinate amount of unfilled columns. If youâre still finding that the columns are excessive like that, perhaps try to reconsider what those columns are representing.
Are they truly data that needs to be separated or could they be combined? With my Organizations database, I thought I had to separate all of the types of orgs into their own columns. So, I would have these columns:
Org Name
Address
Board Association
Customer Account
Vendor Account
etc.
But, then I realized that the TYPE they are is more of a categorization. So instead of having 3 columns, I changed it to one âCategoryâ column and have a drop down which says âCustomer Accountâ âVendor Accountâ etc. Which due to this, allows me to put different views in my side bar and filter properly.
This is going to sound silly perhaps, but I figured a lot of this stuff out using a AI Chatbot. It takes some time to get the language right to ensure youâre returning the proper stuff, but my suggestion is Claude https://www.anthropic.com/
This isnât the end all be all of everything, but it helps you parse out thoughts that are otherwise hard to articulate. You can sign up for free, but keep in mind that your tokens are limited on the free version so make sure your requests are concise. Sonnet 3.5 has the best natural language and ability to detect nuance in what youâre asking. It can also generate code. Word to the wise, tell it exactly how you want it to reply. If you go on and say âHey, help me understand how to structure my data in a relational databaseâ you will get a gigantic flow chart that you canât even read with a bunch of code that represents how to set up a traditional database. So instead, say something like âYou are a collaborator helping me parse through my thoughts about how to structure a new CODA database. Please help me understand a few different ways that the following sets of data could be organized and how they could work together:â then provide a list with some basic descriptions of what youâre trying to do.
âI have Customer Accounts, Vendor Accounts, and Board Associations and I canât decide if they need to be in one big table or three separate ones. WHat are the pros and cons? I have to connect all of these to my People table, which then ends up with 3 different columns itself if they are all separate, but keeping them together presents limitations tooâ
Or something like that⊠the nice thing about it is that itâs there 24/7 and has very expansive knowledge. Do not rely on it for 100% factual information and the code/formulas it generates for coda DO NOT WORK. Instead, ask it to explain to you HOW to structure the code or the formula, and it will break it down and tell you what elements are needed. Then you can do the research on Codaâs website or other threads on the forum here and generally find what you need.
Hopefully this was helpful! Oh, also here is a pic of what Iâm referring to about the views.
2 Likes
perhaps Iâm not explaining my situation well, or my use-case is different than most.
I have tons of buttons in my docs for opening detail views, copying links to clipboard, etc. Iâve got many layouts carefully designed with the necessary columns.
My docs, however, are a work in progress, or contain more data and information than Iâm trying to use/share at any given time. Here are two situations Iâm running into with different docs:
scenario A
I have a doc with 4 DB, one of which has 25,000 rows. If I want to examine a subset of those 25,000 rows (say, all rows created last month) in another doc (so that I donât grant access to all 25,000 rows) w/ a colleague, I have two options:
- use cross doc, filter in the rows from last month, and recreate all of my buttons. This also means Iâm limited by cross doc not syncing all the relational columns.
- create the filter in my source doc (thus avoiding the issues of the relational columns and detail views), then use a page sync. This means either buttons are deactivated, or I have to grant access to the source doc.
Scenario B
Iâm working on a wiki/knowledge base. Itâs a work in progress, and I donât want to grant everyone access to all of it just yet. However, Iâd like to share a few pages that are mostly finished. I decide to create a new doc and use sync pages to share . My options are:
- if I want buttons to work, I have to grant access to the source doc. but then said buttons sometimes open the source doc. clicking on a relational column also transports you to the source doc.
- allow the pages to be viewed by anyone with access to the doc and restrict access to the source doc. this means buttons are greyed out, leaving me without the option of opening modals.
am I understanding this correctly?
1 Like