@Al_Chen_Coda @Juan_Luis_Chulilla Having worked with the page-per-row flow a bit now, I think I can describe my optimal/dream scenario better:
- Define a Table which will describe all Pages in a particular Section, which allows me to:
A. Define attributes per page.
B. Allow a Table view of all Pages of a section, allowing for all workflows normally allowed by Coda. (filtering, formula etc)
- Hierarchical Pages/Sections
A. Where the relationship of this hierarchy is encoded in the Table of the Pages. Ideally the existance of this relationship limiting the hierarchy or not.
B. Pages in hierarchy use the Table attributes of their nearest (grand)parent Section.
Issues and workflows this allows me to solve:
- Meeting structure where a single Page in a section describes the meeting minutes, and the attributes allow for easy definition of Tasks (relation into other table). These Meeting Pages then can have tags, time and other attributes to be easily filterable / searchable.
- Design document where for Pages I want to be able to define categories, tags & attach tasks to Pages so I can later see what a Task was related to. In a design document I would often then still have adhoc Tables per Page for specific structured content. E.g.: A page that outlines a specific part with a Table containing the variants of that part and their info.
Summarized / More abstractly
The primary strength of Coda is allowing for structure on information.
However, at the moment top-level it is either all unstructured (Page / Document), or all structured (Row).
I.e.: If I do my meeting minutes as a page-per-row approach, I lose (per example) the ability to adhoc create a voting table in the Page as the context cell is Text (The only alternative being that I can add in a vote table to ALL meetings). If I do my meeting minutes as a Page, I lose the ability to attach attributes that I can filter on (like date created, categories, tags) and easily be able to ask questions such as: Show me all meetings where I was present.
I need a hybrid where I can say: “This part is structured, this part is where you can do what you want”.
The chaos of Sections
The other issue is that, in my opinion, the current single layer approach to Sections actively undermines the design of Coda.
E.g.: Structure & relationships in Coda are key. I love the fact that I can have a single source of truth for a team and know when and where something came from. I.e.: a Task tracker that allows me to connect tasks to design pages, meetings and bug reports and see at a glance the entire context of that Task.
This however requires me to have all these Tables in a single Document (because Coda doesn’t allow inter-document connections), which then becomes unmanageable because of the single-layer Section hierarchy approach.