Hello,
Following the recent changes of Coda 4.0, I believe an important update could be made in regards to the tables visualisation - have direct access to table rows in the left panel similar to how pages are visualised.
Proposal
Similar to the option to embed another page, add the option to embed a table, or view of a table. Embeding the table, should result in all rows being listed visually as subpages in the left pannel.
- The name of the page could take the information from the value of the main column of the table;
- The page will be in the layout set for that specific table or view;
- The subitems will be also a cool addition to this feature, as each row subitem could be listed as subpage for the corresponding row (page).
- Ideally, the pages will be synced automatically upon change of the table values:
Filtered(hidden) rows should no longer appear in the pannel;
Changed value, should rename the page;
Deleted row should result in deleted page;
But even manual approach to update via formula, by using button, automation etc. will be good enough.
Pros
Where the Wiki Model is needed, it can still be achieved only with a few tweaks of database tables.
It’s a lot more convenient, as you can still use all the cool things you can do with the data in a table while having a page visualisation.
It’ll probably help with the performance of mobile app. Currently, at least for iOS devices, if there are too many pages in the document, it’s just not loading at all.
With this change, organisations will still need to add some more doc makers to keep the content organised, so you’ll still have increased revenue but with fewer complaints on the editor’s restrictions.
Why
Imagine the following case:
- An organisation decides to go with this product, because of the good-value pricing. You need a few doc makers to build the hubs; everyone else could manage the doc contents.
Now this cease to be possible - you either need to upgrade everyone to a Doc Maker, which is no longer competitive, as it’ll be a lot more costly than going with another product, where all seats have equal rights and are a lot cheaper than Doc Maker. Or, the Doc Maker should go and create pages every time someone needs it - not sustainable at all.
The suggested approach will still mean a slight change in the processes for a lot of teams, but it’ll still allow for the wiki model to be used whenever it’s more convenient for the team =
- For a new organisation looking for such type of product, it’ll be less appealing to have all those limitations, without any workarounds.