+1 for this. Also trying to implement PARA from Marie Poulin’s YouTube videos for Notion and having to add pages and reference them manually.
+1 I’m really looking forward to this feature becoming available!
1 Like
See how Notion handles Page management. Everything consists of a page. This makes cross-referencing information much easier. Let’s say I want to build a table with my daily notes. Each row could contain a proper Page with rich content while the page itself shows the meta-data of the row.
7 Likes
+1, Looking forward for this feature!
This feature is something that I have used in Notion in the past, and found it intuitive and highly flexible.
As for a quick daily work use case example:
Doing product development, I want to record my design details in a collection. Each new design or design version takes a row in a master table. The design table allows me to store top level data (version, project, leader, etc) and the page-in-a-row aspect would allow me to create a larger body of information including pictures, code snippets, comments, tables etc. that document the design. Having the designs in the table allows for referencing elsewhere ( design inputs tables, validation and verification testing tables etc).
Hope that is somewhat helpful.
Cheers,
Michael.
2 Likes
Anyway column type “Subpage” is very good for moving from Notion to Coda.
I’ve read everything in this thread twice, and I’ve been thinking about both what other people need/want and what I need/want. My thoughts are not fully formed…
I think there are three issues here - what you see, how you interact, and how you navigate.
In terms of “what you see”: what I want, and what I think people want, is a richer, less limited version of card/detail views. Those are designed to be “single screen” views, which is a very valuable thing. BUT it means that when you have text of unlimited length, or needs for rich text, you end up typing in a box that fills up and having scrolling issues, and also having lots of your viewing space taken up with empty boxes that are not serving your current purpose. In other words, what we want is a details view of a row that looks much more like a page, where it just scrolls off the screen as it gets bigger and you have access to all the usual formatting options.
That, just implemented without care, would be a UI problem. You have a details display that looks just like a page. BUT it is not a page, because there are restrictions on what you can do, and there need to be. If your table has columns of number, date, select list, text, etc, you can’t have the user just putting the cursor anywhere and adding anything/deleting anything. Column headings need to be uneditable.
Suggestion: use the Forms vocabulary, where there are boxes etc that indicate places there the user is free to act. BUT make the text boxes “open” - they start with a single line, but you can write as much, using the full doc tools, as you want.
The other issue with this is navigation within the page/detail. What I would suggest is re-using the existing “outline” model - the column headings become a clickable outline that is there on the right of the “page” automatically.
There is another, different navigation issue - between page/details.The current cards and details mean that you are never very far from the tools that get you to the next record. But on this “page-like details” view, there could be large amounts of text between you and the navigation at the bottom. (And if you put it on the left, it takes too much space and ruins the whole idea of having a more page-like interaction.)
This is where I am a little less certain about what I would like and what other people would like. I think a lot of the “rows as pages” thought will come down to whether you want to use the left (doc/page navigation) menu for this purpose. My impression is that what people are imagining is something like the following: your master table is a page, and each of the page/details/rows shows up as a subpage. (The other option would would be some sort of persistent navigation element that stays at the top of the page when you scroll down.)
So bottom line: a details view which looks like a page/form, with the columns as an outline on the right, and text columns show up as a completely-expandable (no scrolling) text box with full access to the usual text-editing tools. (Maybe called “page” columns to distinguish from regular text?). An option to make the details/rows look like subpages for navigation on the left.
If any of this doesn’t make sense, I can try and clarify. If I am mischaracterizing what people are thinking, sorry!
1 Like
Hi All,
The topic of “Pages like Notion” is recurring topic. I have built an example doc of how that can be implemented in Coda, and I think surpass what can be done in Notion. (I must admit that since I moved from Notion to Coda, I have not used it much, and will therefor not be up to date with the latest in Notion.)
Here is an explanation: Loom | Free Screen & Video Recording Software
Here is the doc: Notion Like pages in Coda
Regards
Piet
4 Likes
I’m interested in using Coda for my personal life (I like organization…what can I say?). I’m currently using Notion, but LOVE the overall functionally and aesthetics of Coda. This is really the only thing, like others have said, keeping me from switching fully from Notion.
This would be idea for me when I track “places to visit” or other such things. That way the place would have it’s own “page” so I could add information like top 10 things to do, or plan an itinerary.
2 Likes
Is there any progress on this? I ask because I love most features of coda over notion for personal use, specifically for graduate medical education, but notion’s “everything is a page” is key, as I would have many documents of notes, each pertaining to a given topic, and the topics themselves would exist as rows in a table to be organized, searched, and codified (especially in a spaced repetition formula and application to a calendar). I believe there is a workaround to this I could figure out, but it would be complex, and given that it already exists in notion, it makes the switch to coda tough.
2 Likes
Hi Kelsey,
Welcome to Coda!
Please see the below for way that I have implemented what you are looking for.
I hope that you find it useful.
Hi @Coda_Zac ,
There is a common pattern where you have a collection of items, about each you want to hold both structured and unstructured information. Examples:
Ebay listings: structured (item name, price, location, condition, weight, SKU); unstructured (general description of the item with some pictures and links to where it came from)
Electronic Medical Record: structured (patient name, date of birth, sex, phone number, SSN, insurance carrier, list of allergies); unstructured (description of patient history, photos of patient, x-rays, story of how they injured themselves, and a description of the family that’s taking care of them).
Meeting notes: structured (date, time, room location, participants, project name) unstructured (notes about the conversation, some links to background documents, photos of the whiteboard, some follow up action items, a poll on how people feel about it)
A portfolio book of clients: structured (client name, website, deal size, date, location, industry, key contact name), unstructured (a description of the work done, pitch decks, invoices, milestones met, lessons learned, the friends we made along the way)
This general pattern of collection of things about which each has both structured and unstructured information shows up a lot!
You can also think of an item with structured + unstructured content as an unstructured (rich) document with structured meta-data.
In coda, you have two choices on how to represent this:
Mostly structured: you make a table with a row for each item. It represents the structured content well, but then you just tack on an extra text column for miscellaneous unstructured data. Text fields are not nearly as powerful as actual pages though, and so you can’t take advantage of all of the powerful features of Coda for expressing unstructured content. Very well organized, but not very rich.
Mostly unstructured: you can have a Page (or sub-page) representing each item. This means everything you want to represent, even the structured fields, is just blocks in a page. It’s very expressive, but you lose out on the searching, filtering, sorting, and automation available to tables. The pages don’t have a strong relationship to each other, even though they represent a lot of the same information. Very rich, but not well organized.
The rows-as-pages idea means that you can capture both structured and unstructured information about each item in the partially structured collection, and you get both the first class searching, filtering, sorting, and automation available to table combined with the first class expressiveness of a page of blocks for the unstructured content. It’s a best of both worlds, and win-win!
Separate for the use cases for partially structured collections are the template use cases that some in the comments have mentioned. This is where the information stored about each item in a collection is structured, however I want to display it by populating those values in an unstructured (block page) template. In my view the structure in template and the partially structured collection are distinct enough that it is probably best to handle them separately within the UI.
Hi Aaron,
At their recent consumer outreach/ block party Coda has announced that this feature is nearing completion.
In the meantime the workaround that I mentioned above works nearly as well as the real thing. It provides a third alternative to the two that you mention in your mail.
Regards
Piet
It doesn’t quite work as you might think it does. This request thread probably still stands.
2 Likes
Hi @Aaron_VanDevender – would you mind expanding on this a bit as it seems to align with the problem I’m attempting to solve. We are implementing coda to develop and maintain standard operating procedures (SOPs) which contain both structured and unstructured data. My initial thoughts were to do exactly as you described – each SOP is a row in a Master SOP table with the structured elements as columns and then the actual writeup, screen captures and relevant tables stored in one column formatted as Canvas. It doesn’t seem like the most elegant method so if you have any suggestions, I’d love to hear them. Thanks, Nate.
HI Nate,
Welcome to Coda!
I have implemented two approaches to this topic in the doc below.
The first approach, Meetings, uses a table with a row for each meeting. It contains fields for date, convener, etc. A column in the table uses the canvas column to store information about the meeting. This is created by default from a template. It includes a table view with attendees, a table view with action items and room to capture notes about the meeting. As far as I am aware, a canvas column can only have one template.
Therefor, in the second approach, Projects, I make use of page templates. Once a new project is created in the project table, the user can decide the type of project that it will be. Based on the decision, a prepared template is copied for use during project execution.
Have a look, and see whether there is anything that interests you.
Regards
Rambling Pete
1 Like
Hi Nate,
I think the one SOP per row with a Canvas column, and then formatting unstructured data in there is your best bet. I think it can be at least somewhat elegant depending on how you format your Canvas, but the functionality is all there.
-Aaron
Thanks for sharing that @Piet_Strydom. The two-template option got me thinking as we’ll need a way to do both procedures and policies. I intended to handle them separately, but like the uniformity of this approach. I can also see some great value in the clever “Archive Action Update” button you created – we have numerous instances where a date-stamped list of comments relevant to a specific RFI, change order, etc. is needed.
1 Like
Hi Nate, And @Aaron_VanDevender , thanks for your ideas.
As usual, my biggest worries are related with scalability, and i don’t recall I have an answer on that matter regarding Canvas format.
See, when you use this method for (single) project tracking, seems all ok, since it has an end and its logical to think an one-document-per-project structure.
But when you are trying to develop some kind of management system, dealing with processes, procedures, and management related stuff, you have a problem some point in the future.
So far, I’ve only come to a extremely costly to develop solution, where you track down everything and implement processes for archiving obsolete elements to keep your document light enough.
First of all, make sure what you want to achieve.
- Document your processes, (all ok, just maybe create copy each year or so, and clean non active information on the master)
- Track your records (scaling problems, require to develop some kind of archiving capabilities)
- Set measures and KPI (previous twice, plus the necessary business logic)
- Control information (here you need to outsmart everythin. Since for effective control you need to be able to work with records and measures along the time axis, you need some way to gather such data from all your different archived data storages You could do some kind of dashboard in yet another document but connecting it with all the others would be really difficult (there are some community packages that could enable that). Other way would be to evaluate archiving data, and calculate some normalized values to show for comparing evolution and so.
PD, the reason why it keeps complicating so much its because in the end, you are one step away from emulating professional Process Management suites just in your Coda doc! 
PD2, being in charge of such things in my microbusiness, i have been years thinking of using CODA instead of Bonita Soft or so, and just scalability keeps my out from this idea. But tieing my entire organization to something such as Bonita Soft or Atlassian (Confluence+Jira+Flower) or so scares me a lot, as it would be very very difficult to move out from there if required
Thanks @Aaron_VanDevender – I’ve been exploring the options since my post and agree this seems as close to a “best practice” as I’m likely to find. Thanks for your input on it.