Hi @GJ_Roelofs, the revision history for a row is in the dropdown of the row detail where the default is “Active Comments.” See this gif below of a row detail where you can switch to “Comments & Activity” to see the revision history:
For your original question, Coda is indeed suited to be a wiki for projects of all sizes. I’m curious which specific features from your original post are most important for your wiki scenario? From this response, it appears that being able to customize layout and the content of the page is important to your use case. We are indeed working on making Coda docs can have more customizable styles. There is no timeline set yet on these features, but it is something we are actively planning and working on!
I definitely missed this feature, you have my thanks!
It’s not ideal in that it displays the entire value of the content instead of a diff, making it hard to use if a single Text column holds the contents for a page.
But, it definitely solves part of my issue!
I’m curious which specific features from your original post are most important for your wiki scenario?
My primary issue at the moment is that if I use a row per page, and a single Text column to hold the “primary” content of the page, it’s very hard for users to style the page as they want.
E.g.: Most users come from other wiki setups or even Google Docs, and in my usecase I want to enforce certain (data) structure on the users, but allow the page styling / content up to them. (Positioning images, etc).
You may want to consider creating a button that directes people to edit the current “page” content. I set this up by usen OpenWindow() and concatenating the current row’s URL and “&columnId=c-fYo_tdyz5K&modal=true”. You will need to find the unique column ID where your page content is stored.
I’ve opted to use the Detailed View as the basis for the wiki setup as that is more accessible.
(The column with content is then displayed in a specific cell which is easily editable.)
@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.
Thanks for the detailed feedback here! Our product team is actively looking at comments like this in the community forum to help shape the platform so your feedback is invaluable.
@Al_Chen_Coda With my hacky work on the Hierarchical Sections (because a text column doesn’t support the same level of customization as a section), I’ve moved more to a Sections-as-Pages perspective. However, I haven’t been able to find any way to view the history of a specific Section.
You can view your doc’s version history by clicking the dropdown arrow near the title of your doc (see this help article for details). This version history feature won’t let you see the history of a specific section over time, but as you click on previous versions you can just click to the section you are interested in as the historical version loads.
It does make it quite hard to find changes to a specific section once a document gains in size?
I assume that there will be a limit on the history further down the line and a separate history tracker per context (a section being an example) will allow you to avoid spamming the history with trivial changes.
E.g.: Row Manipulation easily generates a massive amount of history changes low in value in certain use cases, per example as cards in Kanban setup.
I have accumulated the impression that Codans don’t realize entirelly the immense capabilities that Coda gives to the users for building non-structured information. I appreciate the ridiculously powerful tables of Coda, but there is a user profile that would really appreciate to combine tables with more flexible text work. Not like notion necessarily, although their document model is great.
I don’t have choice. I use tables a lot. But I have tried notion documents and man, it’s so immediate and extensible…
We are most definitely looking at ways to make the text only experience better! These things take time though, it’s not something that happens in a week or two.
For one, I’m using Coda also as living document for customers. I have formula connected reports with data, and when data changes, reports changes accordingly. It’s just too good
@BenLee by any chance can you share the design or approach you are planning for this?
For example do you plan on expanding the table cell functionality to support unstructured data in a cell (essentially a section as a cell element), or do you plan on going with better Section support (folder hierarchies, better section referencing), or maybe something else entirely?
Because we are currently holding on moving our design and other similar docs to coda since we’re not sure if we should go with the Section per doc approach or Table with Text field approach.
Hey @Ed_Liveikis, been appreciating your posts and another good one. I just referenced this post in another carrying on the Roam Research dialogue that’s been active around here lately. I would also be very interested in hearing more about the Coda Product’s team plans in this regard. Like @GJ_Roelofs, I’ve also experimented with using Row’s themselves as actual documents, due to the attributes they have that Sections don’t. And the absolutely terrific writing capabilities you get - in particular the ability to pop-out the Rich Text sections, which also expand in a table view. This is great if you want to see a list of your docs and actually see the contents in that list:
